Re: Multiple versions of Python coexisting in the same OS
On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote: Are the .py and .pyc extensions the only ones which are associated with Python or are there others, for a normal Python installation in Windows ? There's also .pyw Also .pyo .py = Python source code, usually associated with command line Python .pyc = Python byte code .pyo = Python optimized byte code .pyw = is Windows only, and shouldn't open a console window. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy installation
Hi Jia, On Sun, Jul 25, 2010 at 12:01 PM, Jia Hu huji...@gmail.com wrote: Hello: I tried to install numpy 1.4.1 from source under ubuntu following instruction at http://docs.scipy.org/doc/numpy/user/install.html I type python setup.py build –help-fcompiler and it says gnu95 is found. Then I run python setup.py build –fcompiler=gnu95. There is error. Please state the full error. Saying that there is an error is generally unhelpful. Also, you are more likely to receive good information on the numpy ML: http://www.scipy.org/Mailing_Lists David -- http://mail.python.org/mailman/listinfo/python-list
Re: Are those features still the same?
Terry Reedy wrote: As other have said, mostly, but I would change the following... Thanks for all those who replied. I know these are not all the features but some of them and again this is not a comparison but a little taste of what python offers today, and the replies were very informative. By the way Peter Norvig is not biased, he works for Google research and is a supporter of programming in any language, especially in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Library versions
In message 2cb0c88b-58ea-4704-8578-2ebd766f1...@t10g2000yqg.googlegroups.com, Peo wrote: My current plan is to call the library something like 'foo1' and import it into scripts like 'import foo1 as foo'. Releases that change the API would be installed as 'foo2', 'foo3' and so on. This works fine but it will be quite difficult to create new releases (documentation and library code are littered with references to 'foo1'). I don’t understand why this is a problem. The references to “foo1” are because it is “foo1” that implements those facilities, is it not? When “foo2” comes along, you will introduce that name where specifying the facilities specific to it, will you not? Where both modules provide the same facilities, you will have to mention both names, and only in those cases. I don’t see how you can possibly short-cut this process and still produce correct documentation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
Hi Edward, On 07/25/2010 04:40 AM, Edward Diener wrote: I found the solutions too exotic for actual use, and completely ineffectual for the cases I originally cited. The people in that thread seem to have completely forgotten that Python can be invoked externally and internally both through executing 'python(w) xxx' and through executing a file with the file extension(s) associated with Python. They seem to have forgotten this can be within scripts or any other program using Python, both written by themselves and by others, and not just by their typing 'python(w) xxx' somewhere. Their solutions seem to believe that only they will externally be i9nvoking Python and only for their own written scripts, as opposed to the many libraries using Python as well as the Python distribution itself. The best solution is some program which changes the PATH and the Python file type associations depending on which version of Python one wants to use on one's own system when more than one Python version must coexist with others. I will probably write such a program for myself. Hi Edward, changing the path and is perfect for people who use consoles. (under linux there's virtuelenv for his and it's great) changing the file association is perfect for people who'd know at which time they want to use which version of python. The usecase, that I'm nore aware of however is somethig like having some scripts / directories, that should use one version of python and others that shoud use another. In unix you do this normally with the 'shebang line' ( e.g. #!/usr/bin/env/python2.6 ) There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. -- http://mail.python.org/mailman/listinfo/python-list
Re: Socket performance
In article 4c4bd0b1$0$1624$742ec...@news.sonic.net, John Nagle na...@animats.com wrote: 1. When writing to a TCP socket, write everything you have to write with one send or write operation if at all possible. Don't write a little at a time. That results in sending small packets, because sockets are flushed after each write. There's nothing that guarantees that a single write won't be split into multiple packets, nor that multiple writes won't be coalesced into a single packet. Or any combination of splitting and coalescing that the kernel feels like. That being said, for any sane implementation, what John says is true most of the time, and is indeed a reasonable optimization. Just don't depend on it being true all the time. The most common case where it will not be true is if you're trying to send a large amount of data and exceed the MTU of the network. Then you are certain to get fragmentation. Depending on what you're doing, this can be a point of networking trivia, or it can be the difference between your application working and not working. If you're just streaming data from one place to another, you don't have to worry about it. But, if you're doing some sort of interactive protocol where you send a command, wait for a respond, send another command, etc, you really do need to be aware of how this works. Let's say you're writing something like a HTTP client. You send a bunch of headers, then expect to get back something like 200 OK\r\n, or 404 Not Found\r\n. You can't just do a read() on the socket and then examine the string to see if the first three characters are 200 or 404, because (regardless of how the server sent them), it is legal for your read() to return just a single character (i.e. 2), and then for the next read() to get 00 OK\r\n. You need to do buffering inside your application which keeps doing read() until you find the \r\n (and stops there, even if the read() returned more data beyond that). -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 6:07 AM, Gelonida wrote: Hi Edward, On 07/25/2010 04:40 AM, Edward Diener wrote: I found the solutions too exotic for actual use, and completely ineffectual for the cases I originally cited. The people in that thread seem to have completely forgotten that Python can be invoked externally and internally both through executing 'python(w) xxx' and through executing a file with the file extension(s) associated with Python. They seem to have forgotten this can be within scripts or any other program using Python, both written by themselves and by others, and not just by their typing 'python(w) xxx' somewhere. Their solutions seem to believe that only they will externally be i9nvoking Python and only for their own written scripts, as opposed to the many libraries using Python as well as the Python distribution itself. The best solution is some program which changes the PATH and the Python file type associations depending on which version of Python one wants to use on one's own system when more than one Python version must coexist with others. I will probably write such a program for myself. Hi Edward, changing the path and is perfect for people who use consoles. (under linux there's virtuelenv for his and it's great) changing the file association is perfect for people who'd know at which time they want to use which version of python. The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. The usecase, that I'm nore aware of however is somethig like having some scripts / directories, that should use one version of python and others that shoud use another. In unix you do this normally with the 'shebang line' ( e.g. #!/usr/bin/env/python2.6 ) There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Light-weight/very-simple version control under Windows using Python?
pyt...@bdurham.com writes: 1. Use an existing version control utility. There are lots of options here(!), any recommendations on a light weight, open source one that xcopy installs under Windows with lots of command line options? Personally, I like RCS. It seems fulfil your requirements. You can get it for Windows from http://www.cs.purdue.edu/homes/trinkle/RCS/. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 2:20 AM, Steven D'Aprano wrote: On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote: Are the .py and .pyc extensions the only ones which are associated with Python or are there others, for a normal Python installation in Windows ? There's also .pyw Also .pyo .py = Python source code, usually associated with command line Python .pyc = Python byte code .pyo = Python optimized byte code .pyw = is Windows only, and shouldn't open a console window. Thanks ! I had forgotten about .pyo and .pyw under Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: Socket performance
On 25-Jul-2010, at 5:52 PM, Roy Smith wrote: In article 4c4bd0b1$0$1624$742ec...@news.sonic.net, John Nagle na...@animats.com wrote: 1. When writing to a TCP socket, write everything you have to write with one send or write operation if at all possible. Don't write a little at a time. That results in sending small packets, because sockets are flushed after each write. There's nothing that guarantees that a single write won't be split into multiple packets, nor that multiple writes won't be coalesced into a single packet. Or any combination of splitting and coalescing that the kernel feels like. That being said, for any sane implementation, what John says is true most of the time, and is indeed a reasonable optimization. Just don't depend on it being true all the time. The most common case where it will not be true is if you're trying to send a large amount of data and exceed the MTU of the network. Then you are certain to get fragmentation. Depending on what you're doing, this can be a point of networking trivia, or it can be the difference between your application working and not working. If you're just streaming data from one place to another, you don't have to worry about it. But, if you're doing some sort of interactive protocol where you send a command, wait for a respond, send another command, etc, you really do need to be aware of how this works. Let's say you're writing something like a HTTP client. You send a bunch of headers, then expect to get back something like 200 OK\r\n, or 404 Not Found\r\n. You can't just do a read() on the socket and then examine the string to see if the first three characters are 200 or 404, because (regardless of how the server sent them), it is legal for your read() to return just a single character (i.e. 2), and then for the next read() to get 00 OK\r\n. You need to do buffering inside your application which keeps doing read() until you find the \r\n (and stops there, even if the read() returned more data beyond that). -- http://mail.python.org/mailman/listinfo/python-list Thanks John, Roy. I really appreciate your valuable input. I have made a note of what you have said and will implement keeping the same in mind : ) Nav -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode error
On Fri, 23 Jul 2010 18:27:50 -0400, Terry Reedy wrote: But in the meanwhile, once you get an error, you know what it is. You can intentionally feed code bad data and see what you get. And then maybe add a test to make sure your code traps such errors. That doesn't really help with exceptions which are triggered by external factors rather than explicit inputs. Also, if you're writing libraries (rather than self-contained programs), you have no control over the arguments. Coupled with the fact that duck typing is quite widely advocated in Python circles, you're stuck with the possibility that any method call on any argument can raise any exception. This is even true for calls to standard library functions or methods of standard classes if you're passing caller-supplied objects as arguments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. If you let .py scripts specify which interpreter they'd like to be run with in the first line, with some sort of pystarter script that you map to the file extensions (or by using UNIX), this should work equally well no matter if the script being run by a script or by a user. If you invoke the Python interpreter directly, you should NEVER EVER assume that the interpreter is in a certain place, or on the PATH. It's a stupid idea: what if it's not? Instead, if you really must, invoke sys.executable instead of guessing. Obviously, Windows doesn't have fork(), but still, I don't see any reason to leave the comfort of your own running interpreter: you can use runpy to run python scripts. If you want them to run in the background, you can use threads, or, if you require (or want) separate processes, use multiprocessing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. I'm not sure I understand. The ida is of course, that the file association would point to the pystarter and that pystarter would depending on directory / first line of the script identify the correct executable to be started with. Perhaps you could once more explain, what your intended solution would be. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: Hi Edward, There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. What do you mean with invoking python internally? call another python script? from a python script. You could start it again via a pystarter. or just with python (assuming the starter adapts the path) The problem, that I currently encounter are some scripts, which want to use python UNO (open office delivers ther own version of python) and others which want to use libraries of my 'normal' python. having the file association point to a python starter and let the python starter choose could be an option. However I never tried so far. the fast and easy option is to just have specific file suffixes for the open office python scripts (like e.g ) .oopy -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode error
On Sun, 25 Jul 2010 13:52:33 +0100, Nobody wrote: On Fri, 23 Jul 2010 18:27:50 -0400, Terry Reedy wrote: But in the meanwhile, once you get an error, you know what it is. You can intentionally feed code bad data and see what you get. And then maybe add a test to make sure your code traps such errors. That doesn't really help with exceptions which are triggered by external factors rather than explicit inputs. Huh? What do you mean by external factors? Do you mean like power supply fluctuations, cosmic rays flipping bits in memory, bad hardware? You can't defend against that, not without specialist fault-tolerant hardware, so just don't worry about it. If you mean external factors like the network goes down or the disk is full, you can still test for those with appropriate test doubles (think stunt doubles, only for testing) such as stubs or mocks. It's a little bit more work (sometimes a lot more work), but it can be done. Or don't worry about it. Release early, release often, and take lots of logs. You'll soon learn what exceptions can happen and what can't. Your software is still useful even when it's not perfect, and there's always time for another bug fix release. Also, if you're writing libraries (rather than self-contained programs), you have no control over the arguments. You can't control what the caller passes to you, but once you have it, you have total control over it. You can reject it with an exception, stick it inside a wrapper object, convert it to something else, deal with it as best you can, or just ignore it. Coupled with the fact that duck typing is quite widely advocated in Python circles, you're stuck with the possibility that any method call on any argument can raise any exception. This is even true for calls to standard library functions or methods of standard classes if you're passing caller-supplied objects as arguments. That's a gross exaggeration. It's true that some methods could in theory raise any exception, but in practice most exceptions are vanishingly rare. And it isn't even remotely correct that any method could raise anything. If you can get something other than NameError, ValueError or TypeError by calling spam.index(arg), I'd like to see it. Frankly, it sounds to me that you're over-analysing all the things that could go wrong rather than focusing on the things that actually do go wrong. That's your prerogative, of course, but I don't think you'll get much support for it here. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Compare two nested dictionaries
Hi, I am trying to compare two nested dictionaries, I want to know what is the exact difference between them. I tried this solution ... s1 = set(result1) s2 = set(result2) print s1 - s2 but it doesn't seem show any difference, but assert result1 == result2 fails could someone help me to find out the difference the two nested dictionaries. Any help is greatly appreciated. Thanks, Vivek. -- http://mail.python.org/mailman/listinfo/python-list
Constructor call in the same class?
What's wrong with:
class Enum(RootFragment):
__jpaTypes = {
# complete!
'CascadeType': Enum(javax.persistence.CascadeType),
'DiscriminatorType':
Enum(javax.persistence.DiscriminatorType),
'EnumType': Enum(javax.persistence.EnumType),
'FetchType': Enum(javax.persistence.FetchType),
'FlushModeType': Enum(javax.persistence.FlushModeType),
'GenerationType': Enum(javax.persistence.GenerationType),
'InheritanceType': Enum(javax.persistence.InheritanceType),
'LockModeType': Enum(javax.persistence.LockModeType),
'PersistenceContextType':
Enum(javax.persistence.PersistenceContextType),
'TemporalType': Enum(javax.persistence.TemporalType),
}
# constructor
def __init__(self, package, modifiers, name, superInterfaces = [],
annotations = [], innerClasses = [], properties = [],
methods = []):
RootFragment.__init__(self, packageName, modifiers, enum,
name, superInterfaces, annotations, innerClasses, properties, methods)
?
I get
'CascadeType': Enum(javax.persistence.CascadeType),
NameError: name 'Enum' is not defined
What's wrong with calling a constructor in a dict initializer? How do
I solve this?
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Constructor call in the same class?
On 07/25/2010 05:41 PM, Karsten Wutzke wrote:
What's wrong with:
class Enum(RootFragment):
__jpaTypes = {
# complete!
'CascadeType': Enum(javax.persistence.CascadeType),
'DiscriminatorType':
Enum(javax.persistence.DiscriminatorType),
'EnumType': Enum(javax.persistence.EnumType),
'FetchType': Enum(javax.persistence.FetchType),
'FlushModeType': Enum(javax.persistence.FlushModeType),
'GenerationType': Enum(javax.persistence.GenerationType),
'InheritanceType': Enum(javax.persistence.InheritanceType),
'LockModeType': Enum(javax.persistence.LockModeType),
'PersistenceContextType':
Enum(javax.persistence.PersistenceContextType),
'TemporalType': Enum(javax.persistence.TemporalType),
}
# constructor
def __init__(self, package, modifiers, name, superInterfaces = [],
annotations = [], innerClasses = [], properties = [],
methods = []):
RootFragment.__init__(self, packageName, modifiers, enum,
name, superInterfaces, annotations, innerClasses, properties, methods)
?
I get
'CascadeType': Enum(javax.persistence.CascadeType),
NameError: name 'Enum' is not defined
well, within the class statement, it's not defined. So you can't call
Enum yet.
You have to create your dict somewhere else. You can either set it from
outside:
class Enum(RootFragment):
...
Enum._jpaTypes = { ... }
Or, do exactly the same thing, but within a class method:
class Enum(bla):
@classmethod
def contruct_jpatypes(cls):
cls.__jpaTypes = { ... }
Enum.construct_jpatypes()
What's wrong with calling a constructor in a dict initializer? How do
I solve this?
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare two nested dictionaries
On Sun, 25 Jul 2010 08:03:06 -0700, targetsmart wrote:
Hi,
I am trying to compare two nested dictionaries, I want to know what is
the exact difference between them. I tried this solution
...
s1 = set(result1)
s2 = set(result2)
print s1 - s2
but it doesn't seem show any difference, but
assert result1 == result2
fails
could someone help me to find out the difference the two nested
dictionaries.
Have you tried printing them and just looking for the differences?
Calling set() on a dictionary will create a set from the keys only:
d1 = {a: 1, b: 2}
d2 = {a: 1, b: 999}
set(d1) == set(d2)
True
d1 == d2
False
If you want to know the difference between two dictionaries, you have to
consider:
(1) Keys that are in the first dict, but not the second;
(2) Keys that are in the second dict, but not the first; and
(3) Keys which are in both dicts, but have different values.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare two nested dictionaries
Hi, On 07/25/2010 06:21 PM, Steven D'Aprano wrote: On Sun, 25 Jul 2010 08:03:06 -0700, targetsmart wrote: Hi, I am trying to compare two nested dictionaries, I want to know what is the exact difference between them. I tried this solution ... s1 = set(result1) s2 = set(result2) print s1 - s2 I think you want to have the symmetric difference: try s1 ^ s2 but it doesn't seem show any difference, but -- http://mail.python.org/mailman/listinfo/python-list
Re: Constructor call in the same class?
You have to create your dict somewhere else. You can either set it from
outside:
class Enum(RootFragment):
...
Enum._jpaTypes = { ... }
THANKS for the quick help.
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
On Jul 24, 3:56 am, Lacrima lacrima.ma...@gmail.com wrote: Thank you for your answer. You're welcome. Some things are still not clear. Your example works great. But if I remove super(SuperClass1, self).__init__(**kwds) from SuperClass1's __init__, the example stops working. That is when I instantiate SubClass only __init__ of SuperClass1 is called and __init__ of SuperClass2 is omitted, i.e. only 'Python' is printed. Why is it so? So as I understand every parent should necessarily call super() at the end of its __init__ method in order for things to work properly. Yes. That's correct. Python's super() was designed to support cooperative multiple inheritance. The cooperative part means that every class implementing the target method (such as __init__ in your example) needs to call super() in order to trigger the next method in the sequence (the method resolution order or MRO). But what if SuperClass1 is from third party library? . . . How to deal with that? Then, the odds are that that class isn't cooperating. You can either wrap the third-party library to add a super() call or you can switch to an alternate design using composition instead of inheritance. Raymond P.S. Outside of the simple case of single inheritance, the one key to understanding super() is to forget about the concept of parent classes. Instead, super() is all about the MRO which is computed dynamically (unknowable at the time a class is written). Every class in the MRO implementing the target method *must* call super() to give the next class in the MRO a chance to run. IOW, using super() means I'm in the MRO and I got a chance to run; now the next class in the MRO gets its chance. Since the MRO is only knowable at runtime, the sole job of super() is to figure out which is the next class in the MRO. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare two nested dictionaries
[targetsmart] I am trying to compare two nested dictionaries, I want to know what is the exact difference between them. I tried this solution [Steven D'Aprano] If you want to know the difference between two dictionaries, you have to consider: (1) Keys that are in the first dict, but not the second; (2) Keys that are in the second dict, but not the first; and (3) Keys which are in both dicts, but have different values. Steven, thanks for the excellent specification. Here's the code: s1 = set(d1) s2 = set(d2) first_not_second = s1 - s2 second_not_first = s2 - s1 difference_values = set(k for k in s1 s2 if d1[k] != d2[k]) If the values are hashable, an alternate approach is: s1 = set(d1.items()) s2 = set(d2.items()) first_not_second = s1 - s2 second_not_first = s2 - s1 Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
Edward Diener wrote: Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? There is this: http://pypi.python.org/pypi/virtualenv We have a good group in NYC for python and django. That's where I learned about virtualevn. I admit I'm not fully up to speed on it, but it lets you set up multiple 'virtual environments' for python to do exactly what I think you are asking about Joel Goldstick -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley tart...@tartley.com wrote: I presume this problem would go away if future versions of Python itself were compiled on Windows with something like MinGW gcc. You might want to track issue3871. Roumen Petrov has done a lot of work to make CPython compilable with mingw on Windows, as well as to make it possible to compile CPython on a different operating system and produce a CPython executable for Windows (cross-compile). And by the way, I've usually had success building my native extension modules with mingw. I understand (vaguely) that if a native extension module needs to pass FILE*'s or C++ iostreams back and forth to different extension modules or the the core CPython interpreter then this could lead to segfaults, but none of my extension modules need to do that. I would suggest that people try to build their native extension modules with mingw, and if it doesn't work report a bug (to mingw project and to the Python project) so that we can track more precisely what the issues are. Regards, Zooko http://bugs.python.org/issue3871# cross and native build of python for mingw32 with distutils -- http://mail.python.org/mailman/listinfo/python-list
Re: Light-weight/very-simple version control under Windows using Python?
pyt...@bdurham.com wrote: I have some very simple use cases[1] for adding some version control capabilities to a product I'm working on. My product uses simple, text (UTF-8) based scripts that are independent of one another. I would like to version control these scripts on behalf of my users. By version control, I mean *very-simple* version control with no branching or merging - just the ability to store, list and restore a specific version of a file. The data store should be a local file with the ability to upsize to a multi-user database in the future. I'm looking for recommendations on possible solutions: 1. Use an existing version control utility. There are lots of options here(!), any recommendations on a light weight, open source one that xcopy installs under Windows with lots of command line options? 2. Interface to a hosted version control system (SaaS) that provides a RESTful API. Any recommendations here? 3. Build this capability myself using Python and Python's DBI layer to store files in a local SQLite database at first (but with the ability to upsize to a real client server database in the future). Seems like a fun project to work on, but also smells like I'd be re-inventing the wheel with very little value added other than simpler deployment? Any suggestions appreciated. Use Mercurial (http://mercurial.selenic.com). It is written in python, can be extended by python modules/packages and can be used by python programs directly. 1. Check a file in with optional comment and username; ideally get a version number that can be used to reference this specific check-in in the future. That's a basic task in mercurial (as probably in every version control system). 2. Get a history listing of all checkins for a specific file (version number, timestamp, file size, user, comment) Also avalilable. I am not sure about file size and comment, but if you have the list of version numbers, you can extract this info from the repository easily. 3. Check out a specific version of a file by version number. See point 1. 4. Delete checked-in versions by version number, date range, and/or username. I've never tried it with mercurial. There are a remove and a forget command. Maybe, one could use the rebase extension. But deleting changesets from a repository usually is a bad idea. 5. (Optional) Diff 2 versions of a file by version number and return diff in richly formatted format that visually shows changes via color and font effects (strikethru) (I'm thinking of using BeyondCompare for this if not present in a simple version control tool) Also available. Regards, Günther -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 1:51 PM, Joel Goldstick wrote: Edward Diener wrote: Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? There is this: http://pypi.python.org/pypi/virtualenv It appears to be only for Linux. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 09:12 PM, Edward Diener wrote: On 7/25/2010 1:51 PM, Joel Goldstick wrote: There is this: http://pypi.python.org/pypi/virtualenv It appears to be only for Linux. I don't know where you get that impression from. I don't know how well it works on which platforms, but the fact that there is a Note for Windows: does suggest that it does work on windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 09:19 PM, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. I doubt many scripts do it. The fact of the matter is: many systems have multiple Python versions installed in parallel, and it probably will break somewhere, which will get noticed, and probably fixed. If a script uses sys.executable instead of python, there is no problem, at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. I'm not sure I understand. The ida is of course, that the file association would point to the pystarter and that pystarter would depending on directory / first line of the script identify the correct executable to be started with. Perhaps you could once more explain, what your intended solution would be. How does a 'pystarter' program know where the file's location is which is being invoked ? As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the name of that distribution is. Then you tell the program which Python distribution should be the current one by its name, the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the name Python directory tree, and changes the file associations so that the name Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Interesting. Does the multiprocessing module still work in that scenario? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
sOn 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. sys.executable will not work with scripts converted with py2exe, as sys.executable will not be the executable of the python interpreter, but with the main executable's name. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 10:04 PM, News123 wrote: sOn 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. sys.executable will not work with scripts converted with py2exe, as sys.executable will not be the executable of the python interpreter, but with the main executable's name. Well, but a script converted with py2exe can't really ever assume that there is a Python interpreter, at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 09:33 PM, Edward Diener wrote: On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: How does a 'pystarter' program know where the file's location is which is being invoked ? the file's location would be somewhere in sys.argv probably in sys.argv[1]. converting it to an abs path would return a directory which the python file belongs to. As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. Well I would at least do it for all of my self written scripts. It could allow a soft transition from 2.6 to 2.7 to 3.0 without having to upgrade all scripts at the same time. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the name of that distribution is. Then you tell the program which Python distribution should be the current one by its name, the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the name Python directory tree, and changes the file associations so that the name Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. I guess it's rather difficult to find a solution which suits all. The above minor weakness, that you mention would be a killer for me. Currently I'm looking for solutions, where I can start python scripts requireing different python versions at the same time. Currently I'm staring the scripts manually from two different cmd line windows with a different path name and an explicit python call, Thus my idea of having a pystarter with a config file mentioning which directories (tools) should use which python executable -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 10:18 PM, Thomas Jollans wrote: On 07/25/2010 10:04 PM, News123 wrote: sOn 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. sys.executable will not work with scripts converted with py2exe, as sys.executable will not be the executable of the python interpreter, but with the main executable's name. Well, but a script converted with py2exe can't really ever assume that there is a Python interpreter, at all. true :-) However, why I thought about this is, that I write sometimes python code, which tries to call other python files. later on for distribution I use py2exe. Therefore I use wrapper functions, which will work in either case. The wrapper could use sys.executable in 'python mode' and had to call the exe file in 'py2exe mode' -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
News123 wrote: On 07/25/2010 09:33 PM, Edward Diener wrote: On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: How does a 'pystarter' program know where the file's location is which is being invoked ? the file's location would be somewhere in sys.argv probably in sys.argv[1]. converting it to an abs path would return a directory which the python file belongs to. As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. Well I would at least do it for all of my self written scripts. It could allow a soft transition from 2.6 to 2.7 to 3.0 without having to upgrade all scripts at the same time. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the name of that distribution is. Then you tell the program which Python distribution should be the current one by its name, the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the name Python directory tree, and changes the file associations so that the name Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. I guess it's rather difficult to find a solution which suits all. The above minor weakness, that you mention would be a killer for me. Currently I'm looking for solutions, where I can start python scripts requireing different python versions at the same time. Currently I'm staring the scripts manually from two different cmd line windows with a different path name and an explicit python call, Thus my idea of having a pystarter with a config file mentioning which directories (tools) should use which python executable I think that's the wrong way round. A pystarter should ask the _tool_ which version of Python it needs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 3:32 PM, Thomas Jollans wrote: On 07/25/2010 09:19 PM, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. I doubt many scripts do it. The fact of the matter is: many systems have multiple Python versions installed in parallel, and it probably will break somewhere, which will get noticed, and probably fixed. If a script uses sys.executable instead of python, there is no problem, at all. What a script uses to internally invoke Python I can not control. My solution seeks to be non-intrusive and lets me run a particular version of Python, among the co-existing versions installed, at any given time. I believe that is the best I can do. I neither can control, nor do I want to control, all of the Python scripts installed on my system, nor can I worry how they may internally invoke Python. But I do want to be able to say, at any given time, that when I run Python a particular version, amidst the co-existing ones on my system, needs to be executed and therafter all internally executed modules use that version. Trying to make rules for scripts, such as telling scripts they must use sys.executable, is pursuing an imaginary solution that can not work unless one is theoretically willing to manually inspect and change all Python scripts in some way. To me any intrusive changes to actual scripts is no solution at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 3:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 4:22 PM, News123 wrote: On 07/25/2010 09:33 PM, Edward Diener wrote: On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: How does a 'pystarter' program know where the file's location is which is being invoked ? the file's location would be somewhere in sys.argv probably in sys.argv[1]. converting it to an abs path would return a directory which the python file belongs to. As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. Well I would at least do it for all of my self written scripts. It could allow a soft transition from 2.6 to 2.7 to 3.0 without having to upgrade all scripts at the same time. Intrusively changing scripts is a path to Python hell. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the name of that distribution is. Then you tell the program which Python distribution should be the current one by its name, the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the name Python directory tree, and changes the file associations so that the name Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. I guess it's rather difficult to find a solution which suits all. The above minor weakness, that you mention would be a killer for me. Currently I'm looking for solutions, where I can start python scripts requireing different python versions at the same time. If you need that, then of course my intended solution would not work. Currently I'm staring the scripts manually from two different cmd line windows with a different path name and an explicit python call, If you start scripts and point to a specific version of Python, this works in my solution also. But if an internal call to Python exists thwre is always a problem. Thus my idea of having a pystarter with a config file mentioning which directories (tools) should use which python executable Well, good luck ! I don;t know how this is resolved for you when some scripts executes 'python xxx yyy' or 'someScript.py yyy'. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 4:26 PM, News123 wrote: On 07/25/2010 10:18 PM, Thomas Jollans wrote: On 07/25/2010 10:04 PM, News123 wrote: sOn 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. sys.executable will not work with scripts converted with py2exe, as sys.executable will not be the executable of the python interpreter, but with the main executable's name. Well, but a script converted with py2exe can't really ever assume that there is a Python interpreter, at all. true :-) However, why I thought about this is, that I write sometimes python code, which tries to call other python files. later on for distribution I use py2exe. Therefore I use wrapper functions, which will work in either case. The wrapper could use sys.executable in 'python mode' and had to call the exe file in 'py2exe mode' You can control what you do but how are you going to control what any givemn script does ? Attempting to intrusively change potentially every script in a distribution in any way is a path to Python hell IMO. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 07/25/2010 11:10 PM, Edward Diener wrote: On 7/25/2010 3:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems. What exactly is it that you're afraid to change? The standard library? There's certainly no need to change that in any way! Your own code? That'd just be nonsense. Someone else's then. Is there any problem at all when you start it with a specific Python interpreter? I expect that there probably isn't. If there is, if the code makes ANY assumptions about where to find a Python interpreter on your system, I would consider that a serious bug that should be reported. If it's only one or two affected lines of code, why not change them? There's nothing intrusive or wrong about fixing something on your own computer! If it turns out that you'd have to change a lot of code to make it work, THAT's the time to think about a complex workaround, like writing a batch file that sets up an environment in which it works, for that program. Otherwise, I don't think it's worth the effort. I'm on a Linux system with multiple Python interpreters. (Almost) all installed Python programs work with the system default interpreter (CPython 2.6). Those that don't have been fitted with shebang lines like #!/usr/bin/python2.5. This tells the OS to use a different interpreter, like the pystarter script solution proposed in this very thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx zo...@zooko.com wrote: I would suggest that people try to build their native extension modules with mingw, and if it doesn't work report a bug (to mingw project and to the Python project) so that we can track more precisely what the issues are. To be clear, building extensions with mingw for the official python works well. Numpy and scipy official binaries have been built with mingw for years. There are problems for 64 bits binaries, though David -- http://mail.python.org/mailman/listinfo/python-list
Python acting weird
x = {type:folder, name:sonicbot, data:[{type:folder,
name:SonicMail, data:[{type:file, name:bbcode.py,
compressed:False, contents:blahblahfilecontents}]}]}
print x
def setindict(dictionary, keys, value) :
if len(keys) == 1 :
if keys[0].isdigit() and int(keys[0]) == len(dictionary) :
dictionary.append(keys[0])
else :
dictionary[keys[0]] = value
else :
dictionary[keys[0]] = setindict(dictionary[keys[0]], keys[1:], value)
return dictionary
a = x.copy()
print id(a), id(x)
y = setindict(a, [data, 0, data, 0, compressed], True)
if y == x :
print True
else :
print False
print x
print a
How are x and a are ending up the same? I would think .copy() would
make it completely seperate.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Raymond Hettinger wrote: Every class in the MRO implementing the target method *must* call super() to give the next class in the MRO a chance to run. EXCEPT for the last one, which must NOT call super! The posted example happens to work because object has a default __init__ method that does nothing. But this is not generally true of other methods, which means you need a terminating class at the end of the MRO whose methods don't call super. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python acting weird
On Sun, Jul 25, 2010 at 5:08 PM, Westly Ward sonicrules1...@gmail.com wrote:
x = {type:folder, name:sonicbot, data:[{type:folder,
name:SonicMail, data:[{type:file, name:bbcode.py,
compressed:False, contents:blahblahfilecontents}]}]}
print x
def setindict(dictionary, keys, value) :
if len(keys) == 1 :
if keys[0].isdigit() and int(keys[0]) == len(dictionary) :
dictionary.append(keys[0])
else :
dictionary[keys[0]] = value
else :
dictionary[keys[0]] = setindict(dictionary[keys[0]], keys[1:], value)
return dictionary
a = x.copy()
print id(a), id(x)
y = setindict(a, [data, 0, data, 0, compressed], True)
if y == x :
print True
else :
print False
print x
print a
How are x and a are ending up the same? I would think .copy() would
make it completely seperate.
Nope, .copy() only makes a shallow copy of the outermost dict, not a
recursive deep copy; the 2 dictionaries initially point to the
*exact* same objects for their keys and values.
a = x.copy()
assert x is not a # wouldn't be much of a copy otherwise
assert x[data] is a[data] # no recursive copying though
# separate dicts, so rebinding the items of one doesn't affect the other
x[42] = 12
assert 42 not in a
# mutating the items in one does affect the other however
x[data].append(7)
assert a[data].pop() == 7
# remember that x[y] = z === x.__setitem__(y, z)
# so we can write a similar example thusly:
x[data][0] = 8
assert a[data][0] == 8
# again, rebinding at the outermost level is independent
x[data] = 99
assert a[data] != x[data]
For a deep copy, use copy.deepcopy() in the std lib:
http://docs.python.org/library/copy.html#copy.deepcopy
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 5:57 PM, Thomas Jollans wrote: On 07/25/2010 11:10 PM, Edward Diener wrote: On 7/25/2010 3:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of python, there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems. What exactly is it that you're afraid to change? I do not want to intrusively change any script that has been installed as part of Python. I shouldn't even have to know about the code in these scripts other than what good documentation tells me in how to use them. That's not to say having source is worthless. I am just not going to change source to get a version of Python to work properly when I have 2 or more versions installed in their own separate folders. The standard library? There's certainly no need to change that in any way! So if a standard library module ( or distributed library ) executes a call internally to 'python xxx yyy' or executes a call internally to 'someScript.py yyy', you're fine with multiple co-existing versions of Python on your system ? Because under Windows the first call will look for the python.exe first found in the PATH while the second call will find the python.exe associated with the .py extension. And it does not matter in either case what version of the multiple installed versions of Python which are on my system is currently executing that script. And please don't say that there is some sort of guarantee that no library or installation would invoke Python in such a way as opposed to the normal 'import AScript.py' method of using functionality in Python scripts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Yes, people write poorly written, buggy scripts all the time. Just because code is legal syntax doesn't mean it does what is intended, or that what is intended is sensible. If you have multiple versions of Python installed, and you call python somescript.py without knowing *which* Python will be called, it is neither sensible nor does it do what you intend. End of story. This is no different from calling any other application without knowing what version you will get, then relying on features that are only available in some versions. It is just buggy code. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Treat it like any script with a bug: fix the bug, stop using the script, or determine a work-around that masks the bug. All three are acceptable, the third being the least acceptable because it just leaves a bug waiting to bite you again in the future. Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. No, it solves it completely. Treat it as a bug, and fix it. If you're not willing to treat it as a bug, then uninstall all but one of the Python versions, and the problem goes away. You might have a different problem, namely that some scripts stop working, but now the solution is obvious and straight-forward: fix the scripts that aren't working. Or rename the Python applications, so that scripts can easily call the right version without getting confused. Trying to make some brittle, Do-What-I-Mean solution for trying to auto- magically select between Python versions is pursuing a path of endless problems. Any solution that doesn't fix the actual problem, namely that the scripts are buggy, is at best just a work-around and at worst is no solution at all. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Light-weight/very-simple version control under Windows using Python?
Günther Dietrich gd.use...@spamfence.net writes: pyt...@bdurham.com wrote: I have some very simple use cases[1] for adding some version control capabilities to a product I'm working on. […] I'm looking for recommendations on possible solutions: 1. Use an existing version control utility. […] Use Mercurial (http://mercurial.selenic.com). It is written in python, can be extended by python modules/packages and can be used by python programs directly. Either of Mercurial or Bazaar URL:http://bazaar.canonical.com/ will be good choices for the requirements specified. All of Günther's comments (including those I trimmed in this reply) apply equally to both Mercurial and Bazaar. You might like to ask questions in each of the support forums for those tools for more information. -- \ “To punish me for my contempt of authority, Fate has made me an | `\ authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener eldie...@tropicsoft.invalid wrote: On 7/25/2010 5:57 PM, Thomas Jollans wrote: So if a standard library module ( or distributed library ) executes a call internally to 'python xxx yyy' or executes a call internally to 'someScript.py yyy', you're fine with multiple co-existing versions of Python on your system ? Because under Windows the first call will look for the python.exe first found in the PATH while the second call will find the python.exe associated with the .py extension. And it does not matter in either case what version of the multiple installed versions of Python which are on my system is currently executing that script. And please don't say that there is some sort of guarantee that no library or installation would invoke Python in such a way as opposed to the normal 'import AScript.py' method of using functionality in Python scripts. Edward, I'm having a really hard time understanding your problem. Could you give an example of some real code that is causing you difficulty? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 8:41 PM, Steven D'Aprano wrote: On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Yes, people write poorly written, buggy scripts all the time. Just because code is legal syntax doesn't mean it does what is intended, or that what is intended is sensible. If you have multiple versions of Python installed, and you call python somescript.py without knowing *which* Python will be called, it is neither sensible nor does it do what you intend. End of story. Somebody is supplying you with a Python script and internally invoking Python again. But that somebody does not have to be myself. I am neither buying End of story nor that invoking Python internally is an error. But if you believe it to be then you can root out all such Python code, or correct it as you like. Even with co-existing versions of Python installed I have better things to do with my time and therefore will pursue a solution that will work for me in the face of such code. -- http://mail.python.org/mailman/listinfo/python-list
Re: why is this group being spammed?
Python-list is comp.lang.python turned into mailing list form. gmane is python-list turned back into a newsgroup. The reason it gets less spam is because it's behind the mailing list's spam filters. Both the mailing list and gmane should see the same amount of spam. which is way less than the original newsgroup/Google Group sees. On Sat, Jul 24, 2010 at 12:28 PM, Jia Hu huji...@gmail.com wrote: I subscribe for this mailing list at http://mail.python.org/mailman/listinfo/python-list On Sat, Jul 24, 2010 at 3:22 PM, Jia Hu huji...@gmail.com wrote: Hi, can I subscribe this by gmail? On Sat, Jul 24, 2010 at 3:16 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 24/07/2010 18:01, Dennis Lee Bieber wrote: On Sat, 24 Jul 2010 07:32:30 -0700 (PDT), be.krulbe.k...@gmail.com declaimed the following in gmane.comp.python.general: But maybe owner of this group do no care in that case we *all* get spammed! There is NO OWNER of comp.lang.python; and turning a comp.* group into moderated takes a fairly long time assuming you can find someone willing to be the moderators -- what would likely happen is that comp.lang.python.moderated would be created and then take a few months to be picked up by the servers, and a few more months for the real users to leave comp.lang.python to use it. Oh, and also the hassle of the mailing-listusenet gateway (does it pass traffic to both groups, drop the existing one, etc.). And readers on Google may still see spam if Google takes posts stuff before it passes through the moderation board. For the benefit of those who might have missed it, I'll repeat that I'm reading this from gmane.comp.python.general and see little or no spam. Regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Everything you ever wanted to know about super is collected here: http://micheles.googlecode.com/hg/artima/python/super.pdf M.S. -- http://mail.python.org/mailman/listinfo/python-list
obtaining pid of child process
Hi,
I am using python's multiprocessing module to spawn new process
as follows :
import multiprocessing
import os
d = multiprocessing.Process(target=os.system,args=('iostat 2
a.txt',))
d.start()
I want to obtain pid of iostat command or the command executed using
multiprocessing module
When I execute :
d.pid
it gives me pid of subshell in which this command is running .
Any help will be valuable .
Thanks in advance
--
http://mail.python.org/mailman/listinfo/python-list
Re: obtaining pid of child process
On Sun, Jul 25, 2010 at 9:02 PM, tazimk tazimkol...@gmail.com wrote:
Hi,
I am using python's multiprocessing module to spawn new process
as follows :
import multiprocessing
import os
d = multiprocessing.Process(target=os.system,args=('iostat 2
a.txt',))
d.start()
I want to obtain pid of iostat command or the command executed using
multiprocessing module
`multiprocessing` isn't the best module for this; use `subprocess` instead:
from subprocess import Popen, PIPE
process = Popen([iostat], stderr=open(a.txt, 'w'), stdout=PIPE)
print(the PID is, process.pid)
`multiprocessing` is used for parallelism in Python code, as an
alternative to threads. `subprocess` is used for running external
commands, as a preferred alternative to os.system() among other
things.
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unicode error
On Sun, 25 Jul 2010 14:47:11 +, Steven D'Aprano wrote: But in the meanwhile, once you get an error, you know what it is. You can intentionally feed code bad data and see what you get. And then maybe add a test to make sure your code traps such errors. That doesn't really help with exceptions which are triggered by external factors rather than explicit inputs. Huh? What do you mean by external factors? I mean this: If you mean external factors like the network goes down or the disk is full, you can still test for those with appropriate test doubles (think stunt doubles, only for testing) such as stubs or mocks. It's a little bit more work (sometimes a lot more work), but it can be done. I'd say a lot is more often the case. Also, if you're writing libraries (rather than self-contained programs), you have no control over the arguments. You can't control what the caller passes to you, but once you have it, you have total control over it. Total control insofar as you can wrap all method calls in semi-bare excepts (i.e. catch any Exception but not Interrupt). Coupled with the fact that duck typing is quite widely advocated in Python circles, you're stuck with the possibility that any method call on any argument can raise any exception. This is even true for calls to standard library functions or methods of standard classes if you're passing caller-supplied objects as arguments. That's a gross exaggeration. It's true that some methods could in theory raise any exception, but in practice most exceptions are vanishingly rare. Now *that* is a gross exaggeration. Exceptions are by their nature exceptional, in some sense of the word. But a substantial part of Python development is playing whac-a-mole with exceptions. Write code, run code, get traceback, either fix the cause (LBYL) or handle the exception (EAFP), wash, rinse, repeat. And it isn't even remotely correct that any method could raise anything. If you can get something other than NameError, ValueError or TypeError by calling spam.index(arg), I'd like to see it. How common is it to call methods on a string literal in real-world code? It's far, far more common to call methods on an argument or expression whose value could be any string-like object (e.g. UserString or a str subclass). IOW, it's almost correct that any method can raise any exception. The fact that the number of counter-examples is non-zero doesn't really change this. Even an isinstance() check won't help, as nothing prohibits a subclass from raising exceptions which the original doesn't. Even using type(x) == sometype doesn't help if x's methods involve calling methods of user-supplied values (unless those methods are wrapped in catch-all excepts). Java's checked exception mechanism was based on real-world experience of the pitfalls of abstract types. And that experience was gained in environments where interface specifications were far more detailed than is the norm in the Python world. Frankly, it sounds to me that you're over-analysing all the things that could go wrong rather than focusing on the things that actually do go wrong. See Murphy's Law. That's your prerogative, of course, but I don't think you'll get much support for it here. Alas, I suspect that you're correct. Which is why I don't advocate using Python for serious software. Neither the language nor its culture are amenable to robustness. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:42 PM, David Robinow wrote: On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener eldie...@tropicsoft.invalid wrote: On 7/25/2010 5:57 PM, Thomas Jollans wrote: So if a standard library module ( or distributed library ) executes a call internally to 'python xxx yyy' or executes a call internally to 'someScript.py yyy', you're fine with multiple co-existing versions of Python on your system ? Because under Windows the first call will look for the python.exe first found in the PATH while the second call will find the python.exe associated with the .py extension. And it does not matter in either case what version of the multiple installed versions of Python which are on my system is currently executing that script. And please don't say that there is some sort of guarantee that no library or installation would invoke Python in such a way as opposed to the normal 'import AScript.py' method of using functionality in Python scripts. Edward, I'm having a really hard time understanding your problem. Could you give an example of some real code that is causing you difficulty? I start a Python script for version X by going to X's root directory and invoking 'python someScript.py' from the command line. Does that not sound reasonable ? In SomeScript.py there is an internal call to 'python someOtherScript.y someParameters'. But the call invokes another version of Python because it is that version which is in the PATH. Or in SomeScript.py there is an internal call to 'someOtherScript.py someParameters'. But the call invokes another version of Python because the .py extension is associated with a different version. My solution is that I will write some code which sets a particular version of Python as the current version for a particular time, meaning that version will be in the PATH and associated with Python extensions. The way I do not have to worry when I externally invoke Python from the command line that internal calls are going to some other version. -- http://mail.python.org/mailman/listinfo/python-list
Undo-Redo, copy instance, custom events and a problem
Hi, I am developing an app using wxPython. The Undo-Redo implementation is based on storing pre post state of an attribute. You store the instance before changing the value and store the instance after changing the values. While undoing or redoing, you copy/replace the current state with stored once. For color attribute as soon as you choose a color, here is the code: # Custom Event evt = ValueChangeEvent(EVT_COLOR_CHANGED.typeId, self.GetId()) # Store Pre State evt.SetPreState(copy.copy(self.attribute)) # Change the newly selected color self.attribute.setValue(R,G,B) # Store Post State evt.SetPostState(copy.copy(self.attribute)) # Throw Custom Event self.GetEventHandler().ProcessEvent(evt) Both states are copied as new instance with correct values. The problem is when this event is getting fired. evt.GetPreState().GetValue() is showing the post color value. Although GetPreState() GetPostState() are showing two different instances but I have no idea why values are not coming/stored correctly. Some where in between is messed up and post-state values are copied in pre-state. On a side note, self.attribute.setValue takes three floating values for R,G B colors but stored them as a text. Similarly self.attribute.getValue() converts text into float and returns. Is there anything related to scope or something? Cheers Prashant -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On Mon, 26 Jul 2010 00:36:47 -0400, Edward Diener wrote: On 7/25/2010 10:42 PM, David Robinow wrote: [...] Edward, I'm having a really hard time understanding your problem. Could you give an example of some real code that is causing you difficulty? I start a Python script for version X by going to X's root directory and invoking 'python someScript.py' from the command line. Does that not sound reasonable ? No it doesn't, it's a very unreasonable thing to do. If you have multiple versions of Python, you should name them appropriately so you can launch the appropriate version from any directory: python26 someScript.py # calls python31 secondScript.py internally python31 anotherScript.py # calls python25 thirdScript.py internally etc. Or give the full path to the executable: C:\Programs\python26\python.exe someScript.py # calls C:\Programs\python31\python.exe secondScript.py internally If a script doesn't do this, then the script should be treated as buggy. In SomeScript.py there is an internal call to 'python someOtherScript.y someParameters'. That's a pretty dodgy thing to do in the first place, unless you can guarantee that there's only one executable called python. Otherwise, how do you know which one will be called? You can't easily predict which one will be called, so don't do it unless you want your scripts to call arbitrary executables. But the call invokes another version of Python because it is that version which is in the PATH. Or in SomeScript.py there is an internal call to 'someOtherScript.py someParameters'. But the call invokes another version of Python because the .py extension is associated with a different version. Exactly. The root of your problem is that there are multiple executables called python and you don't know which one you will get. So don't do that. My solution is that I will write some code which sets a particular version of Python as the current version for a particular time, meaning that version will be in the PATH and associated with Python extensions. /facepalm The way I do not have to worry when I externally invoke Python from the command line that internal calls are going to some other version. Good luck with that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[issue9375] ElementPath parser in ElementTree 1.3 does not reject element// as invalid
New submission from Stefan Behnel sco...@users.sourceforge.net:
Subject says it all:
Python 2.7 (r27:82500, Jul 5 2010, 13:37:06)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import xml.etree.ElementTree as ET
el = ET.Element('hui')
el.findall('section//')
[]
--
components: Library (Lib), XML
messages: 111521
nosy: scoder
priority: normal
severity: normal
status: open
title: ElementPath parser in ElementTree 1.3 does not reject element// as
invalid
versions: Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9375
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9375] ElementPath parser in ElementTree 1.3 does not reject element// as invalid
Changes by Stefan Behnel sco...@users.sourceforge.net: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9375] ElementPath parser in ElementTree 1.3 does not reject element// as invalid
Stefan Behnel sco...@users.sourceforge.net added the comment: The parser actually starts with this code: def iterfind(elem, path, namespaces=None): # compile selector pattern if path[-1:] == /: path = path + * # implicit all (FIXME: keep this?) IMHO, the 'FIXME' is worth revisiting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9375] ElementPath parser in ElementTree 1.3 does not reject element// as invalid
Changes by Stefan Behnel sco...@users.sourceforge.net: -- nosy: +effbot, flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7303] pkgutil lacks documentation for useful functions
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7303 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closing as no response to msg110598. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2796] Build issues in DragonFly BSD
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closing as no response to msg97413 or msg110632. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closing as no response to msg110681. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8888] Promote SafeConfigParser and warn about ConfigParser
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closed as duplicate of #6517. -- nosy: +BreamoreBoy resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2204] document ConfigParser behaviour when a file has same section multiple times
Mark Lawrence breamore...@yahoo.co.uk added the comment: @Łukasz: could you provide a patch that clarifies the default behaviour. -- assignee: georg.brandl - d...@python nosy: +BreamoreBoy, d...@python stage: unit test needed - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7635] 19.6 xml.dom.pulldom doc: stub?
Mark Smith mark.sm...@practicalpoetry.co.uk added the comment: Terry, thanks for the feedback! I have added a patch, replacing the previous one, which deals with your points 1 and 3 in the following ways: 1. I have used (an edited form of) your synopsis - I've removed the details of exactly what is returned from the iterator, as I thought it made the sentence structure slightly awkward - hope you don't mind. I've moved the old synopsis to the heading, which is where I intended it to be anyway. 3. I added the newline - I don't think this is really a problem, but neither is the fix :) Regarding point 2: I agree with you - I struggled with whether to include references to these classes, eventually settling for what you see. I suppose they could be re-used for converting SAX events to DOM nodes, so it could be useful to know they are there. SAX2DOM isn't even used internally, so is technically part of the module's public interface, but with such brittle behaviour that I think it should really be removed. It automatically adds children to their parent when they are parsed -- but the children will only be parsed if the buffer is large enough. If it isn't then you can get incorrectly empty or even partial subtrees. -- Added file: http://bugs.python.org/file18194/7635_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7635] 19.6 xml.dom.pulldom doc: stub?
Changes by Mark Smith mark.sm...@practicalpoetry.co.uk: Removed file: http://bugs.python.org/file18179/7635.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7519] ConfigParser can't read files with BOM markers
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closing as the main BOM issue is addressed on #7651 and a solution to the OP's problem is given in msg97335. -- nosy: +BreamoreBoy resolution: - duplicate status: open - closed superseder: - Python3: guess text file charset using the BOM ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Mark Lawrence breamore...@yahoo.co.uk added the comment: @Łukasz: please provide an updated patch. -- nosy: +BreamoreBoy stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Alex Willmer a...@moreati.org.uk added the comment: On 25 July 2010 03:46, Matthew Barnett rep...@bugs.python.org wrote: issue2636-20100725.zip is a new version of the regex module. This is now packaged and uploaded to PyPI http://pypi.python.org/pypi/regex/0.1.20100725 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1773632] Remove references to _xmlrpclib from xmlrpclib.py
Mark Lawrence breamore...@yahoo.co.uk added the comment: This has already been done for py3k. Is it worth doing for 2.6 or 2.7? -- nosy: +BreamoreBoy versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1773632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2864] etree: Add XPath documentation
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- assignee: effbot - d...@python nosy: -effbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue648658] xmlrpc can't do proxied HTTP
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- assignee: effbot - orsenthil nosy: +orsenthil -effbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue648658 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767933] Badly formed XML using etree and utf-16
Mark Lawrence breamore...@yahoo.co.uk added the comment: @Richard: Could you provide a test case for this, or do you consider it beyond your Python capabilities allowing for your comments on msg75875? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1767933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Mark Lawrence breamore...@yahoo.co.uk added the comment: Tried the patch against 2.7 and got RuntimeError: Attempt to read ZIP archive that was already closed for TestsWithSourceFile test_deflated and test_stored. The patch needs updating for py3k. -- nosy: +BreamoreBoy stage: unit test needed - patch review versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1739648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked
Mark Lawrence breamore...@yahoo.co.uk added the comment: @David: I couldn't apply the patches directly with tortoisesvn cos of the git format so tried to do them manually but failed. E.g. in test_os I couldn't find PYTHONTESTVAROS to insert the two new lines after and in test_posix couldn't find PYTHONTESTVARB. Am I having a bad day at the office or did you have one yesterday? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9376] Refer to gnuwin32 diff util on development FAQ
New submission from Mark Lawrence breamore...@yahoo.co.uk: Section 6.1 How to make a patch? currently reads in part (a Windows version is available as part of the cygwin tools). I suggest that this is reworded to read (Windows versions are available as part of the cygwin tools or as part of the gnuwin32 project) I simply find it much easier to download and install these individual tools, e.g. I also have their version of grep which is vastly superior to Windows find -- assignee: d...@python components: Documentation keywords: easy messages: 111536 nosy: BreamoreBoy, d...@python priority: normal severity: normal status: open title: Refer to gnuwin32 diff util on development FAQ type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9376 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1463043] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Mark Lawrence breamore...@yahoo.co.uk added the comment: Can this be closed given that we're now at 2.7 and py3k and openSUSE is at 11.3? -- nosy: +BreamoreBoy status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1463043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6098] xml.dom.minidom incorrectly claims DOM Level 3 conformance
Mark Lawrence breamore...@yahoo.co.uk added the comment: Could someone with minidom experience please comment on this, thanks. -- nosy: +BreamoreBoy versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue777884] minidom.py -- TypeError: object doesn't support slice assig
Mark Lawrence breamore...@yahoo.co.uk added the comment: This is still an issue with all Python versions, is there anybody who could take this on please? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue777884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7139] ElementTree: Incorrect serialization of end-of-line characters in attribute values
Mark Lawrence breamore...@yahoo.co.uk added the comment: Closed as a duplicate of #5752 which has patches attached. -- nosy: +BreamoreBoy resolution: - duplicate status: open - closed versions: +Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Alan McIntyre alan.mcint...@gmail.com added the comment: Ok, I'll see if I can update that in the next week or so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1739648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1495229] W3C - Python DOM type mapping docs need updating
Mark Lawrence breamore...@yahoo.co.uk added the comment: Nobody has objected to Terry Reedy's recommendations so can the docs be updated please. -- assignee: loewis - d...@python nosy: +BreamoreBoy, d...@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1495229 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1773632] Remove references to _xmlrpclib from xmlrpclib.py
Alan McIntyre alan.mcint...@gmail.com added the comment: Both 2.6 and 2.7 are in the maintenance-only stage at this point, aren't they? I personally don't think this important enough to worry about for 2.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1773632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6655] etree iterative find[text]
Mark Lawrence breamore...@yahoo.co.uk added the comment: @Digitalxero: could you provide an updated unit test file please. -- nosy: +BreamoreBoy stage: - unit test needed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5762] AttributeError: 'NoneType' object has no attribute 'replace'
Mark Lawrence breamore...@yahoo.co.uk added the comment: This issue will not move unless somebody provides a unit test for it. -- nosy: +BreamoreBoy stage: - unit test needed type: crash - behavior versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7637] Improve 19.5. xml.dom.minidom doc
Mark Lawrence breamore...@yahoo.co.uk added the comment: Items 1) and 3) have been committed, only 2) needs to be addressed. -- assignee: georg.brandl - d...@python nosy: +BreamoreBoy, d...@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9375] ElementPath parser in ElementTree 1.3 does not reject element// as invalid
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Lib/test/test_trace.py is now moved to Lib/test/test_sys_settrace.py. 3.2: r83140 r83141 3.1: r83143 2.7: r83142 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Eli, test_trace_module.py is a good start and I would like to commit it soon. I have a few nitpicks and a suggestion. 1. pprint module is not used in the tests so it should not be imported. 2. It is better to do run_unittest(__name__) in test_main() than list tests explicitly. run_unittest(__name__) will find all classes that derive from TestCase in the module. Note that not all test runners use test_main(). 3. Please don't start docstrings with a space. 4. test_trace is out of the way in 2.7 now, so you can use proper name. If you use SVN, please do svn add Lib/test/test_trace.py with your next revision and post the output of svn diff. 5. A suggestion: since we are doing white-box testing of the Trace class, I would recommend calling Trace methods such as globaltrace or localtrace directly from unit tests rather than rely on settrace registrations. That may require faking frames, but I think you can get away with simply passing the current frame with the events. Whether or not sys.settrace is working correctly is tested in the old test_trace (renamed to test_sys_settrace) now. Thanks for moving this forward. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8733] list type and UserList do not call super in __init__ and therefore, they cannot be parents in a multiple inheritence scheme
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked
David Watson bai...@users.sourceforge.net added the comment: You're having a bad day at the office :) Just use patch -p1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
New submission from David Watson bai...@users.sourceforge.net:
The functions in the socket module which return host/domain
names, such as gethostbyaddr() and getnameinfo(), are wrappers
around byte-oriented interfaces but return Unicode strings in
3.x, and have not been updated to deal with undecodable byte
sequences in the results, as discussed in PEP 383.
Some DNS resolvers do discard hostnames not matching the
ASCII-only RFC 1123 syntax, but checks for this may be absent or
turned off, and non-ASCII bytes can be returned via other lookup
facilities such as /etc/hosts.
Currently, names are converted to str objects using
PyUnicode_FromString(), i.e. by attempting to decode them as
UTF-8. This can fail with UnicodeError of course, but even if it
succeeds, any non-ASCII names returned will fail to round-trip
correctly because most socket functions encode string arguments
into IDNA ASCII-compatible form before using them. For example,
with UTF-8 encoded entries
127.0.0.2 €
127.0.0.3 xn--lzg
in /etc/hosts, I get:
Python 3.1.2 (r312:79147, Mar 23 2010, 19:02:21)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type help, copyright, credits or license for more
information.
from socket import *
getnameinfo((127.0.0.2, 0), 0)
('€', '0')
getaddrinfo(*_)
[(2, 1, 6, '', ('127.0.0.3', 0)), (2, 2, 17, '', ('127.0.0.3', 0)), (2, 3, 0,
'', ('127.0.0.3', 0))]
Here, getaddrinfo() has encoded € to its corresponding ACE
label xn--lzg, which maps to a different address.
PEP 383 can't be applied as-is here, since if the name happened
to be decodable in the file system encoding (and thus was
returned as valid non-ASCII Unicode), the result would fail to
round-trip correctly as shown above, but I think there is a
solution which follows the general idea of PEP 383.
Surrogate characters are not allowed in IDNs, since they are
prohibited by Nameprep[1][2], so if names were instead decoded as
ASCII with the surrogateescape error handler, strings
representing non-ASCII names would always contain surrogate
characters representing the non-ASCII bytes, and would therefore
fail to encode with the IDNA codec. Thus there would be no
ambiguity between these strings and valid IDNs. The attached
ascii-surrogateescape.diff does this.
The returned strings could then be made to round-trip as
arguments, by having functions that take hostname arguments
attempt to encode them using ASCII/surrogateescape first before
trying IDNA encoding. Since IDNA leaves ASCII names unchanged
and surrogate characters are not allowed in IDNs, this would not
change the interpretation of any string hostnames that are
currently accepted. It would remove the 63-octet limit on label
length currently imposed due to the IDNA encoding, for ASCII
names only, but since this is imposed due to the 63-octet limit
of the DNS, and non-IDN names may be intended for other
resolution mechanisms, I think this is a feature, not a bug :)
The patch try-surrogateescape-first.diff implements the above for
all relevant interfaces, including gethostbyaddr() and
getnameinfo(), which do currently accept hostnames, even if the
documentation is vague (in the standard library, socket.fqdn()
calls gethostbyaddr() with a hostname, and the os module docs
suggest calling socket.gethostbyaddr(socket.gethostname()) to get
the fully-qualified hostname).
The patch still allows hostnames to be passed as bytes objects,
but to simplify the implementation, it removes support for
bytearray (as has been done for pathnames in 3.2). Bytearrays
are currently only accepted by the socket object methods
(.connect(), etc.), and this is undocumented and perhaps
unintentional - the get*() functions have never accepted them.
One problem with the surrogateescape scheme would be with
existing code that looks up an address and then tries to write
the hostname to a log file or use it as part of the wire
protocol, since the surrogate characters would fail to encode as
ASCII or UTF-8, but the code would appear to work normally until
it encountered a non-ASCII hostname, allowing the problem to go
undetected.
On the other hand, such code is probably broken as things stand,
given that the address lookup functions can undocumentedly raise
UnicodeError in the same situation. Also, protocol definitions
often specify some variant of the RFC 1123 syntax for hostnames
(thus making non-ASCII bytes illegal), so code that checked for
this prior to encoding the name would probably be OK, but it's
more likely the exception than the rule.
An alternative approach might be to return all hostnames as bytes
objects, thus breaking everything immediately and obviously...
[1] http://tools.ietf.org/html/rfc3491#section-5
[2] http://tools.ietf.org/html/rfc3454#appendix-C.5
--
components: Extension Modules
files: ascii-surrogateescape.diff
keywords: patch
messages: 111550
nosy: baikie
priority: normal
severity: normal
status: open
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain
[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
Changes by David Watson bai...@users.sourceforge.net: Added file: http://bugs.python.org/file18196/try-surrogateescape-first.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9172] zipfile.extractall always raises an OSError after successfully unzipping all files
Teemu Rytkönen teemu.rytko...@gmail.com added the comment: Hi! I encountered the same problem and I debugged it a bit.. I think it not doing the entire unzipping again, but the problem is that the winzip packaged zip actually contains all file and directory entries and it fails trying to create already existing directory (because the dir has been created for the files that are in it). I tried a quick and dirty fix for the zipfile _extract_member method, which basically should fix the problem! So here I create the directory only if it is not already existing, to get those empty directories created inside the zip. zipfile: 959:if member.filename[-1] == '/': add if not os.path.isdir(targetpath): 960:os.mkdir(targetpath) -- nosy: +terytkon versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
