[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-23 02:31
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: d roberts (dcroberts)
>Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 10:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686597 ] descrintro: error describing __new__ behavior
Bugs item #1686597, was opened at 2007-03-23 06:47 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=1686597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro: error describing __new__ behavior Initial Comment: descrintro (http://www.python.org/download/releases/2.2.3/descrintro/#__new__) linked from http://www.python.org/doc/newstyle/ still says: "__new__ must return an object. [...] If you return an object of a different class, its __init__ method will be called." But since Revision 26220 - Modified Sat Apr 6 01:05:01 2002 UTC (4 years, 11 months ago) by gvanrossum: "Changed new-style class instantiation so that when C's __new__ method returns something that's not a C instance, its __init__ is not called. [SF bug #537450]" That is, exactly the opposite as said on descrintro. The documentation for __new__ in the Reference manual, section 3.4.1, is correct and says: "If __new__() does not return an instance of cls, then the new instance's __init__() method will not be invoked." Note that the modified behavior was already present on version 2.2.3 (and later) so updating the document currently at /download/releases/2.2.3/ would be fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-23 03:31
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: d roberts (dcroberts)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 11:24
Message:
Logged In: YES
user_id=21627
Originator: NO
It certainly is; Python is likely opening the file in the wrong mode now.
I'll investigate, although contributions would be welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 11:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685773 ] tarfile file names under win32
Bugs item #1685773, was opened at 2007-03-22 04:12
Message generated for change (Comment added) made by gagenellina
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ralf (indi4source)
Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile file names under win32
Initial Comment:
the tarfile module uses normpath() to store the file name in the archive. Under
win32 this results in pathes with backslashes and possible a leading "\". This
confuses the unix tar command.
I suppose the following commands instead of
just normpath():
path = normpath (path)
path = path.replace ("\\", "/")
path = path.lstrip ("/")
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-03-23 07:36
Message:
Logged In: YES
user_id=479790
Originator: NO
tarfile already attempts to manage backslashes well, using
os.path.normpath(path).replace(os.sep, "/")
Can you provide a small script demonstrating the failure?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Martin v. Löwis (loewis)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 14:35
Message:
Logged In: YES
user_id=21627
Originator: NO
Ok, I reverted this patch in r54543 and r54544.
arigo, what do you think about the alternative patch (fakeclose.diff),
which drops the ssl object in FakeSocket.close()? I don't think we can add
an explicit close operation for 2.5.x to SSL objects, so we have to
continue to rely on reference counting.
File Added: fakeclose.diff
--
Comment By: Armin Rigo (arigo)
Date: 2006-11-20 12:33
Message:
Logged In: YES
user_id=4771
Originator: NO
Martin, I think the rev 50844 is wrong. To start with,
it goes clearly against the documentation for makefile()
which states that both the socket and the pseudo-file
can be closed independently. What httplib.py was doing
was correct.
I could write a whole essay about the twisted history
of socket.py. It would boil down to: in r43746, Georg
removed a comment that was partially out-of-date,
but that was essential in explaining why there was no
self._sock.close() in _socketobject.close(): because
the original purpose of _socketobject was to implement
dup(), so that multiple _socketobjects could refer to
the same underlying _sock. The latter would close
automagically when its reference counter dropped to
zero. (This means that your check-in also made dup()
stop working on all platforms.)
The real OP's problem is that the _ssl object keeps
a reference to the underlying _sock as well, as
kxroberto pointed out. We need somewhere code that
closes the _ssl object...
For reference, PyPy - which doesn't have strong
refcounting guarantees - added the equivalent of an
explicit usage counter in the C socket object, and
socket.py calls methods on its underlying object to
increment and decrement that counter. It looks like
a solution for CPython too - at least, relying on
refcounting is bad, if only because - as you have
just proved - it creates confusion. (Also,
httplib/urllib have their own explicitly-refcounted
wrappers...)
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-26 14:14
[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-22 22:31
Message generated for change (Comment added) made by dcroberts
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: d roberts (dcroberts)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
>Comment By: d roberts (dcroberts)
Date: 2007-03-23 13:49
Message:
Logged In: YES
user_id=1750755
Originator: YES
Taking your hint, I just looked at the code in 42230 which uses the Win32
GetFileAttributesEx() function. This function does indeed return an error
for an in-use file. Not sure if this is a "feature" or "bug" in the
underlying Windows function. I did try FindFirstFile(), which is able to
return info on an in-use file. Not sure if this is a reasonable alternative
to GFAE(), but wanted to make folks aware of the possibility. It's probably
slower, since it can handle wild-cards, and returns a handle for subsequent
calls to FindNextFile(). The handle must be closed with FindClose(). I'm
not sure what underlying mechanism FindFirstFile() uses, but I'm assuming
it accesses the "directory" to get its information, rather than trying to
access the file itself. FWIW.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 06:24
Message:
Logged In: YES
user_id=21627
Originator: NO
It certainly is; Python is likely opening the file in the wrong mode now.
I'll investigate, although contributions would be welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 06:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685000 ] DoS asyncore vulnerability
Bugs item #1685000, was opened at 2007-03-21 02:15 Message generated for change (Comment added) made by rushing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- Comment By: Sam Rushing (rushing) Date: 2007-03-23 12:59 Message: Logged In: YES user_id=73736 Originator: NO The problem is that there's no portable way to know what the limit on file descriptors is. The 'classic' for select/poll is the FD_SETSIZE macro. But on some operating systems there is no such limit. [e.g., win32 does not use the 'lowest-free-int' model common to unix]. I believe that in Medusa there was a derived class or extension that counted the number of open sockets, and limited it, using something like a semaphore. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 09:57
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Martin v. Löwis (loewis)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: Armin Rigo (arigo)
Date: 2007-03-23 20:37
Message:
Logged In: YES
user_id=4771
Originator: NO
The fakeclose.diff patch looks safe enough.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 13:35
Message:
Logged In: YES
user_id=21627
Originator: NO
Ok, I reverted this patch in r54543 and r54544.
arigo, what do you think about the alternative patch (fakeclose.diff),
which drops the ssl object in FakeSocket.close()? I don't think we can add
an explicit close operation for 2.5.x to SSL objects, so we have to
continue to rely on reference counting.
File Added: fakeclose.diff
--
Comment By: Armin Rigo (arigo)
Date: 2006-11-20 11:33
Message:
Logged In: YES
user_id=4771
Originator: NO
Martin, I think the rev 50844 is wrong. To start with,
it goes clearly against the documentation for makefile()
which states that both the socket and the pseudo-file
can be closed independently. What httplib.py was doing
was correct.
I could write a whole essay about the twisted history
of socket.py. It would boil down to: in r43746, Georg
removed a comment that was partially out-of-date,
but that was essential in explaining why there was no
self._sock.close() in _socketobject.close(): because
the original purpose of _socketobject was to implement
dup(), so that multiple _socketobjects could refer to
the same underlying _sock. The latter would close
automagically when its reference counter dropped to
zero. (This means that your check-in also made dup()
stop working on all platforms.)
The real OP's problem is that the _ssl object keeps
a reference to the underlying _sock as well, as
kxroberto pointed out. We need somewhere code that
closes the _ssl object...
For reference, PyPy - which doesn't have strong
refcounting guarantees - added the equivalent of an
explicit usage counter in the C socket object, and
socket.py calls methods on its underlying object to
increment and decrement that counter. It looks like
a solution for CPython too - at least, relying on
refcounting is bad, if only because - as you have
just proved - it
[ python-Bugs-1687125 ] cannot catch KeyboardInterrupt when using curses getkey()
Bugs item #1687125, was opened at 2007-03-23 20:50 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=1687125&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: al65536 (al65536) Assigned to: Nobody/Anonymous (nobody) Summary: cannot catch KeyboardInterrupt when using curses getkey() Initial Comment: #!/usr/bin/python import curses # Will works scr=curses.initscr() key=-1 try: try: key=scr.getkey() except: pass except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key # Will fail scr=curses.initscr() key=-1 try: key=scr.getkey() except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687125 ] cannot catch KeyboardInterrupt when using curses getkey()
Bugs item #1687125, was opened at 2007-03-23 20:50 Message generated for change (Comment added) made by al65536 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: al65536 (al65536) Assigned to: Nobody/Anonymous (nobody) Summary: cannot catch KeyboardInterrupt when using curses getkey() Initial Comment: #!/usr/bin/python import curses # Will works scr=curses.initscr() key=-1 try: try: key=scr.getkey() except: pass except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key # Will fail scr=curses.initscr() key=-1 try: key=scr.getkey() except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key -- >Comment By: al65536 (al65536) Date: 2007-03-23 20:51 Message: Logged In: YES user_id=1751488 Originator: YES python file attached File Added: cursesbug.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes
Bugs item #1687163, was opened at 2007-03-23 16:51 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=1687163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes
Bugs item #1687163, was opened at 2007-03-23 17:51 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute -- >Comment By: Jack Diederich (jackdied) Date: 2007-03-23 18:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes
Bugs item #1687163, was opened at 2007-03-23 16:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 17:16 Message: Logged In: YES user_id=80475 Originator: YES Readonly methods throw an AttributeError, but readonly members (anything defined in PyMemberDef with an RO or READONLY flag) raise a TypeError. -- Comment By: Jack Diederich (jackdied) Date: 2007-03-23 17:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes
Bugs item #1687163, was opened at 2007-03-23 16:51
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent Exceptions for Readonly Attributes
Initial Comment:
Attempting assignment to a readonly attribute raises an Attribute error for
pure Python attributes but raises a TypeError for C readonly attributes. I
think the AttributeError is the correct exception.
>>> class A(object):
... _x = []
...
... @property
... def x(self):
... return self._x
...
>>> a = A()
>>> a.x = None
Traceback (most recent call last):
a.x = None
AttributeError: can't set attribute
>>> def f():
... yield None
>>> g = f()
>>> g.gi_frame = None
Traceback (most recent call last):
g.gi_frame = None
TypeError: readonly attribute
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 18:52
Message:
Logged In: YES
user_id=80475
Originator: YES
Here's the one line change:
Index: Python/structmember.c
===
--- Python/structmember.c (revision 54557)
+++ Python/structmember.c (working copy)
@@ -160,7 +160,7 @@
if ((l->flags & READONLY) || l->type == T_STRING)
{
- PyErr_SetString(PyExc_TypeError, "readonly attribute");
+ PyErr_SetString(PyExc_AttributeError, "readonly
attribute");
Four of the tests will need to be updated:
test_csv test_descr test_generators test_os
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 17:16
Message:
Logged In: YES
user_id=80475
Originator: YES
Readonly methods throw an AttributeError, but readonly members (anything
defined in PyMemberDef with an RO or READONLY flag) raise a TypeError.
--
Comment By: Jack Diederich (jackdied)
Date: 2007-03-23 17:12
Message:
Logged In: YES
user_id=591932
Originator: NO
I think this has something peculiar to frames, for instance:
Python 2.5 (r25:51908, Sep 25 2006, 17:50:07)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = 'asdf'
>>> f.strip = 42
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object attribute 'strip' is read-only
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&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-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-24 02:01 Message: Logged In: YES user_id=1344176 Originator: NO -1 on adding the identity function anywhere in the stdlib. This isn't just a 1-line function, it's only 10 characters: "lambda x:x". -- Comment By: Memotype (twobitsprite) Date: 2007-03-22 17:26 Message: Logged In: YES user_id=1679533 Originator: NO > Neither will submitting a patch with a reference count bug :-). Bleh, generational garbage collectors are where its at anyways. ;P -- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:57 Message: Logged In: YES user_id=591932 Originator: NO Let's put this thread on hold until we get a pronouncement. I don't think there is anything additional to be said. Alexander, don't worry, I didn't think you were talking about my patch ;) and don't worry about people writing sub-optimal code. If you start doing that you'll never get any sleep. -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:34 Message: Logged In: YES user_id=835142 Originator: NO I need to clarify that my comment about a buggy patch was responding to twobitsprite, not to jackdied whose post I noticed only after I hit submit. Jackdied's patch is correct, but my concern is that with identity in operators, functional programmers will start passing identity instead of None as func to map(func, ..) that will result in much slower code. -- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). -- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity funct
