Re: [Python-Dev] iso8601 parsing

[Chris Barker - NOAA Federal]

On Dec 7, 2017, at 7:52 PM, Mike Miller  wrote:

Guess the argument for limiting what it accepts would be that every funky
variation will need to be supported until the endtimes, even those of
little use or utility.


I suppose so, but not that hard once implemented and tests in place.

How about this for a “practicality beats purity” approach:

.fromiso() will parse the most commonly used iso8601 compliant date time
strings.

It is guaranteed to properly parse the output of .isoformat()

It is Not a validator — it may except non-iso compliant strings, and may
give surprising results when passed such.


In any case, I sure hope it will accept iso strings both with and without
the “T”.

But again: Paul, do whatever you think is best.

-CHB









On the other hand, it might be good to keep the two implementations the
same for consistency reasons.

Thanks either way,
-Mike


On 2017-12-07 17:57, Chris Barker - NOAA Federal wrote:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mike Miller]

Guess the argument for limiting what it accepts would be that every funky 
variation will need to be supported until the endtimes, even those of little use 
or utility.


On the other hand, it might be good to keep the two implementations the same for 
consistency reasons.


Thanks either way,
-Mike


On 2017-12-07 17:57, Chris Barker - NOAA Federal wrote:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker - NOAA Federal]

>but is it that hard to parse arbitrary

ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd

like, but not THAT bad a spec.


No, and in fact this PR is adapted from a *more general* ISO-8601 parser
that I wrote (which is now merged into master on python-dateutil). In the
CPython PR I deliberately limited it to be the inverse of `isoformat()` for
two major reasons:

1. It allows us to get something out there that everyone can agree on - not
only would we have to agree on whether to support arcane ISO8601 formats
like -Www-D,


I don’t know — would anyone complain about it supporting too arcane a
format?

Also — “most ISO compliant “ date time strings would get us a long way.

but we also have to then discuss whether we want to be strict and disallow
MM like ISO-8601 does,


Well, I think disallowing something has little utility - we really don’t
want this to be a validator.

do we want fractional minute support? What about different variations
(we're already supporting replacing T with any character in `.isoformat()`
and outputting time zones in the form hh:mm:ss, so what other non-compliant
variations do we want to add..


Wait — does datetime.isoformat() put out non-compliant strings?

Anyway, supporting all of what .isoformat() puts out, plus Most of iso8601
would be a great start.

 - if it comes out of `isoformat()` it should be able to go back in
througuh `fromisoformat()`.


Yup.

But had anyone raised objections to it being more flexible?

2. It makes it *much* easier to understand what formats are supported. You
can say, "This function is for reading in dates serialized with
`.isoformat()`", you *immediately* know how to create compliant dates.


We could still document that as the preferred form.

You’re writing the code, and I don’t have time to help, so by all means do
what you think is best.

But if you’ve got code that’s more flexible, I can’t imagine anyone
complaining about a more flexible parser.

Though I have a limited imagination about such things.

But I hope it will at least accept both with and without the T.

Thanks for working on this.

-Chris

On 12/07/2017 08:12 PM, Chris Barker wrote:


Here is the PR I've submitted:


https://github.com/python/cpython/pull/4699


The contract that I'm supporting (and, I think it can be argued, the only

reasonable contract in the intial implementation) is the following:


   dtstr = dt.isoformat(*args, **kwargs)

   dt_rt = datetime.fromisoformat(dtstr)

   assert dt_rt == dt# The two points represent the

same absolute time

   assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And

the same wall time




that looks good.



I see this in the comments in the PR:



"""

This does not support parsing arbitrary ISO 8601 strings - it is only

intended

as the inverse operation of :meth:`datetime.isoformat`

"""




what ISO8601 compatible features are not supported?


-CHB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

> And I'm sorry, I got a bit lost in the PR, but you are attaching an
> "offset" tzinfo, when parsing an iso string that has one, yes?

Yes, a fixed offset time zone (since the original zone information is lost):

>>> from dateutil import tz
>>> from datetime import datetime
>>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern'))
datetime.datetime(2014, 12, 11, 9, 30, 
tzinfo=tzfile('/usr/share/zoneinfo/US/Eastern'))
>>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern')).isoformat()
'2014-12-11T09:30:00-05:00'
>>> datetime.fromisoformat('2014-12-11T09:30:00-05:00')
datetime.datetime(2014, 12, 11, 9, 30, 
tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=68400)))

> I fully agree that that's the MVP -- but is it that hard to parse arbitrary
> ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd
> like, but not THAT bad a spec.

No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I 
wrote (which is now merged into master on python-dateutil). In the CPython PR I 
deliberately limited it to be the inverse of `isoformat()` for two major 
reasons:

