Re: [Python-Dev] ElementTree in stdlib
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 way) are going to become further > marginalized by virtue of the fact that people will say "well, we have > ElementTree in stdlib already, why do we need (fill in the blank)?" And if they say so, they might be right! I firmly believe that the standard library should be a community-driven thing, not a committee-driven one. For that, two things need to happen for a library to become included: 1. the author of the library must explicitly offer it for inclusion. there is no point in "hijacking" the package into the library, even if the package license would allow to do so (factually, it typically doesn't, because it typically doesn't allow redistribution under a different license). So without the author's explicit endorsement, and promise to maintain it for some time (or some other set of people offering that), nothing will happen to (fill in the blank). 2. the users must indicate that they want to see the package as part of the library. Again, just that the author would like to contribute it isn't enough - there must be people supporting the inclusion of the package. Traditionally, we had a third step: 3. The BDFL must pronounce inclusion of the package. Now, while Guido has a firm vision for how the language proper should evolve, he often indicated that he can't really comment on some specific library because he doesn't know anything about the functionality it provides. So in the case of libraries, this requirement often is waived. > I suppose the same kind of implicit endorsements were given to minidom and > SAX, and that obviously hasn't prevented people from going out and using > ElementTree, lxml, etc., so I don't know... I can't predict the future. I'd > just feel better about it if everyone on XML-SIG, where people hang out > because they have a definite interest in this kind of thing, knew what was > going on. 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. That's part of the process. They could have read PEP 2, so they could have known to write a PEP and get it discussed. When they don't know that, they fail the basic test of "author support": if the author isn't really behind the integration of the package, the package really shouldn't be integrated (this is why I first predicted ElementTree would never become part of the library, because I assumed /F would not like the idea). 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 > written by the primary author of CPython's implementations of Unicode and > regular expressions, and who can be reasonably be believed to be around to > support and maintain the package for some time. I don't know who the "some > authors" you mention are, but those are pretty tough credentials to match, > as are the apparent popularity, Pythonicness, and performance of ElementTree. > > I find it rather hard to believe that there's another XML library that > could have gotten through the approval process anywhere near as easily. > This can be observed simply by looking at who posts to python-dev. Certainly we see input from Fredrik on a fairly regular basis, whereas others appear infrequently or not at all. Absence from python-dev can't really be seen as expressing any keenness at all for one's code to be included in the core. If the authors of code aren't bothered about its promotion to the core I hardly think anyone else should be. 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 Python-Dev@python.org 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
[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 any code I have control over (well, aside from exceptions). Having to type '(object)' all the time is annoying, but less annoying than trying to figure out which set of semantics a given class is using. My interpreter startup script even includes "__metaclass__ = None" in order to disable the implicit metaclass. I think it's an artifact of only seriously starting to use Python with version 2.2.2 - I don't really understand how old-style classes work, so I try to avoid using them. However, you raise a fair point, which is why I raised the suggestion of respecting a "__metaclass__" definition in the builtins, allowing application developers to perform their own new-style class smoke test prior to Py3k. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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. >> >>Perhaps the corollary is that people who are not xml-sig readers will likely >>be put off by DOM and SAX. I couldn't tell you what they do, just that they >>were Too Hard (tm) for me to bother with XML in most situations. Then >>ElementTree came along. > > It seems pretty clear why DOM isn't Pythonic: it doesn't use Python's > standard APIs for things that conceptually are "just" lists and dicts, > or at least sequences and mappings. Also, the memory footprint is a > bit outlandish. > > 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. Then again, pythonic is whatever you say that it is. ;) Bye, Walter Dörwald ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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, so people working in multiple languages cannot reuse their > knowledge. It seems that this is irrelevant, as people don't work > in multiple languages so much. I still think that Python should continue > to provide standard APIs, for those that know how things are done > in Java. I think there could be a middle ground between one API for all XML processors in all languages (SAX+DOM) and every XML package having its own custom API. A common tree API for all Python XML processors might be beneficial. Maybe ElementTree can become that API? Or maybe a subset of the ElementTree API (I don't think the text and trail attributes should be in that API). Bye, Walter Dörwald ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 with you - iterparse [1] was added to the API earlier this year. . . Cheers, Nick. [1] http://effbot.org/zone/element-iterparse.htm -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 the object's own code. > > Jim> If you provide a property or a pair if accessors that just sets and > Jim> gets an attribute with a slightly different name, that affords no > Jim> more protection than if people were setting the attribute directly. > > Sure it does. Suppose I get an exception in my code because some bit of > code somewhere broke my assumptions about the values an attribute could > assume. If that attribute is only set by the object's own code, I can more > easily debug it (stick in a print or an assert in the places where the > attribute changes, etc). If some external bit of code does something like > > self.foo = Foo() > ... > self.foo.attr = None > > then later in Foo's code I have something like > > self.attr.callme() > > The first thing I need to do is figure out who stomped on self.attr. I have never done this, but in theory you could replace attr with a property whose getter uses sys._getframe() to log each modification of the attribute, thus easily find out who did "self.foo.attr = None". Almost like gdb's 'watch' command. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 agree with you - > iterparse was added to the API earlier this year. . . When xml.sax was added to Python, the standard approach was to create parsers that implemented the consumer pattern [1] and called methods either on the parser class itself, or on a target object. Examples include sgmllib, htmllib/formatter, and xmllib. After the discovery of efficient "pull parsing" patterns [2] and "using iterators to invert program logic" patterns (see e.g. the "anonymous blocks" thread from april this year [3], which generated a whole bunch of interesting PEPs), things have changed a bit. 1) http://effbot.org/zone/consumer.htm 2) http://mail.python.org/pipermail/xml-sig/2000-May/002335.html (Paul's xml.dom.pulldom module did make it into the standard library, but it don't seem to be used much, for some unknown reason...) 3) http://mail.python.org/pipermail/python-dev/2005-April/052753.html (lots of interesting posts here) ___ 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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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__ where the implicit name mangling doesn't come into play >>and you have to emulate the name mangling. Or perhaps someone wants >>to examine the value of one of these variables in the debugger. >>In my experience, almost every time someone uses the __private >>trick, they or someone else comes to regret it. >> >>OTOH, explicit name mangling provides the benefits of implicit >>name mangling without it's drawbacks. > > > I half agree. I've seen many classes overuse __private. As I point out above, it's not just a matter of overuse. It is only recognized by the compiler, so it doesn't work with getattr. And of couuse, there's the debugger issue. I've often found cases where, even when I was using it correctly, I had to do manual name mangling myself. Anytime one has to perform weird tricks in Python to work around magic should be a warning sign. > But that's a > separate issue from not having the feature at all; you might as well > argue against private in Java or C++. I'm not arguing against the feature but against it's implementation. My intuition is that the explicit name magling approach is more in keeping with Python's way of doing things. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 recommendation out of PEP >>8. > > > It seems so exacting to me; Me too. > 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 sure of what's there. The grouping help me browse, but I'd > hope that the import list is short enough that I don't need to use > alphabetization to scan for a module. Personally, I don't find the stdlib/external distinction to be useful. 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 packages.) When scanning imports, I don't want to have to think about whether a module is internal or external. I've got enough to think about without that. :) Frankly, I'd be as happy t see the PEP be silent on module ordering. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
[Python-Dev] Import order (was Re: PEP 8 updates/clarifications)
[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] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[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> If you provide a property or a pair if accessors that just sets and > Jim> gets an attribute with a slightly different name, that affords no > Jim> more protection than if people were setting the attribute directly. > > Sure it does. Suppose I get an exception in my code because some bit of > code somewhere broke my assumptions about the values an attribute could > assume. If that attribute is only set by the object's own code, I can more > easily debug it (stick in a print or an assert in the places where the > attribute changes, etc). If some external bit of code does something like > > self.foo = Foo() > ... > self.foo.attr = None > > then later in Foo's code I have something like > > self.attr.callme() > > The first thing I need to do is figure out who stomped on self.attr. That > can be time-consuming if I don't necessarily know where the stomping > occurred. I just don't buy this argument. For trivial accessors and properties, you can't just look at your code to know where the changes are initiated. For debugging purposes, it's easy to add a property to allow debugging of attribute assignment. > At work we use Python for very rapid development of trading applications. > Today I think we made about a half-dozen micro releases fixing bugs and our > traders tried each one immediately live. Much of the design is carried > around in our heads or consists of a few equations scribbled on sheets of > paper. As you might imagine, it's a very lively environment. Localizing > attribute modifications is a very good thing for us, even if they are simply > one-line set methods. Having to write accessors for all your public methods doesn't seem consistent with rapid development. It increases the ceremony of development and adds lots of meaningless boilerplate that readers of the code have to wade through. Note that they can't just skip over it, because they can't know if you've slipped something meaningful into one of these accessors. > Jim> If you don't want external code to change an attribute, don't > Jim> expose it through a public API. > > I suppose "public" is subject to some interpretation. Just because I don't > prefix an attribute with an underscore doesn't mean I've implicitly declared > it public. I assume that people will familiarize themselves with the > callable methods of an object and only use direct attribute access if I > haven't provided the necessary methods. A better approach is to document the API for your classes and expect people to use that API. Prepending an underscore documents that a variable or method is internal. (Of course, there's still the subclassing API to deal with, if you need one, but that's a separate issue.) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 link, >>if someone knows of a good discussion along those lines. I'm sure >>there's some terminology here that I'm forgetting that describes the >>design pattern. There's also a point when the style guide becomes an >>API design guide, and I don't know how far it should go in that direction. > > > I'm not exactly sure if this is what you're getting at, but one thing > that bothers me is using data attributes to trigger actions. Maybe this > gets into the "no side-effects" rule for data attributes, but attributes > that cause an object to perform some action should always be explicit > methods. Exactly. That's why I suggested the PEP start with the trivial case, which, BTW is extremely common. Let judgement guide when something is no-longer trivial. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 time you would be tempted to provide "getFoo()" and "setFoo(v)" >>for some "private attribute _foo", it would be better to make it >>public. I certainly find "blah.foo" and "blah.foo = v" to be much >>better than "blah.getFoo()" and blah.setFoo(v)". >> >>Certainly, properties provide a safety belt. I would argue it this >>way: Python APIs can include attributes as well as methods. >>Exposure of an attribute need not constrain the implementation, thanks >>to properties. OTOH, I wouldn't bother with a property unless it's needed. > > > Let me know what you think about this language (from my in-progress > update of PEP 8): > > Designing for inheritance > > Always decide whether a class's methods and instance variables > (collectively: "attributes") should be public or non-public. Public > attributes are those that you expect unrelated clients of your class to > use, with your commitment to avoid backward incompatible changes. > Non-public attributes are those that are not intended to be used by > third parties; you make no guarantees that non-pubic attributes won't > change or even be removed. I'd add somewhere: "If in doubt, chose non-public. You can always change your mind later." > 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. > With this in mind, here are the Pythonic guidelines: > > - Public attributes should have no leading underscores. > > - If your public attribute name collides with a reserved keyword, append > a single trailing underscore to your attribute name. This is > preferable to an abbreviation or corrupted spelling. E.g. "class_" > is preferable to "cls" or "klass". > > Note 1: See the argument name recommendation above for class methods. > > [BAW: I'll include this new text in a later followup] > > - 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. > - 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, where the name of the class is > mangled into the attribute name. This helps avoid attribute name > collisions should subclasses inadvertently contain attributes with the > same name. > > Note 1: Note that only the simple class name is used in the mangled > name, so if a subclass chooses both the same class name and attribute > name, you can still get name collisions. > > Note 2: Name mangling can make certain uses, such as debugging, less > convenient. However the name mangling algorithm is well documented > and easy to perform manually. Of course, I disagree with this last one, but I've been overruled. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Re: [Python-Dev] ElementTree in stdlib
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 of the files: http://www.python.org/psf/contrib.html I assume that you'll add these, right ? * 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 ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[Ian 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. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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, though I'm at a bit of a loss as to explain why... Cheers, mwh -- An encyclopedia is about being as accurate as it can, not being evenly misinformed. -- Coby Beck, comp.lang.lisp ___ 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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 dict lookup, this would require a > complete overhaul of the getattr API, both at the C and at the Python > level. I hate to flog a dead horse but I feel it's important to clarify my intentions here. I don't see why it couldn't require a dict. Immutable builtins will fail either way, and so will classes using slots (unless they hardcode the required private name). The only problematic use-case I can think of is a proxy class, but is that enough to dictate the entire design of the feature? > But I guess you already said that when you said """Obviously it > doesn't handle backwards compatibility, so it's more of a "if I could > do it again.." suggestion.""" I was referring to code which already hardcodes the format of the current approach, i.e.: class Foo(object): def __init__(self): self.__private = 42 f = Foo() print f._Foo__private -- Adam Olsen, aka Rhamphoryncus ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree (which would then fallback on the Python version if cElementTree isn't built) ? > * 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... > * 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 ___ 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-archive.com
[Python-Dev] Jython and CPython
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 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 prerequisites > need to be installed in one place. 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 system. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
[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 >... >et.ElementTree(...) This is a bit off-topic, but I felt like sharing our experience. One consultant we once hired here was doing exactly that (importing over two-letter abbreviations). >Thus, all objects that were imported from external modules are always >immediately identifiable as such by their prefixed module name. I do >see though that if you like to import the objects directly from the >module this could be confusing. 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, it just does not stick. So, we try to routinely replace abbreviations with the real names whenever we have to play in one module written by this consultant. But it only goes a little bit at a time. We should probably suffer taking the time, dive in it all, and get rid of this style once and for all... -- François Pinard http://pinard.progiciels-bpi.ca ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 solidity of the CODE in ElementTree that secured the approval. It's not even the pythonicness of the API (although that's ElementTree's greatest strength). No, the reason for the rapid acceptance was the solidity of the *community support*. For a long time, lots of people (users, not just core developers) have been thinking to themselves "why isn't ElementTree the standard Python API for XML?". Once it was stated out loud (on c.l.py) and it was clear that /F supported the idea, there was little to discuss. 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. This could have been done long before /F ever wrote ElementTree. But historically, this isn't what happened. I look at some other areas and find that Python tends to have one good (hopefully excellent) implementation of a given feature, and perhaps a few high-powered 3rd party implementations for special purposes. For instance, there's the datetime module which satisfies most users, then there are tools like mxDateTime for specialists. Most users of high-precision numbers make due with the built-in long type, but specialists use GMPY. Most users of threading find that the threading module is sufficient, but those who really want full co-routines get stackless. Expressed in this fashion, I have always felt that the XML-SIG was basically working on developing and standardizing the specialist tools for XML, with special attention paid to things like very high performance, very complete implementation of XML features, cross-language standardization, automatic object serialization, and other such features far removed from the basic "I want to read this file and it's in XML." Those are great areas, and there are people who need them (for some projects, I'm one of those people). However, ElementTree is one of the few libraries that have struck me as being canidates for the "one good implementation" that serves the basic needs of the typical user. -- Michael Chermside ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 is thus to use classic classes in preference to new-style classes, for much the same semantic reasons as you. Nick> I think it's an artifact of only seriously starting to use Python Nick> with version 2.2.2 - I don't really understand how old-style Nick> classes work, so I try to avoid using them. Again, we're actually thinking along the same lines. Classic classes work just fine for me, so I've been slow to let the new-style class meme permeate through my brain. Skip ___ 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-archive.com
Re: [Python-Dev] Incorporating external packages into Python's std distribution
> "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 updating the python-mode code, skip> and am only taking baby steps in that direction, so I'm skip> probably not the best person to describe how it works, but skip> here goes. 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 substantial improvement over the system XEmacs has in place. Even with its defects, it's been a great success for us. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
[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 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 system. More useful, yes, for all the reasons you listed. The fact that people are still working on a formal dependency system, however, indicates that it is not simpler. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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-archive.com
[Python-Dev] On moving to new-style classes
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 class HOW-TO somewhere? It would be useful to summarize the advantages for them. I still have this thought stuck in my head (from where, I don't know, probably incorrect) that one of the main reasons for new-style classes was to get rid of __dict__. Jim> Having to write accessors for all your public methods doesn't seem Jim> consistent with rapid development. I'd rather trade the 30 seconds it takes to write a simple accessor method when I need it than the minute or two it takes to figure out where my attribute got stomped. I guess it mostly boils down to a matter of taste. Did I also mention that most of the programmers here are C++ folk? They have their beloved inline keyword. Skip ___ 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-archive.com
Re: [Python-Dev] On moving to new-style classes
[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 > attractive. > > Is there a new-style class HOW-TO somewhere? See http://www.python.org/doc/newstyle.html > It would be useful to > summarize the advantages for them. I still have this thought stuck in my > head (from where, I don't know, probably incorrect) that one of the main > reasons for new-style classes was to get rid of __dict__. No, the main benefit is to begin to resolve the class/type dichotomy. Among other benefits, this allows you to subclass types written in C. Of course, there are other benefits, most notably descriptors, which make properties, among other things, possible. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 write something like: > > >import elementtree.ElementTree as et > >... > >et.ElementTree(...) > > This is a bit off-topic, but I felt like sharing our experience. One > consultant we once hired here was doing exactly that (importing over > two-letter abbreviations). > > >Thus, all objects that were imported from external modules are always > >immediately identifiable as such by their prefixed module name. I do > >see though that if you like to import the objects directly from the > >module this could be confusing. > > 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, it just does not stick. Much less legible than without the namespace? Or much less legible than with a non-abbreviated namespace. FWIW, here's some real examples from my code: 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? 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... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 sure of >> what's there. The grouping help me browse, but I'd hope that the >> import list is short enough that I don't need to use alphabetization >> to scan for a module. > > > Personally, I don't find the stdlib/external distinction to be useful. I like the stdlib coming first, because (if it's not using "from") stdlib imports are just line noise and I don't pay any attention to them. I care if a module uses an external package, but I don't care what stdlib packages it uses (I'd actually like to be able to avoid importing them at all, but that's an aside: http://blog.ianbicking.org/py-std.html). So I don't really care what comes first, just that stdlib imports are grouped together so I can ignore them, and first is as good a place as anything. "from...import" is a different matter of course, because I need to look at those to see where names come from. Additionally, having the local packages grouped together helps make up for the non-distinction of absolute and relative imports. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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-archive.com
[Python-Dev] Sharing expat instances
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 then add
> > an indirection level to cElementTree)
>
> Ok, this sounds like a larger piece of work.
here's a plan:
1. add an Include/pyexpat.h header file which contains a structure
similar to the following:
#define PyExpat_DISPATCH_MAGIC "... some magic string ..."
struct PyExpat_Dispatch {
int size; /* size of this structure */
int MAJOR_VERSION;
int MINOR_VERSION;
int MICRO_VERSION;
... (*ErrorString)(...)
... (*GetErrorColumnNumber)(...)
... (*GetErrorLineNumber)(...)
... (*Parse)(...)
... (*ParserCreate_MM)(...)
... (*ParserFree)(...)
... (*SetCharacterDataHandler)(...)
... (*SetCommentHandler)(...)
... (*SetDefaultHandlerExpand)(...)
... (*SetElementHandler)(...)
... (*SetNamespaceDeclHandler)(...)
... (*SetProcessingInstructionHandler)(...)
... (*SetUserData)(...)
/* add new stuff to the end */
}
(this is the minimal stuff used by today's cElementTree; it can of course
be extended to cover a larger part of the current expat API)
2. during pyexpat initialization, initialize all members of this structure, and
make it available as a PyCObject:
static PyExpat_Dispatch dispatch;
dispatch.size = sizeof(dispatch):
dispatch.MAJOR_VERSION = XML_MAJOR_VERSION;
...
obj = PyCObject_FromVoidPtrAndDesc(
&dispatch, PyExpat_DISPATCH_MAGIC, NULL
);
... stuff object into module dictionary ...
3. in cElementTree (or _elementtree, or whatever the python version will
be named), import pyexpat, fetch the object, and verify
- that the PyExpat_DISPATCH_MAGIC matches
- that the size field is at least as large as sizeof(struct
PyExpat_Dispatch)
- that the version number matches (at least MAJOR and MINOR; I'm not
sure under what circumstances they change the MICRO number)
4. in cElementTree (...), do all expat calls via the dispatch table.
comments ?
___
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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8updates/clarifications)
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, it just does not stick. > > Much less legible than without the namespace? Or much less legible > than with a non-abbreviated namespace. using abbreviations just for the sake of it may be a bad idea, but using it to able to quickly switch between different drivers works really well. my code is full of stuff like: import sqlite2 as DB import wckTkinter as WCK # import cElementtree as ET import xml.etree.ElementTree as ET but you sure won't see import sys as SY import os.path as op or other gratuitous aliasing. ___ 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-archive.com
Re: [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)
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 as 'pim' and 'mail' to allow more clarity as to naming, while encouraging import patterns that make module reloading more practical during development. Using a module name as a prefix to a class or function name also allows flatter namespaces with fewer imports, especially in the case of APIs which contain many features and are frequently used. Of course, we don't do abbreviations or renaming; instead, code like this is the common pattern: from application import schema class Contact(schema.Item): name = schema.One(schema.Text) # ... etc. ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 system. > >More useful, yes, for all the reasons you listed. The fact that people >are still working on a formal dependency system, however, indicates >that it is not simpler. Depends on your definition of "still working on". I'd characterize the dependency system offered by setuptools as receiving fine-tuning, rather than being under design or development. A few things have been tweaked in the last few months according to real-world feedback: breadth-first processing worked out to be better than depth-first when complex recursive dependencies are involved, and the handling of '-' in version numbers needed a minor adjustment. 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". ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 accessors *are* trivial. +1000. Python is not Java. It's hard enough to get former Java users to stop writing getters and setters in the first place, without PEP 8 providing even a sliver of support for that nonsense. If anything, PEP 8 should warn in the strongest possible terms about the wastefulness of this practice and its detrimental effects on code size, readability, and performance. ___ 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-archive.com
Re: [Python-Dev] Incorporating external packages into Python's std distribution
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 substantial improvement over the system XEmacs > has in place. > > Even with its defects, it's been a great success for us. I'd love to read about the way XEmacs is doing this. -Barry signature.asc Description: This is a digitally signed message part ___ 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-archive.com
Re: [Python-Dev] Jython and CPython
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 <[EMAIL PROTECTED]> wrote: > 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 ? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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. Also the different callbacks have different signatures. But since /F solved this for ElementTree I have to mostly agree with you. :-) > 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications
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 packages.) When scanning imports, I > don't want to have to think about whether a module is internal or > external. I've got enough to think about without that. :) Disagree strongly. The separation into (1) stdlib, (2) thirdparty, (3) internal helps the reader assess dependencies -- where to look for more docs, what to do if the import fails, etc. > Frankly, I'd be as happy t see the PEP be silent on module ordering. Obviously I disagree here too. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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://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: > 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. > This could have been done long before /F ever wrote ElementTree. > But historically, this isn't what happened. That's not true. The current xml package *is* the consensus of xml-sig. 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-archive.com
Re: [Python-Dev] Jython and CPython
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 the portability problem can be solved by checking things into Jython instead, I think I would prefer that. Then having in CPython an import that only succeeds for Jython would be fine. 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-archive.com
Re: [Python-Dev] Sharing expat instances
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-archive.com
Re: [Python-Dev] Sharing expat instances
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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 muster in the current XML-SIG. There's been a lot of evolution in the Python APIs for XML since then, and a lot of really interesting things have been tried with varying degrees of acceptance. Unless the XML-SIG wants to figure it out all over again, adding xml.etree to the standard library is probably the best near-term improvement that can be made. Speaking just for myself, I think this is fine, though I agree with Jim that an easier-to-use package management system would go a long way to avoid the issues related to whether something is in the standard library. Now, just what it means for a package management system to be easier to use might be harder to get us to agree on. :-) -Fred -- Fred L. Drake, Jr. ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 been a lot of evolution in the > Python APIs for XML since then, and a lot of really interesting things have > been tried with varying degrees of acceptance. from what I can tell, most of the stuff under Lib/xml is between two and three years old. the last major PyXML sync appears to be against 1.82, in january 2003. there are a few bug fixes since then, but that's about it. what's the status of PyXML? is it time to move it over to svn.python.org and bring it up to 1.0 (whatever that would mean?) ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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 objected: > That's not true. The current xml package *is* the consensus of > xml-sig. Fred Drake clarifies > 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. Yes, I'm sorry about not being clearer, and thanks for correcting me. It was the more recent work in XML which I was thinking of. -- Michael Chermside ___ 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-archive.com
[Python-Dev] "xml" package in standard library
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 (whatever that would mean?) I'm not entirely sure myself; I've had no real time to look at it for a while. I think before we need to worry about PyXML from the perspective of the standard library, we need to work out a better way to deal with the "xml" package. Not only is the current state a source of confusion for users, it's a problem for testing the standard library if there's also a PyXML installed for the same version of Python (the PyXML modules are imported instead of the stdlib modules, but the tests for the standard library may reflect fixed bugs). This has bit me a few times. 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 deals with now. The tests for the xml package will be changed to test the xmlcore package. Advantages: - People who specifically want the standard library code can get it without having PyXML get in the way if installed. - Existing code using the xml package will continue to work. Risks: - 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. -Fred -- Fred L. Drake, Jr. ___ 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-archive.com
Re: [Python-Dev] "xml" package in standard library
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 deals with now. The tests for the xml > package will be changed to test the xmlcore package. > > Advantages: > > - People who specifically want the standard library code can get it without > having PyXML get in the way if installed. > > - Existing code using the xml package will continue to work. > > Risks: > > - 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. Doing *something* would be good (and what you suggest sounds reasonable). I spent far too much time on a couple of occasions figuring out that an application was blowing up because it expected the full PyXML installation, rather than just the standard lib XML core (I don't know the xml package tree well enough to tell from the name whether a given subpackage is part of the standard lib or not). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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 will > be named), import pyexpat, fetch the object, and verify > 4. in cElementTree (...), do all expat calls via the dispatch table. I've fixed all this, and checked in 1 and 2. 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 install the bundled version under xml.etree, but how do you do that for a C module ? 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 ? ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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: > > > 3. in cElementTree (or _elementtree, or whatever the python version will > > be named), import pyexpat, fetch the object, and verify > > > 4. in cElementTree (...), do all expat calls via the dispatch table. > > I've fixed all this, and checked in 1 and 2. > > 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 install the bundled version under > xml.etree, but how do you do that for a C module ? > > 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 ? > Too bad you can't do 1 and for 2 add ``import _elementtree as cElementTree`` in etree/__init__.py . Unless I am missing something it won't work since ``import xml.etree.cElementTree`` will fail. Since the way you outlined is the standard way to do it in the stdlib I doubt anyone has thought of a better way. -Brett ___ 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-archive.com
Re: [Python-Dev] "xml" package in standard library
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 ___ 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-archive.com
Re: [Python-Dev] Jython and CPython
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 platform (I wouldn't really count in site here). Actually there's some Jython-specific code in xml/sax/__init__.py. Two places, both questionable. One of them refers to sys.registry. The other appears to be a workaround for Jython not having 4-argument __import__. > If the portability problem can be solved by checking things into Jython > instead, I think I would prefer that. Yes, it can be solved that way: Jython could implement pyexpat. I don't know just how crazy that idea is; my impression is that it could be done, perhaps imperfectly, as a wrapper around SAX. -j ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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 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. ___ 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-archive.com
Re: [Python-Dev] should I really have to install Python before Icanbuild it ?
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 typo in one of the input files, for example. > Doesn't look particularly clean to me, if you want my opinion. Perhaps a good solution would be to have a separate make rule for generating the AST code (i.e. not included in the overall dependancy graph). That increases the chance that they don't get regenerated when they should but people hacking on the AST files should notice the error pretty easily. Other people should always be able to build from the files checked in to SVN and so having the dependancy there is just a source of trouble. Neil ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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 install the bundled version > under xml.etree, but how do you do that for a C module ? > > 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 ? Avoiding imaginaary name collisions and putting cElementTree into the xml package is making the task harder than need be and will perpetuate the problems caused by the earlier decision to do magic in the xml import statement. The use of magic was a violation of "explicit is better than implicit". Forgeting this rule has caused pain to many people who didn't expect a magic side effects from simply installing PyXML. Adding cElementTree to the mess that already exists doessn't make sense, and the only justification for not adding a new top level package seems to be to avoid an imaginary potential for name collisions. Why repeat the mistake of PyXML simply to have all the xml software in the same top level package? Perhaps if this were a common practice in the stdlib it might make sense. For instance, if there were a gui.Tkinter and a gui.PyGtk and a gui.wxPython it might look more consistent. Who is pushing to put all xml software inside the xml package? Collisions with names of a top level import statement are rare and Python has supports renaming in the rare event that someone did need to rename the module. import etree as stdetree. I would like the cElementTree version of the package have a shorter name. For example etree. The Python implementation could continue to be named ElementTree or shorten it to pyetree. The cElementTree version will probably be the most frequently used since it is faster, so why not make it's name short. One final addition would be to include a "See Also" reference to the new etree and pyetree modules in the introduction of the xml package. ___ 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-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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_ReadlineFunctionPointer in non-interractive input (2004-05-18) CLOSED http://python.org/sf/955928 reopened by loewis use PyOS_ReadlineFunctionPointer in non-interractive input (2005-11-27) http://python.org/sf/1367628 opened by Gregory Lielens Remove usage of UserDict from os.py (2005-11-27) http://python.org/sf/1367711 opened by Wolfgang Langner replace usage of UserDict with new dict class (2005-11-27) CLOSED http://python.org/sf/1367717 opened by Wolfgang Langner email/Charset.py (2005-11-28) http://python.org/sf/1368247 opened by Damjan Georgievski UUID module for Python (2005-11-29) http://python.org/sf/1368955 opened by Ka-Ping Yee Module fixedlenfields for standard lib (2005-11-29) http://python.org/sf/1369028 opened by Michael Ströder Fix of bug 1366000 (2005-11-30) http://python.org/sf/1370147 opened by STINNER Victor ConfigParser to accept a custom dict to allow ordering (2005-12-01) http://python.org/sf/1371075 opened by Micah Elliott fix UnixBrowswer failure when no browser running (2005-12-02) http://python.org/sf/1372125 opened by Greg Couch tiny chunk of unused code in cookielib (2005-12-04) CLOSED http://python.org/sf/1372836 opened by John J Lee Missing \versionadded in urllib2 and cookielib docs (2005-12-04) CLOSED http://python.org/sf/1372995 opened by John J Lee chunk.py can't handle >2GB chunks (2005-12-05) http://python.org/sf/1373643 opened by Christer Weinigel Tweak pprint.PrettyPrinter.format for subclassing (2005-12-05) http://python.org/sf/1373762 opened by Mark Hirota Broader iterable support for xmlrpclib (2005-12-05) http://python.org/sf/1374063 opened by Skip Montanaro Improper handling of duplicate cookies (2005-12-06) http://python.org/sf/1375011 opened by Viraj Alankar LibRef: reworked chapter organization (2005-12-07) http://python.org/sf/1375417 opened by A.M. Kuchling subprocess.CalledProcessError uses errno incorrectly (2005-12-08) http://python.org/sf/1376309 opened by Michael Hoffman Use 'seealso' to add examples to LibRef (2005-12-08) http://python.org/sf/1376361 opened by A.M. Kuchling fix description of format_exc in traceback doc (2005-12-08) http://python.org/sf/1376914 opened by Ilya Sandler xml.parsers.expat documentation fix (2005-12-10) http://python.org/sf/1377848 opened by Ori Avtalion weakref callbacks are called only if the weakref is alive (2005-12-12) http://python.org/sf/1379023 opened by Noam Raphael StreamReader.readline with size reading multiple lines (2005-12-13) http://python.org/sf/1379332 opened by Matthew Mueller Patches Closed __ use PyOS_ReadlineFunctionPointer in non-interractive input (2004-05-18) http://python.org/sf/955928 closed by greglielens use PyOS_ReadlineFunctionPointer in non-interractive input (2004-05-18) http://python.org/sf/955928 closed by greglielens EditorWindow's title with non-ASCII chars. (2005-03-14) http://python.org/sf/1162825 closed by loewis Fix for signal related abort in Visual Studio 2005 (2005-11-07) http://python.org/sf/1350409 closed by loewis PyOS_Readline (2005-07-04) http://python.org/sf/1232343 closed by dalcinl PyOS_Readline (2005-07-04) http://python.org/sf/1232343 deleted by dalcinl cgi: replace usage of UserDict with new dict class (2005-11-27) http://python.org/sf/1367717 closed by tds33 tiny chunk of unused code in cookielib (2005-12-04) http://python.org/sf/1372836 closed by akuchling SimpleXMLRPCServer.py optional allow_none argument (2004-02-09) http://python.org/sf/893642 closed by akuchling SimpleXMLRPCServer optional allow_none / encoding arguments (2004-10-02) http://python.org/sf/1039083 closed by akuchling Missing \versionadded in urllib2 and cookielib docs (2005-12-04) http://python.org/sf/1372995 closed by akuchling Adding new regrtest resource 'urlfetch' (2005-08-30) http://python.org/sf/1276356 closed by perky New / Reopened Bugs ___ maximum length not enforce in cgi.parse() (2005-11-27) http://python.org/sf/1367631 opened by Andrew Rogers loogger module locks (2005-11-27) http://python.org/sf/1367814 opened by Chris Fuller fix for scheme identification in urllib2? (2005-11-28) http://python.org/sf/1368312 opened by Ben Boals prompt_user_passwd() in FancyURLopener (2005-11-28) http://python.org/sf/1368368 opened by Björn Lindqvist python.dir still refers to python-w
Re: [Python-Dev] PEP 8 updates/clarifications
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, where the name of the class is > mangled into the attribute name. This helps avoid attribute name > collisions should subclasses inadvertently contain attributes with the > same name. > > Note 1: Note that only the simple class name is used in the mangled > name, so if a subclass chooses both the same class name and attribute > name, you can still get name collisions. > > Note 2: Name mangling can make certain uses, such as debugging, less > convenient. However the name mangling algorithm is well documented > and easy to perform manually. Hmm. How about just: "Put two leading underscores on an attribute's name to strongly discourage code outside the class from accessing it." -j ___ 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-archive.com
Re: [Python-Dev] ElementTree in stdlib
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. Strongly agree. This very morning I wrote a long tirade about how I wish Python had true coroutines, for the sole reason that I could wrap SAX in an iterator-based API. Eventually I decided it was SAX's fault for having such a crummy API, so I didn't post it. -j ___ 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-archive.com
Re: [Python-Dev] should I really have to install Python before Icanbuild it ?
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 behavior can bite if the script genuinely fails > > after you just made a typo in one of the input files, for example. > > Doesn't look particularly clean to me, if you want my opinion. > > Perhaps a good solution would be to have a separate make rule for > generating the AST code (i.e. not included in the overall dependancy > graph). That increases the chance that they don't get regenerated > when they should but people hacking on the AST files should notice > the error pretty easily. Other people should always be able to > build from the files checked in to SVN and so having the dependancy > there is just a source of trouble. > Sounds reasonable to me. Would just need to make sure that it is documented in the proper places so people know to do it. -Brett ___ 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-archive.com
Re: [Python-Dev] Sharing expat instances
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...) ___ 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-archive.com
Re: [Python-Dev] "xml" package in standard library
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. -Fred -- Fred L. Drake, Jr. ___ 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-archive.com
