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 buildin
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
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
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 yo
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 loc
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 digit
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 (_elem
[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 reasona
[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
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 m
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]> wro
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
[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 shou
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,
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
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 t
[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://pin
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 wr
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 un
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: y
[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,
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, w
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 th
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 digitall
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
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
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 als
> 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
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-ar
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]
___
Pyt
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 whereve
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
fr
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 pa
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 pre
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!
>
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
> -
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
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
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
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
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
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 impor
/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 changin
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.
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 prov
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
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, m
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
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 c
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 th
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 c
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 th
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 wh
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 alway
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 cElement
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
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
> 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
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 pref
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: vwr
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
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
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 CV
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 imp
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
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 BE
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.
>
>
[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]>
Europe
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
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 conte
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),
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'
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 wi
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.
_
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 sep
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 i
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 f
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 cla
78 matches
Mail list logo