1. It allows us to get something out there that everyone can agree on - not 
only would we have to agree on whether to support arcane ISO8601 formats like 
-Www-D, but we also have to then discuss whether we want to be strict and 
disallow MM like ISO-8601 does, do we want fractional minute support? What 
about different variations (we're already supporting replacing T with any 
character in `.isoformat()` and outputting time zones in the form hh:mm:ss, so 
what other non-compliant variations do we want to add... and then maintain? We 
can have these discussions later if we want, but we might as well start with 
the part everyone can agree on - if it comes out of `isoformat()` it should be 
able to go back in througuh `fromisoformat()`.

2. It makes it *much* easier to understand what formats are supported. You can 
say, "This function is for reading in dates serialized with `.isoformat()`", 
you *immediately* know how to create compliant dates. Not to mention, the 
specific of formats emitted by `isoformat()` can be written very cleanly as: 
-MM-DD[*[HH[:MM[:SS[.mmm[mmm][+HH:MM]] (where * means any character). 
ISO 8601 supports -MM-DD and MMDD but not -MMDD or MM-DD

So, basically, it's not that it's amazingly hard to write a fully-featured 
ISO-8601, it's more that it doesn't seem like a great match for the problem 
this is intended to solve at this point.

Best,
Paul

On 12/07/2017 08:12 PM, Chris Barker wrote:
> 
>> Here is the PR I've submitted:
>>
>> https://github.com/python/cpython/pull/4699
>>
>> The contract that I'm supporting (and, I think it can be argued, the only
>> reasonable contract in the intial implementation) is the following:
>>
>> dtstr = dt.isoformat(*args, **kwargs)
>> dt_rt = datetime.fromisoformat(dtstr)
>> assert dt_rt == dt# The two points represent the
>> same absolute time
>> assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And
>> the same wall time
>>
> 
> 
> that looks good.
> 

> I see this in the comments in the PR:
> 
> 
> """
> This does not support parsing arbitrary ISO 8601 strings - it is only
> intended
> as the inverse operation of :meth:`datetime.isoformat`
> """
> 

> 
> what ISO8601 compatible features are not supported?
> 
> -CHB
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Wed, Dec 6, 2017 at 3:07 PM, Paul Ganssle  wrote:

> Here is the PR I've submitted:
>
> https://github.com/python/cpython/pull/4699
>
> The contract that I'm supporting (and, I think it can be argued, the only
> reasonable contract in the intial implementation) is the following:
>
> dtstr = dt.isoformat(*args, **kwargs)
> dt_rt = datetime.fromisoformat(dtstr)
> assert dt_rt == dt# The two points represent the
> same absolute time
> assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And
> the same wall time
>


that looks good.

And I'm sorry, I got a bit lost in the PR, but you are attaching an
"offset" tzinfo, when parsing an iso string that has one, yes?

I see this in the comments in the PR:


"""
This does not support parsing arbitrary ISO 8601 strings - it is only
intended
as the inverse operation of :meth:`datetime.isoformat`
"""

I fully agree that that's the MVP -- but is it that hard to parse arbitrary
ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd
like, but not THAT bad a spec.

what ISO8601 compatible features are not supported?

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul Ganssle]

Here is the PR I've submitted:

https://github.com/python/cpython/pull/4699

The contract that I'm supporting (and, I think it can be argued, the only 
reasonable contract in the intial implementation) is the following:

dtstr = dt.isoformat(*args, **kwargs)
dt_rt = datetime.fromisoformat(dtstr)
assert dt_rt == dt# The two points represent the same 
absolute time
assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And the 
same wall time

For all valid values of `dt`, `args` and `kwargs`.

A corollary of the `dt_rt == dt` invariant is that you can perfectly recreate 
the original `datetime` with the following additional step:

dt_rt = dt_rt if dt.tzinfo is None else dt_rt.astimezone(dt.tzinfo)

There is no way for us to guarantee that `dt_rt.tzinfo == dt.tzinfo` or that 
`dt_rt.tzinfo is dt.tzinfo`, because `isoformat()` is slightly lossy (it loses 
the political zone), but this is not an issue because lossless round trips just 
require you to serialize the political zone, which is generally simple enough.


On 12/06/2017 07:54 PM, Barry Scott wrote:
> 
> 
>> On 26 Oct 2017, at 17:45, Chris Barker  wrote:
>>
>> This is a key point that I hope is obvious:
>>
>> If an ISO string has NO offset or timezone indicator, then a naive datetime 
>> should be created.
>>
>> (I say, I "hope" it's obvious, because the numpy datetime64 implementation 
>> initially (and for years) would apply the machine local timezone to a bare 
>> iso string -- which was a f-ing nightmare!)
> 
> 
> I hope the other obvious thing is that if there is a offset then a datetime 
> that is *not* naive can be created
> as it describes an unambiguous point in time. We just cannot know what 
> political timezone to choose.
> I'd guess that it should use the UTC timezone in that case.
> 
> Barry
> 
> 
> 
> 
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Barry Scott]

> On 26 Oct 2017, at 17:45, Chris Barker  wrote:
> 
> This is a key point that I hope is obvious:
> 
> If an ISO string has NO offset or timezone indicator, then a naive datetime 
> should be created.
> 
> (I say, I "hope" it's obvious, because the numpy datetime64 implementation 
> initially (and for years) would apply the machine local timezone to a bare 
> iso string -- which was a f-ing nightmare!)


I hope the other obvious thing is that if there is a offset then a datetime 
that is *not* naive can be created
as it describes an unambiguous point in time. We just cannot know what 
political timezone to choose.
I'd guess that it should use the UTC timezone in that case.

Barry



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

> is there a strict deadline here if we want this for Python 3.7?

The deadline for the new features is the date of the first beta currently
scheduled for 2018-01-29, but if you can get this in before the last alpha
(2018-01-08) it will be best.

