Re: [Python-Dev] ast-objects branch created
Fredrik Lundh wrote: > if you check my original post, you'll find code for a new list helper > function, which would solve this in a convenient way. Yep - I thought I'd seen something like this, but couldn't find it (eventually found it by searching for Lundh ;). That's exactly what I was thinking of. However, I'm also thinking that it's worthwhile to have aliases that state that this is being done for memory management - hence the idea of _PyArena_ADD (and probably _PyArena_REMOVE, which would have to do an identity removal). I'm taking some leave over Christmas/New Year, so I might have a look at some other parts of the python codebase and see if there are other areas that might benefit from using lists as arenas like this. Tim Delaney ___ 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] imaplib module with IDLE implememted via threads
I hope you'll check this into SVN too? --Guido On 12/8/05, Piers Lauder <[EMAIL PROTECTED]> wrote: > If anyone needs the IMAP4 extension "IDLE", there is a copy of an enhanced > imaplib module available for download here: > > http://www.cs.usyd.edu.au/~piers/python/imaplib.html > > This is an IMAP4rev1 mail protocol client class using threads for parallel > operation. It is modified from the non-threaded version included in the > standard Python distributions, but presents (a superset of) the same API. > > I have named this version "imaplib2" as it uses threads to implememt > the necessary callbacks, and it doesn't seem necessary to burden the > orginal module with requiring threading. > > The module has been in production use for several months, and seems stable. > > Piers Lauder > > http://www.cs.usyd.edu.au/~piers/python/imaplib.html";>imaplib2 > IMAP4rev1 mail protocol client class using threads to implement the IDLE > extension. > (09-Dec-2005) > > > > -- > http://mail.python.org/mailman/listinfo/python-announce-list > > Support the Python Software Foundation: > http://www.python.org/psf/donations.html > -- --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
[Python-Dev] PEP 8 updates/clarifications
I was reading through PEP 8, and I think there's a few things that could be clarified or updated: Exception Names If a module defines a single exception raised for all sorts of conditions, it is generally called "error" or "Error". It seems that built-in (extension) modules use "error" (e.g. os.error), while Python modules generally use "Error" (e.g. xdrlib.Error). The trend seems to be toward CapWords exception names. To my knowledge, except for some outlying cases like os.error or socket.error (which are themselves old modules), CapWords are always used. The less obvious question I'm wondering about is if exceptions should have names that are relatively unique, or simply unique within their namespace. Built-in exceptions use fairly long names, but then they have no namespace. Looking at some newer stdlib modules: email and optparse use longer-named exceptions; csv uses csv.Error. Should "error" exceptions be discouraged? Would http.ServerError or http.HTTPServerError be considered better? Also, perhaps somewhere in the description of CapWords, how should they deal with acronyms? It seems like the convention is, to give an example, HTTPRedirect over HttpRedirect. I would appreciate an explicit preferred style. Global Variable Names (Let's hope that these variables are meant for use inside one module only.) The conventions are about the same as those for functions. Modules that are designed for use via "from M import *" should prefix their globals (and internal functions and classes) with an underscore to prevent exporting them. It seems like __all__ is a better technique than leading underscores. 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. 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. 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, and I haven't see class_ used. - Class-based exceptions are always preferred over string-based exceptions. Modules or packages should define their own domain-specific base exception class, which should be subclassed from the built-in Exception class. Always include a class docstring. E.g.: class MessageError(Exception): """Base class for errors in the email package.""" I think the language against string-based exceptions can be stronger. And this kind of implicitly indicates that longer names for exceptions are better; how long? Should they generally end in "Error"? -- 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
On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking wrote: > I was reading through PEP 8, and I think there's a few things that could > be clarified or updated: BTW, I'm willing to make updates to PEP 8, if we agree on what to change. > Exception Names > >If a module defines a single exception raised for all sorts of >conditions, it is generally called "error" or "Error". It seems >that built-in (extension) modules use "error" (e.g. os.error), >while Python modules generally use "Error" (e.g. xdrlib.Error). >The trend seems to be toward CapWords exception names. > > To my knowledge, except for some outlying cases like os.error or > socket.error (which are themselves old modules), CapWords are always > used. My own preference is away from "error" and toward CapWordsEndingInError. This is especially true now that we're recommending exceptions be classes. So really, the exception naming scheme is just the class naming scheme. > The less obvious question I'm wondering about is if exceptions > should have names that are relatively unique, or simply unique within > their namespace. It depends. If the exception class is intended to be imported with other symbols via import-* it needs to be unique of course. Otherwise I think it's fine that it simply be unique in its own namespace (though I tend to make them unique anyway). > Built-in exceptions use fairly long names, but then > they have no namespace. Looking at some newer stdlib modules: email and > optparse use longer-named exceptions; csv uses csv.Error. Should > "error" exceptions be discouraged? Would http.ServerError or > http.HTTPServerError be considered better? I think the latter are best, but "error" should definitely be out. csv.Error is okay as a base exception, though I think I'd opt for something longer. > Also, perhaps somewhere in the description of CapWords, how should they > deal with acronyms? It seems like the convention is, to give an > example, HTTPRedirect over HttpRedirect. I would appreciate an explicit > preferred style. My own preference here is for HTTPRedirect -- IOW capitalize all letters of the acronym. > Global Variable Names > >(Let's hope that these variables are meant for use inside one >module only.) The conventions are about the same as those for >functions. Modules that are designed for use via "from M import *" >should prefix their globals (and internal functions and classes) >with an underscore to prevent exporting them. > > It seems like __all__ is a better technique than leading underscores. Yep, good point. > 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. Again, good point. >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. Maybe the right thing to say is that non-public attributes should always start with at least one, and usually only one, underscore. If it is a private attribute of a class that is intended to be inherited from, and there is a likelihood that subclass attributes may conflict with this attribute's name, use two leading and no trailing underscores. > >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, and I haven't see class_ used. It does seem like the more popula
Re: [Python-Dev] PEP 8 updates/clarifications
Barry Warsaw wrote: > It does seem like the more popular convention is to use "cls" than > "class_". I'll admit the latter does look kind of ugly. Maybe the > suggestion should be to use either a trailing single underscore or an > abbreviation instead of a spelling corruption. We could then list some > common attribute names for common keywords, e.g. cls for class (what > else?). 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. Most other keywords don't come up in my experience. Suggestions for some non-keyword abbreviations might be useful, particularly for list, dict, and type, which come up a lot. I often use lst, d, and t, but I don't actually like any of them. I personally am comfortable reusing the variables dir, input, and vars, as I never use them in code. id, type, and file are somewhere in-between. I'll use the name of builtin as function arguments if it is meant to be used as a keyword argument, and the name is appropriate. I'm not really sure there's a useful conclusion we can come to on these. > Also, I have some additional guidelines adapted from the Mailman coding > standards: http://barry.warsaw.us/software/STYLEGUIDE.txt 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. In general, there should be at most one class per module, if the module contains class definitions. If it's a module of functions, that's fine, group them as common sense dictates. A class-containing module can also contain some helper functions, but it's best to keep these non-public (i.e. use a single leading underscore). This doesn't effect me that much as a library user, and I'd defer to whatever the package maintainer preferred in terms of file layout. - Right hanging comments are discouraged, in favor of preceding comments. E.g. foo = blarzigop(bar) # if you don't blarzigop it, it'll shlorp should be written as # if you don't blarzigop it, it'll shlorp foo = blarzigop(bar) I agree with this, but only as a loose suggestion. There's some sections on vertical whitespace and ^L. In these cases I'd defer to the package maintainer, like with file layout. The PEP has some suggestions, which I think are sufficient. - Unless internal quote characters would mess things up, the general rule is that single quotes should be used for short strings, double quotes for triple-quoted multi-line strings and docstrings. E.g. foo = 'a foo thing' warn = "Don't mess things up" notice = """Our three chief weapons are: - surprise - deception - an almost fanatical devotion to the pope """ This is more prescriptive than would be appropriate for PEP 8. It might be lightly suggested that double quotes signify "data", while single quotes signify "symbols". But I think that might be too subtle a distinction for the PEP. I personally don't care about this, and quotes for docstrings are already covered. Do not indent subsequent lines in a triple-quoted string; you should consider the opening quote to be the left margin. I don't understand exactly what you are saying here. Always use True and False instead of 1 and 0 for boolean values. I would agree. -- 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
Ian Bicking wrote: >(Let's hope that these variables are meant for use inside one >module only.) The conventions are about the same as those for >functions. Modules that are designed for use via "from M import *" >should prefix their globals (and internal functions and classes) >with an underscore to prevent exporting them. > > It seems like __all__ is a better technique than leading underscores. I think it should also go in (perhaps in the imports section) that __all__ comes after the imports, but before code. I thought this was in there already, because I know I've seen it documented elsewhere. -- 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
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. Cool. >Do not indent subsequent lines in a triple-quoted string; you should >consider the opening quote to be the left margin. > > I don't understand exactly what you are saying here. Just that I dislike: def foo(): """Here is a triple quoted, multiline string Some people write the continuation lines starting in this column, but I don't like that. """ -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
Barry Warsaw wrote: > Again, I'd say something like: Since your exceptions > will be classes, use the CapWord naming convention for > classes to name your exceptions. It is recommended > that your exception class end in the word "Error". Unless, of course, your exception is not an error (like the aforementioned HTTPRedirect). ;) Robert Brewer System Architect Amor Ministries [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
Barry Warsaw wrote: > On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking 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. > > Maybe the right thing to say is that non-public attributes should always > start with at least one, and usually only one, underscore. If it is a > private attribute of a class that is intended to be inherited from, and > there is a likelihood that subclass attributes may conflict with this > attribute's name, use two leading and no trailing underscores. I'd prefer language that discouraged double-underscores more since they can't prevent all name conflicts, e.g.: -- mod1.py -- class C(object): __x = 'mod1.C' @classmethod def getx(cls): return cls.__x - -- mod2.py -- import mod1 class C(mod1.C): __x = 'mod2.C' - py> import mod1, mod2 py> mod1.C.getx() 'mod1.C' py> mod2.C.getx() 'mod2.C' In this example, there should be two __x attributes, one for the superclass and one for the subclass. But since the name mangling doesn't include the module name, the two classes share the same __x attribute. Note that this problem can arise any time a class and its subclass share the same name. If you have to say something about double-underscores, I'd prefer something like: """ If you're concerned about name conflicts between a non-public attribute of a class and the non-public attributes of its subclasses, some of these can be prevented by using two leading and no trailing underscores. This will not work in all cases however, so sublcasses still cannot be completely ignorant of the non-public attributes of the superclass. """ 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] PEP 8 updates/clarifications
On Fri, 2005-12-09 at 16:23 -0800, Robert Brewer wrote: > Barry Warsaw wrote: > > Again, I'd say something like: Since your exceptions > > will be classes, use the CapWord naming convention for > > classes to name your exceptions. It is recommended > > that your exception class end in the word "Error". > > Unless, of course, your exception is not an error (like the > aforementioned HTTPRedirect). ;) Good point! -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
