[ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly
Bugs item #1368515, was opened at 2005-11-28 20:10
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&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: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: dominikush (dominikush)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer: Constructor does not handle args correctly
Initial Comment:
The constructor of threading.Timer does not correctly
handle arguments passed to it, see example given. I
noted the bug in Python 2.4.1 and checked it also for
Python 2.4.2:
>>> def test(*args,**kwds): print "test: args
=",args,"and kwds =",kwds
...
>>> import threading
>>> t = threading.Timer(2,test,"hello")
>>> t.start()
>>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {}
Proposed bug fix in threading.Timer.__init__:
def __init__(self, interval, function, args=[],
kwargs={}): # bug
def __init__(self, interval, function, *args,
**kwargs):# correction
After proposed correction, rerun of test results in:
>>> t.start()
>>> test: args = ('hallo',) and kwds = {}
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-11-29 12:11
Message:
Logged In: YES
user_id=38376
The implemented behaviour is the documented behaviour (it's
the same for both Thread and Timer). You're not supposed to
"call" the Thread constructor; you're supposed to pass in
the arguments using keyword arguments. See the library
reference for details.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly
Bugs item #1368515, was opened at 2005-11-28 20:10
Message generated for change (Settings changed) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: dominikush (dominikush)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Timer: Constructor does not handle args correctly
Initial Comment:
The constructor of threading.Timer does not correctly
handle arguments passed to it, see example given. I
noted the bug in Python 2.4.1 and checked it also for
Python 2.4.2:
>>> def test(*args,**kwds): print "test: args
=",args,"and kwds =",kwds
...
>>> import threading
>>> t = threading.Timer(2,test,"hello")
>>> t.start()
>>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {}
Proposed bug fix in threading.Timer.__init__:
def __init__(self, interval, function, args=[],
kwargs={}): # bug
def __init__(self, interval, function, *args,
**kwargs):# correction
After proposed correction, rerun of test results in:
>>> t.start()
>>> test: args = ('hallo',) and kwds = {}
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-11-29 12:11
Message:
Logged In: YES
user_id=38376
The implemented behaviour is the documented behaviour (it's
the same for both Thread and Timer). You're not supposed to
"call" the Thread constructor; you're supposed to pass in
the arguments using keyword arguments. See the library
reference for details.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368827 ] bad external link in xmlrpc lib page
Bugs item #1368827, was opened at 2005-11-29 05:38 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net -- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:14 Message: Logged In: YES user_id=38376 The new permalink for the XML-RPC HOWTO seems to be: http://www.tldp.org/HOWTO/XML-RPC-HOWTO/index.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368827 ] bad external link in xmlrpc lib page
Bugs item #1368827, was opened at 2005-11-29 05:38 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net -- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:25 Message: Logged In: YES user_id=38376 The HOWTO document includes links to the XMLRPC-C site, as well as to other useful (and working) links. Just fixing the broken URL should be good enough, for now. -- Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:14 Message: Logged In: YES user_id=38376 The new permalink for the XML-RPC HOWTO seems to be: http://www.tldp.org/HOWTO/XML-RPC-HOWTO/index.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge
Bugs item #1369116, was opened at 2005-11-29 13:37 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=1369116&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: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&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-1367936 ] split() string method has two splitting algorithms
Feature Requests item #1367936, was opened at 2005-11-28 00:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&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
Submitted By: crackwitz (crackwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: split() string method has two splitting algorithms
Initial Comment:
The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say:
"If sep is not specified or is None, a different
splitting algorithm is applied."
I would like to see that behavior exposed and
consistent, i.e. stripping (new key strip=...?)
independent of whether sep is None or not.
Making it consistent could break existing code because
people already built on split()'s special behavior.
You could say strip=None by default and only keep
switching if strip==None.
I don't like this magic behavior though because there's
no reason for it to exist.
# this is now (Python v2.4.2)
' foo bar '.split() # => ['foo', 'bar']
' foo bar '.split(' ') # => ['', 'foo', '', 'bar', '']
# this is how I would like it to be
' foo bar '.split(strip=True) # => ['foo', 'bar']
' foo bar '.split(strip=False) # => ['', 'foo', '',
'bar', '']
# compatibility preserved (strip=None by default):
' foo bar '.split(strip=None) # => ['foo', 'bar']
' foo bar '.split(' ', strip=None) # => ['', 'foo',
'', 'bar', '']
what do you think?
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-29 23:10
Message:
Logged In: YES
user_id=80475
While unfortunate, this function already suffers from excess
complexity. Changing the behavior and adding backwards
compatability features would make the situation worse.
Also, the two different behaviors were not accidental.
Someone put them in for a reason. There may be orthogonal
use cases. Ideally, that need would have been been through
two different functions/methods. But, if you change the
behavior, you're likely breaking an entire class of use cases.
So, I'm -1 on mucking with this prior to Py3.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