See PEP 537 (https://www.python.org/dev/peps/pep-0537) for details and
updates.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

As an update, I have the C version done and basically tested as an extension (I 
"cheated" on the tests by using hypothesis, so I still need to write 
unittest-style tests), just writing the Python version with tests now.

I know there is a feature freeze coming in soon, is there a strict deadline 
here if we want this for Python 3.7?

Best,
Paul

On 12/01/2017 12:47 PM, Chris Barker wrote:
> On Wed, Nov 29, 2017 at 4:19 PM, Paul G  wrote:
> 
>> I can write at least a pure Python implementation in the next few days, if
>> not a full C implementation. Shouldn't be too hard since I've got a few
>> different Cython implementations sitting around anyway.
>>
>>
> Thanks!
> 
> -CHB
> 
> 
> 
> 
>> On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky <
>> alexander.belopol...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker 
>>> wrote:
>>>

 indeed what is the holdup? I don't recall anyone saying it was a bad
 idea in the last discussion.

 Do we just need an implementation?

 Is the one in the Bug Report not up to snuff? If not, then what's wrong
 with it? This is just not that hard a problem to solve.

>>>
>>>
>>> See my comment from over a year ago: >> issue15873#msg273609>.  The proposed patch did not have a C
>>> implementation, but we can use the same approach as with strptime and call
>>> Python code from C.  If users will start complaining about performance, we
>>> can speed it up in later releases.  Also the new method needs to be
>>> documented.  Overall, it does not seem to require more than an hour of work
>>> from a motivated developer, but the people who contributed to the issue in
>>> the past seem to have lost their interest.
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Wed, Nov 29, 2017 at 4:19 PM, Paul G  wrote:

> I can write at least a pure Python implementation in the next few days, if
> not a full C implementation. Shouldn't be too hard since I've got a few
> different Cython implementations sitting around anyway.
>
>
Thanks!

-CHB




> On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
>>
>>
>>
>> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker 
>> wrote:
>>
>>>
>>> indeed what is the holdup? I don't recall anyone saying it was a bad
>>> idea in the last discussion.
>>>
>>> Do we just need an implementation?
>>>
>>> Is the one in the Bug Report not up to snuff? If not, then what's wrong
>>> with it? This is just not that hard a problem to solve.
>>>
>>
>>
>> See my comment from over a year ago: > issue15873#msg273609>.  The proposed patch did not have a C
>> implementation, but we can use the same approach as with strptime and call
>> Python code from C.  If users will start complaining about performance, we
>> can speed it up in later releases.  Also the new method needs to be
>> documented.  Overall, it does not seem to require more than an hour of work
>> from a motivated developer, but the people who contributed to the issue in
>> the past seem to have lost their interest.
>>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Wed, Nov 29, 2017 at 7:18 PM, Mario Corchero  wrote:

> There were discussions about having it a function, making the constructor
> of datetime accept a string(this was strongly rejected), having a static
> function in datetime, etc... and there was no real agreement.
>

Guido has written several times that a named constructor is the way
forward.  The name "fromisoformat" was more or less agreed upon as well.
In fact, Mathieu Dupuy's patch was 95% there.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mike Miller]

Yeah!  I'm available for writing docs and testing it if needed.

Performance is not a big concern in this first version, unless you've already 
written most of it.  If it is a concern for others then the third-party modules 
will still be available as well.


-Mike


On 2017-11-29 16:19, Paul G wrote:
I can write at least a pure Python implementation in the next few days, if not a 
full C implementation. Shouldn't be too hard since I've got a few different 
Cython implementations sitting around anyway.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

I can write at least a pure Python implementation in the next few days, if not 
a full C implementation. Shouldn't be too hard since I've got a few different 
Cython implementations sitting around anyway.

On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky 
 wrote:
>On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker 
>wrote:
>
>>
>> indeed what is the holdup? I don't recall anyone saying it was a bad
>idea
>> in the last discussion.
>>
>> Do we just need an implementation?
>>
>> Is the one in the Bug Report not up to snuff? If not, then what's
>wrong
>> with it? This is just not that hard a problem to solve.
>>
>
>
>See my comment from over a year ago: <
>https://bugs.python.org/issue15873#msg273609>.  The proposed patch did
>not
>have a C implementation, but we can use the same approach as with
>strptime
>and call Python code from C.  If users will start complaining about
>performance, we can speed it up in later releases.  Also the new method
>needs to be documented.  Overall, it does not seem to require more than
>an
>hour of work from a motivated developer, but the people who contributed
>to
>the issue in the past seem to have lost their interest.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mario Corchero]

There were discussions about having it a function, making the constructor
of datetime accept a string(this was strongly rejected), having a static
funcion in datetime, etc... and there was no real agreement.

If the agreement is that we want a funcion to be able to parse it I am sure
Paul G will be kind to do it (he told me not long ago he was thinking on
sending a PR for it). If he is busy I am happy to chip in time this
weekend.

All I wanted when I sent https://bugs.python.org/issue31800 was actually to
be able to parse isoformat datetime ^^.



 Thu, 30 Nov 2017 at 00:09, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker 
> wrote:
>
>>
>> indeed what is the holdup? I don't recall anyone saying it was a bad idea
>> in the last discussion.
>>
>> Do we just need an implementation?
>>
>> Is the one in the Bug Report not up to snuff? If not, then what's wrong
>> with it? This is just not that hard a problem to solve.
>>
>
>
> See my comment from over a year ago: <
> https://bugs.python.org/issue15873#msg273609>.  The proposed patch did
> not have a C implementation, but we can use the same approach as with
> strptime and call Python code from C.  If users will start complaining
> about performance, we can speed it up in later releases.  Also the new
> method needs to be documented.  Overall, it does not seem to require more
> than an hour of work from a motivated developer, but the people who
> contributed to the issue in the past seem to have lost their interest.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mariocj89%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker  wrote:

>
> indeed what is the holdup? I don't recall anyone saying it was a bad idea
> in the last discussion.
>
> Do we just need an implementation?
>
> Is the one in the Bug Report not up to snuff? If not, then what's wrong
> with it? This is just not that hard a problem to solve.
>


See my comment from over a year ago: <
https://bugs.python.org/issue15873#msg273609>.  The proposed patch did not
have a C implementation, but we can use the same approach as with strptime
and call Python code from C.  If users will start complaining about
performance, we can speed it up in later releases.  Also the new method
needs to be documented.  Overall, it does not seem to require more than an
hour of work from a motivated developer, but the people who contributed to
the issue in the past seem to have lost their interest.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller 
wrote:

> This thread isn't about the numerous third-party solutions that are a pip
> command away.  But rather getting a minimal return parser to handle
> datetime.isoformat() into the std library.
>
> It's been needed for years,


indeed what is the holdup? I don't recall anyone saying it was a bad idea
in the last discussion.

Do we just need an implementation?

Is the one in the Bug Report not up to snuff? If not, then what's wrong
with it? This is just not that hard a problem to solve.

-CHB






> and hopefully someone can squeeze it into 3.7 before its too late.  (It
> takes years for a new version to trickle down to Linux dists.)
>
> -Mike
>
>
> On 2017-11-28 13:09, Skip Montanaro wrote:
>
>> It's got its own little parsing language, different than the usual
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.
> barker%40noaa.gov
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mike Miller]

Hi,

This thread isn't about the numerous third-party solutions that are a pip 
command away.  But rather getting a minimal return parser to handle 
datetime.isoformat() into the std library.


It's been needed for years, and hopefully someone can squeeze it into 3.7 before 
its too late.  (It takes years for a new version to trickle down to Linux dists.)


-Mike


On 2017-11-28 13:09, Skip Montanaro wrote:
It's got its own little parsing language, different than the usual 


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mario Corchero]

