[ python-Bugs-1714773 ] python throws an error when unpacking bz2 file
Bugs item #1714773, was opened at 2007-05-08 17:23 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=1714773&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: runnig (runnig) Assigned to: Nobody/Anonymous (nobody) Summary: python throws an error when unpacking bz2 file Initial Comment: C:\work\python>c:\work\python\25\py.exe Python 2.5 (r25:51908, Feb 13 2007, 14:33:20) [MSC v.1400 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. C:\work\python>ez_setup.py wxpython Searching for wxpython Reading http://cheeseshop.python.org/pypi/wxpython/ Couldn't find index page for 'wxpython' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://cheeseshop.python.org/pypi/ Reading http://cheeseshop.python.org/pypi/wxPython/2.6.3.2 Reading http://wxPython.org/ Reading http://wxPython.org/download.php Best match: wxPython src-2.8.3.0 Downloading http://prdownloads.sourceforge.net/wxpython/wxPython-src-2.8.3.0.tar.bz2 Processing wxPython-src-2.8.3.0.tar.bz2 I think, when unpacking bz2, an error occurs and windows shows an error about "python.exe has encountered a problem and needs to close" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714773&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by iszegedi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50
Message:
Logged In: YES
user_id=1772412
Originator: NO
I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.
To response to the remarks from siemer:
1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard).
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended".
Nevertheless, I can accept that since it is not implemented neither in
regular UNIX shell utilities nor in C system libraries, we may opt for a
"common sense solution" meaning that
os.path.normpath('/etc/passwd/') --> '/etc/passwd/'
In fact, this is pretty simple to implement as I have already given an
example; the original proposal needs to be modified by one character only:
Instead of adding '/.' to the end of the path, just add a '/':
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/'
3./ path = path.rstrip()
This doesn't remove any significant whitespaces from the pathname, as far
as I see. It only removes the trailing whitespaces from the pathname, the
rest is going to stay as is. An example:
In the current posixpath module, if you use spaces at the end of the
pathname string, it will be displayed like:
os.path.normpath('/etc/password/ ') ---> '/etc/passwd/'
if we use rstrip() as suggested, then the result would be:
os.path.normpath('/etc/password/ ') ---> '/etc/passwd/'
which makes more sense to me.
But for instance:
os.path.normpath('/etc/ /passwd/') ---> '/etc/ /passwd/'
Istvan
--
Comment By: jos (josm)
Date: 2007-05-06 11:31
Message:
Logged In: YES
user_id=1776568
Originator: NO
Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.
siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.
According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."
So the TODO list would be
1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit
Correct Me If I'm Wrong.
--
Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15
Message:
Logged In: YES
user_id=150699
Originator: YES
1) I (submitter) didn't specify what I expected to see:
os.path.normpath('/etc/passwd/') --> '/etc/passwd/'
So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...
2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.
And I think everybody agrees that -
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by siemer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
>Comment By: Robert Siemer (siemer)
Date: 2007-05-08 16:24
Message:
Logged In: YES
user_id=150699
Originator: YES
Istvan, you seem to think that trailing whitespace is not significant.
That assumption is wrong. ' ' is a perfect file name... Apart from spaces
even newlines, etc. are okay - and not the same.
I'm also "working" on a good path name handling essay. (-:
Robert
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50
Message:
Logged In: YES
user_id=1772412
Originator: NO
I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.
To response to the remarks from siemer:
1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard).
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended".
Nevertheless, I can accept that since it is not implemented neither in
regular UNIX shell utilities nor in C system libraries, we may opt for a
"common sense solution" meaning that
os.path.normpath('/etc/passwd/') --> '/etc/passwd/'
In fact, this is pretty simple to implement as I have already given an
example; the original proposal needs to be modified by one character only:
Instead of adding '/.' to the end of the path, just add a '/':
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/'
3./ path = path.rstrip()
This doesn't remove any significant whitespaces from the pathname, as far
as I see. It only removes the trailing whitespaces from the pathname, the
rest is going to stay as is. An example:
In the current posixpath module, if you use spaces at the end of the
pathname string, it will be displayed like:
os.path.normpath('/etc/password/ ') ---> '/etc/passwd/'
if we use rstrip() as suggested, then the result would be:
os.path.normpath('/etc/password/ ') ---> '/etc/passwd/'
which makes more sense to me.
But for instance:
os.path.normpath('/etc/ /passwd/') ---> '/etc/ /passwd/'
Istvan
--
Comment By: jos (josm)
Date: 2007-05-06 11:31
Message:
Logged In: YES
user_id=1776568
Originator: NO
Like all other python libraries, posixpath.normpath has its test cases,
which specify what normpath is supposed to work.
See test_normpath() in Lib/test/test_posixpath.py.
siemer, would you add some test cases for this problem to
test_posixpath.py?
I think it needs not just adding but also need to update existent cases.
That means it would break backwards-compatibility.
According to http://www.python.org/dev/intro/,
changing existing functionality "requires python- dev as a whole to agree
to the change."
So the TODO list would be
1. Write test cases for this problem and post it to the patch manager
2. Discuss the changes on python-dev at python.org and get agreement
3. Write patch and post it to the patch manager
4. Get some reviews
5. Commit
Correct Me If I'm Wrong.
--
Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15
Message:
Logged In: YES
user_id=150699
Originator: YES
1) I (submitter) didn't specify what I expected to see:
os.path.normpath('/etc/passwd/') --> '/etc/passwd/'
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by iszegedi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 18:01
Message:
Logged In: YES
user_id=1772412
Originator: NO
Robert,
I checked once again the POSIX definition of filenames and you are right;
trailing whitespaces are allowed:
-- clip --
3.169 Filename
A name consisting of 1 to {NAME_MAX} bytes used to name a file. The
characters composing the name may be selected from the set of all character
values excluding the slash character and the null byte. The filenames dot
and dot-dot have special meaning. A filename is sometimes referred to as a
"pathname component".
-- clip --
So I agree that this line
path = path.rstrip()
should be removed from the correction suggested by me.
-- clip --
def normpath(path):
"""Normalize path, eliminating double slashes, etc."""
if path == '':
return '.'
initial_slashes = path.startswith('/')
# The next line was added by iszegedi
trailing_slash = path.endswith('/')
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes and
path.startswith('//') and not path.startswith('///')):
initial_slashes = 2
comps = path.split('/')
new_comps = []
for comp in comps:
if comp in ('', '.'):
continue
if (comp != '..' or (not initial_slashes and not new_comps) or
(new_comps and new_comps[-1] == '..')):
new_comps.append(comp)
elif new_comps:
new_comps.pop()
comps = new_comps
path = '/'.join(comps)
if initial_slashes:
path = '/'*initial_slashes + path
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/'
return path or '.'
-- clip --
Nevertheless, the remaining question for me is still the same: what is the
exact definition of normalized path in regards with trailing slash (in
other words what is the correct solution: no slash at the end of the path
OR there should be a slash at the end of the path OR or there should be a
single . appended to the end of the path):
So what is the correct answer:
os.path.normpath('/etc/passwd/') ---> '/etc/passwd' OR
os.path.normpath('/etc/passwd/') ---> '/etc/passwd/' OR
os.path.normpath('/etc/passwd/') ---> '/etc/passwd/.'
Once this is clarified, the solution is pretty easy.
Istvan
--
Comment By: Robert Siemer (siemer)
Date: 2007-05-08 16:24
Message:
Logged In: YES
user_id=150699
Originator: YES
Istvan, you seem to think that trailing whitespace is not significant.
That assumption is wrong. ' ' is a perfect file name... Apart from spaces
even newlines, etc. are okay - and not the same.
I'm also "working" on a good path name handling essay. (-:
Robert
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-08 14:50
Message:
Logged In: YES
user_id=1772412
Originator: NO
I agree with the approach that josm suggested. That is a reasonable way to
get the fix approved or declined.
To response to the remarks from siemer:
1 - 2./ I think what we miss here is the exact definition what path
normalization means. All examples that I have seen so far - including the
comments in the posixpath python module as well - are about removing
redundant information or extra dots and double dots from the path (e.g.
A//B, A/./B and A/foo/../B all become A/B). I have not seen any precise
definition how to deal with trailing slash in a pathname (except for the
one that I copy&pasted from POSIX standard).
That says explicitly that "a pathname ... SHALL BE RESOLVED as if a single
dot .. were appended".
Nevertheless, I can
[ python-Bugs-1713252 ] character set in Japanese on Ubuntu distribution
Bugs item #1713252, was opened at 2007-05-05 07:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Christopher Grell (cgrell) Assigned to: Nobody/Anonymous (nobody) Summary: character set in Japanese on Ubuntu distribution Initial Comment: I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-08 21:05 Message: Logged In: YES user_id=21627 Originator: NO What do you mean by "opens with Japanese character set"? Can you provide a screenshot? Can you figure out what font it is using? -- Comment By: Christopher Grell (cgrell) Date: 2007-05-07 04:42 Message: Logged In: YES user_id=1785859 Originator: YES Changing default character size to 20 removes the issue -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-05 09:08 Message: Logged In: YES user_id=849994 Originator: NO As this is certainly not the case in other distributions, this is something you should file with the Ubuntu bug tracker. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711605 ] CGIHttpServer leaves traces of previous requests in env
Bugs item #1711605, was opened at 2007-05-03 02:28
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711605&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: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer leaves traces of previous requests in env
Initial Comment:
CGIHttpserver tries to reset the environment between calls to CGI scripts by
setting various variables to '' if they are not needed in the current request.
In some cases this is not the correct behaviour since the presence of a null
value can be interpreted by a CGI script as being significant.
For example, if HTTP_COOKIE has a null value then a script doing the standard
test:
if os.environ.has_key('HTTP_COOKIE'):
# get the cookie
will have trouble
The problem is that CGIHTTPserver.py resets the entries in the env array which
is then passed to os.environ.update(), this can only overwrite the env
variables, not remove them.
An alternative is to call
if os.environ.has_key(k):
del os.environ[k]
inside the loop that updates the empty keys, then these variables will not be
passed on to the CGI script.
Steve
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-05-08 21:07
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you provide a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Bugs item #1711608, was opened at 2007-05-03 02:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-08 21:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-856047 ] urllib.py does not use "no_proxy";
Bugs item #856047, was opened at 2003-12-08 05:15 Message generated for change (Comment added) made by tmaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&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: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py does not use "no_proxy"; Initial Comment: urllib.py uses "*_proxy" variables to identify proxies to use in the "getproxies()" function. However, it does not use the corresponding "no_proxy" variable in the "proxy_bypass()" method. This affects any platform that can use "*_proxy" environment variables to specify proxies. This includes win32, which will use environment variables before the registry if they are defined. On win32 this causes the confusing behaviour of using the registry for "proxy_bypass()" checking when "*_proxy" environment variables are used to identify the proxies. Attached is a patch against python-2.3.2 that adds support for "no_proxy". Note that win32 will correctly favor using "no_proxy" over using the registry if any "*_proxy" variables are defined. -- Comment By: Till Maas (tmaas) Date: 2007-05-08 22:15 Message: Logged In: YES user_id=60606 Originator: NO So, it is two years later now, will this ever be fixed? Is there a way to disable to use of proxies completely without having to change the enviroment when http_proxy is set? It is a bad user experience, when one is only able to change a proxy but not to disable the use of proxies completely. -- Comment By: Donovan Baarda (abo) Date: 2005-02-19 06:21 Message: Logged In: YES user_id=10273 This bug is still present in current versions of Python. The biggest problem with this patch is it only addresses urllib, when urllib2 has the same problem. I have been meaning to put together a new patch that fixes both urllib and urllib2, but haven't had time or external motivation yet. -- Comment By: Enrico Scholz (ensc) Date: 2005-02-18 12:13 Message: Logged In: YES user_id=10773 What is the state of this bug? Is something wrong with the patch that it was not applied yet? It is something annoying to unset $http_proxy manually for some programs. -- Comment By: Donovan Baarda (abo) Date: 2003-12-08 05:27 Message: Logged In: YES user_id=10273 Whups... failed to attach patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid days.
Bugs item #1715302, was opened at 2007-05-08 14:49 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=1715302&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: Erik Wickstrom (erikcw) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.date won't accept 08 or 09 as valid days. Initial Comment: The method won't accept 08 or 09 as valid days, but will accept 07. Here is my output: Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t = datetime.date(2007, 05, 07) >>> print t 2007-05-07 >>> t = datetime.date(2007, 05, 08) File "", line 1 t = datetime.date(2007, 05, 08) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 09) File "", line 1 t = datetime.date(2007, 05, 09) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 10) >>> print t 2007-05-10 >>> I was able to reproduce this on another machine as well: Python 2.4.3 (#1, Aug 6 2006, 20:52:01) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid days.
Bugs item #1715302, was opened at 2007-05-08 16:49 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&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: Erik Wickstrom (erikcw) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.date won't accept 08 or 09 as valid days. Initial Comment: The method won't accept 08 or 09 as valid days, but will accept 07. Here is my output: Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t = datetime.date(2007, 05, 07) >>> print t 2007-05-07 >>> t = datetime.date(2007, 05, 08) File "", line 1 t = datetime.date(2007, 05, 08) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 09) File "", line 1 t = datetime.date(2007, 05, 09) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 10) >>> print t 2007-05-10 >>> I was able to reproduce this on another machine as well: Python 2.4.3 (#1, Aug 6 2006, 20:52:01) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-08 17:24 Message: Logged In: YES user_id=1115903 Originator: NO Recommend closing this as not a bug. A number with a leading zero is interpreted as octal literal, so trying to interpret 08 gives an error, since anything bigger than 7 isn't allowed in octal numbers. For your examples above, you should do this: t = datetime.date(2007, 5, 8) t = datetime.date(2007, 5, 9) and then it works as expected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1715302 ] datetime.date won't accept 08 or 09 as valid days.
Bugs item #1715302, was opened at 2007-05-08 17:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Erik Wickstrom (erikcw) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.date won't accept 08 or 09 as valid days. Initial Comment: The method won't accept 08 or 09 as valid days, but will accept 07. Here is my output: Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t = datetime.date(2007, 05, 07) >>> print t 2007-05-07 >>> t = datetime.date(2007, 05, 08) File "", line 1 t = datetime.date(2007, 05, 08) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 09) File "", line 1 t = datetime.date(2007, 05, 09) ^ SyntaxError: invalid token >>> t = datetime.date(2007, 05, 10) >>> print t 2007-05-10 >>> I was able to reproduce this on another machine as well: Python 2.4.3 (#1, Aug 6 2006, 20:52:01) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2007-05-08 23:45 Message: Logged In: YES user_id=3066 Originator: NO Agreed -- not a bug. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-08 18:24 Message: Logged In: YES user_id=1115903 Originator: NO Recommend closing this as not a bug. A number with a leading zero is interpreted as octal literal, so trying to interpret 08 gives an error, since anything bigger than 7 isn't allowed in octal numbers. For your examples above, you should do this: t = datetime.date(2007, 5, 8) t = datetime.date(2007, 5, 9) and then it works as expected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715302&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
