> A concrete example would probably help. What are you envisioning?
Let say you have an interface (zope.interface) IMyProduct and two
classes
implementing the interface MyProduct1 and MyProduct2 ...
But I think I found the answer. One file each.
Python is just more flexi
Huron wrote:
> For instance, if you have several classes implementing the same
> interface
> (say, doing the same things with different strategies), how would you
> organize that in terms of files (modules) and directories (packages) ?
A concrete example would probably help. What are you
Huron wrote:
> Hi Peter,
> Thanks for you detailed reply.
> The layout that you suggest sounds wise to me (I'm about to start a
> project).
I wouldn't necessarily recommend something so complex (not that it's
particular complex, but it's more than just "flat") for a newcomer,
however. One of th
Hi again,
For instance, if you have several classes implementing the same
interface
(say, doing the same things with different strategies), how would you
organize that in terms of files (modules) and directories (packages) ?
-- huron
--
http://mail.python.org/mailman/listinfo/python-li
Hi Peter,
Thanks for you detailed reply.
The layout that you suggest sounds wise to me (I'm about to start a
project).
I confess that, coming from the java world, I've trouble to move away
from
the paradigm "one class" = "one file" ... and to gather things inside
"python m
Huron wrote:
> What do you guys recommend in terms of python project layout,
> especially
> unit tests layout ?
> Zope has unit tests per packages, twisted has a big tests directory
> full of
> tests ... and the file naming convention are also pretty differen
Hi,
What do you guys recommend in terms of python project layout, especially
unit tests layout ?
Zope has unit tests per packages, twisted has a big tests directory
full of
tests ... and the file naming convention are also pretty differents ...
I guess there is part of
