[ python-Bugs-1174712 ] subclassing ModuleType and another built-in type
Bugs item #1174712, was opened at 2005-04-01 09:22
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=1174712&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type
Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault
This buggy subclassing goes through typeobject.c's checks because
PyModuleObject looks exactly like a user-defined subclass of 'object': it has a
PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.
A fix would be to forbid any subclassing to move the tp_dictoffset of a
non-heap type.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174606 ] Reading /dev/zero causes SystemError
Bugs item #1174606, was opened at 2005-04-01 04:48
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading /dev/zero causes SystemError
Initial Comment:
$ python -c 'open("/dev/zero").read()'
Traceback (most recent call last):
File "", line 1, in ?
SystemError: ../Objects/stringobject.c:3316: bad
argument to internal function
Compare with this two variants:
$ python -c 'open("/dev/zero").read(2**31-1)'
Traceback (most recent call last):
File "", line 1, in ?
MemoryError
$ python -c 'open("/dev/zero").read(2**31)'
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: long int too large to convert to int
The unsized read should produce either MemoryError or
OverflowError instead of SystemError.
Tested with Python 2.2, 2.3, and 2.4.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-04-01 09:58
Message:
Logged In: YES
user_id=4771
I think that file.read() with no argument needs to be more conservative.
Currently it asks and trusts the stat() to get the file size, but this can lead
to just plain wrong results on special devices. (I had the problem that
open('/dev/null').read() would give a MemoryError!)
We can argue whether plain read() on special devices is a good idea or not, but
I guess that not blindly trusting stat() if it returns huge values could be a
good idea.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1173637 ] quit should quit
Bugs item #1173637, was opened at 2005-03-30 23:37 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Chaput (mchaput) Assigned to: Nobody/Anonymous (nobody) Summary: quit should quit Initial Comment: When the user types "quit" in the interpreter, instead of quitting the program gives him or her a lecture on the "proper" way to quit. This is very obnoxious. Since the interpreter obviously understands the "quit" command, it should just quit, dammit. -- >Comment By: Sjoerd Mullender (sjoerd) Date: 2005-04-01 13:04 Message: Logged In: YES user_id=43607 Something like this instead of the current quit should do the trick: class Quit: def __repr__(self): import sys sys.exit(0) quit = Quit() del Quit The problem with the Raymond's suggestion is that you need to type parentheses. But of course, this does get a little magical... -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 08:14 Message: Logged In: YES user_id=80475 'quit' and 'exit' currently show-up in a dir() of__builtins__. If the OP's suggestion is accepted, it should probably be implemented just like a builtin: def quit(): sys.exit() That approach is not at all magical and still allows shadowing (quit=2, etc.) What we have now is an annoying wart. -- Comment By: Ilya Sandler (isandler) Date: 2005-04-01 06:35 Message: Logged In: YES user_id=971153 I am not sure adding quit to interpreter is such a good idea: Right now quit is treated as an ordinary (non-keyword) identifier... (with a bit of magic: if quit is not defined then lecture the user :-))... E.g now you can do this: >>> quit=2 >>> quit 2 Would you want to disallow this usage when quit becomes a "magic word"? -- Comment By: Michael Hudson (mwh) Date: 2005-03-31 11:49 Message: Logged In: YES user_id=6656 I'm not so sure typing quit should quit -- that doesn't seem like Python to me (how would you implement it?) Having quit be the same object as sys.exit seems sensible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-31 00:11 Message: Logged In: YES user_id=80475 I concur! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1173637 ] quit should quit
Bugs item #1173637, was opened at 2005-03-30 21:37 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Chaput (mchaput) Assigned to: Nobody/Anonymous (nobody) Summary: quit should quit Initial Comment: When the user types "quit" in the interpreter, instead of quitting the program gives him or her a lecture on the "proper" way to quit. This is very obnoxious. Since the interpreter obviously understands the "quit" command, it should just quit, dammit. -- >Comment By: Armin Rigo (arigo) Date: 2005-04-01 11:12 Message: Logged In: YES user_id=4771 This discussion keeps coming up time and again. sjoerd's trick has been tried a few times already, until people implementing it realized that trying to display the builtins dict (directly or indirectly) would quit the interpreter! 'quit' cannot just be a synonym for 'sys.exit' either, because typing 'quit' would just print '', which is worse than the current situation in term of expliciteness. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2005-04-01 11:04 Message: Logged In: YES user_id=43607 Something like this instead of the current quit should do the trick: class Quit: def __repr__(self): import sys sys.exit(0) quit = Quit() del Quit The problem with the Raymond's suggestion is that you need to type parentheses. But of course, this does get a little magical... -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 06:14 Message: Logged In: YES user_id=80475 'quit' and 'exit' currently show-up in a dir() of__builtins__. If the OP's suggestion is accepted, it should probably be implemented just like a builtin: def quit(): sys.exit() That approach is not at all magical and still allows shadowing (quit=2, etc.) What we have now is an annoying wart. -- Comment By: Ilya Sandler (isandler) Date: 2005-04-01 04:35 Message: Logged In: YES user_id=971153 I am not sure adding quit to interpreter is such a good idea: Right now quit is treated as an ordinary (non-keyword) identifier... (with a bit of magic: if quit is not defined then lecture the user :-))... E.g now you can do this: >>> quit=2 >>> quit 2 Would you want to disallow this usage when quit becomes a "magic word"? -- Comment By: Michael Hudson (mwh) Date: 2005-03-31 09:49 Message: Logged In: YES user_id=6656 I'm not so sure typing quit should quit -- that doesn't seem like Python to me (how would you implement it?) Having quit be the same object as sys.exit seems sensible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-30 22:11 Message: Logged In: YES user_id=80475 I concur! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174795 ] PYTHONPATH is not working
Bugs item #1174795, was opened at 2005-04-01 15:49 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=1174795&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: Nobody/Anonymous (nobody) Summary: PYTHONPATH is not working Initial Comment: When I run python for interpreting script in form: > python somescript.py I got error: python: can't open file 'somescript.py': [Errno 2] No such file or directory I set environment variable PYTHONPATH to 'C:\Python24\Scripts'. In directory C:\Python24\Scripts I place script 'hello.py' with content: print 'Hello' This script simply prints 'Hello' word on the screen. When I run script with command: > python c:\python24\scripts\hello.py all works right and prints 'Hello'. When I run script with command 'python hello.py' I have above mentioned error: C:\>python hello.py python: can't open file 'hello.py': [Errno 2] No such file or directory I check that this directory appear in sys.path when invoking python in interpreter session: C:\>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\Python24\Scripts', 'C:\Python24', 'C:\WINNT\system32\python24.zip ', 'C:\', 'C:\Python24\DLLs', 'C:\Python24\lib', 'C:\Python24\lib\plat-w in', 'C:\Python24\lib\lib-tk', 'C:\Python24\lib\site-packages', 'C:\Pytho n24\lib\site-packages\win32', 'C:\Python24\lib\site-packages\win32\lib', 'C:\Python24\lib\site-packages\Pythonwin'] >>> import hello Hello >>> As you see sys.path contain path to directory 'C:\Python24\Scripts' but nevertheless I cannot run my script hello.py simply type 'python hello.py' Changing of case of chars in string 'C:\Python24\Scripts' did not solved problem. This error has been reproduced on Windows 2000 SP4, Windows XP SP1, Windows 98 SE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174795 ] PYTHONPATH is not working
Bugs item #1174795, was opened at 2005-04-01 21:49 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: Nobody/Anonymous (nobody) Summary: PYTHONPATH is not working Initial Comment: When I run python for interpreting script in form: > python somescript.py I got error: python: can't open file 'somescript.py': [Errno 2] No such file or directory I set environment variable PYTHONPATH to 'C:\Python24\Scripts'. In directory C:\Python24\Scripts I place script 'hello.py' with content: print 'Hello' This script simply prints 'Hello' word on the screen. When I run script with command: > python c:\python24\scripts\hello.py all works right and prints 'Hello'. When I run script with command 'python hello.py' I have above mentioned error: C:\>python hello.py python: can't open file 'hello.py': [Errno 2] No such file or directory I check that this directory appear in sys.path when invoking python in interpreter session: C:\>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\Python24\Scripts', 'C:\Python24', 'C:\WINNT\system32\python24.zip ', 'C:\', 'C:\Python24\DLLs', 'C:\Python24\lib', 'C:\Python24\lib\plat-w in', 'C:\Python24\lib\lib-tk', 'C:\Python24\lib\site-packages', 'C:\Pytho n24\lib\site-packages\win32', 'C:\Python24\lib\site-packages\win32\lib', 'C:\Python24\lib\site-packages\Pythonwin'] >>> import hello Hello >>> As you see sys.path contain path to directory 'C:\Python24\Scripts' but nevertheless I cannot run my script hello.py simply type 'python hello.py' Changing of case of chars in string 'C:\Python24\Scripts' did not solved problem. This error has been reproduced on Windows 2000 SP4, Windows XP SP1, Windows 98 SE. -- Comment By: George Yoshida (quiver) Date: 2005-04-02 02:36 Message: Logged In: YES user_id=671362 PYTHONPATH is a path to search for modules, not a path to search for executable programs like PATH. If PATH variable contains a path to where hello.py is located, c:\> hello.py should work. Please read the tutorial about PYTHONPATH. http://docs.python.org/tut/node8.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1173637 ] quit should quit
Bugs item #1173637, was opened at 2005-03-30 16:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Chaput (mchaput) Assigned to: Nobody/Anonymous (nobody) Summary: quit should quit Initial Comment: When the user types "quit" in the interpreter, instead of quitting the program gives him or her a lecture on the "proper" way to quit. This is very obnoxious. Since the interpreter obviously understands the "quit" command, it should just quit, dammit. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 13:13 Message: Logged In: YES user_id=80475 class quit: def __repr__(self): return "Type quit() to exit the interpreter" def __call__(self): sys.exit() Requiring the parentheses is not a big deal as long as there is an advisory where they are omitted. -- Comment By: Armin Rigo (arigo) Date: 2005-04-01 06:12 Message: Logged In: YES user_id=4771 This discussion keeps coming up time and again. sjoerd's trick has been tried a few times already, until people implementing it realized that trying to display the builtins dict (directly or indirectly) would quit the interpreter! 'quit' cannot just be a synonym for 'sys.exit' either, because typing 'quit' would just print '', which is worse than the current situation in term of expliciteness. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2005-04-01 06:04 Message: Logged In: YES user_id=43607 Something like this instead of the current quit should do the trick: class Quit: def __repr__(self): import sys sys.exit(0) quit = Quit() del Quit The problem with the Raymond's suggestion is that you need to type parentheses. But of course, this does get a little magical... -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 01:14 Message: Logged In: YES user_id=80475 'quit' and 'exit' currently show-up in a dir() of__builtins__. If the OP's suggestion is accepted, it should probably be implemented just like a builtin: def quit(): sys.exit() That approach is not at all magical and still allows shadowing (quit=2, etc.) What we have now is an annoying wart. -- Comment By: Ilya Sandler (isandler) Date: 2005-03-31 23:35 Message: Logged In: YES user_id=971153 I am not sure adding quit to interpreter is such a good idea: Right now quit is treated as an ordinary (non-keyword) identifier... (with a bit of magic: if quit is not defined then lecture the user :-))... E.g now you can do this: >>> quit=2 >>> quit 2 Would you want to disallow this usage when quit becomes a "magic word"? -- Comment By: Michael Hudson (mwh) Date: 2005-03-31 04:49 Message: Logged In: YES user_id=6656 I'm not so sure typing quit should quit -- that doesn't seem like Python to me (how would you implement it?) Having quit be the same object as sys.exit seems sensible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-30 17:11 Message: Logged In: YES user_id=80475 I concur! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning
Bugs item #997100, was opened at 2004-07-24 10:20
Message generated for change (Comment added) made by hydrian
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Charles (melicertes)
Assigned to: Greg Ward (gward)
Summary: optparse.py:668 triggers FutureWarning
Initial Comment:
In Python 2.3.3, importing optparse triggers a
FutureWarning on line 668:
> /usr/local/lib/python2.3/optparse.py:668:
FutureWarning:
> %u/%o/%x/%X of negative int will return a signed
string in
> Python 2.4 and up
> return ("<%s at 0x%x: %r>"
--
Comment By: Ben Tyger (hydrian)
Date: 2005-04-01 13:35
Message:
Logged In: YES
user_id=685946
I am still seeing issues with Python 2.3.5 with getmail 4.3.3
--
Comment By: Greg Ward (gward)
Date: 2004-11-05 21:08
Message:
Logged In: YES
user_id=14422
Closing since (I think) I fixed this in Optik 1.5a2.
--
Comment By: Matthias Andree (m-a)
Date: 2004-09-25 06:27
Message:
Logged In: YES
user_id=2788
I for one have seen the warning with a Python 2.3.4 I compiled myself
(based on SuSE's 2.3.3 source RPM) on SuSE Linux 9.1.
--
Comment By: Greg Ward (gward)
Date: 2004-09-24 20:58
Message:
Logged In: YES
user_id=14422
Marking this fixed, but not closing it, pending a checkin to
optparse.py on Python 2.3 branch and confirmation that it
actually helped.
--
Comment By: Greg Ward (gward)
Date: 2004-09-24 20:58
Message:
Logged In: YES
user_id=14422
You didn't specify which OS this happens on; I bet it was
Fedora Core or RHEL 3.0, right? (I found a related thread
on python-dev, and ISTR it was related to the SE-Linux
changes fiddling how the userspace heap fits into VM.)
I'm checking in a change to optik/lib/option.py that should
suppress the warning. I'm not sure this is the right thing
to do, though, since 1) I can't reproduce it, and 2) I don't
think it will be an issue under Python 2.4, with the
continuing unification of int and long.
See
http://mail.python.org/pipermail/python-dev/2003-November/039952.html
and following messages.
Perhaps the right thing to do is just fix this in
optparse.py on the Python 2.3 branch and forget about Optik
or Python 2.4. Hmmm.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175022 ] property example code error
Bugs item #1175022, was opened at 2005-04-01 20:09 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=1175022&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ridley (ojokimu) Assigned to: Nobody/Anonymous (nobody) Summary: property example code error Initial Comment: The example code for 'property' in lib/built-in-funcs.html may produce an error if run "as is": Python 2.4.1 (#1, Mar 31 2005, 21:33:58) [GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 >>> class C(object): ... def getx(self): return self.__x ... def setx(self, value): self.__x = value ... def delx(self): del self.__x ... x = property(getx, setx, delx, "I'm the 'x' property.") ... >>> c=C() >>> c.x Traceback (most recent call last): File "", line 1, in ? File "", line 2, in getx AttributeError: 'C' object has no attribute '_C__x' The same goes for 'del c.x' (although not 'c.x = 0', of course). A more "typical" way of defining managed attributes would be to include an 'init' as follows: class C(object): def __init__(self): self.__x = None def getx(self): return self.__x def setx(self, value): self.__x = value def delx(self): del self.__x x = property(getx, setx, delx, "I'm the 'x' property.") -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174795 ] PYTHONPATH is not working
Bugs item #1174795, was opened at 2005-04-01 04:49 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: Nobody/Anonymous (nobody) Summary: PYTHONPATH is not working Initial Comment: When I run python for interpreting script in form: > python somescript.py I got error: python: can't open file 'somescript.py': [Errno 2] No such file or directory I set environment variable PYTHONPATH to 'C:\Python24\Scripts'. In directory C:\Python24\Scripts I place script 'hello.py' with content: print 'Hello' This script simply prints 'Hello' word on the screen. When I run script with command: > python c:\python24\scripts\hello.py all works right and prints 'Hello'. When I run script with command 'python hello.py' I have above mentioned error: C:\>python hello.py python: can't open file 'hello.py': [Errno 2] No such file or directory I check that this directory appear in sys.path when invoking python in interpreter session: C:\>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\Python24\Scripts', 'C:\Python24', 'C:\WINNT\system32\python24.zip ', 'C:\', 'C:\Python24\DLLs', 'C:\Python24\lib', 'C:\Python24\lib\plat-w in', 'C:\Python24\lib\lib-tk', 'C:\Python24\lib\site-packages', 'C:\Pytho n24\lib\site-packages\win32', 'C:\Python24\lib\site-packages\win32\lib', 'C:\Python24\lib\site-packages\Pythonwin'] >>> import hello Hello >>> As you see sys.path contain path to directory 'C:\Python24\Scripts' but nevertheless I cannot run my script hello.py simply type 'python hello.py' Changing of case of chars in string 'C:\Python24\Scripts' did not solved problem. This error has been reproduced on Windows 2000 SP4, Windows XP SP1, Windows 98 SE. -- >Comment By: Brett Cannon (bcannon) Date: 2005-04-01 13:02 Message: Logged In: YES user_id=357491 George is right. Closing as invalid. -- Comment By: George Yoshida (quiver) Date: 2005-04-01 09:36 Message: Logged In: YES user_id=671362 PYTHONPATH is a path to search for modules, not a path to search for executable programs like PATH. If PATH variable contains a path to where hello.py is located, c:\> hello.py should work. Please read the tutorial about PYTHONPATH. http://docs.python.org/tut/node8.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174606 ] Reading /dev/zero causes SystemError
Bugs item #1174606, was opened at 2005-04-01 06:48
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading /dev/zero causes SystemError
Initial Comment:
$ python -c 'open("/dev/zero").read()'
Traceback (most recent call last):
File "", line 1, in ?
SystemError: ../Objects/stringobject.c:3316: bad
argument to internal function
Compare with this two variants:
$ python -c 'open("/dev/zero").read(2**31-1)'
Traceback (most recent call last):
File "", line 1, in ?
MemoryError
$ python -c 'open("/dev/zero").read(2**31)'
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: long int too large to convert to int
The unsized read should produce either MemoryError or
OverflowError instead of SystemError.
Tested with Python 2.2, 2.3, and 2.4.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-04-01 23:42
Message:
Logged In: YES
user_id=21627
I think it should trust the stat result, and then find that
it cannot allocate that much memory.
Actually, os.stat("/dev/zero").st_size is 0, so something
else must be going on.
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-01 11:58
Message:
Logged In: YES
user_id=4771
I think that file.read() with no argument needs to be more conservative.
Currently it asks and trusts the stat() to get the file size, but this can lead
to just plain wrong results on special devices. (I had the problem that
open('/dev/null').read() would give a MemoryError!)
We can argue whether plain read() on special devices is a good idea or not, but
I guess that not blindly trusting stat() if it returns huge values could be a
good idea.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1173637 ] quit should quit
Bugs item #1173637, was opened at 2005-03-30 23:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matt Chaput (mchaput) Assigned to: Nobody/Anonymous (nobody) Summary: quit should quit Initial Comment: When the user types "quit" in the interpreter, instead of quitting the program gives him or her a lecture on the "proper" way to quit. This is very obnoxious. Since the interpreter obviously understands the "quit" command, it should just quit, dammit. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-01 23:47 Message: Logged In: YES user_id=21627 But how is this better than the current >>> quit 'Use Ctrl-D (i.e. EOF) to exit.' I'd rather learn that I have to type Ctrl-D instead of typing quit() I think the original report is misguided: The interpreter does not "obviously understand" the quit command. Instead, it really does not understand it all. The name quit is bound to a string, and the interpreter displays the string. It does not understand at all what the string says. So I'm rejecting the report as "won't fix". -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 20:13 Message: Logged In: YES user_id=80475 class quit: def __repr__(self): return "Type quit() to exit the interpreter" def __call__(self): sys.exit() Requiring the parentheses is not a big deal as long as there is an advisory where they are omitted. -- Comment By: Armin Rigo (arigo) Date: 2005-04-01 13:12 Message: Logged In: YES user_id=4771 This discussion keeps coming up time and again. sjoerd's trick has been tried a few times already, until people implementing it realized that trying to display the builtins dict (directly or indirectly) would quit the interpreter! 'quit' cannot just be a synonym for 'sys.exit' either, because typing 'quit' would just print '', which is worse than the current situation in term of expliciteness. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2005-04-01 13:04 Message: Logged In: YES user_id=43607 Something like this instead of the current quit should do the trick: class Quit: def __repr__(self): import sys sys.exit(0) quit = Quit() del Quit The problem with the Raymond's suggestion is that you need to type parentheses. But of course, this does get a little magical... -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 08:14 Message: Logged In: YES user_id=80475 'quit' and 'exit' currently show-up in a dir() of__builtins__. If the OP's suggestion is accepted, it should probably be implemented just like a builtin: def quit(): sys.exit() That approach is not at all magical and still allows shadowing (quit=2, etc.) What we have now is an annoying wart. -- Comment By: Ilya Sandler (isandler) Date: 2005-04-01 06:35 Message: Logged In: YES user_id=971153 I am not sure adding quit to interpreter is such a good idea: Right now quit is treated as an ordinary (non-keyword) identifier... (with a bit of magic: if quit is not defined then lecture the user :-))... E.g now you can do this: >>> quit=2 >>> quit 2 Would you want to disallow this usage when quit becomes a "magic word"? -- Comment By: Michael Hudson (mwh) Date: 2005-03-31 11:49 Message: Logged In: YES user_id=6656 I'm not so sure typing quit should quit -- that doesn't seem like Python to me (how would you implement it?) Having quit be the same object as sys.exit seems sensible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-31 00:11 Message: Logged In: YES user_id=80475 I concur! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1170424 ] why should URL be required for all packages
Bugs item #1170424, was opened at 2005-03-25 10:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jürgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: why should URL be required for all packages Initial Comment: Annoying if you just want to roll an in-house package. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-01 23:50 Message: Logged In: YES user_id=21627 In addition, the bug report is under-specified: Who says that an URL is required for all packages? It certainly is possible to have packages without URL, so I can't see why you are annoyed. Closing the report as "invalid". If you still think there is a bug in Python, please submit a new report, stating what you are doing, what happens, and what you expect to happen instead. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 20:12 Message: Logged In: YES user_id=593130 Bugs are a discrepancy between intended/claimed behavior and actual behavior. Since this does not appear to report such a discrepancy, it does not appear to be a bug report. Please close and ask your question and make your comment on the Python discussion mailing list or newsgroup (comp.lang.python). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1169633 ] Install fail code 2932 after fail to copy python_icon.exe
Bugs item #1169633, was opened at 2005-03-24 05:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169633&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wagner (wks2) Assigned to: Nobody/Anonymous (nobody) Summary: Install fail code 2932 after fail to copy python_icon.exe Initial Comment: In the Enterprise Windows environment we have a Network share as the homedir for all users. The server forbid to write .exe files to this share. I can install programs in the local disk (I have lots of then installed). Python-2.4.MSI Installation fails with error code 2932 after the system rejects the copy of python_icon.exe to the homedir. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-01 23:55 Message: Logged In: YES user_id=21627 Please provide a little more details on how to reproduce this: What operating system are you using? How precisely is the server setup to forbid writing .exe files to a share? Are you trying to install the program as a machine administrator, or as a non-administrator? If administrator, did you select per-user or per-machine installations? As is, it is very hard to understand what you did. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169633&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Bugs item #1167262, was opened at 2005-03-21 04:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-02 00:02 Message: Logged In: YES user_id=21627 C99 7.14.1.1/p8 specifies # If the request can be honored, the signal function # returns the value of func for the most recent successful # call to signal for the specified signal sig. Otherwise, a # value of SIG_ERR is returned and a positive value is stored # in errno. So it seems to me that VC8 is in error: the request cannot be "honored", so it should return SIG_ERR. Until/if VC8 is released with that bug, I would like to take no action here. When it is released, we still might consider to ignore it until say, 8.1 comes along and fixes the bug. -- Comment By: Michael Hudson (mwh) Date: 2005-03-27 22:59 Message: Logged In: YES user_id=6656 Ew. My first thought is, is that allowed by ANSI C? I'd guess it's undefined behaviour. It still seems excessively unfriendly -- have you reported this to MS? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning
Bugs item #997100, was opened at 2004-07-24 11:20
Message generated for change (Comment added) made by gward
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Charles (melicertes)
Assigned to: Greg Ward (gward)
Summary: optparse.py:668 triggers FutureWarning
Initial Comment:
In Python 2.3.3, importing optparse triggers a
FutureWarning on line 668:
> /usr/local/lib/python2.3/optparse.py:668:
FutureWarning:
> %u/%o/%x/%X of negative int will return a signed
string in
> Python 2.4 and up
> return ("<%s at 0x%x: %r>"
--
>Comment By: Greg Ward (gward)
Date: 2005-04-01 22:00
Message:
Logged In: YES
user_id=14422
It's highly unlikely there will be another Python 2.3
release. If you still see this behaviour with 2.4 or 2.4.1,
let me know and I'll consider fixing it in 2.4. Otherwise,
this bug stayss closed. Sorry.
--
Comment By: Ben Tyger (hydrian)
Date: 2005-04-01 13:35
Message:
Logged In: YES
user_id=685946
I am still seeing issues with Python 2.3.5 with getmail 4.3.3
--
Comment By: Greg Ward (gward)
Date: 2004-11-05 21:08
Message:
Logged In: YES
user_id=14422
Closing since (I think) I fixed this in Optik 1.5a2.
--
Comment By: Matthias Andree (m-a)
Date: 2004-09-25 07:27
Message:
Logged In: YES
user_id=2788
I for one have seen the warning with a Python 2.3.4 I compiled myself
(based on SuSE's 2.3.3 source RPM) on SuSE Linux 9.1.
--
Comment By: Greg Ward (gward)
Date: 2004-09-24 21:58
Message:
Logged In: YES
user_id=14422
Marking this fixed, but not closing it, pending a checkin to
optparse.py on Python 2.3 branch and confirmation that it
actually helped.
--
Comment By: Greg Ward (gward)
Date: 2004-09-24 21:58
Message:
Logged In: YES
user_id=14422
You didn't specify which OS this happens on; I bet it was
Fedora Core or RHEL 3.0, right? (I found a related thread
on python-dev, and ISTR it was related to the SE-Linux
changes fiddling how the userspace heap fits into VM.)
I'm checking in a change to optik/lib/option.py that should
suppress the warning. I'm not sure this is the right thing
to do, though, since 1) I can't reproduce it, and 2) I don't
think it will be an issue under Python 2.4, with the
continuing unification of int and long.
See
http://mail.python.org/pipermail/python-dev/2003-November/039952.html
and following messages.
Perhaps the right thing to do is just fix this in
optparse.py on the Python 2.3 branch and forget about Optik
or Python 2.4. Hmmm.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174795 ] PYTHONPATH is not working
Bugs item #1174795, was opened at 2005-04-01 15:49 Message generated for change (Comment added) made by bialix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 Category: Windows Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: Nobody/Anonymous (nobody) Summary: PYTHONPATH is not working Initial Comment: When I run python for interpreting script in form: > python somescript.py I got error: python: can't open file 'somescript.py': [Errno 2] No such file or directory I set environment variable PYTHONPATH to 'C:\Python24\Scripts'. In directory C:\Python24\Scripts I place script 'hello.py' with content: print 'Hello' This script simply prints 'Hello' word on the screen. When I run script with command: > python c:\python24\scripts\hello.py all works right and prints 'Hello'. When I run script with command 'python hello.py' I have above mentioned error: C:\>python hello.py python: can't open file 'hello.py': [Errno 2] No such file or directory I check that this directory appear in sys.path when invoking python in interpreter session: C:\>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\Python24\Scripts', 'C:\Python24', 'C:\WINNT\system32\python24.zip ', 'C:\', 'C:\Python24\DLLs', 'C:\Python24\lib', 'C:\Python24\lib\plat-w in', 'C:\Python24\lib\lib-tk', 'C:\Python24\lib\site-packages', 'C:\Pytho n24\lib\site-packages\win32', 'C:\Python24\lib\site-packages\win32\lib', 'C:\Python24\lib\site-packages\Pythonwin'] >>> import hello Hello >>> As you see sys.path contain path to directory 'C:\Python24\Scripts' but nevertheless I cannot run my script hello.py simply type 'python hello.py' Changing of case of chars in string 'C:\Python24\Scripts' did not solved problem. This error has been reproduced on Windows 2000 SP4, Windows XP SP1, Windows 98 SE. -- >Comment By: Alexander Belchenko (bialix) Date: 2005-04-02 07:46 Message: Logged In: YES user_id=957594 Sorry for this mistake. Obviously I misunderstood documentation. -- Comment By: Brett Cannon (bcannon) Date: 2005-04-02 00:02 Message: Logged In: YES user_id=357491 George is right. Closing as invalid. -- Comment By: George Yoshida (quiver) Date: 2005-04-01 20:36 Message: Logged In: YES user_id=671362 PYTHONPATH is a path to search for modules, not a path to search for executable programs like PATH. If PATH variable contains a path to where hello.py is located, c:\> hello.py should work. Please read the tutorial about PYTHONPATH. http://docs.python.org/tut/node8.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174795&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175194 ] import statement likely to crash if module launches threads
Bugs item #1175194, was opened at 2005-04-01 21:11 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=1175194&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: import statement likely to crash if module launches threads Initial Comment: I have a simple module which launches multiple HTTP client threads. The main thread creates 10 HTTP clients, each of which fetches documents from a web server. The main thread then simply goes to sleep while the client threads work. The threads are launched when the module is imported. If I launch the script via python bug1.py it launches and runs OK, and dies cleanly upon ^C. But if I launch the script via python -c 'import bug1' it hangs at launch, and dumps core upon ^C. Here's an example: [EMAIL PROTECTED]> ./python -c 'import bug1' Using 10 threads cc <- [program hangs here] Traceback (most recent call last): File "", line 1, in ? File "test/bug1.py", line 55, in ? run (10) File "test/bug1.py", line 50, in run time.sleep (3) KeyboardInterrupt Fatal Python error: PyImport_GetModuleDict: no module dictionary! Aborted (core dumped) You might argue that it's inappropriate to launch threads from within import statement, but I can't find a specific prohibition against it. In any event, it shouldn't cause the interpreter to crash. Please note that the crash isn't consistent. Sometimes the import statement doesn't lead to a crash. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175194&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175202 ] python hangs if import statement launches threads
Bugs item #1175202, was opened at 2005-04-01 21:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175202&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: python hangs if import statement launches threads Initial Comment: (This bug looks similar to bug 1175194, but reports a different problem.) I have a simple module which launches multiple HTTP client threads. The main thread creates 10 HTTP clients, each of which fetches documents from a web server. The main thread then simply goes to sleep while the client threads work. The threads are launched when the module is imported. If I launch the script via python bug1.py it launches and runs OK. But if I launch the script via python -c 'import bug1' it runs a bit, then hangs. Here's an example: [EMAIL PROTECTED]> ./python -c 'import bug1' Using 10 threads cc <- [program hangs here] Each thread prints a character every time that it does something interesting. The 'c' characters indicate that a connect syscall was made. These should be followed by 'C', indicating the the connect returned. That never happens. You might argue that it's inappropriate to launch threads from within import statement, but I can't find a specific prohibition against it. Here's a trace of the last few syscalls before it hangs (pids are actually thread ids): [pid 15481] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15481] futex(0x8148698, FUTEX_WAIT, 0, NULL [pid 15482] futex(0x81a9a80, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] write(2, "c", 1c)= 1 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x8148698, FUTEX_WAIT, 0, NULL <- hangs here Please note that this bug is similar to bug 1175194, but reports a different problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