The basics should be possible already with issue31800
, that said the issue you reference is
to get a single function to parse it (without having to put the whole
format), which would be neat.

I believe Paul Ganssle is planning on adding it to dateutil as well:
https://github.com/dateutil/dateutil/pull/489/files

On 28 November 2017 at 19:51, Mike Miller  wrote:

> This may have gotten bogged down again.  Could we get the output of
> datetime.isoformat() parsed at a minimum?  Perfection is not required.
>
> Looks like there is a patch or two and test cases on the bug.
>
> -Mike
>
>
> Could anyone put this five year-old bug about parsing iso8601 format
>> date-times on the front burner?
>>
>>  http://bugs.python.org/issue15873
>>
>> In the comments there's a lot of hand-wringing about different variations
>> that bogged it down, but right now I only need it to handle the output of
>> datetime.isoformat():
>>
>>  >>> dt.isoformat()
>>  '2017-10-20T08:20:08.986166+00:00'
>>
>> Perhaps if we could get that minimum first step in, it could be iterated
>> on and made more lenient in the future.
>>
>> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mariocj89
> %40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Skip Montanaro]

It's got its own little parsing language, different than the usual
strftime/strptime format scheme, more like what you might see in Excel. I
never worried too much about the speed of dateutil.parser.parse() unless I
was calling it in an inner loop, but arrow.get() seems to be a fair bit
faster than dateutil.parser.parse. This makes sense, as the latter tries to
figure out what you've given it (you never give it a format string), while
in the absence of a format string, arrow.get assumes you have an ISO-8601
date/time, with only a few small variations allowed.

Skip

On Tue, Nov 28, 2017 at 2:52 PM, Paul G  wrote:

> IIRC, arrow usually calls dateutil to parse dates anyway, and there are
> many other, lighter dependencies that will parse an ISO 8601 date quickly
> into a datetime.datetime object.
>
> I still think it's reasonable for the .isoformat() operation to have an
> inverse operation in the standard library.
>
> On November 28, 2017 3:45:41 PM EST, Skip Montanaro <
> skip.montan...@gmail.com> wrote:
>>
>>  I think the latest version can now strptime offsets of the form ±HH:MM with
>>>  %z, so there's no longer anything blocking you from parsing from all
>>>  isoformat() outputs with strptime, provided you know which one you need.
>>>
>>
>> Or just punt and install arrow:
>>
>>  import arrow
>  arrow.get('2017-10-20T08:20:08.986166+00:00')
>
 
>>
>>>  arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>
 datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))
>>
>> Skip
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

IIRC, arrow usually calls dateutil to parse dates anyway, and there are many 
other, lighter dependencies that will parse an ISO 8601 date quickly into a 
datetime.datetime object. 

I still think it's reasonable for the .isoformat() operation to have an inverse 
operation in the standard library.

On November 28, 2017 3:45:41 PM EST, Skip Montanaro  
wrote:
>> I think the latest version can now strptime offsets of the form
>±HH:MM with
>> %z, so there's no longer anything blocking you from parsing from all
>> isoformat() outputs with strptime, provided you know which one you
>need.
>
>Or just punt and install arrow:
>
 import arrow
 arrow.get('2017-10-20T08:20:08.986166+00:00')
>
 arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None,
>0))
>
>Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Skip Montanaro]

> I think the latest version can now strptime offsets of the form ±HH:MM with
> %z, so there's no longer anything blocking you from parsing from all
> isoformat() outputs with strptime, provided you know which one you need.

Or just punt and install arrow:

>>> import arrow
>>> arrow.get('2017-10-20T08:20:08.986166+00:00')

>>> arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

I think the latest version can now strptime offsets of the form ±HH:MM with %z, 
so there's no longer anything blocking you from parsing from all isoformat() 
outputs with strptime, provided you know which one you need.

I think a from_isoformat() like method that *only* supports isoformat outputs 
is a fine idea, though, with a fairly obvious interface. I'd be happy to take a 
crack at it (I've been working on the somewhat harder problem of an iso8601 
compliant parser for dateutil, so this is fresh in my mind).

On November 28, 2017 2:51:14 PM EST, Mike Miller  
wrote:
>This may have gotten bogged down again.  Could we get the output of 
>datetime.isoformat() parsed at a minimum?  Perfection is not required.
>
>Looks like there is a patch or two and test cases on the bug.
>
>-Mike
>
>
>> Could anyone put this five year-old bug about parsing iso8601 format
>date-times 
>> on the front burner?
>> 
>>      http://bugs.python.org/issue15873
>> 
>> In the comments there's a lot of hand-wringing about different
>variations that 
>> bogged it down, but right now I only need it to handle the output of 
>> datetime.isoformat():
>> 
>>      >>> dt.isoformat()
>>      '2017-10-20T08:20:08.986166+00:00'
>> 
>> Perhaps if we could get that minimum first step in, it could be
>iterated on and 
>> made more lenient in the future.
>> 
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mike Miller]

This may have gotten bogged down again.  Could we get the output of 
datetime.isoformat() parsed at a minimum?  Perfection is not required.


Looks like there is a patch or two and test cases on the bug.

-Mike


Could anyone put this five year-old bug about parsing iso8601 format date-times 
on the front burner?


     http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that 
bogged it down, but right now I only need it to handle the output of 
datetime.isoformat():


     >>> dt.isoformat()
     '2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and 
made more lenient in the future.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Wes Turner]

On Thursday, October 26, 2017, Chris Barker  wrote:

> On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner  > wrote:
>
>> ISO 8601 support offsets, but not time zones -- presumably the __str__
>>> supports the full datetime tzinfo somehow. Which may be why .isoformat()
>>> exists.
>>>
>>
>> ISO8601 does support timezones.
>> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>>
>
> No, it doesn't -- it may call them "timezones", but it only supports
> offsets -- that is, and offset of -6 could be US Eastern Standard Time or
> US Central Daylight TIme (or I got that backwards :-)  )
>
> The point is that an offset is really easy, and timezones (with Daylight
> savings and all that) are a frickin' nightmare, but ARE supported by
> datetime
>
> Note that the vocabulary is not precise here, as I see this in the Pyton
> docs:
>
> *class *datetime.timezone
>
> A class that implements the tzinfo
>  abstract
> base class as a fixed offset from the UTC.
> So THAT is supported by iso8601, and, indeed maps naturally to it.
>

