Erik Cederstrand added the comment:
There are two conflicting interests: ISO 8601 that allows non-precise
durations, and timedelta that assumes precise durations.
For me, the non-precise durations only make sense in date arithmetic - to a
human, it's pretty clear what adding 3 months
Erik Cederstrand added the comment:
Among other things, ISO 8601 duration strings are commonly used to communicate
offset values in timezone definitions.
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Erik Cederstrand :
Python 3.7 gained support for parsing ISO 8601 formatted time, date and
datetime strings via the fromisoformat() methods. Python has seen improved
support for ISO 8601 in general; ISO calendar format codes were added in Python
3.6, and fromisocalendar
Erik Cederstrand added the comment:
Additionally, the output in the 2nd example does not contain the helpful text
printing the context and location of the code containing the syntax error.
--
___
Python tracker
<https://bugs.python.org/issue38
New submission from Erik Cederstrand :
When I have a normal syntax error in a file, Python reports the filename in the
exception output:
$ cat syntax_error.py
0x=5
$ python3.8 syntax_error.py
File "syntax_error.py", line 1
0x=5
^
SyntaxError: invalid hexadecim
Erik Cederstrand added the comment:
I have reviewed the latest patch, and it looks good to me. There are tests for
the tricky conversions around Jan 1, and the docs are brief and succinct. Until
the full set of new c99 strftime directives are supported, I think it's
overkill to include
Erik Cederstrand added the comment:
The going's a bit tough here. I've spent at least 10 times as long on this bug
than it took me to work around the fact that Python doesn't support ISO week
number round-trip. Python puts a smile on my face every day and I enjoy giving
back where I can
Erik Cederstrand added the comment:
I think POLA would be to raise ValueError on time.strptime('2015', '%G') and
other situations that don't make sense or are ambiguous.
That, or reproduce the bugs that the native OS strptime() implementation has. I
got the %G, %V, and %u directives accepted
Erik Cederstrand added the comment:
I don't have the repo handy to make a patch against 3.5, but would an addition
like this do?
in Lib/_strptime.py:
+elif iso_week != -1 and iso_year == -1:
+raise ValueError('%Y' directive is ambiguous in combination with
'%V'. Use '%G' instead
Erik Cederstrand added the comment:
Well, it's an ambiguous situation, as established earlier. I'm not sure what
the policy is wrt. foot-shooting, but I'd opt to fail if %G, %V and %u are not
used together.
--
___
Python tracker rep
Erik Cederstrand added the comment:
Ping. Is anyone willing to take this? I'm not a committer nor know anyone with
commit access.
--
nosy: +Erik Cederstrand
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
Erik Cederstrand e...@cederstrand.dk added the comment:
I would like to point out that http://bugs.python.org/issue12006 provides a
solution (including patches) based on %G%, V and %u directives for use in
strptime()/strftime(). These directives are defined in (FreeBSD) libc, and PHP
has them
Erik Cederstrand e...@1calendar.dk added the comment:
I respectfully disagree. I take strptime('2002 01 1', '%Y %V %u') as mening
first day of first week in the year 2002
There is only one date that corresponds to the first day of the first week of
2002, i.e. Dec. 31, 2001. If you specify
Erik Cederstrand e...@1calendar.dk added the comment:
Reading you comment again, I see the ambiguity now, if %Y is interpreted as
The resulting date MUST be in 2001.
I think the safest way would be to implement %G and fail if %Y is used in
combination with %V. Maybe even fail if %V and %u
Erik Cederstrand e...@1calendar.dk added the comment:
Uploaded patch adding unit tests for %V and %u. Patch is against python2.7
--
Added file: http://bugs.python.org/file22125/test_strptime.py.patch
___
Python tracker rep...@bugs.python.org
http
Erik Cederstrand e...@1calendar.dk added the comment:
Patch by aganders3 doesn't compile. Added comments in review of his patch.
Adding a patch against python2.7 with my changes, which pass all unit tests
posted previously.
--
Added file: http://bugs.python.org/file22126
Erik Cederstrand e...@1calendar.dk added the comment:
Documentation (I have no idea how to create a patch for this):
%V ISO week number of the year (Monday as the first day of the week) as a
decimal number (01-53). The week containing January 4 is week 1;
the previous week is the last week
Erik Cederstrand e...@1calendar.dk added the comment:
Ashley, can you elaborate on wherein the ambiguity lies? Which combination of
year, ISO week number and ISO weekday would lead to ambiguity?
Regarding documentation, the %G, %V and %u directives are listed in IEEE Std
1003.1, 2004 Edition
Erik Cederstrand e...@1calendar.dk added the comment:
Oh, I see, you're talking about strftime(). You're correct that you would need
%G to print the year to which the ISO week containing the specific date
belongs. I see no ambiguity or need for %G in strptime
Erik Cederstrand e...@1calendar.dk added the comment:
Getting a date from ISO week /weekday is not possible with the %W and %w
directives. ISO week numbers and normal week numbers are calculated differently
(see my libc qoute in the original post). Also, using %w instead of %u would
New submission from Erik Cederstrand e...@1calendar.dk:
Python is via datetime.isocalendar() able to produce the ISO week number and
ISO weekday from a given date. But it is not possible to do the reverse;
calculate the date from a year, ISO week number and weekday.
libc strptime()/strftime
Erik Cederstrand e...@1calendar.dk added the comment:
At least in Denmark, week numbers are used regularly in everyday communication
and planning, and the numbering follows the ISO rules. Also, the week starts on
Monday.
--
___
Python tracker rep
Erik Cederstrand e...@1calendar.dk added the comment:
I'm not sure if I was supposed to respond. The patch looks straight-forward to
me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11155
Erik Cederstrand e...@1calendar.dk added the comment:
Just checked on Python 2.7.1 with the same result. Test script attached.
--
Added file: http://bugs.python.org/file21459/q.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Erik Cederstrand e...@1calendar.dk:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11155
___
___
Python-bugs
New submission from Erik Cederstrand e...@1calendar.dk:
In Python 2.6.6 on OSX:
import inspect
from multiprocessing import Queue
q = Queue()
print(inspect.getargspec(q.put))
ArgSpec(args=['self', 'obj', 'block', 'timeout'], varargs=None, keywords=None,
defaults=(True, None))
from Queue
26 matches
Mail list logo
