Coding style clarifications
Hi, while gathering, cleaning and consolidating the various statements that float around about the coding style for Zope 3, I found a couple of issues that I'd like to get clarification for. What I found is currently gathered at http://svn.zope.org/zope3docs/source/codingstyle/python-style.rst?rev=96729&... Which attribute naming is current? ================================== Do we use under_scores or mixedCaseNames? I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct? Global variable names ===================== I don't understand that rule. I kept it around because someone might be able to explain it more in-depth and whether it still applies. Import ordering =============== Jim proposed an alternative rule for ordering imports. Is this official? (My vote is +1 on it) Cheers, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Previously Christian Theune wrote:
Hi,
while gathering, cleaning and consolidating the various statements that float around about the coding style for Zope 3, I found a couple of issues that I'd like to get clarification for.
What I found is currently gathered at http://svn.zope.org/zope3docs/source/codingstyle/python-style.rst?rev=96729&...
Which attribute naming is current? ==================================
Do we use under_scores or mixedCaseNames?
I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct?
That would make the end result inconsistent. I seem to remember camel case being declared 'the zope standard'. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Feb 19, 2009, at 5:13 AM, Wichert Akkerman wrote:
Previously Christian Theune wrote:
Which attribute naming is current? ==================================
Do we use under_scores or mixedCaseNames?
I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct?
That would make the end result inconsistent. I seem to remember camel case being declared 'the zope standard'.
You probably remember right for some point in time at least. However, see the discussion from last year, started by this message. http://mail.zope.org/pipermail/zope3-dev/2007-August/023394.html and the decision that was apparently adopted is in this document (section titled "Coding style"): http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-softw...
On Thursday 19 February 2009, Zvezdan Petkovic wrote:
and the decision that was apparently adopted is in this document (section titled "Coding style"):
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-soft ware.txt
Except that not all people agreed to that, including me. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Thursday 19 February 2009, Christian Theune wrote:
Which attribute naming is current? ==================================
Do we use under_scores or mixedCaseNames?
I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct?
Depends on the namespace.ZC has decisively decided to go with underscores, so all packages in the zc namespace would be like that. The zope and z3c namespace use camel-case.
Global variable names =====================
I don't understand that rule. I kept it around because someone might be able to explain it more in-depth and whether it still applies.
Well, factories (most often classes) should be capitalized. Sometimes helper-functions act like classes in that they construct a new objects, then this rule suggests that it should also be capitalized. I am not sure I like that, but I can live with it. All other functions should be mixed case.
Import ordering ===============
Jim proposed an alternative rule for ordering imports. Is this official?
(My vote is +1 on it)
We commonly put import * before from * import *. But otherwise I agree with that rule and I started doing it this way as well. I have found the PEP8 recommendation hard to follow in certain cases, since it is subjective. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Which attribute naming is current? ==================================
Do we use under_scores or mixedCaseNames?
I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct?
According to this document in Zope3 developer info (http://wiki.zope.org/zope3/DeveloperInfo ) it is. http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-softw... However, it seems not everybody agrees with that document completely. :-)
Import ordering ===============
Jim proposed an alternative rule for ordering imports. Is this official?
(My vote is +1 on it)
I like PEP-8 rule with alphabetically sorted groups. import some-python-module ... import zope.some-module ... import myapp.some-module ... It's consistent with similar import/include rules for other languages and large projects. For example, type "man style" on a Mac or BSD computer for BSD kernel style guide. Having said the above, I personally don't think any of the points above are so much important. For example, a single group of sorted imports (which is I think what you refer to) will still form sub-groups internally because of sorting (only without empty lines in between). The one interesting difference is that z3c.something or zc.something will sort before zope.something. Since z3c.something almost certainly depends on zope.something that looks a little out of order. Still, I don't think it's worth arguing over that difference. Similarly both method_name() and methodName() look fine to me. One could argue that mixedCase() makes public attributes visually distinct from local variables (as is suggested in http://wiki.zope.org/zope3/ZopePythonNamingConventions) . So, deviating from PEP-8 in that regard doesn't bother me at all. OTOH, there's a simplicity in following the PEP-8 single rule for any variable/attribute. Consistency is good on a coarse grain level, but once we start going into fine grain details -- whether there's a blank line in between sorted import groups or not -- it becomes unproductive. Zvezdan
On Feb 19, 2009, at 4:47 AM, Christian Theune wrote:
Hi,
while gathering, cleaning and consolidating the various statements that float around about the coding style for Zope 3, I found a couple of issues that I'd like to get clarification for.
What I found is currently gathered at http://svn.zope.org/zope3docs/source/codingstyle/python-style.rst?rev=96729&...
Which attribute naming is current? ==================================
Do we use under_scores or mixedCaseNames?
I think I remember that we decided to follow PEP 8 for new code and invoke the "local consistentency" rule on old code. Is that correct?
This is a mess, mainly because PEP 8 changed after an alternative style had been established in the Zope community. This is complicated by the fact that many people who work on Zope projects also work on many non-zope projects. I only mention this so that readers know the history. I don't really care much about this issue. Whatever decision is made is arbitrary.
Global variable names =====================
I don't understand that rule. I kept it around because someone might be able to explain it more in-depth and whether it still applies.
I don't understand it either. I think it mostly follows established Python practices which have been changing recently. I don't care much about this myself.
Import ordering ===============
Jim proposed an alternative rule for ordering imports. Is this official?
(My vote is +1 on it)
PEP 8's rule is silly subjective and generally a waste of time. I'm not going to waste my time following it. I sort my imports. Period. This makes from imports come before regular imports (because f comes before i). I discourage from imports, so this isn't much of an issue for me except for old code. Having imports sorted takes very little effort and makes imports easier to find and duplicated easier to spot. Grouping imports makes imports harder to maintain and read, especially since groupings are arbitrary unless they follow package boundaries, and just sorting imports groups imports by package boundaries. BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread. Jim -- Jim Fulton Zope Corporation
On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton <jim@zope.com> wrote:
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
You're welcome. :-) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton <jim@zope.com> wrote:
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
You're welcome. :-)
You're saying that: import zope.interface.Interface class IFoo(zope.interface.Interface): ... is better than: from zope.interface import Interface class IFoo(Interface): ... ? Shane
On Feb 19, 2009, at 4:07 PM, Shane Hathaway wrote:
Fred Drake wrote:
On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton <jim@zope.com> wrote:
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
You're welcome. :-)
You're saying that:
import zope.interface.Interface
class IFoo(zope.interface.Interface): ...
is better than:
from zope.interface import Interface
class IFoo(Interface): ...
This is an interesting case. This could make a good exception to the rule. Interface is so commonly used, at least within the zope community it really wants to be a builtin, like list or tuple. Most names are not nearly as common. Even with this example, which I consider atypical, I think there are a couple of interesting things to note: 1. While Interface is well known to us, it isn't well known to other possible readers of the code. When working on a project, certain names are very will known to me and don't seem to benefit from qualification, however, when I leave a project and come back to it much later, I appreciate the qualification that makes interpreting the no-longer familiar names much easier. 2. Depending on what code you might unearth, Interface could be either zope.interface.Interface, or the older version Interface.Interface. Package qualification makes this unambiguous. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Feb 19, 2009, at 4:07 PM, Shane Hathaway wrote:
You're saying that:
import zope.interface.Interface
class IFoo(zope.interface.Interface): ...
is better than:
from zope.interface import Interface
class IFoo(Interface): ...
2. Depending on what code you might unearth, Interface could be either zope.interface.Interface, or the older version Interface.Interface. Package qualification makes this unambiguous.
if module qualification is enough and "from" discouraged one could as well write: import zope.interface as interface class IFoo(interface.Interface): ... Joachim
On Feb 20, 2009, at 7:48 AM, Joachim König wrote: ...
2. Depending on what code you might unearth, Interface could be either zope.interface.Interface, or the older version Interface.Interface. Package qualification makes this unambiguous.
if module qualification is enough and "from" discouraged one could as well write:
import zope.interface as interface
class IFoo(interface.Interface):
...
"as" is evil and should never be used except in the most extreme circumstances, if there even are any that extreme. We have recommended: from zope import interface, component and then not having to type "zope.", as you suggest above. I've come to dislike this because: - It doesn't buy that much, and - It's an odd case that has to be recognized. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20.02.2009 15:39 Uhr, Jim Fulton wrote:
On Feb 20, 2009, at 7:48 AM, Joachim König wrote: ...
2. Depending on what code you might unearth, Interface could be either zope.interface.Interface, or the older version Interface.Interface. Package qualification makes this unambiguous.
if module qualification is enough and "from" discouraged one could as well write:
import zope.interface as interface
class IFoo(interface.Interface):
...
"as" is evil and should never be used except in the most extreme circumstances, if there even are any that extreme.
We have recommended:
from zope import interface, component
and then not having to type "zope.", as you suggest above. I've come to dislike this because:
- It doesn't buy that much, and
- It's an odd case that has to be recognized.
I followed the whole thread with some amusement. There are too many personal coding styles on the market which makes it impossible to regulate all all and everything. At least this discussion about about how to write imports properly appears esoteric to me. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmew3YACgkQCJIWIbr9KYyjlgCdGFtjHDTCSywVjGjCIyhGnnGI lGcAoM4V7EkwFBztQyM5TKF0zTAJDhBs =zZIL -----END PGP SIGNATURE-----
Hey, Andreas Jung wrote:
I followed the whole thread with some amusement. There are too many personal coding styles on the market which makes it impossible to regulate all all and everything. At least this discussion about about how to write imports properly appears esoteric to me.
Yeah, I agree, this is a fairly useless religious discussion. I think we should just let packages have the structure their original creators intended to have them. For new packages people should pick their preference. It's pretty hopeless to start changing it now anyway, as each package has its own structure. The only point where this really affects me is in package APIs, as I really like providing a brief API in a package's __init__.py, and certain import patterns will in various subtle ways create circular imports when I do this. Regards, Martijn
Hey, Joachim König wrote:
import zope.interface as interface
Surprisingly enough this actually has a subtly different behavior than: from zope import interface the former can create circular import situations where the latter doesn't. Regards, Martijn
On Feb 19, 2009, at 11:03 AM, Jim Fulton wrote:
I sort my imports. Period. This makes from imports come before regular imports (because f comes before i). I discourage from imports, so this isn't much of an issue for me except for old code. Having imports sorted takes very little effort and makes imports easier to find and duplicated easier to spot. Grouping imports makes imports harder to maintain and read, especially since groupings are arbitrary unless they follow package boundaries, and just sorting imports groups imports by package boundaries.
Exactly . As I mentioned in the previous post, sorting is the *key* here. [Pun intended]. Grouping (python, zope., myapp. modules order), or non-grouping, becomes a non-issue when imports are sorted. +1
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
Very important for code maintenance/readability! +1 Zvezdan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zvezdan Petkovic wrote:
On Feb 19, 2009, at 11:03 AM, Jim Fulton wrote:
I sort my imports. Period. This makes from imports come before regular imports (because f comes before i). I discourage from imports, so this isn't much of an issue for me except for old code. Having imports sorted takes very little effort and makes imports easier to find and duplicated easier to spot. Grouping imports makes imports harder to maintain and read, especially since groupings are arbitrary unless they follow package boundaries, and just sorting imports groups imports by package boundaries.
Exactly . As I mentioned in the previous post, sorting is the *key* here. [Pun intended]. Grouping (python, zope., myapp. modules order), or non-grouping, becomes a non-issue when imports are sorted.
+1
- -1. I prefer the PEP8 grouping, where "stdlib" imports are separated from "dependecy" imports, which are separated from "local" imports. Note that this is *not* subjective (an import is unambiguously in exaclty one of those three classifications.)
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
Very important for code maintenance/readability! +1
- -1, especially in heavily-namespaced libraries: I vastly prefer from imports to the noise of repeating the module path everywhere. A one chearacter search ('*' or '#') normally finds the import for me, which makes the repetition useless. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnZpA+gerLs4ltQ4RAp3lAKDOVsZjLoWT9LmHxeY/KpXRmk+x5gCfdUmX kx9JhthFuPgaEXokLVLo+r4= =Vi9G -----END PGP SIGNATURE-----
On Feb 19, 2009, at 12:43 PM, Tres Seaver wrote:
Exactly . As I mentioned in the previous post, sorting is the *key* here. [Pun intended]. Grouping (python, zope., myapp. modules order), or non-grouping, becomes a non-issue when imports are sorted.
+1
- -1. I prefer the PEP8 grouping, where "stdlib" imports are separated from "dependecy" imports, which are separated from "local" imports. Note that this is *not* subjective (an import is unambiguously in exaclty one of those three classifications.)
If you read my previous post, you'll see that I also prefer PEP-8 style. http://mail.zope.org/pipermail/zope-dev/2009-February/034629.html What I argued and gave +1 for is that *sorting* is the most important requirement. I explained the details in the previous post.
- -1, especially in heavily-namespaced libraries: I vastly prefer from imports to the noise of repeating the module path everywhere. A one chearacter search ('*' or '#') normally finds the import for me, which makes the repetition useless.
By the character mentioned it seems you use Vim. Arguably, one can use another key press in Vim for name completion during typing. :-) Seeing where the name comes from during the code review (or when reading a diff), without having to press that key is important to some people. Personally, I am used to finding such things in an editor using tags, because, for example, in C programming, one cannot use namespace qualifiers anyway and the names can come from any other file in a large project. Such topics are obviously too subjective and sometimes defended too passionately. I _tried_ to argue in my original post linked above that such discussions are not productive. I can adapt to any style and believe that the fine grain details should not be dogmatically enforced but rather allow for variations in such subjective preferences. Best regards, Zvezdan
Zvezdan Petkovic wrote at 2009-2-19 13:06 -0500:
I can adapt to any style and believe that the fine grain details should not be dogmatically enforced but rather allow for variations in such subjective preferences.
+1 -- Dieter
Dieter Maurer wrote:
Zvezdan Petkovic wrote at 2009-2-19 13:06 -0500:
I can adapt to any style and believe that the fine grain details should not be dogmatically enforced but rather allow for variations in such subjective preferences.
+1
+ sys.maxint Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Feb 19, 2009, at 12:43 PM, Tres Seaver wrote:
- -1. I prefer the PEP8 grouping, where "stdlib" imports are separated from "dependecy" imports, which are separated from "local" imports. Note that this is *not* subjective (an import is unambiguously in exaclty one of those three classifications.)
I find it very subjective, or, at best, orthogonal to anything I care about. If I'm working in a ZEO package, is an import from ZODB local? How about transaction? If I import asyncore or cPickle, is that coming from the standard library? It is today, but it wasn't in the past, when the code I'm reading may have been written. The grouping in PEP 8 is based on packaging decisions that are irrelevant to the meaning of the software. Jim -- Jim Fulton Zope Corporation
I'm with Tres on both issues: +1 for PEP-8 import grouping (sorted alphabetically within each group), -1 for repeating english.adjective.fully english.adverb.qualified english.noun.package english.noun.names all over the place in the code (this also ties with my preference of trying to keep all my names unique project-wide, for easier ctags searches). Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Feb 19, 2009, at 2:07 PM, Marius Gedminas wrote: ...
-1 for repeating english.adjective.fully english.adverb.qualified english.noun.package english.noun.names all over the place in the code
If you have package hierarchies remotely that deep, you have bigger problems. If dotted names are long enough to be a significant bother, packages are too deeply nested. Too deeply nested packages was a mistake we made in Zope 3 early on. I prefer to have no-more than two levels of packages, a namespace package and a project package within the namespace packages. (I can live with 3 levels in some cases.) Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Feb 19, 2009, at 2:07 PM, Marius Gedminas wrote: ...
-1 for repeating english.adjective.fully english.adverb.qualified english.noun.package english.noun.names all over the place in the code
If you have package hierarchies remotely that deep, you have bigger problems.
Dotted name imports within a package's modules like that break the ability for people to create package specific namespaces in __init__.py due to subtle circular dependency issues. from imports tend to avoid this as the namespace package isn't actually needed yet for dotted access at a critical point. Regards, Martijn
On Feb 20, 2009, at 10:22 AM, Martijn Faassen wrote:
Jim Fulton wrote:
On Feb 19, 2009, at 2:07 PM, Marius Gedminas wrote: ...
-1 for repeating english.adjective.fully english.adverb.qualified english.noun.package english.noun.names all over the place in the code
If you have package hierarchies remotely that deep, you have bigger problems.
Dotted name imports within a package's modules like that break the ability for people to create package specific namespaces in __init__.py due to subtle circular dependency issues. from imports tend to avoid this as the namespace package isn't actually needed yet for dotted access at a critical point.
Names exported to a containing package cause circular import problems whether or not from imports are used. I've seen from imports make this worse. I believe you've seen cases where they make it better. I think the only way to avoid this is to use a deferred import mechanism such as zope.deferredimport. (This is one of the few batteries I actually wish Python included.) Jim -- Jim Fulton Zope Corporation
Hi there,
Names exported to a containing package cause circular import problems whether or not from imports are used. I've seen from imports make this worse. I believe you've seen cases where they make it better. I think the only way to avoid this is to use a deferred import mechanism such as zope.deferredimport. (This is one of the few batteries I actually wish Python included.)
A bunch of us spent quite a bit of time diving into this issue at the sprint a few weeks ago here. It's quite mystifying but enough to reach some conclusions. in foo.baz.py: import foo.bar will trigger for some reason a more complete import of 'foo' so that the attribute 'bar' can be accessed. foo's __init_.py cannot do this then: from foo.bar input whatever If instead baz.py contains: from foo import bar The problem will not arise. If instead you do: import foo.bar as bar which you'd think was the semantic equivalent, it *will*. The main take-home message was that the import mechanics of Python are rather surprising in operation here and it's very hard to reason about it. It has something to do with 'foo'" having to be more initialized during importing than in the other case. I do know that the pattern of 'from' imports in a package's module will allow me to write a __init__.py assembling a namespace from sub-modules, while the pattern of "import foo.bar" in a package's module will give circular import related errors. "foo" in the latter case will have to be a more complete object. Regards, Martijn
On Feb 20, 2009, at 11:00 AM, Martijn Faassen wrote: ...
The main take-home message was that the import mechanics of Python are rather surprising in operation here and it's very hard to reason about it. It has something to do with 'foo'" having to be more initialized during importing than in the other case. I do know that the pattern of 'from' imports in a package's module will allow me to write a __init__.py assembling a namespace from sub-modules, while the pattern of "import foo.bar" in a package's module will give circular import related errors. "foo" in the latter case will have to be a more complete object.
You will still likely have other problems unless you use deferred imports which will generally solve this problem in a robust way. Jim -- Jim Fulton Zope Corporation
Hey, On Fri, Feb 20, 2009 at 5:05 PM, Jim Fulton <jim@zope.com> wrote: [snip]
You will still likely have other problems unless you use deferred imports which will generally solve this problem in a robust way.
I've created quite a few packages that have this structure without any problems in my experience. That's not to say there aren't any, it's just I haven't had people or myself run into them (or recognize them? :). That said, a more robust solution in Python that would allow both patterns to be mixed would be nice. Regards, Martijn
Jim Fulton wrote:
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
I like from imports as they allow me to provide a public API in the __init__.py of a package (instead of scattering it all over the place in sub-modules of the package nobody should need to know about). Absolute imports tend to break this ability in subtle ways. I suspect there are two possibilities: * no API defined in __init__.py and absolute imports * API defined in __init__.py and dotted.package.name.references don't work. This looks like a religious debate though. Regards, Martijn
On Feb 20, 2009, at 10:15 AM, Martijn Faassen wrote:
Jim Fulton wrote:
BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread.
I like from imports as they allow me to provide a public API in the __init__.py of a package (instead of scattering it all over the place in sub-modules of the package nobody should need to know about). Absolute imports tend to break this ability in subtle ways.
I suspect there are two possibilities:
* no API defined in __init__.py and absolute imports
* API defined in __init__.py and dotted.package.name.references don't work.
In what way don't they work? I don't see how this has anything to do with from imports. Putting an API in the package __init__ just makes object paths shorter. I don't see how the location of an API has much bearing on whether to use from imports or not.
This looks like a religious debate though.
Maybe. The most important reason for a style guide is to make code more readable. In my experience, from imports make code significantly harder to read, so this is fairly important to me. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Feb 20, 2009, at 10:15 AM, Martijn Faassen wrote:
<snip>
This looks like a religious debate though.
Maybe. The most important reason for a style guide is to make code more readable. In my experience, from imports make code significantly harder to read, so this is fairly important to me.
That is why this is religious: I find "from imports" make code *more* readable: the dotted prefixes are "noise" rather than "signal" to my eyes. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnt2h+gerLs4ltQ4RApr3AKC5kCcuuYreIs26bpFmYabDrLCB/wCeNrMO 8cnCGY9Yuz0yftquNI60rHA= =Mdqk -----END PGP SIGNATURE-----
Tres Seaver wrote:
That is why this is religious: I find "from imports" make code *more* readable: the dotted prefixes are "noise" rather than "signal" to my eyes.
+1 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi there, Jim Fulton wrote: [snip]
I suspect there are two possibilities:
* no API defined in __init__.py and absolute imports
* API defined in __init__.py and dotted.package.name.references don't work.
In what way don't they work?
I don't see how this has anything to do with from imports. Putting an API in the package __init__ just makes object paths shorter. I don't see how the location of an API has much bearing on whether to use from imports or not.
You generate circular imports if a package that does this has modules that contain absolute dotted imports from the same package, as I described elsewhere. If you use from imports in the modules in the package it does work. For imports of stuff that is external to the package it usually shouldn't matter (unless I guess there's a circular dependency between packages). What causes this exactly caused us quite a bit of headscratching back at the sprint, and a lot of theorizing, but if anything satisfactory came out of that it's slipped my mind again. The interactions are quite subtle and changing an import from one form to the other (and having imports in __init__.py at all) can break it. We discovered this when Christian Theune said he wanted his package __init__.py empty as otherwise he runs into circular import issues. Some of the others including myself were puzzled as we put APIs in __init__.py quite frequently without such problems. Turned out it was because he is using the same convention for imports you do, and we weren't. Regards, Martijn
On Fri, 2009-02-20 at 18:18 +0100, Martijn Faassen wrote:
We discovered this when Christian Theune said he wanted his package __init__.py empty as otherwise he runs into circular import issues. Some of the others including myself were puzzled as we put APIs in __init__.py quite frequently without such problems. Turned out it was because he is using the same convention for imports you do, and we weren't.
The conclusion that I took from that round was that either approach works reasonably well (with its own limitations) by itself, but mixing them increases the chance for import problems a lot. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote:
On Fri, 2009-02-20 at 18:18 +0100, Martijn Faassen wrote:
We discovered this when Christian Theune said he wanted his package __init__.py empty as otherwise he runs into circular import issues. Some of the others including myself were puzzled as we put APIs in __init__.py quite frequently without such problems. Turned out it was because he is using the same convention for imports you do, and we weren't.
The conclusion that I took from that round was that either approach works reasonably well (with its own limitations) by itself, but mixing them increases the chance for import problems a lot.
Yes. The from import method supports putting an API in __init__.py while the other method does not (unless, I imagine, deferred import is used). The import dotted.name method allows, well, itself. Seems people just gravitated to each pole according to their preferences, and find out the other approach causes problems. :) Regards, Martijn
Hey Christian, You do realize you started a bikeshed discussion right? Suddenly people wake up and spout opinions because everybody has an opinion about this. :) Regards, Martijn
participants (14)
-
Andreas Jung -
Chris Withers -
Christian Theune -
Dieter Maurer -
Fred Drake -
Jim Fulton -
Joachim König -
Marius Gedminas -
Martijn Faassen -
Shane Hathaway -
Stephan Richter -
Tres Seaver -
Wichert Akkerman -
Zvezdan Petkovic