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 - Co
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
_
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
___
Zope-Dev mai
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
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 frequentl
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 d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On Feb 20, 2009, at 10:15 AM, Martijn Faassen wrote:
>> 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
Hey,
On Fri, Feb 20, 2009 at 5:05 PM, Jim Fulton 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.
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
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 su
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,
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
>>
>> I
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
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailm
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
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
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
___
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 imp
-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.Interf
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
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(Int
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 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
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
Fred Drake wrote:
> On Thu, Feb 19, 2009 at 11:03 AM, 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 o
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
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 clas
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 PEP
-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 fo
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 a
On Thu, Feb 19, 2009 at 11:03 AM, 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 t
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
> 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
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, includi
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.
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 t
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.o
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?re
36 matches
Mail list logo
