kwhitefoot

Friday 9 February 2018

Mellerware 84300 breadmaker manual

If anyone is still looking for the Mellerware 84300 breadmaker manual you can download a scan from my Google Drive: https://drive.google.com/open?id=1O4k6Xvne6RWjdZp_I_u2BneIfiFydOjG

Friday 11 November 2011

kisielk / covenant / overview — Bitbucket

kisielk / covenant

covenant - A Python design-by-contract library.

Clone this repository (size: 35.3 KB): HTTPS / SSH
hg clone https://bitbucket.org/kisielk/covenant
hg clone ssh://hg@bitbucket.org/kisielk/covenant

Posted via email from kwhitefoot's posterous

[Python] Ryan

Check out this website I found at pastebin.com

Posted via email from kwhitefoot's posterous

python-dbc - Design-By-Contract features for Python - Google Project Hosting

Summary

This project enables to use the basics of Design by Contract capabilities in Python, such as enforcing the contracts defined in the epydoc documentation. At the moment, it is highly work-in-progress, so you are not expected to use it successfully: but have a look and maybe assist me in getting it done!

Download

To checkout the project repository (assuming that you have Mercurial client installed), use the following command:

hg clone https://python-dbc.googlecode.com/hg/ python-dbc

Requirements

For the most important functionality of this module, you must have epydoc installed. Please refer to epydoc site or your Unix/Linux distribution regarding the installation details.

Though, you may use the more general helper functions like typed(), ntyped() or consists_of() from the module without using epydoc, if you just need to perform some simple type assertions.

Usage

Are you tired of declaring the same assertions twice, first in the epydoc declaration, then in the code?

def hypo(leg_a, leg_b):    """    @precondition: leg_a > 0    @precondition: leg_b > 0    @type leg_a: (int, float)    @type leg_b: (int, float)    @rtype: float    @postcondition: result > 0    """    assert leg_a > 0    assert leg_b > 0    assert isinstance(leg_a, (int, float))    assert isinstance(leg_b, (int, float))    result = math.sqrt(leg_a**2 + leg_b**2)    assert isinstance(result, float)    assert result > 0    return result

Don't waste the code anymore. Just do this instead:

from dbc import contract_epydoc@contract_epydocdef hypo(leg_a, leg_b):    """    @precondition: leg_a > 0    @precondition: leg_b > 0    @type leg_a: (int, float)    @type leg_b: (int, float)    @rtype: float    @postcondition: result > 0    """    return math.sqrt(leg_a**2 + leg_b**2)

And all the assumptions and assertions defined in the epydoc docstring for the function are automagically checked whenever the function is called!

Note that having to verify all the incomes and outcomes may significantly decrease the performance; therefore, these verifications (similarly to the only DbC-related Python builtin assert function) are completely disabled if the code is executed with optimization, i.e. via python -O or python -OO. The only runtime overhead from this module in optimized mode is calling the decorator itself once during the very first code interpretation pass.

Notes

Don't do this:

  @contract_epydoc  @staticmethod  def some_method(...

or

  @contract_epydoc  @classmethod  def some_method(cls, ...

Classmethods and staticmethods are not the proper functions, but the objects of special kind, so the function arguments cannot be checked for them.

Do this instead:

  @staticmethod  @contract_epydoc  def some_method(...

or

  @classmethod  @contract_epydoc  def some_method(cls, ...

Disclaimer

This code is highly experimental yet, hence no releases are yet available.

The code assumed to be working rather well with normal methods and functions; assumed to be non-working (yet, but maybe never) with the static and class methods; and may have (though may not have) difficulties with various nested functions, contract definitions using the variables from various nesting levels, and other complex cases.

Feel free to send me comments and (maybe) patches via amyodov@gmail.com.

Posted via email from kwhitefoot's posterous

Design by Contract for Python

Design by Contract for Python

R. Plösch


The idea of design by contract (DBC), realized in the statically typed object-oriented programming language Eiffel, can be viewed as a systematic approach to specifying and implementing object-oriented software systems. We believe that a statically typed programming language is not suitable in the analysis and design phase of a prototyping-oriented software life cycle. For this purpose, dynamically typed interpreted programming languages are better suited. Unfortunately, dynamically typed programming languages usually do not support the concept of DBC. Therefore we integrated DBC into the programming language Python by using a metapro- gramming approach, i.e., without changing the language or the run-time system. We adopted the DBC concept by adding mechanisms for dynamic type checking for method parameters and instance variables. The proposed combination of a more formal approach with a slim programming language provides a good basis for elicitation and documentation tasks in the analysis and design phase, especially in cases of a prototyping-oriented software development approach. Although the approach presented provides basic tool support for the analysis and design phase, further tool support, especially for browsing assertions, is desirable.

R. Plösch, Design by Contract for Python, IEEE Proceedings of the Joint Asia Pacific Software Engineering Conference (APSEC97/ICSC97), Hongkong, December 2-5, 1997.

  • Get Publication PDF, 68K
  • TR-SE-97.24

    Posted via email from kwhitefoot's posterous

    Index of /publications/pdf

    Yet another Design By Contract module for Python « Python recipes « ActiveState Code

    Followers