Anders Hovmöller added the comment:
I've written a parser for ISO 8601: https://github.com/boxed/iso8601
Some basic tests are included and it supports most of the standard. Haven't
gotten around to the more obscure parts like durations and intervals, but those
are trivial to add
Anders Hovmöller added the comment:
Éric Araujo: absolutely. Although I think my code can be improved (speed wise,
elegance, etc) since I just wrote it quickly a weekend :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Anders Hovmöller added the comment:
The tests attached to this ticket seem pretty bare. Issues that I can spot
directly:
- only tests for datetimes, not times or dates
- only tests for zulu and "-8:00” timezones
- no tests for invalid input (parsing a valid date as a datetime for ex
Anders Hovmöller added the comment:
> The `arrow` library depends on the supposed "strict" behaviour of strptime
> that has never been guaranteed, which often results in very buggy behaviour
> under some conditions.
Well… the arrow library accepts all sorts of broken
Anders Hovmöller added the comment:
Hmm, ok. I guess I was confused by "dates and times" part of the subject. Ok,
so only datetimes. My other comments still apply though.
> On 19 Jul 2016, at 16:20, Mathieu Dupuy <rep...@bugs.python.org> wrote:
>
>
> Mat
Anders Hovmöller added the comment:
>
> By the way, I just discovered, that the way we treat microseconds differs
> from the strptime one : we are smarter read every digits and smartly round to
> six, strptime doesn't go that far and just *truncate* to this. Should go
Anders Hovmöller added the comment:
@larsonreever That lib is pretty limited, in that it doesn't handle dates or
deltas. Again: my lib that is linked above does and has comprehensive tests.
--
___
Python tracker <rep...@bugs.python.org>
Change by Anders Hovmöller <bo...@killingar.net>:
--
nosy: +Anders.Hovmöller
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Anders Hovmöller <bo...@killingar.net>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22490>
___
Anders Hovmöller added the comment:
There is an example output on github. Should I paste it here too? I can do it
once I get home if you want.
--
___
Python tracker
<https://bugs.python.org/issue34
Change by Anders Hovmöller :
--
keywords: +patch
pull_requests: +9046
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34861>
___
___
Py
New submission from Anders Hovmöller :
The standard output for cProfile when run from a command line is not very
useful. It has two main flaws:
- Default sort order is by name of function
- It strips the full path of source files
The first makes it very hard to look at the output. The second
Anders Hovmöller added the comment:
Output before this patch:
3666 function calls (3556 primitive calls) in 0.005 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
20.0000.0000.0020.001 :1009
Anders Hovmöller added the comment:
I think this is a great idea. We would have needed this many times for tests
over the years.
--
nosy: +Anders.Hovmöller
___
Python tracker
<https://bugs.python.org/issue36
Anders Hovmöller added the comment:
I just discovered this ticket again and see that it's stuck!
I have read through the thread but it's still a bit unclear what would be
required to test this with homebrew like Guido says is needed for this to go
forward. Is there anyone who can explain
Anders Hovmöller added the comment:
Just as a comparison, sed does the 3.6 thing:
> echo foo | sed 's/\(.*\)/x\1y/g'
xfooy
--
___
Python tracker
<https://bugs.python.org/issu
Anders Hovmöller added the comment:
This was a really bad idea in my opinion. We just found this and we have no way
to know how this will impact production. It's really absurd that
re.sub('(.*)', r'foo', 'asd')
is "foo" in python 1 to 3.6 but 'foofoo' in python 3.7.
-
Anders Hovmöller added the comment:
That might be true, but that seems like a weak argument. If anything, it means
those others are broken. What is the logic behind "(.*)" returning the entire
string (which is what you asked for) and exactly one empty string? Why not two
empty str
Anders Hovmöller added the comment:
We were also bitten by this. In fact we still run a compatibility shim in
production where we log if the new and old behavior are different. We also
didn't think this "bug fix" made sense or was treated with the appropriate
gravity in the rel
New submission from Anders Hovmöller :
>>> def foo(a):
... pass
...
>>> foo()
Traceback (most recent call last):
File "", line 1, in
TypeError: foo() missing 1 required positional argument: 'a'
This error is incorrect. It says "positional argument"
Anders Hovmöller added the comment:
For `foo(a, /, b)`, it could be:
"TypeError: foo() missing 1 required argument 'a', and one required positional
argument 'b'.
If we start on this road there are some more, like for `def foo(a, *, b)` you
get the error "TypeError: foo() missing
Anders Hovmöller added the comment:
Just dropping the word "positional" is very good. That word is a lie, and just
removing it makes it true.
--
___
Python tracker
<https://bugs.python.o
22 matches
Mail list logo
