[ python-Bugs-1681228 ] webbrowser priorities
Bugs item #1681228, was opened at 2007-03-15 09:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser priorities
Initial Comment:
Recently I've run into a Windows-specific bug in webbrowser (using close_fds
and preexec_fn in subprocess.Popen), and I noticed there are some strange
priorities in the default browsers.
For example:
* Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred
over the *user's* preferred browser on Windows?
* Why is the GNOME default browser preferred even if the user is currently
running KDE (but has GNOME installed)?
>From all the platforms, only on Mac OS X it really respects the user's
>preferrencies.
I'd like to propose this:
* On Windows, make "windows-default" the first in _try_order
* If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and
command "gnome-open" exists, use `gnome-open '%s'`.
* If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true")
and command "kfmclient" exists, use `kfmclient exec '%s'`.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681228 ] webbrowser priorities
Bugs item #1681228, was opened at 2007-03-15 09:03
Message generated for change (Comment added) made by luks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser priorities
Initial Comment:
Recently I've run into a Windows-specific bug in webbrowser (using close_fds
and preexec_fn in subprocess.Popen), and I noticed there are some strange
priorities in the default browsers.
For example:
* Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred
over the *user's* preferred browser on Windows?
* Why is the GNOME default browser preferred even if the user is currently
running KDE (but has GNOME installed)?
>From all the platforms, only on Mac OS X it really respects the user's
>preferrencies.
I'd like to propose this:
* On Windows, make "windows-default" the first in _try_order
* If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and
command "gnome-open" exists, use `gnome-open '%s'`.
* If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true")
and command "kfmclient" exists, use `kfmclient exec '%s'`.
--
>Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 09:06
Message:
Logged In: YES
user_id=587716
Originator: YES
Just a note, if you agree with this behavior, I'll be more than happy to
make a patch. Currently I'm using similar mechanism in my own code (because
Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can
easily turn it into a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681248 ] WindowsError in webbrowser.open
Bugs item #1681248, was opened at 2007-03-15 09:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681248 ] WindowsError in webbrowser.open
Bugs item #1681248, was opened at 2007-03-15 09:35 Message generated for change (Settings changed) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681228 ] webbrowser priorities
Bugs item #1681228, was opened at 2007-03-15 08:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser priorities
Initial Comment:
Recently I've run into a Windows-specific bug in webbrowser (using close_fds
and preexec_fn in subprocess.Popen), and I noticed there are some strange
priorities in the default browsers.
For example:
* Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred
over the *user's* preferred browser on Windows?
* Why is the GNOME default browser preferred even if the user is currently
running KDE (but has GNOME installed)?
>From all the platforms, only on Mac OS X it really respects the user's
>preferrencies.
I'd like to propose this:
* On Windows, make "windows-default" the first in _try_order
* If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and
command "gnome-open" exists, use `gnome-open '%s'`.
* If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true")
and command "kfmclient" exists, use `kfmclient exec '%s'`.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-15 08:50
Message:
Logged In: YES
user_id=849994
Originator: NO
I agree with your suggestion. Can you make a patch (and include a fix for
the other bug you filed)?
--
Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 08:06
Message:
Logged In: YES
user_id=587716
Originator: YES
Just a note, if you agree with this behavior, I'll be more than happy to
make a patch. Currently I'm using similar mechanism in my own code (because
Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can
easily turn it into a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1068268 ] subprocess is not EINTR-safe
Bugs item #1068268, was opened at 2004-11-17 22:07 Message generated for change (Comment added) made by mpitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Peter Åstrand (astrand) Assigned to: Peter Åstrand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. -- Comment By: Martin Pitt (mpitt) Date: 2007-03-15 09:57 Message: Logged In: YES user_id=80975 Originator: NO Updated patch: http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch I removed the _read_all() function, since that broke the 1 MB exception limit and does not seem to be necessary in the first place. -- Comment By: Martin Pitt (mpitt) Date: 2007-03-14 23:36 Message: Logged In: YES user_id=80975 Originator: NO I updated Peter's original patch to 2.5+svn fixes and added proper tests to test_subprocess.py. It works great now. What do you think about this approach? Fixing it only in submodule feels a bit strange, but then again, this is meant to be an easy to use abstraction, and most of the people that were hit by this (according to Google) encountered the problem in subprocess. I don't see how to attach something here, so I attached the updated patch to the Ubuntu bug (https://launchpad.net/bugs/87292): http://librarian.launchpad.net/6807594/subprocess-eintr-safety.patch Thanks, Martin -- Comment By: Martin Pitt (mpitt) Date: 2007-02-26 13:15 Message: Logged In: YES user_id=80975 Originator: NO I just got two different Ubuntu bug reports about this problem as well, and I'm unsure how to circumvent this at the application level. http://librarian.launchpad.net/6514580/Traceback.txt http://librarian.launchpad.net/6527195/Traceback.txt (from https://launchpad.net/bugs/87292 and its duplicate) -- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-22 08:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R -- Comment By: Peter Åstrand (astrand) Date: 2004-11-17 22:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681228 ] webbrowser priorities
Bugs item #1681228, was opened at 2007-03-15 09:03
Message generated for change (Comment added) made by luks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser priorities
Initial Comment:
Recently I've run into a Windows-specific bug in webbrowser (using close_fds
and preexec_fn in subprocess.Popen), and I noticed there are some strange
priorities in the default browsers.
For example:
* Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred
over the *user's* preferred browser on Windows?
* Why is the GNOME default browser preferred even if the user is currently
running KDE (but has GNOME installed)?
>From all the platforms, only on Mac OS X it really respects the user's
>preferrencies.
I'd like to propose this:
* On Windows, make "windows-default" the first in _try_order
* If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and
command "gnome-open" exists, use `gnome-open '%s'`.
* If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true")
and command "kfmclient" exists, use `kfmclient exec '%s'`.
--
>Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 12:47
Message:
Logged In: YES
user_id=587716
Originator: YES
Ok, here is the patch, including the fix for #1681248. The priorities on
all platforms with this patch are:
1. The BROWSER environment variable overrides everything
2. Next step is to check the preferred browsers for desktop environments
(Windows, Mac OS X, GNOME and KDE)
3. Fallback to available installed browsers (firefox, opera, konqueror,
epiphany, ...)
File Added: webbrowser-defaults.diff
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-15 09:50
Message:
Logged In: YES
user_id=849994
Originator: NO
I agree with your suggestion. Can you make a patch (and include a fix for
the other bug you filed)?
--
Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 09:06
Message:
Logged In: YES
user_id=587716
Originator: YES
Just a note, if you agree with this behavior, I'll be more than happy to
make a patch. Currently I'm using similar mechanism in my own code (because
Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can
easily turn it into a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-931877 ] Segfault in object_reduce_ex
Bugs item #931877, was opened at 2004-04-08 19:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Segfault in object_reduce_ex Initial Comment: Shane Hathaway bumped into this, unbounded recursion in typeobject.c's object_reduce_ex(). This occurs in Python 2.3.3 and current CVS. Assigned to Guido, to ponder whether object_reduce_ex is doing what it should; if it is (which seems likely to me), I suppose we need to inject a recursion counter to prevent the segfault. The failing case is short, but I'll attach it (temp99.py) to avoid SF line mangling. While the test uses pickle, same symptom if it's changed to use cPickle instead. Jim Fulton's analysis: """ This is a very clever infinite loop. The proxy doesn't actually proxy, but it does manage to confuse reduce about what's going on. reduce tries to figure out if it has been overridden by asking whether the class's reduce is the same as object.__reduce__. It doesn't expect to be lied to about the class. Things wouldn't have been so bad if the proxy had proxied __reduce__ as well as __class__. """ The priority hasn't been bumped, because "the real code" from which this was whittled down wasn't doing what it needed to do anyway, and the recursion went away when the real code was repaired. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-03-15 12:53 Message: Logged In: YES user_id=1326842 Originator: NO Fixed with said patch in rev. 54397, 54398 (2.5). -- Comment By: Žiga Seilnacht (zseil) Date: 2006-04-01 03:43 Message: Logged In: YES user_id=1326842 See patch #1462488. If that patch is accepted, this bug should be closed as fixed. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:05 Message: Logged In: YES user_id=6380 Unassigning. I need to concentrate on Python 3000. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:58 Message: Logged In: YES user_id=1188172 Still crashing with 2.5... -- Comment By: Nathan Srebro (nati) Date: 2004-11-30 02:26 Message: Logged In: YES user_id=63133 This infinite recursion also occurs in another place, that got me stumped for a couple of days when old code that worked with Python 2.2 stopped working. If __class__ is not fidgeted with (as in original bug report), but a descriptor returns a custom reduce for the class, but not for its objects, reduce enters an infinite loop on the object: """ class descriptor_for_reduce(object): def __get__(self,obj,tp=None): if obj is not None: return super(ASpecialClass,obj).__reduce__ return self.reducer def reducer(self,proto=None): return "VerySpecial" class ASpecialClass(object): __reduce__ = descriptor_for_reduce() copy.copy(ASpecialClass()) """ ASpecialClass().__reduce__ is object.__reduce__, which is implemented by typeobject.c:object_reduce_ex. This function (that doesn't know if its called as the __reduce__ or the __reduce_ex__ method) tries to detect if the object's __reduce__ is overridden. It does so by checking if the object's class's __reduce__ is overridden, and in fact it is. It then assumes that the object's __reduce__ is overridden, and calls it. But the object's __reduce__ is the same function, causing the infinite loop. If __reduce_ex__ is used instead of __reduce__, the problem goes away, ASpecialClass().__reduce_ex__() return the usual tuple, and ASpecialClass.__reduce_ex__() return "VerySpecial". But when __reduce__ is overridden, ASpecialClass().__reduce__() enters an infinite loop. I believe this is a legitimate example that should behave just as when __reduce_ex__ is overridden. The example doesn't lie about __class__, and it is certainly legitimate for define a property that behaves differently for the class and for its objects. Where did this come up and why would I ever care about a class's __reduce__? The __reduce__ attribute of a class is never used by (the standard) pickle or copy, since save_global() is called instead. However, I have a custom pickler, implemented as a subclass of pickle.Pickler, which falls back on the class's __reduce__ when save_global() fails. This way, I can pickle certain classes that are created at run-time (and
[ python-Bugs-1681671 ] Python and Indeterminate Forms (Math)
Bugs item #1681671, was opened at 2007-03-15 15:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jehahn (jehahn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python and Indeterminate Forms (Math)
Initial Comment:
Primary example:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0 ** 0
1
Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate
form. 0 ** 0 should probably return NaN and NOT 1.
Other examples include:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf ** 0
1.0
>>> 1 ** inf
1.0
For a few others, Python provides an arguably correct answer of NaN. Examples:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf * 0
nan
>>> inf / inf
nan
>>> inf - inf
nan
And, of course, for the most obvious indeterminate form (0/0) Python does
precisely the right thing:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0/0
Traceback (most recent call last):
File "", line 1, in ?
ZeroDivisionError: integer division or modulo by zero
It could be argued that the correct thing to do here is to throw an exception -
mathematically speaking these forms are about as meaningful as division by zero
which Python handles by throwing an exception. (unlike Java and IEEE 754,
which do arguably evil things here by returning +/- infinity for the quantity
k/0 for all k != 0)
Unfortunately, some people doing numerical work may have gotten used to the
current Python behavior so the change isn't without risk. And some of the
current values are common "conventions" used to simplify certain common issues.
(e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform
(having only tried it on a couple of the boxes I have handy.)
However, from a mathematical purist's standpoint, Python is doing the wrong
thing on these counts.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows
Bugs item #1681674, was opened at 2007-03-15 20:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows
Bugs item #1681674, was opened at 2007-03-15 20:32 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. -- >Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 20:33 Message: Logged In: YES user_id=376953 Originator: YES File Added: tst_subprocess_socket_client.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers
Bugs item #1660009, was opened at 2007-02-14 19:52
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Margrave (davidma)
Assigned to: Nobody/Anonymous (nobody)
Summary: continuing problem with httplib multiple set-cookie headers
Initial Comment:
This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was
unable to re-open.
The workaround that was adopted in the previous bug tracker item was to combine
multiple set-cookie headers received from the server, into a single set-cookie
element in the headers dictionary, with the cookies joined into a
comma-separated string.
The problem arises when a comma character appears inside the 'expires' field of
one of the cookies. This makes it difficult to split the cookie headers back
apart. The comma character should be escaped, or a different separator
character used.
i.e.
expires=Sun, 17-Jan-2038 19:14:07 GMT
For now I am using the workaround that gstein suggested, use
response.msg.getallmatchingheaders()
Python 2.3 has this behavior, and probably later versions.
--
Comment By: John J Lee (jjlee)
Date: 2007-03-15 20:19
Message:
Logged In: YES
user_id=261020
Originator: NO
OK, thanks!
That certainly does look wrong. The Set-Cookie case should be
special-cased in that method, I think.
--
Comment By: David Margrave (davidma)
Date: 2007-03-15 00:58
Message:
Logged In: YES
user_id=31040
Originator: YES
See the addheader method of the HTTPMessage class in httplib.py
def addheader(self, key, value):
"""Add header for field key handling repeats."""
prev = self.dict.get(key)
if prev is None:
self.dict[key] = value
else:
combined = ", ".join((prev, value))
self.dict[key] = combined
also see the original tracker entry where this fix was first discussed &
implemented
https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470
--
Comment By: John J Lee (jjlee)
Date: 2007-03-15 00:45
Message:
Logged In: YES
user_id=261020
Originator: NO
Huh?
1. *What* behaviour is correct? You still have not said which bit of code
you're talking about, or even which module.
2. You seem to have got the sense of what I said backwards. As I said,
RFC 2616 is (in practice) WRONG about joining with commas being OK for
Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite
what RFC 2616 says.
--
Comment By: David Margrave (davidma)
Date: 2007-03-15 00:30
Message:
Logged In: YES
user_id=31040
Originator: YES
fair enough, the RFC says thay have to be joinable with commas, so the
behavior is correct. I can get by with getallmatchingheaders if I need
access to the original individual cookie values.
thanks,
dave
--
Comment By: John J Lee (jjlee)
Date: 2007-03-14 23:57
Message:
Logged In: YES
user_id=261020
Originator: NO
SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to
module SimpleHTTPServer rather than httplib, perhaps?
I don't see the particular bit of code you refer to (neither in httplib
nor in module SimpleHTTPServer), but re the general issue:
Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to
be combined with commas, Netscape Set-Cookie headers simply don't work that
way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie
headers must not be combined.
(Quoting does not help, because Netscape Set-Cookie headers contain cookie
values that 1. may contain commas and 2. do not support quoting -- any
quote (") characters are in fact part of the cookie value itself rather
than being part of a quoting mechanism. And there is no precedent for any
choice of delimter other than a comma, nor for any other Netscape
Set-Cookie cookie value quoting mechanism.)
--
Comment By: David Margrave (davidma)
Date: 2007-03-14 21:10
Message:
Logged In: YES
user_id=31040
Originator: YES
getallmatchingheaders() works fine.
The problem is with the self.headers in the SimpleHTTPRequestHandler and
derived classes.
A website may send multiple set-cookie headers, using gmail.com as an
example:
Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue
[ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers
Bugs item #1660009, was opened at 2007-02-14 19:52
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Margrave (davidma)
Assigned to: Nobody/Anonymous (nobody)
Summary: continuing problem with httplib multiple set-cookie headers
Initial Comment:
This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was
unable to re-open.
The workaround that was adopted in the previous bug tracker item was to combine
multiple set-cookie headers received from the server, into a single set-cookie
element in the headers dictionary, with the cookies joined into a
comma-separated string.
The problem arises when a comma character appears inside the 'expires' field of
one of the cookies. This makes it difficult to split the cookie headers back
apart. The comma character should be escaped, or a different separator
character used.
i.e.
expires=Sun, 17-Jan-2038 19:14:07 GMT
For now I am using the workaround that gstein suggested, use
response.msg.getallmatchingheaders()
Python 2.3 has this behavior, and probably later versions.
--
Comment By: John J Lee (jjlee)
Date: 2007-03-15 20:46
Message:
Logged In: YES
user_id=261020
Originator: NO
Hold on, httplib.HTTPMessage.addheader() is undocumented, hence private.
httplib.HTTPMessage.readheaders() itself calls that method, but also keeps
the raw multiple-header data in the .headers list, so
.getallmatchingheaders() still works.
So the only bug I see is that the documentation for APIs that return
should point out the fact that Set-Cookie is an oddity, and that
.getallmatchingheaders() should be used in that case.
--
Comment By: John J Lee (jjlee)
Date: 2007-03-15 20:19
Message:
Logged In: YES
user_id=261020
Originator: NO
OK, thanks!
That certainly does look wrong. The Set-Cookie case should be
special-cased in that method, I think.
--
Comment By: David Margrave (davidma)
Date: 2007-03-15 00:58
Message:
Logged In: YES
user_id=31040
Originator: YES
See the addheader method of the HTTPMessage class in httplib.py
def addheader(self, key, value):
"""Add header for field key handling repeats."""
prev = self.dict.get(key)
if prev is None:
self.dict[key] = value
else:
combined = ", ".join((prev, value))
self.dict[key] = combined
also see the original tracker entry where this fix was first discussed &
implemented
https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470
--
Comment By: John J Lee (jjlee)
Date: 2007-03-15 00:45
Message:
Logged In: YES
user_id=261020
Originator: NO
Huh?
1. *What* behaviour is correct? You still have not said which bit of code
you're talking about, or even which module.
2. You seem to have got the sense of what I said backwards. As I said,
RFC 2616 is (in practice) WRONG about joining with commas being OK for
Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite
what RFC 2616 says.
--
Comment By: David Margrave (davidma)
Date: 2007-03-15 00:30
Message:
Logged In: YES
user_id=31040
Originator: YES
fair enough, the RFC says thay have to be joinable with commas, so the
behavior is correct. I can get by with getallmatchingheaders if I need
access to the original individual cookie values.
thanks,
dave
--
Comment By: John J Lee (jjlee)
Date: 2007-03-14 23:57
Message:
Logged In: YES
user_id=261020
Originator: NO
SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to
module SimpleHTTPServer rather than httplib, perhaps?
I don't see the particular bit of code you refer to (neither in httplib
nor in module SimpleHTTPServer), but re the general issue:
Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to
be combined with commas, Netscape Set-Cookie headers simply don't work that
way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie
headers must not be combined.
(Quoting does not help, because Netscape Set-Cookie headers contain cookie
values that 1. may contain commas and 2. do not support quoting -- any
quote (") characters are in fact part of the cookie value itself rather
than being part of a quoting mech
[ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers
Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. -- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:49 Message: Logged In: YES user_id=261020 Originator: NO Sorry, my last paragraph got garbled a bit, here it is again: So the only bug I see is that the documentation for APIs that always return single headers (as opposed to lists of headers) should point out the fact that Set-Cookie is an oddity, and that .getallmatchingheaders() should be used in that case. -- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:46 Message: Logged In: YES user_id=261020 Originator: NO Hold on, httplib.HTTPMessage.addheader() is undocumented, hence private. httplib.HTTPMessage.readheaders() itself calls that method, but also keeps the raw multiple-header data in the .headers list, so .getallmatchingheaders() still works. So the only bug I see is that the documentation for APIs that return should point out the fact that Set-Cookie is an oddity, and that .getallmatchingheaders() should be used in that case. -- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:19 Message: Logged In: YES user_id=261020 Originator: NO OK, thanks! That certainly does look wrong. The Set-Cookie case should be special-cased in that method, I think. -- Comment By: David Margrave (davidma) Date: 2007-03-15 00:58 Message: Logged In: YES user_id=31040 Originator: YES See the addheader method of the HTTPMessage class in httplib.py def addheader(self, key, value): """Add header for field key handling repeats.""" prev = self.dict.get(key) if prev is None: self.dict[key] = value else: combined = ", ".join((prev, value)) self.dict[key] = combined also see the original tracker entry where this fix was first discussed & implemented https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470 -- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. -- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave -- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless o
[ python-Bugs-1681762 ] too long string causes segmentation fault
Bugs item #1681762, was opened at 2007-03-16 00:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: L (llukas11) Assigned to: Nobody/Anonymous (nobody) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [EMAIL PROTECTED] 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-443775 ] Update to the BEGIN_ALLOW_THREADS macros
Feature Requests item #443775, was opened at 2001-07-23 05:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 1
Private: No
Submitted By: Martin Sj�gren (msjogren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update to the BEGIN_ALLOW_THREADS macros
Initial Comment:
The Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS
currently do not support supplying WHERE to save the
thread state via an argument. I needed that for a
project myself so I wrote the following:
#ifdef WITH_THREAD
# define MY_BEGIN_ALLOW_THREADS(st)\
{ st = PyEval_SaveThread(); }
# define MY_END_ALLOW_THREADS(st) \
{ PyEval_RestoreThread(st); st = NULL; }
#else
# define MY_BEGIN_ALLOW_THREADS(st)
# define MY_END_ALLOW_THREADS(st) { st = NULL; }
#endif
This has, of course, the drawback that whenever the
Py_BEGIN_ALLOW_THREADS macro changes I have to change mine!
Therefore, I propose that these macros (under different
names certainly) or macros that work something like
this (I can't have asymmetric { and } in them, since I
needed to retrieve the thread state somewhere else) in
the standard Python distribution.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-15 22:27
Message:
Logged In: YES
user_id=33168
Originator: NO
As Brett says, you can use the _save variable. Since no one else has
requested this feature it doesn't seem worth it to change.
--
Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 17:08
Message:
Logged In: YES
user_id=357491
Couldn't you cheat and access the _save variable that
Py_BEGIN_ALLOW_THREADS creates? And does PEP 311 help solve your
usage need at all?
--
Comment By: Michael Dubner (dubnerm)
Date: 2003-01-17 21:16
Message:
Logged In: YES
user_id=39274
I think that current Py_BEGIN/END_ALLOW_THREADS macroses
model (with block) is choosen to enforce compile-time
pairwise check. Isn't it?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-464605 ] moving the Mac/ src dir to a diff packag
Feature Requests item #464605, was opened at 2001-09-24 14:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=464605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: moving the Mac/ src dir to a diff packag Initial Comment: Given the size of the Mac/ source directory, in the 2.1.1 source distribution (314 python files, 13 MB uncompressed of platform-specific material; a large amount of Mac-specific modules in the module documentation, would it be possible to move this outside the Python core source distribution ? This is taking dispk space and consuming CVS cpu time for nothing, for all but a few developpers. Thanks, Frederic Giacometti -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:39 Message: Logged In: YES user_id=33168 Originator: NO The file count is down to 268 not including files under .svn/. Although the size has increased to 17MB. Given the size of disks, etc and the effort involved with changing this, it's not likely to happen. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-16 01:09 Message: Logged In: YES user_id=21627 This won't happen. The Mac hierarchy was deliberately introduced into the Python CVS recently to simplify maintenance of the PythonMac port, and it won't be removed just for size reasons. OTOH, removing specific code because it is not used anymore may be feasible - it just needs somebody to identify these pieces. -- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-24 15:21 Message: Logged In: YES user_id=93657 Actually, it even a lot worse: there are over 1300 files in the Mac directory. Just think of the time CVS spends on them :(( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=464605&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-585915 ] assert return values
Feature Requests item #585915, was opened at 2002-07-24 06:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Thomas Leonard (tal197) Assigned to: Nobody/Anonymous (nobody) Summary: assert return values Initial Comment: It would be nice to write: def root(x): assert x >= 0 assert return >= 0 ... or def get_path(foo): if foo is None: return None assert return is not None ... and have the 'return' assertion checked when the function exits. 'return' is already a reserved keyword so the syntax doesn't introduce any incompatibility. This might make functions more self-documenting, since asserts at the end / in the middle tend to get lost. Even if the assert goes at the end, it's still clearer, eg: def foo(): ... assert min <= return <= max return bar(min, max) vs def foo(): ... tmp = bar(min, max) assert min <= tmp <= max return tmp Thanks! -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:48 Message: Logged In: YES user_id=33168 Originator: NO Raymond pretty much summed up my opinion. :-) This could only happen with a PEP and still doesn't seem likely. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 23:41 Message: Logged In: YES user_id=80475 Yuck! -- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:32 Message: Logged In: YES user_id=357491 Wouldn't this require turning 'return' into an expression instead of a statement? -- Comment By: Tim Peters (tim_one) Date: 2002-07-24 08:42 Message: Logged In: YES user_id=31435 Re-opened but moved to the Feature Request tracker (it's certainly not "a bug", but there's no rule against asking for new features either, provided they're in the right place). I don't believe there's any control flow in the suggestion, just that the name "return" be taken as being bound, in assert statements, to the possibly anonyous return expression. Eiffel does something very much like this for the benefit of expressing post-conditions. I certainly agree this way of spelling it in Python has problems, though, and a PEP would be in order. -- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-24 08:06 Message: Logged In: YES user_id=31392 I don't think this is a great feature. It seems like control flow via yield or return could easily be overlooked if it's inside an assert statement. Regardless of whether I like the idea, the SF bug tracker isn't the right place to make this suggestion. The right thing to do is write a PEP describing the feature in detail, then come up with a patch to implement it. If that's too much work, but you really like the idea, you could try to drum up interest on comp.lang.python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-706970 ] Including python-codecs codecs in standard distribution?
Feature Requests item #706970, was opened at 2003-03-20 08:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Bjorn Stabell (bjoerns) Assigned to: Nobody/Anonymous (nobody) Summary: Including python-codecs codecs in standard distribution? Initial Comment: Are there any plans to include the python-codecs in the standard distribution? They are Chinese and Japanese encodings, very useful if you live in China or Japan, which quite a few people do :) -- Imagine having to download ASCII encoding separately. What's stopping the inclusion, if anything? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:51 Message: Logged In: YES user_id=33168 Originator: NO CJK codecs was introduced in Python 2.4 IIRC. I assume that satisfies this request. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-29 09:32 Message: Logged In: YES user_id=12800 We should continue to discuss this. There are good technical and political reasons for re-evaluating whether to include Asian codecs in a batteries included Python distribution. I suggest python-dev and/or i18n-sig @python.org. -- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 07:05 Message: Logged In: YES user_id=21627 The size of the code, and its correctness is stopping inclusion of these codecs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-878458 ] optparse help text is not easily extensible
Feature Requests item #878458, was opened at 2004-01-16 10:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=878458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: optparse help text is not easily extensible Initial Comment: optparse doesn't allow for paragraph/narrative help text. This text would typically go below the option listing. There is currently no place to describe positional arguments, and this would be a simple way to allow for that. This could be provided as an extra keyword argument to OptionParser.__init__, included in the help in the function OptionParser.format_help. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:58 Message: Logged In: YES user_id=33168 Originator: NO Since optik is maintained separately from the core, this request should go there. http://sourceforge.net/projects/optik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=878458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-925537 ] dir(mod) OK or use vars(mod).keys()?
Feature Requests item #925537, was opened at 2004-03-29 11:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dir(mod) OK or use vars(mod).keys()? Initial Comment: The documentation on dir() notes that its behavior may change across releases. Several library modules use dir(x) in ways that might break if it changed too much. Should these be changed to use vars(obj).keys() (and possibly sort()), or should the note on dir() be removed? My own preference would just be to provide some guidance, such as "The output of dir() will always include all public variables which do not have a magic meaning." I realize that the standard library itself could be updated if dir() changes in an uncomfortable way. My real concern is which spelling to use in my own code. The library examples suggest a simpler (and clearer) dir(), but the documentation still says otherwise. A quick search for modules using dir() showed possible trouble in at least cgitb, cmd, FCNTL, inspect, optparse, os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, tokenize, unittest, and urllib2. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:02 Message: Logged In: YES user_id=33168 Originator: NO Has anything happened? Is this still relevant? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 23:05 Message: Logged In: YES user_id=80475 One possible change is in the works. Someone, suggested that dir() starting including the __name__ attribute. -- Comment By: Tim Peters (tim_one) Date: 2004-03-30 16:51 Message: Logged In: YES user_id=31435 Ya, dir() was *intended* to be a convenience for use at the interactive shell. I expect the only promise Guido wants to make about it is that it will show him stuff he finds interesting as Python changes <0.7 wink>. -- Comment By: Martin v. Löwis (loewis) Date: 2004-03-30 13:09 Message: Logged In: YES user_id=21627 Ok, marking it as a feature request then: Explicitly pointing out that behaviour may change in the future has usually been done because change in behaviour is anticipated, or has happened in the past. Giving stronger guarantees about future versions a feature that is currently not provided. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-30 07:28 Message: Logged In: YES user_id=764593 The ideal fix would be in documentation (and therefore policy). I want to do something like import_list = [x for x in dir(other_mod) if wanted(x)] It happens to work today on my machine, but the documentation says that dir(x) may return different results in different releases. This means that I can't safely use it in released code. If there were some indication that dir(module) would continue to return the same names as vars(module).keys(), then I could use it. If the differences were only in variables not intended for export, that would also be OK -- but dir does not current promise this. -- Comment By: Martin v. Löwis (loewis) Date: 2004-03-29 14:11 Message: Logged In: YES user_id=21627 I fail to see a bug. Which specific usage of dir() does not work as intended? -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 11:58 Message: Logged In: YES user_id=764593 Correction: "The output of dir (module) will always include ..." The most common use is figuring out what to do with (import from) a module. Symmetry suggests the same for a no-argument call or a class or type object, but object instances do not use their __dict__ for their attributes; the results are already different there. -jJ -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 11:39 Message: Logged In: YES user_id=764593 If there concern is over attributes that are "public" but don't exist until called, then most uses of dir and vars are already broken. An alternative reasonable promise would be The output of dir(obj) will always include all (public?, non-magical?) names in vars(obj).keys(). -
[ python-Feature Requests-950644 ] Allow any lvalue for function definitions
Feature Requests item #950644, was opened at 2004-05-08 18:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any lvalue for function definitions Initial Comment: A definition like: def M(x): return 2*x is the same as: M = lambda x: 2*x With the latter form, I can use any lvalue: A[0] = lambda x: 2*x B.f = lambda x: 2*x But with the first form, you're locked into just using a plain variable name. If this were fixed, it wouldn't break anything else but would be useful for making method definitons outside of a class definition: This came up when I was experimenting with David MacQuigg's ideas for prototype OO. I want to write something like: Account = Object.clone() Account.balance = 0 def Account.deposit(self, v): self.balance += v Unfortunately, the latter has to be written: def Account.deposit(self, v): self.balance += v Account.deposit = deposit -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=33168 Originator: NO Pinging to check interest. -- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-28 10:43 Message: Logged In: YES user_id=6380 This is the kind of thing that needs a lot of thought going into it to decide whether it is a net improvement to the language. Right now my gut feeling is that it's not worth the complexity, and more likely to be used towards unnecessary obfuscation. The redability gain is minimal if not negative IMO. Also, I've sometimes typed "def self.foo(args):" instead of "def foo(self, args):" suggesting that there's more than one intuitive way of interpreting the proposed syntax. Another minus point. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-24 10:08 Message: Logged In: YES user_id=80475 Guido, are you open to this? If so, I would be happy to draft a patch. I wouldn't expect it to become mainstream, but it would open the door to working with namespaces more directly. AFAICT, there is no downside to allowing this capability. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 22:57 Message: Logged In: YES user_id=80475 I think this should be made possible. It allows for alternate coding styles wihout harming anything else. The Lua programming language has something similar. It is a lightweight, non-OO language that revolves around making the best possible use of namespaces. Direct assignments into a namespace come up in several contexts throughout the language and are key to Lua's flexibility (using one concept to meet all needs). My only concern is that "def" and "class" statements also have the side effect of binding the __name__ attribute. We would have to come up with a lambda style placeholder for the attribute. -- Comment By: Michael Chermside (mcherm) Date: 2004-05-19 17:56 Message: Logged In: YES user_id=99874 I'm highly dubious of this. I see little advantage to doing the definition and storing the value in a single line, mostly because I rarely want to do such a thing. Your example may be convincing in Prothon or some relative, but in Python the sensible way to do it is a normal method. I'd suggest that if you want this idea to go anywhere that you try posting this to c.l.py and seeing if you can drum up interest and support there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-967161 ] pty.spawn() enhancements
Feature Requests item #967161, was opened at 2004-06-05 09:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: pty.spawn() enhancements Initial Comment: (Originally suggested by James Henstridge in bug #897935) There are also a few changes that would be nice to see in pty.spawn: 1) get the exit status of the child. Could be fixed by adding the following to the end of the function: pid, status = os.waitpid(pid, 0) return status 2) set master_fd to non-blocking mode, so that the output is printed to the screen at the speed it is produced by the child. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:08 Message: Logged In: YES user_id=33168 Originator: NO Wouldn't it be better to just return the pid. The caller can get the status if they want or do anything else with the pid. I'm guessing #2 is no longer requested? -- Comment By: James Henstridge (jhenstridge) Date: 2004-06-09 07:16 Message: Logged In: YES user_id=146903 Since filing the original bug report, I got reports that simply setting the fds to non-blocking caused problems under Solaris. Some details are available in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=139168 The _copy() function never raised an IOError or OSError, so it never exited. I'd imagine that EOF could be detected by getting back then empty string when reading from the fd when select() says it is ready for reading, but I haven't checked whether this works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1073198 ] Extension to optparse: options with optional arguments
Feature Requests item #1073198, was opened at 2004-11-25 06:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: pollastri (pollastri) Assigned to: Greg Ward (gward) Summary: Extension to optparse: options with optional arguments Initial Comment: When parsing command line options, I found very useful to have an option with a facultative value, able to do the following: 1-tell to me if the option was or was not seen on the command line, return the value None if the option was not seen; 2-if the option only was specified, return a default value. 3-if the option with a value was specified on the command line, return the specified value; A way to reach this goal can be the addition of a new value for the options actions in module optparse, it may be something like "store_with_default". -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:11 Message: Logged In: YES user_id=33168 Originator: NO Greg, since optik is maintained separately, it seems to make sense to close this and possibly create a new report in optik. http://sourceforge.net/projects/optik . Let me know if that's not how you want to handle bugs/feature requests. -- Comment By: Greg Ward (gward) Date: 2005-01-05 05:19 Message: Logged In: YES user_id=14422 I don't know what "facultative" means, but what you want is optional option arguments. Don't worry, I want that feature too, and have even started implementing it on a branch of the Optik source repository. See http://sourceforge.net/tracker/?func=detail&aid=1050431&group_id=38019&atid=421100 for a similar feature request. I'm leaving this open, since I haven't finished anything or merged it into the Python CVS. It could be a few months before there's any action here, and it certainly won't happen before Optik 1.6 / Python 2.5. Might require Optik 2.0, in which case I'm not certain when it'll get into Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1085861 ] subprocess.Popen feature request
Feature Requests item #1085861, was opened at 2004-12-15 07:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085861&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michele Simionato (michele_s) Assigned to: Peter Åstrand (astrand) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:16 Message: Logged In: YES user_id=33168 Originator: NO TerminateProcess is now in _subprocess.c. Can you work up a patch? It's not likely to get done otherwise. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 15:37 Message: Logged In: YES user_id=1188172 Moving to RFE tracker. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085861&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1087741 ] subclassable mmap
Feature Requests item #1087741, was opened at 2004-12-18 16:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: subclassable mmap Initial Comment: As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type. Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern". -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:17 Message: Logged In: YES user_id=33168 Originator: NO Josiah, care to work up a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1087741 ] subclassable mmap
Feature Requests item #1087741, was opened at 2004-12-18 16:16 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: subclassable mmap Initial Comment: As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type. Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern". -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-15 23:27 Message: Logged In: YES user_id=341410 Originator: YES I honestly wouldn't know where to start. I don't know what the differences are between the currently un-subclassable mmap, and something like int/list/dict. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:17 Message: Logged In: YES user_id=33168 Originator: NO Josiah, care to work up a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1222235 ] Bad optparse help wrapping with multiple paragraphs
Feature Requests item #135, was opened at 2005-06-16 15:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:27 Message: Logged In: YES user_id=33168 Originator: NO Closing, assuming this is tracked in http://sourceforge.net/projects/optik -- Comment By: Greg Ward (gward) Date: 2005-07-21 19:08 Message: Logged In: YES user_id=14422 This sounds an awful lot like Optik RFE #1055954 -- see https://sourceforge.net/tracker/?func=detail&atid=421100&aid=1055954&group_id=38019 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 07:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:39 Message: Logged In: YES user_id=33168 Originator: NO What's the status of this? Is it a bug report? -- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 03:10 Message: Logged In: YES user_id=21338 (1) (HKCU|HKLM)\Software\Classes\Python.File\open\command really is (HKCU|HKLM)\Software\Classes\Python.File\shell\open\command (2) with python 24 a new behaviour occurs: i try to execute the script on the commandline, but a dialog boy appears with: the file "[...correct complete path to the script...]" could not be found. Again, if i prepend python.exe, everything works as expected. windows 2000 professional. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 01:14 Message: Logged In: YES user_id=1188172 Do you mean that the registry setting is ok, but the parameters are not passed correctly? -- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 00:12 Message: Logged In: YES user_id=21338 I checked the registry. It's ok. It's windows 2000. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-16 13:29 Message: Logged In: YES user_id=21627 That (arguments not passed to the script) was a bug in some versions of the Windows installer. Please verify that the registry, at (HKCU|HKLM)\Software\Classes\Python.File\open\command has the value '[path]python.exe "%1" %*'. The %* part should arrange for arguments being passed. -- Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 02:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-14 10:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? -- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 14:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 13:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments
Feature Requests item #1527705, was opened at 2006-07-24 05:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments
Initial Comment:
Currently, the number of arguments an option
can/should have, needs be defined.
This is done using "nagrs".
parser.add_option("", "--my-option", nargs=3)
The problem is that at times it isn't predictable how
many arguments you'll be receiving.
I request the implementation of this feature in
optparse, where the following could be possible.
parser.add_option("", "--my-option", nargs=*)
Thanks,
Ritesh
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-15 23:44
Message:
Logged In: YES
user_id=33168
Originator: NO
Optik is maintained separately. Please file a feature request there:
http://sourceforge.net/projects/optik
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 06:31
Message:
Logged In: YES
user_id=849994
I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 06:21
Message:
Logged In: YES
user_id=382018
Can you please go through the following link and give your
comments ?
http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8
I feel its a valid feature request.
Ritesh
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 05:57
Message:
Logged In: YES
user_id=849994
I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.
I you still need this, you can implement a custom callback,
I think.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1578269 ] Add os.link() and os.symlink() support for Windows
Feature Requests item #1578269, was opened at 2006-10-16 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.link() and os.symlink() support for Windows Initial Comment: NTFS version 5.0 and up has all the needed APIs for creating hard links and symlinks (junctions), so it should be possible to add support for both hard links and symlinks to the posixmodule. Here are a few references: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html (see list of links at the end of the page) http://www.codeproject.com/w2k/junctionpoints.asp (junction points only, but includes analysis and source code) Note: NTFS 5.0 is supported in Win 2k, XP, 2003 and later. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:50 Message: Logged In: YES user_id=33168 Originator: NO Note a similar feature request which also contains a possible patch: 478407 -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 08:47 Message: Logged In: YES user_id=21627 We shouldn't expose junctions as symlinks. Instead, Vista will get real symlinks, so we should use that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1627266 ] optparse "store" action should not gobble up next option
Feature Requests item #1627266, was opened at 2007-01-03 10:46
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Greg Ward (gward)
Summary: optparse "store" action should not gobble up next option
Initial Comment:
Hi,
Check the following code:
--opttest.py--
from optparse import OptionParser
def process_options():
global options, args, parser
parser = OptionParser()
parser.add_option("--test", action="store_true")
parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
(options, args) = parser.parse_args()
return
process_options()
print "comment (%r)" % options.comment
-
$ ./opttest.py -m --test
comment ('--test')
I was expecting this to give an error as "--test" is an option. But it looks
like even C library's getopt() behaves similarly. It will be nice if optparse
can report error in this case.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-15 23:54
Message:
Logged In: YES
user_id=33168
Originator: NO
Closing since optik is maintained separately. Please file a feature
request at http://sourceforge.net/projects/optik
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 10:19
Message:
Logged In: YES
user_id=945502
Originator: NO
At the moment, you generally can't:
http://argparse.python-hosting.com/ticket/25
though the simple value "-" is valid. I do plan to address this in the
not-so-distant future (though no one yet has complained about it).
For optparse module, I think the OP's problem could likely be fixed by
editing _process_long_opt() and _process_short_opts() to do some checks
around the code:
elif nargs == 1:
value = rargs.pop(0)
else:
value = tuple(rargs[0:nargs])
del rargs[0:nargs]
You could make sure that the option arguments (the "value" objects in the
code above) were not already existing options with a check like:
all(not self._match_long_opt(arg) and
not self._short_opt.get(arg)
for arg in rargs[0:nargs])
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 08:16
Message:
Logged In: YES
user_id=849994
Originator: NO
So how does one give option arguments starting with - to argparse?
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 07:41
Message:
Logged In: YES
user_id=945502
Originator: NO
For what it's worth, argparse_ gives an error here:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--test', action='store_true')
>>> parser.add_argument('-m', dest='comment')
>>> parser.parse_args(['-m', '--test'])
usage: PROG [-h] [--test] [-m COMMENT]
PROG: error: argument -m: expected one argument
That's because argparse assumes that anything that looks like "--foo" is
an option (unless it's after the pseudo-argument "--" on the command
line).
.. _argparse: http://argparse.python-hosting.com/
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 09:58
Message:
Logged In: YES
user_id=984087
Originator: YES
It is possible to deduce "--test" as an option because it is in the list
of options given to optparse. But your point about what if the user really
wants "--test" as an option argument is valid. I guess this request can be
closed.
Thanks,
Raghu.
--
Comment By: David Goodger (goodger)
Date: 2007-01-05 08:28
Message:
Logged In: YES
user_id=7733
Originator: NO
I think what you're asking for is ambiguous at best. In your example, how
could optparse possibly decide that the "--test" is a second option, not an
option argument? What if you *do* want "--test" as an argument?
Assigning to Greg Ward. Recommend closing as invalid.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 07:19
Message:
Logged In: YES
user_id=984087
Originator: YES
I am attaching the code fragment as a file since the indentation got all
messed up in the original post.
File Added: opttest.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid
[ python-Bugs-1665333 ] Documentation missing for OptionGroup class in optparse
Bugs item #1665333, was opened at 2007-02-21 07:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: LunarYorn (lunar_yorn) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation missing for OptionGroup class in optparse Initial Comment: Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul. In detail documentation of the following classes and methods in optparse is missing: - OptionGroup - OptionParser.add_option_group - OptionParser.get_option_group These classes and methods also lack docstrings. I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:59 Message: Logged In: YES user_id=33168 Originator: NO LunarYorn, thanks for the report. bediviere, thanks to for filing a report with optik. Since the issue is tracked there, I'm closing this report. -- Comment By: LunarYorn (lunar_yorn) Date: 2007-02-26 09:45 Message: Logged In: YES user_id=1485244 Originator: YES Thanks for filing the patch there! I didn't know, that optparse is developt outside of Python... Anyway I think you're right not to comment the whole api. I did not intend that. I would be content with a little note in the docs quickly explains OptionGroups and how to create them. More shouldn't be told, since they are only useful for formatting help output. I just needed such a thing for my recent project and was short of overwriting the OptionParser and HelpFormatter classes. For that purpose I looked into the sources, where I found the OptionGroup capabilities. A little note would have shortened the development of the option parsing code quite a bit... ;) -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 09:39 Message: Logged In: YES user_id=945502 Originator: NO Looks like the optparse docs are also auto-generated from optik. Here's the first line of liboptparse.tex: % THIS FILE IS AUTO-GENERATED! DO NOT EDIT! So I guess this needs to be handled in the optparse bugs. -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 09:37 Message: Logged In: YES user_id=945502 Originator: NO The docstrings need to be modified in the Optik package (from which the stdlib optparse module is derived). I've filed you an appropriate patch there: http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097. I'll see what I can do about adding some documentation. My preference is only to document OptionParser.add_option_group -- I think making the OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc. APIs public was). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments
Feature Requests item #1527705, was opened at 2006-07-24 17:33
Message generated for change (Comment added) made by riteshsarraf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments
Initial Comment:
Currently, the number of arguments an option
can/should have, needs be defined.
This is done using "nagrs".
parser.add_option("", "--my-option", nargs=3)
The problem is that at times it isn't predictable how
many arguments you'll be receiving.
I request the implementation of this feature in
optparse, where the following could be possible.
parser.add_option("", "--my-option", nargs=*)
Thanks,
Ritesh
--
>Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 13:07
Message:
Logged In: YES
user_id=382018
Originator: YES
I don't think this is the correct way of resolving a bug. You mark it as
"Close" with a resolution "Invalid" when the bug was filed against "Python
Library", of which optparse is one. Python ships optparse as part of its
libraries.
If internally, it is a separate project, you could file one there and link
to it.
But why just plain close it ?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 12:14
Message:
Logged In: YES
user_id=33168
Originator: NO
Optik is maintained separately. Please file a feature request there:
http://sourceforge.net/projects/optik
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 19:01
Message:
Logged In: YES
user_id=849994
I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 18:51
Message:
Logged In: YES
user_id=382018
Can you please go through the following link and give your
comments ?
http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8
I feel its a valid feature request.
Ritesh
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 18:27
Message:
Logged In: YES
user_id=849994
I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.
I you still need this, you can implement a custom callback,
I think.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments
Feature Requests item #1527705, was opened at 2006-07-24 05:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments
Initial Comment:
Currently, the number of arguments an option
can/should have, needs be defined.
This is done using "nagrs".
parser.add_option("", "--my-option", nargs=3)
The problem is that at times it isn't predictable how
many arguments you'll be receiving.
I request the implementation of this feature in
optparse, where the following could be possible.
parser.add_option("", "--my-option", nargs=*)
Thanks,
Ritesh
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 00:47
Message:
Logged In: YES
user_id=33168
Originator: NO
I encourage you to file a feature request with optik if it's important to
you.
While it may not be the nicest way, it's the only way we can get anything
done. I pointed you to optik so you can file the feature request if it's
important to you. What has happened in the past is that this report would
be left open forever. That is worse.
If you think this is wrong, you can fix the problem by helping us resolve
all the issues in python. Otherwise, there's no hope of us managing it.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 00:37
Message:
Logged In: YES
user_id=382018
Originator: YES
I don't think this is the correct way of resolving a bug. You mark it as
"Close" with a resolution "Invalid" when the bug was filed against "Python
Library", of which optparse is one. Python ships optparse as part of its
libraries.
If internally, it is a separate project, you could file one there and link
to it.
But why just plain close it ?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-15 23:44
Message:
Logged In: YES
user_id=33168
Originator: NO
Optik is maintained separately. Please file a feature request there:
http://sourceforge.net/projects/optik
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 06:31
Message:
Logged In: YES
user_id=849994
I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 06:21
Message:
Logged In: YES
user_id=382018
Can you please go through the following link and give your
comments ?
http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8
I feel its a valid feature request.
Ritesh
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 05:57
Message:
Logged In: YES
user_id=849994
I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.
I you still need this, you can implement a custom callback,
I think.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681228 ] webbrowser priorities
Bugs item #1681228, was opened at 2007-03-15 08:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser priorities
Initial Comment:
Recently I've run into a Windows-specific bug in webbrowser (using close_fds
and preexec_fn in subprocess.Popen), and I noticed there are some strange
priorities in the default browsers.
For example:
* Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred
over the *user's* preferred browser on Windows?
* Why is the GNOME default browser preferred even if the user is currently
running KDE (but has GNOME installed)?
>From all the platforms, only on Mac OS X it really respects the user's
>preferrencies.
I'd like to propose this:
* On Windows, make "windows-default" the first in _try_order
* If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and
command "gnome-open" exists, use `gnome-open '%s'`.
* If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true")
and command "kfmclient" exists, use `kfmclient exec '%s'`.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-16 07:55
Message:
Logged In: YES
user_id=849994
Originator: NO
Committed in rev. 54406.
--
Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 11:47
Message:
Logged In: YES
user_id=587716
Originator: YES
Ok, here is the patch, including the fix for #1681248. The priorities on
all platforms with this patch are:
1. The BROWSER environment variable overrides everything
2. Next step is to check the preferred browsers for desktop environments
(Windows, Mac OS X, GNOME and KDE)
3. Fallback to available installed browsers (firefox, opera, konqueror,
epiphany, ...)
File Added: webbrowser-defaults.diff
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-15 08:50
Message:
Logged In: YES
user_id=849994
Originator: NO
I agree with your suggestion. Can you make a patch (and include a fix for
the other bug you filed)?
--
Comment By: Lukas Lalinsky (luks)
Date: 2007-03-15 08:06
Message:
Logged In: YES
user_id=587716
Originator: YES
Just a note, if you agree with this behavior, I'll be more than happy to
make a patch. Currently I'm using similar mechanism in my own code (because
Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can
easily turn it into a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681248 ] WindowsError in webbrowser.open
Bugs item #1681248, was opened at 2007-03-15 08:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 07:56 Message: Logged In: YES user_id=849994 Originator: NO Fixed with your patch from #1681228. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
