[issue42094] isoformat() / fromisoformat() for datetime.timedelta
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 or a year will do to the date. There may be edge cases when crossing DST, but normal arithmetic with timezone also have those cases. Regarding ISO weeks, I'm pretty sure that they are only special in regards to calculating week numbers and the weekday they start. They still have a duration of 7 days. Apart from being able to parse ISO durations coming from other systems, the non-precise durations would be useful e.g. when implementing recurring events. Calculating a series of dates for something that happens on the 12th day of every 2nd month is doable in Python, but not with the aid of timedelta. I see four options here: 1) expand timedelta to allow month and year, with the implication that e.g. total_seconds() would fail or be ambiguous for these timedeltas 2) implement only the parts of ISO 8601 that can safely be represented by the current timedelta 3) add a new relativetimedelta class that allows representing non-precise durations 4) do nothing and leave it to 3rd party packages to implement this -- ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42094] isoformat() / fromisoformat() for datetime.timedelta
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/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42094] isoformat() / fromisoformat() for datetime.timedelta
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() was added in Python 3.8. ISO 8601 also has a standard for durations: https://en.wikipedia.org/wiki/ISO_8601#Durations For consistency with the other objects in the datetime module, I suggest adding isoformat()/fromisoformat() methods for datetime.timedelta that implement ISO 8601 durations. ISO 8601 durations support years and months that are not valid timedelta arguments because they are non-precise durations. I suggest throwing an exception if the conversion to or from timedelta cannot be done safely. https://pypi.org/project/isodate/ implements a parse_duration() method that could be used for inspiration. -- components: Library (Lib) messages: 379091 nosy: Erik Cederstrand priority: normal severity: normal status: open title: isoformat() / fromisoformat() for datetime.timedelta versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38964] Output of syntax error in f-string contains wrong filename
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/issue38964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38964] Output of syntax error in f-string contains wrong filename
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 hexadecimal literal
But if the syntax error is inside an f-string, Python reports 'File
""' instead of the actual filename in the exception output.
$ cat syntax_error_in_fstring.py
f'This is a syntax error: {0x=5}'
$ python3.8 syntax_error_in_fstring.py
File "", line 1
SyntaxError: invalid hexadecimal literal
--
messages: 35
nosy: Erik Cederstrand
priority: normal
severity: normal
status: open
title: Output of syntax error in f-string contains wrong filename
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38964>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %G, %V and %u directives
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 a lecture about the origin of these new directives and their support in the underlying OS. There are a number of foot-shooting possibilities when parsing date strings with the directives supported by strptime(), but at least this patch does not make it worse. It validates the input nicely when using the new directives and prints useful error messages it input is ambiguous. I'm not a committer, but I approve of the patch as-is. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %G, %V and %u directives
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. But after four years, the smile is getting a bit stiff when I look at this enhancement request. I'm hereby offering a scrumptious, mouth-watering, virtual, blackberry mousse gateau with a honey-roasted almond meringue cake bottom to the person who gets this enhancement committed. In good open-source spirit, everyone who contributed along the way is entitled to a healthy serving and eternal gratitude from me. Bon appetit! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %G, %V and %u directives
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 for the next POSIX spec
(http://austingroupbugs.net/view.php?id=879). But it will be years before
operating systems catch up, so I would opt for the ValueError approach instead.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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.)
+elif julian == -1 and iso_week != -1 and iso_weekday != -1:
+year, julian = _calc_julian_from_V(iso_year, iso_week, iso_weekday)
In Lib/test/test_strptime.py:
def test_ValueError(self):
+# Make sure ValueError is raised when match fails or format is bad
+self.assertRaises(ValueError, _strptime._strptime, data_string=1905
52,
+ format=%Y %V)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
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, too. I think the strptime approach is a more elegant and standardized way of creating dates from exotic values. -- nosy: +Erik Cederstrand ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 the first day of the first week of
2001 instead, then that's another date (Jan. 1, 2001). The last and the first
week in a year may span dates belonging to two years. That's just the way it
is.
Are you suggesting strptime('2002 01 1', '%Y %V %u') to mean first day of
first week of 2002, except if that would change the year, in which case it
means ???
If you want to strftime(strptime(date, fmt), fmt) and arrive at the original
date then yes, you need %G (but only in strftime).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 aren't used in combination (since using %w could mean either the Sunday in the end of ISO week X or the Sunday preceeding ISO week X). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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/_strptime.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 of the previous year. %u ISO weekday (Monday as the first day of the week) as a decimal number (1-7). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 for strftime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html For some reason, these directives are not mentioned in the related strptime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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 be ambiguous, since %w weeks start on Sunday, while %u start with Monday. I agree that this should be implemented in strptime(), to follow libc strptime(). datetime() has a clear constructor while strptime() has all the whacky cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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() mentions a %V and %u directive which does this, i.e.
Monday in ISO week 22 of the year 2011:
datetime.strptime('2011221', '%Y%V%u')
returning 2011-05-30 and
datetime.strptime('2011227', '%Y%V%u')
returning 2011-06-05
libc (on FreeBSD) has this to say:
%V is replaced by the week number of the year (Monday as the first day
of the week) as a decimal number (01-53). If the week containing
January 1 has four or more days in the new year, then it is week 1;
otherwise it is the last week of the previous year, and the next
week is week 1.
%u is replaced by the weekday (Monday as the first day of the week) as
a decimal number (1-7).
--
components: Library (Lib)
messages: 135177
nosy: Erik.Cederstrand
priority: normal
severity: normal
status: open
title: strptime should implement %V or %u directive from libc
type: feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
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...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
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/issue11155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
Changes by Erik Cederstrand e...@1calendar.dk: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
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 import Queue q = Queue() print(inspect.getargspec(q.put)) ArgSpec(args=['self', 'item', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None)) Notice the 'obj' argument in the multiprocessing version and the 'item' argument in the Queue version. I think 'obj' should be renamed to 'item' to be in line with the other implementation and to agree with the docs: (http://docs.python.org/library/multiprocessing.html?highlight=multiprocessing#multiprocessing.Queue.put): put(item[, block[, timeout]]) -- assignee: docs@python components: Documentation messages: 128200 nosy: Erik.Cederstrand, docs@python priority: normal severity: normal status: open title: multiprocessing.Queue's put() signature differs from docs versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
