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

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

t 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 <p...@ganssle.io> wrote: > >> I can write at least a pure Python implementation in the next few days, if >> not a full C imp

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I'm not entirely sure I understand the full set of reasoning for this - I couldn't really tell what the problem with OrderedDict is from the link Stefan provided. It seems to me like a kind of huge change for the language to move from arbitrary-ordered to guaranteed-ordered dict. The problem I

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

or does not matter to them when initializing a container. On 11/05/2017 01:39 PM, Stefan Krah wrote: > On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: >> I'm not entirely sure I understand the full set of reasoning for this - I >> couldn't really tell what the problem with Or

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Is there a major objection to just adding in explicit syntax for order-preserving dictionaries? To some extent that seems like a reasonable compromise position in an "explicit is better than implicit" sense. A whole lot of code is out there that doesn't require or expect order-preserving

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

tatements will always throw `AssertionError`, but that's not guaranteed, and some people run their test suites with -O just to check that they aren't making that assumption. On 11/07/2017 04:15 PM, Paul Moore wrote: > On 7 November 2017 at 20:35, Paul G <p...@ganssle.io> wrote: >&

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

If dictionary order is *not* guaranteed in the spec and the dictionary order isn't randomized (which I think everyone agrees is a bit messed up), it would probably be useful if you could enable "random order mode" in CPython, so you can stress-test that your code isn't making any assumptions

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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

This doesn't seem like the best idea, since it would kick off dozens or hundreds of builds for every commit to the master branch. On 05/29/2018 11:25 AM, Matthias Bussonnier wrote: >> As I wrote, it became very difficult to merge any PR on 2.7 because of >> that. We all run a race to be the

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Rust has a few syntactic ways to accomplish the same thing, though. I think match expressions are used for the equivalent of conditionals that carry the condition value into the body of the expression, and all blocks return the result of the last statement, so you can do things like: let mut

Re: [Python-Dev] Dataclasses and correct hashability

I don't think it matters so much whether you are stacking two decorators or a single decorator, but would an @add_unsafe_hash decorator be useful for anything *except* data classes? If not, then there's no point in having a *second* decorator that can *only* modify the first one - particularly

Re: [Python-Dev] Fuzzing the Python standard library

In many languages numeric types can't hold arbitrarily large values, and I for one hadn't really previously recognized that if you read in a numeric value with an exponent that it would be represented *exactly* in memory (and thus one object with a very compact representation can take up huge

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

One thing to note is that if getting Travis working with Python 3.7 is a pain, a huge number of libraries on PyPI probably just won't test against Python 3.7, which is not a great situation to be in. It's probably worth contacting Travis to give them a head's up and see how likely it is that

[Python-Dev] Python version numbers

Breaking this off from the pickle thread because it seems unrelated: On 04/02/2018 06:57 PM, Lukasz Langa wrote: > I think we need to get past thinking about "Python 2" vs. "Python 3". This > frame of mind creates space for another mythical release of Python that will > break all the

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/23/2018 06:04 PM, Tim Peters wrote: > However, against "as" is that its current use in "with" statements > does something quite different: > > with f() as name: > > does not bind the result of `f()` to `name`, but the result of > `f().__enter__()`. Whether that "should be" fatal, I

Re: [Python-Dev] Python version numbers

ill be confusing and annoying for most people (not me, because I know about it and I test against nightly), and as long as there's a "3" in the "major" slot, people will speculate about the possibility of a "4". On 04/03/2018 09:07 AM, Paul Moore wrote: > On 3 April 2

Re: [Python-Dev] Python version numbers

On 04/03/2018 10:10 AM, Nick Coghlan wrote: > The reason for sticking with 3.x for a while is because of the corner > \*nix systems have gotten stuck into regarding the "python" symlink, > and the fact it currently still points to "python2" (if it exists at > all). Once we've updated PEP 394 to

Re: [Python-Dev] Python version numbers

On 04/03/2018 12:36 PM, Brett Cannon wrote: > On Tue, 3 Apr 2018 at 07:39 Paul G <p...@ganssle.io> wrote: > Paul's point is that he knows e.g. code working in 3.6.0 will work when he > upgrades to 3.6.5, and if his code is warning-free and works with all > __future__

Re: [Python-Dev] Python version numbers

> When programs use calendar-based versioning, I'm left with no > information as to whether it's breaking changes or not. In fact, it > might as well have no version numbers whatsoever. If I care about > backward compatibility, I just have to stick with the exact same > unpatched version that I

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

I am not familiar enough with the compiler logic, but would it be possible to optimize this away by detecting whether the bound name has already been deleted during the body of the except statement? On January 6, 2019 4:18:00 PM UTC, Chris Angelico wrote: >On Mon, Jan 7, 2019 at 3:13 AM P

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

I think Serhiy is saying that if you delete exc before the except body ends, when the compiled code goes to delete it it will fail. Binding to None guarantees that there is something to delete. On January 6, 2019 4:05:27 PM UTC, Chris Angelico wrote: >On Mon, Jan 7, 2019 at 2:52 AM Serhiy

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

That's a bit of a fine line to walk. I noticed it when writing tests for IPython, which is not a implementation of Python, but is dealing with the nitty gritty details and manipulating the syntax tree it's true, but it's roughly the same class of project as implementing coverage.py, so if we

[Python-Dev] Re: Do not fallback to __trunc__ when convert to int

> Do you have an idea of how many projects would emit such warning? More and more projects are running their test suite using -Werror. Any new warning can make a project test suite to fail. I don't have an opinion on __trunc__, but as someone who runs such a project, I have to say this is

[Python-Dev] Re: PEP 584: Add Union Operators To dict

I don't have a terribly strong opinion about whether or not it is acceptable to use dict.copy, my point was that the desired semantics can be achieved using only dunder methods if desired, and I think at this point getting the semantics right probably matters more than the implementation

[Python-Dev] Re: PEP 584: Add Union Operators To dict

It looks to me like dict.__copy__ is not implemented, does anyone know why it's not basically an alias for dict.copy? If it's just random happenstance, presumably we could move dict.copy to __copy__ and then have dict.copy as an alias or thin wrapper. It might be desirable anyway for copy.copy