[ python-Bugs-1297986 ] hashable and mutable functions
Bugs item #1297986, was opened at 2005-09-21 17:55 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=1297986&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 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298120 ] shlex does not support unicode
Bugs item #1298120, was opened at 2005-09-21 13:18 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=1298120&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: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: shlex does not support unicode Initial Comment: Should make prominent notice that shlex does not support unicode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&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-1191964 ] asynchronous Subprocess
Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Peter Åstrand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 12:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? -- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. --
[ python-Feature Requests-1191964 ] asynchronous Subprocess
Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Peter Åstrand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 12:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? -- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=47333
[ python-Bugs-1297986 ] hashable and mutable functions
Bugs item #1297986, was opened at 2005-09-21 19:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&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 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&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-1297986 ] hashable and mutable functions
Feature Requests item #1297986, was opened at 2005-09-21 19:55 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&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 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-694812 ] setup.py imports pwd before it's built if HOME not set
Bugs item #694812, was opened at 2003-02-28 03:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&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: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py imports pwd before it's built if HOME not set Initial Comment: The function check_environ in Lib/distutils/util.py imports the 'pwd' module if the HOME environment variable is not set and os.name is 'posix' (as it is on at least Linux, Solaris, and Tru64 Unix). In the context of building Python, this happens before the pwd module has been built. The error is reproduced below. I can work around this easily. However, since the error message was somewhat oblique, it was confusing to diagnose. Perhaps there's some way to improve the diagnostic if the underlying problem cannot be fixed. case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 795, in ? main() File "./setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/core.py", line 110, in setup dist.parse_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 310, in parse_config_files filenames = self.find_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 272, in find_config_files check_environ() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/util.py", line 150, in check_environ import pwd ImportError: No module named pwd -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:41 Message: Logged In: YES user_id=1188172 Duplicate of #959576. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-17 19:15 Message: Logged In: YES user_id=1188172 Still present in current CVS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-924333 ] Build issues (lib path) on linux2-x86_64
Bugs item #924333, was opened at 2004-03-27 05:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&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: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Petrilli (petrilli) Assigned to: Nobody/Anonymous (nobody) Summary: Build issues (lib path) on linux2-x86_64 Initial Comment: The current CVS HEAD won't build "out of the box" on a Fedora x86_64 box, nor on any other Linux AMD64 platform. This is due to the fact that the libraries for many things are not in /usr/lib, but /usr/lib64, and the current 'autoconf' script, as well as the current setup.py do not look there. When added, they detect, build. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:46 Message: Logged In: YES user_id=1188172 The patch has been applied in 2004-11-13. -- Comment By: Bob Halley (rthalley) Date: 2004-11-04 23:09 Message: Logged In: YES user_id=671513 Just a note that this issue is still present in 2.4b2, and that the patch still applies. -- Comment By: Bob Halley (rthalley) Date: 2004-10-20 06:54 Message: Logged In: YES user_id=671513 My patch is #1050475 -- Comment By: Bob Halley (rthalley) Date: 2004-10-20 03:01 Message: Logged In: YES user_id=671513 Python 2.4b1 still doesn't build "out of the box" on a Fedora Core 2 x86_64 box. The patch that was submitted got munged when applied; '/usr/lib/lib64' was added instead of the correct value of '/usr/lib64'. I will submit a new patch once I track down 3 'unexpected skips' in the regression tests. /Bob P.S. I'm very happy with 2.4 so far; good work all! -- Comment By: Mihai Ibanescu (misa) Date: 2004-04-08 19:05 Message: Logged In: YES user_id=205865 have you tried to port the patches from python 2.3.3 to HEAD? From your bug I understand they seem to work - do you have them? -- Comment By: Christopher Petrilli (petrilli) Date: 2004-03-30 21:46 Message: Logged In: YES user_id=38410 See patch #926209 -- Comment By: Martin v. Löwis (loewis) Date: 2004-03-30 00:19 Message: Logged In: YES user_id=21627 Can you submit a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-872392 ] Finding X11 fails on SuSE Opteron
Bugs item #872392, was opened at 2004-01-07 14:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872392&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: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Joseph Winston (josephwinston)
Assigned to: Nobody/Anonymous (nobody)
Summary: Finding X11 fails on SuSE Opteron
Initial Comment:
The 64 bit versions of libraries are in a different location.
A possible patch would be:
opteron:~/src/Languages/Python/Python-2.3.3 cvs diff
setup.py
Index: setup.py
===
RCS
file: /ts2/jwinston/CACHE/CVSROOT/jwinston/src/Langu
ages/Python/Python-2.3.3/setup.py,v
retrieving revision 1.1
diff -r1.1 setup.py
986a987,989
> elif os.path.exists('/usr/X11R6/lib64'):
> include_dirs.append('/usr/X11R6/include')
> added_lib_dirs.append('/usr/X11R6/lib64')
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 08:47
Message:
Logged In: YES
user_id=1188172
Your proposed path has been applied in 2004-11-13.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872392&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