Got it, thanks.


>
> Which means we can round trip isp8601 datetimes nicely, but can't round
> trip a datetime with a "full featured" tzinfo attached.
>

Because an iso8601 string only persists the offset.


>
> I don't think this really has any impact on the proposal, though: it's
> clear what to do when parsing a iso Datetime.
>
> I might be wrong, but I think many of the third party libraries listed
>> here default to either UTC or timezone-naieve timezones:
>> https://github.com/vinta/awesome-python/blob/master/README.
>> md#date-and-time
>>
>
> This is a key point that I hope is obvious:
>
>

> If an ISO string has NO offset or timezone indicator, then a naive
> datetime should be created.
>


>
> (I say, I "hope" it's obvious, because the numpy datetime64 implementation
> initially (and for years) would apply the machine local timezone to a bare
> iso string -- which was a f-ing nightmare!)
>

astropy.time.Time supports numpy.


>
>
>> Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
>> with my local time.
>>
>> Here's an example with a *custom* GMT1 tzinfo subclass:
>> https://docs.python.org/3/library/datetime.html#datetime.time.tzname
>>
>
> Here it is:
>
> class GMT1(tzinfo):
> def utcoffset(self, dt):
> return timedelta(hours=1)
> def dst(self, dt):
> return timedelta(0)
> def tzname(self,dt):
> return "Europe/Prague"
>
> I hope Prague doesn't do DST, or that would be just wrong ...
>

Pendulum seems to have a faster timezone lookup than pytz:

https://pendulum.eustace.io/blog/a-faster-alternative-to-pyz.html

Both pendulum and pytz are in conda-forge (the new basis for the anaconda
distribution).


>
> What would you call the str argument? Does it accept strptime args or only
>> ISO8601?
>>
>
> I think Fred answered this, but iso 8601 only. we already have strptime if
> you need to parse anything else.
>
> Would all of that string parsing logic be a performance regression from
>> the current constructor? Does it accept None or empty string?
>>
>
> I suppose you need to do a little type checking first, so a tiny one.
>
> Though maybe just catching an Exception, so really tiny.
>
> The current constructor only takes numbers, so yes the string parsing
> version would be slower, but only if you use it...
>
> Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
>> types is nasty, regardless (try/except, *custom* schema awareness). And
>> pickle is dangerous.
>>
>> AFAIU, we should not ever eval(repr(dt: datetime)).
>>
>
> why not? isn't that what __repr__ is supposed to do?
>

repr(dict) now returns ellipses ... for cyclical dicts; so I'm assuming
that repr only MAY be eval'able.


>
> Or do you mean not that it shouldn't work, but that we shouldn't do it?
>

That
We shouldn't ever eval untrusted data / code.
(That's why we need package hashes, signatures, and TUF).


>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE
> 
>   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> 
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alex Walters]

 

 

From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon@python.org] 
On Behalf Of Chris Barker
Sent: Thursday, October 26, 2017 12:46 PM
To: Wes Turner 
Cc: Python-Dev 
Subject: Re: [Python-Dev] iso8601 parsing

 

> No, it doesn't -- it may call them "timezones", but it only supports offsets 
> -- that is, and offset of -6 could be US Eastern Standard Time or US Central 
> Daylight TIme (or I got that backwards :-)  )

 

US Central Standard, Mountain Daylight.  (Eastern is -5/-4DST)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner  wrote:

> ISO 8601 support offsets, but not time zones -- presumably the __str__
>> supports the full datetime tzinfo somehow. Which may be why .isoformat()
>> exists.
>>
>
> ISO8601 does support timezones.
> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>

No, it doesn't -- it may call them "timezones", but it only supports
offsets -- that is, and offset of -6 could be US Eastern Standard Time or
US Central Daylight TIme (or I got that backwards :-)  )

The point is that an offset is really easy, and timezones (with Daylight
savings and all that) are a frickin' nightmare, but ARE supported by
datetime

Note that the vocabulary is not precise here, as I see this in the Pyton
docs:

*class *datetime.timezone

A class that implements the tzinfo
 abstract
base class as a fixed offset from the UTC.
So THAT is supported by iso8601, and, indeed maps naturally to it.

Which means we can round trip isp8601 datetimes nicely, but can't round
trip a datetime with a "full featured" tzinfo attached.

I don't think this really has any impact on the proposal, though: it's
clear what to do when parsing a iso Datetime.

I might be wrong, but I think many of the third party libraries listed here
> default to either UTC or timezone-naieve timezones:
> https://github.com/vinta/awesome-python/blob/master/
> README.md#date-and-time
>

This is a key point that I hope is obvious:

If an ISO string has NO offset or timezone indicator, then a naive datetime
should be created.

(I say, I "hope" it's obvious, because the numpy datetime64 implementation
initially (and for years) would apply the machine local timezone to a bare
iso string -- which was a f-ing nightmare!)


> Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
> with my local time.
>
> Here's an example with a *custom* GMT1 tzinfo subclass:
> https://docs.python.org/3/library/datetime.html#datetime.time.tzname
>

Here it is:

class GMT1(tzinfo):
def utcoffset(self, dt):
return timedelta(hours=1)
def dst(self, dt):
return timedelta(0)
def tzname(self,dt):
return "Europe/Prague"

I hope Prague doesn't do DST, or that would be just wrong ...

What would you call the str argument? Does it accept strptime args or only
> ISO8601?
>

I think Fred answered this, but iso 8601 only. we already have strptime if
you need to parse anything else.

Would all of that string parsing logic be a performance regression from the
> current constructor? Does it accept None or empty string?
>

I suppose you need to do a little type checking first, so a tiny one.

Though maybe just catching an Exception, so really tiny.

The current constructor only takes numbers, so yes the string parsing
version would be slower, but only if you use it...

Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
> types is nasty, regardless (try/except, *custom* schema awareness). And
> pickle is dangerous.
>
> AFAIU, we should not ever eval(repr(dt: datetime)).
>

why not? isn't that what __repr__ is supposed to do?

Or do you mean not that it shouldn't work, but that we shouldn't do it?

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Nick Coghlan]

On 26 October 2017 at 07:30, Chris Barker  wrote:

> +1 on a classmethod constructor
> +0 on a based-on-type default constructor
>
> +inf on SOMETHING!
>
> Let's get passed the bike shedding and make this work!
>

I'll also note that these aren't either/or outcomes: adding a str-specific
classmethod *doesn't* preclude implicitly calling that class method from
the default constructor later based on the input type.

For example, decimal.Decimal.from_float() was added before the type
constructor gained native support for float inputs, due to concerns about
potential binary-vs-decimal rounding errors arising from doing such
conversions implicitly.

So we can add "datetime.fromisoformat(isotime: str)" now, and then *if* we
later decide to support the "type(x)(str(x)) == x" numeric invariant for
the datetime classes, that can be specified as "If the constructor
arguments consist of a single string, that is handled by calling the
fromisoformat class method".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Fred Drake]

On Wed, Oct 25, 2017 at 10:37 PM, Wes Turner  wrote:
> What would you call the str argument? Does it accept strptime args or only
> ISO8601?

There'd be no reason to accept a format.  That wouldn't make sense.  A
.fromiso(s:str) should only accept an ISO 8601 string, though I'd
advocate tolerating both space and "T".

> Would all of that string parsing logic be a performance regression
> from the current constructor? Does it accept None or empty string?

It's an alternate constructor, so should not impact the existing
constructor (though it could employ the existing constructor to get
work done).

It should not accept anything but a valid ISO 8601 string.

> Should the date time constructor support nanos= (just like time_ns())?

No.  It should support exactly up to 6 decimal digits to populate the
microsecond field.

> ENH: Add nanosecond support to the time and datetime constructors

This should be left for a separate change, if we determine it should
be implemented for the datetime and timedelta types.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Wes Turner]

On Wednesday, October 25, 2017, Chris Barker  wrote:

> On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky <
> alexander.belopol...@gmail.com
> > wrote:
>
>> > times. The only difference is that instead of calling the type directly,
>> > you call the appropriate classmethod.
>> >
>> > What am I missing?
>>
>> Nothing. The only annoyance is that the data processing code typically
>> needs to know the type anyway, so the classmethod is one more variable
>> to keep track of.
>
>
> I don't think anyone is arguing that is is hard to do either way, or that
> hard to use either way.
>
> I think it comes down to a trade-off between:
>
> Having an API for datetime that is like the datetime for number types:
>
>  int(str(an_int)) == an_int
>
>  so:
>
>  datetime(str(a_datetime)) == a_datetime
>
> Alexander strongly supports that.
>
> Or an API that is perhaps more like the rest of the datetime api, which
> has a number of alternate constructors:
>
>  datetime.now()
>
>  datetime.fromordinal()
>
>  datetime.fromtimestamp()
>
> And has:
>
>   datetime.isoformat()
>
> So a
>
>datetime.fromisoformat()
>
> would make a lot of sense.
>
> I would note that the number types don't have all those alternate
> constructors Also, the number types mostly have a single parameter (except
> int has an optional base parameter). So I'm not sure the parallel is that
> strong.
>
> Would it be horrible if we did both?
>
> After all, right now, datetime has:
>
> In [16]: dt.isoformat()
> Out[16]: '2017-10-25T16:30:48.744489'
>
> and
> In [18]: dt.__str__()
> Out[18]: '2017-10-25 16:30:48.744489'
>
> which do almost the same thing (I understand the "T" is option in iso 8601)
>
> However, maybe they are different when you add a time zone?
>
> ISO 8601 support offsets, but not time zones -- presumably the __str__
> supports the full datetime tzinfo somehow. Which may be why .isoformat()
> exists.
>

ISO8601 does support timezones.
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

I might be wrong, but I think many of the third party libraries listed here
default to either UTC or timezone-naieve timezones:
https://github.com/vinta/awesome-python/blob/master/README.md#date-and-time

Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
with my local time.

Here's an example with a *custom* GMT1 tzinfo subclass:
https://docs.python.org/3/library/datetime.html#datetime.time.tzname



> Though I don't think that means you couldn't have the __init__ parse
> proper ISO strings, in addition to the full datetime __str__ results.
>

What would you call the str argument? Does it accept strptime args or only
ISO8601? Would all of that string parsing logic be a performance regression
from the current constructor? Does it accept None or empty string?

...

Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
types is nasty, regardless (try/except, *custom* schema awareness). And
pickle is dangerous.

AFAIU, we should not ever eval(repr(dt: datetime)).

...

Should the date time constructor support nanos= (just like time_ns())?

ENH: Add nanosecond support to the time and datetime constructors

...

The astropy Time class supports a string argument as the first parameter
sometimes:
http://docs.astropy.org/en/stable/time/#inferring-input-format

Astropy does support a "year zero".

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Guido van Rossum]

I think this ship has long sailed. Sorry Alexander, but I see a new class
method in your future.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> > times. The only difference is that instead of calling the type directly,
> > you call the appropriate classmethod.
> >
> > What am I missing?
>
> Nothing. The only annoyance is that the data processing code typically
> needs to know the type anyway, so the classmethod is one more variable
> to keep track of.


I don't think anyone is arguing that is is hard to do either way, or that
hard to use either way.

I think it comes down to a trade-off between:

Having an API for datetime that is like the datetime for number types:

 int(str(an_int)) == an_int

 so:

 datetime(str(a_datetime)) == a_datetime

Alexander strongly supports that.

Or an API that is perhaps more like the rest of the datetime api, which has
a number of alternate constructors:

 datetime.now()

 datetime.fromordinal()

 datetime.fromtimestamp()

And has:

  datetime.isoformat()

So a

   datetime.fromisoformat()

would make a lot of sense.

I would note that the number types don't have all those alternate
constructors Also, the number types mostly have a single parameter (except
int has an optional base parameter). So I'm not sure the parallel is that
strong.

