Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
We need someone to maintain the copy of ElementTree in the Python repository. We have one: Fredrik Lundh. Ideally this means pulling upgrades and bugfixes from Fredrik's repository every now and then. If the goals of Python ElementTree and Fredrik ElementTree diverge I don't see a problem with an amicable fork. I see one: Fredrik will not consider such a fork amicable. Of course, if you could make him state in public that he is fine with a procedure that you propose, go ahead. He had stated in public that he is fine with the procedure I'm defending right now, that's why I'm defending it: no substantial changes without his explicit approval (breakage due to language changes is about the only exception - not even bug fixes are allowed). 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Sat, Feb 20, 2010 at 9:57 AM, Martin v. Löwis mar...@v.loewis.de wrote: We need someone to maintain the copy of ElementTree in the Python repository. We have one: Fredrik Lundh. The last commits by Fredrik to ElementTree in Python SVN that I can see are dated 2006-08-16. The last commits I can see to ElementTree at http://svn.effbot.python-hosting.com/ are dated 2006-07-05. To paraphrase Antoine's comment [1] on Rietveld -- we need a process that results in bug fixes for users of the copy of ElementTree in Python. [1] http://codereview.appspot.com/207048/show (most direct link I could find) Schiavo Simon ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Florent Xicluna, 18.02.2010 10:21: For this purpose, I grew the test suite from 300 lines to 1800 lines, using both the tests from upstream and the tests proposed by Neil Muller on issue #6232. Just a comment on this. While the new tests may work with ElementTree as is, there are a couple of problem with them. They become apparent when running the test suite against lxml.etree. Some of the tests depend on specifics of the serialiser that may not be guaranteed, such as the order of attributes or namespace declarations in a tag, or whitespace before the self-closing tag terminator ( /). ET 1.3 has a mostly redesigned serialiser, and it may receive another couple of improvements or changes before it comes out. None of theses features is really required to hold for anything but the current as-is implementation. Other tests rely on non-XML being serialised, such as 'textsubtagsubtext/subtag' This is achieved by setting root.tag to None - I'm not sure this is a feature of ElementTree, and I'd be surprised if it was documented anywhere. Several of the tests also use invalid namespace URIs like uri or non well-formed attribute names like 123. That's bad style at best. There are also some tests for implementation details, such as the _cache in ElementPath or the parser version (requiring expat), or even this test: element.getiterator == element.iter which doesn't apply to lxml.etree, as its element.getiterator() complies with the ET 1.2 interface for compatibility, whereas the new element.iter() obeys the ET 1.3 interface that defines it. Asserting both to be equal doesn't make much sense in the context of their specification. Another example is check_method(element.findall(*).next) In lxml.etree, this produces an AttributeError: 'list' object has no attribute 'next' because element.findall() is specified in the official ET documentation to return a list or iterator, i.e. not necessarily an iterator but always an iterable. There is an iterfind() that would do the above, which matches ET 1.3. So my impression is that many of the tests try to provide guarantees where they cannot or should not exist, and even where the output is clearly non-conforming with respect to standards. I don't think it makes sense to put these into a regression test suite. That said, I should add that lxml's test suite includes about 250 unit tests that work with (and adapt to) lxml.etree, ElementTree and cElementTree, in Py2.3+ and Py3.x, and with ET 1.2 and ET 1.3. Although certainly not a copyrun replacement, those should be much better suited to accompany the existing stdlib tests. Stefan ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Stefan Behnel stefan_ml at behnel.de writes: Florent Xicluna, 18.02.2010 10:21: For this purpose, I grew the test suite from 300 lines to 1800 lines, using both the tests from upstream and the tests proposed by Neil Muller on issue #6232. Just a comment on this. While the new tests may work with ElementTree as is, there are a couple of problem with them. They become apparent when running the test suite against lxml.etree. The test suite in the stdlib targets the xml.etree implementations only. None of theses features is really required to hold for anything but the current as-is implementation. I agree. So my impression is that many of the tests try to provide guarantees where they cannot or should not exist, and even where the output is clearly non-conforming with respect to standards. I don't think it makes sense to put these into a regression test suite. The test suite in the stdlib should try to cover every piece of code, even implementation details and edge cases. It guarantees that the implementation details do not change between minor releases. And it helps identify regression or evolution of the behavior when the library is updated. However we may identify better each category of tests: - tests for the ElementTree API 1.2, which should pass with lxml.etree, too. - tests of implementation details, which are not part of the specification. Additionally, these tests ensure that the C implementation can be used as a drop-in replacement of the Python implementation. It is a request expressed by many users of the xml.etree package. That said, I should add that lxml's test suite includes about 250 unit tests that work with (and adapt to) lxml.etree, ElementTree and cElementTree, in Py2.3+ and Py3.x, and with ET 1.2 and ET 1.3. Although certainly not a copyrun replacement, those should be much better suited to accompany the existing stdlib tests. Interesting. I may add these tests to the test_suite, if they are not completely redundant. -- Florent Xicluna ___ 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] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. So if you can't test it, why would you state it as a fact... and then back-pedal? :) It was a question, not a statement! Plus, I figured I could con someone into testing it for me. Mission accomplished. :) Thanks for investigating. Eric. ___ 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] Buffered streams design + raw io gotchas
Allright, so in the case of regular files I may content myself of BufferedRandom. And maybe I'll put some warnings concerning the returning of raw streams by factory functions. Thanks, Regards, Pascal Guido van Rossum a écrit : IIRC here is the use case for buffered reader/writer vs. random: a disk file opened for reading and writing uses a random access buffer; but a TCP stream stream, while both writable and readable, should use separate read and write buffers. The reader and writer don't have to worry about reversing the I/O direction. But maybe I'm missing something about your question? --Guido On Thu, Feb 18, 2010 at 1:59 PM, Pascal Chambon chambon.pas...@gmail.com wrote: Hello, As I continue experimenting with advanced streams, I'm currently beginning an important modification of io's Buffered and Text streams (removal of locks, adding of methods...), to fit the optimization process of the whole library. However, I'm now wondering what the idea is behind the 3 main buffer classes : Bufferedwriter, Bufferedreader and Bufferedrandom. The i/o PEP claimed that the two first ones were for sequential streams only, and the latter for all kinds of seekable streams; but as it is implemented, actually the 3 classes can be returned by open() for seekable files. Am I missing some use case in which this distinction would be useful (for optimizations ?) ? Else, I guess I should just create a RSBufferedStream class which handles all kinds of situations, raising InsupportedOperation exceptions whenever needed after all, text streams act that way (there is no TextWriter or TextReader stream), and they seem fine. Also, io.open() might return a raw file stream when we set buffering=0. The problem is that raw file streams are NOT like buffered streams with a buffer limit of zero : raw streams might fail writing/reading all the data asked, without raising errors. I agree this case should be rare, but it might be a gotcha for people wanting direct control of the stream (eg. for locking purpose), but no silently incomplete read/write operation. Shouldn't we rather return a write through buffered stream in this case buffering=0, to cleanly handle partial read/write ops ? regards, Pascal PS : if you have 3 minutes, I'd be very interested by your opinion on the advanced modes draft below. Does it seem intuitive to you ? In particular, shouldn't the + and - flags have the opposite meaning ? http://bytebucket.org/pchambon/python-rock-solid-tools/wiki/rsopen.html ___ 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/guido%40python.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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Florent Xicluna, 20.02.2010 11:53: Stefan Behnel writes: None of theses features is really required to hold for anything but the current as-is implementation. I agree. So my impression is that many of the tests try to provide guarantees where they cannot or should not exist, and even where the output is clearly non-conforming with respect to standards. I don't think it makes sense to put these into a regression test suite. The test suite in the stdlib should try to cover every piece of code, even implementation details and edge cases. It shouldn't test for un(der)defined or non-guaranteed behaviour, bugs or the /absence/ of certain features, though. Apart from that, I agree with the following: It guarantees that the implementation details do not change between minor releases. And it helps identify regression or evolution of the behavior when the library is updated. Additionally, these tests ensure that the C implementation can be used as a drop-in replacement of the Python implementation. It is a request expressed by many users of the xml.etree package. That's certainly a worthy goal, but it's orthogonal to the interest of changing/improving/evolving ElementTree itself. The goal here is to make cElementTree compatible with ET, without any impact on ET. I agree with Fredrik that there are a number of additional features in ET 1.3 (and lxml 2.x) that can be easily added to the existing API, e.g. the element.extend() method. Other new features (and certainly the incompatible changes) are a lot more controversial, though. That said, I should add that lxml's test suite includes about 250 unit tests that work with (and adapt to) lxml.etree, ElementTree and cElementTree, in Py2.3+ and Py3.x, and with ET 1.2 and ET 1.3. Although certainly not a copyrun replacement, those should be much better suited to accompany the existing stdlib tests. Interesting. I may add these tests to the test_suite, if they are not completely redundant. They certainly were not redundant with the original tests that shipped with ET, and they test all sorts of funny cases. The main files are https://codespeak.net/viewvc/lxml/trunk/src/lxml/tests/test_elementtree.py?view=markup https://codespeak.net/viewvc/lxml/trunk/src/lxml/tests/test_io.py?view=markup There are also a number of ET API tests in other parts of the test suite (mostly test_etree.py, also test_unicode.py). Some of them would work with ET but produce different results due to various reasons, including the fact that lxml.etree behaves more correct in some cases. The latter are the kind of tests that I would prefer not to see in the stdlib test suite. Stefan ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Martin v. Löwis martin at v.loewis.de writes: If the goals of Python ElementTree and Fredrik ElementTree diverge I don't see a problem with an amicable fork. I see one: Fredrik will not consider such a fork amicable. Of course, if you could make him state in public that he is fine with a procedure that you propose, go ahead. He had stated in public that he is fine with the procedure I'm defending right now, that's why I'm defending it: no substantial changes without his explicit approval (breakage due to language changes is about the only exception - not even bug fixes are allowed). Actually this should not be a fork of the upstream library. The goal is to improve stability and predictability of the ElementTree implementations in the stdlib, and to fix some bugs. I thought that it is better to backport the fixes from upstream than to fix each bug separately in the stdlib. I try to get some clear assessment from Fredrik. If it is accepted, I will probably cut some parts which are in the upstream library, but which are not in the API 1.2. If it is not accepted, it is bad news for the xml.etree users... It is qualified as a best effort to get something better for ET. Nothing else. -- Florent “Nobody expects the Spanish Inquisition!” ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
The last commits by Fredrik to ElementTree in Python SVN that I can see are dated 2006-08-16. The last commits I can see to ElementTree at http://svn.effbot.python-hosting.com/ are dated 2006-07-05. And? To paraphrase Antoine's comment [1] on Rietveld -- we need a process that results in bug fixes for users of the copy of ElementTree in Python. [1] http://codereview.appspot.com/207048/show (most direct link I could find) To quote Fredrik Lundh from the same reviews: # You do realize that you're merging in an experimental release, right? # I'm a bit worried that the result of this effort will be plenty of # incompatibilities with the upstream library (and there are also signs # on bugs.python.org that some people involved don't understand the # difference between specification of a portable API and artifacts of a # certain implementation of the same API), but I'm travelling right now, # and have no bandwidth to deal with this. Just be careful. # Since you've effectively hijacked the library, and have created your # own fork that's not fully compatible with any formal release of the # upstream library, and am not contributing any patches back to # upstream, I suggest renaming it instead. This may be politely phrased, but it seems that he is quite upset about these proposed changes. I'd rather drop ElementTree from the standard library than fork it. 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Actually this should not be a fork of the upstream library. The goal is to improve stability and predictability of the ElementTree implementations in the stdlib, and to fix some bugs. I thought that it is better to backport the fixes from upstream than to fix each bug separately in the stdlib. I try to get some clear assessment from Fredrik. If it is accepted, I will probably cut some parts which are in the upstream library, but which are not in the API 1.2. If it is not accepted, it is bad news for the xml.etree users... Not sure about the timing, but in case you have not got the message: we should rather drop ElementTree from the standard library than integrate unreleased changes from an experimental upstream repository. It is qualified as a best effort to get something better for ET. Nothing else. Unfortunately, it hurts ET users if it ultimately leads to a fork, or to a removal of ET from the standard library. Please be EXTREMELY careful. I urge you not to act on this until mid-March (which is the earliest time at which Fredrik has said he may have time to look into this). 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] Buffered streams design + raw io gotchas
Not really, BufferedRandom is only suitable when the file is open for reading *and* writing. The 'rb' and 'wb' modes should return BufferedReader and BufferedWriter, respectively. On Sat, Feb 20, 2010 at 6:20 AM, Pascal Chambon chambon.pas...@gmail.com wrote: Allright, so in the case of regular files I may content myself of BufferedRandom. And maybe I'll put some warnings concerning the returning of raw streams by factory functions. Thanks, Regards, Pascal Guido van Rossum a écrit : IIRC here is the use case for buffered reader/writer vs. random: a disk file opened for reading and writing uses a random access buffer; but a TCP stream stream, while both writable and readable, should use separate read and write buffers. The reader and writer don't have to worry about reversing the I/O direction. But maybe I'm missing something about your question? --Guido On Thu, Feb 18, 2010 at 1:59 PM, Pascal Chambon chambon.pas...@gmail.com wrote: Hello, As I continue experimenting with advanced streams, I'm currently beginning an important modification of io's Buffered and Text streams (removal of locks, adding of methods...), to fit the optimization process of the whole library. However, I'm now wondering what the idea is behind the 3 main buffer classes : Bufferedwriter, Bufferedreader and Bufferedrandom. The i/o PEP claimed that the two first ones were for sequential streams only, and the latter for all kinds of seekable streams; but as it is implemented, actually the 3 classes can be returned by open() for seekable files. Am I missing some use case in which this distinction would be useful (for optimizations ?) ? Else, I guess I should just create a RSBufferedStream class which handles all kinds of situations, raising InsupportedOperation exceptions whenever needed after all, text streams act that way (there is no TextWriter or TextReader stream), and they seem fine. Also, io.open() might return a raw file stream when we set buffering=0. The problem is that raw file streams are NOT like buffered streams with a buffer limit of zero : raw streams might fail writing/reading all the data asked, without raising errors. I agree this case should be rare, but it might be a gotcha for people wanting direct control of the stream (eg. for locking purpose), but no silently incomplete read/write operation. Shouldn't we rather return a write through buffered stream in this case buffering=0, to cleanly handle partial read/write ops ? regards, Pascal PS : if you have 3 minutes, I'd be very interested by your opinion on the advanced modes draft below. Does it seem intuitive to you ? In particular, shouldn't the + and - flags have the opposite meaning ? http://bytebucket.org/pchambon/python-rock-solid-tools/wiki/rsopen.html ___ 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/guido%40python.org -- --Guido van Rossum (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] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. Here comes my nit picking mode again. ;) First of all the links are not a feature of the operating system but rather a feature of the file system (version). The fact is valid for Unix as well but most Unix file systems support hard- and soft links anyway. To my best knowledge links are only supported on NTFS. FAT doesn't support links and IIRC it's not possible to create a hard link on a remote file system. NTFS supports POSIX style hard links of files that are limited to one file system. It's not possible to create a hard link that points to another file system. This constrain also applies to Unix. Since Windows 2000 NTFS has junction points that work similar to symbolic link on directories within a local file system. Junction points should be avoided because the Windows explorer can't handle them properly until Windows Vista. Since Vista NTFS also has symbolic links that work across file systems and can point to remote locations and non-existing files, too. However only administrators are allowed to create symlinks on Vista. Vista has no builtin tool to lift the restriction for ordinary users. You have to grab some files from Windows Server 2003 for the task. As long as Python supports XP we shouldn't use symlinks on Windows for stuff like virtualenv. The python.exe on Windows is small (just a few kb) since it is linked against the dll. Let's copy it and we are on the safe side. Christian ___ 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] Proposal for virtualenv functionality in Python
Christian Heimes wrote: good stuff deleted As long as Python supports XP we shouldn't use symlinks on Windows for stuff like virtualenv. The python.exe on Windows is small (just a few kb) since it is linked against the dll. Let's copy it and we are on the safe side. +1. Even if we dropped XP I'm not sure moving to symlinks for this would be the right thing to do. Eric. ___ 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] Proposal for virtualenv functionality in Python
First of all the links are not a feature of the operating system but rather a feature of the file system (version). That's not really true. Even though ext2 supports symbolic links, on XP with an ext2 driver, you still don't get symbolic links. So you need the feature *both* in the operating system and the file system. The fact is valid for Unix as well but most Unix file systems support hard- and soft links anyway. As do most Unix implementations - but I still remember Unix implementations which didn't support symlinks, not even in the API. To my best knowledge links are only supported on NTFS. FAT doesn't support links and IIRC it's not possible to create a hard link on a remote file system. The latter is not really true: NFS most certainly supports hard links. I can't try right now, but I would be surprised if SMB didn't support both symbolic and hard links, given the right server and client versions. 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Le Sat, 20 Feb 2010 13:08:39 +0100, Martin v. Löwis a écrit : Please be EXTREMELY careful. I urge you not to act on this until mid-March (which is the earliest time at which Fredrik has said he may have time to look into this). Ok, so let's wait until then before we make a decision. cheers Antoine. ___ 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] Proposal for virtualenv functionality in Python
Martin v. Löwis wrote: The latter is not really true: NFS most certainly supports hard links. I can't try right now, but I would be surprised if SMB didn't support both symbolic and hard links, given the right server and client versions. I've never seen nor used NFS on Windows so I can't comment on NFS. Some time ago I did some experiments with links but I wasn't able to create a hard link on a remote SMB server. However Wikipedia claims that CIFS support hard and sym links. Your conclusion regarding server and client version sounds plausible. In my humble opinion links are aliens on Windows. I wouldn't use them to implement virtualenv. :) Christian ___ 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] Proposal for virtualenv functionality in Python
Am 20.02.2010 06:37, schrieb Michael Foord: -- http://www.ironpythoninaction.com Nice signature! On 19 Feb 2010, at 22:52, Eric Smith e...@trueblade.com wrote: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. They do if you add .lnk to your PATHEXT environment variable. Which is something we probably don't want to do globally. Georg ___ 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] Proposal for virtualenv functionality in Python
On Fri, Feb 19, 2010 at 10:39 PM, Glenn Linderman v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the real prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have shortcuts but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. Virtualenv uses copies when it can't use symlinks. A copy (or hard link) seems appropriate on systems that do not have symlinks. It would seem reasonable that on Windows it might look in the registry to find the actual location where Python was installed. Or... whatever technique Windows people think is best; it's simply necessary that the interpreter know its location (the isolated environment) and also know where Python is installed. All this needs to be calculated in C, as the standard library needs to be on the path very early (so os.symlink wouldn't help, but any C-level function to determine this would be helpful). (It's maybe a bit lame of me that I'm dropping this in the middle of PyCon, as I'm not online frequently during the conference; sorry about that) -- Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Sat, Feb 20, 2010 at 2:03 PM, Martin v. Löwis mar...@v.loewis.de wrote: I'd rather drop ElementTree from the standard library than fork it. Fork what? Upstream ElementTree is dead. Schiavo Simon ___ 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] Proposal for virtualenv functionality in Python
At 02:41 PM 2/20/2010 -0500, Ian Bicking wrote: Virtualenv uses copies when it can't use symlinks. Â A copy (or hard link) seems appropriate on systems that do not have symlinks. Â It would seem reasonable that on Windows it might look in the registry to find the actual location where Python was installed. Â Or... whatever technique Windows people think is best; it's simply necessary that the interpreter know its location (the isolated environment) and also know where Python is installed. Â All this needs to be calculated in C, as the standard library needs to be on the path very early (so os.symlink wouldn't help, but any C-level function to determine this would be helpful). The ways pretty much boil down to: 1. Explicit per-instance configuration (either appended to the .exe or in a file adjacent to it), 2. An implicit global search/lookup (PATH, registry, etc.) 3. A combination of the two, checking explicit configuration before implicit. Since the virtualenv itself may need some kind of nearby configuration anyway, putting it in that file seems to me like the One Obvious Way To Do It. Windows does have C-level APIs for reading and writing .ini files, from the good old days before the registry existed. And the C-level code might only need to read one entry prior to booting Python anyway - a single call to the GetPrivateProfileString function, once you've determined the name of the file to be read from. ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100220 13:04], Martin v. Löwis (mar...@v.loewis.de) wrote: The last commits by Fredrik to ElementTree in Python SVN that I can see are dated 2006-08-16. The last commits I can see to ElementTree at http://svn.effbot.python-hosting.com/ are dated 2006-07-05. And? [snip] # Since you've effectively hijacked the library, and have created your # own fork that's not fully compatible with any formal release of the # upstream library, and am not contributing any patches back to # upstream, I suggest renaming it instead. This may be politely phrased, but it seems that he is quite upset about these proposed changes. I'd rather drop ElementTree from the standard library than fork it. Maybe I am fully misunderstanding something here and I am also known for just bluntly stating things but: Isn't inclusion into the standard library under the assumption that maintenance will be performed on the code? With all due respect to Frederik, but if you add such a module to the base distribution and then ignore it for 3-4 years I personally have a hard time feeling your 'outrage' being justified for someone who is trying to fix outstanding issues in ElementTree. I also do not find your idea of dropping the module productive either Martin. Just dropping it for no other reason because someone cannot be bothered to act as a responsible maintainer just seems not useful for Python users at all. Especially since patches *are* available. If Frederik has problems with that he should have put a bit more effort into maintaining it in the first place. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B In this short time of promise, you're a memory... ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Maybe I am fully misunderstanding something here and I am also known for just bluntly stating things but: Isn't inclusion into the standard library under the assumption that maintenance will be performed on the code? In general, that's the assumption, and Guido has stated that he dislikes exceptions. However, Fredrik's code was included only under the exception. ElementTree wouldn't be part of the standard library if an exception had not been made. With all due respect to Frederik, but if you add such a module to the base distribution and then ignore it for 3-4 years I personally have a hard time feeling your 'outrage' being justified for someone who is trying to fix outstanding issues in ElementTree. If users and co-developers think that these issues absolutely must be resolved now (rather than waiting some more), I see only two options: a) ElementTree is removed from the library b) we declare that we fork ElementTree, and designate a maintainer. Just fixing the bugs without designating a maintainer is *not* an option, because we absolutely need somebody to pronounce on changes. It will not be Guido, and if it is not Fredrik, somebody else must step forward. I would then ask that person, as the first thing, to rename the package when making incompatible changes. I also do not find your idea of dropping the module productive either Martin. Just dropping it for no other reason because someone cannot be bothered to act as a responsible maintainer just seems not useful for Python users at all. Especially since patches *are* available. Well, I promised that we will stick to the procedure when integrating ElementTree. I'm not willing to break this promise. 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100220 22:47], Martin v. Löwis (mar...@v.loewis.de) wrote: In general, that's the assumption, and Guido has stated that he dislikes exceptions. However, Fredrik's code was included only under the exception. ElementTree wouldn't be part of the standard library if an exception had not been made. I was not fully aware of that bit of history, my thanks for enlightening me on it. If users and co-developers think that these issues absolutely must be resolved now (rather than waiting some more), I see only two options: a) ElementTree is removed from the library b) we declare that we fork ElementTree, and designate a maintainer. Just fixing the bugs without designating a maintainer is *not* an option, because we absolutely need somebody to pronounce on changes. It will not be Guido, and if it is not Fredrik, somebody else must step forward. I would then ask that person, as the first thing, to rename the package when making incompatible changes. Call me a sceptic or pragmatist, but I don't see the situation change suddenly from what it has been for the past couple of years. I vaguely remember running into problems or limitations myself with ElementTree and switching to lxml at one point. It sort of has to escalate now in order to get the maintainer to look at it and I doubt that's how we want to keep operating in the future? So the choice of removal or forking may actually be quite imminent, but of course, that's my interpretation of things. Well, I promised that we will stick to the procedure when integrating ElementTree. I'm not willing to break this promise. Honourable and I can understand that. Although it doesn't make it flexible to work on. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The fragrance always stays in the hand that gives the rose... ___ 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] Proposal for virtualenv functionality in Python
Dj Gilcrease wrote: win2k and later have a form of sym link, the api for it is just not provided in a nice simple app like it is on nix platforms. Yes, it's possible to create symlinks on win2k using a command line tool called 'linkd' (I've done it). However, they're extremely dangerous, because the GUI side of win2k doesn't know about them. It thinks that a symlink to a folder is a real folder, and if you delete it, you end up deleting the contents of the folder that the symlink points to. So if you use them, you need to keep your wits about you. -- Greg ___ 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] Ctrl-C handling in pdb
I have used pdb for several years and have always wanted a gdb-like Ctrl-C handling: in gdb pressing Ctrl-C interrupts the program but the execution can be resumed later by the user (while pdb will terminate the program and throw you into postmortem debugging with no ability to resume the execution). So I implemented this functionality as http://bugs.python.org/issue7245. The patch is very simple: install a SIGINT handler and when SIGINT arrives, set the tracing. The signal handler is only activated when pdb is run as a script. I cann't think of any disadvantages. If this functionality is indeed useful and I am not missing some serious side effects, would it be possible to review the patch? Thanks, Ilya Sandler ___ 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] some notes from the first part of the lang summit
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon br...@python.org wrote: My notes from the session I led: + argparse - Same issues brought up. For those of us not at PyCon, what were the issues? Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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
