Re: [Python-Dev] ElementTree in stdlib
Guido van Rossum wrote: > On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> 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). >> Having to define classes that conform to a certain API and registering >> instances of those classes as callbacks with the parser doesn't look >> that pythonic to me. An iterator API seems much more pythonic. > > Perhaps. Although the SAX API lets you leave a callback undefined if > you don't have a need to handle those events; that's a bit trickier to > do with an iterator. Changing the iterator to only generate the events you need requires passing information to the iterator. And when you do that you can just as well pass information about which function to call at which event. But IMHO the main difference isn't dispatching, but who's in control. > Also the different callbacks have different > signatures. True, I've always wondered why SAX uses a startelement callback which gets passed a complete attribute dictionary. IMHO for spam the following event sequence would be better: starttagbegin foo attributebegin bar text baz attributeend bar starttagend foo text spam endtag foo This would simplify signatures (always one string argument) and it would leave handling entity references inside attribute values to the application (or at least a higher level of the parser). > But since /F solved this for ElementTree I have to mostly agree with you. :-) Unfortunately there probably won't be that many parsers that support iterparse(). Most parsers existing outside the Python world use the callback model and turning a callback parser into a iterator parser requires support for incremental parsing (which has a certain latency) or stack switching tricks. >> Then again, pythonic is whatever you say that it is. ;) > > Not at all. I will argue but I will also take arguments from others. > Seriously. Bye, Walter Dörwald ___ 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] "xml" package in standard library
Fred L. Drake, Jr. wrote:
> On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote:
> > +1; it's what should have been done in the first place.
>
> If only I'd understood that when I added the xml/PyXML hack to the stdlib
> years ago. :-(
>
> Fixed now. I'll deal with the documentation in a few days; I actually expect
> to have some time.
I saw your checkin: wouldn't it be better to keep the xml directory
and xml/__init__.py instead of adding an xml.py module ?
The semantics of a package import are different than that
of a module import, so this may make a difference. I did the
same for the mx packages some years ago (when I moved everything
under the mx package) and then used code like this to make sure
that pickles continued to work as well as have them redirected
to the new package once they were stored again:
DateTime/__init__.py:
# Redirect all imports to the corresponding mx package
def _redirect(mx_subpackage):
global __path__
import os,mx
__path__ = [os.path.join(mx.__path__[0],mx_subpackage)]
_redirect('DateTime')
# Now load all important symbols
from mx.DateTime import *
from mx.DateTime import __version__
Note that in doing so, pickles will get redirected to the new
package. I'm not sure whether that's what you would want for
the xml/PyXML package, though: it would either direct them
to the xmlcore package (bypassing PyXML on systems where it's
installed) or direct them to the PyXML versions (bypassing
the xmlcore package and causing them only to be unpicklable
on systems with PyXML installed).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Dec 14 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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
Fredrik Lundh wrote: > M.-A. Lemburg wrote: > >> Some questions: >> >> * Are you going to contribute cElementTree as well ? > > yes, but there are some build issues we need to sort out first (both pyexpat > and cET link to their own copies of expat) Great ! > we also need to figure out how to import the bundled version; should it be > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > (which would then fallback on the Python version if cElementTree isn't > built) ? If the semantics are identical I'd prefer the latter approach of using the faster variant if possible. >> * What was the motivation to not include the whole ElementTree >> package ? > > this is a perfect time to get rid of some little-used stuff. if there's > enough user > demand, we can always add a few more modules before 2.5 goes out of the > door... Ok. >> * I'm missing the usual "Licensed to PSF under a Contributor Agreement." >> in the copyright notices of the files: >> >> http://www.python.org/psf/contrib.html >> >> I assume that you'll add these, right ? > > will fix. > >> * How should users that want to use the latest and greatest >> (more recent) distribution directly from your site go about in >> their apps ? Using from...as contructs ? > > from-import or import-as works fine Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 14 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Sharing expat instances
On Wednesday 14 December 2005 01:05, Fredrik Lundh wrote: > Michael McLay wrote: > > Avoiding imaginaary name collisions and putting cElementTree into the xml > > package > > there's nothing imaginary here -- cElementTree is an existing and quite > popular module, and will remain available as a separate distribution. > > it would be nice if people could install that kit also under 2.5 without > risking to mess up their Python installation. > > (another solution would of course to rule out use of cElementTree by > modules shipped with Python...) Renaming the cElementTree in the standard distribution to etree would elmiinate collisions with the existing cElementTree. A few other names to consider would be xmltree or xmlTree. Or, if the consensus is to keep it in the xml package, the name could still be shorted to calling it xml.tree. Average name lengths in the standard distribution are getting longer. In some cases the longer names are very helpful when browsing the module index. For instance, the function of SimpleXMLRPCServer is immediately apparent. To me, the purpose of a package named ElementTree isn't as apparent. While there is value in having meaningful names, there is also an advantage in having names short for commonly used tools. Imagine how painful it would be to type Operatingsystem instead of os. The name xmltree would be shorter and as descriptive as xml.cElementTree. The name etree would be shorter, but less descriptive. ___ 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] Website cruft
The download page http://www.python.org/download/ has a reference to "CVS Access" http://www.python.org/download/cvs.html that references a page with pointers to the old SourceForge CVS. Would someone please update these pages to reflect the move to 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] Sharing expat instances
Michael McLay wrote: > On Wednesday 14 December 2005 01:05, Fredrik Lundh wrote: > >>Michael McLay wrote: >> >>>Avoiding imaginaary name collisions and putting cElementTree into the xml >>>package >> >>there's nothing imaginary here -- cElementTree is an existing and quite >>popular module, and will remain available as a separate distribution. >> >>it would be nice if people could install that kit also under 2.5 without >>risking to mess up their Python installation. >> >>(another solution would of course to rule out use of cElementTree by >>modules shipped with Python...) > > > Renaming the cElementTree in the standard distribution to etree would > elmiinate collisions with the existing cElementTree. A few other names to > consider would be xmltree or xmlTree. Or, if the consensus is to keep it in > the xml package, the name could still be shorted to calling it xml.tree. > > Average name lengths in the standard distribution are getting longer. In some > cases the longer names are very helpful when browsing the module index. For > instance, the function of SimpleXMLRPCServer is immediately apparent. To me, > the purpose of a package named ElementTree isn't as apparent. While there is > value in having meaningful names, there is also an advantage in having names > short for commonly used tools. Imagine how painful it would be to type > Operatingsystem instead of os. The name xmltree would be shorter and as > descriptive as xml.cElementTree. The name etree would be shorter, but less > descriptive. Which reminds me, what about the idea of reducing certain packages (Carbon, dostutils and email come to mind) to just a single entry in the global module index and adding a first-level TOC at the beginning of that section of content? Even if we then have to call it the global package and module index! 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] Website cruft
Michael McLay wrote: > The download page http://www.python.org/download/ has a reference to "CVS > Access" http://www.python.org/download/cvs.html that references a page with > pointers to the old SourceForge CVS. Would someone please update these pages > to reflect the move to Subversion. > I've made a quick first-cut change to ensure that people don't start using the CVS repository by accident. Someone else might want to replace the FAQ reference, though really it's asking for trouble (as we are currently finding out) to duplicate this type of information. Arguably the FAQ should reference the main web. However, this change highlights the fact that the checkins mailing-list description at http://mail.python.org/mailman/listinfo/python-checkins is so out of date it warns that the CVS repository on cvs.python.org should no longer be used as we have now migrated to CVS on Sourceforge :-( Could someone fix that? 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] PEP 8 updates/clarifications, function/method style
Hello, PEP 8 for function and method names: - Function Names Function names should be lowercase, possibly with words separated by underscores to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. Method Names and Instance Variables The story is largely the same as with functions: in general, use lowercase with words separated by underscores as necessary to improve readability. - We need a clear style for function and method names now std lib uses "foo_bar" sometimes "foobar" and sometimes "fooBar". The use of lowercase with underscores is the default so the python std lib should use it in all modules. -> Python 3000 std lib Or should we switch to camelCase with lowercase first letter ? As most other Languages prefer this (Java, C#, C++, ...) bye by Wolfgang ___ 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] Sharing expat instances
On Wednesday 14 December 2005 09:51, Steve Holden wrote: > Which reminds me, what about the idea of reducing certain packages > (Carbon, dostutils and email come to mind) to just a single entry in the > global module index and adding a first-level TOC at the beginning of > that section of content? This echos a recent Doc-SIG post from Skip Montanaro that I've been meaning to reply to. I've now done that: http://mail.python.org/pipermail/doc-sig/2005-December/003453.html -Fred -- Fred L. Drake, Jr. ___ 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] Website cruft
On Wednesday 14 December 2005 10:12, Steve Holden wrote: > However, this change highlights the fact that the checkins mailing-list > description at > >http://mail.python.org/mailman/listinfo/python-checkins > > is so out of date it warns that the CVS repository on cvs.python.org > should no longer be used as we have now migrated to CVS on Sourceforge :-( Try it now. -Fred -- Fred L. Drake, Jr. ___ 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, function/method style
[Wolfgang] > Or should we switch to camelCase with lowercase first letter ? > As most other Languages prefer this (Java, C#, C++, ...) They also use curly braces instead of indentation to indicate block structure. Maybe we should switch to that too. -- 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] ElementTree in stdlib
Guido van Rossum wrote: > On 12/13/05, Walter Dörwald <[EMAIL PROTECTED]> wrote: > > Having to define classes that conform to a certain API and registering > > instances of those classes as callbacks with the parser doesn't look > > that pythonic to me. An iterator API seems much more pythonic. > > Perhaps. Although the SAX API lets you leave a callback undefined if > you don't have a need to handle those events; that's a bit trickier to > do with an iterator. Well, suppose you want to dump the text of a document. for e in iterparse(filename): if e.isText(): out.write(e.data) Not tricky. > > Also the different callbacks have different signatures. True. With SAX I always have to look up the signatures. The iterator yields Node-like objects in document order. I don't have to remember signatures. But the biggest advantage of an iterator-based API would be: when you hit an element, you can easily pass control to a function that knows how to parse that particular element. parsePlay() can call parseAct(), which can call parseScene(). To do anything like that with SAX, you have to write a bunch of dispatch code. -j ___ 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, function/method style
Hi, Michael Hoffman wrote: > [Wolfgang] > >> Or should we switch to camelCase with lowercase first letter ? >> As most other Languages prefer this (Java, C#, C++, ...) > > They also use curly braces instead of indentation to indicate block > structure. Maybe we should switch to that too. Or BEGIN, END style. :-) bye by Wolfgang ___ 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/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > we also need to figure out how to import the bundled version; should it be > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > > (which would then fallback on the Python version if cElementTree isn't > > built) ? > > If the semantics are identical I'd prefer the latter approach > of using the faster variant if possible. That is my preference, too. 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] Sharing expat instances
Phillip J. Eby wrote. > >my current idea is to > > > > 1. include it under a different name (_elementtree.so) > > > > 2. add a cElementTree.py under xml.etree, which simply does > > > > from _elementtree import * > > > >does anyone have a better idea ? > > I was under the impression that simply installing cElementTree.so in the > relevant package directory would work; this is what the distutils do for > extensions with a package name. it would work, of course, but the core puts all the binaries in a separate directory (lib-dynload on unix, DLLs on windows, etc). do we really want to put executables in other locations ? ___ 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] Website cruft
Fred L. Drake, Jr. wrote: > On Wednesday 14 December 2005 10:12, Steve Holden wrote: > > However, this change highlights the fact that the checkins mailing-list > > description at > > > >http://mail.python.org/mailman/listinfo/python-checkins > > > > is so out of date it warns that the CVS repository on cvs.python.org > > should no longer be used as we have now migrated to CVS on Sourceforge :-( > > Try it now. > Much better! 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] PEP 8 updates/clarifications, function/method style
Wolfgang writes: > We need a clear style for function and method names > now std lib uses "foo_bar" sometimes "foobar" > and sometimes "fooBar". Personally, I prefer "fooBar". But I try not to use it in python code... I try to always use "foo_bar" because that's what PEP 8 says. I believe recall the conversation that preceded putting that into PEP 8, and the impetus for that particular decision was input from non-native English speakers (particularly those not coming from a European alphabet) that it was far easier to read with underscore separation rather than capWords. -- Michael Chermside ___ 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] "xml" package in standard library
Fred L. Drake, Jr. wrote: > On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote: > > +1; it's what should have been done in the first place. > > If only I'd understood that when I added the xml/PyXML hack to the stdlib > years ago. :-( > > Fixed now. I'll deal with the documentation in a few days; I actually expect > to have some time. looks like you broken installation (the libinstall target hasn't been updated); from comp.lang.python: [EMAIL PROTECTED]:~$ python Python 2.5a0 (#1, Dec 14 2005, 14:11:55) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as ET Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/xml.py", line 20, in import xmlcore ImportError: No module named xmlcore >>> (works under trunk, but not after installation) you also broke my subversion: $ svn up svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt || cstr' failed. Aborted (but that's probably not your fault). has anyone seen this error? any ideas on how to fix 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] "xml" package in standard library
On Wednesday 14 December 2005 12:13, Fredrik Lundh wrote: > looks like you broken installation (the libinstall target hasn't been > updated); from comp.lang.python: Ouch! Thanks for fixing this. > you also broke my subversion: > > $ svn up > svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt > || cstr' failed. Aborted I've never seen anything like that from Subversion before. -Fred -- Fred L. Drake, Jr. ___ 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
M.-A. Lemburg wrote: >>we also need to figure out how to import the bundled version; should it be >>cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree >>(which would then fallback on the Python version if cElementTree isn't >>built) ? > > > If the semantics are identical I'd prefer the latter approach > of using the faster variant if possible. I have myself in the past used or overridden non-public methods of ElementTree, which I'm sure wouldn't work with cElementTree. While I'd also prefer automatic fallback, it would be nice if there was additionally an explicit path to each version. -- 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] "xml" package in standard library
> you also broke my subversion: > > $ svn up > svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt || > cstr' failed. > Aborted > > (but that's probably not your fault). > > has anyone seen this error? any ideas on how to fix it? google indicated that people had seen this when directories were removed from the repository, so I removed Lib/xml by hand, and that fixed 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] ElementTree in stdlib
On Wednesday 14 December 2005 12:39, Ian Bicking wrote: > I have myself in the past used or overridden non-public methods of > ElementTree, which I'm sure wouldn't work with cElementTree. While I'd > also prefer automatic fallback, it would be nice if there was > additionally an explicit path to each version. I think the whole PyXML v. the standard library dabacle has taught us that there should *always* be an explicit path to each version of a module or package. -Fred -- Fred L. Drake, Jr. ___ 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] Sharing expat instances
Fredrik Lundh wrote: > Phillip J. Eby wrote. > >>> my current idea is to >>> >>> 1. include it under a different name (_elementtree.so) >>> 2. add a cElementTree.py under xml.etree, which simply does >>> from _elementtree import * >>> >>> does anyone have a better idea ? >> I was under the impression that simply installing cElementTree.so in the >> relevant package directory would work; this is what the distutils do for >> extensions with a package name. > > it would work, of course, but the core puts all the binaries in a separate > directory (lib-dynload on unix, DLLs on windows, etc). One good reason for this is that the .pyd's or .so's cannot necessarily be used from zip files, so it is nice to keep those binaries out of the package directory (packages can then easily go in a Python25.zip). My (admittedly weak) understanding of how packages work is that all parts of a package should lie off the same node of the PYTHONPATH. --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] ElementTree in stdlib
Jeremy Hylton wrote: > On 12/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > > we also need to figure out how to import the bundled version; should it be > > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > > > (which would then fallback on the Python version if cElementTree isn't > > > built) ? > > > > If the semantics are identical I'd prefer the latter approach > > of using the faster variant if possible. > > That is my preference, too. it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the modules are 99% compatible, but there's always someone that relies on that last % (which is a result of ET being written in Python). at this point, I think it's more important to guarantee that changing "elementtree" to "xml.etree" will always work under Python 2.5 [1], than to have a new set of potential subtle incompatibility issues. but I have changed my mind before... 1) except for users that need a newer version, of course. ___ 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] Sharing expat instances
On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote: > One good reason for this is that the .pyd's or .so's cannot necessarily > be used from zip files When you say "cannot necessarily", are the situations where they can be imported from zip files? I thought the answer to that was always "no". -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, function/method style
On 12/14/05, Wolfgang <[EMAIL PROTECTED]> wrote: > Hello, > > PEP 8 for function and method names: > - > Function Names > >Function names should be lowercase, possibly with words separated by >underscores to improve readability. mixedCase is allowed only in >contexts where that's already the prevailing style (e.g. threading.py), >to retain backwards compatibility. > > Method Names and Instance Variables > >The story is largely the same as with functions: in general, use >lowercase with words separated by underscores as necessary to improve >readability. > - > > We need a clear style for function and method names > now std lib uses "foo_bar" sometimes "foobar" > and sometimes "fooBar". Actually this (function, method and ivar names) is such a contentious issue that I think the style guide should explicitly allow all two/three styles and recommend to be consistent within a class, module or package. I want to be adamant about module, package and class names though: module/package names should be short all-lowercase without underscores; class names should be CapWords. I'd like to fix this for StringIO.py, UserDict.py etc. > The use of lowercase with underscores is the default so > the python std lib should use it in all modules. Too late. I don't think the diversity is all that distracting. I'd be much more concerned about spelling MethodNames (as unfortunately the Google style guide requires). -- --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] Sharing expat instances
Barry Warsaw wrote: > On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote: >> One good reason for this is that the .pyd's or .so's cannot necessarily >> be used from zip files > When you say "cannot necessarily", are the situations where they can be > imported from zip files? I thought the answer to that was always "no". I thought so too, but was not sure enough to state it that way. --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] "xml" package in standard library
Fred L. Drake, Jr. wrote: > - Pickles containing classes from the xml package will break if we're not > really careful. But I think they're pretty fragile now. > > I'll be glad to make these or similar changes if there's concensus on this. I don't agree with the change. You just broke source compatibility between the core package and PyXML. 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] Sharing expat instances
Scott David Daniels wrote: > > > One good reason for this is that the .pyd's or .so's cannot necessarily > > > be used from zip files > > > > When you say "cannot necessarily", are the situations where they can be > > imported from zip files? I thought the answer to that was always "no". > > I thought so too, but was not sure enough to state it that way. you could of course add them to the zip file, and automagically extract them before you start importing things. ___ 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] Linked lists
Hello again. As I'm digging deeper into LISP and Scheme these days, I was wondering, is there a good compelling reason why in Python we don't have a native singly-linked and doubly-linked list types? That is, reasons other than - "you can get by without it" (sometimes I *want* lists), or - "you can use tuples to emulate lists" (only in limited contexts, and it's not pretty), or - "you can code your own in Python" (not as efficient as native types) Maybe I'm slapping an old horse here, but searching the archives I could not find some relevant controversy, that would--I hoped--include a final word from the BDFL. If I had "real" lists I would use them more often, where I now use Python lists (vectors, really). (Although In LISP I have the reverse problem, I tend to use lists sometimes where I should use arrays--I think I need to grow up). Anyway, why not provide good lists or cons-cell classes in C? ___ 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] Sharing expat instances
On Wed, 2005-12-14 at 20:21 +0100, Fredrik Lundh wrote: > you could of course add them to the zip file, and automagically extract > them before you start importing things. Sure (although we don't). I wonder if this is useful functionality for the core. -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, function/method style
Guido writes: > Actually this (function, method and ivar names) is such a contentious > issue that I think the style guide should explicitly allow all > two/three styles and recommend to be consistent within a class, module > or package. Hurray! Now I can go back to using capWords for functions, methods, and variables! Guido writes: > Too late. I don't think the diversity is all that distracting. I disagree. One of the things that Java got very much right was to specify, from the very beginning, what the preferred conventions are for naming conventions. (Packages in lowercase, Classes in CapWords, methods and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.) The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes). Of course, a really good IDE might make this irrelevent by popping up the correct option as I type... but the IDEs I use for Python don't even know the types of my variables, so they don't do this for me. Anyhow... I don't think we can change it now, but I _do_ believe that the lack of such conventions is a bit distracting. (Not enough to make me prefer Java, of course!) -- Michael Chermside ___ 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] Sharing expat instances
At 08:21 PM 12/14/2005 +0100, Fredrik Lundh wrote: >Scott David Daniels wrote: > > > > > One good reason for this is that the .pyd's or .so's cannot necessarily > > > > be used from zip files > > > > > > When you say "cannot necessarily", are the situations where they can be > > > imported from zip files? I thought the answer to that was always "no". > > > > I thought so too, but was not sure enough to state it that way. > >you could of course add them to the zip file, and automagically extract >them before you start importing things. The runtime system for Python Eggs does this; extraction is to a PYTHON_EGG_CACHE directory. See e.g.: http://peak.telecommunity.com/DevCenter/PkgResources#resource-extraction The egg builder writes a .py file alongside the .pyd or .so in the .egg file that contains something like: def __bootstrap__(): global __bootstrap__, __loader__, __file__ import sys, pkg_resources, imp __file__ = pkg_resources.resource_filename(__name__,'foobar.so') del __bootstrap__, __loader__ imp.load_dynamic(__name__,__file__) __bootstrap__() So, when you import from the zipfile, the .py file gets loaded (since zipimport doesn't support .pyd/.so/etc. imports directly) and then it reloads the module from the extracted file. The other magic there is just to keep any of the special names from staying behind in the reloaded module. ___ 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] Linked lists
On Wed, Dec 14, 2005, Martin Blais wrote: > > As I'm digging deeper into LISP and Scheme these days, I was > wondering, is there a good compelling reason why in Python we don't > have a native singly-linked and doubly-linked list types? How about taking this dicussion to comp.lang.python and providing more examples of use cases. I think you should probably be able to throw together a PEP for a library without too much trouble, but it'll take a lot of convincing to make the push for a builtin type. As with sets and Decimal, plan on starting with a pure-Python module; finding one already in the wild that people use would be even better. -- 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] Sharing expat instances
At 09:56 AM 12/14/2005 -0800, Scott David Daniels wrote: >My (admittedly weak) understanding of how packages work is that all >parts of a package should lie off the same node of the PYTHONPATH. This isn't a requirement; packages have a __path__ attribute which can include more than one directory. The 'pkgutil' module (added in Python 2.3) even has a convenient way to merge parts of a package that are in separate directories. ___ 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
/F writes: > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the > modules are 99% compatible, but there's always someone that relies > on that last % (which is a result of ET being written in Python). Yes! > at this point, I think it's more important to guarantee that changing > "elementtree" to "xml.etree" will always work under Python 2.5 [1], > than to have a new set of potential subtle incompatibility issues. but > I have changed my mind before... Consider changing it again. I fear that if ElementTree is part of the core without cElementTree, then a meme will spread which says (and PLEASE don't quote this!) "ElementTree has a great API, but it's just too slow for real work." We already know that Python is particularly susceptable to "too slow" memes, even invalid ones. I think the best all-around solution is to include cElementTree and use it wherever possible unless the user specially imports the pure-python version. Perhaps importing "xml.etree" gets you cElementTree unless that isn't compiled on your platform, but you can import "xml.pure_python.etree" or something like that to get the pure Python version if you really want it. -- Michael Chermside ___ 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] Sharing expat instances
At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote: >Phillip J. Eby wrote. > > > >my current idea is to > > > > > > 1. include it under a different name (_elementtree.so) > > > > > > 2. add a cElementTree.py under xml.etree, which simply does > > > > > > from _elementtree import * > > > > > >does anyone have a better idea ? > > > > I was under the impression that simply installing cElementTree.so in the > > relevant package directory would work; this is what the distutils do for > > extensions with a package name. > >it would work, of course, but the core puts all the binaries in a separate >directory (lib-dynload on unix, DLLs on windows, etc). > >do we really want to put executables in other locations ? I don't know. I can see that the split makes sense for prefix/exec-prefix distinctions, but then again, the disutils will install an entire distribution in exec-prefix if it contains "impure" parts, so that's certainly an option here. On the other hand, it's not clear to me *why* the lib-dynload/DLLs directories exist, since it seems to me that that's what exec-prefix is for. Perhaps somebody can explain why lib-dynload/ and DLLs/ exist? Perhaps some platforms have to add these directories to some godforsaken environment variables like LD_LIBRARY_PATH or something? ___ 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 Tue, 2005-12-13 at 07:26 -0500, Jim Fulton wrote: > I'd add somewhere: "If in doubt, chose non-public. You can always change your > mind later." Added. > > > 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. > > A useful term might be "subclass API". Decide which non-public attributes > are part of the subclass API. Excellent suggestion, thanks. I like the term "subclass API". Added. > > - 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. > > Personally, I'd actively discourage use of trivial accessors. Simple > attribute access is not only "fine", IMO, but it is much better than > trivial accessors. This is an important point, IMO, because, in my > experience, the vast majority of accessors *are* trivial. I've changed "fine" to "best". -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 Tue, 2005-12-13 at 12:00 -0500, Phillip J. Eby wrote: > In any case, the algorithms involved are near-trivial; the most complex > piece is the processing of complex version specifications like > "CherryPy>=2.1.0,!=2.1.1-rc2,<2.2a" into a series of version intervals. > > The only outstanding feature request for the dependency resolution > algorithm is supporting optional or replaceable dependencies such as "we > need either scipy *or* Numeric". You might look at Gentoo's portage system and its package dependencies for a model here. I think they have a notion of "virtual" packages, such as "mta" or "X" which various specific packages such as sendmail, postfix, X11 or xorg can fulfill. -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, function/method style
On Wed, 2005-12-14 at 09:08 -0800, Michael Chermside wrote: > Wolfgang writes: > > We need a clear style for function and method names > > now std lib uses "foo_bar" sometimes "foobar" > > and sometimes "fooBar". > > Personally, I prefer "fooBar". But I try not to use it in python > code... I try to always use "foo_bar" because that's what PEP 8 says. > > I believe recall the conversation that preceded putting that into > PEP 8, and the impetus for that particular decision was input from > non-native English speakers (particularly those not coming from a > European alphabet) that it was far easier to read with underscore > separation rather than capWords. Correct, which is one reason I feel strongly that we should keep the current recommendation of lower_case_words. -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, function/method style
On Wed, 2005-12-14 at 10:17 -0800, Guido van Rossum wrote: > Actually this (function, method and ivar names) is such a contentious > issue that I think the style guide should explicitly allow all > two/three styles and recommend to be consistent within a class, module > or package. My own feeling is that the PEP should keep its current recommendation of lower_case_words. It allows for the other styles under the "be internally consistent" guideline. My current rewrite (to be checked in soon), has this also to say: mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. It could be argued that this guideline should be relaxed to give lower_case_words and mixedCase equal footing. I'd disagree, but will make that change to the PEP if there's strong consensus in favor of taking that position. > I want to be adamant about module, package and class names though: > module/package names should be short all-lowercase without > underscores; class names should be CapWords. I'd like to fix this for > StringIO.py, UserDict.py etc. Absolutely. > > The use of lowercase with underscores is the default so > > the python std lib should use it in all modules. > > Too late. I don't think the diversity is all that distracting. I'd be > much more concerned about spelling MethodNames (as unfortunately the > Google style guide requires). That's right out. :) -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] Linked lists
Martin Blais wrote: > As I'm digging deeper into LISP and Scheme these days, I was > wondering, is there a good compelling reason why in Python we don't > have a native singly-linked and doubly-linked list types? As you seem to be asking for the historical reason: because nobody ever wanted it so badly to do anything about it. I would personally consider it a waste of energy to implement such a thing with so little use, given the alternatives. 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] Linked lists
On 12/14/05, Martin Blais <[EMAIL PROTECTED]> wrote: > Hello again. > > As I'm digging deeper into LISP and Scheme these days, I was > wondering, is there a good compelling reason why in Python we don't > have a native singly-linked and doubly-linked list types? > > That is, reasons other than > - "you can get by without it" (sometimes I *want* lists), or > - "you can use tuples to emulate lists" (only in limited contexts, and > it's not pretty), or > - "you can code your own in Python" (not as efficient as native types) > > Maybe I'm slapping an old horse here, but searching the archives I > could not find some relevant controversy, that would--I hoped--include > a final word from the BDFL. > > If I had "real" lists I would use them more often, where I now use > Python lists (vectors, really). (Although In LISP I have the reverse > problem, I tend to use lists sometimes where I should use arrays--I > think I need to grow up). > > Anyway, why not provide good lists or cons-cell classes in C? So here's a word from the BDFL. :) I'm curious about the use cases you have in mind. Python's philosophy about (built-in) data types, inherited from ABC, is to offer a few powerful clearly distinct choices rather than lots of alternatives with overlapping usages. This reduces the time it takes to choose a data type and reduces the risk of picking the wrong type. (You seem to be indicating that this is indeed what's happening to you in Lisp. :-) In this philosophy, there is a real cost associated with offering more data types which isn't necessarily offset by the advantage. -- --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
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > /F writes: > > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the > > modules are 99% compatible, but there's always someone that relies > > on that last % (which is a result of ET being written in Python). > > Yes! > > > at this point, I think it's more important to guarantee that changing > > "elementtree" to "xml.etree" will always work under Python 2.5 [1], > > than to have a new set of potential subtle incompatibility issues. but > > I have changed my mind before... > > Consider changing it again. I fear that if ElementTree is part of the > core without cElementTree, then a meme will spread which says (and > PLEASE don't quote this!) "ElementTree has a great API, but it's > just too slow for real work." > > We already know that Python is particularly susceptable to "too slow" > memes, even invalid ones. I think the best all-around solution is to > include cElementTree and use it wherever possible unless the user > specially imports the pure-python version. Perhaps importing > "xml.etree" gets you cElementTree unless that isn't compiled on your > platform, but you can import "xml.pure_python.etree" or something > like that to get the pure Python version if you really want it. > I don't think this will necessarily happen. You are assuming people are going to know there is a faster way than ET written in Python. I think most people consider stuff in the stdlib good and fast enough for most uses and when they want faster they roll their own. And since I have always voted on the side of "have a C version only if someone wants to maintain a C version but don't have both C and Python", I say /F should include which ever he wants, but I personally vote for only one version. So if /F is going to continue to maintain cElementTree and since it is already written I say use that and just get the speed boost and eliminate the isssue of people relying on that 1% semantic difference between the Python and C version. -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] PEP 8 updates/clarifications
I've pushed out a revised PEP 8 http://www.python.org/peps/pep-0008.html Please review and comment. Thanks everyone for providing an excellent discussion. Hopefully I have captured our current collective recommendations. I've also tried to simplify the text, while making it (somewhat) more prescriptive. -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, function/method style
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > Guido writes: > > Actually this (function, method and ivar names) is such a contentious > > issue that I think the style guide should explicitly allow all > > two/three styles and recommend to be consistent within a class, module > > or package. > > Hurray! Now I can go back to using capWords for functions, methods, and > variables! > > Guido writes: > > Too late. I don't think the diversity is all that distracting. > > I disagree. One of the things that Java got very much right was to > specify, from the very beginning, what the preferred conventions are > for naming conventions. (Packages in lowercase, Classes in CapWords, > methods and variables in lowerCapWords, constants optionally in > ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: > SimpleHTTPServer.) > > The conventions are nearly universally followed, and as a result in > java I always know how to spell things. I never have to remember > whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() > and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain > convention as part of the language... this prevents breaking the rules > on purpose (eg: wrapping a library from another language, or using > an object with attributes to represent an XML node with child nodes). I agree completely with this. I might remember the name of a method, but I don't always remember the capping and the possible use of underscores. Consistency would be really nice. I am not saying we should rename everything (at least not until Python 3 =), but at least we can make sure new stuff that is not preexisting can use a consistent naming scheme. And as for it being contentious, I say Guido can pronounce on this. We are all grown-ups and can learn to name things in a certain way to give our memories an easier time. =) -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] Sharing expat instances
Phillip J. Eby wrote: > At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote: >> Phillip J. Eby wrote. >> my current idea is to 1. include it under a different name (_elementtree.so) 2. add a cElementTree.py under xml.etree, which simply does from _elementtree import * does anyone have a better idea ? >>> I was under the impression that simply installing cElementTree.so in the >>> relevant package directory would work; this is what the distutils do for >>> extensions with a package name. >> it would work, of course, but the core puts all the binaries in a separate >> directory (lib-dynload on unix, DLLs on windows, etc). >> >> do we really want to put executables in other locations ? > > I don't know. I can see that the split makes sense for prefix/exec-prefix > distinctions, but then again, the disutils will install an entire > distribution in exec-prefix if it contains "impure" parts, so that's > certainly an option here. > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > directories exist, since it seems to me that that's what exec-prefix is > for. Perhaps somebody can explain why lib-dynload/ and DLLs/ > exist? Perhaps some platforms have to add these directories to some > godforsaken environment variables like LD_LIBRARY_PATH or something? What I believe I understand about /.pyd / .so / .dll / shared libraries is that they are meant to allow several processes to map the same disk backing store to the same same virtual address for more than a single process. If the .egg strategy is followed, I expect that either the file shared is in a user(or even process)-specific location or there is a shared folder that is writable by many processes from which executable code can be run. The one solution reduces sharing, the other violates security principles. --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] ElementTree in stdlib
At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote: >On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > > We already know that Python is particularly susceptable to "too slow" > > memes, even invalid ones. I think the best all-around solution is to > > include cElementTree and use it wherever possible unless the user > > specially imports the pure-python version. Perhaps importing > > "xml.etree" gets you cElementTree unless that isn't compiled on your > > platform, but you can import "xml.pure_python.etree" or something > > like that to get the pure Python version if you really want it. > >I don't think this will necessarily happen. You are assuming people >are going to know there is a faster way than ET written in Python. Actually, he's said that the C version should be the default, with the Python version only used if you have subclassing needs that can't be met by the C version. >And since I have always voted on the side of "have a C version only if >someone wants to maintain a C version but don't have both C and >Python", I say /F should include which ever he wants, but I personally >vote for only one version. So if /F is going to continue to maintain >cElementTree and since it is already written I say use that and just >get the speed boost and eliminate the isssue of people relying on that >1% semantic difference between the Python and C version. Having a Python version available for Jython, PyPy, etc., is a good idea; Michael's proposal lets us have your cake (C version be the default) and eat it too (have the pure Python available for other platforms and for explicit use by subclassers. ___ 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
Michael Chermside wrote: > ... a meme will spread which says (and PLEASE don't quote this!) > "ElementTree has a great API, but it's just too slow for real work." +1 DNQOTW :-) (Do Not Quote Of The Week) --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] ElementTree in stdlib
On 12/14/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote: > >On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > > > We already know that Python is particularly susceptable to "too slow" > > > memes, even invalid ones. I think the best all-around solution is to > > > include cElementTree and use it wherever possible unless the user > > > specially imports the pure-python version. Perhaps importing > > > "xml.etree" gets you cElementTree unless that isn't compiled on your > > > platform, but you can import "xml.pure_python.etree" or something > > > like that to get the pure Python version if you really want it. > > > >I don't think this will necessarily happen. You are assuming people > >are going to know there is a faster way than ET written in Python. > > Actually, he's said that the C version should be the default, with the > Python version only used if you have subclassing needs that can't be met by > the C version. > Ah, misread it. > > >And since I have always voted on the side of "have a C version only if > >someone wants to maintain a C version but don't have both C and > >Python", I say /F should include which ever he wants, but I personally > >vote for only one version. So if /F is going to continue to maintain > >cElementTree and since it is already written I say use that and just > >get the speed boost and eliminate the isssue of people relying on that > >1% semantic difference between the Python and C version. > > Having a Python version available for Jython, PyPy, etc., is a good idea; > Michael's proposal lets us have your cake (C version be the default) and > eat it too (have the pure Python available for other platforms and for > explicit use by subclassers. > Good point. My preference then would be to not directly expose it but have it there for the other distributions to use with an added note to make sure to not use anyt edge semantics that might crop up from the different versions since they might be using the Python version. -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] PEP 8 updates/clarifications
> I've pushed out a revised PEP 8 > > http://www.python.org/peps/pep-0008.html > > Please review and comment. Why does PEP 8 continually refer to one particular editor (Emacs)? (There are even parts in the form "x is better because it works better in Emacs", when surely it's actually the case that x is better because it's better in the majority of editors.) ISTM that the PEP would be much simpler if it was completely editor- agnostic, but perhaps there's some historical reasoning I'm not aware of? =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
Re: [Python-Dev] PEP 8 updates/clarifications
On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > I've pushed out a revised PEP 8 > > http://www.python.org/peps/pep-0008.html > > Please review and comment. Thanks everyone for providing an excellent > discussion. Hopefully I have captured our current collective > recommendations. I've also tried to simplify the text, while making it > (somewhat) more prescriptive. Thanks, Barry! I've made another pass and added a couple more tweaks, hopefully non-controversial. -- --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/14/05, Tony Meyer <[EMAIL PROTECTED]> wrote: > > I've pushed out a revised PEP 8 > > > > http://www.python.org/peps/pep-0008.html > > > > Please review and comment. > > Why does PEP 8 continually refer to one particular editor (Emacs)? > (There are even parts in the form "x is better because it works > better in Emacs", when surely it's actually the case that x is better > because it's better in the majority of editors.) > > ISTM that the PEP would be much simpler if it was completely editor- > agnostic, but perhaps there's some historical reasoning I'm not aware > of? Historically many Python developers use Emacs. Barry & I still do. I think the best way to avoid editor wars is to pick one editor and stick with 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 Wed, 2005-12-14 at 14:10 -0800, Guido van Rossum wrote: > Thanks, Barry! I've made another pass and added a couple more tweaks, > hopefully non-controversial. Cool thanks Guido. I fixed a couple of small typos. One question: you made the suggestion that a blank line separate the last line in a tqs docstring from its closing tqs. I'm wondering why that is. Note that python-mode now (or shall we say with the fix I just made ;) properly fills paragraphs in those strings, even if there is no blank line before the closing tqs line. -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 Wed, 2005-12-14 at 14:14 -0800, Guido van Rossum wrote: > Historically many Python developers use Emacs. Barry & I still do. > > I think the best way to avoid editor wars is to pick one editor and > stick with it. :-) Dinosaurs rule! :) -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] Sharing expat instances
Py2exe manages to load .pyd files and dlls from zip. Apparently they have written an alternate dll loader that does not need the file to be on the file system. This is used for single file apps. I don't know if it is possible to write a portable Unix equivalent for .so files. -Chris P.S. I think it is standard practice to do an introduction on first post to pydev. I have been lurking on the Dev list for about a year. I recently completed my masters thesis which used Python extensively. I am helping to promote the adoption of Python for various tasks at my place of work. On Wed, Dec 14, 2005 at 01:15:49PM -0500, Barry Warsaw wrote: > On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote: > > > One good reason for this is that the .pyd's or .so's cannot necessarily > > be used from zip files > > When you say "cannot necessarily", are the situations where they can be > imported from zip files? I thought the answer to that was always "no". > > -Barry > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lambacck%40computer.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: > I've pushed out a revised PEP 8 > > http://www.python.org/peps/pep-0008.html > > Please review and comment. Thanks everyone for providing an excellent > discussion. Hopefully I have captured our current collective > recommendations. I've also tried to simplify the text, while making it > (somewhat) more prescriptive. The only thing I strongly disagree with is the promotion of javaNaming to equal footing with python_naming. We can look forward to future programs that look like this: class Something: def __init__(self, i_care): self.mem_a = pkga.uses_python_naming() self.mem_b = pkgb.usesJavaNaming() if i_care: self.this_looks(self.mem_b.reallyCrap()) It gets worse if you subclass from modules using different conventions in your own code. Ugly code. - Dave -- http://www.object-craft.com.au ___ 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)
[Steven Bethard] >import ellogon.utils as utils >import ellogon.features.relations as features_relations >import ellogon.chunking as chunking >import ml.classifiers as _ml_classifiers >import ml.data as _ml_data >The only two-letter one was ElementTree, and the vast majority were >unabbreviated, though as you can see, some of them drop one of the >items in the import chain. Do you find imports like the above >problematic? No, all of the above seems very clear. What creates us problems is the flurry of two-letter abbreviations for imported modules. >FWIW, I don't like importing objects from modules directly for the >same reason that when I write Java now, I always use an explicit >"this" for instance variables. When I see a name which isn't local to >a function, I want to have some idea where it came from... Reasonable, and clearer. Yet, in some cases, the reuse of a few prefixes all over the code may develop being more polluting than helping. Good taste may be better than too inflexible principles. One may search the source with an editor and quickly find the proper import. _Given_, of course, it is not of the form "from HELL import *". :-) But this gets a bit far from the original topic. Let's drop the matter here as not being much more of general interest, or else, let's switch to private email. Keep happy, all. -- François Pinard http://pinard.progiciels-bpi.ca ___ 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/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Wed, 2005-12-14 at 14:10 -0800, Guido van Rossum wrote: > > > Thanks, Barry! I've made another pass and added a couple more tweaks, > > hopefully non-controversial. > > Cool thanks Guido. I fixed a couple of small typos. > > One question: you made the suggestion that a blank line separate the > last line in a tqs docstring from its closing tqs. I'm wondering why > that is. Note that python-mode now (or shall we say with the fix I just > made ;) properly fills paragraphs in those strings, even if there is no > blank line before the closing tqs line. Primarily because I didn't have that fix when I wrote it, and I think many people don't have it. And did you fix it in IDLE too? I can make up another reason too, but this is the main one. (I think it also visually separates the doc string paragraphs from the code better.) -- --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] Add timeout to subprocess.py?
A frequent requirement seems to be to run a subprocess but give up if it takes more than N seconds. I suppose you can hack this using the poll() method and time.sleep(), but perhaps a more direct approach can be added to the subprocess module? This should directly support reading output / stderr until the time limit is up as well. Any takers? -- --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] Sharing expat instances
On 12/14/05, Chris Lambacher <[EMAIL PROTECTED]> wrote:
> Py2exe manages to load .pyd files and dlls from zip. Apparently they have
> written an alternate dll loader that does not need the file to be on the file
> system. This is used for single file apps.
>
> I don't know if it is possible to write a portable Unix equivalent for .so
> files.
If you mean, portable to all dialects of Unix and Unix-like systems, I
am pretty confident in answering "no". But it might be possible to
support many such systems, e.g. by exploiting the DMG format ("disk
image" within a single file), native to MacOSX, that can be used in
Linux (and I believe in some other Unix variants) by mounting the file
as a "loop device" (there's all sort of niggling issues, such as the
need to be root to do so, but perhaps there might be workarounds...).
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] Deprecate __ private (was Re: PEP 8 updates/clarifications)
[Phillip J. Eby] >At 09:53 AM 12/13/2005 -0500, François Pinard wrote: >>Everybody here agrees that this style makes the code much less legible. >I hope you mean, "here at your company or organization", as I disagree. :) Yes, of course! Sorry for the ambiguity. -- François Pinard http://pinard.progiciels-bpi.ca ___ 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
Dave Cole wrote: > Barry Warsaw wrote: > >>I've pushed out a revised PEP 8 >> >>http://www.python.org/peps/pep-0008.html >> >>Please review and comment. Thanks everyone for providing an excellent >>discussion. Hopefully I have captured our current collective >>recommendations. I've also tried to simplify the text, while making it >>(somewhat) more prescriptive. > > > The only thing I strongly disagree with is the promotion of javaNaming > to equal footing with python_naming. We can look forward to future > programs that look like this: I don't see this suggestion...? Here's what seems to be the current text on the matter: Function Names Function names should be lowercase, with words separated by underscores as necessary to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. Method Names and Instance Variables Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability. I know Guido in a later thread seems to be going back on that, which would be disappointing to me. I think it's reasonable to loosen the phrasing a bit -- it's nearly always better to stay consistent with a package than follow PEP 8 on this point. The current text merely implies that it's acceptable to follow previous convention, not preferable. Many people who come to Python *want* to follow whatever the prevalent and preferred style is, but it's not immediately clear what that is. So I think PEP 8 should as often as possible at least indicate preference. Which it pretty much does now, so we should leave well enough alone ;) -- 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] Sharing expat instances
On Dec 14, 2005, at 5:31 PM, Alex Martelli wrote:
> On 12/14/05, Chris Lambacher <[EMAIL PROTECTED]> wrote:
>> Py2exe manages to load .pyd files and dlls from zip. Apparently
>> they have
>> written an alternate dll loader that does not need the file to be
>> on the file
>> system. This is used for single file apps.
>>
>> I don't know if it is possible to write a portable Unix equivalent
>> for .so
>> files.
>
> If you mean, portable to all dialects of Unix and Unix-like systems, I
> am pretty confident in answering "no". But it might be possible to
> support many such systems, e.g. by exploiting the DMG format ("disk
> image" within a single file), native to MacOSX, that can be used in
> Linux (and I believe in some other Unix variants) by mounting the file
> as a "loop device" (there's all sort of niggling issues, such as the
> need to be root to do so, but perhaps there might be workarounds...).
For Mac OS X 10.4+, you don't even have to bother. The dynamic
linker finally implements the function that lets you load a code
bundle straight from RAM:
extern NSObjectFileImageReturnCode NSCreateObjectFileImageFromMemory(
const void *address,
size_t size,
NSObjectFileImage *objectFileImage);
Of course, you could always just use temporary files or a cache
somewhere.
-bob
___
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] Sharing expat instances
Scott David Daniels wrote: > Phillip J. Eby wrote: > >>At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote: >> >>>Phillip J. Eby wrote. >>> >>> >my current idea is to > >1. include it under a different name (_elementtree.so) > >2. add a cElementTree.py under xml.etree, which simply does > >from _elementtree import * > >does anyone have a better idea ? I was under the impression that simply installing cElementTree.so in the relevant package directory would work; this is what the distutils do for extensions with a package name. >>> >>>it would work, of course, but the core puts all the binaries in a separate >>>directory (lib-dynload on unix, DLLs on windows, etc). >>> >>>do we really want to put executables in other locations ? >> >>I don't know. I can see that the split makes sense for prefix/exec-prefix >>distinctions, but then again, the disutils will install an entire >>distribution in exec-prefix if it contains "impure" parts, so that's >>certainly an option here. >> >>On the other hand, it's not clear to me *why* the lib-dynload/DLLs >>directories exist, since it seems to me that that's what exec-prefix is >>for. Perhaps somebody can explain why lib-dynload/ and DLLs/ >>exist? Perhaps some platforms have to add these directories to some >>godforsaken environment variables like LD_LIBRARY_PATH or something? > > > What I believe I understand about /.pyd / .so / .dll / shared libraries > is that they are meant to allow several processes to map the same disk > backing store to the same same virtual address for more than a single > process. If the .egg strategy is followed, I expect that either the > file shared is in a user(or even process)-specific location or there > is a shared folder that is writable by many processes from which > executable code can be run. The one solution reduces sharing, the > other violates security principles. > When extension modules are to be run from zip files it's difficult to avoid a reduction in sharing anyway - without some kind of additional mechanism there's no guarantee that two modules with the same filename are actually the same library anyway, and there's every likelihood that over time several zipped applications will be released containing different versions of the same extension module. In that case each app would want the version that came with it anyway, no? There are slightly different requirements for packaged distribution than for the standard interpreter, which I assume can always rely on having an installed module available as a file (though this might not be desirable in the future). 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] PEP 8 updates/clarifications
[Barry Warsaw] >I've pushed out a revised PEP 8 >http://www.python.org/peps/pep-0008.html >Please review and comment. Hi, Barry, and people. Allow me a few remarks, nothing essential. * Within "Naming Conventions", "Prescriptive: Naming Conventions", "Module names", we read: Modules should have short, lowercase names, without underscores. I would like that PEP 0008 add some cement around this idea that common English words, properly spelled, which are likely to be user variable names, be avoided whenever reasonable. * Within "Code lay-out", "Blank Lines", we read: Separate top-level function and class definitions with two blank lines. In a running English text (like in this message!), it might make sense, but after tried for a long while both a single line and two lines between top-level elements in Python programs, I did not see that two lines gives so much more legibility to be worth a prescription. One white line is enough in my opinion, and I wonder if "with two blank lines" could not be replaced by "at least one blank line". * Within "Programming Recommendations", writers are suggested to prefer str methods of the string module, as well as a few others more recent additions (recent in the history of Python). I wonder if this would not be a good place to suggest more of such. These come to mind: - Replacing "apply(func, args)" with "func(*args)". - Replacing "for line in file.readlines():" with "for line in file:". - Replacing "for key in dict.keys():" with "for key in dict:". - Replacing "if has_key(dict, key):" with "if key in dict:". and there might be others. Deprecated functions could be listed, too. -- François Pinard http://pinard.progiciels-bpi.ca ___ 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: > I've pushed out a revised PEP 8 > > http://www.python.org/peps/pep-0008.html Just two little things... Use 4 spaces per indentation level. This is the default for Emacs's python-mode. For really old code that you don't want to mess up, you can continue to use 8-space tabs. Emacs python-mode auto-detects the prevailing indentation level used in a file and sets its indentation parameters accordingly. I think the reference to Emacs here is unneeded. "Use 4 spaces per indentation level" is sufficient instruction on its own. ...Latin-1 should only be used when a comment or docstring needs to mention an author name that requires Latin-1; otherwise, using \x escapes is the preferred way to include non-ASCII data in string literals. An exception is made for those files that are part of the test suite for the code implementing PEP 263. I think the reference to PEP 263 tests is kind of obvious. -- 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] Add timeout to subprocess.py?
I've got a recipe in the Python cookbook which adds async subprocess support[1], which can be wrapped to support handling IO to/from the subprocess until a time limit occurs. - Josiah [1] - http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Guido van Rossum <[EMAIL PROTECTED]> wrote: > > A frequent requirement seems to be to run a subprocess but give up if > it takes more than N seconds. I suppose you can hack this using the > poll() method and time.sleep(), but perhaps a more direct approach can > be added to the subprocess module? This should directly support > reading output / stderr until the time limit is up as well. Any > takers? > > -- > --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/jcarlson%40uci.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] PEP 8 updates/clarifications
On 12/14/05, François Pinard <[EMAIL PROTECTED]> wrote: > I would like that PEP 0008 add some cement around this idea that common > English words, properly spelled, which are likely to be user variable > names, be avoided whenever reasonable. I don't think that's a reasonable rule. There are too many English words and the rule as formulated is too vague. Also, module/package names can only conflict with *global* user variable names. > * Within "Code lay-out", "Blank Lines", we read: > > Separate top-level function and class definitions with two blank lines. > > In a running English text (like in this message!), it might make sense, > but after tried for a long while both a single line and two lines > between top-level elements in Python programs, I did not see that two > lines gives so much more legibility to be worth a prescription. One > white line is enough in my opinion, and I wonder if "with two blank > lines" could not be replaced by "at least one blank line". Here I agree, especially bewteen top-level functions. You *might* want to separate classes with two blank lines if the methods within them are separated by single blank lines, but even there it's probably overkill. > > * Within "Programming Recommendations", writers are suggested to prefer > str methods of the string module, as well as a few others more recent > additions (recent in the history of Python). I wonder if this would not > be a good place to suggest more of such. These come to mind: > > - Replacing "apply(func, args)" with "func(*args)". > - Replacing "for line in file.readlines():" with "for line in file:". > - Replacing "for key in dict.keys():" with "for key in dict:". > - Replacing "if has_key(dict, key):" with "if key in dict:". > > and there might be others. +; however see below. > Deprecated functions could be listed, too. I think that's more proper for a separate PEP -- the style guide shouldn't have to be updated each time something else is deprecated. -- --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
[Barry] >>> I've pushed out a revised PEP 8 >>> >>> http://www.python.org/peps/pep-0008.html >>> >>> Please review and comment. [Tony Meyer] >> Why does PEP 8 continually refer to one particular editor (Emacs)? [Guido] > I think the best way to avoid editor wars is to pick one editor and > stick with it. :-) I wasn't suggesting an editor war, or replacing or adding to the Emacs references. My point (echoed in part by Ian Bicking) was that the Emacs references don't seem to add anything worthwhile to the PEP (it's the style guide, not the "Python in Emacs" guide), and if the aim is to simplify the text then this would be another way to do that. =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
Re: [Python-Dev] PEP 8 updates/clarifications
[Guido van Rossum] >On 12/14/05, François Pinard <[EMAIL PROTECTED]> wrote: >> I would like that PEP 0008 add some cement around this idea that common >> English words, properly spelled, which are likely to be user variable >> names, be avoided whenever reasonable. >I don't think that's a reasonable rule. There are too many English >words and the rule as formulated is too vague. Also, module/package >names can only conflict with *global* user variable names. It would be hard making a precise formulation for it indeed. Yet, the danger exists and would be more easily avoided if stated in PEP 0008. A good exemple is the "textwrap" module, for which the name is very acceptable to me, while "text" (which was suggested here on python-dev) would have been a bit nightmarish in my own code: I used to do a lot of text processing, and I selected "text" as the common name for strings under consideration, exactly because "string" was already taken! ½ :-) I do not understand your statement that module/package names can only conflict with *global* user variable names. Local variables hide global variables with same names, and imported modules are often global variables. So, using a local name in a function prevents accessing a module by the same name (defined either locally or globally). >> - Replacing "apply(func, args)" with "func(*args)". >> - Replacing "for line in file.readlines():" with "for line in file:". >> - Replacing "for key in dict.keys():" with "for key in dict:". >> - Replacing "if has_key(dict, key):" with "if key in dict:". >> Deprecated functions could be listed, too. >I think that's more proper for a separate PEP -- the style guide >shouldn't have to be updated each time something else is deprecated. I was more thinking of things like xreadlines, having replacements suggested in the style guile already (given you accept the second "Replacing" above). Not every single deprecated function, of course, but only the prominent ones. On the other hand, xreadlines is not even prominent. :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] Sharing expat instances
At 02:19 AM 12/15/2005 +, Steve Holden wrote: >Scott David Daniels wrote: > > Phillip J. Eby wrote: > > > >>At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote: > >> > >>>Phillip J. Eby wrote. > >>> > >>> > >my current idea is to > > > >1. include it under a different name (_elementtree.so) > > > >2. add a cElementTree.py under xml.etree, which simply does > > > >from _elementtree import * > > > >does anyone have a better idea ? > > I was under the impression that simply installing cElementTree.so in the > relevant package directory would work; this is what the distutils do for > extensions with a package name. > >>> > >>>it would work, of course, but the core puts all the binaries in a separate > >>>directory (lib-dynload on unix, DLLs on windows, etc). > >>> > >>>do we really want to put executables in other locations ? > >> > >>I don't know. I can see that the split makes sense for prefix/exec-prefix > >>distinctions, but then again, the disutils will install an entire > >>distribution in exec-prefix if it contains "impure" parts, so that's > >>certainly an option here. > >> > >>On the other hand, it's not clear to me *why* the lib-dynload/DLLs > >>directories exist, since it seems to me that that's what exec-prefix is > >>for. Perhaps somebody can explain why lib-dynload/ and DLLs/ > >>exist? Perhaps some platforms have to add these directories to some > >>godforsaken environment variables like LD_LIBRARY_PATH or something? > > > > > > What I believe I understand about /.pyd / .so / .dll / shared libraries > > is that they are meant to allow several processes to map the same disk > > backing store to the same same virtual address for more than a single > > process. If the .egg strategy is followed, I expect that either the > > file shared is in a user(or even process)-specific location or there > > is a shared folder that is writable by many processes from which > > executable code can be run. The one solution reduces sharing, the > > other violates security principles. Actually, the discussion wasn't about eggs, but about the placement of C extensions in standard, "normal" package directories. The Python installation uses only top-level C extensions and puts them in separate directories. The question outstanding is, why? Since there already exists exec-prefix for architecture-specific files, and the distutils installs an entire package to either prefix or exec-prefix depending upon its "purity". I suspect that the reason is legacy: originally packages didn't exist, and then even when they did, the distutils didn't. Most of the stdlib is developed in-place without benefit of the distutils, so it makes sense historically that the modules would be where they are, especially since the distutils need some of those modules to run. However, this alone wouldn't be a reason not to build and install ElementTree using the distutils. ___ 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 Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: > The only thing I strongly disagree with is the promotion of javaNaming > to equal footing with python_naming. Actually, they're not on equal footing atm. I happen to agree with you though. -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 12/14/05, François Pinard <[EMAIL PROTECTED]> wrote: > I do not understand your statement that module/package names can only > conflict with *global* user variable names. Local variables hide global > variables with same names, and imported modules are often global > variables. So, using a local name in a function prevents accessing > a module by the same name (defined either locally or globally). In a module where you import 'foo' I don't understand why you would name a local variable 'foo'. So I'm not sure how the conflict would arise. Perhaps more to the point, I would expect that non-words are just as likely to accidentally conflict with variable or function names, your personal habits notwithstanding. -- --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/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: > > > The only thing I strongly disagree with is the promotion of javaNaming > > to equal footing with python_naming. > > Actually, they're not on equal footing atm. I happen to agree with you > though. It doesn't matter. Many large projects are adopting the camelCase convention, either by choice or by accident. I did a brief review of Zope 3 and Chandler, and while neither is consistent, camelCase prevails (Chandler also has a lot of CapWords method names, wihch suggests they didn't get this from Java -- maybe from 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] PEP 8 updates/clarifications
Guido van Rossum wrote: > On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > >>On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: >> >> >>>The only thing I strongly disagree with is the promotion of javaNaming >>>to equal footing with python_naming. >> >>Actually, they're not on equal footing atm. I happen to agree with you >>though. > > > It doesn't matter. Many large projects are adopting the camelCase > convention, either by choice or by accident. I did a brief review of > Zope 3 and Chandler, and while neither is consistent, camelCase > prevails (Chandler also has a lot of CapWords method names, wihch > suggests they didn't get this from Java -- maybe from C++?). Everything that touches wx seems to adopt CapWords method names -- in part (hopefully) or in whole. Wx's API comes from Windows, and the Microsoft method conventions. I'd say that there's pretty strong support of underscores for functions, and less so for methods. But that doesn't really matter that much -- it's still valid to say that there's a preference, because there's a lot of code being created that doesn't have to be consistent with anything in particular, or has to be consistent with conflicting styles and must choose one. A suggestion in PEP 8 is better than flipping a coin. -- 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 11:50 PM 12/14/2005 -0600, Ian Bicking wrote: >Guido van Rossum wrote: > > On 12/14/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > > >>On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote: > >> > >> > >>>The only thing I strongly disagree with is the promotion of javaNaming > >>>to equal footing with python_naming. > >> > >>Actually, they're not on equal footing atm. I happen to agree with you > >>though. > > > > > > It doesn't matter. Many large projects are adopting the camelCase > > convention, either by choice or by accident. I did a brief review of > > Zope 3 and Chandler, and while neither is consistent, camelCase > > prevails (Chandler also has a lot of CapWords method names, wihch > > suggests they didn't get this from Java -- maybe from C++?). > >Everything that touches wx seems to adopt CapWords method names -- in >part (hopefully) or in whole. Wx's API comes from Windows, and the >Microsoft method conventions. Yes, at least the Chandler use of CapWords is due to wx influence (and perhaps a little of Visual Basic as well). In theory we use PEP 8 as the basis for the project's style guidelines, but in practice, code that works with wxPython has to at least use CapWords for overriding methods defined by wx. In addition, there's a heavy Java influence due to the use of PyLucene and other SWIG-wrapped Java compiled to C. So, as a practical matter, a One True Naming Style isn't going to happen soon, certainly not in Chandler. We are making some progress getting rid of Java-isms like classes named 'blah.foo.foo.foo.Foo', though. :) ___ 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] Sharing expat instances
I wrote: > my current idea is to > > 1. include it under a different name (_elementtree.so) > > 2. add a cElementTree.py under xml.etree, which simply does > > from _elementtree import * I've implemented this, for now. can anyone with a working windows setup look at building the _elementtree module for windows ? (see the setup.py file for build options; it wants the same defines as pyexpat, plus one extra define.). ___ 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
