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 development takes
place
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 it
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? In any
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 somewhat conventional for
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 ?
I think contrib is
[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__
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
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 only to avoid name
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 is
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 previous suggestion Generally,
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 you're
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 be
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
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 stop as
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. Using
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
is
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 would I
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's what
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 of
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
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
[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 accessor
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
confident that the
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
hazardous
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 mangling
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 access in
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
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 pyshell#28, line 1, in -toplevel-
a.read()
ValueError: I/O operation on closed file
Shoudn't this raise IOError?
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 use cases.
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
spelling
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
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
of
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 version
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
different versions of
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 EnhancedDocument or
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
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
of
[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 steps
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 anyway? I have
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 try to
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 so many
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 was Pronounced
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
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 should
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,
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
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
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
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. Both has
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's
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 grouped
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
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:
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
* 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 specific imports
62 matches
Mail list logo
