Re: [Zope-dev] an Interface expressing "a list of generator function"

2010-11-09 Thread Jean-Daniel
The end of the last message was not finished...


Ideally, here is (maybe) what I wish I could write:

>
"""
from zope.interface import IList, IGenerator, implements, requires
def make_generator_functions():
implements(IList(IGenerator))
[...]

def stack_assumption(gen_funcs):
requires(IList(IGenerator), gen_funcs)
[ ... ]
"""

Regards,
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] an Interface expressing "a list of generator function"

2010-11-09 Thread Jean-Daniel
>
> What exactly are you hoping to accomplish?
>

In brief, I wish there were a concise and clear way to express that an
object implements a "list of generator functions", in the context of CS
students learning the concept of interface.

I am writing an article on a sudoku solver for an audience of CS
students, They do not know much of Python, have recently heard about
recursivity and the yield keyword was not obvious for them. The goal is that
they meet a nice collaboration between three objects, in Python, to
manipulate the concepts of code reuse and interface.

There is 1. a Sudoku class modelling a sudoku board and rules,
2. a backtracking algorithm,
3. and a function which returns the data structure (a list of generator
functions) used by the backtracking algorithm, and which uses an instance of
the Sudoku class,

(The solver code can be read at
jdb.github.com/modules/sudoku.html,
a draft of the article is at : jdb.github.com/sudoku.html, the nice
backtracking algorithm comes from the conjoin algorithm described in
test_generators.py in the Python sources)

As the naive implementation the students would write is one big fat
function, I have to convince them that going through a more sophisticated
design is a better path. The idea is to exemplify code reuse by swapping the
Sudoku class with an optimized equivalent class, for instance. Also the same
backtracking algorithm can "cook" a solution to the eight queens problems or
the knight's tour problem, without modification but given the adapted list
of generator functions.

The interfaces help designing formalizing the collaboration between objects
and the article wishes to convey this idea. The Sudoku interface is nice and
clean but explaining the interface for a "list of generator functions" is
likely to raise more questions from the student than it brings clarity.
The interface will require the students to know that "list" and its bracket
notation implies the __getitem__ function, and that generator implies
__iter__ and next(). Roughly a dozen elegant lines are needed to implement
the interface with the Python keywords and syntax but the expected
__getitem__, __iter__ and next() will be absent from the implementation
which uses "[]" and "yield".

I understand that the interfaces presented by Tres Seaver will work well for
the purpose of code reuse in a real application, and it is the way to go if
I want to use a global registry and/or a validation of the interface
provided by a class. At this point, I think it is easier to explain the
interface in plain english in the documentation with the help of the sphinx
documentation directives extracting the public methods of the class.

Here is (maybe) what I wish I could write:

"""
from zope.interface import IList, IGenerator, Interface, provides, validates

def make_generator_functions():
[...]

make_generator_functions = , make_generator_functions)

def stack_assumption(gen_funcs):
validates(IList(IGenerator), gen_funcs)

[ ... ]
"""

Thanks for your attention,



> Jim
>
> --
> Jim Fulton
>
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] an Interface expressing "a list of generator function"

2010-11-09 Thread Jim Fulton
On Tue, Nov 9, 2010 at 2:58 AM, Jean-Daniel  wrote:
> Ok,
> If I attach an item_type to the the list, I do not think I will able to use
> the native Python list, and should use a subclass instead. It is a bit
> heavyweight, especially when the intent of the use of the interface was
> documentation.

Tres could have avoided the generalization and just said something like:

class IGeneratorList(Interface):
"A sequence of generators."

def __getitem__(index):
""" Return the 'index'th item.

'index' must be an integer between 0 and __len__() - 1,
else raise IndexError.
"""

blah blah...

Note that zope interfaces are only *semi*-formal.

> List and generators are very common in Python and are expressed in very few
> and clear characters,

Huh? What does this mean?

> I thought there would be a shorter  way to document
> their interfaces.

What exactly are you hoping to accomplish?

Jim

--
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] an Interface expressing "a list of generator function"

2010-11-08 Thread Jean-Daniel
Ok,

If I attach an item_type to the the list, I do not think I will able to use
the native Python list, and should use a subclass instead. It is a bit
heavyweight, especially when the intent of the use of the interface was
documentation.

List and generators are very common in Python and are expressed in very few
and clear characters, I thought there would be a shorter  way to document
their interfaces.

