>> * Python core modules/packages
>>
>> * Third-party modules/packages
>>
>> * Local modules/packages
>
> This is already in PEP 8:
[...]
>1. standard library imports
>2. related major package imports (i.e. all email package
> imports
> next)
>3. application sp
On 12/12/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > This is subjective enough that I would think some rationale explaining this
> > convention should be given. Personally, I group imports into three sections
> > as follows:
> >
> > * Python core modules/packages
On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Martin> It's difficult to establish precise numbers, but I would expect
> Martin> that most readers of xml-sig are well aware of how DOM and SAX
> Martin> work, perhaps even better than ElementTree.
>
> Perhaps the corollary
[EMAIL PROTECTED] wrote:
> This is subjective enough that I would think some rationale explaining this
> convention should be given. Personally, I group imports into three sections
> as follows:
>
> * Python core modules/packages
>
> * Third-party modules/packages
>
> * Local module
Martin> It's difficult to establish precise numbers, but I would expect
Martin> that most readers of xml-sig are well aware of how DOM and SAX
Martin> work, perhaps even better than ElementTree.
Perhaps the corollary is that people who are not xml-sig readers will likely
be put off by
On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> I looked at that too, but most of these didn't jump out at me. I'll
> >> copy in the parts that aren't already in PEP 8 that seem possible:
> >>
> >> From-imports should follow non-from imports. Dotted imports should
Jim> I don't understand this argument. Any mutating method or property
Jim> invoked by foreign code changes an object's state.
Sure, but the only place I need to look for direct changes to the object's
state are in the object's own code.
Jim> If you provide a property or a pair if
>> I looked at that too, but most of these didn't jump out at me. I'll
>> copy in the parts that aren't already in PEP 8 that seem possible:
>>
>> From-imports should follow non-from imports. Dotted imports should
>> follow non-dotted imports. Non-dotted imports should be
Below is Guido's response to my question: Can we start getting rid of
__builtins__ (or __builtin__) at least for py3k?
Having both builtin versions is confusing, how can we improve the situation?
n
-- Forwarded message --
From: Guido van Rossum <[EMAIL PROTECTED]>
Couple of loo
At 06:19 PM 12/12/2005 -0700, Mike Brown wrote:
>Some authors of other libs may not even be aware that they could so
>easily have their code whisked into stdlib, if it's solid enough.
But here the definition of "solid enough" includes such credits as being
written by the primary author of CPython
"Martin v. L> So as that has more-or-less failed, the next natural approach is
> "let's believe in the community". For that, two things need to
> happen: the author of the package must indicate that he would like
> to see it incorporated, and the users must indicate that they like
> the package. Bo
> The single nomination actually triggered a (admittedly
> fast) process, where multiple people spoke in favour, not just a
single
> one. It also followed a discussion on python-list.
Also, there were silent +1 votes from people like me who followed all
the posts and saw no need to alter the direc
Martin v. Löwis wrote:
> Steven Bethard wrote:
> > I didn't really feel like the proposal was out of the blue. The
> > proposal has been brought up before, both on python-dev[1] and the
> > python-list[2]. ElementTree has a pretty large following - if you
> > look at XML-based questions on the py
Mike Brown wrote:
> Catching up on some python-dev email, I was surprised to see that things seem
> to be barrelling ahead with the adding of ElementTree to Python core without
> any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of
> PyXML in order to satsify the demand for
Steven Bethard wrote:
> I didn't really feel like the proposal was out of the blue. The
> proposal has been brought up before, both on python-dev[1] and the
> python-list[2]. ElementTree has a pretty large following - if you
> look at XML-based questions on the python-list, I can almost guarantee
Mike Brown wrote:
> Catching up on some python-dev email, I was surprised to see that things seem
> to be barrelling ahead with the adding of ElementTree to Python core without
> any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of
> PyXML in order to satsify the demand for a
On 12/12/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > but that's not the same at all. The point of __private is that it uses
> > the *static* scope of the code that contains the reference, not the
> > (dynamic) type of the object being ref
I'm not so surprised that Fredrik chose to bypass XML-SIG. There
doesn't seem to be a lot of decision power there -- in fact it feels a
bit dead, with a weird mix of too-high-level discussions that don't go
anywhere, plus basic beginner's Q+A.
Also, it would seem that /F's ElementTree doesn't need
Fredrik Lundh wrote:
> just one question: where do you want the "vendor" checkins ?
external is fine with me.
I think I would have preferred a "real" vendor branch (i.e.
where you do svn merge to integrate the changes, and where
the subsequent external releases all show up in the same
directory,
Brett Cannon wrote:
> What do other people think of this option? Sounds reasonable to me.
> if people like it I will add this to the suggested config options
> specified in the dev FAQ.
There is a problem with that option, an no good solution. If you
had built the tree before the update, the obj
On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> but that's not the same at all. The point of __private is that it uses
> the *static* scope of the code that contains the reference, not the
> (dynamic) type of the object being referenced. With your approach, if
> class A defined __private
Neal Norwitz wrote:
> I recently asked Guido about name mangling wrt Py3k. He definitely
> wanted to keep it in. Unless he changed his mind, I doubt he would
> deprecate it. His rationale was that there needs to be a way to
> handle name collision with multiple inheritance.
Then maybe it shoul
Catching up on some python-dev email, I was surprised to see that things seem
to be barrelling ahead with the adding of ElementTree to Python core without
any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of
PyXML in order to satsify the demand for a Pythonic databinding+AP
On Mon, 2005-12-12 at 14:22 -0500, Jeremy Hylton wrote:
> The C files are checked into subversion. Perhaps there is some
> problem with the timestamps that causes the Makefile to try to rebuild
> them anyway? I have a modern Python and I've been doing a fair amount
> of development on these files
Alex Martelli wrote:
> On 12/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>...
>
>>I'd rather see 'metaclass' fully spelled out than resort to 'mcl';
>>metaclass code is tricky enough to write without figuring out
>>abbreviations. :)
>>
>>Indeed, the only reason I use 'cls' is because it
On 12/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
...
> I'd rather see 'metaclass' fully spelled out than resort to 'mcl';
> metaclass code is tricky enough to write without figuring out
> abbreviations. :)
>
> Indeed, the only reason I use 'cls' is because it was Pronounced the
> standard
At 02:59 PM 12/12/2005 -0800, Alex Martelli wrote:
>On 12/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
> > >That looks good to me. Well, I actually try not to use cls as the first
> > >argument to metaclass's __new__ method, because there's
On 12/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
> >That looks good to me. Well, I actually try not to use cls as the first
> >argument to metaclass's __new__ method, because there's so many classes
> >being tossed about at that point that I
Barry Warsaw wrote:
> Which reminds me. I think it may make sense to offer svn.python.org to
> other contrib projects that may or are included in the stdlib.
Sure. Committers should understand what part of the tree they
are supposed to write to.
Regards,
Martin
__
On 12/12/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-12-12 at 20:43 +0100, Fredrik Lundh wrote:
> > Jeremy Hylton wrote:
> >
> > > The C files are checked into subversion. Perhaps there is some
> > > problem with the timestamps that causes the Makefile to try to rebuild
> > > them
Hi Fredrik,
On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote:
> $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
> -$(PYTHON) $(ASDLGEN) $(AST_ASDL)
I suppose that the trick is in the "-" sign here. If this command fails
for any reason you get warnings and errors but the buil
[EMAIL PROTECTED] wrote:
> BTW, there is one project I'm theoretically familiar with that attempts to
> handle the dual source situation: XEmacs. I'm still trying to come to terms
> with the practical issues involved. I'm supposed to be updating the
> python-mode code, and am only taking baby st
On Mon, 2005-12-12 at 20:43 +0100, Fredrik Lundh wrote:
> Jeremy Hylton wrote:
>
> > The C files are checked into subversion. Perhaps there is some
> > problem with the timestamps that causes the Makefile to try to rebuild
> > them anyway? I have a modern Python and I've been doing a fair amount
On 12/12/05, Aahz <[EMAIL PROTECTED]> wrote:
> Please submit a doc patch to SF (or even just a bug report if you don't
> have time). The patch may be plain text or reST; no need for Latex.
Done - patch number 1379023.
Noam
___
Python-Dev mailing list
P
On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > class Document(_cdm.Document):
> > ...
> > # add convenience methods here
> > ...
>
> Personally, I find that naming convention a mistake. Call it
> MyDocument or Enhanc
Brett Cannon wrote:
> > maybe the right thing here would be to change this to
> >
> > #!./python
> > """Generate C code from an ASDL description."""
> >
> > and only run the script if ./python has been built ?
>
> What if you build with a different suffix for the executable? Or do
> diffe
At 10:03 PM 12/12/2005 +0100, Fredrik Lundh wrote:
>the xml/__init__.py file contains a cute little hack that overrides
>the *entire* xml subtree with stuff from PyXML, if available.
>
>the code basically does
>
> import _xmlplus
> sys.modules[__name__] = _xmlplus
>
>(exception handling and
On 12/12/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
>
> > The C files are checked into subversion. Perhaps there is some
> > problem with the timestamps that causes the Makefile to try to rebuild
> > them anyway? I have a modern Python and I've been doing a fair amount
>
the xml/__init__.py file contains a cute little hack that overrides
the *entire* xml subtree with stuff from PyXML, if available.
the code basically does
import _xmlplus
sys.modules[__name__] = _xmlplus
(exception handling and version checks not shown).
however, this means that as thing
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
>That looks good to me. Well, I actually try not to use cls as the first
>argument to metaclass's __new__ method, because there's so many classes
>being tossed about at that point that I try to be more explicit. But I
>don't consider that a common
Barry Warsaw wrote:
> On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
>
>
>>I personally feel "cls" should be used for classmethods, and not
>>elsewhere. Just like I wouldn't like someone using "self" outside of
>>the first argument of instance methods. So class_ still would be a good
Raymond Hettinger wrote:
>>Do not use accessor methods, like ``obj.getFoo()`` and
>>``obj.setFoo(v)``, instead just expose a public attribute
>
> (``obj.foo``).
>
> This advice is, of course, not appropriate for all users (properties are
> not typically in a Python beginner's skill set) or all us
Jeremy Hylton wrote:
> The C files are checked into subversion. Perhaps there is some
> problem with the timestamps that causes the Makefile to try to rebuild
> them anyway? I have a modern Python and I've been doing a fair amount
> of development on these files; as a result, I haven't noticed a
On 12/11/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> João Paulo Silva wrote:
>
> > >>> a = file("dir/foo")
> > >>> a.close()
> > >>> a.read()
> >
> > Traceback (most recent call last):
> > File "", line 1, in -toplevel-
> > a.read()
> > ValueError: I/O operation on closed file
> >
> > Shou
The C files are checked into subversion. Perhaps there is some
problem with the timestamps that causes the Makefile to try to rebuild
them anyway? I have a modern Python and I've been doing a fair amount
of development on these files; as a result, I haven't noticed a
problem.
Jeremy
On 12/12/05
On 12/12/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Perhaps "The __ name convention is designed for 'mixins'; as a means of
> enforcing "private" it is both ineffective and annoying. For example,
> distutils.msvccompiler uses a bunch of instance variables which would I
> would like to ac
On 12/12/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> In practice, I don't agree that it works fine. Inevitably, someone
> finds a need to access a "private" variable in a subclass. Or
> even in the original class, you find some need to use something like
> __getattr__ where the implicit name mang
On 12/12/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> When I need an identifier unique to a class I just use a reference to
> the class itself. As such I'd like to suggest that
> obj.__private
> be converted to
> obj.__dict__[(type(obj), '__private')]
>
> Note that I'm accessing __dict__ directly s
On 12/11/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I know about the fear of accidental reuse of class names, but I don't
> > find it a compelling argument.
>
> FWIW, I know I currently have a number of classes that are potentially
>
At 11:35 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
> >> In my experience it's difficult to find the locations where another
> >> module mucks with your object's state. Using properties or accessor
> >> methods coupling between modules is reduced and you can be more
> >> confide
[EMAIL PROTECTED] wrote:
> Jim> That's why, in my suggested writeup, I suggested that attributes
> Jim> should be used if the accessors are trivial.
>
> In my experience it's difficult to find the locations where another module
> mucks with your object's state. Using properties or accesso
On Sun, 2005-12-11 at 15:12 -0800, Brett Cannon wrote:
> I remember Barry saying he wanted to start a branch for work on the
> next version of the 'email' package. And it is possible more and more
> modules developed externally will begin to be included in the stdlib.
> Perhaps PEP 2 should be u
looks like you need to have a recent Python version installed
to be able to build the current trunk:
./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl
./Parser/asdl_c.py:150: SyntaxWarning: local name 'self' in
'sum_with_constructors' shadows use of 'self' as global in nested scope
On Sun, 2005-12-11 at 16:30 -0600, Ian Bicking wrote:
> Potentially it could be added that the whole issue can often be avoided
> when an object's methods perform actions instead of returning attributes
> of the object. It's a long topic; maybe it could even just be a link,
> if someone knows
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
> I personally feel "cls" should be used for classmethods, and not
> elsewhere. Just like I wouldn't like someone using "self" outside of
> the first argument of instance methods. So class_ still would be a good
> spelling elsewhere.
Here
Jeremy Hylton wrote:
> On 12/12/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> Perhaps "The __ name convention is designed for 'mixins'; as a means of
>> enforcing "private" it is both ineffective and annoying. For example,
>> distutils.msvccompiler uses a bunch of instance variables which
>> In my experience it's difficult to find the locations where another
>> module mucks with your object's state. Using properties or accessor
>> methods coupling between modules is reduced and you can be more
>> confident that the only place an object's state is modified directly
On Sun, 2005-12-11 at 11:20 -0500, Jim Fulton wrote:
> This seems outdated. My impression, in part from time spent
> working with the Python Labs guys, is that it is fine to have public
> data sttributes even for non-"record" types. In fact, I would argue that
> any time you would be tempted to
At 09:59 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
> Jim> That's why, in my suggested writeup, I suggested that attributes
> Jim> should be used if the accessors are trivial.
>
>In my experience it's difficult to find the locations where another module
>mucks with your object's state.
Jim> That's why, in my suggested writeup, I suggested that attributes
Jim> should be used if the accessors are trivial.
In my experience it's difficult to find the locations where another module
mucks with your object's state. Using properties or accessor methods
coupling between modules
>> Just say "go", and I'll start working on this.
Jeremy> Are you still waiting for someone to say go? I'm not sure what
Jeremy> responsible party should say it; if I'm not the right person,
Jeremy> would the right person please say "go."
Can we take the absence of an explicit "
Nick> Any old code could be fixed by putting "from types import
Nick> ClassType as __metaclass__" at the top of the affected modules.
Which would be, what, 90% of all Python code written that defines classes?
Skip
___
Python-Dev mailing list
Py
On Mon, Dec 12, 2005, Noam Raphael wrote:
>
> I now discovered that a callback registered when creating a weak
> reference will be called only if the weak reference object is still
> alive. This is not documented in the weakref module documentation.
>
> (It's a good behaviour - it just ought to b
Dom, 2005-12-11 às 16:30 -0600, Ian Bicking escreveu:
> Jim Fulton wrote:
> >> Designing for inheritance
> >>
> >>Always decide whether a class's methods and instance variables
> >>should be public or non-public. In general, never make data
> >>variables public unless
On 12/12/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Jim Fulton wrote:
> > Ian Bicking wrote:
> >> Jim Fulton wrote:
> >>> Ian Bicking wrote:
> Private attributes should have two leading underscores, no
> trailing underscores.
>
> This conflicts with a pre
Gustavo J. A. M. Carneiro wrote:
...
> IMHO, if getting a property involves a potentially long computation,
> it's better to have an accessor method rather than a property;
> xpto.getFoobar() hints right away the programmer that to access that
> value some code has to be run, so the programmer i
Jim Fulton wrote:
> Ian Bicking wrote:
>> Jim Fulton wrote:
>>> Ian Bicking wrote:
Private attributes should have two leading underscores, no
trailing underscores.
This conflicts with a previous suggestion "Generally, double leading
underscores should be used
On Mon, Dec 12, 2005 at 01:32:31PM +, Michael Hoffman wrote:
> [Hye-Shik Chang]
> >> I think "contrib" is somewhat conventional for the purpose.
>
> [Steve Holden]
> > Indeed, but conventionally *all* code in the Python core is contributed,
> > and I think we need a name that differentiates ex
[Hye-Shik Chang]
>> I think "contrib" is somewhat conventional for the purpose.
[Steve Holden]
> Indeed, but conventionally *all* code in the Python core is contributed,
> and I think we need a name that differentiates externally-maintained
> packages from the contributions that are integrated int
[Quotations deleted since I'm not replying to anything directly]
When I need an identifier unique to a class I just use a reference to
the class itself. As such I'd like to suggest that
obj.__private
be converted to
obj.__dict__[(type(obj), '__private')]
Note that I'm accessing __dict__ directly
Steve Holden wrote:
>>>anyone ?
>>
>> I think "contrib" is somewhat conventional for the purpose.
>>
> Indeed, but conventionally *all* code in the Python core is contributed,
> and I think we need a name that differentiates externally-maintained
> packages from the contributions that are integrat
Hye-Shik Chang wrote:
> On 12/12/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>Fredrik Lundh wrote:
>>
>>
>>>just one question: where do you want [to put] the "vendor" checkins ? I'm
>>>using
>>>a flat "kits" namespace in my own repositories, e.g.
>>
>>>anyone has a better name?
>>
>>anyone ?
On 12/12/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> > just one question: where do you want [to put] the "vendor" checkins ? I'm
> > using
> > a flat "kits" namespace in my own repositories, e.g.
>
> > anyone has a better name?
>
> anyone ?
>
I think "contrib" is some
Raymond Hettinger wrote:
>>Do not use accessor methods, like ``obj.getFoo()`` and
>>``obj.setFoo(v)``, instead just expose a public attribute
>
> (``obj.foo``).
>
> This advice is, of course, not appropriate for all users (properties are
> not typically in a Python beginner's skill set)
Really?
Tim Peters wrote:
> [Neal Norwitz]
>
...
> That was the only point to `__` name-mangling. People who think it's
> trying to, e.g., emulate C++'s `private` gimmick are enjoying a
> semi-private fantasy ;-) It works fine for its intended use.
In theory, I agree.
In practice, I don't agree that
Hello,
I now discovered that a callback registered when creating a weak
reference will be called only if the weak reference object is still
alive. This is not documented in the weakref module documentation.
(It's a good behaviour - it just ought to be documented.)
Have a good day,
Noam
_
Fredrik Lundh wrote:
> Fredrik Lundh wrote:
>
>
>>just one question: where do you want [to put] the "vendor" checkins ? I'm
>>using
>>a flat "kits" namespace in my own repositories, e.g.
>
>
>>anyone has a better name?
>
>
> anyone ?
>
How about "independent" to highlight the fact that dev
[EMAIL PROTECTED] wrote:
> Ian> Do not use accessor methods, like ``obj.getFoo()`` and
> Ian> ``obj.setFoo(v)``, instead just expose a public attribute
> Ian> (``obj.foo``). If necessary you can use ``property`` to implement
> Ian> the same functionality that accessor methods would
Martin v. Löwis wrote:
> > Since all the relevant module names start with "Element", putting it
> > directly
> > under xml wouldn't be too bad. But an xml subpackage is better, and prior
> > art says "etree".
>
> So etree it is.
I just realized that the prior art (lxml.etree) uses etree as an a
Fredrik Lundh wrote:
> just one question: where do you want [to put] the "vendor" checkins ? I'm
> using
> a flat "kits" namespace in my own repositories, e.g.
> anyone has a better name?
anyone ?
___
Python-Dev mailing list
Python-Dev@python.or
Tim Peters wrote:
> [Neal Norwitz]
>
>>I recently asked Guido about name mangling wrt Py3k. He definitely
>>wanted to keep it in. Unless he changed his mind, I doubt he would
>>deprecate it. His rationale was that there needs to be a way to
>>handle name collision with multiple inheritance.
>
Guido van Rossum wrote:
> On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
>>> [EMAIL PROTECTED] wrote:
Ian> Do not use accessor methods, like ``obj.getFoo()`` and
Ian> ``obj.setFoo(v)``, instead just expose a public attribute
Ian> (``obj.foo`
82 matches
Mail list logo
