Re: [Python-Dev] PEP 8 updates/clarifications
Ian Bicking wrote: > I was reading through PEP 8, and I think there's a few things that could > be clarified or updated: Good idea. ... > 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. > >Also decide whether your attributes should be private or not. >The difference between private and non-public is that the former >will never be useful for a derived class, while the latter might >be. Yes, you should design your classes with inheritence in >mind! > >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. 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'll note that, IMO: - If you have to worry about protecting attributes from subclasses, maybe should shouldn't be using inheritence. (This may be too bold a statement, but perhaps the first rule of inheritence should echo Fowler's first rule of Distribution: "don't inherit". :) Increasingly, I like to use inheritence only to avoid "boiler plate" implementations, such as default methods or data implementations that almost all implementations of some API are going to do the same way. On rare occasions, I find inheritence to be, sadly, unavoidable. I should also make a distinction between what I would call "private" and "public" inheritence. Private inheritence is between classes that are part of a single implementation unit or having a single implementor. With private inheritence, there is much less danger since the same people are responsible for the base classes and subclasses. It is public inheritence, where separate people maintain the base and subclasses where I think inhetitence should be used sparingly. Public inheritence causes too much coupling. ) - If you really have to use "public" inheritence, then consider naming conventions. I think ZODB's use of the _p_ variables has worked well for variables reserved for the base class attributes. (Although, I think if I could do it over, I would use _persistent_ rather than _p_.) I'll also note that, when providing "transpatent" facilities, like persistence or proxies whos functions are orthogonal to subclass or proxied-object functionality, I've come to prefer the use of external functions to access provided functionality. For example, rather than using something like: "someproxy._proxy_object" to get a proxied object from a proxy, I use "getProxiedObject(someproxy)". This allows the proxies themselves to remain as transparent as possible. I intend to take a similar approach with future versions of ZODB's persistence framework to avoid _p_ attributes and methods. >Non-public attributes should have a single leading underscore, >no trailing underscores. > >Public attributes should have no leading or trailing >underscores, unless they conflict with reserved words, in which >case, a single trailing underscore is preferrable to a leading >one, or a corrupted spelling, e.g. class_ rather than klass. >(This last point is a bit controversial; if you prefer klass >over class_ then just be consistent. :). > > With class methods, this has become a more important. Can PEP 8 include > a preferred name for the class argument to classmethods? I personally > prefer cls, there are some who use klass, a
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Martin v. Löwis wrote: > That's primarily for the author of the software to decide, at this > point. Fredrik Lundh would have to offer it for contribution first. I've already done that, as others have noted. Everything I release under a Python-compatible license is available for bundling with the python core. > I don't know what his current position is, but I think it is unlikely > that he will contribute it: in the past, he often indicated that he > a) dislikes the growth of the standard Python library Yes and no; replacing stale or incomplete parts with better libraries are usually a very good idea (the subprocess library is a recent example) But it's correct that I want the core library (the parts that lives in the python development trunk) to get smaller; that doesn't necessarily mean that a standard Python distribution should ship with a smaller library. > b) dislikes forking his own branch for inclusion in another package > (which would happen if he contributed one version for the > standard library, and would continue to maintain the code > outside of Python also). I want to avoid things like sgmlop (which was forked, and is currently shipped with broken bindings in a mostly unmaintained library). I also want to avoid problems for people who've come to rely on the deve- lopment and release approach I've used since I started shipping Python software in 1995. But if everyone is aware that this is a bundled piece of software, and the development and maintenance process is updated accordingly, that shouldn't be a problem. Here's a plan: - I check in an existing elementtree release in a separate location in the svn.python.org source tree. e.g. svn.python.org/kits/elementtree-1.2.6-20050316 this will make it clear that this is external software, and it also provides a reference point for tracking down local changes - we decide what elementtree modules to include, and where to place them, and copy them to the python trunk. (suggestion: either directly under xml, or under xml.etree) - I adapt the elementtree selftest so it runs under Python's test suite - I convert the pythondoc pages for the included modules to match the library reference format (someone will have to help with the markup here) - when new stable releases appear upstream, add to kits and copy relevant modules. update/tweak docs as necessary. - delegate incoming bug reports / patches to the upstream maintainer. and, optionally - sort out expat bundling issues, and include cElementTree as well (using the same approach as above). whaddya think? ___ Python-Dev mailing list Python-Dev@python.org 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> This seems outdated. My impression, in part from time spent Jim> working with the Python Labs guys, is that it is fine to have Jim> public data sttributes even for non-"record" types. In fact, I Jim> would argue that any time you would be tempted to provide Jim> "getFoo()" and "setFoo(v)" for some "private attribute _foo", it Jim> would be better to make it public. I certainly find "blah.foo" and Jim> "blah.foo = v" to be much better than "blah.getFoo()" and Jim> blah.setFoo(v)". Presuming the foo attribute provides some element of the API that you are willing to support forever. If it is just an implementation detail you should use accessor methods or properties. Skip ___ Python-Dev mailing list Python-Dev@python.org 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> This seems outdated. My impression, in part from time spent > Jim> working with the Python Labs guys, is that it is fine to have > Jim> public data sttributes even for non-"record" types. In fact, I > Jim> would argue that any time you would be tempted to provide > Jim> "getFoo()" and "setFoo(v)" for some "private attribute _foo", it > Jim> would be better to make it public. I certainly find "blah.foo" and > Jim> "blah.foo = v" to be much better than "blah.getFoo()" and > Jim> blah.setFoo(v)". > > Presuming the foo attribute provides some element of the API that you are > willing to support forever. If it is just an implementation detail you > should use accessor methods or properties. If foo is an implementation detail, then it shoudln't be exposed at all, even with accessors. Using attribute syntax makes no more of a commitment than accessor functions. The decision about wither to implement foo as a key in the instance dictionary *is* an implementation detail that can be hidden by a property. If the initial decision, following the rule of "do the simplest thing that works", is to use an instance dictionary item, then I wouldn't bother with a property until you change your mind. 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 Python-Dev@python.org 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: >>That's primarily for the author of the software to decide, at this >>point. Fredrik Lundh would have to offer it for contribution first. > > > I've already done that, as others have noted. Everything I release > under a Python-compatible license is available for bundling with the > python core. I see a difference here, though, between "offer for contribution" and "make available for bundling". To my knowledge, you never said (until now) "I would like to incorporate ElementTree into the Python CVS repository, and thus have it become part of future Python releases". > But it's correct that I want the core library (the parts that lives in the > python development trunk) to get smaller; that doesn't necessarily mean > that a standard Python distribution should ship with a smaller library. I know you said this before; I could never understand what you mean by that. I would always assume that we only ship what is in the source repository (plus, for the specific case of Windows binaries, what is documented in PCbuild/readme.txt). So how can the trunk get smaller, yet the distribution larger? > - I check in an existing elementtree release in a separate location in > the svn.python.org source tree. e.g. > > svn.python.org/kits/elementtree-1.2.6-20050316 > > this will make it clear that this is external software, and it also > provides a reference point for tracking down local changes Ah, so you want what CVS calls a "vendor branch": code that is externally maintained, and imported from time to time. Clearly, "local" (i.e. python.org) changes are one primary issue, so we should agree on an update process - I would personally prefer one that allows for merging (in the "svn merge" sense). The other issue is, of course, the question whose job it is to actually perform the updates. Would you expect to do that yourself, or would you expect somebody else does that? I'm still troubled that you keep saying that sgmlop "was forked". I had not been PyXML maintainer long enough to remember the precise history of things, but it was certainly the case that you could have updated it all the time - you still have write permission to the PyXML repository. > - we decide what elementtree modules to include, and where to place > them, and copy them to the python trunk. > > (suggestion: either directly under xml, or under xml.etree) Would there be a reason not to include the entire elementtree package? Either xml.etree, or xml.tree would be fine with me, -0 for putting it directly into xml. > - I adapt the elementtree selftest so it runs under Python's test suite Good. > - I convert the pythondoc pages for the included modules to match the > library reference format (someone will have to help with the markup > here) Would you then start using the tex sources as your primary sources, or would this conversion need to be done every time the package is updated? > - when new stable releases appear upstream, add to kits and copy > relevant modules. update/tweak docs as necessary. The "tweak docs" part sounds somewhat worrying. Of course, you could run "svn diff" on the old and new version, to see what doc strings have changed or appeared - but that might be quite some work. > - delegate incoming bug reports / patches to the upstream maintainer. Would it be sufficient to set you as the "Assigned To" in the SF tracker? I don't see specific bug reporting instructions on the elementtree page. > and, optionally > > - sort out expat bundling issues, and include cElementTree as well > (using the same approach as above). Not sure what this would be; we probably can look at it again when we are done with the first part. > whaddya think? Overall, sounds like a good plan. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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" == Jim Fulton <[EMAIL PROTECTED]> writes: Jim> The decision about wither to implement foo as a key in the instance Jim> dictionary *is* an implementation detail that can be hidden by a Jim> property. If it's not in the instance dictionary, where is it? Skip ___ Python-Dev mailing list Python-Dev@python.org 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" == Jim Fulton <[EMAIL PROTECTED]> writes: > > > Jim> The decision about wither to implement foo as a key in the instance > Jim> dictionary *is* an implementation detail that can be hidden by a > Jim> property. > > If it's not in the instance dictionary, where is it? It could be in a slot. It could be in the instance dictionary under another name. It could be in a subobject. It could be computed from other variables... (in a box, with a fox :) 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 Python-Dev@python.org 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: > >>That's primarily for the author of the software to decide, at this > >>point. Fredrik Lundh would have to offer it for contribution first. > > > > I've already done that, as others have noted. Everything I release > > under a Python-compatible license is available for bundling with the > > python core. > > I see a difference here, though, between "offer for contribution" > and "make available for bundling". To my knowledge, you never said > (until now) "I would like to incorporate ElementTree into the Python CVS > repository, and thus have it become part of future Python releases". Well, I'm offering you to bundle a well-defined version of ElementTree with Python. In practice, the plan I proposed means that we'll be shipping a *copy* of ET with Python, not that ET development will move over to python.org. At any time, it should be possible to say "Python release X.Y.Z includes ElementTree release A.B.C". (this doesn't rule out bug fixes in the trunk, of course, but work on new features should take place elsewhere) > So how can the trunk get smaller, yet the distribution larger? That's a separate issue; I'll have to get back to this at a later time. > > - I check in an existing elementtree release in a separate location in > > the svn.python.org source tree. e.g. > > > > svn.python.org/kits/elementtree-1.2.6-20050316 > > > > this will make it clear that this is external software, and it also > > provides a reference point for tracking down local changes > > Ah, so you want what CVS calls a "vendor branch": code that is > externally maintained, and imported from time to time. Exactly. But I'm not sure "branch" is really accurate here; it's more like "snapshot". Stable releases are added to the "vendor" tree, and relevant files are are then copied to the appropriate location in the release tree. > The other issue is, of course, the question whose job it is to actually > perform the updates. Would you expect to do that yourself, or would > you expect somebody else does that? I can deal with this. > I'm still troubled that you keep saying that sgmlop "was forked". I > had not been PyXML maintainer long enough to remember the precise > history of things, but it was certainly the case that you could have > updated it all the time - you still have write permission to the > PyXML repository. Perhaps, but there's a limit to how much downstream use you can expect anyone to monitor (cf. the Seigenthaler story). But I should point out that I don't think the forking was intentional; it just happened. > > - we decide what elementtree modules to include, and where to place > > them, and copy them to the python trunk. > > > > (suggestion: either directly under xml, or under xml.etree) > > Would there be a reason not to include the entire elementtree package? > Either xml.etree, or xml.tree would be fine with me, -0 for putting > it directly into xml. 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". I think that limiting this to ElementTree, ElementPath, and perhaps Element- Include would be a good start. > > - I convert the pythondoc pages for the included modules to match the > > library reference format (someone will have to help with the markup > > here) > > Would you then start using the tex sources as your primary sources, or > would this conversion need to be done every time the package is updated? The reference documentation is autogenerated from markup in the source file, so yes, some kind of conversion has to be done for each new release. > > - when new stable releases appear upstream, add to kits and copy > > relevant modules. update/tweak docs as necessary. > > The "tweak docs" part sounds somewhat worrying. Of course, you could run > "svn diff" on the old and new version, to see what doc strings have > changed or appeared - but that might be quite some work. Luckily, it can be partially automated. And ET doesn't change very quickly. > > - delegate incoming bug reports / patches to the upstream maintainer. > > Would it be sufficient to set you as the "Assigned To" in the SF > tracker? Sure. And maybe PEP 291 could be updated to cover both compatibility with older Python versions and other compatibility issues. > > and, optionally > > > > - sort out expat bundling issues, and include cElementTree as well > > (using the same approach as above). > > Not sure what this would be; we probably can look at it again when > we are done with the first part. The problem is that cElementTree is, by default, statically linked against its own (unmodified) copy of expat. The same applies to pyexpat. I think it would be better if there was only one copy of expat in (one way to do this would be to add an "function pointer table" to pyexpat that contains pointers to selected portions of the e
Re: [Python-Dev] PEP 8 updates/clarifications
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] 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. >>Also decide whether your attributes should be private or not. >>The difference between private and non-public is that the former >>will never be useful for a derived class, while the latter might >>be. Yes, you should design your classes with inheritence in >>mind! >> >>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. > > > 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, but I thought I'd let some other people suggest stronger language first. I prefer explicit name mangling for those cases where people justifiably use double underscores now, e.g., self._MyPackage_variable instead of self.__variable, which I think you also suggest below. Since it's all name mangling anyway, at least explicit is better than implicit, especially when it's something one could argue *should* look a little ugly. Perhaps all the non-public/private language should be switched to just "private" (one underscore) and "hidden from subclasses" (double underscore). I don't like calling __ private at all, because it's not what people coming from other languages think of as private. > I'll note that, IMO: > > - If you have to worry about protecting attributes from subclasses, > maybe should shouldn't be using inheritence. > > (This may be too bold a statement, but perhaps the first >rule of inheritence should echo Fowler's first rule of Distribution: >"don't inherit". :) > >Increasingly, I like to use inheritence only to avoid "boiler plate" >implementations, such as default methods or data implementations that >almost all implementations of some API are going to do the same way. > >On rare occasions, I find inheritence to be, sadly, unavoidable. > >I should also make a distinction between what I would call "private" >and "public" inheritence. Private inheritence is between classes >that are part of a single implementation unit or having a single >implementor. With private inheritence, the
[Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
Ian Bicking wrote: > Jim Fulton wrote: > ... >>>Also decide whether your attributes should be private or not. >>>The difference between private and non-public is that the former >>>will never be useful for a derived class, while the latter might >>>be. Yes, you should design your classes with inheritence in >>>mind! >>> >>>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. >> >> >> >> 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, but I thought I'd let some > other people suggest stronger language first. I prefer explicit name > mangling for those cases where people justifiably use double underscores > now, e.g., self._MyPackage_variable instead of self.__variable, which I > think you also suggest below. Since it's all name mangling anyway, at > least explicit is better than implicit, especially when it's something > one could argue *should* look a little ugly. Perhaps all the > non-public/private language should be switched to just "private" (one > underscore) and "hidden from subclasses" (double underscore). I don't > like calling __ private at all, because it's not what people coming from > other languages think of as private. 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.) 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 Python-Dev@python.org 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, Dec 11, 2005, Fredrik Lundh wrote: > > whaddya think? Huzzah! (Not that I've used ElementTree personally, but I think this conversation is a wonderful example of good Open Source discussion and development practice. Everyone involved deserves kudos, but particularly Fredrik for taking the ball and moving it forward.) -- 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 Python-Dev@python.org 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
Ian Bicking wrote: > 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] > > 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. Perhaps something like: "If you find yourself writing trivial accessor functions like: def getFoo(self): return self._foo def setFoo(self, v): self._foo = v Use attribute accessors instead. In the example above, just store foo in an attribute named "foo". If you need to store foo a different way later, you can use properties. On the other hand, if getting or setting a variable has other application- meaningful effects, then accessor methods might be better, or perhaps it would be best not to expose the attributes at all. " ... >> 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, Doesn't everyone? :) > but I thought I'd let some > other people suggest stronger language first. I prefer explicit name > mangling for those cases where people justifiably use double underscores > now, e.g., self._MyPackage_variable instead of self.__variable, which I > think you also suggest below. Since it's all name mangling anyway, at > least explicit is better than implicit, especially when it's something > one could argue *should* look a little ugly. Perhaps all the > non-public/private language should be switched to just "private" (one > underscore) and "hidden from subclasses" (double underscore). I don't > like calling __ private at all, because it's not what people coming from > other languages think of as private. I think we should strongly discourage it in the style guide. I think we should go even further, as I pointed out in another post. >> I'll note that, IMO: >> >> - If you have to worry about protecting attributes from subclasses, >> maybe should shouldn't be using inheritence. >> >> (This may be too bold a statement, but perhaps the first >>rule of inheritence should echo Fowler's first rule of Distribution: >>"don't inherit". :) >> >>Increasingly, I like to use inheritence only to avoid "boiler plate" >>implementations, such as default methods or data implementations that >>almost all implementations of some API are going to do the same way. >> >>On rare occasions, I find inheritence to be, sadly, unavoidable. >> >>I should also make a distinction between what I would call "private" >>a
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
On 12/11/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: [SNIP] > > - I check in an existing elementtree release in a separate location in > > the svn.python.org source tree. e.g. > > > > svn.python.org/kits/elementtree-1.2.6-20050316 > > > > this will make it clear that this is external software, and it also > > provides a reference point for tracking down local changes > > Ah, so you want what CVS calls a "vendor branch": code that is > externally maintained, and imported from time to time. > > Clearly, "local" (i.e. python.org) changes are one primary issue, > so we should agree on an update process - I would personally prefer > one that allows for merging (in the "svn merge" sense). > > The other issue is, of course, the question whose job it is to actually > perform the updates. Would you expect to do that yourself, or would > you expect somebody else does that? > 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. -Brett ___ Python-Dev mailing list Python-Dev@python.org 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: > Can we officially mark __private as a mistake. Perhaps: > > - Strongly discourage it in the style guide +1 > - Mark it in the language reference as a deprecated feature +1 > - Generate deprecation warnings when it is used? -0 I don't see that this gains us much. It will create annoyances for people who don't want to update old code, and since most folks have to search for the "feature" in the first place, if it's documented as deprecated, hopefully they won't use it. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org 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 Fulton wrote: > FWIW, as a general rule, I like using a single trailing underscore, > especially for keywords. It allows the use of meaningful and easy > to remember names. When the name of a variable should be "class" or > "for" or whatever, it's easy, as a Python programmer, to remember that > I need to add a trailing _. As a reformed abuser of single-character > variable names, I've come to really hate abbreviations. It's not only > easier to use unabbreviated names, it's easier to remember them when > reading code. (Note that ease of use hinges on editors that automate > typeing of repeated names.) FWIW, I believe scipy uses the trailing underscore to avoid shadowing certain builtins (type_, object_, str_, etc). I thought it was ugly when I first encountered the convention, but the concept is growing on me. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org 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
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. Skip ___ Python-Dev mailing list Python-Dev@python.org 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, Jim Fulton <[EMAIL PROTECTED]> wrote: > > Can we officially mark __private as a mistake. Perhaps: > > - Strongly discourage it in the style guide This may be acceptable. > - Mark it in the language reference as a deprecated feature > > - Generate deprecation warnings when it is used? >(This might be too much.) 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. n ___ Python-Dev mailing list Python-Dev@python.org 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] > 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. ___ Python-Dev mailing list Python-Dev@python.org 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
> 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. > > 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. 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. Raymond ___ Python-Dev mailing list Python-Dev@python.org 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: > On 12/11/05, Jim Fulton <[EMAIL PROTECTED]> wrote: >> Can we officially mark __private as a mistake. Perhaps: >> >> - Strongly discourage it in the style guide > > This may be acceptable. > >> - Mark it in the language reference as a deprecated feature >> >> - Generate deprecation warnings when it is used? >>(This might be too much.) > > 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. Keeping it for Py3K would be fine, if the mechanism was changed so that it actually worked right. That is, the mechanics would be such that any two concurrently existing classes would be guaranteed to mangle the names of their private variables differently - simply using the class name (as now) doesn't guarantee that when inheriting from a class in a different module and reusing the name. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org 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)
Interesting discussion. I've been thinking the opposite; that I should start using __attribute more often for "undocumented, private" member variables that are implementation details and clearly not part of the public interface. I'm curious what people have against it? On Sun, Dec 11, 2005 at 09:18:04PM -0500, Tim Peters wrote: | 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 ... | 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). About one year ago, I was updating a "shared module" that I wrote about 6-9 months prior. I added a member variable, and a few days later one of my applications started to mysteriously fail. This was a bugger to track down... name collision problem. I've since become very sensitive about "from xx import *" as well, for the same reason -- it tends to cause very nasty bugs when the module xx changes to introduce a few more methods, etc. Best, Clark ___ Python-Dev mailing list Python-Dev@python.org 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. In the future, aren't all classes going to become new-style? Was it going to wait until Py3k, or sometime sooner? - Josiah ___ Python-Dev mailing list Python-Dev@python.org 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, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Keeping it for Py3K would be fine, if the mechanism was changed so that it > actually worked right. That is, the mechanics would be such that any two > concurrently existing classes would be guaranteed to mangle the names of their > private variables differently - simply using the class name (as now) doesn't > guarantee that when inheriting from a class in a different module and reusing > the name. I know about the fear of accidental reuse of class names, but I don't find it a compelling argument. Python encourages shallow class hierarchies. It's easy to find all the base classes (look at __mro__). It's unlikely that a hierarchy refactoring will introduce a new name conflict after the fact. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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
>> Don't properties only work with new-style clsses? If so, this should >> probably be noted. Josiah> In the future, aren't all classes going to become new-style? Sure, but PEP 8 should be accurate for current Python. <0.5 wink> Josiah> Was it going to wait until Py3k, or sometime sooner? Dunno. Skip ___ Python-Dev mailing list Python-Dev@python.org 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
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. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org 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/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. 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). (That said, I'm all for exceptions becoming new-style in 2.5.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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)
Hi All, I think that a big problem is that there isn't an obvious way to say: self.a is part of the class interface, self.b isn't. Or: you can override self._c to do that. I believe we really need a way to do these things more clear. Currently we can use methods and properties, but even this is not clear enough in a inheritance tree. -- Até mais.. João Paulo da Silva LinuxUser #355914 ICQ: 265770691 | Jabber: [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Exception type on handling closed files
Look:
>>> 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.
--
João Paulo da Silva
LinuxUser #355914
ICQ: 265770691 | Jabber: [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
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, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Keeping it for Py3K would be fine, if the mechanism was changed so that it > > actually worked right. That is, the mechanics would be such that any two > > concurrently existing classes would be guaranteed to mangle the names of > > their > > private variables differently - simply using the class name (as now) doesn't > > guarantee that when inheriting from a class in a different module and > > reusing > > the name. > > 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 ... I don't use double-underscore name mangling, but if I did, it would clearly fail in this case. [1] I've concluded this after a variety of refactorings. But perhaps there is a better way... > 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) This would still allow manual mangling/unmangling, and it seems like it would cover most of the same-name different module concerns... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org 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/11/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > Overall, sounds like a good plan. > > Just say "go", and I'll start working on this. Are you still waiting for someone to say go? I'm not sure what responsible party should say it; if I'm not the right person, would the right person please say "go." Jeremy ___ Python-Dev mailing list Python-Dev@python.org 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: > Exactly. But I'm not sure "branch" is really accurate here; it's more like > "snapshot". Stable releases are added to the "vendor" tree, and relevant > files are are then copied to the appropriate location in the release tree. In practice, it will be a branch - unless you want to completely rule out modifications (which you didn't). >>The other issue is, of course, the question whose job it is to actually >>perform the updates. Would you expect to do that yourself, or would >>you expect somebody else does that? > > > I can deal with this. Sounds good. > 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 think that limiting this to ElementTree, ElementPath, and perhaps Element- > Include would be a good start. Ok. > And maybe PEP 291 could be updated to cover both compatibility with older > Python versions and other compatibility issues. So what would be the minimum Python version you keep compatibility with? > (one way to do this would be to add an "function pointer table" to pyexpat > that contains pointers to selected portions of the expat API, and then add > an indirection level to cElementTree) Ok, this sounds like a larger piece of work. > Just say "go", and I'll start working on this. Not sure if it is me who should say that; as nobody else has spoken against it: go. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
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."
___
Python-Dev mailing list
Python-Dev@python.org
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 > > And maybe PEP 291 could be updated to cover both compatibility with older > > Python versions and other compatibility issues. > > So what would be the minimum Python version you keep compatibility with? as Brett pointed out, the procedure to use for externally developed and bundled components should be described in PEP 2. but we need to list them somewhere too; PEP 291 is as good as any other place. > > Just say "go", and I'll start working on this. > > Not sure if it is me who should say that; as nobody else > has spoken against it: go. just one question: where do you want the "vendor" checkins ? I'm using a flat "kits" namespace in my own repositories, e.g. http://svn.python.org/kits/elementtree-1.2.6-20050316 http://svn.python.org/kits/jpeg-6b http://svn.python.org/kits/zlib-1.2.1 or, as commands for this specific case: $ wget http://effbot.org/downloads/elementtree-1.2.6-20050316.tar.gz $ tar xvfz elementtree-1.2.6-20050316.tar.gz $ svn import elementtree-1.2.6-20050316 svn+ssh://[EMAIL PROTECTED]/kits/elementtree-1.2.6-20050316 anyone has a better name? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