Thank you,


On Mon, Nov 8, 2010 at 2:24 PM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/08/2010 04:40 AM, Jean-Daniel wrote:
> > Hello,
> >
> > I have two objects which interoperate to solve a sudoku: the Sudoku class
> > and a vector (a list actually) of generator functions. The Sudoku
> interface
> > is simple to write as it requires three functions and an attribute.
> >
> > class ISudoku:
> >
> > board = Attribute()
> >
> > def free(col, line):
> > "frees the slot at position col, line"
> >
> > def set(col, line, value):
> > "Sets the value in the slot at position col, line"
> >
> > def candidates(col, line):
> > "Returns the candidate digits for the slot at position col,line"
> >
> >
> > But how to express "vector of generator functions" with Zope interfaces?
> I
> > want to express the possibility to access the vector object with
> > the  [n] index notation, and this returns a function returning a
> generator
> > (an object with an iter and next function).
> >
> > Thank you for your help,
> >
> >
> > PS: the vector of generator functions is the input of the algorithm
> called
> > "conjoin", used to solve the eight queen problem and knight's tour
> problem.
> > It is described in the Python sources
> > (Python-2.6.5/Lib/test/test_generators.py).
> >
> > PPS: I say vector instead of list even when the vector is a list, because
> > "list" usually  implies the possibility to append elements dynamically
> which
> > is not pertinent in this problem. The length of the vector won't change
> and
> > is equal to the number of slots on a sudoku board.
>
>
> I would specify the contracts omething like so::
>
>
> class IVector(Interface):
>
>item_type = Attribute(u"Interface of items.")
>
>def __len__():
>""" Fixed length of vector.
>"""
>
>def __getitem__(index):
>""" Return the 'index'th item.
>
>Items conform to 'item_type'.
>
>'index' must be an integer between 0 and __len__() - 1,
>else raise IndexError.
>"""
>
> class IIterable(Interface):
>
>def __iter__():
>""" Return an iterator for this object.
>"""
>
>
>
>
> - --
> ===
> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
> Palladion Software   "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzX+ggACgkQ+gerLs4ltQ7WQwCeNu4lF+WysIjSYM86EjMhoPFH
> 9ZsAnRB7T4Pz+bIVeVYxHbvRYaqN6iE7
> =U5bo
> -END PGP SIGNATURE-
>
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] an Interface expressing "a list of generator function"

2010-11-08 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/08/2010 04:40 AM, Jean-Daniel wrote:
> Hello,
> 
> I have two objects which interoperate to solve a sudoku: the Sudoku class
> and a vector (a list actually) of generator functions. The Sudoku interface
> is simple to write as it requires three functions and an attribute.
> 
> class ISudoku:
> 
> board = Attribute()
> 
> def free(col, line):
> "frees the slot at position col, line"
> 
> def set(col, line, value):
> "Sets the value in the slot at position col, line"
> 
> def candidates(col, line):
> "Returns the candidate digits for the slot at position col,line"
> 
> 
> But how to express "vector of generator functions" with Zope interfaces? I
> want to express the possibility to access the vector object with
> the  [n] index notation, and this returns a function returning a generator
> (an object with an iter and next function).
> 
> Thank you for your help,
> 
> 
> PS: the vector of generator functions is the input of the algorithm called
> "conjoin", used to solve the eight queen problem and knight's tour problem.
> It is described in the Python sources
> (Python-2.6.5/Lib/test/test_generators.py).
> 
> PPS: I say vector instead of list even when the vector is a list, because
> "list" usually  implies the possibility to append elements dynamically which
> is not pertinent in this problem. The length of the vector won't change and
> is equal to the number of slots on a sudoku board.


I would specify the contracts omething like so::


class IVector(Interface):

item_type = Attribute(u"Interface of items.")

def __len__():
""" Fixed length of vector.
"""

def __getitem__(index):
""" Return the 'index'th item.

Items conform to 'item_type'.

'index' must be an integer between 0 and __len__() - 1,
else raise IndexError.
"""

class IIterable(Interface):

def __iter__():
""" Return an iterator for this object.
"""




- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzX+ggACgkQ+gerLs4ltQ7WQwCeNu4lF+WysIjSYM86EjMhoPFH
9ZsAnRB7T4Pz+bIVeVYxHbvRYaqN6iE7
=U5bo
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )