[ python-Bugs-1673403 ] date-datetime comparison doesn't work
Bugs item #1673403, was opened at 2007-03-04 11: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=1673403&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: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673405 ] None-datetime comparison doesn't work
Bugs item #1673405, was opened at 2007-03-04 11:52 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=1673405&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: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: None-datetime comparison doesn't work Initial Comment: Comparing None to the objects in the datetime module throws an exception. This violates the general rule in Python that None compares "less than" everything else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673409 ] datetime module missing some important methods
Bugs item #1673409, was opened at 2007-03-04 11:59 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=1673409&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: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module missing some important methods Initial Comment: The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00). There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back. In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/100). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673409&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673405 ] None-datetime comparison doesn't work
Bugs item #1673405, was opened at 2007-03-04 06:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&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: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: None-datetime comparison doesn't work Initial Comment: Comparing None to the objects in the datetime module throws an exception. This violates the general rule in Python that None compares "less than" everything else. -- >Comment By: Tim Peters (tim_one) Date: 2007-03-04 13:48 Message: Logged In: YES user_id=31435 Originator: NO There is no such rule, and it's quite deliberate that the newer types (like datetime objects and sets) raise an exception on mixed-type inequality comparisons. For older types, the result of inequality comparison with None isn't defined by the language, and the outcome does vary across CPython releases. Rejecting this, since the code is working as designed and documented (see, e.g., footnote (4) in the datetime docs: "Note: In order to stop comparison from falling back to the default scheme of comparing object addresses, datetime comparison normally raises TypeError if the other comparand isn't also a datetime object. However, ..."). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 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=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669498, was opened at 2007-02-26 15:18
Message generated for change (Settings changed) made by murrayg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&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: 5
Private: No
Submitted By: Glenn Murray (murrayg)
Assigned to: Vinay Sajip (vsajip)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
>Comment By: Glenn Murray (murrayg)
Date: 2007-03-04 21:27
Message:
Logged In: YES
user_id=584266
Originator: YES
Hi Vinay,
Good call, recompiling the /usr/lib/python2.4/logging/*.pyc files
fixed the problem.
Thanks,
Glenn
--
Comment By: Vinay Sajip (vsajip)
Date: 2007-02-28 14:15
Message:
Logged In: YES
user_id=308438
Originator: NO
Can you please delete all logging .pyc files before running the test
script? The problem appears to be caused by the __file__ value stored
inside a .pyc being different (possibly due to symlink changes) from the
source file it was originally compiled from.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
