[ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2
Bugs item #711830, was opened at 2003-03-29 10:54
Message generated for change (Comment added) made by misa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: SEEK_{SET,CUR,END} missing in 2.2.2
Initial Comment:
Python 1.5.2 used to define SEEK_{SET,CUR,END} both in
FCNTL.py and in posixfile.py
Python 2.2.2 obsoletes both of them (and the symbols
are no longer in FCNTL anyway).
A quick grep on the 2.2.2 tree shows me posixfile is
the only place that still defines the SEEK_* constants.
It seems to me it's wrong to drop the constants
(because a deprecated module will eventually be dropped).
--
>Comment By: Mihai Ibanescu (misa)
Date: 2005-01-15 22:39
Message:
Logged In: YES
user_id=205865
Did a quick grep in python 2.3.4 - still only defined in
posixfile which is deprecated.
I didn't notice Martin's question - yes, the os module seems
to be the best place to put them.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 12:43
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 12:36
Message:
Logged In: YES
user_id=21627
Would you agree that these constants are best located in the
os module?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&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-774546 ] popen does not like filenames with spaces
Feature Requests item #774546, was opened at 2003-07-20 07:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 >Category: Python Library >Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-15 20:00 Message: Logged In: YES user_id=80475 The proposed change would not be eligible for backporting as it is a new feature. And since Py2.4 and later already have a preferred solution (in the form of the subprocess modules), will close this feature request as being out-of-date (or least, no longer necessary). Feel free to re-open if the sub-process module does not fully meet your needs. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Peter Åstrand (astrand) Date: 2003-11-01 11:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). -- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 05:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this
[ python-Bugs-487471 ] urllib2 proxyhandle won't work.
Bugs item #487471, was opened at 2001-11-30 09:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 19:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 20:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: John J Lee (jjlee) Date: 2003-10-30 16:02 Message: Logged In: YES user_id=261020 That last comment was from me (cookie problems, ironically). -- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-30 15:57 Message: Logged In: NO This should be closed. I don't recall which minor version of 2.2 this was introduced at, but there's no need to replace build_opener any more. The most you have to do is to explicitly pass a handler or two to build_opener with appropriately set handler_order attributes. Or you can subclass the handlers. -- Comment By: Micah Stetson (micahs) Date: 2003-05-07 20:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 18:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? -- Comment By: Ha Shao (hashao) Date: 2001-11-30 10:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-629345 ] build does not respect --prefix
Bugs item #629345, was opened at 2002-10-27 04:10 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629345&group_id=5470 Category: Build Group: Python 2.1.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Philip Brown (theferret) Assigned to: Nobody/Anonymous (nobody) Summary: build does not respect --prefix Initial Comment: I want to compile python with a different prefix. I use configure --prefix=/my/stuf but some things are still hardcoded to look in /usr/local for example, setup.py This stops extensions like bsddb from being built, even though the include files are present in $prefix/include Even if I go the extra mile to do export CPPFLAGS=/my/stuff, and the configure script successfully detects I have db.h... it STILL does not compile bsddb until I make a link from /my/stuff/include/db.h to /usr/local/include/db.h Please fix all those locations that have hardcodes for /usr/local -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:56 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Philip Brown (theferret) Date: 2002-10-27 22:53 Message: Logged In: YES user_id=7120 Whats wrong with editing Modules/Setup? How about, "whats wrong with automating the build process in a standard fashion, instead of forcing builders to jump through unneccessary hoops?" Thats what autoconf, etc. is for, after all. LD_LIBRARY_PATH is a standard environment setting, across virtually all modern UNIXen. Most other programs tend to compile a fake program, or some such, to check for existance of a library (like, $CC -o test test.c -ldb, and see if it works) That is a fairly standard autoconf method of checking for libraries, and has the nice side effect of taking advantage of whatever dynamic loading paths the OS happens to use. If you are going to stick with your own methods of probing, you should make those methods as effective as the more common ones. The way to DO that, is to respect LD_LIBRARY_PATH, if it is set. -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 16:36 Message: Logged In: YES user_id=21627 What's wrong with editing Modules/Setup? -- Comment By: Philip Brown (theferret) Date: 2002-10-27 16:27 Message: Logged In: YES user_id=7120 When trying to detect whether a library is available, you should at least respect LD_LIBRARY_PATH if it is set, rather than hardcoding stuff like /usr/local reguardless of $prefix -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 15:54 Message: Logged In: YES user_id=21627 #--prefix specifies what to put in strings instead of /usr/local. No. See ./configure --help: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] -- Comment By: Philip Brown (theferret) Date: 2002-10-27 15:51 Message: Logged In: YES user_id=7120 --prefix specifies what to put in strings instead of /usr/local. It is common practice to install ALL free software under a /usr/local equivalent. eg: /opt/freeware Clearly, /opt/freeware is for ALL freeware, not just for "this package". It is the most consistent to scan whatever was specified for $prefix, rather than to hardcode for /usr/local Additionally, there could conceptually be other stuff in /usr/local that might conflict (which actually happend to me) The whole point of --prefix is to specify a location to use INSTEAD OF /usr/local. If the user/admin explicitly says "do not use /usr/local, use this path instead", you should NOT use /usr/local !! (unless it is in $PATH, $CPPFLAGS, or $LD_LIBRARY_PATH. Which it is not, in my case) -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 09:20 Message: Logged In: YES user_id=21627 This is by design. --prefix specifies the places to install *this* package (i.e. python), not the places to look for other packages. If you want to f
[ python-Bugs-771429 ] Signals discard one level of exception handling
Bugs item #771429, was opened at 2003-07-15 03:57 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Signals discard one level of exception handling Initial Comment: Signals handled by Python (especially KeyboardInterrupt) may discard one level of exception handling. Consider the following code fragment: try: # outer exception handling level try: # inner exception handling level blocking_external_extension_function() except: print "inner exception handling" except: print "outer exception handling" Assume that "blocking_external_extension_function" is an external function (implemented in "C") that blocks until interrupted by a signal (EINTR) and then returns with an exception but without handling the signal. In our concrete case, "blocking_external_extension_function" has been "psycopg.connect" (the database "connect" from the Python-PostgreSQL bridge "psycopg"). In this case, when you interrupt the execution, while "blocking_external_extension_function" waits, the "KeyboardInterrupt" is not caught in the inner "try: ...except: ..." but only in the outer "try: ... except: ..." The following happens in detail in Python's main interpreter loop: * "blocking_external_extension_function" returns with an exception. * Python sets the next instruction to the exception handler of the inner exception handling * Python begins a new run through its main loop. At the start, it detects the "KeyboardInterrupt" signal. It now thinks, the "KeyboardInterrupt" were caused inside the inner exception handler and pops this exception handling level without executing it. The interpreter has lost one level of exception handling. The behaviour would probably better fit with expectations, when the interpreter would check for signals at the end of its main loop and before it sets its instruction pointer to the exception handler. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:26 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:33 Message: Logged In: YES user_id=6656 Oh, after some judicious view-sourcing and query-replacing, I get the problem. However, I can't reproduce it (see attached script). So we're back to needing a failing example and more platform details. -- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:16 Message: Logged In: YES user_id=6656 In addition, attaching any code samples rather than including them would seem a good idea. I can't make head or tail of the code in the summary. -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:45 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-771429 ] Signals discard one level of exception handling
Bugs item #771429, was opened at 2003-07-15 03:57 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Signals discard one level of exception handling Initial Comment: Signals handled by Python (especially KeyboardInterrupt) may discard one level of exception handling. Consider the following code fragment: try: # outer exception handling level try: # inner exception handling level blocking_external_extension_function() except: print "inner exception handling" except: print "outer exception handling" Assume that "blocking_external_extension_function" is an external function (implemented in "C") that blocks until interrupted by a signal (EINTR) and then returns with an exception but without handling the signal. In our concrete case, "blocking_external_extension_function" has been "psycopg.connect" (the database "connect" from the Python-PostgreSQL bridge "psycopg"). In this case, when you interrupt the execution, while "blocking_external_extension_function" waits, the "KeyboardInterrupt" is not caught in the inner "try: ...except: ..." but only in the outer "try: ... except: ..." The following happens in detail in Python's main interpreter loop: * "blocking_external_extension_function" returns with an exception. * Python sets the next instruction to the exception handler of the inner exception handling * Python begins a new run through its main loop. At the start, it detects the "KeyboardInterrupt" signal. It now thinks, the "KeyboardInterrupt" were caused inside the inner exception handler and pops this exception handling level without executing it. The interpreter has lost one level of exception handling. The behaviour would probably better fit with expectations, when the interpreter would check for signals at the end of its main loop and before it sets its instruction pointer to the exception handler. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:26 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:33 Message: Logged In: YES user_id=6656 Oh, after some judicious view-sourcing and query-replacing, I get the problem. However, I can't reproduce it (see attached script). So we're back to needing a failing example and more platform details. -- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:16 Message: Logged In: YES user_id=6656 In addition, attaching any code samples rather than including them would seem a good idea. I can't make head or tail of the code in the summary. -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:45 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100673 ] Python Interpreter shell is crashed
Bugs item #1100673, was opened at 2005-01-12 02:49
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470
Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: abhishek (abhishekkabra)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python Interpreter shell is crashed
Initial Comment:
I faced this problem about 50 % of time when I hit
follwing commands on python shell.
But I think Crash of interpreter is not a expected
behaviour. It should throw some error even if I am
wrong/ hitting wrong commands
1. on shell of linux start python
2 On python shell hit _doc__
( underscore doc underscore
underscore )
So Python shell is crashed with following crash dump
darwin{akabra}6: python
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> _doc__Segmentation fault (core dumped)
darwin{akabra}7:
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:55
Message:
Logged In: YES
user_id=752496
Works ok to me.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:55
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Puneet (puneet_mnitian)
Date: 2005-01-13 02:46
Message:
Logged In: YES
user_id=1196195
Not reproducible
--
Comment By: Michael Hudson (mwh)
Date: 2005-01-12 16:16
Message:
Logged In: YES
user_id=6656
That's certainly not expected behaviour, however I think
it's unlikely to be a python bug -- I've not heard of this
behaviour before.
Is python using readline?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-768649 ] popen4 doesn't close filedescriptors when in Threads
Bugs item #768649, was opened at 2003-07-09 15:36
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: martin doudoroff (mdoudoroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen4 doesn't close filedescriptors when in Threads
Initial Comment:
Running the following code under Linux will result in a
crash on the 508th thread started. The error is
OSError: [Errno 24] Too many open files
The nature of the bug seems to be that Python isn't
closing filedescriptors cleanly when running a thread.
---
import os
from threading import Thread
class Crash(Thread):
def run(self):
a = os.popen4('ls')
b = a[1].read()
# uncommenting these lines fixes the problem
# but this isn't really documented as far as
# we can tell...
# a[0].close()
# a[1].close()
for i in range(1000):
t = Crash()
t.start()
while t.isAlive():
pass
print i
---
The same code without threads (Crash as a plain class)
doesn't crash, so the descriptor must be getting taken
care of when the run() method is exited.
import os
class Crash:
def run(self):
a = os.popen4('ls')
b = a[1].read()
for i in range(1000):
t = Crash()
t.run()
print i
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:48
Message:
Logged In: YES
user_id=752496
Works fine to me:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
with glibc-2.3.4-2
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:48
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Andrew Gaul (gaul)
Date: 2003-10-01 15:51
Message:
Logged In: YES
user_id=139865
Duplicated with Python 2.3 on Red Hat 7.3 using
glibc-2.2.5-43. Popen3.{poll,wait} are written under the
incorrect assumption that waitpid can monitor any process in
the same process group, when it only works for immediate
children. _active.remove is never called, so Popen3 objects
are never destroyed and the associated file descriptors are
not returned to the operating system.
A general solution for Popen[34] is not obvious to me. With
patch #816059, popen2.popen[234] plugs the _active leak,
which in turn returns the file descriptors to the operating
system when the file objects that popen2.popen[234] return
go out of scope.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-10 00:20
Message:
Logged In: YES
user_id=33168
I can't duplicate this on Redhat 9. What OS, what version
of glibc and what kernel are you using? Does it always
crash on the 508th iteration?
I tested with both 2.2.3 and 2.3b2 from CVS without
problems. I even used ulimit to set my open files to 10.
Can you try the patch in bug #761888 to see if that helps?
http://pythong.org/sf/761888
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-701836 ] Thread running (os.system or popen#)
Bugs item #701836, was opened at 2003-03-11 18:46
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470
Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Fredrik Öhman (johanfo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread running (os.system or popen#)
Initial Comment:
Bottom line: Some programs may lock up when
spawned from a thread.
>>> import thread, os
>>> thread.start_new_thread(os.system,
("/usr/sbin/ntpdate ifi.uio.no",))
This starts a program "ntpdate" from a Python thread.
Usually this is no problem. Ntpdate, is a simple program
to adjust the clock of the system. However, when
ntpdate is started from a thread it locks up and newer
exits!! With my limited debugging knowledge, it sems
as it hangs in a "poll()" kernel call, however, this could
be misleading. (I used stacktrace -p )
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:34
Message:
Logged In: YES
user_id=752496
Works ok for me:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import thread, os
>>> thread.start_new_thread(os.system,("/usr/sbin/ntpdate
ifi.uio.no",))
-1210684496
>>>
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:34
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Johan Fredrik Öhman (johanfo)
Date: 2003-03-12 13:12
Message:
Logged In: YES
user_id=556425
I have verified this bug on both Redhat 8.0 and SuSE 8.1,
linux yes.
Signal is one possible path, filedescriptors another. I read
somwhere that there was some issues with pthreads forking
and filedescriptors. However, this is not my area (too low
level)
--
Comment By: Michael Hudson (mwh)
Date: 2003-03-12 09:40
Message:
Logged In: YES
user_id=6656
IIRC, threads other than the main thread get a signal mask
that blocks everything. That could be the problem, but I
don't know what to do about it...
What platform are you on? Linux?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-856706 ] popen3 under threads reports different stderr results
Bugs item #856706, was opened at 2003-12-09 04:08 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:59 Message: Logged In: YES user_id=752496 Duplicate of #853411 (the OP says so in the other bug). -- Comment By: Andrew Gaul (gaul) Date: 2003-12-25 16:42 Message: Logged In: YES user_id=139865 This appears to be a duplicate of #853411. The thread on python-dev with subject "Python threads end up blocking signals in subprocesses" discusses this. -- Comment By: Steven Howe (stevenhowe) Date: 2003-12-12 16:02 Message: Logged In: YES user_id=916892 Hello Gaul. Well I found a work around. Using threading.Thread, I init a routine that forks and execv's a script (execv has no method to accept redirects '> 2>') that runs the badblocks program and route output to files. Then I the a thread that uses open() to attach theto a progress reading routine and when complete for the badblock list (if any). This method created another problem. Popen3 does not return an end of file ( '' ) until the process has ended. With badblocks forked, there is no syncronization between my script and the badblocks output. So I can and do overrun the output, which then returns an EOF. Another workaround: I wrote a routine to make sure I never read to the end of file: readsize = os.stat(fname)[stat.ST_SIZE] - fptr.tell() - BIAS All this so I can using threading. No doubt you're asking why use threading? I'm making a pygtk app similar to 'gfloppy' that can handle USB floppies. I need to make a progress meter. Using threading allows a GTK call back to examine the current status of badblocks. But a fix would be preferable. Thanks, Steven Howe -- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 07:03 Message: Logged In: YES user_id=139865 Confirmed with Python CVS and Fedora on x86. e2fsprogs/misc/badblocks:alarm_intr sets a SIGALRM handler and calls alarm(1), but it is not getting fired. I will look into this further. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-794291 ] double symlinking corrupts sys.path[0]
Bugs item #794291, was opened at 2003-08-24 16:52 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794291&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Csaba Henk (dzsekijo) Assigned to: Nobody/Anonymous (nobody) Summary: double symlinking corrupts sys.path[0] Initial Comment: The bug can be demonstrated as follows (In some Bourne-tpye Unix shell) type $ mkdir d1 d2 && echo 'import sys print sys.path[0]' > d1/script.py && ln -s ../d1/script.py d2 && ln -s d2/script.py . Now see what the three invocations of script.py give us: $ python d1/script.py d1 $ python d2/script.py d2/../d1 $ python script.py d2 -- if script.py imported modules residing in d1, at the third invocation the modules would not be found. -- Comment By: Steven Taschuk (staschuk) Date: 2003-08-28 02:39 Message: Logged In: YES user_id=666873 I confirm this behaviour on Linux 2.4.17 (glibc 2.2.4) with Python 2.2.2 and 2.2.3; but not with Python 2.3. The relevant change seems to be revision 2.114 of Python/sysmodule.c, which implemented SF patch #664376 (q.v.). The change appeared in 2.3a2. Should this be backported to the 2.2 line? -- Comment By: Csaba Henk (dzsekijo) Date: 2003-08-27 12:29 Message: Logged In: YES user_id=754125 I hope the startup message is exact enough: Python 2.2.2 (#1, May 19 2003, 03:15:27) [GCC 3.1] on linux2 -- Comment By: Christos Georgiou (tzot) Date: 2003-08-27 08:46 Message: Logged In: YES user_id=539787 My mistake, I missed the Pyhton 2.2.2 part, sorry. -- Comment By: Christos Georgiou (tzot) Date: 2003-08-27 08:45 Message: Logged In: YES user_id=539787 Which version of Python? With a recent 2.4 (built on Aug 21, sources of Aug 20), on a 2.4.19 SMP kernel: $ mkdir d1 d2 $ echo 'import sys > print sys.path[0]' >d1/script.py $ ln -s ../d1/script.py d2 $ ln -s d2/script.py . $ python d1/script.py /tmp/tzot/d1 $ python d2/script.py /tmp/tzot/d1 $ python script.py /tmp/tzot/d1 Please specify OS too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794291&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-774546 ] popen does not like filenames with spaces
Bugs item #774546, was opened at 2003-07-20 09:29 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Peter Åstrand (astrand) Date: 2003-11-01 13:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). -- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 07:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this myself. -- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 09:17 Message: Logged In: YES user_id=139865 Yes, it works. This is also the same behaviour as os.system. os.popen2 allows one to pass either a quoted string or a sequence of strings (pfremy's suggested behaviour). It would be nice to have consistent functionality, and using a sequence would be easier when providing a list of files to be operated on. I am willing to provide a patch if this is th
[ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection
Bugs item #763190, was opened at 2003-06-30 10:34 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Maria Martinsdotter (dehex) Assigned to: Nobody/Anonymous (nobody) Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection Initial Comment: Environment: Python 2.2.2 win32all-150 Win2000 Server Dell server 2 CPU Pentuim 4 emulating 4 CPU's. Application: Service with many (50-150) threads. Problem: The entire service exits unexepectedly with only a brief reference made by Dr.Watson indicating the Windows equivalent of SIGSEGV in RtlEnterCriticalSection. Side info: Known to have happened once, we believe it may have happened three times in total but the two extra did not leave even a Dr.Watson trace. The known occurrence can be connected to our use of a timer where the action routine restarts the timer. The two extra's occurred at a point in time that connect the problem event to the timer expiration. The application have been used for five months, runnning around the clock. The customer installation currently use five instances of the base software, only configuration differs. It is arbitrary which instance fail. We have no means to trigger the problem. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:40 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Maria Martinsdotter (dehex) Date: 2003-06-30 19:00 Message: Logged In: YES user_id=807857 Apart from what we initially reported, no extensions are used. It is all pure Python and the only part of win32all used is the support for running it as a service. We are aware of the enhancements provided by 2.3 beta but let it suffice to say that the customer is picky. We have not been able to reproduce the problem in our test environment, however the hardware is not as sophisticated. -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 12:13 Message: Logged In: YES user_id=33168 Are there any other C/Extension modules used which are not from the standard python distribution? Can you make a self contained test case? I encourage you to test with 2.3 beta 2. There were some thread changes which could affect this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread
Bugs item #756940, was opened at 2003-06-18 20:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Jones (morngnstar) Assigned to: Nobody/Anonymous (nobody) Summary: can't CNTRL-C when running os.system in a thread Initial Comment: This is related to Bug #756924. When os.system is called in a thread, Control-C is ignored. Steps to reproduce: 1. Download the attached file fibonacci.py. 2. Run python2.2 fibonacci.py. 3. Hit CNTRL-C. fibonacci.py starts a thread that executes fibonacci.py again (but with a flag to prevent this from recursing infinitely). Then it computes and prints the Fibonacci sequence, the slow way. The process executed in the thread redirects this to a file to avoid conflict over stdout. All this is just to give the program something to do while you hit CNTRL-C. Expected, and Python 2.1 behavior: You get a KeyboardInterrupt exception, a stack trace, and the program exits. Actual Python 2.2 behavior: No response. You have to run kill on the process. Maybe this is not a bug, but rather a limitation of Linux, since I understand SIGINT is blocked during the C function 'system'. However, CNTRL-C worked in Python 2.1, and that was nicer. Removing the lines of code described in Bug #756924 also fix this bug. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 The other bug have a very long discussion about this, and talks about patches to be applied to Py2.4, and the last patch is actually accepted. Maybe this is already fixed, please give it a try. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Greg Jones (morngnstar) Date: 2003-06-18 23:58 Message: Logged In: YES user_id=554883 OS is Linux. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Bugs item #756104, was opened at 2003-06-17 15:25 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 >Category: Documentation >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:07 Message: Logged In: YES user_id=752496 This is a documentation bug; something the user should be "warned" about. This caught me once, and two different persons asked about this in #python, so maybe we should put something like the following in the recv() docs. """ For best match with hardware and network realities, the value of "buffer" should be a relatively small power of 2, for example, 4096. """ If you think the wording is right, just assign the bug to me, I'll take care of it. -- Comment By: Tim Peters (tim_one) Date: 2004-09-13 11:11 Message: Logged In: YES user_id=31435 As Jeremy implied at the start, someone needs to demonstrate that "the bug" is actually in Python, not in your platform's implementation of sockets. If a C program displays the same behavior, your complaint is with your platform socket implementation. Sockets are low-level gimmicks, which is why Jeremy expected a C program to fail the same way. -- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 08:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. -- Comment By: Tim Peters (tim_one) Date: 2004-07-26 21:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. -- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 08:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True: left = size - buf_len recv_size = max(self._rbufsize, left) data = self._sock.recv(recv_size) This code should read not more than *left* or *buffer size* So, it should be min instead of max ! Should I file a bug/patch for this ? -- Comment By: Tim Peters (tim_one) Date: 2003-06-18 15:51 Message: Logged In: YES user_id=31435 I assume you're
[ python-Bugs-751758 ] ftplib.retrbinary fails when called from retrlines callback
Bugs item #751758, was opened at 2003-06-10 03:51
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470
Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Long (christianmlong)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.retrbinary fails when called from retrlines callback
Initial Comment:
Subject: ftplib.retrbinary() fails when called from
inside retrlines() callback function
I'm using ftplib to backup files from a Linux server to
a Windows 2000 worksation.
Client:
Windows 2000 Pro
ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on
Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit
(Intel)] on win32
Komodo IDE
Server:
ProFTP server (ProFTPd version 1.25)
Mandrake Linux 9.0
Summary:
When I use it like this it works fine.
# Build a list of files that are on the remote server
f.retrlines('NLST', makeListOfFiles)
--then--
# Iterate over the list, retrieving each file
for remoteFileName in listOfFiles:
--snip--
f.retrbinary('RETR %s' % remoteFileName,
localFile.write)
--snip--
But it fails if I try to do the retrieve directly in my
callback function.
def transferFile(listLine):
--snip--
f.retrbinary('RETR %s' % remoteFileName,
localFile.write) <--fails here on first time through
--snip--
# get list of files from server, adn transfer each file
as it gets listed
f.retrlines('LIST', transferFile)
--snip--
File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
f.retrlines('LIST', transferFile)
File "C:\Python22\lib\ftplib.py", line 413, in retrlines
callback(line)
File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
f.retrbinary('RETR mra.py', localFile.write)
--snip--
File "C:\Python22\lib\ftplib.py", line 300, in makepasv
host, port = parse227(self.sendcmd('PASV'))
File "C:\Python22\lib\ftplib.py", line 572, in parse227
raise error_reply, resp
error_reply: 200 Type set to I.
It looks like the server is returning a 200 instead of
a 227 when retrbinary() is called inside a callback
function for retrlines().
Files:
2 Files are included: a broken version and a version
that works
This One Is Broken - retrbinary() called from inside a
callback function for retrlines().
===
import ftplib
import os
import time
REMOTE_DIR = "/home/mydir"
LOCAL_DIR = "C:\My Documents"
TIME_FORMAT = "%y%m%d"# YYMMDD, like 030522
def transferFile(listLine):
# Strips the file name from a line of a
# directory listing, and gets it from the
# server. Depends on filenames
# with no embedded spaces or extra dots.
if listLine.endswith('.py'):
#Split file name on the dot
splitFileName=remoteFileName.split('.')
# Add a timestamp
localFileName="%s_%s.%s" % (splitFileName[0],
time.strftime(TIME_FORMAT),
splitFileName[1])
# Open a local file for (over)writing, in
binary mode.
# print os.path.join(LOCAL_DIR,localFileName)
localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb')
print remoteFileName
print localFile
# Execute the FTP retrieve command, calling
# the write() function of the local file
# for each block retrieved from the FTP server
# BUG: This should work, but I get the
following traceback
f.retrbinary('RETR %s' % remoteFileName,
localFile.write)#<--- Fails
# Here
#mra.py
#
#Traceback (most recent call last):
# File "C:\Program Files\ActiveState Komodo
2.3\callkomodo\kdb.py", line 430, in _do_start
#self.kdb.run(code_ob, locals, locals)
# File "C:\Python22\lib\bdb.py", line 349, in run
#exec cmd in globals, locals
# File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
45, in ?
#f.retrlines('LIST', transferFile)
# File "C:\Python22\lib\ftplib.py", line 413, in retrlines
#callback(line)
# File "D:\My Documents\Computer World\Python
Resources\My Utilities\backup_remote_files.py", line
36, in transferFile
#f.retrbinary('RETR mra.py', localFile.write)
# File "C:\Python22\lib\ftplib.py", line 385, in
retrbinary
#conn = self.transfercmd(cmd, rest)
# File "C:\Python22\lib\ftplib.py", line 346, in
transfercmd
#return self.ntransfercmd(cmd, rest)[0]
# File "C:\Python22\lib\ftplib.py", line 322, in
ntransfercmd
#host, port = self.makepasv()
# File "C:\Python22\lib\ftplib.py", line 300, in makepasv
#host, port = p
[ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories
Bugs item #778804, was opened at 2003-07-28 06:00
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470
Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: vincent delft (vincent_delft)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer cannot manage cgi in sub directories
Initial Comment:
With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo
If I have a cgi script in cgi-bin it works wery well.
If i copy the same script (with all same privileges) in cgi-bin/test
(a subdirectory) I got the following message :
"Error response
Error code 403.
Message: CGI script is not a plain file ('/cgi-bin/test').
Error code explanation: 403 = Request forbidden -- authorization
will not help. "
If I remove the "rest.find('/')" code functionality by forcing the
result to -1 it works well (cfr here after)
Can you explain the goal of such coding ?
i = rest.find('/')
+ i=-1
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:43
Message:
Logged In: YES
user_id=752496
Duplicate of #737202, as the other has the patch, please go
on with it.
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 03:19
Message:
Logged In: YES
user_id=23486
same as bug 737202, which has an attached patch.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 14:06
Message:
Logged In: YES
user_id=80475
Eric, this was your change (2/9/2001). Will you take it from
here?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 14:54
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 03:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 10:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continue "walking" the url
continue
# scriptname is not a directory, stop "walking" the url
break
Patch is included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1103023 ] raw_input problem with readline and UTF8
Bugs item #1103023, was opened at 2005-01-15 18:10
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=1103023&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Casey Crabb (airog)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input problem with readline and UTF8
Initial Comment:
Backspace doesn't remove all bytes of a multi-byte
UTF-8 character.
To reproduce the problem:
$ export LANG=en_US.UTF-8
$ python
Python 2.3.4 (#1, Jun 11 2004, 16:35:29)
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r3, ssp-3.3-7,
pie-8.5.3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import readline
>>> raw_input() # ä, return
ä
'\xc3\xa4'
>>> raw_input() # ä, backspace, return
'\xc3'
>>>
A small C program does not have the same problem:
#include
#include
#include
#include
void pprint(const char *s);
int main(void) {
char *line;
for (;;) {
line = readline("> ");
if (!line)
break;
pprint(line);
free(line);
}
return 0;
}
void pprint(const char *s) {
while (*s) {
if (isprint(*s))
putchar(*s);
else
printf("\x%x", *s & 0xff);
s++;
}
putchar('\n');
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr
Bugs item #730222, was opened at 2003-04-30 12:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); - -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 This patch is no applied, the bug persists? -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 00:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-727241 ] Core Dumps : Python2.2.2
Bugs item #727241, was opened at 2003-04-24 19:16
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470
Category: None
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2
Initial Comment:
Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below. I have
compiled with 3 versions of gcc as well as MIPSpro.
Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.
>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))
> 0 realfree(0x10162e98, 0x0, 0x20, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
1 cleanfree(0x0, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
2 __malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
3 _malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]
I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.
import socket
import time
def doit():
s = socket.socket()
start = time.time()
try:
s.connect(('www.cnn.com', 80))
except socket.error,e:
print repr(e),str(e)
finish = time.time()
time.sleep(.5)
print str(finish-start),"\n"
s.close()
for x in xrange(10):
doit()
Here is the stack trace:
> 0 realfree(0x10162e98, 0x0, 0x20, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
1 cleanfree(0x0, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
2 __malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
3 _malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
7 PyTraceBack_H
[ python-Bugs-718532 ] inspect, class instances and __getattr__
Bugs item #718532, was opened at 2003-04-09 17:01 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 07:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 07:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 21:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2
Bugs item #711830, was opened at 2003-03-29 12:54
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: SEEK_{SET,CUR,END} missing in 2.2.2
Initial Comment:
Python 1.5.2 used to define SEEK_{SET,CUR,END} both in
FCNTL.py and in posixfile.py
Python 2.2.2 obsoletes both of them (and the symbols
are no longer in FCNTL anyway).
A quick grep on the 2.2.2 tree shows me posixfile is
the only place that still defines the SEEK_* constants.
It seems to me it's wrong to drop the constants
(because a deprecated module will eventually be dropped).
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 14:43
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 14:36
Message:
Logged In: YES
user_id=21627
Would you agree that these constants are best located in the
os module?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-716634 ] " build_ext" " libraries" subcommand not s
Bugs item #716634, was opened at 2003-04-07 06:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) >Summary: "build_ext" "libraries" subcommand not s Initial Comment: The "libraries" command for "build_ext" is definitely one that should accept multiple libraries. However, this is impossible for both the command line as well as the configuration file. Patch attached. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-706595 ] codecs.open and iterators
Bugs item #706595, was opened at 2003-03-19 20:02
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Todd Reed (toddreed)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open and iterators
Initial Comment:
Greg Aumann originally posted this problem in
comp.lang.python on Nov 4, 2002, but I could not find a
bug report. I've simply copied his news post, which
explains the problem:
---
Recently I figured out how to use iterators and
generators. Quite easy to
use and a great improvement.
But when I refactored some of my code I came across a
discrepancy that seems
like it must be a bug. If you use the old file reading idiom
with a codec
the lines are converted to unicode but if you use the new
iterators idiom
then they retain the original encoding and the line is
returned in non
unicode strings. Surely using the new "for line in file:"
idiom should give
the same result as the old, "while 1: "
I came across this when using the pythonzh Chinese
codecs but the below code
uses the cp1252 encoding to illustrate the problem
because everyone should
have those codecs. The symptoms are the same with
both codecs.
I am using python 2.2.2 on win2k.
Is this definitely a bug, or is it an undocumented 'feature'
of the codecs
module?
Greg Aumann
The following code illustrates the problem:
"""Check readline iterator using a codec."""
import codecs
fname = 'tmp.txt'
f = file(fname, 'w')
for i in range(0x82, 0x8c):
f.write( '%x, %s\n' % (i, chr(i)))
f.close()
def test_iter():
print '\ntesting codec iterator.'
f = codecs.open(fname, 'r', 'cp1252')
for line in f:
l = line.rstrip()
print repr(l)
print repr(l.decode('cp1252'))
f.close()
def test_readline():
print '\ntesting codec readline.'
f = codecs.open(fname, 'r', 'cp1252')
while 1:
line = f.readline()
if not line:
break
l = line.rstrip()
print repr(l)
try:
print repr(l.decode('cp1252'))
except AttributeError, msg:
print 'AttributeError', msg
f.close()
test_iter()
test_readline()
This code gives the following output:
testing codec iterator.
'82, \x82'
u'82, \u201a'
'83, \x83'
u'83, \u0192'
'84, \x84'
u'84, \u201e'
'85, \x85'
u'85, \u2026'
'86, \x86'
u'86, \u2020'
'87, \x87'
u'87, \u2021'
'88, \x88'
u'88, \u02c6'
'89, \x89'
u'89, \u2030'
'8a, \x8a'
u'8a, \u0160'
'8b, \x8b'
u'8b, \u2039'
testing codec readline.
u'82, \u201a'
AttributeError 'unicode' object has no attribute 'decode'
u'83, \u0192'
AttributeError 'unicode' object has no attribute 'decode'
u'84, \u201e'
AttributeError 'unicode' object has no attribute 'decode'
u'85, \u2026'
AttributeError 'unicode' object has no attribute 'decode'
u'86, \u2020'
AttributeError 'unicode' object has no attribute 'decode'
u'87, \u2021'
AttributeError 'unicode' object has no attribute 'decode'
u'88, \u02c6'
AttributeError 'unicode' object has no attribute 'decode'
u'89, \u2030'
AttributeError 'unicode' object has no attribute 'decode'
u'8a, \u0160'
AttributeError 'unicode' object has no attribute 'decode'
u'8b, \u2039'
AttributeError 'unicode' object has no attribute 'decode'
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 14:38
Message:
Logged In: YES
user_id=752496
Can not test it so far, all I got is:
testing codec iterator.
u'82, \u201a'
Traceback (most recent call last):
...
File "C:\Python24\lib\encodings\cp1252.py", line 22, in decode
return codecs.charmap_decode(input,errors,decoding_map)
UnicodeEncodeError: 'ascii' codec can't encode character
u'\u201a' in position 4: ordinal not in range(128)
I'm on Win2k, sp2, with Py2.4
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 14:38
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-03-20 06:35
Message:
Logged In: YES
user_id=38388
That's a bug in the iterator support which was added
to the codecs module: the .n
[ python-Bugs-1102973 ] Incorrect RFC 2231 decoding
Bugs item #1102973, was opened at 2005-01-15 11:13 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=1102973&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Incorrect RFC 2231 decoding Initial Comment: The following message ---snip snip--- Content-Transfer-Encoding: base64 Content-Type: application/msword; x-mac-type=42494E41; x-unix-mode=0644; x-mac-creator=4D535744; name="miriam's file.doc" Content-Disposition: attachment; filename*0="miriam's file"; filename*1=ths.doc ---snip snip--- Is incorrectly decoded according to RFC 2231. The bug is in Utils.py in the decode_params() and decode_rfc2231() functions. charset/lang encoding should only be present on the first parameter, i.e. filename*0 and even then, the quoted single quote should not trip up the scanner. The problem is two fold: - first, the unquoting of filename*0 happens in decode_param(), too early for decode_rfc2231() to know about it. Second, the logic in docode_rfc2231() is too naive; it should take quoting into account to decide whether a single quote is part of the file name or part of the leading charset/lang encoding. I've labeled this in the Group: Python 2.4, but it really affects Python 2.3 as well, and the current head. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-705792 ] test_atexit fails in directories with spaces
Bugs item #705792, was opened at 2003-03-18 16:33
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470
Category: None
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Hutchings (wom-work)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_atexit fails in directories with spaces
Initial Comment:
The regression test program test_atexit.py constructs a
command line without doing any quoting of arguments. If
the name of the build directory contains spaces, the
command doesn't work and the test fails. Here's what
happens in Windows:
H:\benh\My
Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d
test_atexit.py
Adding parser accelerators ...
Done.
Traceback (most recent call last):
File "test_atexit.py", line 33, in ?
""")
File "test_support.py", line 122, in vereq
raise TestFailed, "%r == %r" % (a, b)
test_support.TestFailed: '' == "handler2 (7,) {'kw':
'abc'}\nhandler2 () {}\nhandler1\n"
[5168 refs]
If I change the current directory to use a
compatibility name without a space in it:
H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd
h:\benh\mydocu~1\python\python-2.2.2\lib\test
H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d
test_atexit.py
Adding parser accelerators ...
Done.
[5168 refs]
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 21:42
Message:
Logged In: YES
user_id=33168
Directories with spaces should work with current CVS. The
fix needs to be backported.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-702147 ] --without-cxx flag of configure isn't documented.
Bugs item #702147, was opened at 2003-03-12 09:05 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:53 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 19:14 Message: Logged In: YES user_id=21627 Yes, please attached unified or context diffs to this bug report, preferably using the CVS version of Python (or 2.3a2 if CVS is not possible). -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 16:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? -- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 15:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 09:24 Message: Logged In: YES user_id=732192 For example.. The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -Lif you have libraries in a nonstandard directory CPPFLAGSC/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 08:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading
[ python-Bugs-700650 ] Canvas origin is off-canvas in create_< item> (). Worka
Bugs item #700650, was opened at 2003-03-10 02:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) >Summary: Canvas origin is off-canvas in create_- (). Worka Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-699816 ] Canvas Widget origin is off-screen
Bugs item #699816, was opened at 2003-03-08 03:21 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas Widget origin is off-screen Initial Comment: I'm a Python newbie, so be patient. I noticed that create-- didn't place the item where I expected. My [EMAIL PROTECTED] guru Matt Cowles suggested that highlightthickness (hT hereinafter) might be the culprit. I wasn't using hT, but I was using borderwidth (bd to all), and I eventually found the problem. I believe that it is an error in Tkinter, but I'll be happy to be corrected. I wrote a program to display the canvases with the four combinations of hT and bd, and later I doubled up to see if 'relief' with bd==0 had any effect. I'll try to upload the code (oops. It invoves two modules. I may have to send two messages, one with each module). Here is what I think happens, and what I think should happen : DOES: SHOULD: Tkinter finds screen coordinates cx, cy of Canvas same (crucial step omitted) tx, ty = cx, cy Tkinter translatescx, cy = cx - bd, cy -bd tx, ty = tx- bd, ty - bd Tkinter draws the border (width is 2*bd wider than the Canvas)draws the border Tkinter translatescx, cy = cx - hT, cy - hT tx, ty = tx - hT, ty - hT Tkinter draws the highlight box (width is 2*hT wider than the border)draws the hightlight box Tkinter delivers cx, cy as the origin of the Canvas delivers cx, cy as the origin The attached program, if it arrives, demonstrates this effect. Any one doing serious graphics will need to adjust the x,y values of every Canvas item they draw. Putting a wrapper around each to .get() the values of hT and bd (and others I haven't discovered yet ?) is feasible but awful. Putting a function at the top of each event callback function to correct the event object x and y is even more awkward. To preserve backwards compatibility, I suggest that Tkinter Canvas items all be given an extra set of x and y values, with distinctive names. The user can put any old values in the current x,y positional spots and use xcorrected = NN, ycorrected=NN to override the stuff in the positional spots. To handle the variable number of x,y pairs in create_polygon(), create_line(), and perhaps other, Tkinter might require that the new values be given in a tuple of pairs or two tuples (x0,x1,x2) & (y0,y1,y2) The attached file is TkCoords03.py The next error will include algGrid03.py. Hope you can get them together. Roy Keir newbieroy [EMAIL PROTECTED] -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-698706 ] imaplib: parsing INTERNALDATE
Bugs item #698706, was opened at 2003-03-06 10:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib: parsing INTERNALDATE Initial Comment: The regular expression InternalDate in imaplib does not match dates in which the day number is two-digit with a leading zero. >From a cursory glance at the IMAP definition, this is a legal format, and there is at least one IMAP server that uses it (courier-imap). The attached patch is for Python 2.2.2, but the problem still exists in 2.3a2. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:41 Message: Logged In: YES user_id=752496 This patch is not yet applied in CVS. Piers, I assign this to you because you know the module, but the patch is pretty simple, it's just adding a 0 to a part of the InternalDate's re: From: (?P[ 123] To: (?P[ 0123] -- Comment By: Tony Meyer (anadelonbrin) Date: 2004-04-22 22:43 Message: Logged In: YES user_id=552329 This is correct, RFC 2060 allows for the date to be "2digit", where digit includes 0. There is no attached patch, but I can't attach to this tracker, so I'm putting it here in the comment (it's a one character change). This still exists in 2004-04-23 anon cvs. *** imaplib.py Fri Apr 23 13:40:32 2004 --- imaplib-fixed.pyFri Apr 23 13:42:31 2004 *** *** 79,85 Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0- 9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') --- 79,85 Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 0123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0 -9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-687747 ] _iscommand() in webbrowser module
Bugs item #687747, was opened at 2003-02-17 01:17
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: _iscommand() in webbrowser module
Initial Comment:
[From a post to python-help]
Under KDE under Mandrake Linux the BROWSER environment
variable is set to
kfmclient openProfile webbrowsing
The problem is that _iscommand() in the webbrowser
module doesn't realize that only the first thing there
is the name of the executable. It looks for an
executable with that whole thing as its name and
doesn't find one. Since the module doesn't use any
browser it has found if BROWSER is set, it raises an
error rather than opening the page.
The possible fixes that are obvious to me all have
potential disadvantages:
One solution would be to assume that the name of the
executable ran only up to the first space. But
executables can have spaces in their names, especially
on a Macintosh, I think.
Another possibility would be not to call _iscommand()
on anything in BROWSER. That would have the additional
advantage of not requiring that the executable
specified there be in a directory that's in the user's
PATH. The problem with doing things this way is that it
would be impossible to tell which of the browsers
specified in BROWSER should be used until the user
called open().
I'm prepared to work on a fix if given some guidance
about the best way to go.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 09:26
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Richard Jones (richard)
Date: 2003-08-19 21:29
Message:
Logged In: YES
user_id=6405
This is still an issue... has there been any movement on it outside of this
bug report?
I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is
finding the BROWSER env var as described above, and thus not finding a
usable browser.
As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but
just prepended with its value. Sure, that means that the KDE BROWSER
value will be ignored, but it'll still find konqueror. This approach works for
me, and I'm sure it'll work for others who have "valid" BROWSER
values
:)
Simple patch against python2.3 (sorry, sf will mangle this, but it's short):
--- webbrowser.py 2003-08-20 10:28:07.0 +1000
+++ /usr/lib/python2.3/webbrowser.py2003-08-04
10:18:17.0 +1000
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any unknown
# browser referenced by this value, before calling open().
-_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
+_tryorder = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-02 22:19
Message:
Logged In: YES
user_id=6380
You know, I have no idea why all the lower() business is
there. Assigning to Fred Drake, maybe he knows more. (Fred,
please treat this as a hot potato -- if you don't
immediately know the answer, assign it back to me.)
--
Comment By: Matthew Cowles (mdcowles)
Date: 2003-03-02 17:43
Message:
Logged In: YES
user_id=198518
A week after posting <[EMAIL PROTECTED]>
("webbrowser module under MacOS"), it hasn't gotten any
replies. That suggests that Mac users either don't much care
about the module or don't read comp.lang.python.
If it's desirable merely to stop at the first space, it
should be sufficient to replace:
if _iscommand(cmd.lower()):
with
if _iscommand(cmd.lower().split(" ")[0]):
There remain some things that are dubious about the handling
of the values in the BROWSER environment variable. In
particular, the lower() in that line, the assumption that
the executables specified in BROWSER are in the user's PATH,
and the lack of handling of %% and %s in those values.
Still, it may be reasonable to ignore those issues until
they pose a problem.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-23 10:53
Message:
Logged In: YES
user_id=6380
Please ask around on c.l.py if the macintosh
[ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice
Bugs item #926423, was opened at 2004-03-31 05:48
Message generated for change (Comment added) made by irmen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeouts + Ctrl-C don't play nice
Initial Comment:
As reported by Koen Vossen in c.l.py, when a timeout is
set on a socket, a try...except block around a
socket.recv (or socket.recvfrom) won't properly catch a
keyboard interrupt (by Ctrl-C). I've attached example
code that shows this. Run it and press Ctrl-C before
the socket times out. This is for Python 2.3 under Linux.
I believe the problem boils down to this sequence of
events inside of the socketmodule.c::sock_recv function
(and similiar for sock_recvfrom):
1) internal_select is called, which calls select, which
waits for a timeout. A SIGINT is received (and caught
by the default handler). The select returns with errno
set to EINTR. internal_select returns with timeout==1
2) without checking errno, recv() is called. Since
there is actually no data, it returns an error, with
errno set to EAGAIN.
3) the default socket error handler is called, which
calls PyErr_SetFromErrno(). Since errno != EINTR (it's
now EAGAIN), a socket_error exception is thrown.
4) the innermost try..except block is triggered.
5) next loop around in eval_frame, notices that SIGINT
was caught, and so KeyboardInterrupt is raised, exiting
innermost try..except clause
6) KeyboardInterrupt is caught by the outermost
try..except block.
I was going to make a patch, but I couldn't figure out
the best way to fix this in general :-( There are
likely similiar problems with everywhere
internal_select is used. The quick fix is to check
errno before calling recv()
--
Comment By: Irmen de Jong (irmen)
Date: 2005-01-15 12:38
Message:
Logged In: YES
user_id=129426
I've submitted a patch, it's at 1102879
Please have a close look at it.
--
Comment By: David M. Cooke (dmcooke)
Date: 2005-01-14 00:28
Message:
Logged In: YES
user_id=65069
Looks like my assertion that timeout==1 is wrong :-).
Otherwise, the analysis is correct: recv is called when
select() retuned EINTR.
I think your approach is the way to go. Since the return
value of internal_select is no longer a boolean for a
timeout, maybe in the expressions "timeout =
internal_select(...)", "timeout" should be renamed to
something more generic (possibly 'selectresult')?
--
Comment By: Irmen de Jong (irmen)
Date: 2005-01-13 23:59
Message:
Logged In: YES
user_id=129426
(confirmed on Python 2.4 and HEAD)
But: your analysis is not correct:
internal_select doesn't return with timeout==1 when a SIGINT
occurs, instead it returns 0, because it doesn't check for
an error condition that select() may return.
So I hacked around a bit and changed internal_select to
return -1 when the select() system call returns -1,
and then also added the following in sock_recv:
if(errno) {
Py_DECREF(buf);
return PyErr_SetFromErrno(socket_error);
}
Which seems to make the example script that is attached to
this bug report run as expected.
As you say, I also think that this check must be added at
all locations where internal_select is called.
What do you say? I can make a patch if this is okay.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
