[ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 13:48 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). -- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternative is to do date arithmetic on the results of localtime() and gmtime(), as you say. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 23:48 Message: Logged In: YES user_id=6380 Originator: NO Hm I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 18:09 Message: Logged In: YES user_id=146903 O
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 10:21 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-03 00:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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 22:18
Message generated for change (Settings changed) made by vsajip
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: Closed
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-05 04: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 21: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
[ python-Feature Requests-1674032 ] Make threading.Event().wait(timeout=3) return isSet
Feature Requests item #1674032, was opened at 2007-03-05 15:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674032&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: Threads Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Make threading.Event().wait(timeout=3) return isSet Initial Comment: Currently the wait method on threading.Event always returns None, even if a timeout is given and the event is not set. This means that there is no way to determine whether the wait method returned because the event was set, or because the timeout period expired, without querying the event status again: x.wait(3) if x.isSet(): # do stuff Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out It would be great to be able to do: if x.wait(3): # do stuff This should also not affect any existing code as it shouldn't be relying on the return value from x.wait anyway -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674032&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines
Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> -- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines
Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by oneg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> -- >Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 17:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 =>/usr/lib/librt.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libstdc++.so.5 =>/usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 -- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674223 ] Unicode xmlcharrefreplace produces backslash not xml style.
Bugs item #1674223, was opened at 2007-03-05 09:11
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=1674223&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stanley Sokolow (odontomatix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode xmlcharrefreplace produces backslash not xml style.
Initial Comment:
In Python 2.4.2 and 2.5, and maybe other versions too, the unicode string
encoder for producing xml style unicode output (example, © for copyright
symbol) produces the wrong style -- it produces backslash encoding (\xa9 for
same copyright unicode character).
Example at Python shell:
u'\u2122'.encode('unicode_escape','xmlcharrefreplace')
should produce: ™
but it produces \u2122
The same happens when it is used in a program. The print output of the encoded
unicode contains backslash encodings as though the method 'backslashreplace'
had been used.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674223 ] Unicode xmlcharrefreplace produces backslash not xml style.
Bugs item #1674223, was opened at 2007-03-05 18:11
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&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: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Stanley Sokolow (odontomatix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode xmlcharrefreplace produces backslash not xml style.
Initial Comment:
In Python 2.4.2 and 2.5, and maybe other versions too, the unicode string
encoder for producing xml style unicode output (example, © for copyright
symbol) produces the wrong style -- it produces backslash encoding (\xa9 for
same copyright unicode character).
Example at Python shell:
u'\u2122'.encode('unicode_escape','xmlcharrefreplace')
should produce: ™
but it produces \u2122
The same happens when it is used in a program. The print output of the encoded
unicode contains backslash encodings as though the method 'backslashreplace'
had been used.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2007-03-05 18:54
Message:
Logged In: YES
user_id=89016
Originator: NO
u'\u2122'.encode('unicode_escape','xmlcharrefreplace') produces \u2122
because that's the way the unicode_escape codec outputs unicode codepoints.
For unicode_escape the xmlcharrefreplace error handler never kicks in. If
you want the error handler to kick in, you have to use an encoding that
doesn't support the character you want to encode. The best candidate is
probably ascii:
>>> u"\u2122".encode("ascii", "xmlcharrefreplace")
>>> '™'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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-1674315 ] funcName and module incorrectly reported in logging
Feature Requests item #1674315, was opened at 2007-03-05 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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-1674315 ] funcName and module incorrectly reported in logging
Feature Requests item #1674315, was opened at 2007-03-05 11:31 Message generated for change (Comment added) made by wraithgar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 -- >Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 11:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip <[EMAIL PROTECTED]>" __status__ = "production" __version__ = "0.4.9.9" __date__= "06 February 2006" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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-1674315 ] funcName and module incorrectly reported in logging
Feature Requests item #1674315, was opened at 2007-03-05 11:31 Message generated for change (Comment added) made by wraithgar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 -- >Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 12:28 Message: Logged In: YES user_id=725363 Originator: YES this appears to be a dirty logging/__init__.pyc file in the debian package. Removing that file fixes this problem. -- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 11:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip <[EMAIL PROTECTED]>" __status__ = "production" __version__ = "0.4.9.9" __date__= "06 February 2006" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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-1674315 ] funcName and module incorrectly reported in logging
Feature Requests item #1674315, was opened at 2007-03-05 19:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&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: None Priority: 5 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 21:45 Message: Logged In: YES user_id=849994 Originator: NO Closing here then, you may want to file a bug (or search if someone else already did) in Debian's tracker. -- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 20:28 Message: Logged In: YES user_id=725363 Originator: YES this appears to be a dirty logging/__init__.pyc file in the debian package. Removing that file fixes this problem. -- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 19:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip <[EMAIL PROTECTED]>" __status__ = "production" __version__ = "0.4.9.9" __date__= "06 February 2006" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines
Bugs item #1672332, was opened at 2007-03-02 11:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 21:46 Message: Logged In: YES user_id=849994 Originator: NO I seem to remember that float pickling has been overhauled for 2.5, could you try with a 2.5 Python and report the results? -- Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 16:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 =>/usr/lib/librt.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libstdc++.so.5 =>/usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 -- Comment By: Santiago Gala (sgala) Date: 2007-03-05 16:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633621 ] curses should reset curses.{COLS, LINES} when term. resized
Bugs item #1633621, was opened at 2007-01-11 18:38
Message generated for change (Comment added) made by geekmug
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized
Initial Comment:
[forwarded from http://bugs.debian.org/366698]
The curses module does not reset curses.COLS and curses.LINES when the terminal
is resized.
--
Comment By: Scott Dial (geekmug)
Date: 2007-03-05 17:14
Message:
Logged In: YES
user_id=383208
Originator: NO
I've reviewed this patch and I believe it to be the correct patch. I
believe it would be prudent to add a test case for this. I'm unable to
attach, but here is a link to a patch for that:
http://scottdial.com/python-dev/curses-test.patch
--
Comment By: Walter Dörwald (doerwalter)
Date: 2007-02-12 13:59
Message:
Logged In: YES
user_id=89016
Originator: NO
Here's a patch that implements the requested changes.
File Added: diff.txt
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674503 ] execfile() response to syntax errors
Bugs item #1674503, was opened at 2007-03-05 16:38
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=1674503&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Griffitts (jcgriffitts)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile() response to syntax errors
Initial Comment:
Python 2.5 seems to have an anomaly when execfile() encounters syntax errors.
If I use execfile() to execute a file that contains a syntax error, it throws
the expected SyntaxError exception but does not close the source file. Since
the file is still open, an external program can't modify it to fix the syntax
error.
I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I
tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen
there.
spam.py -
[intentional-syntax-error)
--
The following is my console session:
--
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> execfile('spam.py')
Traceback (most recent call last):
File "", line 1, in
File "spam.py", line 1
[intentional-syntax-error)
^
SyntaxError: invalid syntax
>>>
--
At this point file spam.py remains open until Python exits. There's no obvious
way to close the file from within the script because there is no file object.
Under Windows, this prevents spam.py from being edited,
renamed, or deleted.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 10:21 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 08:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 02:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-03 00:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674503 ] execfile() response to syntax errors
Bugs item #1674503, was opened at 2007-03-05 16:38
Message generated for change (Comment added) made by jcgriffitts
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&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: 3
Private: No
Submitted By: Jonathan Griffitts (jcgriffitts)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile() response to syntax errors
Initial Comment:
Python 2.5 seems to have an anomaly when execfile() encounters syntax errors.
If I use execfile() to execute a file that contains a syntax error, it throws
the expected SyntaxError exception but does not close the source file. Since
the file is still open, an external program can't modify it to fix the syntax
error.
I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I
tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen
there.
spam.py -
[intentional-syntax-error)
--
The following is my console session:
--
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> execfile('spam.py')
Traceback (most recent call last):
File "", line 1, in
File "spam.py", line 1
[intentional-syntax-error)
^
SyntaxError: invalid syntax
>>>
--
At this point file spam.py remains open until Python exits. There's no obvious
way to close the file from within the script because there is no file object.
Under Windows, this prevents spam.py from being edited,
renamed, or deleted.
--
>Comment By: Jonathan Griffitts (jcgriffitts)
Date: 2007-03-05 18:17
Message:
Logged In: YES
user_id=796443
Originator: YES
Easy work-around: use exec(file('spam.py')) instead of execfile('spam.py')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674555 ] Python 2.5 testsuite sys.path contains system dirs
Bugs item #1674555, was opened at 2007-03-06 01: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=1674555&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Theodoros V. Kalamatianos (nyb) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 testsuite sys.path contains system dirs Initial Comment: While trying to debug a testsuite crash, I discovered that a faulty module from the system wide directories was being picked up. The module in question was sgmlop.so, which was being imported by Lib/xmlrpclib.py. (BTW isn't it considered bad form for a module within the Python distribution to load a third party module?) In my opinion, the main issue here is that while testing a Python build, no out-of-tree modules should be able to be imported in any case, in order to avoid pollution of the testing environment. Yet AFAICT, there is no place where the sys.path is manipulated to remove the out-of-tree directories. I believe that the proper thing to do would be to allow only the build tree module directories in the search path. Any comments/patches would be appreciated. Best Regards, Theodoros Kalamatianos -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674555&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663392 ] PyType_IsSubtype segfaults
Bugs item #1663392, was opened at 2007-02-19 03:42 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: navtej singh (nsbuttar) Assigned to: Nobody/Anonymous (nobody) Summary: PyType_IsSubtype segfaults Initial Comment: It seems the issue is similar to bug#560215. I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library. PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00) attaching the gdb bt as attachment. -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-05 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-19 04:21 Message: Logged In: YES user_id=849994 Originator: NO I don't think this is a bug in the core. Most Python API functions may not be passed NULL pointers; it is expected that the user of the function checks for that condition. -- Comment By: navtej singh (nsbuttar) Date: 2007-02-19 03:46 Message: Logged In: YES user_id=847825 Originator: YES Additional Information cat /etc/gentoo-release ; uname -r; python -V Gentoo Base System release 1.12.9 2.6.19-suspend2-r2 Python 2.4.4 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&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-1043446 ] Interpreter should be interruptable everywhere
Feature Requests item #1043446, was opened at 2004-10-08 23:26
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&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: None
>Status: Closed
Resolution: None
Priority: 3
Private: No
Submitted By: Jp Calderone (kuran)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Interpreter should be interruptable everywhere
Initial Comment:
import itertools
list(itertools.repeat('x'))
^C will not interrupt this.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 07:40
Message:
Logged In: YES
user_id=849994
Turning into a feature request.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 17:15
Message:
Logged In: YES
user_id=1188172
What to do here?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-15 17:25
Message:
Logged In: YES
user_id=593130
Killing the interpreter will, of course, interrupt anything ;-).
The ability to ask the interpreter, via an alternate non-code
communication channel, to stop doing what one just
requested via the normal code input channel, is an
implementation-specific metafeature independent of the
language definition. So I see this as a CPython feature-
expansion request rather than a bug report.
If the CPython interpreter documentation promises that ^C
or whatever will always grab the interpreter's attention, then
that overpromise is a bug that should be modified.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-10 03:06
Message:
Logged In: YES
user_id=80475
FWIW, there are many variations of this theme using almost
anything accepting an iterable input (dict.fromkeys, tuple,
set, etc) paired with any long running or infinite iterator
(itertools.count, xrange(sys.maxint), etc). Even the
tp_print slot can get caught up in emitting oversized output
in a way that is uninterruptable.
I don't see a clean way of teaching all of these functions
to periodically check for signals, and either handle them,
raise an exception or continue. Fixing this could muck-up
and complicate a bunch of otherwise clean code.
Still, it would be nice if everything were interruptable.
I'm just not sure it's worth it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
