Jim Fulton wrote:
Dieter Maurer wrote:
Jim Fulton wrote at 2005-11-21 09:43 -0500:
Absolute always. Until the Python import mechanism is fixed,
*always* use absolute imports.
But, this will make refactoring (moving modules around in the
package hierarchy) more difficult.
It only makes mo
Dieter Maurer wrote:
Jim Fulton wrote at 2005-11-21 09:43 -0500:
...
A Python convention is that a leading underscore indicates privateness.
- what about import paths inside a same package: relative or absolute?
from mypackage.interfaces import ISomeInterface
or:
from interfaces import
Jim Fulton wrote at 2005-11-21 09:43 -0500:
> ...
>A Python convention is that a leading underscore indicates privateness.
>
>> - what about import paths inside a same package: relative or absolute?
>>
>>from mypackage.interfaces import ISomeInterface
>> or:
>>from interfaces import ISomeI
Gary Poster wrote:
On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote:
There is another place where there seems to be two different patterns
too:
sometimes we have:
import zope.schema
name = zope.schema.TextLine(...)
and sometimes:
from zope.schema import TextLine
name = T
Martijn Faassen wrote:
I don't think using any of these patterns is a big style problem (I'm
much less opinionated about this than about code in __init__.py); it's
hard to recommend a single practice, so perhaps we shouldn't.
+1
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
Gary Poster wrote:
On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote:
There is another place where there seems to be two different patterns
too:
sometimes we have:
import zope.schema
name = zope.schema.TextLine(...)
and sometimes:
from zope.schema import TextLine
name = T
On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote:
There is another place where there seems to be two different
patterns too:
sometimes we have:
import zope.schema
name = zope.schema.TextLine(...)
and sometimes:
from zope.schema import TextLine
name = TextLine(...)
FWIW,
There is another place where there seems to be two different patterns too:
sometimes we have:
import zope.schema
name = zope.schema.TextLine(...)
and sometimes:
from zope.schema import TextLine
name = TextLine(...)
any reason to use one or the other (speed, verbosity, avoiding circul
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
yes indeed, but no "cross" imports between packages that are siblings.
Huh? Why? I'm not at all sure I know what you mean.
the question is what relation between the importer and the imported are
OK: if I add such imports in __init__.py, I
Jim Fulton wrote:
yes indeed, but no "cross" imports between packages that are siblings.
Huh? Why? I'm not at all sure I know what you mean.
the question is what relation between the importer and the imported are
OK: if I add such imports in __init__.py, I should only import from
pack
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the same
package or in a subpackage?
I'm typically okay with this, though I suspect it can in some cases lead
to circular imports you m
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the
same package or in a subpackage?
Actually, primarily for convenient import by exte
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the
same package or in a subpackage?
Actually, primarily for convenient import by external packages.
yes indeed,
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the same
package or in a subpackage?
Actually, primarily for convenient import by external packages.
- public interfaces are stored in
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
One ore two years ago garett raised a similar issue too. IMO (Excuse me,
I could not find the mail) then we decided to import the interfaces.py
within __init__.py: from interfaces import *
Regards,
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the same
package or in a subpackage?
- public interfaces are stored in interfaces.py
- private interfaces are written along with the implementation code
- what abo
Martijn Faassen wrote:
Hi there,
Hi Martijn,
Jean-Marc Orliaguet wrote:
some packages have an interfaces.py file others have a "interfaces"
folder, others have the interface definitions in the implementation
code itself ...
The pattern changed over time during Zope 3 development. In my
Janko Hauser wrote:
Am 21.11.2005 um 12:15 schrieb Martijn Faassen:
My recommendations for any guidelines would be:
* use namespace packages, so nothing (or very minimal stuff only,
like a few imports) in __init__.py. I think this is recommended
practice outside of Zope 3 as well, so we s
Martijn Faassen wrote:
Hi there,
Jean-Marc Orliaguet wrote:
> are there any guidelines / best practises for setting the contents of
__init__.py, interfaces.py, and the packages that they import or that
they expose? there are too many alternatives and too many ways of
ending up doing circular
Am 21.11.2005 um 12:15 schrieb Martijn Faassen:
My recommendations for any guidelines would be:
* use namespace packages, so nothing (or very minimal stuff only,
like a few imports) in __init__.py. I think this is recommended
practice outside of Zope 3 as well, so we should stick with this
Hi there,
Jean-Marc Orliaguet wrote:
> are there any guidelines / best practises for setting the contents of
__init__.py, interfaces.py, and the packages that they import or that
they expose? there are too many alternatives and too many ways of ending
up doing circular imports and I'd like to
Hi!
are there any guidelines / best practises for setting the contents of
__init__.py, interfaces.py, and the packages that they import or that
they expose? there are too many alternatives and too many ways of ending
up doing circular imports and I'd like to have a consistent pattern for
red
22 matches
Mail list logo
