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
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 k
On 12/13/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Armin Rigo <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote:
> >> $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
> >> -$(PYTHON) $(ASDLGEN) $(AST_ASDL)
>
> > The same just-ignore-it behav
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 cert
Barry Warsaw wrote:
> - If your class is intended to be subclassed, and you have attributes
> that you do not want subclasses to use, consider naming them with
> double leading underscores and no trailing underscores. This invokes
> Python's name mangling algorithm, w
Patch / Bug Summary
___
Patches : 383 open (+11) / 2990 closed (+10) / 3373 total (+21)
Bugs: 927 open (+19) / 5415 closed (+20) / 6342 total (+39)
RFE : 204 open ( +4) / 192 closed ( +1) / 396 total ( +5)
New / Reopened Patches
__
use PyOS_
On Tuesday 13 December 2005 17:17, Fredrik Lundh wrote:
> the remaining issue is how to include cElementTree. the current stand-
> alone distribution consists of a single cElementTree module, which is in-
> stalled under site-packages, as usual.
>
> to avoid collisions, it's probably best to insta
Armin Rigo <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 12, 2005 at 10:23:27PM +0100, Fredrik Lundh wrote:
>> $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
>> -$(PYTHON) $(ASDLGEN) $(AST_ASDL)
> The same just-ignore-it behavior can bite if the script genuinely fails
> after you just made a t
At 11:17 PM 12/13/2005 +0100, Fredrik Lundh 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
On 12/13/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Fredrik Lundh wrote:> BTW, what's the policy wrt. Jython-specific modules in the standard library?I don't think there is enough precedence to have a policy. So far, theonly places that explicitly support Jython is the test suite, pickle,
and
On Tue, Dec 13, 2005 at 03:54:00PM -0500, Fred L. Drake, Jr. wrote:
> I'd like to propose that a new package be created in the standard library:
> xmlcore. This package should contain what's currently in the "xml" package.
+1; it's what should have been done in the first place.
--amk
__
On 12/13/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I wrote:
>
> > 1. add an Include/pyexpat.h header file which contains a structure
> > similar to the following:
>
> > 2. during pyexpat initialization, initialize all members of this structure,
> > and
> > make it available as a PyCObject:
>
I wrote:
> 1. add an Include/pyexpat.h header file which contains a structure
> similar to the following:
> 2. during pyexpat initialization, initialize all members of this structure,
> and
> make it available as a PyCObject:
> 3. in cElementTree (or _elementtree, or whatever the python version
Fred L. Drake, Jr. wrote:
> I'd like to propose that a new package be created in the standard library:
> xmlcore. This package should contain what's currently in the "xml" package.
> The xml package should be replaced with a single module that's responsible
> for the magic that xml/__init__.py
I've CC'd the XML-SIG list on this; discussion should probably continue on
python-dev since we're well into the xml package at this point.
On Tuesday 13 December 2005 15:29, Fredrik Lundh wrote:
> what's the status of PyXML? is it time to move it over to svn.python.org
> and bring it up to 1.0
I wrote:
> Frankly, if at any time in the past several years the XML-SIG had
> published their consensus report on the "preferred API for XML"
> (or perhaps "preferred small set of APIs, each tuned for a specific
> purpose"), I expect it would have been incorporated in the core.
Martin v. Löwis ob
Fred wrote:
> > That's not true. The current xml package *is* the consensus of
> > xml-sig.
>
> It pretty much was at the time, at any rate. It's not clear to me that the
> xml package shipped in 2.4 and several preceeding versions of Python would
> pass muster in the current XML-SIG. There's be
On Tuesday 13 December 2005 15:02, Martin v. Löwis wrote:
> That's not true. The current xml package *is* the consensus of
> xml-sig.
It pretty much was at the time, at any rate. It's not clear to me that the
xml package shipped in 2.4 and several preceeding versions of Python would
pass must
On Tuesday 13 December 2005 14:52, Fredrik Lundh wrote:
> I take that as a "go ahead" ;-)
Good call! :-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Fredrik Lundh wrote:
> comments ?
As Fred says: go ahead.
regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
Fredrik Lundh wrote:
> BTW, what's the policy wrt. Jython-specific modules in the standard library?
I don't think there is enough precedence to have a policy. So far, the
only places that explicitly support Jython is the test suite, pickle,
and platform (I wouldn't really count in site here).
If
Michael Chermside wrote:
> Frankly, if at any time in the past several years the XML-SIG had
> published their consensus report on the "preferred API for XML"
> (or perhaps "preferred small set of APIs, each tuned for a specific
> purpose"), I expect it would have been incorporated in the core.
> T
Fred L. Drake, Jr. wrote:
> > 1. add an Include/pyexpat.h header file which contains a structure
> > similar to the following:
> ...
> > comments ?
>
> +1
I take that as a "go ahead" ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Personally, I'd rather just sort aphabetically based on dotted package
> name. Because packages provide meaningful groupings to begin with,
> this approach provides the most meaningful groupings to me. (All of
> my "internal" modules are in pac
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 cert
I'm no expert on policy any more, but if you can reasonably prevent it
from doing any harm (such as failing unit tests) to CPython I don't
see why not. However I believe that traditionally, Jython-specific
code has been checked into Jython's own source control.
--Guido
On 12/13/05, Fredrik Lundh
On Tue, 2005-12-13 at 23:52 +0900, Stephen J. Turnbull wrote:
> I'd be happy to make some time to describe the XEmacs scheme and
> experience if somebody wants. However, XEmacs faces language and code
> organization constraints that Python does not, and Fredrik's
> suggestion looks like a substan
At 07:26 AM 12/13/2005 -0500, Jim Fulton wrote:
>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 accesso
On Tuesday 13 December 2005 11:22, Fredrik Lundh wrote:
> here's a plan:
>
> 1. add an Include/pyexpat.h header file which contains a structure
> similar to the following:
...
> comments ?
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev maili
At 03:25 PM 12/13/2005 +, Michael Hoffman wrote:
>[Jim Fulton]
> > Sure, if you only have one module, and if your module doesn't do any
> > dynamic imports, and if the things your importing don't have dependencies,
> > and ...
> >
> > I think it would be simpler to have a formal dependency syst
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. :)
The current draft API guidelines for Chandler encourage the use of short
API module names such
Steven Bethard wrote:
> > Everybody here agrees that this style makes the code much less legible.
> > Partly because of the constant indirection. Also because it imposes
> > learning all those two-letter abbreviations before reading a module, and
> > the learning has to be redone on each visit, i
Martin v. Löwis wrote:
> > - sort out expat bundling issues, and include cElementTree as well
> > (using the same approach as above).
...
> > (one way to do this would be to add an "function pointer table" to pyexpat
> > that contains pointers to selected portions of the expat API, and the
Jim Fulton wrote:
>> stdlib, external modules, internal modules seems like enough ordering
>> to me. If you want to order things more exactly, sure, but I don't
>> really see the point personally. Since I can't assume as a reader
>> that imports are ordered in any way I have to search to be su
On 12/13/05, François Pinard <[EMAIL PROTECTED]> wrote:
> [Steven Bethard]
>
> >Ahh. I never run into this because I never import objects directly
> >from modules. So, instead of:
>
> >from elementtree.ElementTree import ElementTree
> >...
> >ElementTree(...)
>
> >I almost always writ
[EMAIL PROTECTED] wrote:
> Jim> For debugging purposes, it's easy to add a property to allow
> Jim> debugging of attribute assignment.
>
> Assuming you use new-style classes, which I often don't. The property/debug
> idea that you and Gustavo have both now mentioned makes them a bit more
Jim> For debugging purposes, it's easy to add a property to allow
Jim> debugging of attribute assignment.
Assuming you use new-style classes, which I often don't. The property/debug
idea that you and Gustavo have both now mentioned makes them a bit more
attractive.
Is there a new-style
[Jim Fulton]
>>> Personally, I don't find the stdlib/external distinction to be useful.
[Michael Hoffman]
>> It's useful because it allows one to quickly see all the prerequisites
>> need to be installed in one place.
[Jim Fulton]
> Sure, if you only have one module, and if your module doesn't do
Jim> Personally, I don't find the stdlib/external distinction to be
Jim> useful.
For me it's just a "who do I blame for problems" sort of thing. Most of the
time I know, but others looking at my code might not know that MySQLdb isn't
in the core but that bsddb is.
Skip
_
> "skip" == skip <[EMAIL PROTECTED]> writes:
skip> BTW, there is one project I'm theoretically familiar with
skip> that attempts to handle the dual source situation: XEmacs.
skip> I'm still trying to come to terms with the practical issues
skip> involved. I'm supposed to be u
Nick> Having to type '(object)' all the time is annoying, but less
Nick> annoying than trying to figure out which set of semantics a given
Nick> class is using.
Sure. Since I started writing Python long before new-style classes were
around, I have lots of classic classes. My default
Mike Brown writes:
[ElementTree was accepted into stdlib immediately without discussion
on XML-Sig. Seems like a lack of due process.]
> Some authors of other libs may not even be aware that they could so
> easily have their code whisked into stdlib, if it's solid enough.
It's not the solid
[Steven Bethard]
>Ahh. I never run into this because I never import objects directly
>from modules. So, instead of:
>from elementtree.ElementTree import ElementTree
>...
>ElementTree(...)
>I almost always write something like:
>import elementtree.ElementTree as et
>...
>
Michael Hoffman wrote:
> [Ian Bickling]
>
>>>stdlib, external modules, internal modules seems like enough
>>>ordering to me.
>
>
> [Jim Fulton]
>
>>Personally, I don't find the stdlib/external distinction to be useful.
>
>
> It's useful because it allows one to quickly see all the prerequisit
BTW, what's the policy wrt. Jython-specific modules in the standard library?
Expat isn't available under Jython, but I have a Java/Jython-driver for
ElementTree
on my disk. Can / should this go into the CPython standard library ?
___
Python-Dev m
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)
we also need to figure out how to import the bundled version; should it be
cElem
On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Unfortunately that fails one of the other requirements, which (at the
> time of implementation) was minimal impact on the rest of the
> interpreter. Since __private isn't limited to self, and attribute
> lookup doesn't always result in a di
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Dotted non-from imports (e.g. import test.pystone) are rare enough
> that they don't deserve a special rule; if you want me to give a rule,
> I think they should be mixed in with the undotted ones,
> alphabetically.
I actually really hate this style,
[Ian Bickling]
>> stdlib, external modules, internal modules seems like enough
>> ordering to me.
[Jim Fulton]
> Personally, I don't find the stdlib/external distinction to be useful.
It's useful because it allows one to quickly see all the prerequisites
need to be installed in one place.
--
Mic
Nice that we now have ElementTree in the stdlib :-)
Some questions:
* Are you going to contribute cElementTree as well ?
* What was the motivation to not include the whole ElementTree
package ?
* I'm missing the usual "Licensed to PSF under a Contributor Agreement."
in the copyright notices
Barry Warsaw wrote:
> On Sun, 2005-12-11 at 11:20 -0500, Jim Fulton wrote:
>
>
>>This seems outdated. My impression, in part from time spent
>>working with the Python Labs guys, is that it is fine to have public
>>data sttributes even for non-"record" types. In fact, I would argue that
>>any ti
Barry Warsaw wrote:
> On Sun, 2005-12-11 at 16:30 -0600, Ian Bicking wrote:
>
>
>>Potentially it could be added that the whole issue can often be avoided
>>when an object's methods perform actions instead of returning attributes
>>of the object. It's a long topic; maybe it could even just be a
[EMAIL PROTECTED] wrote:
> Jim> I don't understand this argument. Any mutating method or property
> Jim> invoked by foreign code changes an object's state.
>
> Sure, but the only place I need to look for direct changes to the object's
> state are in the object's own code.
>
> Jim>
[EMAIL PROTECTED] wrote:
...
> This is subjective enough that I would think some rationale explaining this
> convention should be given.
This is subjective enough that I don't think it should be in the PEP.
Sometimes, less is more.
JIm
--
Jim Fulton mailto:[EMAIL PROTECTED] Pyth
Ian Bicking wrote:
> Barry Warsaw wrote:
...
>>>This seems too complex to me for PEP 8.
>>
>>
>>Really? ISTR adopting this convention from Guido, but I'm not 100% sure
>>about that. After having used it for several years now, I do really
>>like this style, but I'm willing to leave the recommenda
Guido van Rossum wrote:
> On 12/12/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
>>In practice, I don't agree that it works fine. Inevitably, someone
>>finds a need to access a "private" variable in a subclass. Or
>>even in the original class, you find some need to use something like
>>__getattr__
Nick Coghlan 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.
>
> If this is a comment on the ElementTree API, then /F must a
Seg, 2005-12-12 às 22:38 -0600, [EMAIL PROTECTED] escreveu:
> Jim> I don't understand this argument. Any mutating method or property
> Jim> invoked by foreign code changes an object's state.
>
> Sure, but the only place I need to look for direct changes to the object's
> state are in th
Walter Dörwald 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.
If this is a comment on the ElementTree API, then /F must agree w
Martin v. Löwis wrote:
> [...]
>
> It's difficult to establish precise numbers, but I would expect that
> most readers of xml-sig are well aware of how DOM and SAX work, perhaps
> even better than ElementTree.
>
> My main complaint about this was in the past that it is a Python-only
> solution,
Guido van Rossum wrote:
> On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>>Martin> It's difficult to establish precise numbers, but I would expect
>>Martin> that most readers of xml-sig are well aware of how DOM and SAX
>>Martin> work, perhaps even better than ElementTree
[EMAIL PROTECTED] wrote:
> Nick> Any old code could be fixed by putting "from types import
> Nick> ClassType as __metaclass__" at the top of the affected modules.
>
> Which would be, what, 90% of all Python code written that defines classes?
I generally don't allow old-style classes in an
Phillip J. Eby wrote:
> At 06:19 PM 12/12/2005 -0700, Mike Brown wrote:
>
>>Some authors of other libs may not even be aware that they could so
>>easily have their code whisked into stdlib, if it's solid enough.
>
>
> But here the definition of "solid enough" includes such credits as being
> wr
Mike Brown wrote:
> My fears are just that 1. XML-SIG is being seen as either irrelevant or as an
> obstacle (perhaps due to the friction between Fredrik and Uche) and are thus
> being sidestepped, and 2. other libs that could/should be contenders (Amara
> and 4Suite are not in this list, by the
64 matches
Mail list logo
