Re: [Python-Dev] Python XML Validator
(weird places these threads come up at, but now that it's here...) Mike Meyer wrote: > On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote: >> In article <[EMAIL PROTECTED]>, >> Mike Meyer <[EMAIL PROTECTED]> wrote: >>> On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed >>> <[EMAIL PROTECTED]> wrote: lxml is good but not written in python and difficult to install and didn't work on MacOS X. Due to a design problem in MacOS-X, not a problem in lxml. But it's not that hard to install either, as previous posts presented. >>> lxml is built on top of libxml2/libxslt, which are bundled with most >>> Unix-like OS's (including Mac OS X), or available in their package >>> systems. Trying to install it from the repository is a PITA, because >>> it uses both the easyinstall and Pyrex (later Cython) packages Using a release version of lxml does not require you to install any of the two. Just download the tar.gz, unpack it, and do the usual setup.py dance. That's how package installation in Python works. It does, however, require you to have libxml2 and libxslt installed with their dependencies, but that has nothing to do with Python. >>> aren't bundled with anything. On the other hand, if it's in the >>> package system (I no longer have macports installed anywhere, but >>> believe it was there at one time), that solves all those problems. I >>> believe they've excised the easyinstall source dependencies, though. There is no source dependency on easy_install. I assume that all they did is: build lxml against the libxml2/libxslt libraries that come with macports. Which is a sensible thing to do IMHO. > I think lxml is the best Python XML library that meets his > requirements, and it would make my life a lot easier if it were part > of the standard library. I don't object to that. I'm just not a major driver here as it would require a bit of work that I can't currently spare. > However, the authors tend to require recent > versions of libxml2 and libxslt, which means recent versions of lxml > won't build and/or work with the libraries bundled with many Unix and > Unix-like systems I wouldn't consider a dependency on an almost three year old library version "recent", libxml2 2.6.20 was released in July 2005. > - including OSX. That's different, because the system libraries here are a) horribly outdated for every new version of MacOS-X (i.e. usually more than two years old and very buggy), and b) difficult to replace by design. > Which means you wind up having to > build those yourself if you want a recent version of lxml, even if > you're using a system that includes lxml in it's package system. If you want a clean system, e.g. for production use, buildout has proven to be a good idea. And we also provide pretty good instructions on our web page on how to install lxml on MacOS-X and what to take care of. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python XML Validator
Mike Meyer wrote: > On Wed, 05 Mar 2008 13:01:14 +1300 Greg Ewing <[EMAIL PROTECTED]> wrote: > >> Mike Meyer wrote: >>> Trying to install it from the repository is a PITA, because >>> it uses both the easyinstall and Pyrex >> It shouldn't depend on Pyrex as long as it's distributed >> with the generated C files. If it's not, that's an >> oversight on the part of the distributor. > > Sorry I wasn't clear. "from the repository" means building from > sourced checked out of the source repository, not from a > distribution. Ok, uhm, what do you think we do releases for? :) Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler used to build Python for Windows
Martin v. Löwis wrote: >> I think the best lesson here is Tcl. Because it uses stubs mechanism, >> you don't need to depend on tclXX.dll, you don't deal with really >> direct implementation details, you don't care about runtimes, >> everything is much easier. Maybe it's possible (and not too late) for >> Python to somehow embrace such mechanism? > > It would be possible, but it would be a fairly large project. You would > have to remove a lot of things from the Python header files, and that > would cause significant breakage in existing extension modules. Hmm, would it? I mean, you can currently build extensions with MinGW (at least from what I heard, I never managed to do so as it would require cross compiling for Windows), so why would you say you'd have to update the header files? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python XML Validator
On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel <[EMAIL PROTECTED]> wrote: > (weird places these threads come up at, but now that it's here...) > Mike Meyer wrote: > > On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote: > >> In article <[EMAIL PROTECTED]>, > >> Mike Meyer <[EMAIL PROTECTED]> wrote: > >>> On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed > >>> <[EMAIL PROTECTED]> wrote: > lxml is good but not written in python and difficult to install and > didn't > work on MacOS X. Please note that this original complaint is *not* mine. However... > Due to a design problem in MacOS-X, not a problem in lxml. I didn't find it noticeably harder to install lxml on MacOS-X than most other systems. > But it's not that hard to install either, as previous posts presented. Depends on how you define "hard". If I have to create a custom environment with updated version of system libraries just to use lxml, I'd call that "hard". That was pretty much the only route available the first time I wanted lxml on OS-X. And ubuntu. And RHEL. The second time for OS-X, I used an older version of lxml (1.3.6), and just did "setup.py install". Worked like a charm. That's not hard. The only system that installing a modern version of lxml on was easy was FreeBSD, probably because libxml2 and libxslt aren't part of the system software. > > However, the authors tend to require recent > > versions of libxml2 and libxslt, which means recent versions of lxml > > won't build and/or work with the libraries bundled with many Unix and > > Unix-like systems > I wouldn't consider a dependency on an almost three year old library version > "recent", libxml2 2.6.20 was released in July 2005. Well, if you're on a development box that you update regularly, you're right: three years old is pretty old. If you're talking about a production box that you don't touch unless you absolutely have to, you're wrong: three years old is still pretty recent. For example, the most recent release of RHEL is 4.6, which ships with libxml2 2.6.16. > > Which means you wind up having to > > build those yourself if you want a recent version of lxml, even if > > you're using a system that includes lxml in it's package system. > If you want a clean system, e.g. for production use, buildout has proven to be > a good idea. And we also provide pretty good instructions on our web page on > how to install lxml on MacOS-X and what to take care of. Yes, but the proposal was to include it in the Python standard library. Software that doesn't work on popular target platforms without updating a standard system library isn't really suitable for that. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python XML Validator
Mike Meyer wrote: > On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel <[EMAIL PROTECTED]> wrote: >> (weird places these threads come up at, but now that it's here...) >> Mike Meyer wrote: >>> On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote: In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed > <[EMAIL PROTECTED]> wrote: >> lxml is good but not written in python and difficult to install and >> didn't >> work on MacOS X. > > Please note that this original complaint is *not* mine. However... > >> Due to a design problem in MacOS-X, not a problem in lxml. > > I didn't find it noticeably harder to install lxml on MacOS-X than > most other systems. It seems to be for a number of people, though, who turn up on the mailing list complaining about just that. >> But it's not that hard to install either, as previous posts presented. > > Depends on how you define "hard". If I have to create a custom > environment with updated version of system libraries just to use lxml, > I'd call that "hard". That was pretty much the only route available > the first time I wanted lxml on OS-X. And ubuntu. And RHEL. It got a lot better by now. The only problem is how to tell your operating system where to look for libraries that you installed yourself (which I still refuse to consider a problem of lxml). BTW, we had MacOS builds a while ago, so I wouldn't mind having someone volunteer to contribute builds on a regular basis (static builds preferred). > The second time for OS-X, I used an older version of lxml (1.3.6), and > just did "setup.py install". Worked like a charm. That's not hard. Interesting. 1.3.6 should also require libxml2 2.6.20 (although maybe less strictly than 2.0). >>> However, the authors tend to require recent >>> versions of libxml2 and libxslt, which means recent versions of lxml >>> won't build and/or work with the libraries bundled with many Unix and >>> Unix-like systems >> I wouldn't consider a dependency on an almost three year old library version >> "recent", libxml2 2.6.20 was released in July 2005. > > Well, if you're on a development box that you update regularly, you're > right: three years old is pretty old. If you're talking about a > production box that you don't touch unless you absolutely have to, > you're wrong: three years old is still pretty recent. For example, the > most recent release of RHEL is 4.6, which ships with libxml2 2.6.16. Ok, that's pretty old, although that was the last version we supported before requiring 2.6.20 (last summer, somewhere in the 1.3 series). Anyway, it's definitely less of a problem to upgrade system libraries on Linux (IIRC "rpm -bs" helps you on older RH*L versions) than under MacOS. >>> Which means you wind up having to >>> build those yourself if you want a recent version of lxml, even if >>> you're using a system that includes lxml in it's package system. >> If you want a clean system, e.g. for production use, buildout has proven to >> be >> a good idea. And we also provide pretty good instructions on our web page on >> how to install lxml on MacOS-X and what to take care of. > > Yes, but the proposal was to include it in the Python standard > library. Software that doesn't work on popular target platforms > without updating a standard system library isn't really suitable for > that. Hmm, coming somewhat back on-topic: how does Python currently handle its dependencies under MacOS-X? SQLite, for example? Does it use system libraries only, or are there libraries it ships with? (The MacOS distro is much bigger, but that might be due to the universal build - although that suggests that MacOS-X users do not care about disk space or download size anyway) It looks like it already ships with expat on all platforms, so why not add libxml2/libxslt to the distribution, at least on platforms where it's necessary? (happily ignoring the fact here that lxml isn't currently even close to being integrated) Admittedly, that would add some 1.3MB (uncompressed) to the distro... Regarding updated version requirements: those are always discussed on the mailing list. The only reason we had for continued support of 2.6.16 was MacOS-X 10.4, until we found that most users installed newer libraries anyway, because the old ones were just too old and crash-prone. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
Daniel Stutzbach wrote: > On Sun, Mar 9, 2008 at 9:22 AM, Aahz <[EMAIL PROTECTED]> wrote: >> There probably would be some value in a wiki page on python.org that >> provides this information, particularly across versions. You may be >> able to find volunteers to help on comp.lang.python. > > I just created a very basic one at > http://wiki.python.org/moin/TimeComplexity?action=show > > I'm not that familiar with the Wiki syntax, so the tables are kind of > ugly at the moment. > > I wasn't sure about many of the set() operations, so I didn't include those. > Thanks! I'm interested too in some operations I don't know about, I think I'll just add them with blank fields so that eventually people who know fill them out. Dimitris P.S. This wiki is really bad in tables: I can't figure out how to draw a border for the tables and every table element contains a tag, making the cell spanning 2-3 lines of height... :-@ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler used to build Python for Windows
>>> I think the best lesson here is Tcl. Because it uses stubs mechanism, >>> you don't need to depend on tclXX.dll, you don't deal with really >>> direct implementation details, you don't care about runtimes, >>> everything is much easier. Maybe it's possible (and not too late) for >>> Python to somehow embrace such mechanism? >> It would be possible, but it would be a fairly large project. You would >> have to remove a lot of things from the Python header files, and that >> would cause significant breakage in existing extension modules. > > Hmm, would it? I mean, you can currently build extensions with MinGW (at least > from what I heard, I never managed to do so as it would require cross > compiling for Windows), so why would you say you'd have to update the header > files? I wasn't talking about building with other compilers, but about the subject of the Tcl stub mechanism being applied to Python. As others noted, that mechanism doesn't help at all with the issue of different CRTs. It does help with another issue, though, namely the constant ABI changes that we see. Every time the ABI changes, extension modules have to be recompiled. With a scheme similar to Tcl stubs, that need could go away. This would be particularly useful on Windows, where each feature release comes up with the new DLL name. With such a mechanism in place, we could do "python3.dll" (rather than python30.dll, python31.dll, and so on). To implement such a system, you need to get all ABI dependencies out of the header files; this includes the structure layouts in particular. You might want to keep struct _object, for sake of INCREF/DECREF. You then need to specify which of the remaining functions officially belongs to the ABI, and freeze them for the lifetime of Python 3. New functions can be added, but when changing the signature, the old functions must remain in place. In Tcl stubs, that is achieved through a function vector, IIUC. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ANN] Python 2.3.7 and 2.4.5 (final)
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.5 and 2.3.7 (final). Both releases include only security fixes. Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.3 or 2.4. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed; most of them prevent interpreter crashes (and now cause proper Python exceptions in cases where the interpreter may have crashed before). Since the release candidate, we received various reports that the this release may fail to build on current operating systems, in particular on OS X. We have made no attempt to fix these problems, as the release is targeted for systems that were current at the time Python 2.4 was originally released. For more recent systems, you might have to come up with work-arounds. For OS X in particular, try invoking:: ./configure MACOSX_DEPLOYMENT_TARGET=10.5 We have made no changes since the release candidate (except for the version numbers). For more information on Python 2.3.7 and 2.4.5, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.3.7 http://www.python.org/2.4.5 Highlights of the previous major Python releases are available from the Python 2.4 page, at http://www.python.org/2.3/highlights.html http://www.python.org/2.4/highlights.html Enjoy this release, Martin Martin v. Loewis [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
> Can you really say that you don't make any design > decisions early on based on the assumption that > dict lookup will almost certainly be a lot faster > than searching a list? I follow the advice Guido gave: I use the data structure that will make my code shortest and easiest to read, regardless of performance consequences initially. Premature optimization is the root of all evil. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [OT] Python mentioned on OOPSLA 2008 postcard
I just got my postcard announcing OOPSLA 2008. Interesting thing is that the postcard, which lists various things that will be at OOPSLA, includes Python. It's actually listed in the first line and the thing is not alphabetized. And even cooler, it is the first language listed (ruby, Objective-C, C#, and Java are also listed). Anyway, thought other might get a kick out of this like I did. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
"Martin v. Löwis" writes: > Premature optimization is the root of all evil. Actually, Knuth's bon mot was "Premature optimization is the root of all error." Which is probably worse; it leaves the perpetrator the excuse "but I was only trying to help!" While we all know what to do to evildoers, it's hard to punish those who deliberately invite Murphy's attention as severely as they deserve. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Python mentioned on OOPSLA 2008 postcard
Well maybe they'll invite me as a speaker now. ;-) On Tue, Mar 11, 2008 at 3:34 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I just got my postcard announcing OOPSLA 2008. Interesting thing is > that the postcard, which lists various things that will be at OOPSLA, > includes Python. It's actually listed in the first line and the thing > is not alphabetized. And even cooler, it is the first language listed > (ruby, Objective-C, C#, and Java are also listed). > > Anyway, thought other might get a kick out of this like I did. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler used to build Python for Windows
Martin v. Löwis wrote: > To implement such a system, you need to get all ABI dependencies out > of the header files; this includes the structure layouts in particular. That could hurt the performance of some things. Macros like PyList_GET_ITEM etc. rely on knowing about struct layouts to get at things quickly. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
On Wed, Mar 12, 2008, Stephen J. Turnbull wrote: > "Martin v. L?wis" writes: >> >> Premature optimization is the root of all evil. > > Actually, Knuth's bon mot was "Premature optimization is the root of > all error." >From my .sig database: "Premature optimization is the root of all evil in programming." --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting Hoare) "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Knuth restates Hoare -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
Martin v. Löwis wrote: > I follow the advice Guido gave: I use the data > structure that will make my code shortest and easiest > to read, But given a choice such as list vs. dict, the code is almost identical either way. What do you do then? Toss a coin? Or make a few educated guesses based on what you know about each data type? > Premature optimization is the root of all evil. This phrase seems to be widely misused. Making your code bloated and convoluted without good evidence of the necessity is premature optimisation. Picking an appropriate data structure for the task based on experience is good design practice. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
>> I follow the advice Guido gave: I use the data >> structure that will make my code shortest and easiest >> to read, > > But given a choice such as list vs. dict, the code > is almost identical either way. What do you do then? Why do you say that? Lists and dictionaries are *completely* different things, not interchangeable at all. > Toss a coin? Or make a few educated guesses based on > what you know about each data type? I look at my problem, and the choice of container falls out of that naturally. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler used to build Python for Windows
>> To implement such a system, you need to get all ABI dependencies out >> of the header files; this includes the structure layouts in particular. > > That could hurt the performance of some things. Macros > like PyList_GET_ITEM etc. rely on knowing about struct > layouts to get at things quickly. OTOH, they are discouraged for use outside the core already. Use PyList_GetItem, and you won't notice the difference. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
