Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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,

Re: [Python-Dev] iso8601 parsing

>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

Re: [Python-Dev] iso8601 parsing

> 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 >>>

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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 =

Re: [Python-Dev] iso8601 parsing

> 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

Re: [Python-Dev] iso8601 parsing

> 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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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 >

Re: [Python-Dev] iso8601 parsing

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. >

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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 >

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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:

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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.

Re: [Python-Dev] iso8601 parsing

> 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 >>>

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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 <wes.tur...@gmail.com> Cc: Python-Dev <python-dev@python.org> Subject: Re: [Python-Dev] iso8601 parsing >

Re: [Python-Dev] iso8601 parsing

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. >

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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, >

Re: [Python-Dev] iso8601 parsing

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,

Re: [Python-Dev] iso8601 parsing

gt; > From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com] > > Sent: Wednesday, October 25, 2017 4:33 PM > > To: Alex Walters <tritium-l...@sdamon.com> > > Cc: Elvis Pranskevichus <elpr...@gmail.com>; Python-Dev > d...@python.org>; Chris Barker &

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

g>; Chris Barker <chris.bar...@noaa.gov> > Subject: Re: [Python-Dev] iso8601 parsing > > On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-l...@sdamon.com> > wrote: > > Why make parsing ISO time special? > > It's not the ISO format per se that is special, b

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

Re: [Python-Dev] iso8601 parsing

> -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 <chris.bar...@noaa.gov> > Subjec

Re: [Python-Dev] iso8601 parsing

> -Original Message- > From: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com] > Sent: Wednesday, October 25, 2017 12:07 PM > To: Alex Walters <tritium-l...@sdamon.com> > Cc: Chris Barker <chris.bar...@noaa.gov>; Python-Dev d...@python.org> >

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

Re: [Python-Dev] iso8601 parsing

org> > Subject: Re: [Python-Dev] iso8601 parsing > > On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > > On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan <hasan.di...@gmail.com> > wrote: > >> > > can anyone argue that i

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

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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? > >

[Python-Dev] iso8601 parsing

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