Would it be horrible if we did both?

After all, right now, datetime has:

In [16]: dt.isoformat()
Out[16]: '2017-10-25T16:30:48.744489'

and
In [18]: dt.__str__()
Out[18]: '2017-10-25 16:30:48.744489'

which do almost the same thing (I understand the "T" is option in iso 8601)

However, maybe they are different when you add a time zone?

ISO 8601 support offsets, but not time zones -- presumably the __str__
supports the full datetime tzinfo somehow. Which may be why .isoformat()
exists.

Though I don't think that means you couldn't have the __init__ parse proper
ISO strings, in addition to the full datetime __str__ results.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 5:30 PM, Chris Barker  wrote:

> Let's get passed the bike shedding and make this work!

Sure.  Submitting a pull request for
 would be a good start.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 5:30 PM, Steven D'Aprano  wrote:
> Maybe I'm just being slow today, but I don't see how you can write
> "generic code" to convert text to int/float/complex/Fraction, but not
> times. The only difference is that instead of calling the type directly,
> you call the appropriate classmethod.
>
> What am I missing?

Nothing. The only annoyance is that the data processing code typically
needs to know the type anyway, so the classmethod is one more variable
to keep track of.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Steven D'Aprano]

On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote:
> On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters  wrote:
> >  Why make parsing ISO time special?
> 
> It's not the ISO format per se that is special, but parsing of str(x).
> For all numeric types, int, float, complex and even
> fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
> Datetime types are a special kind of numbers, but they don't follow
> this established pattern.  This is annoying when you deal with time
> series where it is common to have text files with a mix of dates,
> timestamps and numbers.  You can write generic code to deal with ints
> and floats, but have to special-case anything time related.

Maybe I'm just being slow today, but I don't see how you can write 
"generic code" to convert text to int/float/complex/Fraction, but not 
times. The only difference is that instead of calling the type directly, 
you call the appropriate classmethod.

What am I missing?



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

+1 on a classmethod constructor
+0 on a based-on-type default constructor

+inf on SOMETHING!

Let's get passed the bike shedding and make this work!

-CHB


On Wed, Oct 25, 2017 at 2:18 PM, Alex Walters 
wrote:

>
>
> > -Original Message-
> > From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> > Sent: Wednesday, October 25, 2017 4:33 PM
> > To: Alex Walters 
> > Cc: Elvis Pranskevichus ; Python-Dev  > d...@python.org>; Chris Barker 
> > Subject: Re: [Python-Dev] iso8601 parsing
> >
> > On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters 
> > wrote:
> > >  Why make parsing ISO time special?
> >
> > It's not the ISO format per se that is special, but parsing of str(x).
> > For all numeric types, int, float, complex and even
> > fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
> > Datetime types are a special kind of numbers, but they don't follow
> > this established pattern.  This is annoying when you deal with time
> > series where it is common to have text files with a mix of dates,
> > timestamps and numbers.  You can write generic code to deal with ints
> > and floats, but have to special-case anything time related.
>
> >>> repr(datetime.datetime.now())
> 'datetime.datetime(2017, 10, 25, 17, 16, 20, 973107)'
>
> You can already roundtrip the repr of datetime objects with eval (if you
> care to do so).  You get iso formatting from a method on dt objects, I
> don’t see why it should be parsed by anything but a classmethod.
>
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Random832]

On Wed, Oct 25, 2017, at 16:32, Alexander Belopolsky wrote:
> This is annoying when you deal with time
> series where it is common to have text files with a mix of dates,
> timestamps and numbers.  You can write generic code to deal with ints
> and floats, but have to special-case anything time related.

Generic code that uses a Callable[[str], ...] instead of a type works
fine with a class method.

column1.parser = int
column2.parser = float
column3.parser = datetime.parse_iso
column4.parser = json.loads

It is *very slightly* more complex than a model that needs the type also
for some reason and has the type pull double duty as the parser... but
why do that?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> Sent: Wednesday, October 25, 2017 4:33 PM
> To: Alex Walters 
> Cc: Elvis Pranskevichus ; Python-Dev  d...@python.org>; Chris Barker 
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters 
> wrote:
> >  Why make parsing ISO time special?
> 
> It's not the ISO format per se that is special, but parsing of str(x).
> For all numeric types, int, float, complex and even
> fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
> Datetime types are a special kind of numbers, but they don't follow
> this established pattern.  This is annoying when you deal with time
> series where it is common to have text files with a mix of dates,
> timestamps and numbers.  You can write generic code to deal with ints
> and floats, but have to special-case anything time related.

>>> repr(datetime.datetime.now())
'datetime.datetime(2017, 10, 25, 17, 16, 20, 973107)'

You can already roundtrip the repr of datetime objects with eval (if you care 
to do so).  You get iso formatting from a method on dt objects, I don’t see why 
it should be parsed by anything but a classmethod.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters  wrote:
>  Why make parsing ISO time special?

It's not the ISO format per se that is special, but parsing of str(x).
For all numeric types, int, float, complex and even
fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
Datetime types are a special kind of numbers, but they don't follow
this established pattern.  This is annoying when you deal with time
series where it is common to have text files with a mix of dates,
timestamps and numbers.  You can write generic code to deal with ints
and floats, but have to special-case anything time related.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Elvis Pranskevichus
> Sent: Tuesday, October 24, 2017 8:12 PM
> To: python-dev@python.org
> Cc: Chris Barker 
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote:
> > No, but the last time I suggested that that datetime types should
> > satisfy the same invariants as numbers, namely
> > T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
> > am not very enthusiastic about named constructors such as
> > date.isoparse().  Compared with date(s:str), this is one more method
> > name to remember, plus the potential for abuse as an instance method.
> > What is d.isoparse('2017-11-24')?
> 
> Agreed.  datetime(s:str) seems like a far more natural and consistent
> choice.

It's inconsistent with the rest of the module.  All other constructions of
datetime objects are on classmethods.  Why make parsing ISO time special?

