Re: [Python-Dev] PEP 8 updates/clarifications
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``). If necessary you can use ``property`` to implement Ian> the same functionality that accessor methods would give you. Don't properties only work with new-style clsses? If so, this should probably be noted. >>> In the future, aren't all classes going to become new-style? Was it >>> going to wait until Py3k, or sometime sooner? >> Going the Java route (no implicit base class) would be an interim step along >> that road (i.e., a release or two where there is no default __metaclass__ >> fallback). >> >> Any old code could be fixed by putting "from types import ClassType as >> __metaclass__" at the top of the affected modules. > > I'm not sure what you are proposing and I'm not sure what problem you > are trying to solve. I'm accustomed to handling major semantic changes in an API by deprecating the API first, then later bringing it back with the new semantics. A sharp cutover to new semantics (even in a version advertised as backwards incompatible) makes me nervous :) > The plan for new-style vs. classic classes is simple and doesn't need > to change (IMO): until Py3k, the status quo will remain; in Py3k, > there is only new-style (except if you use a custom metaclass). The problem I have with the currently planned sharp cutover is that the errors caused by the change are not necessarily easy to predict, causing difficulties with managing that transition. Tracking down whether or not the change to new-style classes is the cause of a given Py3k migration problem could be difficult. Code can be future-proofed by instituting one of three rules: 1. Always inherit from something (enforcable via "__metaclass__ = None") 2. Always use new-style classes by default (via "__metaclass__ = type") 3. Always use old-style classes by default (via "from types import ClassType as __metaclass__") One way to make this migration easier to manage would be to have the class creation code check __builtins__ for a definition of __metaclass__. This would make it possible for application developers to determine whether or not their application or any of its support libraries are dependent on certain classes being old-style (by running the program and changing the default metaclass via "__builtins__.__metaclass_ = None" or "__builtins__.__metaclass_ = type"). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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. > > > That wasn't quite it. The original motivation was to help avoid name > collisions under inheritance period, and especially when writing a > base class intended for subclassing by other parties, such as most > mix-in classes. For example, if your utility or mixin base class `A` > has a data member named `n`, nobody deriving from `A` dare name one of > their data members `n` too, and it's unreasonable to expect everyone > deriving from `A` to learn and avoid all the names `A` uses > internally. It's even more unreasonable for A's author to have to > promise, after A's first release, never to change the name of, or > introduce any new, attribute (A's author dare not, lest the new name > conflict with a name someone else's subclass used). > > If A's author names the attribute `__n` instead, all those problems go > away, provided only that some subclass doesn't also name itself `A`. > > 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 that case it would seem to make even *more* sense, theoretically, to replace the class name in mangled names with a GUID, hence avoiding collisions in similarly-named subclasses. Then it would work even finer (though the mangled names would be longer, and less meaningful in debugging). mangling-things-by-typing-them-since-1967-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 alias for the ElementTree module, not as a package name. this means that to import the core Element type, you'd do: # classic ET from elementtree.ElementTree import Element or # bundled ET from xml.etree.ElementTree import Element or # libxml-powered ET from lxml.etree import Element or # accelerated ET from cElementTree import Element I'm not sure if this really is a problem. better explicit than implicit, as PyXML has shown us. if people want to be able to rapidly switch between versions, they can always use from-import or import-as. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[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 give you. > > Don't properties only work with new-style clsses? If so, this should > probably be noted. Read properties work with old-style classes. Write properties require old-stype classes. I'm always forgetting this for some reason. Yes, it should be noted. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 elsewhere? Or "external"? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A missing piece of information in weakref documentation
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 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 doesn't come into play and you have to emulate the name mangling. Or perhaps someone wants to examine the value of one of these variables in the debugger. In my experience, almost every time someone uses the __private trick, they or someone else comes to regret it. OTOH, explicit name mangling provides the benefits of implicit name mangling without it's drawbacks. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 case, properties are only needed if you change your mind about the implementation. In my experience, they are rarely needed. > or all use cases. I think the advice gave a very narrow case, which was when you were going to write trivial accessors. > It is > closer to one person's view of the One-Right-Way(tm). Opinions on > programming best practices vary widely, evolve over time, and may be > context dependent. I thought I was reflecting more than just my opinion. Also, the original text had just as strong an admonition -- one that, as I mentioned, seem to be out of line with current thinking. ... >>>experience (for everyone I know) has shown them to be an attractive >>>nuisance. I recommend discouraging them. >> >>I really really hate double underscores > > > FWIW, I think we have no business dictating to others how they should > name their variables. This is doubly true for a convention that has a > long history and built-in language support. Even if, experience with a practice has shown it to be highly problematic? > My preference is to leave PEP 8 for the minimum practices necessary for > one programmer to be able to read and maintain another programmer's > code. I'm for making the style guide smaller. I do think it offers too much advice in places. Although I'm not sure we could all agree om what those places are. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 the purpose. Hye-Shik ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 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 integrated into the core and maintained as part of it. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 integrated into the core and > maintained as part of it. I'm leaning towards a flat "external" directory at the top of the SVN tree. no tags or trunk stuff; just the snapshots (plus a README file that explains what's in there). If nobody stops me (Martin?), I'll set this up later today... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
[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 so as to avoid getattr's requirement for attribute names to be strings. Obviously it doesn't handle backwards compatibility, so it's more of a "if I could do it again.." suggestion. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Directory for packages maintained outside the core (was Re: ElementTree - Why not part of the core?)
[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 into the core and > maintained as part of it. The same could be said of a lot of other projects that use the "contrib" convention. I have a much better idea of what "contrib" means than "kits" or "external." -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Directory for packages maintained outside the core (was Re: ElementTree - Why not part of the core?)
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 externally-maintained > > packages from the contributions that are integrated into the core and > > maintained as part of it. > > The same could be said of a lot of other projects that use the > "contrib" convention. I have a much better idea of what "contrib" > means than "kits" or "external." I have a much better idea of what "contrib" means than "external", but it's the wrong idea :) "contrib" implies to me things that are not really a core part of the project (just extras that may perhaps be of use to someone), and so they haven't received the same quality control or integration (e.g. I wouldn't expect to find documentation for it in the standard library reference). Of course, I'm thinking of "contrib" directories in tar.gz files when I think this, but if I saw a contrib directory in SVN (without having seen this mailing list thread), I'd probably assume the same of it. "external" is much clearer to me, and has a clear parallel with SVN's "svn:external" feature. Either way, a simple README.txt in the directory could explain things adequately. -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 conflicts with attributes in classes designed to be subclassed." Or perhaps "private attributes" needs to be better explained. ... >> I really really hate double underscores, but I thought I'd let some >> other people suggest stronger language first > > Can we officially mark __private as a mistake. Perhaps: > - Strongly discourage it in the style guide > - Mark it in the language reference as a deprecated feature > - Generate deprecation warnings when it is used? >(This might be too much.) 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 a subclass, but are "unavailable" because the author could not imagine why I would need them. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 more likely to store > the result in a temp variable for use in the same context, instead of > calling it multiple times. Similar reasoning applites for setter vs > property =. That's why, in my suggested writeup, I suggested that attributes should be used if the accessors are trivial. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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, double leading > underscores should be used only to avoid name conflicts with > attributes in classes designed to be subclassed." Or perhaps > "private attributes" needs to be better explained. > ... > >> I really really hate double underscores, but I thought I'd let some > >> other people suggest stronger language first > > > > Can we officially mark __private as a mistake. Perhaps: > > - Strongly discourage it in the style guide > > - Mark it in the language reference as a deprecated feature > > - Generate deprecation warnings when it is used? > >(This might be too much.) > > 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 a subclass, but are "unavailable" because the > author could not imagine why I would need them. These are really separate issues, right? The effect of __ names is to make a variable private to a class, because it's a right pain to access it from any other class. If you design a class for inheritance and use __ names, you're deciding to keep the details of those names private. There is a separate question about whether the designer of msvccompiler made the right choices about which instance variables were private. This issue is really separate from the naming mechanism. If the designer of the class didn't intent to make those instance variables available to you, it's not the language's fault. There are ways the language and tools could make things easier for developers. The debugger could know how to mangle names for us. It would be great to have editors/ides that could rename all the variables if we decide to change the name to make it available to subclasses. I think these problems are the primary reasons I dislike mangled names. I can't remember how to type the names in pdb and it's a pain to change every use of the name if I change from __var to _var. C++ private variables don't suffer from either of these problems. The visibility is separate from the name; if I change an instance variable from private to protected, I don't have to edit existing code to track a new name. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 implementing essentially a > >>record. It's almost always preferrable to give a functional > > > > >interface to your class instead (and some Python 2.2 > > >developments will make this much nicer). > > > > > > Yes, Python 2.2 developments have made this better. Use of property() > > > should be suggested. > > > > 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 provide "getFoo()" and "setFoo(v)" > > for some "private attribute _foo", it would be better to make it > > public. I certainly find "blah.foo" and "blah.foo = v" to be much > > better than "blah.getFoo()" and blah.setFoo(v)". > > > > Certainly, properties provide a safety belt. I would argue it this > > way: Python APIs can include attributes as well as methods. > > Exposure of an attribute need not constrain the implementation, thanks > > to properties. OTOH, I wouldn't bother with a property unless it's needed. > > So, getting back to the original paragraph, perhaps it could say: > > Decide whether a class's methods and instance variables should be public > or non-public. Non-public methods and variables should start with an > underscore. > > Do not use accessor methods, like ``obj.getFoo()`` and > ``obj.setFoo(v)``, instead just expose a public attribute (``obj.foo``). > If necessary you can use ``property`` to implement the same > functionality that accessor methods would give you. If you do use > properties, getting that property should never have a side effect. > [well... I think that certain side effects like caching and logging are > okay, but I'm not sure how to make that distinction] 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 more likely to store the result in a temp variable for use in the same context, instead of calling it multiple times. Similar reasoning applites for setter vs property =. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A missing piece of information in weakref documentation
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 documented.) 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. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck." --USENET schmuck (aka Robert Kern) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Incorporating external packages into Python's std distribution
>> 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 an implicit "go"? 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 in that direction, so I'm probably not the best person to describe how it works, but here goes. For any given externally maintained package you give it a place to live in the xemacs-packages CVS repository. Each file gets two versions, e.g., python-mode.el and python-mode.el.upstream. I believe the intent is that the difference between the two represents XEmacs-specific changes to the code. When you import a new version of your code, you're supposed to factor in the diffs between the upstream version and the XEmacs version. You could maintain a context/unified diff instead I suppose, then just update the .upstream version and patch it to get the candidate version. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 is reduced and you can be more confident that the only place an object's state is modified directly is in its own code. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 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 in its own code. So? There is no reason for you to care about this in advance of actual requirements. Normal instance variables should be used for normal instance variable things, until you have a need to do something when they change. Then, and only then, is it appropriate to introduce properties. Otherwise, you're just wasting your time with busywork and annoying the heck out of people trying to read your code. Python is not Java, and Java's use of getters and setters is a reflection of its inadequacies as a programming language, not a badge of strength. They're a bug, not a feature. What *would* be a nice feature to add to Python would be a descriptor that stores the value of the property in the object dictionary, but calls a function whenever the attribute is changed. So then you could do: @setter def somevar(self, value): # update attrs affected by changing self.somevar This is the shortest upgrade path for the common case of an attribute's lifetime. First, it's just a regular __dict__ attribute, and then you maybe want to do something when it changes, but you still want it readable and stored normally, without having to have two attribute names (one public and one private). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 provide "getFoo()" and "setFoo(v)" > for some "private attribute _foo", it would be better to make it > public. I certainly find "blah.foo" and "blah.foo = v" to be much > better than "blah.getFoo()" and blah.setFoo(v)". > > Certainly, properties provide a safety belt. I would argue it this > way: Python APIs can include attributes as well as methods. > Exposure of an attribute need not constrain the implementation, thanks > to properties. OTOH, I wouldn't bother with a property unless it's needed. Let me know what you think about this language (from my in-progress update of PEP 8): Designing for inheritance Always decide whether a class's methods and instance variables (collectively: "attributes") should be public or non-public. Public attributes are those that you expect unrelated clients of your class to use, with your commitment to avoid backward incompatible changes. Non-public attributes are those that are not intended to be used by third parties; you make no guarantees that non-pubic attributes won't change or even be removed. We don't use the term "private" here, since no attribute is really private in Python (without a generally unnecessary amount of work). However, another category of attribute are those which, while not being public, are intended for use by subclasses (often called "protected" in other languages). Some classes are designed to be inherited from, either to extend or modify aspects of the class's behavior. When designing such a class, take care to make explicit decisions about which attributes are public, which are non-public but useful for subclasses, and which are truly only to be used by your base class. With this in mind, here are the Pythonic guidelines: - Public attributes should have no leading underscores. - If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling. E.g. "class_" is preferable to "cls" or "klass". Note 1: See the argument name recommendation above for class methods. [BAW: I'll include this new text in a later followup] - For simple public data attributes, it is fine to expose just the attribute name, without complicated accessor/mutator methods. Keep in mind that Python provides an easy path to future enhancement, should you find that a simple data attribute needs to grow functional behavior. In that case, use properties to hide functional implementation behind simple data attribute access syntax. Note 1: Properties only work on new-style classes. Note 2: Try to keep the functional behavior side-effect free, although side-effects such as caching are generally fine. - If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores. This invokes Python's name mangling algorithm, where the name of the class is mangled into the attribute name. This helps avoid attribute name collisions should subclasses inadvertently contain attributes with the same name. Note 1: Note that only the simple class name is used in the mangled name, so if a subclass chooses both the same class name and attribute name, you can still get name collisions. Note 2: Name mangling can make certain uses, such as debugging, less convenient. However the name mangling algorithm is well documented and easy to perform manually. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
>> 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 in its own code. pje> So? So I'm saying I encounter it in practice and makes code harder to maintain. It's not a hypothetical problem for me. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 >> would like to access in a subclass, but are "unavailable" because the >> author could not imagine why I would need them. > > These are really separate issues, right? The effect of __ names is to > make a variable private to a class, because it's a right pain to > access it from any other class. If you design a class for inheritance > and use __ names, you're deciding to keep the details of those names > private. For 'mixins' (or other multi-inheritance schemes) the renaming serves a useful (and necessary) function -- collision avoidance. In a hierarchy designed for inheritance, I suspect fewer problems than I see in the cited code. For code built with no thought of inheritance, it will be easier to (re) use parts if non-'__' names are used. Code built for inheritance is not responsible for the correctness of subclasses; I suspect many '__' names are used in a mistaken attempt to prevent subclasses from making mistakes, rather than attempting to ease their use. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 I've written: Function and method arguments Always use 'self' for the first argument to instance methods. Always use 'cls' for the first argument to class methods. If a function argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. Thus "print_" is better than "prnt". > 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 by increasing >length, while dotted imports should be grouped roughly alphabetically. > > This seems too complex to me for PEP 8. Really? ISTR adopting this convention from Guido, but I'm not 100% sure about that. After having used it for several years now, I do really like this style, but I'm willing to leave the recommendation out of PEP 8. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 a good discussion along those lines. I'm sure > there's some terminology here that I'm forgetting that describes the > design pattern. There's also a point when the style guide becomes an > API design guide, and I don't know how far it should go in that direction. I'm not exactly sure if this is what you're getting at, but one thing that bothers me is using data attributes to trigger actions. Maybe this gets into the "no side-effects" rule for data attributes, but attributes that cause an object to perform some action should always be explicit methods. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] should I really have to install Python before I can build it ?
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 'emit' def sum_with_constructors(self, sum, name, depth): ./Parser/asdl_c.py:263: SyntaxWarning: local name 'self' in 'emit_function' shadows use of 'self' as global in nested scope 'emit' def emit_function(self, name, ctype, args, attrs, union=1): ./Parser/asdl_c.py:296: SyntaxWarning: local name 'self' in 'emit_body_union' shadows use of 'self' as global in nested scope 'emit' def emit_body_union(self, name, args, attrs): ./Parser/asdl_c.py:305: SyntaxWarning: local name 'self' in 'emit_body_struct' shadows use of 'self' as global in nested scope 'emit' def emit_body_struct(self, name, args, attrs): ./Parser/asdl_c.py:444: SyntaxWarning: local name 'self' in 'visitField' shadows use of 'self' as global in nested scope 'emit' def visitField(self, field, name, depth, product): ./Parser/asdl_c.py:444: SyntaxWarning: local name 'depth' in 'visitField' shadows use of 'depth' as global in nested scope 'emit' def visitField(self, field, name, depth, product): ./Parser/asdl_c.py:605: SyntaxWarning: local name 'self' in 'visitField' shadows use of 'self' as global in nested scope 'emit' def visitField(self, field, name, depth, product): ./Parser/asdl_c.py:605: SyntaxWarning: local name 'depth' in 'visitField' shadows use of 'depth' as global in nested scope 'emit' def visitField(self, field, name, depth, product): Traceback (most recent call last): File "./Parser/asdl_c.py", line 9, in ? import asdl File "./Parser/asdl.py", line 53, in ? class ASDLScanner(spark.GenericScanner, object): NameError: name 'object' is not defined make: *** [Include/Python-ast.h] Error 1 (this machine has Python 2.1) any reason why the C files are not checked into subversion ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 updated with basic guidelines we plan to stick > to > for modules that are externally developed and occasionally synched > with the core. Basically I think specifying who the code comes from, > having auto-assignment for bug reports in the tracker, and saying that > no updates to the snapshot except for bug fixes once alpha is released > should be enough. I would assume the snapshot in svn would just be a > direct copy to the core and not require running any special script or > something to generate anything. If we do go that way, then mentioning > that in the PEP wouldn't hurt either. 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. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[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 methods > coupling between modules is reduced and you can be more confident that the > only place an object's state is modified directly is in its own code. I don't understand this argument. Any mutating method or property invoked by foreign code changes an object's state. If you provide a property or a pair if accessors that just sets and gets an attribute with a slightly different name, that affords no more protection than if people were setting the attribute directly. If you don't want external code to change an attribute, don't expose it through a public API. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 only place an object's state is modified directly > >> is in its own code. > > pje> So? > >So I'm saying I encounter it in practice and makes code harder to maintain. >It's not a hypothetical problem for me. I don't understand what part is the "problem". Why do you care what other code does to your object's state? If you need to maintain your own state when an attribute changes, change the attribute to a property. Where's the "problem"? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 in this way. Each of these classes is basically a > substitute class for a third-party API that I have to code to. The > API is missing a number of convenience methods, and the most > straightforward way to introduce these methods[1] is to create a > subclass of the appropriate class. Since they are in a different > module, it seems perfectly normal for me to give them the same name > since for all external modules, they should look the same as the > original API (but with the added methods). So I have a number of > classes that look something like: > > class Document(_cdm.Document): > ... > # add convenience methods here > ... Personally, I find that naming convention a mistake. Call it MyDocument or EnhancedDocument or DocumentPlusPlus (be creative!) but don't reuse the original name. I'm not saying this because it helps the __private argument; I'm saying this because in lots of contexts we leave out the package/module path and only use the class name, and added functionality is a good reason to be able to distinguish between the original class and the enhanced version. > > Also, I like the current, well-defined mangling algorithm; it means > > that when I'm in the debugger I can manually mangle or unmangle names > > as required. > > Why couldn't the name mangling do something like: > > '_%s_%s__%s' % (cls.__module__, cls.__name__, attrname) Too long, IMO. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 so as to avoid getattr's > requirement for attribute names to be strings. > > Obviously it doesn't handle backwards compatibility, so it's more of a > "if I could do it again.." suggestion. 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, *anyone* could use A().__private (but not B().__private where B is a subclass of A). The intention is for __private to have the right meaning only within the source code for class A, but it should work even if type(self) is a subclass of A. (Or even if it's unrelated to A, but that's a separate and weaker use case.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 doesn't come into play > and you have to emulate the name mangling. Or perhaps someone wants > to examine the value of one of these variables in the debugger. > In my experience, almost every time someone uses the __private > trick, they or someone else comes to regret it. > > OTOH, explicit name mangling provides the benefits of implicit > name mangling without it's drawbacks. I half agree. I've seen many classes overuse __private. But that's a separate issue from not having the feature at all; you might as well argue against private in Java or C++. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 a subclass, but are "unavailable" because the > author could not imagine why I would need them. But __private's use case is *not* restricted to mixins; this seems to be a common misconception. It is a tool (not the only one!) for name conflict avoidance in all inheritance situations, including single inheritance. BTW let me note that inheritance is overused. People should get used to containment patterns (e.g. facade, delegate etc.) in favor of inheritance patterns. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before I can build it ?
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, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > 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 > 'emit' > def sum_with_constructors(self, sum, name, depth): > ./Parser/asdl_c.py:263: SyntaxWarning: local name 'self' in 'emit_function' > shadows use of 'self' as global in nested scope 'emit' > def emit_function(self, name, ctype, args, attrs, union=1): > ./Parser/asdl_c.py:296: SyntaxWarning: local name 'self' in 'emit_body_union' > shadows use of 'self' as global in nested scope 'emit' > def emit_body_union(self, name, args, attrs): > ./Parser/asdl_c.py:305: SyntaxWarning: local name 'self' in > 'emit_body_struct' shadows use of 'self' as global in nested scope > 'emit' > def emit_body_struct(self, name, args, attrs): > ./Parser/asdl_c.py:444: SyntaxWarning: local name 'self' in 'visitField' > shadows use of 'self' as global in nested scope 'emit' > def visitField(self, field, name, depth, product): > ./Parser/asdl_c.py:444: SyntaxWarning: local name 'depth' in 'visitField' > shadows use of 'depth' as global in nested scope 'emit' > def visitField(self, field, name, depth, product): > ./Parser/asdl_c.py:605: SyntaxWarning: local name 'self' in 'visitField' > shadows use of 'self' as global in nested scope 'emit' > def visitField(self, field, name, depth, product): > ./Parser/asdl_c.py:605: SyntaxWarning: local name 'depth' in 'visitField' > shadows use of 'depth' as global in nested scope 'emit' > def visitField(self, field, name, depth, product): > Traceback (most recent call last): > File "./Parser/asdl_c.py", line 9, in ? > import asdl > File "./Parser/asdl.py", line 53, in ? > class ASDLScanner(spark.GenericScanner, object): > NameError: name 'object' is not defined > make: *** [Include/Python-ast.h] Error 1 > > (this machine has Python 2.1) > > any reason why the C files are not checked into subversion ? > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception type on handling closed files
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
> >
> > Shoudn't this raise IOError? Seems more semantically correct to me.
>
> IOError is, as the documentation says, used "when an I/O operation fails
> for an I/O related reason", while ValueError is used "when an argument has
> the right type but an inappropriate value."
What /F says.
IOError is something you could reasonably catch, log, and ignore
(since I/O devices are known to be fallible). The ValueError (at least
in this case) means there's a logic bug in your program -- you're
trying to use a file that you've already closed. Very important
distinction!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Ican build it ?
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 > problem. ah, of course. subversion sets the timestamp to the checkout time for each file, so things may or may not work after a fresh checkout. however, adsl_c does use the installed python, rather than the local version: #! /usr/bin/env python """Generate C code from an ASDL description.""" 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 ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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. It is > closer to one person's view of the One-Right-Way(tm). Opinions on > programming best practices vary widely, evolve over time, and may be > context dependent. Beginning programmers do all sorts of things that aren't considered good style by more experienced programmers. That's fine -- but then PEP 8 should direct them to a better style. Specifically PEP 8 currently suggests that public attributes should be avoided, and this no longer needs to be the case. But at the same time, people are using Java conventions of setters and getters (and these conventions exist in older code as well), so I think it is helpful to suggest that accessor methods should be avoided. I don't think the suggestion has to be strongly worded. >>>While, on some level, private variables seem attractive, I think that >>>experience (for everyone I know) has shown them to be an attractive >>>nuisance. I recommend discouraging them. >> >>I really really hate double underscores > > > FWIW, I think we have no business dictating to others how they should > name their variables. This is doubly true for a convention that has a > long history and built-in language support. Double underscores aren't just naming, they involve the semantics of name mangling. That's what makes them different than other names, and jarring to many programmers (like myself). Personally I'm happy if we call double underscore attributes "hidden" instead of "private", or otherwise help keep people from being misdirected into using double underscore as "real" private variables. PEP 8 currently gives the impression that they should be used for private attributes. > My preference is to leave PEP 8 for the minimum practices necessary for > one programmer to be able to read and maintain another programmer's > code. There's a couple things I want to use PEP 8 for: * Deciding on things I don't care that much about, except in terms of consistency. I am happy that PEP 8 was updated to say that underscore separated words are preferred, for instance, though I would have been just as happy with mixed case. I just want everyone to at least move towards being on the same page. * When debates on these styles come up, I want to be able to point to something somewhat authoritative. This avoids a lot of pointless discussion. Given these motivations, I guess I don't care that much about how __ is presented in PEP 8, except that the current inconsistent messages about it is made consistent, and that it isn't misrepresented as being the way of indicating "private". I don't think PEP 8 needs to be a text on good API design. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 elsewhere. > > > Here's what I've written: > > Function and method arguments > > Always use 'self' for the first argument to instance methods. > > Always use 'cls' for the first argument to class methods. > > If a function argument's name clashes with a reserved keyword, it is > generally better to append a single trailing underscore rather than use > an abbreviation or spelling corruption. Thus "print_" is better than > "prnt". 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 enough issue to be worth mentioning in PEP 8. >>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 by increasing >> length, while dotted imports should be grouped roughly alphabetically. >> >>This seems too complex to me for PEP 8. > > > Really? ISTR adopting this convention from Guido, but I'm not 100% sure > about that. After having used it for several years now, I do really > like this style, but I'm willing to leave the recommendation out of PEP > 8. It seems so exacting to me; stdlib, external modules, internal modules seems like enough ordering to me. If you want to order things more exactly, sure, but I don't really see the point personally. Since I can't assume as a reader that imports are ordered in any way I have to search to be sure of what's there. The grouping help me browse, but I'd hope that the import list is short enough that I don't need to use alphabetization to scan for a module. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 enough issue to be worth mentioning in PEP 8. I usually use 'meta' as the first argument of a metaclass __new__ or a metaclass classmethod, to avoid this particular bit of confusion. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] stupid package tricks
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 things are right now, xml.etree will simply disappear if the user has PyXML on the machine. what's the best way to fix this? the obvious fix is of course to do something like import _xmlplus import xml.etree _xmlplus.etree = xml.etree sys.modules[__name__] = _xmlplus but I have to admit that I'm no expert on package internals, so I might be missing something here. will the above solution work in all cases? is there some better way to do it? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Ican build it ?
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 development on these files; as a result, I haven't noticed a > > problem. > > ah, of course. subversion sets the timestamp to the checkout time for each > file, so things may or may not work after a fresh checkout. > > however, adsl_c does use the installed python, rather than the local version: > > #! /usr/bin/env python > """Generate C code from an ASDL description.""" > > 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 make build different names (e.g., on my OS X machine the executable is python.exe in my checkout, not python)? The idea seems fine to me, though, since the generated files are already checked out. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stupid package tricks
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 checks not shown). > >however, this means that as things are right now, xml.etree will >simply disappear if the user has PyXML on the machine. > >what's the best way to fix this? the obvious fix is of course to do >something like > > import _xmlplus > import xml.etree > _xmlplus.etree = xml.etree > sys.modules[__name__] = _xmlplus > >but I have to admit that I'm no expert on package internals, so I >might be missing something here. will the above solution work in >all cases? is there some better way to do it? I'd suggest: import _xmlplus _xmlplus.__path__.extend(__path__) sys.modules[__name__] = _xmlplus This ensures that any modules or packages inside 'xml' that aren't explicitly overridden by _xmlplus will still be available. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Icanbuild it ?
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 make build different names (e.g., on my OS X > machine the executable is python.exe in my checkout, not python)? you're right. I guess the right thing is to do this in the Makefile, and use $(PYTHON) to find the appropriate interpreter. changing the relevant rule to $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(PYTHON) $(ASDLGEN) $(AST_ASDL) might be sufficient. > The idea seems fine to me, though, since the generated files are > already checked out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 DocumentPlusPlus (be creative!) but > don't reuse the original name. > > I'm not saying this because it helps the __private argument; I'm > saying this because in lots of contexts we leave out the > package/module path and only use the class name, and added > functionality is a good reason to be able to distinguish between the > original class and the enhanced version. Ahh. I never run into this because I never import objects directly from modules. So, instead of: from elementtree.ElementTree import ElementTree ... ElementTree(...) I almost always write something like: import elementtree.ElementTree as et ... et.ElementTree(...) Thus, all objects that were imported from external modules are always immediately identifiable as such by their prefixed module name. I do see though that if you like to import the objects directly from the module this could be confusing. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A missing piece of information in weakref documentation
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Ican build it ?
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 development on these files; as a result, I haven't noticed a > > problem. > > ah, of course. subversion sets the timestamp to the checkout time for each > file, so things may or may not work after a fresh checkout. You can change this by setting use-commit-times=true in ~/.subversion/config ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorporating external packages into Python's stddistribution
[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 in that direction, so I'm > probably not the best person to describe how it works, but here goes. > > For any given externally maintained package you give it a place to live in > the xemacs-packages CVS repository. Each file gets two versions, e.g., > python-mode.el and python-mode.el.upstream. I believe the intent is that > the difference between the two represents XEmacs-specific changes to the > code. When you import a new version of your code, you're supposed to factor > in the diffs between the upstream version and the XEmacs version. You could > maintain a context/unified diff instead I suppose, then just update the > .upstream version and patch it to get the candidate version. in the model I proposed (and just implemented), the "external" repository corresponds to your "upstream" copy. you can use $ svn log -v --stop-on-copy to get an overview of all changes since the last upstream copy $ svn log -v --stop-on-copy Lib/xml/etree/ElementTree.py r41651 | fredrik.lundh | 2005-12-12 16:10:44 +0100 (Mon, 12 Dec 2005) | 3 lines Changed paths: A /python/trunk/Lib/xml/etree A /python/trunk/Lib/xml/etree/ElementInclude.py (from /external/elementtree-1.2.6-20050316/elementtree/ElementInclude.py:41650) A /python/trunk/Lib/xml/etree/ElementPath.py (from /external/elementtree-1.2.6-20050316/elementtree/ElementPath.py:41650) A /python/trunk/Lib/xml/etree/ElementTree.py (from /external/elementtree-1.2.6-20050316/elementtree/ElementTree.py:41650) A /python/trunk/Lib/xml/etree/__init__.py (from /external/elementtree-1.2.6-20050316/elementtree/__init__.py:41650) added ElementTree core components to xml.etree and use $ svn diff -r to get a full diff: $ svn diff -r 41651 Lib/xml/etree/ElementTree.py $ (nothing has changed yet) to update to a new upstream release, save the diff somewhere, import the new release under external, copy relevant files to trunk, commit, merge in the diff by hand, or using "svn merge". when you're done, commit again. that's it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Icanbuild it ?
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 build still continues with the current version of the .h/.c files, and we are left with telling users "no no, ignore this build error, everything is fine". The same just-ignore-it behavior can bite if the script genuinely fails after you just made a typo in one of the input files, for example. Doesn't look particularly clean to me, if you want my opinion. A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Ican build it ?
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 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. > > > > ah, of course. subversion sets the timestamp to the checkout time for each > > file, so things may or may not work after a fresh checkout. > You can change this by setting use-commit-times=true in > ~/.subversion/config 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. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 be more explicit. But I > >don't consider that a common enough issue to be worth mentioning in PEP 8. > > I usually use 'meta' as the first argument of a metaclass __new__ or a > metaclass classmethod, to avoid this particular bit of confusion. ...while I use 'mcl' for the same purpose (seems closer to me in spirit to 'cls' than 'meta' would be); Guido said he liked that, at the time (a couple of years ago) when he was following a talk of mine on metaclasses where I introduced this convention. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 classes > > >being tossed about at that point that I try to be more explicit. But I > > >don't consider that a common enough issue to be worth mentioning in PEP 8. > > > > I usually use 'meta' as the first argument of a metaclass __new__ or a > > metaclass classmethod, to avoid this particular bit of confusion. > >...while I use 'mcl' for the same purpose (seems closer to me in >spirit to 'cls' than 'meta' would be); Guido said he liked that, at >the time (a couple of years ago) when he was following a talk of mine >on metaclasses where I introduced this convention. 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; before the pronouncement I was using 'klass' as the argument name for class methods. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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; before the pronouncement I was using 'klass' as the argument name > for class methods. The name choices klass and meta are internally consistent, and so are cls and mcl. I just wouldn't like a mixed, and thus harder-to-remember, pair of choices such as cls and meta. Perhaps Guido can Pronounce one way or another and set the subdiscussion to rest... Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 the >>standard; before the pronouncement I was using 'klass' as the argument name >>for class methods. > > > The name choices klass and meta are internally consistent, and so are > cls and mcl. I just wouldn't like a mixed, and thus > harder-to-remember, pair of choices such as cls and meta. Perhaps > Guido can Pronounce one way or another and set the subdiscussion to > rest... I personally happily use "meta", but it doesn't seem that important, except insofar as it is reasonable (and perhaps preferred) not to use "cls" in that case. If someone wants to use even more verbose names in their metaclass that'd be fine by me -- it's not the kind of code I breeze by and expect to instantly understand like I do simple methods. I don't think it's that important to include in PEP 8, at least as long as no one reads the prescription of "cls" to mean they shouldn't choose a better argument name when there's a good reason. PEP 8 generally applies when there isn't a good reason. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before I can build 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; as a result, I haven't noticed a > problem. I tried this early today: svn up; make distclean; configure; make Unfortunately, that requires Python to already exist, so there's definitely a boostrapping issue in the build process. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ElementTree in stdlib
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+API for XML in stdlib seems to be a bit of a raised middle finger to those folks who have worked hard on competing or differently-scoped APIs, each of which deserves a bit more peer review than just a single nomination on python-dev, which seems to be all it took to obtain a blessing for ElementTree. I have nothing against ElementTree, and would like to see more XML processing options in core, but it seems to me like the XML-SIG is being deliberately left out of this process. Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had been tinkering with.[1] I don't think anyone was really bold enough to tell him what they really thought of it (other than that it is a lot like XIST), but it was admirable that he put it up for peer review rather than just dropping it into stdlib. Perhaps more importantly, it prompted some discussion that more or less acknowledged that these kinds of APIs do seem to be the future of XML in Python, and that we should be thinking about bringing some of them into PyXML and, ultimately, stdlib. But the problem of how to choose from the many options also became immediately apparent.[2] The discussion stalled, but I think it should start up again, in the proper forum, rather than letting the first-mentioned API supplant the dozen+ alternatives that could also be considered as candidates.[3] Sorry to be a sourpuss. Mike -- [1] http://mail.python.org/pipermail/xml-sig/2005-November/011248.html (Guido's very civil proposal and request for peer review) [2] http://mail.python.org/pipermail/xml-sig/2005-November/011252.html (this also summarizes the categories of software/approaches that people are taking to the general problem of working with XML Pythonically) [3] http://www.xml.com/pub/a/2004/10/13/py-xml.html (and there are at least 3 more databinding APIs that have come out since then) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 be beefed up to include the module name somehow, so that it works reliably (or at least more reliably than now). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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, *anyone* could use A().__private (but not > B().__private where B is a subclass of A). The intention is for > __private to have the right meaning only within the source code for > class A, but it should work even if type(self) is a subclass of A. (Or > even if it's unrelated to A, but that's a separate and weaker use > case.) Err.. you are of course right. My intent, however, was to use the static scope of the code, so let me redo my examples: class ObjClass(object): def foo(self): return self.__private becomes class ObjClass(object): def foo(self): return object.__getattribute__(self, '__dict__')[(ObjClass, '__private')] Hopefully that example does not get bogged down in poor pseudocode. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] should I really have to install Python before Ican build it ?
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 object files will have changed recently. If you then update with use-commit-times, some files might get changes so they are newer than they used to be, but still older than their object files. As a result, a rebuilt will fail to pick up the modified sources, potentially resulting in a broken interpreter (e.g. when a structure layout changed, yet this change didn't get compiled into all object files). CVS tried to tackle this problem with this approach: on update, touch the updated files so that they are all new, but have the same relative order in time as the commit times (e.g. spacing them apart by one second). Of course, with subversion changesets, this is futile: the generated files will be in the same changeset as the sources (e.g. Python-ast committed together with .asdl, configure committed together with configure.in). As it is the changeset which has the commit time, all these files have the *same* commit time. make(1) then decides "not newer". The common solution is to have an application-specific update procedure. For example, we might provide a make update target, which is defined as update: svn update sleep 1 test ! Python/Python-ast.c -nt Parser/Python.asdl && \ touch Python/Python-ast.c test ! Include/Python-ast.h -nt Parser/Python.asdl && \ touch Include/Python-ast.h test ! configure -nt configure.in && \ touch configure This, of course, assumes that the committers of these files always regenerated them properly before committing. See http://gcc.gnu.org/viewcvs/trunk/contrib/gcc_update?rev=106327&view=markup for gcc's solution to this problem; gcc developers are expected to invoke contrib/gcc_update, which will automatically spread the right time stamps after the update completed. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
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, potentially with copies for symbolic release names), but if you think that manual merging at each external release is doable/better/simpler, it's fine with me. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 much vetting -- it seems well established and well-known in the XML-SIG (it was listed in all the overviews of APIs). Finally, compared offerings based on e.g. 4thought (sp.?), ElementTree feels much more practical and hence, might I say it, "pythonic". --Guido On 12/12/05, Mike Brown <[EMAIL PROTECTED]> 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 Pythonic databinding+API for XML in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. I have nothing against > ElementTree, and would like to see more XML processing options in core, but it > seems to me like the XML-SIG is being deliberately left out of this process. > > Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had > been tinkering with.[1] I don't think anyone was really bold enough to tell > him what they really thought of it (other than that it is a lot like XIST), > but it was admirable that he put it up for peer review rather than just > dropping it into stdlib. Perhaps more importantly, it prompted some discussion > that more or less acknowledged that these kinds of APIs do seem to be the > future of XML in Python, and that we should be thinking about bringing some of > them into PyXML and, ultimately, stdlib. But the problem of how to choose from > the many options also became immediately apparent.[2] The discussion stalled, > but I think it should start up again, in the proper forum, rather than letting > the first-mentioned API supplant the dozen+ alternatives that could also be > considered as candidates.[3] > > Sorry to be a sourpuss. > > Mike > -- > > [1] http://mail.python.org/pipermail/xml-sig/2005-November/011248.html > (Guido's very civil proposal and request for peer review) > [2] http://mail.python.org/pipermail/xml-sig/2005-November/011252.html (this > also summarizes the categories of software/approaches that people are > taking to the general problem of working with XML Pythonically) > [3] http://www.xml.com/pub/a/2004/10/13/py-xml.html (and there are at least > 3 more databinding APIs that have come out since then) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 referenced. With your approach, if > > class A defined __private, *anyone* could use A().__private (but not > > B().__private where B is a subclass of A). The intention is for > > __private to have the right meaning only within the source code for > > class A, but it should work even if type(self) is a subclass of A. (Or > > even if it's unrelated to A, but that's a separate and weaker use > > case.) > > Err.. you are of course right. My intent, however, was to use the > static scope of the code, so let me redo my examples: > > class ObjClass(object): > def foo(self): > return self.__private > > becomes > > class ObjClass(object): > def foo(self): > return object.__getattribute__(self, '__dict__')[(ObjClass, > '__private')] > > Hopefully that example does not get bogged down in poor pseudocode. Unfortunately that fails one of the other requirements, which (at the time of implementation) was minimal impact on the rest of the interpreter. Since __private isn't limited to self, and attribute lookup doesn't always result in a dict lookup, this would require a complete overhaul of the getattr API, both at the C and at the Python level. But I guess you already said that when you said """Obviously it doesn't handle backwards compatibility, so it's more of a "if I could do it again.." suggestion.""" I think all has been said that can be said about this suggestion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 Pythonic databinding+API for XML in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. 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 you that someone will give an elementtree solution to it (and not just Fredrik). I don't know much about any other APIs, so I'm not going to try to claim it's the best API or anything, but it is the best of what seems to have any user visibility on the python-list. [1]http://mail.python.org/pipermail/python-dev/2005-June/054092.html [2]http://mail.python.org/pipermail/python-list/2005-December/314288.html STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 > you that someone will give an elementtree solution to it (and not just > Fredrik). I don't know much about any other APIs, so I'm not going to > try to claim it's the best API or anything, but it is the best of what > seems to have any user visibility on the python-list. It's difficult to establish precise numbers, but I would expect that most readers of xml-sig are well aware of how DOM and SAX work, perhaps even better than ElementTree. My main complaint about this was in the past that it is a Python-only solution, so people working in multiple languages cannot reuse their knowledge. It seems that this is irrelevant, as people don't work in multiple languages so much. I still think that Python should continue to provide standard APIs, for those that know how things are done in Java. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 Pythonic databinding+API for XML > in > stdlib seems to be a bit of a raised middle finger to those folks who have > worked hard on competing or differently-scoped APIs, each of which deserves a > bit more peer review than just a single nomination on python-dev, which seems > to be all it took to obtain a blessing for ElementTree. That is not true. 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. > I have nothing against > ElementTree, and would like to see more XML processing options in core, but > it > seems to me like the XML-SIG is being deliberately left out of this process. I think your impression is wrong (atleast on my part): I did not deliberately side-step xml-sig; it just didn't occur to me to have the discussion there also. I implicitly assumed most people on xml-sig would agree. > Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had > been tinkering with.[1] I don't think anyone was really bold enough to tell > him what they really thought of it (other than that it is a lot like XIST), > but it was admirable that he put it up for peer review rather than just > dropping it into stdlib. Again, your impression is somewhat wrong: Guido first submitted the code to the SF bug tracker; there I commented that he should discuss it on xml-sig. I based this recommendation on my view that any such library should see a wider audience first before being admitted to the core; this library of Guido had (to my knowledge) not been seen by a wider audience. This is unlike ElementTree, which had existed for quite some time, and collected a lot of community feedback. > But the problem of how to choose from > the many options also became immediately apparent.[2] The discussion stalled, > but I think it should start up again, in the proper forum, rather than > letting > the first-mentioned API supplant the dozen+ alternatives that could also be > considered as candidates.[3] Well, this is one of the big problems with XML: there are so many libraries to chose from, for so many different kinds of applications. It took me some time to understand what kind of application Guido's library is targetting - and such an analysis always ends up with saying "It is like X, but has Y instead". In this setting, how should we chose a library? In the last round, it was "let's believe in standards". I personally still believe in standards, but it appears that the Python community views them as too bloated. 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 happened for ElementTree, but I think it could happen for other packages, as well. If it is merely the lack of due process you are complaining about, and you agree with the result, then IMO nothing would need to be changed about the result. Discussing it post-factum on xml-sig might still be valuable. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 python-list, I can almost guarantee > > you that someone will give an elementtree solution to it (and not just > > Fredrik). I don't know much about any other APIs, so I'm not going to > > try to claim it's the best API or anything, but it is the best of what > > seems to have any user visibility on the python-list. > > It's difficult to establish precise numbers, but I would expect that > most readers of xml-sig are well aware of how DOM and SAX work, perhaps > even better than ElementTree. Sorry, I didn't mean to imply that DOM and SAX (though mainly DOM in my experience) solutions weren't also offered on the python-list. It's just that we already have DOM and SAX APIs in the stdlib. My point was mainly that elementtree was the xml module that I've seen most often cited on python-list that isn't already in the stdlib. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
> 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 direction of the discussion. FWIW, I've been hoping for this for a long time. In retrospect, CCing the XML list would have been nice but I don't think it would have changed the outcome. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
"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 happened for ElementTree, but I think it > could happen for other packages, as well. > > If it is merely the lack of due process you are complaining about, > and you agree with the result, then IMO nothing would need to be > changed about the result. Discussing it post-factum on xml-sig > might still be valuable. Thanks Martin and others for responding. I full agree that ElementTree has proven to be useful, popular, and stable, and probably no one would object to ElementTree being given the endorsement that is implicit in its being made a part of stdlib. The lack of due process, given that XML-SIG seems to exist largely to provide that very service for all things XML in Python, is indeed all I'm complaining about. I am happy that for once, there is momentum behind this sort of thing, and more power to you for that. My fears are just that 1. XML-SIG is being seen as either irrelevant or as an obstacle (perhaps due to the friction between Fredrik and Uche) and are thus being sidestepped, and 2. other libs that could/should be contenders (Amara and 4Suite are not in this list, by the way) are going to become further marginalized by virtue of the fact that people will say "well, we have ElementTree in stdlib already, why do we need (fill in the blank)?" I suppose the same kind of implicit endorsements were given to minidom and SAX, and that obviously hasn't prevented people from going out and using ElementTree, lxml, etc., so I don't know... I can't predict the future. I'd just feel better about it if everyone on XML-SIG, where people hang out because they have a definite interest in this kind of thing, knew what was going on. 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. Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 implementations of Unicode and regular expressions, and who can be reasonably be believed to be around to support and maintain the package for some time. I don't know who the "some authors" you mention are, but those are pretty tough credentials to match, as are the apparent popularity, Pythonicness, and performance of ElementTree. I find it rather hard to believe that there's another XML library that could have gotten through the approval process anywhere near as easily. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __builtin__ vs __builtins__
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 loose thoughts: - Having __builtins__ and __builtin__ both is clearly a bad idea. - Long ago, __builtin__ was just called builtin; I'm not sure I still agree with the reasoning that made me change it. After all, we don't have __sys__. But we *do* have __main__, and __builtin__ is special at least in the sense that modifying it has a global effect. (But then again, so does modifying sys.) I still think the case for __main__ is much stronger than for __builtin__ and wouldn't mind renaming the latter back to builtin. - Making __builtins__ always be a dict would simplify some code; but it really means that vars() must be hacked to suppress it in interactive mode; I really wouldn't like to see the output of vars() include the entire __builtins__ dict. - Another alternative might be to merge the __builtin__ and __builtins__ functionality (and call it __builtin__). This would slow down some stuff (always one extra indirection to get from __builtin__ to __builtin__.__dict__ which is where the built-ins are looked up) but that could be fixed by caching __builtin__.__dict__ in the C frame (I'm fine with the rule that you can't modify your own __builtin__; I think that rule already exists). - This is probably worth a few smart people mulling it over some more... Python-dev? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
>> 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 by >> increasing length, while dotted imports should be grouped roughly >> alphabetically. >> >> This seems too complex to me for PEP 8. Barry> Really? ISTR adopting this convention from Guido, but I'm not Barry> 100% sure about that. After having used it for several years Barry> now, I do really like this style, but I'm willing to leave the Barry> recommendation out of PEP 8. 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 modules/packages I can't explain why I do it that way. I guess it just satisfies some inner hobgoblin. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 accessors that just sets and Jim> gets an attribute with a slightly different name, that affords no Jim> more protection than if people were setting the attribute directly. Sure it does. Suppose I get an exception in my code because some bit of code somewhere broke my assumptions about the values an attribute could assume. If that attribute is only set by the object's own code, I can more easily debug it (stick in a print or an assert in the places where the attribute changes, etc). If some external bit of code does something like self.foo = Foo() ... self.foo.attr = None then later in Foo's code I have something like self.attr.callme() The first thing I need to do is figure out who stomped on self.attr. That can be time-consuming if I don't necessarily know where the stomping occurred. At work we use Python for very rapid development of trading applications. Today I think we made about a half-dozen micro releases fixing bugs and our traders tried each one immediately live. Much of the design is carried around in our heads or consists of a few equations scribbled on sheets of paper. As you might imagine, it's a very lively environment. Localizing attribute modifications is a very good thing for us, even if they are simply one-line set methods. Jim> If you don't want external code to change an attribute, don't Jim> expose it through a public API. I suppose "public" is subject to some interpretation. Just because I don't prefix an attribute with an underscore doesn't mean I've implicitly declared it public. I assume that people will familiarize themselves with the callable methods of an object and only use direct attribute access if I haven't provided the necessary methods. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 > >> follow non-dotted imports. Non-dotted imports should be grouped by > >> increasing length, while dotted imports should be grouped roughly > >> alphabetically. > >> This seems too complex to me for PEP 8. > > Barry> Really? ISTR adopting this convention from Guido, but I'm not > Barry> 100% sure about that. After having used it for several years > Barry> now, I do really like this style, but I'm willing to leave the > Barry> recommendation out of PEP 8. > > 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 modules/packages > > I can't explain why I do it that way. I guess it just satisfies some inner > hobgoblin. This is what I recommend too, and PEP 8 should recommend this. While I admit to a kind of secret enjoyment when I see the standard library module imports arranged by increasing length, I don't think that ought to be put in the PEP. (I remember once seeing a friend's books arranged by size on their shelves and finding it bizarre. You should have the same feeling when you see imports arranged that way.) A more rational approach would be to do them alphabetically. Putting the from...import ones last makes sense if only because it's not obvious where they fit in the alphabetization. Dotted non-from imports (e.g. import test.pystone) are rare enough that they don't deserve a special rule; if you want me to give a rule, I think they should be mixed in with the undotted ones, alphabetically. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 DOM and SAX. I couldn't tell you what they do, just that they were Too Hard (tm) for me to bother with XML in most situations. Then ElementTree came along. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[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 modules/packages This is already in PEP 8: - Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants. Imports should be grouped, with the order being 1. standard library imports 2. related major package imports (i.e. all email package imports next) 3. application specific imports You should put a blank line between each group of imports. I would suggest that it should also say that __all__ goes after imports. But otherwise it's all good; the Mailman style guide just goes into greater detail. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 people who are not xml-sig readers will likely > be put off by DOM and SAX. I couldn't tell you what they do, just that they > were Too Hard (tm) for me to bother with XML in most situations. Then > ElementTree came along. It seems pretty clear why DOM isn't Pythonic: it doesn't use Python's standard APIs for things that conceptually are "just" lists and dicts, or at least sequences and mappings. Also, the memory footprint is a bit outlandish. I don't think that SAX is unpythonic, but it's pretty low-level and mostly of use to people writing higher-level XML parsers (my parsexml module uses it). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 > > > > * Third-party modules/packages > > > > * Local modules/packages > > This is already in PEP 8: > > - Imports are always put at the top of the file, just after any >module comments and docstrings, and before module globals and >constants. Imports should be grouped, with the order being > >1. standard library imports >2. related major package imports (i.e. all email package imports next) >3. application specific imports Hm. I like Skip's list better; "related major package imports" is a bit vague and ambiguous. It seems to have been written before email became a standard library module; also it clearly meant to say "e.g." instead of "i.e.". >You should put a blank line between each group of imports. > > I would suggest that it should also say that __all__ goes after imports. +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
>> * 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 > >You should put a blank line between each group of imports. Does this pre-date the email package being included in the standard library? As it is, asterisk 2 and #2 don't appear to match. If that is the case, then perhaps something else should be chosen? =Tony.Meyer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
