[ python-Bugs-1217152 ] Info from man python not in docs
Bugs item #1217152, was opened at 2005-06-08 20:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217152&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: Feature Request >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Info from man python not in docs Initial Comment: Some of the information available from 'man python' is not available anywhere else in the docs. In particular there is no comprehensive, detailed listing of all the command line options and environment variables. Consequently this information is not available to users on platforms that don't support man, such as Windows. I suggest adding an appendix to the tutorial or language reference that includes the info from the man page. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 18:46 Message: Logged In: YES user_id=1188172 Closed as a duplicate of #469773. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217152&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail()
Bugs item #1217513, was opened at 2005-06-09 14:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&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: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Omission in docs for smtplib.SMTP.sendmail() Initial Comment: In Library Reference 11.12.1 SMTP Objects, the description of the to_addrs parameter to SMTP.sendmail() is, "a list of RFC 822 to-address strings". In fact sendmail() also allows a single string to be passed as to_addrs. The comment in smtplib.py says, "to_addrs: A list of addresses to send this mail to. A barestring will be treated as a list with 1 address." I suggest the Library Reference be changed to say, "a list of RFC 822 to-address strings or a single to-address string" -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:25 Message: Logged In: YES user_id=1188172 Fixed by accepting patch #1227442. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225705 ] os.environ documentation should mention unsetenv
Bugs item #1225705, was opened at 2005-06-22 20:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Wellington (bwelling) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.environ documentation should mention unsetenv Initial Comment: The (current) documentation for os.environ says: --- If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. --- Some platforms (Solaris 8 and 9, at least) have putenv() but not unsetenv(), which means that setting environment variables by assigning values in os.environ works, but unsetting them by deleting from os.environ doesn't. This is confusing, and should at least be documented (if for no other reason than no one else should waste several hours figuring this out). This was tested with Python 2.4.1 and earlier versions. I'd suggest documenting os.unsetenv() in 6.1.1 (Process Parameters) of the manual, and modifying the above text to say something like: --- If the platform supports the putenv() and unsetenv() functions, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when an entry in the mapping is added or changed, and unsetenv() will be called automatically when an entry is deleted. --- -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:47 Message: Logged In: YES user_id=1188172 Fixed as Doc/lib/libos.tex r1.158, r1.146.2.4. Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202475 ] httplib docs mentioning HTTPConnection.getreply
Bugs item #1202475, was opened at 2005-05-15 22:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: httplib docs mentioning HTTPConnection.getreply Initial Comment: ... instead of getresponse in the description of send(). Also, a general note or explanation like that could be given before the description of send(): """ You can send requests in two ways: either using the request() method as described above, which combines all request parameters, or using a sequence of putrequest(), zero or more times addheader(), endheaders() and then send(). """ It is sort of confusing in its current state. Oh yes, and while you're at it ;), you could add a note that the response object must be read completely before a new request can be sent. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 21:17 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libhttplib.tex r1.39, r1.38.2.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227480 ] Two requests to one file are not done in parallel
Bugs item #1227480, was opened at 2005-06-25 21:24 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=1227480&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: Open Resolution: None Priority: 5 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190563 ] os.waitpid docs don't specify return value for WNOHANG
Bugs item #1190563, was opened at 2005-04-26 22:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: jls (apjenkins) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.waitpid docs don't specify return value for WNOHANG Initial Comment: The library documentation for os.waitpid() does not specify what the return value should be if the os.WNOHANG flag is given, and the process still hasn't exited. p, v = os.waitpid(pid, os.WNOHANG) Through trial and error I discovered that in this case, os.waitpid returns the tuple (0, 0) if pid is still running. This should be in the documentation for os.waitpid(). -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 21:55 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/lib/libos.tex r1.160, r1.146.2.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-801992 ] cgi.CGIHTTPRequestHandler remembers QUERY_STRING
Bugs item #801992, was opened at 2003-09-07 15:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801992&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Ivo Danihelka (fidlej) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.CGIHTTPRequestHandler remembers QUERY_STRING Initial Comment: Python 2.3+, Debian SID: cgi.CGIHTTPRequestHandler remembers QUERY_STRING from last query. If query is '', then condition "if query:" fails and env['QUERY_STRING'] is remembered from last query. Solution: --- /usr/lib/python2.3/CGIHTTPServer.py 2003-09-07 15:33:41.0 +0200 +++ CGIHTTPServer.py2003-09-07 15:36:27.0 +0200 @@ -147,8 +147,7 @@ env['PATH_INFO'] = uqrest env['PATH_TRANSLATED'] = self.translate_path(uqrest) env['SCRIPT_NAME'] = scriptname -if query: -env['QUERY_STRING'] = query +env['QUERY_STRING'] = query host = self.address_string() if host != self.client_address[0]: env['REMOTE_HOST'] = host -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:02 Message: Logged In: YES user_id=1188172 This is a duplicate of #777848, closing as such. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 05:40 Message: Logged In: YES user_id=80475 See the patch at www.python.org/sf/796772 -- Comment By: Martin v. Löwis (loewis) Date: 2003-09-07 21:48 Message: Logged In: YES user_id=21627 I believe the bug lies elsewhere: If we have fork, we shouldn't set the environment variables in the parent process, but only in the child process. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175022 ] property example code error
Bugs item #1175022, was opened at 2005-04-01 22:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&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: Fixed Priority: 5 Submitted By: John Ridley (ojokimu) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: property example code error Initial Comment: The example code for 'property' in lib/built-in-funcs.html may produce an error if run "as is": Python 2.4.1 (#1, Mar 31 2005, 21:33:58) [GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 >>> class C(object): ... def getx(self): return self.__x ... def setx(self, value): self.__x = value ... def delx(self): del self.__x ... x = property(getx, setx, delx, "I'm the 'x' property.") ... >>> c=C() >>> c.x Traceback (most recent call last): File "", line 1, in ? File "", line 2, in getx AttributeError: 'C' object has no attribute '_C__x' The same goes for 'del c.x' (although not 'c.x = 0', of course). A more "typical" way of defining managed attributes would be to include an 'init' as follows: class C(object): def __init__(self): self.__x = None def getx(self): return self.__x def setx(self, value): self.__x = value def delx(self): del self.__x x = property(getx, setx, delx, "I'm the 'x' property.") -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:08 Message: Logged In: YES user_id=1188172 Thanks for the report; fixed as Doc/lib/libfuncs.tex r1.184, r1.175.2.4. -- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:33 Message: Logged In: YES user_id=81797 I agree, adding the __init__ to set a value would be useful. +1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-857566 ] tempfile.mktemp() omits pid from name
Bugs item #857566, was opened at 2003-12-10 14:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gottfried Ganßauge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:21 Message: Logged In: YES user_id=1188172 Closing this as Won't Fix, as mktemp is really deprecated now and shouldn't be used. -- Comment By: Gottfried Ganßauge (ganssauge) Date: 2003-12-11 11:29 Message: Logged In: YES user_id=792746 It is already hard to keep a system working in a changing world, so I see no necessity to needlessly introduce incompatibilities. Your comments are apreciated nonetheless. -- Comment By: Thomas Heller (theller) Date: 2003-12-10 16:56 Message: Logged In: YES user_id=11105 Well, you could close the file (or even remove it, depending on your requirements), and pass the filename to the spawned program. Or, if you insist on using mktemp(), pass a prefix argument yourself? But I'm not really sure if this is what you need, so this is my last comment. -- Comment By: Gottfried Ganßauge (ganssauge) Date: 2003-12-10 15:17 Message: Logged In: YES user_id=792746 This is no option. In our system we need to spawn another program which doesn't accept file handles but wants to have a filename instead. -- Comment By: Thomas Heller (theller) Date: 2003-12-10 15:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186072 ] tempnam doc doesn't include link to tmpfile
Bugs item #1186072, was opened at 2005-04-19 17:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: tempnam doc doesn't include link to tmpfile Initial Comment: Both tmpnam and tempnam include references to tmpfile (as a preferred way of using temporary files). However, they don't include a link to the page where tmpfile is documented, and it is documented in a different (non-obvious) section of the ``os`` page. A link to the section containing tmpfile would be helpful. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:44 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/lib/libos.tex r1.161, r1.146.2.7. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166582 ] IterableUserDict not in docs
Bugs item #1166582, was opened at 2005-03-19 19:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&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: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: IterableUserDict not in docs Initial Comment: There is no mention of UserDict.IterableUserDict in the docs (3.7 UserDict). Here is a suggested rewrite: class UserDict( [initialdata]) Class that simulates a dictionary. The instance's contents are kept in a regular dictionary, which is accessible via the data attribute of UserDict instances. If initialdata is provided, data is initialized with its contents; note that a reference to initialdata will not be kept, allowing it be used for other purposes. Note: For backward compatibility, instances of UserDict are not iterable. class IterableUserDict( [initialdata]) Subclass of UserDict that supports direct iteration (e.g. "for key in myDict"). In addition to supporting the methods and operations of mappings (see section 2.3.8), UserDict and IterableUserDict instances provide the following attribute: -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 23:04 Message: Logged In: YES user_id=1188172 Thanks for the report; fixed as Doc/lib/libuserdict.tex r1.27, r1.24.4.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223238 ] race in os.makedirs()
Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&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: Mattias Engdegård (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? -- >Comment By: Mattias Engdegård (yorick) Date: 2005-06-25 23:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 19:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians
Bugs item #1212195, was opened at 2005-05-31 20:56
Message generated for change (Comment added) made by pterk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: M.-A. Lemburg (lemburg)
Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians
Initial Comment:
lower() {maybe others} should mention that if used with
string object [not unicode object] it's likely the that
encoding will change unde some locales [eg pl_PL makes
it from utf8 to latin2]!!
or this hsould be put in the beginning of the doc in
str as a general WARNING/NOTE:
--
Comment By: Peter van Kampen (pterk)
Date: 2005-06-26 00:05
Message:
Logged In: YES
user_id=174455
I tried to come up with a doc-patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-06-02 13:48
Message:
Logged In: YES
user_id=38388
A doc-patch would be nice.
I don't like the general situation either. Unicode doesn't
behave like this and I don't think string.lower() and
.upper() should either, but there are users out there who
think differently, so we might want to add a parameter which
then allows modifying the type of mapping:
string.lower(map='ascii')
string.upper(map='latin-1')
etc.
Just an idea.
PS: I'll be offline for two weeks now, so don't expect any
more comments before then.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:43
Message:
Logged In: YES
user_id=80475
Mark, do you have any thoughts on this one?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226969 ] segfault in os module
Bugs item #1226969, was opened at 2005-06-24 13:05
Message generated for change (Comment added) made by jacobo_es
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: jacobo_es (jacobo_es)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in os module
Initial Comment:
python crashes when a bad parameters are passed to execl function
of the os module:
>>> import os
>>> os.execl("/bin/bash")
Segmentation Fault (core dumped)
No matter the platform (on ppc raises a bus error) and the version of
C compiler, always crashes, python versions used are 2.4.1 and
2.4c1.
Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise
and debian woody 3.0 (x86).
However, on 2.2.3 version not crashes.
--
>Comment By: jacobo_es (jacobo_es)
Date: 2005-06-25 23:15
Message:
Logged In: YES
user_id=1302185
I tried this directly on the C layer, too, and not raises a
signal 11, segmentation fault, just the function execl()
isn't executed and the program flow goes, not raises a
sigsegv, and that's not happen in
the same way in python, that abort the python interpreter
and dump a core file.
-( tmp )- ./p
execl not executed.
-( tmp )- cat p.c
#include
int main() {
execl("/bin/bash");
fprintf(stderr, "execl not executed.\n");
exit(-1);
}
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-24 14:53
Message:
Logged In: YES
user_id=1188172
This behaviour was introduced with the fixing of bug
#952953, where someone complained that he couldn't call
execl with only one argument.
I tried this directly on the C layer on Linux, and it
segfaults too.
Are there OSes where this is legal?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226969 ] segfault in os module
Bugs item #1226969, was opened at 2005-06-24 15:05
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: jacobo_es (jacobo_es)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in os module
Initial Comment:
python crashes when a bad parameters are passed to execl function
of the os module:
>>> import os
>>> os.execl("/bin/bash")
Segmentation Fault (core dumped)
No matter the platform (on ppc raises a bus error) and the version of
C compiler, always crashes, python versions used are 2.4.1 and
2.4c1.
Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise
and debian woody 3.0 (x86).
However, on 2.2.3 version not crashes.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-26 08:19
Message:
Logged In: YES
user_id=1188172
First, Python does not call the C execl functions, but
translates them to execv calls.
For execv called like Python does:
~/tmp> ./execv
zsh: 15395 segmentation fault ./execv
~/tmp> cat execv.c
#include
#include
int main() {
const char* args[1];
args[0] = NULL;
execv("/bin/bash", args);
return errno;
}
For execl on the C layer, my Linux doesn't want that:
~/tmp> gcc -o execl execl.c
execl.c: In function `main':
execl.c:4: error: too few arguments to function 'execl'
~/tmp> cat execv.c
#include
int main() {
execl("/bin/bash");
return 0;
}
--
Comment By: jacobo_es (jacobo_es)
Date: 2005-06-26 01:15
Message:
Logged In: YES
user_id=1302185
I tried this directly on the C layer, too, and not raises a
signal 11, segmentation fault, just the function execl()
isn't executed and the program flow goes, not raises a
sigsegv, and that's not happen in
the same way in python, that abort the python interpreter
and dump a core file.
-( tmp )- ./p
execl not executed.
-( tmp )- cat p.c
#include
int main() {
execl("/bin/bash");
fprintf(stderr, "execl not executed.\n");
exit(-1);
}
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-24 16:53
Message:
Logged In: YES
user_id=1188172
This behaviour was introduced with the fixing of bug
#952953, where someone complained that he couldn't call
execl with only one argument.
I tried this directly on the C layer on Linux, and it
segfaults too.
Are there OSes where this is legal?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1069410 ] import on Windows: please call SetErrorMode first
Bugs item #1069410, was opened at 2004-11-19 15:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069410&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 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: import on Windows: please call SetErrorMode first Initial Comment: Hi, We have a problem with "import" on Windows XP. If we attempt to import a missing Python module, an exception is raised. That's OK. If we attempt to import an existing Python module depending on a missing DLL, then the Windows runtime will pop up an error message, before the exception is raised by Python. That's not OK. I would expect an exception should be thrown, but I believe the Windows error message should not be displayed. I guess the error message originates in the win32 LoadLibrary function: http://msdn.microsoft.com/library/en-us/dllproc/base/loadlibrary.asp According to this documentation: To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function. SetErrorMode is documented here: http://msdn.microsoft.com/library/en-us/debug/base/seterrormode.asp I believe Python should handle the DLL error instead of letting the system handle it. The default behavior is not appropriate for most Python programs. The Python way of dealing with errors is raising an exception, not passing errors to the system and let it pop up platform specific error messages. We're running Python 2.3.4 on Windows XP. Background: The problems occurs when importing the PyMat library. This Matlab wrapper depends on a Matlab DLL. We don't know before hand whether Matlab is present or not on the system. We expect import pymat to raise an exception if Matlab is not installed. We don't want the user to have to click in the annoying control popped up by the Windows runtime. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 08:21 Message: Logged In: YES user_id=1188172 That seems to be a correct wish. Is there any problem with SetErrorMode? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069410&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
