[ python-Feature Requests-1296581 ] datetime.replace could take a dict
Feature Requests item #1296581, was opened at 2005-09-20 18:56 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&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: Invalid Priority: 1 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.replace could take a dict Initial Comment: Python 2.4.1. datetime.replace uses its kwargs to specify the fields, which I found a bit surprising. It could also take an equivalent dict. (Failing that, it could have a fuller docstring.) What I was actually trying to do was round to the nearest half hour. floor and ceil methods taking a timedelta would be nice too. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-16 04:20 Message: Logged In: YES user_id=80475 Any function accepting keyword arguments can already be called with an equivalent dict using the ** notation (similar to tuple unpacking): >>> from datetime import date >>> d = dict(day=26, year=2004) >>> date(2001, 1, 2).replace(**d) datetime.date(2004, 1, 26) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327110 ] wrong TypeError traceback in generator expressions
Bugs item #1327110, was opened at 2005-10-14 21:25
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&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: Yusuke Shinyama (euske)
Assigned to: Raymond Hettinger (rhettinger)
Summary: wrong TypeError traceback in generator expressions
Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
File "", line 1, in bar
ValueError: bar!
--
>Comment By: Michael Hudson (mwh)
Date: 2005-10-16 13:25
Message:
Logged In: YES
user_id=6656
Oh come on, this is just a bad idea (esp so in this case; the error message
that you get for e.g. ''.join(1) is "iteration over non-sequence" which pretty
clear -- I think this may have improved since the introduction of the
PySequence_Fast API).
Here's a patch (with tests) that I'll check in after Jeremy has merged the
ast-branch unless you talk very fast :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 21:57
Message:
Logged In: YES
user_id=80475
This isn't an error -- it was a design decision. It is not
unusual to have a situation arise in Python where a high
level routine competes with a low level routine over which
is in the best position to provide the most useful error
message. The low level routine typically knows the
proximate cause. The high level routine typically knows
what the user was trying to do.
In the case of str.join(), the high level routine usually
makes the most informative error message; however, it is
sometimes off the mark.
Will revisit the design decision to see if it should be
changed. Lowering the priority because the code is working
as designed, the error type is correct, and it is not clear
that any change is warranted.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple locales
Bugs item #1158490, was opened at 2005-03-07 20:11 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&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: Open Resolution: None Priority: 3 Submitted By: mixedpuppy (mixedpuppy) Assigned to: M.-A. Lemburg (lemburg) Summary: locale fails if LANGUAGE has multiple locales Initial Comment: The locale module does not correctly handle the LANGUAGE environment variable if it contains multiple settings. Example: LANGUAGE="en_DK:en_GB:en_US:en" Note, en_DK does not exist in locale_alias In normalize, the colons are replaced with dots, which is incorrect. getdefaultlocal should seperate these first, then try each one until it finds one that works, or fails on all. GLIBC documentation: http://www.delorie.com/gnu/docs/glibc/libc_138.html "While for the LC_xxx variables the value should consist of exactly one specification of a locale the LANGUAGE variable's value can consist of a colon separated list of locale names." Testing this is simple, just set your LANGUAGE environment var to the above example, and use locale.getdefaultlocal() > export LANGUAGE="en_DK:en_GB:en_US:en" > python ActivePython 2.4 Build 244 (ActiveState Corp.) based on Python 2.4 (#1, Feb 9 2005, 19:33:15) [GCC 3.3.1 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 344, in getdefaultlocale return _parse_localename(localename) File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: en_DK:en_GB:en_US:en >>> -- Comment By: Bernhard Reiter (ber) Date: 2005-10-16 15:26 Message: Logged In: YES user_id=113859 Hi Marc-Andre, do you mean that the current CVS version will return (None, None) always or only for special LANUGUAGE settings? I do not have an overview about other problems with the LANGUAGE variable (from gettext), but adding support for the proper parsing of the colons and the testing seems a good thing to do from my perspective. Getdefaultlocale() will not get called often and if additional information can be used from the LANGUAGE variable, this will be benefical to the applications. Anyway, just my 0,02 Euro-Cents. Bernhard R. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-26 20:23 Message: Logged In: YES user_id=38388 The current CVS version returns this value: >>> import locale >>> locale.getdefaultlocale() (None, None) Given all the problems with the LANGUAGE environment variable (which is a gettext() only thing) I'm inclined to remove support for it altogether. -- Comment By: Bernhard Herzog (bernhard) Date: 2005-09-26 18:43 Message: Logged In: YES user_id=2369 Another consequence of this bug is that even if getdefaultlocale does not fail with an exception, it may return an invalid value for the encoding. E.g. one thuban user had LANGUAGE=pt_BR:pt_PT:pt getdefaultlocale did not raise an exception, but return "pt_pt" as the encoding because the normalized form of the above value was pt_BR.pt_pt and the locale module assumes that the part after the "." is the encoding. -- Comment By: mixedpuppy (mixedpuppy) Date: 2005-03-10 22:50 Message: Logged In: YES user_id=1234417 IMHO the proper behaviour is to split on the colon, then try each one from start to finish until there is a success, or all fail. For example, if you just try en_DK, you will get a failure since that is not in locale.locale_alias, but en_GB or en_US would succeed. -- Comment By: Serge Orlov (sorlov) Date: 2005-03-10 19:48 Message: Logged In: YES user_id=1235914 The docs for getdefaultlocale state that it follows the GNU gettext search path. OTOH gettext can return result from any of catalogs en_DK:en_GB:en_US:en, it depends on the content of the message. So maybe getdefaultlocale should just pick up the first value from LANGUAGE ? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-03-10 16:43 Message: Logged In: YES user_id=38388 The URL you gave does state that LANGUAGE can take mulitple entries separated by colons. However, I fail to see how to ch
[ python-Bugs-1327110 ] wrong TypeError traceback in generator expressions
Bugs item #1327110, was opened at 2005-10-14 15:25
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&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: Yusuke Shinyama (euske)
>Assigned to: Nobody/Anonymous (nobody)
Summary: wrong TypeError traceback in generator expressions
Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
File "", line 1, in bar
ValueError: bar!
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-16 09:24
Message:
Logged In: YES
user_id=80475
I don't think this should be backported.
--
Comment By: Michael Hudson (mwh)
Date: 2005-10-16 07:25
Message:
Logged In: YES
user_id=6656
Oh come on, this is just a bad idea (esp so in this case; the error message
that you get for e.g. ''.join(1) is "iteration over non-sequence" which pretty
clear -- I think this may have improved since the introduction of the
PySequence_Fast API).
Here's a patch (with tests) that I'll check in after Jeremy has merged the
ast-branch unless you talk very fast :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 15:57
Message:
Logged In: YES
user_id=80475
This isn't an error -- it was a design decision. It is not
unusual to have a situation arise in Python where a high
level routine competes with a low level routine over which
is in the best position to provide the most useful error
message. The low level routine typically knows the
proximate cause. The high level routine typically knows
what the user was trying to do.
In the case of str.join(), the high level routine usually
makes the most informative error message; however, it is
sometimes off the mark.
Will revisit the design decision to see if it should be
changed. Lowering the priority because the code is working
as designed, the error type is correct, and it is not clear
that any change is warranted.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327110 ] wrong TypeError traceback in generator expressions
Bugs item #1327110, was opened at 2005-10-14 21:25
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&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: Yusuke Shinyama (euske)
>Assigned to: Michael Hudson (mwh)
Summary: wrong TypeError traceback in generator expressions
Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
File "", line 1, in bar
ValueError: bar!
--
>Comment By: Michael Hudson (mwh)
Date: 2005-10-16 15:28
Message:
Logged In: YES
user_id=6656
Agreed.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-16 15:24
Message:
Logged In: YES
user_id=80475
I don't think this should be backported.
--
Comment By: Michael Hudson (mwh)
Date: 2005-10-16 13:25
Message:
Logged In: YES
user_id=6656
Oh come on, this is just a bad idea (esp so in this case; the error message
that you get for e.g. ''.join(1) is "iteration over non-sequence" which pretty
clear -- I think this may have improved since the introduction of the
PySequence_Fast API).
Here's a patch (with tests) that I'll check in after Jeremy has merged the
ast-branch unless you talk very fast :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 21:57
Message:
Logged In: YES
user_id=80475
This isn't an error -- it was a design decision. It is not
unusual to have a situation arise in Python where a high
level routine competes with a low level routine over which
is in the best position to provide the most useful error
message. The low level routine typically knows the
proximate cause. The high level routine typically knows
what the user was trying to do.
In the case of str.join(), the high level routine usually
makes the most informative error message; however, it is
sometimes off the mark.
Will revisit the design decision to see if it should be
changed. Lowering the priority because the code is working
as designed, the error type is correct, and it is not clear
that any change is warranted.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327971 ] HTTPResponse instance has no attribute 'fileno'
Bugs item #1327971, was opened at 2005-10-16 10:41
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=1327971&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: Kevin Dwyer (kevindication)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse instance has no attribute 'fileno'
Initial Comment:
In python2.3, the following code works. In python2.4
it fails with an AttributeError:
>>> import urllib2
>>> request = urllib2.Request("http://pheared.net";)
>>> opener = urllib2.build_opener()
>>> r = opener.open(request)
>>> r.fileno()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/socket.py", line 246, in fileno
return self._sock.fileno()
AttributeError: HTTPResponse instance has no attribute
'fileno'
Without a fileno it's hard to do things like select.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327971&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327971 ] HTTPResponse instance has no attribute 'fileno'
Bugs item #1327971, was opened at 2005-10-16 10:41
Message generated for change (Comment added) made by kevindication
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327971&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: Kevin Dwyer (kevindication)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse instance has no attribute 'fileno'
Initial Comment:
In python2.3, the following code works. In python2.4
it fails with an AttributeError:
>>> import urllib2
>>> request = urllib2.Request("http://pheared.net";)
>>> opener = urllib2.build_opener()
>>> r = opener.open(request)
>>> r.fileno()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/socket.py", line 246, in fileno
return self._sock.fileno()
AttributeError: HTTPResponse instance has no attribute
'fileno'
Without a fileno it's hard to do things like select.
--
>Comment By: Kevin Dwyer (kevindication)
Date: 2005-10-16 11:08
Message:
Logged In: YES
user_id=285914
I think the problem is at line 1010 in urllib2.py.
--- urllib2.py-orig 2005-10-16 11:04:30.0 -0400
+++ urllib2.py 2005-10-16 11:05:02.0 -0400
@@ -1007,7 +1007,7 @@
# out of socket._fileobject() and into a base class.
r.recv = r.read
-fp = socket._fileobject(r)
+fp = socket._fileobject(r.fp)
resp = addinfourl(fp, r.msg, req.get_full_url())
resp.code = r.status
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327971&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327971 ] HTTPResponse instance has no attribute 'fileno'
Bugs item #1327971, was opened at 2005-10-16 10:41
Message generated for change (Comment added) made by kevindication
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327971&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: Kevin Dwyer (kevindication)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPResponse instance has no attribute 'fileno'
Initial Comment:
In python2.3, the following code works. In python2.4
it fails with an AttributeError:
>>> import urllib2
>>> request = urllib2.Request("http://pheared.net";)
>>> opener = urllib2.build_opener()
>>> r = opener.open(request)
>>> r.fileno()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/socket.py", line 246, in fileno
return self._sock.fileno()
AttributeError: HTTPResponse instance has no attribute
'fileno'
Without a fileno it's hard to do things like select.
--
>Comment By: Kevin Dwyer (kevindication)
Date: 2005-10-16 11:23
Message:
Logged In: YES
user_id=285914
Actually that's not entirely correct. The fix is probably
more like the other hack in there:
--- urllib2.py-orig 2005-10-16 11:19:34.0 -0400
+++ urllib2.py 2005-10-16 11:22:30.0 -0400
@@ -1007,6 +1007,7 @@
# out of socket._fileobject() and into a base class.
r.recv = r.read
+r.fileno = r.fp.fileno
fp = socket._fileobject(r)
resp = addinfourl(fp, r.msg, req.get_full_url())
--
Comment By: Kevin Dwyer (kevindication)
Date: 2005-10-16 11:08
Message:
Logged In: YES
user_id=285914
I think the problem is at line 1010 in urllib2.py.
--- urllib2.py-orig 2005-10-16 11:04:30.0 -0400
+++ urllib2.py 2005-10-16 11:05:02.0 -0400
@@ -1007,7 +1007,7 @@
# out of socket._fileobject() and into a base class.
r.recv = r.read
-fp = socket._fileobject(r)
+fp = socket._fileobject(r.fp)
resp = addinfourl(fp, r.msg, req.get_full_url())
resp.code = r.status
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327971&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189216 ] zipfile module and 2G boundary
Bugs item #1189216, was opened at 2005-04-24 21:08 Message generated for change (Comment added) made by mdcowles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189216&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 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile module and 2G boundary Initial Comment: The zipfile module currently can not handle archives that have file headers that begin past the 2**31 byte boundary. This is really bug #679953 all over again -- that fix didn't solve all of the problem. Patch to CVS HEAD attached, backport candidate to 2.4.2 and 2.3.6. -- Comment By: Matthew Cowles (mdcowles) Date: 2005-10-16 14:18 Message: Logged In: YES user_id=198518 [From a post to python-help] Related to this is that zipfile raises an exception on creating a file that's too big. It seems that the limitation should be documented or removed. This is from the message to python-help: python version 4.2. the class zipfile in the module zipfile is unable to .close() a file bigger than 2^32-1 (or whatever) bytes. Traceback (most recent call last): File "bk.py", line 12, in ? zf.close() File "C:\Python24\lib\zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert to int -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__
Bugs item #1328278, was opened at 2005-10-17 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&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: Josh Marshall (jpmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ taking priority over __getitem__ Initial Comment: When creating a class that uses __getitem__ to implement slicing, if __getattr__ is also implemented, slicing will fail. This is due to the (deprecated) __getslice__ method being called before __getitem__. The attached file demonstrates this. If __getitem__ is implemented on its own, all is rosy. When we add __getattr__ and do not raise an AttributeError when __getslice__ is searched for, the slicing fails. If we raise this AttributeError, __getitem__ is called next. The only other reference I could find to this bug is on the jython mailing list, from 2003: http://sourceforge.net/mailarchive/forum.php? thread_id=2350972&forum_id=5586 My question is; why is __getslice__ called before __getitem__? I assumed that because it is deprecated, it would be the last resort for a slicing. Is this planned to be fixed, or is there existing behaviour that is reliant on it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