> 
>  Elvis
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> list%40sdamon.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> Sent: Wednesday, October 25, 2017 12:07 PM
> To: Alex Walters 
> Cc: Chris Barker ; Python-Dev  d...@python.org>
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> 
> 
> > On Oct 25, 2017, at 11:45 AM, Alex Walters 
> wrote:
> >
> > it means
> > the type of the first argument changes the semantic meaning of
> subsequent
> > arguments, and that just adds a level of confusion to any api.
> 
> No, it does not. Passing a string a the first of three arguments will
still be a
> type error.

And that is a confusing api.  The problem has already been solved by
classmethod alternate constructors - they are already used widely in the
datetime api.  NOT using classmethod constructors is new and confusing for
the SINGLE use case of parsing iso formatted dates and times.  Why is that
special?  Why isn't ordinal time special to get into __init__?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

> On Oct 25, 2017, at 11:45 AM, Alex Walters  wrote:
> 
> it means
> the type of the first argument changes the semantic meaning of subsequent
> arguments, and that just adds a level of confusion to any api.

No, it does not. Passing a string a the first of three arguments will still be 
a type error. 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alex Walters]

> -Original Message-
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Alexander Belopolsky
> Sent: Tuesday, October 24, 2017 5:54 PM
> To: Chris Barker 
> Cc: Python-Dev 
> Subject: Re: [Python-Dev] iso8601 parsing
> 
> On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker 
> wrote:
> > On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan 
> wrote:
> >>
> > can anyone argue that it's not a good idea for datetime ot
> > be able to read the iso format it puts out?
> 
> No, but the last time I suggested that that datetime types should
> satisfy the same invariants as numbers, namely
> T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
> am not very enthusiastic about named constructors such as
> date.isoparse().  Compared with date(s:str), this is one more method
> name to remember, plus the potential for abuse as an instance method.
> What is d.isoparse('2017-11-24')?

Datetime.datetime.fromiso() (classmethod) is much more in keeping with the
rest of the datetime api - in fact, I have tried calling that method more
than once, before remembering datetime *doesn't* have that classmethod.
Making it a classmethod solves any concerns about calling it as an instance
method (the same way d.now() and d.strptime() just create and return a new
datetime objects, not mutates the current).  In fact, looking at the docs,
most of the methods are classmethods, so an additional classmethod is
fitting.

I really do not like the idea of making the first positional argument of the
datetime constructor int or str.  What happens when you pass a string for
the first argument and ints for subsequent arguments?  You would have to
raise a typeerror or valueerror.  I don't like that API design - it means
the type of the first argument changes the semantic meaning of subsequent
arguments, and that just adds a level of confusion to any api.  You might be
able to get away with that in third party code, but this is the standard
library, and this is the time manipulation module in the standard library -
you have to assume that this is one of the first modules a new user uses, we
have to keep the api sane.

The only way I can think of keeping the api sane and still pass an iso
string to the constructor is to pass It as a keyword argument - and at that
point you have to remember the argument name anyways, so you might as well
make it a classmethod to match everything else in the library.

$0.02

> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> list%40sdamon.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Elvis Pranskevichus]

On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote:
> No, but the last time I suggested that that datetime types should
> satisfy the same invariants as numbers, namely
> T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
> am not very enthusiastic about named constructors such as
> date.isoparse().  Compared with date(s:str), this is one more method
> name to remember, plus the potential for abuse as an instance method.
> What is d.isoparse('2017-11-24')?

Agreed.  datetime(s:str) seems like a far more natural and consistent 
choice.

 Elvis
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Alexander Belopolsky]

On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker  wrote:
> On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan  wrote:
>>
> can anyone argue that it's not a good idea for datetime ot
> be able to read the iso format it puts out?

No, but the last time I suggested that that datetime types should
satisfy the same invariants as numbers, namely
T(repr(x)) == x, the idea was met will silence.  I, on the other hand,
am not very enthusiastic about named constructors such as
date.isoparse().  Compared with date(s:str), this is one more method
name to remember, plus the potential for abuse as an instance method.
What is d.isoparse('2017-11-24')?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Chris Barker]

On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan  wrote:

> If one simply replaces the 'T' with a space and trims it after the '.',
> IIRC, it parses fine.
>

sure, but really, can anyone argue that it's not a good idea for datetime
ot be able to read the iso format it puts out???

-CHB



> -- H
>
> On Oct 23, 2017 15:16, "Mike Miller"  wrote:
>
>> Hi,
>>
>> Could anyone put this five year-old bug about parsing iso8601 format
>> date-times on the front burner?
>>
>> http://bugs.python.org/issue15873
>>
>> In the comments there's a lot of hand-wringing about different variations
>> that bogged it down, but right now I only need it to handle the output of
>> datetime.isoformat():
>>
>> >>> dt.isoformat()
>> '2017-10-20T08:20:08.986166+00:00'
>>
>> Perhaps if we could get that minimum first step in, it could be iterated
>> on and made more lenient in the future.
>>
>> Thank you,
>> -Mike
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/hasan.diw
>> an%40gmail.com
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> chris.barker%40noaa.gov
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Hasan Diwan]

If one simply replaces the 'T' with a space and trims it after the '.',
IIRC, it parses fine.
-- H

On Oct 23, 2017 15:16, "Mike Miller"  wrote:

> Hi,
>
> Could anyone put this five year-old bug about parsing iso8601 format
> date-times on the front burner?
>
> http://bugs.python.org/issue15873
>
> In the comments there's a lot of hand-wringing about different variations
> that bogged it down, but right now I only need it to handle the output of
> datetime.isoformat():
>
> >>> dt.isoformat()
> '2017-10-20T08:20:08.986166+00:00'
>
> Perhaps if we could get that minimum first step in, it could be iterated
> on and made more lenient in the future.
>
> Thank you,
> -Mike
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/hasan.
> diwan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] iso8601 parsing

[Mike Miller]

Hi,

Could anyone put this five year-old bug about parsing iso8601 format date-times 
on the front burner?


http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that 
bogged it down, but right now I only need it to handle the output of 
datetime.isoformat():


>>> dt.isoformat()
'2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and 
made more lenient in the future.


Thank you,
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com