[ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo
Bugs item #1553577, was opened at 2006-09-06 11:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Tim Peters (tim_one)
Summary: datetime.datetime.now() mangles tzinfo
Initial Comment:
When using the pytz package (http://pytz.sf.net/) to create
timezone info objects datetime.datetime.now() behaves
differently than the regular datetime.datetime()
contstructor. Here's an example:
>>> import pytz
>>> info = pytz.timezone("US/Central")
>>> info
>>> import datetime
>>> now = datetime.datetime.now(tz=info)
>>> now
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18,
983849, tzinfo=info)
>>> t2
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
True
It appears that datetime.datetime.now() makes an
off-by-one-hour copy of the timezone info it was passed.
I've reproduced this on 2.4.3 and 2.5c1 as of August 17.
(It's also a little annoying that the timezone arg for
datetime.datetime.now() is "tz" while the timezone arg for
datetime.datetime() is "tzinfo". Is there a good
reason for
them to be different?)
Skip
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-07 00:08
Message:
Logged In: YES
user_id=33168
Since Tim wrote this code AFAIK, there *had* to be a good
reason. :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553819 ] Class instance apparently not destructed when expected
Bugs item #1553819, was opened at 2006-09-06 20:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: Nobody/Anonymous (nobody) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8
Bugs item #1324799, was opened at 2005-10-12 08:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: A.M. Kuchling (akuchling) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:37 Message: Logged In: YES user_id=11375 Committed in rev.50845, so this fix will be in Python 2.5. Closing this bug. If someone wants to submit a patch to use X/Open curses, please do. (I don't have a Solaris machine, so I can't assemble a patch myself.) -- Comment By: Tim Mooney (enchanter) Date: 2006-05-14 22:06 Message: Logged In: YES user_id=36222 First, your patch does fix the problem. Next, Solaris 8+ *does* have mvwgetnwstr, the problem is that it's in the X/Open version of the curses library, not the (old, stinky, backwards-compatible) default version of libcurses. Solaris 10's man pages do a much better job of explaining the differences, on 10 one can look at man -s 3xcurses libcurses vs. man libcurses If you want to compile and link against the X/Open version of the curses library, you need to have -I/usr/xpg4/include in CPPFLAGS and CFLAGS, and either -L/usr/xpg4/lib or -L/usr/xpg4/lib/64 (depending on whether you're compiling for ILP32 or LP64). /usr/xpg4/lib and /usr/xpg4/lib/64 are also not in the default loader search path, so you either need to modify the loader search path (man crle) or your also need a -R/usr/xpg4/lib or -R/usr/xpg4/lib/64 in LDFLAGS too. Because of the way the _cursesmodule is currently written, though, it assumes that if __sun is defined as a preprocessor symbol, STRICT_SYSV_CURSES should be defined, which actually causes problems if you try build with with newer X/Open curses. It should be possible to support building against either curses implementation on Solaris, but for now your patch at least makes _cursesmodule compile with the default version. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 09:45 Message: Logged In: YES user_id=11375 One use of mvwgetnwstr in the module is replaced by a manual emulation of the function, if STRICT_SYSV_CURSES is true, but another use isn't replaced; I suspect this is the problem. I've attached a patch that ensures that mvwgetnstr() is only used when STRICT_SYSV_CURSES is undefined. Please let me know if this fixes the compilation problem. -- Comment By: Nelson Arzola (narzola) Date: 2005-10-29 04:01 Message: Logged In: YES user_id=39023 I would like to add that this problem also exists under Solaris 2.10. For some reason, mvwgetnstr is not defined under Solaris 10. When I use nm to get t
[ python-Bugs-1542407 ] httplib reads one byte per system call
Bugs item #1542407, was opened at 2006-08-18 00:33
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Zoyd Wheeler (zoyd2k)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib reads one byte per system call
Initial Comment:
The HTTPResponse class in httplib.py contains the
following line in its __init__ method:
self.fp = sock.makefile('rb', 0)
The zero in that second (bufsize) argument overrides
the default behavior of the socket filedescriptor in
its readline() method, which is to read in a buffer's
worth of data from the socket at a time and only hit
the socket again if the buffer runs dry. When bufsize
is set to zero, the filedescriptor sets its internal
buffer size to one. As a result, readline() makes a
system call for every byte of data consumed. Since
httplib uses readline to obtain the http header, that's
an awful lot of system calls. We noticed this when
trying to build a fairly aggressive application on top
of xmlrpclib (which relies on httplib); we saw tons of
system call activity.
There is no comment near this line of code to indicate
whether this behavior is intended or not. If it is not
intended, the patch is to simply remove the second
argument and rely on the default (or allow the caller
to specify a buffer size).
In case reading a byte at a time is actually intended,
we have a simple work-around for those who care to use
it. In the python code that uses httplib, add the
following:
import httplib
...
class HTTPResponse(httplib.HTTPResponse):
def __init__(self, sock, **kw):
httplib.HTTPResponse.__init__(self, sock, **kw)
self.fp = sock.makefile('rb')
httplib.HTTPConnection.response_class = HTTPResponse
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 09:41
Message:
Logged In: YES
user_id=11375
Also, I have a vague memory that httplib is used with
pipelined HTTP requests. Buffering on the makefile() then
causes problems because the stdio buffer can slurp up too
much data, including portions of the next pipelined request.
I think making buffering workable would require serious
restructuring of the httplib code.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-08-27 13:44
Message:
Logged In: YES
user_id=341410
Because the socket is in blocking mode, performing
self.fp.read(x) with an x > 1 will generally block until it
has read x bytes or the other end disconnects. As such, I
believe it is intended behavior.
For your own application, you could perhaps write a response
class that uses non-blocking sockets to handle readline,
switching back to blocking sockets after header reading is over.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) >Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1554133 ] PyOS_InputHook() and related API funcs. not documented
Bugs item #1554133, was opened at 2006-09-07 10:06 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=1554133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook() and related API funcs. not documented Initial Comment: AFAICT, PyOS_InputHook() isn't described anywhere in the docs. Even the .h files don't contain comments explaining it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1554133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553819 ] Class instance apparently not destructed when expected
Bugs item #1553819, was opened at 2006-09-07 04:26 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] -- >Comment By: Michael Hudson (mwh) Date: 2006-09-07 15:06 Message: Logged In: YES user_id=6656 It's a reference cycle featuring an object with a __del__ --> it ends up in gc.garbage. More coffee for Neal? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 08:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 15:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. -- >Comment By: Michael Hudson (mwh) Date: 2006-09-07 15:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 15:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. -- Comment By: Michael Hudson (mwh) Date: 2006-09-07 10:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 10:42
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Richard Boulton (richardb)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python polls unnecessarily every 0.1 second when interactive
Initial Comment:
When python is running an interactive session, and is
idle, it calls "select" with a timeout of 0.1 seconds
repeatedly. This is intended to allow PyOS_InputHook()
to be called every 0.1 seconds, but happens even if
PyOS_InputHook() isn't being used (ie, is NULL).
To reproduce:
- start a python session
- attach to it using strace -p PID
- observe that python repeatedly
This isn't a significant problem, since it only affects
idle interactive python sessions and uses only a tiny
bit of CPU, but people are whinging about it (though
some appear to be doing so tongue-in-cheek) and it
would be nice to fix it.
The attached patch (against Python-2.5c1) modifies the
readline.c module so that the polling doesn't happen
unless PyOS_InputHook is not NULL.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 10:38
Message:
Logged In: YES
user_id=11375
On looking at the readline code, I think this patch makes no
difference to signals.
The code in readline.c for the callbacks looks like this:
has_input = 0;
while (!has_input) {
...
has_input = select.select(rl_input);
}
if (has_input > 0) {read character}
elif (errno == EINTR) {check signals}
So I think that, if a signal is delivered to a thread and
select() in the main thread doesn't return EINTR, the old
code is just as problematic as the code with this patch.
The (while !has_input) loop doesn't check for signals at all
as an exit condition.
I'm not sure what to do at this point. I think the new code
is no worse than the old code with regard to signals. Maybe
this loop is buggy w.r.t. to signals, but I don't know how
to test that.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 10:17
Message:
Logged In: YES
user_id=11375
HAVE_READLINE_CALLBACK was not defined with readline 5.1 on
Ubuntu Dapper, until I did the configure/CFLAG trick.
I didn't think of a possible interaction with signals, and
will re-open the bug while trying to work up a test case.
--
Comment By: Michael Hudson (mwh)
Date: 2006-09-07 10:12
Message:
Logged In: YES
user_id=6656
I'd be cautious about applying this to 2.5: we could end up with the same
problem currently entertaining python-dev, i.e. a signal gets delivered to a
non-
main thread but the main thread is sitting in a select with no timeout so any
python signal handler doesn't run until the user hits a key.
HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think...
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 10:02
Message:
Logged In: YES
user_id=11375
Recent versions of readline can still support callbacks if
READLINE_CALLBACK is defined, so I could test the patch by
running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure.
Applied as rev. 51815 to the trunk, so the fix will be in
Python 2.6. The 2.5 release manager needs to decide if it
should be applied to the 2.5 branch.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 09:24
Message:
Logged In: YES
user_id=11375
Original report:
http://perkypants.org/blog/2006/09/02/rfte-python
This is tied to the version of readline being used; the
select code is only used if HAVE_RL_CALLBACK is defined, and
a comment in Python's configure.in claims it's only defined
with readline 2.1. Current versions of readline are 4.3 and
5.1; are people still using such an ancient version of readline?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo
Bugs item #1553577, was opened at 2006-09-06 14:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.datetime.now() mangles tzinfo
Initial Comment:
When using the pytz package (http://pytz.sf.net/) to create
timezone info objects datetime.datetime.now() behaves
differently than the regular datetime.datetime()
contstructor. Here's an example:
>>> import pytz
>>> info = pytz.timezone("US/Central")
>>> info
>>> import datetime
>>> now = datetime.datetime.now(tz=info)
>>> now
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18,
983849, tzinfo=info)
>>> t2
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
True
It appears that datetime.datetime.now() makes an
off-by-one-hour copy of the timezone info it was passed.
I've reproduced this on 2.4.3 and 2.5c1 as of August 17.
(It's also a little annoying that the timezone arg for
datetime.datetime.now() is "tz" while the timezone arg for
datetime.datetime() is "tzinfo". Is there a good
reason for
them to be different?)
Skip
--
>Comment By: Tim Peters (tim_one)
Date: 2006-09-07 13:11
Message:
Logged In: YES
user_id=31435
`tzinfo` is the name of a datetime data attribute, and the
same name (i.e., "tzinfo") is generally used for arguments
that mindlessly attach a subclass of the `tzinfo` class to
an object as the value of its `tzinfo` data attribute. The
datetime constructor is an example of that. `tz` is
generally used when the time zone info is /actively
applied/, as now() does.
In contrast, the datetime constructor never makes any
attempt at conversion; if a tzinfo argument is passed, it's
merely tacked on to the datetime object.
Beyond that, I have no idea why the pytz class passed to
now() isn't showing up as the resulting datetime object's
tzinfo member. For example, that's not what happens if you
try this in the Python sandbox "datetime" directory:
>>> from US import Eastern
>>> from datetime import datetime
>>> now = datetime.now(Eastern)
>>> now
datetime.datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=)
>>> t2 = datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=Eastern)
>>> t2
datetime.datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=)
>>> now.tzinfo == Eastern
True
>>> t2.tzinfo == Eastern
True
>>> t2.tzinfo is now.tzinfo is Eastern
True
I expect the pytz developers could shed light on that.
datetime.now(tz) with `tz` not None first mindlessly
constructs a datetime object (let's call it `self`) based on
current (UTC) time with tz attached as the value of its
`tzinfo` data attribute, and then returns the result of invoking
tz.fromutc(self)
So if pytz overrides the default `fromutc()` implementation
in its tzinfo subclasses, you'll get back whatever they
decided to return from it. No code in Python "makes an
off-by-one-hour copy" here.
In short, I believe your primary question here is about how
pytz works, and I can't answer that. IIRC, pytz does fancy
stuff trying to avoid the 1-hour ambiguities at DST
transition times, and I wouldn't be surprised if, toward
that end, they have multiple internal tzinfo subclasses for
each "conceptual" time zone.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-07 03:08
Message:
Logged In: YES
user_id=33168
Since Tim wrote this code AFAIK, there *had* to be a good
reason. :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553819 ] Class instance apparently not destructed when expected
Bugs item #1553819, was opened at 2006-09-06 23:26
Message generated for change (Comment added) made by peterdonis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Donis (peterdonis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Class instance apparently not destructed when expected
Initial Comment:
When an instance variable of a class with the same
name as a class variable in a base class is assigned
a value (making the class variable of the base class
invisible), the class instance does not appear to be
destructed when it should.
Here is the simplest test script I've been able to
come up with that reproduces the error, along with
its output when run from a shell prompt. I've
included the dir() commands to make sure that the
variable referencing the class instance is in fact
deleted in both cases. As you can see, the instance
of the base class gets destructed as expected, but
the instance of the derived class does not.
--- Test script ---
#!/usr/bin/env python
# Test script to see when objects are freed
class Test(object):
testfield = None
def __init__(self):
print "Initializing test object."
def __del__(self):
print "Freeing test object."
class Test2(Test):
def __init__(self):
# This masks Test.testfield
self.testfield = self.meth
Test.__init__(self)
def meth(self):
pass
print dir()
t = Test()
print dir()
del t
print dir()
t2 = Test2()
print dir()
del t2
print dir()
--- Output ---
$ python deltest.py
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
Initializing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func',
't']
Freeing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
Initializing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func',
't2']
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
--
>Comment By: Peter Donis (peterdonis)
Date: 2006-09-07 23:05
Message:
Logged In: YES
user_id=1592444
mwh's comment is correct. See attached script deltest2.py,
showing the contents of gc.garbage and how the reference
cycle can be cleared (script output shown below). Note that
I eliminated the base class and the masking of its class
field; that was a red herring. My only other question is
whether it might be worthwhile to add a sentence or two to
the description of bound method objects in the
documentation to make it clearer that you're creating a
reference to the class instance.
--- script output ---
$ python deltest2.py
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc']
Initializing test object.
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc', 't']
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc']
[]
gc: uncollectable
gc: uncollectable
gc: uncollectable
3
[<__main__.Test object at 0xb7c3f34c>, {'testfield': >},
>]
[]
0
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'g', 'gc']
Freeing test object.
--
Comment By: Michael Hudson (mwh)
Date: 2006-09-07 10:06
Message:
Logged In: YES
user_id=6656
It's a reference cycle featuring an object with a __del__ --> it ends up in
gc.garbage.
More coffee for Neal?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-07 03:19
Message:
Logged In: YES
user_id=33168
The attached variant puts this into a function and shows ref
leaks. It requires a debug build.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553819 ] Class instance apparently not destructed when expected
Bugs item #1553819, was opened at 2006-09-06 20:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Donis (peterdonis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Class instance apparently not destructed when expected
Initial Comment:
When an instance variable of a class with the same
name as a class variable in a base class is assigned
a value (making the class variable of the base class
invisible), the class instance does not appear to be
destructed when it should.
Here is the simplest test script I've been able to
come up with that reproduces the error, along with
its output when run from a shell prompt. I've
included the dir() commands to make sure that the
variable referencing the class instance is in fact
deleted in both cases. As you can see, the instance
of the base class gets destructed as expected, but
the instance of the derived class does not.
--- Test script ---
#!/usr/bin/env python
# Test script to see when objects are freed
class Test(object):
testfield = None
def __init__(self):
print "Initializing test object."
def __del__(self):
print "Freeing test object."
class Test2(Test):
def __init__(self):
# This masks Test.testfield
self.testfield = self.meth
Test.__init__(self)
def meth(self):
pass
print dir()
t = Test()
print dir()
del t
print dir()
t2 = Test2()
print dir()
del t2
print dir()
--- Output ---
$ python deltest.py
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
Initializing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func',
't']
Freeing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
Initializing test object.
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func',
't2']
['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func']
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-07 20:09
Message:
Logged In: YES
user_id=33168
Michael: coffee, no, sleep, yes. :-)
--
Comment By: Peter Donis (peterdonis)
Date: 2006-09-07 20:05
Message:
Logged In: YES
user_id=1592444
mwh's comment is correct. See attached script deltest2.py,
showing the contents of gc.garbage and how the reference
cycle can be cleared (script output shown below). Note that
I eliminated the base class and the masking of its class
field; that was a red herring. My only other question is
whether it might be worthwhile to add a sentence or two to
the description of bound method objects in the
documentation to make it clearer that you're creating a
reference to the class instance.
--- script output ---
$ python deltest2.py
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc']
Initializing test object.
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc', 't']
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'gc']
[]
gc: uncollectable
gc: uncollectable
gc: uncollectable
3
[<__main__.Test object at 0xb7c3f34c>, {'testfield': >},
>]
[]
0
['Test', '__builtins__', '__doc__', '__file__', '__name__',
'g', 'gc']
Freeing test object.
--
Comment By: Michael Hudson (mwh)
Date: 2006-09-07 07:06
Message:
Logged In: YES
user_id=6656
It's a reference cycle featuring an object with a __del__ --> it ends up in
gc.garbage.
More coffee for Neal?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-07 00:19
Message:
Logged In: YES
user_id=33168
The attached variant puts this into a function and shows ref
leaks. It requires a debug build.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo
Bugs item #1553577, was opened at 2006-09-07 04:11
Message generated for change (Comment added) made by zenzen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.datetime.now() mangles tzinfo
Initial Comment:
When using the pytz package (http://pytz.sf.net/) to create
timezone info objects datetime.datetime.now() behaves
differently than the regular datetime.datetime()
contstructor. Here's an example:
>>> import pytz
>>> info = pytz.timezone("US/Central")
>>> info
>>> import datetime
>>> now = datetime.datetime.now(tz=info)
>>> now
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18,
983849, tzinfo=info)
>>> t2
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
True
It appears that datetime.datetime.now() makes an
off-by-one-hour copy of the timezone info it was passed.
I've reproduced this on 2.4.3 and 2.5c1 as of August 17.
(It's also a little annoying that the timezone arg for
datetime.datetime.now() is "tz" while the timezone arg for
datetime.datetime() is "tzinfo". Is there a good
reason for
them to be different?)
Skip
--
Comment By: Stuart Bishop (zenzen)
Date: 2006-09-08 14:36
Message:
Logged In: YES
user_id=46639
This is a pytz issue, and a result of me abusing Tim's code
in ways he never intended. Tim is quite correct in that
there are actually several tzinfo instances under the
covers. In order to to unambiguous localtime calculations,
an extra bit of information needs to be known (the is_dst
flag in most datetime libraries). pytz uses the tzinfo
instance to store this bit of information. The side affects
of doing this are the behavior you noticed, and confusion as
constructing datetime instances needs to be done as per
pytz's README rather than the documented method in the
Python Library Reference.
>>> import pytz
>>> info = pytz.timezone('US/Central')
>>> info
>>> from datetime import datetime
>>> now = info.localize(datetime.now(), is_dst=True)
>>> now
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=)
>>> t2 = info.localize(datetime(2006, 9, 8, 11, 19, 29, 587943))
>>> t2
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
False
>>> now.tzinfo == t2.tzinfo
True
Last time I tried, it seemed impossible to support both
pytz's goals and the datetime construction API specified in
the Python Library Reference without extending the Python
datetime module (and I have yet to specify what would be
required).
If I was to add an __eq__ method to the tzinfo classes, I'm
not actually sure what the correct behavior should be.
Should US/Eastern Daylight Savings Time really equate to
US/Eastern Standard Time? Should US/Eastern Daylight Savings
Time in 2002 really equate to US/Eastern Daylight Savings
Time in 2007? The umbrella timezone might be the same, but
the UTC offsets or switchover dates are different.
The pytz bugtracker is at
https://launchpad.net/products/pytz/+bugs
--
Comment By: Tim Peters (tim_one)
Date: 2006-09-08 03:11
Message:
Logged In: YES
user_id=31435
`tzinfo` is the name of a datetime data attribute, and the
same name (i.e., "tzinfo") is generally used for arguments
that mindlessly attach a subclass of the `tzinfo` class to
an object as the value of its `tzinfo` data attribute. The
datetime constructor is an example of that. `tz` is
generally used when the time zone info is /actively
applied/, as now() does.
In contrast, the datetime constructor never makes any
attempt at conversion; if a tzinfo argument is passed, it's
merely tacked on to the datetime object.
Beyond that, I have no idea why the pytz class passed to
now() isn't showing up as the resulting datetime object's
tzinfo member. For example, that's not what happens if you
try this in the Python sandbox "datetime" directory:
>>> from US import Eastern
>>> from datetime import datetime
>>> now = datetime.now(Eastern)
>>> now
datetime.datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=)
>>> t2 = datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=Eastern)
>>> t2
datetime.datetime(2006, 9, 7, 12, 49, 48, 43,
tzinfo=)
>>> now.tzinfo == Eastern
True
>>> t2.tzinfo == Eastern
True
>>> t2.tzinfo is now.tzinfo is Eastern
True
I expect the pytz developers could shed light on that.
datetime.now(tz) with `tz` not None first mindlessly
constructs
