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
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
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.
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
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
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),
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
[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. wink
--
Michael Hoffman [EMAIL PROTECTED]
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.
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. wink
Or BEGIN,
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
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
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
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;
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:
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
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
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
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
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
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
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
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
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
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,
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
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
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.
/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
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
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
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
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
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
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 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
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
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
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.
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
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]
___
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
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
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
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 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
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
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
[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
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
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
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
[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
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
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
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
[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
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
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]
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
[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
[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.
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
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
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
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
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.
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
68 matches
Mail list logo
