[ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin
Bugs item #1666952, was opened at 2007-02-23 11:29 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=1666952&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: Jurjen N.E. Bos (jneb) Assigned to: Nobody/Anonymous (nobody) Summary: terminalcommand doesn't work under Darwin Initial Comment: The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out. I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-) Quotes, spaces and backslashes are handled properly. I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin
Bugs item #1666952, was opened at 2007-02-23 11:29 Message generated for change (Comment added) made by jneb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&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: Jurjen N.E. Bos (jneb) Assigned to: Nobody/Anonymous (nobody) Summary: terminalcommand doesn't work under Darwin Initial Comment: The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out. I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-) Quotes, spaces and backslashes are handled properly. I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9. -- >Comment By: Jurjen N.E. Bos (jneb) Date: 2007-02-23 11:31 Message: Logged In: YES user_id=446428 Originator: YES O yes: forgot to mention: The bug is for Mac only, any version of Python, OS X and up. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 06:25
Message:
Logged In: YES
user_id=357491
Originator: NO
It is not a Python issue. strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.
You can write a patch if you want to cause it to blank out if it is not
supported and submit it.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 08:22
Message:
Logged In: YES
user_id=1209659
Originator: NO
Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.
>From Python docs at http://docs.python.org/lib/module-time.html :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."
Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+ for EST.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 14:26
Message:
Logged In: YES
user_id=357491
Closing as invalid since, as Georg pointed out, %z is not
supported by Python.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 09:58
Message:
Logged In: YES
user_id=849994
Note that %z isn't officially supported by Python, judging
by the docs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20
Message:
Logged In: YES
user_id=1209659
Originator: NO
But the C library does support it (and ones that don't will start - +
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).
The question is different - as the original post shows:
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.
Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 14:25
Message:
Logged In: YES
user_id=357491
Originator: NO
It is not a Python issue. strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.
You can write a patch if you want to cause it to blank out if it is not
supported and submit it.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22
Message:
Logged In: YES
user_id=1209659
Originator: NO
Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.
>From Python docs at http://docs.python.org/lib/module-time.html :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."
Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+ for EST.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26
Message:
Logged In: YES
user_id=357491
Closing as invalid since, as Georg pointed out, %z is not
supported by Python.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58
Message:
Logged In: YES
user_id=849994
Note that %z isn't officially supported by Python, judging
by the docs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file descriptor
Bugs item #803610, was opened at 2003-09-10 08:18
Message generated for change (Comment added) made by rhn_mk1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&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.3
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor
Initial Comment:
os.close(3) raises OSError: Bad file descriptor on
FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1).
Python 2.3 on Gentoo Linux 1.4 is not affected.
Interestingly, if you call os.fstat(3) first, a
subsequent call to os.close(3) succeeds.
And yes, you do need to set up fd #3.
Here is a demonstration (on FreeBSD):
[EMAIL PROTECTED] filter]$ cat test.py
import os
os.close (3)
[EMAIL PROTECTED] filter]$ python test.py 3> file
Traceback (most recent call last):
File "test.py", line 2, in ?
os.close (3)
OSError: [Errno 9] Bad file descriptor
[EMAIL PROTECTED] filter]$ cat test2.py
import os
os.fstat (3)
os.close (3)
[EMAIL PROTECTED] filter]$ python test2.py 3> file
[EMAIL PROTECTED] filter]$ (success!)
--
Comment By: rhn (rhn_mk1)
Date: 2007-02-23 16:36
Message:
Logged In: YES
user_id=1727118
Originator: NO
I have a similar problem on Ubuntu 6.06 and Python 2.5:
>>> import os, struct, fcntl
>>> lpt = open('/dev/lp0', 'rw')
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
File "", line 1, in ?
IOError: [Errno 9] Bad file descriptor
But calling os.fstat doesn't do much.
>>> lpt.fileno()
3
>>> os.fstat(3)
(8630, 8123L, 13L, 1, 0, 7, 0L, 1172241640, 1172241640, 1172241878)
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
File "", line 1, in ?
IOError: [Errno 9] Bad file descriptor
It's definitely some Python error in this, because it 3 is not a valid
file descriptore, Python shouldn't use it with open() call.
The same happens whe I try os.open().
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-09-12 07:44
Message:
Logged In: YES
user_id=21627
Ok, closing it.
--
Comment By: Syrah (syrah)
Date: 2003-09-12 03:13
Message:
Logged In: YES
user_id=827529
Well... I just got a FreeBSD 4.8 machine running. (FreeBSD
5.1 is billed as experimental.)
The problem does NOT manifest on FreeBSD 4.8. They are both
running Python 2.3. (Although the 5.1 machine has
portrevision 1, whereas the 4.8 machine has portrevision 0.
But they use the same sourcecode tarball.)
So... I'm willing to close out the bug report and assume
that the bug is in FreeBSD 5.1 somewhere. If in the future
I determine otherwise, I'll reopen the bug then.
Let me know what you think. Many thanks for all your help.
--
Comment By: Syrah (syrah)
Date: 2003-09-12 02:55
Message:
Logged In: YES
user_id=827529
I think fd6 is created in the pipe call. But why is pipe
returning 4? It should return 0 or -1, shouldn't it?
Do I need to recomiple python (so that debug info is added
to the executable) to attach the debugger to it?
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-09-12 00:06
Message:
Logged In: YES
user_id=21627
I think you are misinterpreting the ktrace output. fd 6 is
the source code file, test.py, which can be seen by looking
at the read result for fd 6. Unfortunately, there is no
corresponding open call opening the file... (there is a
second open call for test.py, when Python opens the file to
print the backtrace, but there should be an earlier call).
If this ktrace output can be trusted, it appears that Python
does not call os.open(3) at all, but immediately decides on
an error - which could happen if errno was somehow
overwritten. However, I doubt that ktrace output, since it
fails to report the first open of test.py, which I know must
be there.
I recommend to run this under a debugger, and break at
posix_open.
--
Comment By: Syrah (syrah)
Date: 2003-09-11 18:50
Message:
Logged In: YES
user_id=827529
Okay. I think I have attached a tgz file with 3 programs, 3
binary ktraces, and the ktraces converted to text files.
In all cases, the programs were run as follows:
[bash]$ program 3> file
Many thanks for your continued interest.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-09-11 08:01
Message:
Logged In: YES
user_id=2162
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:
1. In Modules/timemodule.c, the time_strftime function calls gettmarg.
2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).
3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.
4. Thus, the strftime system call fails to find or make use of time
zone information.
So it looks like no call to strftime with a supplied argument will
produce time zone information.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20
Message:
Logged In: YES
user_id=1209659
Originator: NO
But the C library does support it (and ones that don't will start - +
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).
The question is different - as the original post shows:
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.
Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 14:25
Message:
Logged In: YES
user_id=357491
Originator: NO
It is not a Python issue. strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.
You can write a patch if you want to cause it to blank out if it is not
supported and submit it.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 16:22
Message:
Logged In: YES
user_id=1209659
Originator: NO
Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.
>From Python docs at http://docs.python.org/lib/module-time.html :
"The use of %Z is now deprecated, but the %z escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries."
Most current C libraries support %z, it is in fact the preferred way to do
things, would be bad to see python reject this.
Even then - isn't the above a bug? If not supported, %z should always
provide a empty character, but not print out totally incorrect data as
+ for EST.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 21:26
Message:
Logged In: YES
user_id=357491
Closing as invalid since, as Georg pointed out, %z is not
supported by Python.
--
Comment By: Georg Brand
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Fernando P�rez (fer_perez) Date: 2007-02-23 16:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org. HTH, f -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 09:23
Message:
Logged In: YES
user_id=357491
Originator: NO
OK, but that is an issue of how much information is stored in the time
tuple. There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not. That is just an inherit shortcoming of
the time tuple. You can't fix that without adding a new field to the time
tuple itself.
I am personally not about to do that, but if someone wants to write a
patch it might be considered. But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 07:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:
1. In Modules/timemodule.c, the time_strftime function calls gettmarg.
2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).
3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.
4. Thus, the strftime system call fails to find or make use of time
zone information.
So it looks like no call to strftime with a supplied argument will
produce time zone information.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 07:20
Message:
Logged In: YES
user_id=1209659
Originator: NO
But the C library does support it (and ones that don't will start - +
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).
The question is different - as the original post shows:
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wrong data.
Someone posted code analysis in comp.lang.python explaining this, maybe
that can be used as a starting point for a patch to fix the two code paths
in Python strftime to work the same?
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 06:25
Message:
Logged In: YES
user_id=357491
Originator: NO
It is not a Python issue. strftime is a very thin wrapper to the
underlying C implementation, so if the C library doesn't support %z,
neither does Python.
You can write a patch if you want to cause it to blank out if it is not
supported and submit it.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-22 08:22
Message:
Logged In: YES
user_id=1209659
Originator: NO
Can we confirm whether this issue is not a python issue?
We are talking about small z, not capital Z.
>From Python docs at http://docs.python.org/lib/module-time.html :
"The use of %Z is now d
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by bwooster47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 18:33
Message:
Logged In: YES
user_id=1209659
Originator: NO
Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).
So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).
(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
%z The time-zone as hour offset from GMT. Required to
emit
RFC 822-conformant dates (using "%a, %d %b %Y %H:%M:%S
%z").
(GNU)
)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 17:23
Message:
Logged In: YES
user_id=357491
Originator: NO
OK, but that is an issue of how much information is stored in the time
tuple. There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not. That is just an inherit shortcoming of
the time tuple. You can't fix that without adding a new field to the time
tuple itself.
I am personally not about to do that, but if someone wants to write a
patch it might be considered. But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:
1. In Modules/timemodule.c, the time_strftime function calls gettmarg.
2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).
3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.
4. Thus, the strftime system call fails to find or make use of time
zone information.
So it looks like no call to strftime with a supplied argument will
produce time zone information.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:20
Message:
Logged In: YES
user_id=1209659
Originator: NO
But the C library does support it (and ones that don't will start - +
is ISO format, and frankly, I don't know a C library that does not support
it, though I'm sure some exist).
The question is different - as the original post shows:
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
Python has clearly used the C-library to get correct data in the first
code path through strftime, but there is a second code path that prints
wro
[ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file descriptor
Bugs item #803610, was opened at 2003-09-10 08:18
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&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.3
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor
Initial Comment:
os.close(3) raises OSError: Bad file descriptor on
FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1).
Python 2.3 on Gentoo Linux 1.4 is not affected.
Interestingly, if you call os.fstat(3) first, a
subsequent call to os.close(3) succeeds.
And yes, you do need to set up fd #3.
Here is a demonstration (on FreeBSD):
[EMAIL PROTECTED] filter]$ cat test.py
import os
os.close (3)
[EMAIL PROTECTED] filter]$ python test.py 3> file
Traceback (most recent call last):
File "test.py", line 2, in ?
os.close (3)
OSError: [Errno 9] Bad file descriptor
[EMAIL PROTECTED] filter]$ cat test2.py
import os
os.fstat (3)
os.close (3)
[EMAIL PROTECTED] filter]$ python test2.py 3> file
[EMAIL PROTECTED] filter]$ (success!)
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-23 20:52
Message:
Logged In: YES
user_id=21627
Originator: NO
rhn_mk1: I doubt it is a similar problem (entirely different operating
system). If you want to report a bug in Python, please submit a new bug
report.
However, I fail to see the bug at all. You somehow seem to believe that 3
could not be a valid file descriptor, but I cannot understand why you think
so. File descriptors 0, 1, 2 are in use for stdin, stdout, stderr, and then
the next call to open() will give you a the next file descriptor.
Python doesn't use the 3 *with* open, in fact, the file descriptor is not
a parameter to open at all. It is a *result* *from* open, i.e. a value that
the operating system returns. Please read some Unix book to understand the
concept of file descriptors better.
--
Comment By: rhn (rhn_mk1)
Date: 2007-02-23 16:36
Message:
Logged In: YES
user_id=1727118
Originator: NO
I have a similar problem on Ubuntu 6.06 and Python 2.5:
>>> import os, struct, fcntl
>>> lpt = open('/dev/lp0', 'rw')
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
File "", line 1, in ?
IOError: [Errno 9] Bad file descriptor
But calling os.fstat doesn't do much.
>>> lpt.fileno()
3
>>> os.fstat(3)
(8630, 8123L, 13L, 1, 0, 7, 0L, 1172241640, 1172241640, 1172241878)
>>> fcntl.lockf(lpt, fcntl.LOCK_EX)
Traceback (most recent call last):
File "", line 1, in ?
IOError: [Errno 9] Bad file descriptor
It's definitely some Python error in this, because it 3 is not a valid
file descriptore, Python shouldn't use it with open() call.
The same happens whe I try os.open().
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-09-12 07:44
Message:
Logged In: YES
user_id=21627
Ok, closing it.
--
Comment By: Syrah (syrah)
Date: 2003-09-12 03:13
Message:
Logged In: YES
user_id=827529
Well... I just got a FreeBSD 4.8 machine running. (FreeBSD
5.1 is billed as experimental.)
The problem does NOT manifest on FreeBSD 4.8. They are both
running Python 2.3. (Although the 5.1 machine has
portrevision 1, whereas the 4.8 machine has portrevision 0.
But they use the same sourcecode tarball.)
So... I'm willing to close out the bug report and assume
that the bug is in FreeBSD 5.1 somewhere. If in the future
I determine otherwise, I'll reopen the bug then.
Let me know what you think. Many thanks for all your help.
--
Comment By: Syrah (syrah)
Date: 2003-09-12 02:55
Message:
Logged In: YES
user_id=827529
I think fd6 is created in the pipe call. But why is pipe
returning 4? It should return 0 or -1, shouldn't it?
Do I need to recomiple python (so that debug info is added
to the executable) to attach the debugger to it?
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-09-12 00:06
Message:
Logged In: YES
user_id=21627
I think you are misinterpreting the ktrace output. fd 6 is
the source code file, test.py, which can be seen by looking
at the read result for fd 6. Unfortunately, there is no
corresponding open call opening the file... (there is a
second open call for test.py, when Python opens the file to
print the backtrace, but there should be an earlier call).
If this ktrace output can be trusted, it app
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 17:58
Message generated for change (Comment added) made by pboddie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:13
Message:
Logged In: YES
user_id=226443
Originator: NO
It's probably too late to change details of the time tuple (far too much
code now depends on it), but I have patches against 2.4.4 which provide an
additional function called localtime_tz, which itself returns a localtime
tuple containing the additional "GMT offset" field. With some modifications
to various internal functions, the "struct tm" data can be populated and
strftime can then produce the desired result.
With regard to datetime, it does support time zones, but there's a
relatively large of work required to get "aware" datetime objects. I noted
this situation in the referenced newsgroup message on this topic.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 19:33
Message:
Logged In: YES
user_id=1209659
Originator: NO
Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).
So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).
(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
%z The time-zone as hour offset from GMT. Required to
emit
RFC 822-conformant dates (using "%a, %d %b %Y %H:%M:%S
%z").
(GNU)
)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 18:23
Message:
Logged In: YES
user_id=357491
Originator: NO
OK, but that is an issue of how much information is stored in the time
tuple. There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not. That is just an inherit shortcoming of
the time tuple. You can't fix that without adding a new field to the time
tuple itself.
I am personally not about to do that, but if someone wants to write a
patch it might be considered. But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:
1. In Modules/timemodule.c, the time_strftime function calls gettmarg.
2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).
3. Consequently, any structure produced from a tuple may lack those
fields, in contrast to such structures produced directly by the system
calls.
4. Thus, the strftime system call fails to find or make use of time
zone information.
So it looks like no call to strftime wit
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 17:58
Message generated for change (Comment added) made by pboddie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:26
Message:
Logged In: YES
user_id=226443
Originator: NO
See patch #1667546 for a somewhat tested implementation of the changes
mentioned below.
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 00:13
Message:
Logged In: YES
user_id=226443
Originator: NO
It's probably too late to change details of the time tuple (far too much
code now depends on it), but I have patches against 2.4.4 which provide an
additional function called localtime_tz, which itself returns a localtime
tuple containing the additional "GMT offset" field. With some
modifications to various internal functions, the "struct tm" data can be
populated and strftime can then produce the desired result.
With regard to datetime, it does support time zones, but there's a
relatively large of work required to get "aware" datetime objects. I noted
this situation in the referenced newsgroup message on this topic.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 19:33
Message:
Logged In: YES
user_id=1209659
Originator: NO
Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).
So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).
(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
%z The time-zone as hour offset from GMT. Required to
emit
RFC 822-conformant dates (using "%a, %d %b %Y %H:%M:%S
%z").
(GNU)
)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 18:23
Message:
Logged In: YES
user_id=357491
Originator: NO
OK, but that is an issue of how much information is stored in the time
tuple. There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not. That is just an inherit shortcoming of
the time tuple. You can't fix that without adding a new field to the time
tuple itself.
I am personally not about to do that, but if someone wants to write a
patch it might be considered. But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 16:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I can see, the reason for the differing behaviour of
time.strftime is due to the way any supplied tuple is processed:
1. In Modules/timemodule.c, the time_strftime function calls gettmarg.
2. In gettmarg, various fields of struct tm are filled in, except for
tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h).
[ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 06:48 Message generated for change (Comment added) made by pboddie 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: Paul Boddie (pboddie) Date: 2007-02-24 01:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560794 ] strftime('%z') behaving differently with/without time arg.
Bugs item #1560794, was opened at 2006-09-18 16:53
Message generated for change (Comment added) made by pboddie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&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: Knut Aksel Røysland (knutroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime('%z') behaving differently with/without time arg.
Initial Comment:
According to the documentation, time.strftime will use
time.localtime, when no time tuple is provided as
argument. So, I wonder if it is desired behavior that
%z returns different values in the following two cases:
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z')
'2006-09-18T16:12:05+0200'
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z', time.localtime())
'2006-09-18T16:12:05+'
The first behavior is what I am looking for.
I realize that %z is not documented, so maybe it should
be rejected instead of giving surprising results, like
above.
This behavior is observed on different Linux systems
under different versions of Python, e.g. on Ubuntu
Dapper Drake running Python 2.4.3.
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-24 01:33
Message:
Logged In: YES
user_id=226443
Originator: NO
See patch #1667546 and related bug #1493676 (with discussion).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 00:08 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- Comment By: Jerry Seutter (jseutter) Date: 2007-02-23 23:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: [EMAIL PROTECTED]:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: [EMAIL PROTECTED]:~/code/python $ python bug_1666807.py Version info: (2, 4, 3, 'final', 0) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /usr/lib/python2.4/inspect.py Do these match? True OK However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get: [prompt goes here python]$ python bug_1666807.py Version info: (2, 2, 3, 'final', 0) File for `inspect` : /xxx//PythonHome/lib/python2.2/inspect.py File for `inspect.iscode`: /xxx//Python-2.2/lib/python2.2/inspect.py Do these match? 0 BUG - this is a bug in this version of Python Is a symlink involved on the system where you saw this behaviour? -- Comment By: Fernando P�rez (fer_perez) Date: 2007-02-23 09:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done un
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Fernando P�rez (fer_perez) Date: 2007-02-24 07:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! -- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 06:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: [EMAIL PROTECTED]:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: [EMAIL PROTECTED]:~/code/python $ pyt
