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`
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.
>
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
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
[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
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
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
_
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
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?
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
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 ?
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
[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
[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
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
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
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
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
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 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
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
>> 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 "
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
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.
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
>> 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
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
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
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
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 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
[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
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
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
>
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/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, 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
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/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
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
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
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
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
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
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
>
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
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
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
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 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
[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
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
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
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, 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
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:
...
> 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
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 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
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
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
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
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
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,
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
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
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
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
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
> 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> 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
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
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
>> 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
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
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
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
[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
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
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
>> * 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
82 matches
Mail list logo
