Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
28.11.17 22:31, Raymond Hettinger пише: I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. Put me down for a strong -1. The proposal would occasionally save a few keystokes but comes at the expense of giving Python a more Perlish look and a more arcane feel. One of the things I like about Python is that I can walk non-programmers through the code and explain what it does. The examples in PEP 505 look like a step in the wrong direction. They don't "look like Python" and make me feel like I have to decrypt the code to figure-out what it does. timeout ?? local_timeout ?? global_timeout 'foo' in (None ?? ['foo', 'bar']) requested_quantity ?? default_quantity * price name?.strip()[4:].upper() user?.first_name.upper() New syntax often look unusual. "lambda" and "yield" also didn't "look like Python". But there are other considerations. 1. Languages that has the ?? and ?. operators usually have a single special (or at least a one obvious) value that is served for signaling "there-is-no-a-value". The None in Python is not so special. It can be used as a common object, and other ways can be used for denoting an "absent" value. The need of None-specific operators in Python is lower. 2. Python already have other ways for handling "absent" values: the short-circuit "or" and "and" operators which return the one of arguments, getattr() with the default value, the hack with default class attributes, exception handling. The need of the proposed operators in Python is lower. 3. These languages usually have borrowed the syntax of the ternary operator from C: "... ? ... : ...". Thus the syntax with "?" looks more natural in them. But in Python it looks less natural. I'm -1 for accepting this syntax in 3.7. In future all can be changed. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Second post: PEP 557, Data Classes
On 11/28/2017 8:31 PM, Eric V. Smith wrote: On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would use C.__gt__. Which had better not reject this on the basis that other is not an instance of a subclass of C. IIRC there's already something in the interpreter that tries the most derived class first for binary operators -- that may force our hand here. I'm leaning toward doing the same thing attrs does. They have much more experience with this. Except that given Hynek's response in https://github.com/ericvsmith/dataclasses/issues/51#issuecomment-347769322, I'm just going to leave it as-is, with a strict type requirement for all 6 methods. Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
On 29 November 2017 at 06:17, Guido van Rossum wrote: > Please, not for 3.7. I think it will be very difficult to get consensus > about this, and I personally feel something like +/- zero about it -- > sometimes I think it makes sense, sometimes I think we're jumping the shark > here. I've marked all 3 of the related PEPs as Deferred until 3.8 at the earliest: https://github.com/python/peps/commit/181cc79af925e06a068733a1419b1760ac1a2d6f PEP 505: None-aware operators PEP 532: A circuit breaking protocol and binary operators PEP 535: Rich comparison chaining I don't see any urgency to resolve any of them - the None-aware operators do make certain kinds of code (commonly found in JSON processing) easier to read and write, but such code is still fairly readable and writable today (it's just a bit verbose and boilerplate heavy), and the other two PEPs arise specifically from seeking to provide a common conceptual underpinning for the semantics of both the proposed None-aware operations and the existing short-circuiting logical operators. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__
> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith wrote: > > We have been using DeprecationWarning for changes where code will > transition from working -> raising an error, and that *is* based on > the Official Recommendation to hide those by default whenever > possible. We've been doing this for a few years now, and I'd say our > experience so far has been... poor. I'm trying to figure out how to > say this politely. Basically it doesn't work at all. What happens in > practice is that we issue a DeprecationWarning for a year, mostly > no-one notices, then we make the change in a 1.x.0 release, everyone's > code breaks, we roll it back in 1.x.1, and then possibly repeat > several times in 1.(x+1).0 and 1.(x+2).0 until enough people have > updated their code that the screams die down. I'm pretty sure we'll be > changing our policy at some point, possibly to always use > FutureWarning for everything. In pip we ended up working around the not-displaying-by-default so that we got the old behavior back again because hiding warnings doesn’t work great in my experience.___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote: > > > I also cc python-dev to see if anybody here is strongly in favor or against > > this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a few > keystokes but comes at the expense of giving Python a more Perlish look > and a more arcane feel. > > One of the things I like about Python is that I can walk non-programmers > through the code and explain what it does. The examples in PEP 505 look > like a step in the wrong direction. They don't "look like Python" and > make me feel like I have to decrypt the code to figure-out what it does. > > timeout ?? local_timeout ?? global_timeout > 'foo' in (None ?? ['foo', 'bar']) > requested_quantity ?? default_quantity * price > name?.strip()[4:].upper() > user?.first_name.upper() Since we're looking at different syntax for the ?? operator, I have a suggestion for the ?. operator - and related ?[] and ?() that appeared in some of the proposals. How about this approach? Something like (or None: ...) as a syntax block in which any operation [lexically within the expression, not within e.g. called functions, so it's different from simply catching AttributeError etc, even if that could be limited to only catching when the operand is None] on None that is not valid for None will yield None instead. This isn't *entirely* equivalent, but offers finer control. v = name?.strip()[4:].upper() under the old proposal would be more or less equivalent to: v = name.strip()[4:].upper() if name is not None else None Whereas, you could get the same result with: (or None: name.strip()[4:].upper()) Though that would technically be equivalent to these steps: v = name.strip if name is not None else None v = v() if v " v = v[4:] """ v = v.upper """ v = v() """ The compiler could optimize this case since it knows none of the operations are valid on None. This has the advantage of being explicit about what scope the modified rules apply to, rather than simply implicitly being "to the end of the chain of dot/bracket/call operators" It could also be extended to apply, without any additional syntax, to binary operators (result is None if either operand is None) (or None: a + b), for example, could return None if either a or b is none. [I think I proposed this before with the syntax ?(...), the (or None: ...) is just an idea to make it look more like Python.] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
I like much of the thinking in Random's approach. But I still think None
isn't quite special enough to warrant it's own syntax.
However, his '(or None: name.strip()[4:].upper())' makes me realize that
what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of
ternary expression. Except the ternary isn't based on whether a predicate
holds, but rather on whether an exception occurs (AttributeError, KeyError,
TypeError). And the fallback in the ternary is always None rather than
being general.
I think we could generalize this to get something both more Pythonic and
more flexible. E.g.:
val = name.strip()[4:].upper() except None
This would just be catching all errors, which is perhaps too broad. But it
*would* allow a fallback other than None:
val = name.strip()[4:].upper() except -1
I think some syntax could be possible to only "catch" some exceptions and
let others propagate. Maybe:
val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
I don't really like throwing a colon in an expression though. Perhaps some
other word or symbol could work instead. How does this read:
val = name.strip()[4:].upper() except -1 in (AttributeError, KeyError)
Where the 'in' clause at the end would be optional, and default to
'Exception'.
I'll note that what this idea DOES NOT get us is:
val = timeout ?? local_timeout ?? global_timeout
Those values that are "possibly None" don't raise exceptions, so they
wouldn't apply to this syntax.
Yours, David...
On Wed, Nov 29, 2017 at 9:03 AM, Random832 wrote:
> On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote:
> >
> > > I also cc python-dev to see if anybody here is strongly in favor or
> against this inclusion.
> >
> > Put me down for a strong -1. The proposal would occasionally save a few
> > keystokes but comes at the expense of giving Python a more Perlish look
> > and a more arcane feel.
> >
> > One of the things I like about Python is that I can walk non-programmers
> > through the code and explain what it does. The examples in PEP 505 look
> > like a step in the wrong direction. They don't "look like Python" and
> > make me feel like I have to decrypt the code to figure-out what it does.
> >
> > timeout ?? local_timeout ?? global_timeout
> > 'foo' in (None ?? ['foo', 'bar'])
> > requested_quantity ?? default_quantity * price
> > name?.strip()[4:].upper()
> > user?.first_name.upper()
>
> Since we're looking at different syntax for the ?? operator, I have a
> suggestion for the ?. operator - and related ?[] and ?() that appeared
> in some of the proposals. How about this approach?
>
> Something like (or None: ...) as a syntax block in which any operation
> [lexically within the expression, not within e.g. called functions, so
> it's different from simply catching AttributeError etc, even if that
> could be limited to only catching when the operand is None] on None that
> is not valid for None will yield None instead.
>
> This isn't *entirely* equivalent, but offers finer control.
>
> v = name?.strip()[4:].upper() under the old proposal would be more or
> less equivalent to:
>
> v = name.strip()[4:].upper() if name is not None else None
>
> Whereas, you could get the same result with:
> (or None: name.strip()[4:].upper())
>
> Though that would technically be equivalent to these steps:
> v = name.strip if name is not None else None
> v = v() if v "
> v = v[4:] """
> v = v.upper """
> v = v() """
>
> The compiler could optimize this case since it knows none of the
> operations are valid on None. This has the advantage of being explicit
> about what scope the modified rules apply to, rather than simply
> implicitly being "to the end of the chain of dot/bracket/call operators"
>
> It could also be extended to apply, without any additional syntax, to
> binary operators (result is None if either operand is None) (or None: a
> + b), for example, could return None if either a or b is none.
>
> [I think I proposed this before with the syntax ?(...), the (or None:
> ...) is just an idea to make it look more like Python.]
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
> On Nov 29, 2017, at 12:40 PM, David Mertz wrote:
>
> I like much of the thinking in Random's approach. But I still think None
> isn't quite special enough to warrant it's own syntax.
>
> However, his '(or None: name.strip()[4:].upper())' makes me realize that what
> is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of ternary
> expression. Except the ternary isn't based on whether a predicate holds, but
> rather on whether an exception occurs (AttributeError, KeyError, TypeError).
> And the fallback in the ternary is always None rather than being general.
>
> I think we could generalize this to get something both more Pythonic and more
> flexible. E.g.:
>
> val = name.strip()[4:].upper() except None
>
> This would just be catching all errors, which is perhaps too broad. But it
> *would* allow a fallback other than None:
>
> val = name.strip()[4:].upper() except -1
>
> I think some syntax could be possible to only "catch" some exceptions and let
> others propagate. Maybe:
>
> val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
>
> I don't really like throwing a colon in an expression though. Perhaps some
> other word or symbol could work instead. How does this read:
>
> val = name.strip()[4:].upper() except -1 in (AttributeError, KeyError)
>
> Where the 'in' clause at the end would be optional, and default to
> 'Exception'.
>
> I'll note that what this idea DOES NOT get us is:
>
> val = timeout ?? local_timeout ?? global_timeout
>
> Those values that are "possibly None" don't raise exceptions, so they
> wouldn't apply to this syntax.
See the rejected PEP 463 for Exception catching expressions.
Eric.
>
> Yours, David...
>
>
>> On Wed, Nov 29, 2017 at 9:03 AM, Random832 wrote:
>> On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote:
>> >
>> > > I also cc python-dev to see if anybody here is strongly in favor or
>> > > against this inclusion.
>> >
>> > Put me down for a strong -1. The proposal would occasionally save a few
>> > keystokes but comes at the expense of giving Python a more Perlish look
>> > and a more arcane feel.
>> >
>> > One of the things I like about Python is that I can walk non-programmers
>> > through the code and explain what it does. The examples in PEP 505 look
>> > like a step in the wrong direction. They don't "look like Python" and
>> > make me feel like I have to decrypt the code to figure-out what it does.
>> >
>> > timeout ?? local_timeout ?? global_timeout
>> > 'foo' in (None ?? ['foo', 'bar'])
>> > requested_quantity ?? default_quantity * price
>> > name?.strip()[4:].upper()
>> > user?.first_name.upper()
>>
>> Since we're looking at different syntax for the ?? operator, I have a
>> suggestion for the ?. operator - and related ?[] and ?() that appeared
>> in some of the proposals. How about this approach?
>>
>> Something like (or None: ...) as a syntax block in which any operation
>> [lexically within the expression, not within e.g. called functions, so
>> it's different from simply catching AttributeError etc, even if that
>> could be limited to only catching when the operand is None] on None that
>> is not valid for None will yield None instead.
>>
>> This isn't *entirely* equivalent, but offers finer control.
>>
>> v = name?.strip()[4:].upper() under the old proposal would be more or
>> less equivalent to:
>>
>> v = name.strip()[4:].upper() if name is not None else None
>>
>> Whereas, you could get the same result with:
>> (or None: name.strip()[4:].upper())
>>
>> Though that would technically be equivalent to these steps:
>> v = name.strip if name is not None else None
>> v = v() if v "
>> v = v[4:] """
>> v = v.upper """
>> v = v() """
>>
>> The compiler could optimize this case since it knows none of the
>> operations are valid on None. This has the advantage of being explicit
>> about what scope the modified rules apply to, rather than simply
>> implicitly being "to the end of the chain of dot/bracket/call operators"
>>
>> It could also be extended to apply, without any additional syntax, to
>> binary operators (result is None if either operand is None) (or None: a
>> + b), for example, could return None if either a or b is none.
>>
>> [I think I proposed this before with the syntax ?(...), the (or None:
>> ...) is just an idea to make it look more like Python.]
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons. Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
On Nov 29, 2017, at 12:40, David Mertz wrote: > I think some syntax could be possible to only "catch" some exceptions and let > others propagate. Maybe: > >val = name.strip()[4:].upper() except (AttributeError, KeyError): -1 > > I don't really like throwing a colon in an expression though. Perhaps some > other word or symbol could work instead. How does this read: > >val = name.strip()[4:].upper() except -1 in (AttributeError, KeyError) I don’t know whether I like any of this but I think a more natural spelling would be: val = name.strip()[4:].upper() except (AttributeError, KeyError) as -1 which could devolve into: val = name.strip()[4:].upper() except KeyError as -1 or: val = name.strip()[4:].upper() except KeyError # Implicit `as None` I would *not* add any spelling for an explicit bare-except equivalent. You would have to write: val = name.strip()[4:].upper() except Exception as -1 Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list [email protected] 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
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
On 28 November 2017 at 18:38, Barry Warsaw wrote: > On Nov 28, 2017, at 15:31, Raymond Hettinger > wrote: > >> Put me down for a strong -1. The proposal would occasionally save a few >> keystokes but comes at the expense of giving Python a more Perlish look and >> a more arcane feel. > > I am also -1. > >> One of the things I like about Python is that I can walk non-programmers >> through the code and explain what it does. The examples in PEP 505 look >> like a step in the wrong direction. They don't "look like Python" and make >> me feel like I have to decrypt the code to figure-out what it does. > > I had occasional to speak with someone very involved in Rust development. > They have a process roughly similar to our PEPs. One of the things he told > me, which I found very interesting and have been mulling over for PEPs is, > they require a section in their specification discussion how any new feature > will be taught, both to new Rust programmers and experienced ones. I love > the emphasis on teachability. Sometimes I really miss that when considering > some of the PEPs and the features they introduce (look how hard it is to > teach asynchronous programming). Oh well, I would be +1 on patching PEP 1 for that. > > Cheers, > -Barry > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Removing files from the repository
After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder. I think that any file removals from the repository should pass some PEP-like process. Declaring the intention with the rationale, taking a feedback, discussing, and finally documenting the removal. Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that similar file existed. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or restore it: git checkout ^ -- https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history On Wednesday, November 29, 2017 12:26:01 PM CST, Serhiy Storchaka wrote: After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder. I think that any file removals from the repository should pass some PEP-like process. Declaring the intention with the rationale, taking a feedback, discussing, and finally documenting the removal. Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that similar file existed. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
That sounds a bit excessive. Is there a recent incident that inspired this proposal? On Wed, Nov 29, 2017 at 10:26 AM, Serhiy Storchaka wrote: > After removing files from the repository they disappear from the source > tree, and it is even hard to notice this if you don't use it regularly. It > is hard to track the history of the removed file even if you know it exact > path. If you know it only approximate this is harder. > > I think that any file removals from the repository should pass some > PEP-like process. Declaring the intention with the rationale, taking a > feedback, discussing, and finally documenting the removal. Perhaps it is > worth to track all removals in a special file, so if later you will find > that the removed file can be useful you could restore it instead of > recreating its functionality from zero in the case if you even don't know > that similar file existed. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% > 40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
On Wed, Nov 29, 2017 at 1:47 PM, Ryan Gonzalez wrote: > Doesn't Git make this rather easy, though? +1. PEP-like process for removing/renaming files is too much, in my opinion. Yury ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__
On Nov 28, 2017 3:55 PM, "Guido van Rossum" wrote: On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote: > Eh, numpy does use FutureWarning for changes where the same code will > transition from doing one thing to doing something else without > passing through a state where it raises an error. But that decision > was based on FutureWarning being shown to users by default, not > because it matches the nominal purpose :-). IIRC I proposed this > policy for NumPy in the first place, and I still don't even know if it > matches the original intent because the docs are so vague. "Will > change behavior in the future" describes every case where you might > consider using FutureWarning *or* DeprecationWarning, right? > > We have been using DeprecationWarning for changes where code will > transition from working -> raising an error, and that *is* based on > the Official Recommendation to hide those by default whenever > possible. We've been doing this for a few years now, and I'd say our > experience so far has been... poor. I'm trying to figure out how to > say this politely. Basically it doesn't work at all. What happens in > practice is that we issue a DeprecationWarning for a year, mostly > no-one notices, then we make the change in a 1.x.0 release, everyone's > code breaks, we roll it back in 1.x.1, and then possibly repeat > several times in 1.(x+1).0 and 1.(x+2).0 until enough people have > updated their code that the screams die down. I'm pretty sure we'll be > changing our policy at some point, possibly to always use > FutureWarning for everything. Can one of you check that the latest version of PEP 565 gets this right? If you're asking about the the proposed new language about FutureWarnings, it seems fine to me. If you're asking about the PEP as a whole, it seems fine but I don't think it will make much difference in our case. IPython has been showing deprecation warnings in __main__ for a few years now, and it's nice enough. Getting warnings for scripts seems nice too. But we aren't rolling back changes because they broke someone's one off script – I'm sure it happens but we don't tend to hear about it. We're responding to things like major downstream dependencies that nonetheless totally missed all the warnings. The part that might help there is evangelising popular test runners like pytest to change their defaults. To me that's the most interesting change to come out of this. But it's hard to predict in advance how effective it will be. tl;dr: I don't think PEP 565 solves all my problems, but I don't have any objections to what it does to. -n ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
29.11.17 20:47, Ryan Gonzalez пише: Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or restore it: git checkout ^ -- https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history Thank you Ryan. I didn't know this. But the first command produces much noise. It includes reverted changes that added new files (they could be reapplied again), files Misc/NEWS.d/next/ which were merged into Misc/NEWS, and full content of deleted directories. If the list of deleted files be supported manually, it would contain only the root of deleted directories, and wouldn't contain files which were not released. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
Hi, Serhiy opened this thread after I removed tools for CVS and Subversion from the master branch: two scripts and a svnmap.txt file. I removed Misc/svnmap.txt, a mapping of Subversion commits to Mercurial commits. The change was approved by 3 core dev, but then I was asked to restore (only) the svnmap.txt and so I reverted it. See the issue and the pull request for the full story: https://bugs.python.org/issue32159 https://github.com/python/cpython/pull/4615 I misunderstood the purpose of the file. I understood that it was used by removed scripts, whereas it was kept for historic purpose, to find Suversion commits like r12345. The mapping maps to Mercurial commits, whereas the CPython repository was converted to Git in the meanwhile. The last 3 years, I someone need to get access to an old r12345 commit, but it was always in messages on the bug tracker which is able to give me a working link to the actual change. Victor Le 29 nov. 2017 8:03 PM, "Guido van Rossum" a écrit : > That sounds a bit excessive. Is there a recent incident that inspired this > proposal? > > On Wed, Nov 29, 2017 at 10:26 AM, Serhiy Storchaka > wrote: > >> After removing files from the repository they disappear from the source >> tree, and it is even hard to notice this if you don't use it regularly. It >> is hard to track the history of the removed file even if you know it exact >> path. If you know it only approximate this is harder. >> >> I think that any file removals from the repository should pass some >> PEP-like process. Declaring the intention with the rationale, taking a >> feedback, discussing, and finally documenting the removal. Perhaps it is >> worth to track all removals in a special file, so if later you will find >> that the removed file can be useful you could restore it instead of >> recreating its functionality from zero in the case if you even don't know >> that similar file existed. >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40p >> ython.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > victor.stinner%40gmail.com > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
29.11.17 21:00, Guido van Rossum пише: That sounds a bit excessive. Is there a recent incident that inspired this proposal? The concrete inspiration is issue32159 [1]. I am still not sure that removing these scripts is needed. But there were other cases in which I was not sure about the rationale of removing files. https://bugs.python.org/issue32159 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
On 11/29/2017 07:26 PM, Serhiy Storchaka wrote: [...] Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that similar file existed. All removals are tracked by Git, necessarily. It's the command to show them that's not obvious (unless you're Finnish): git log --oneline --diff-filter=D --summary -- :^/Misc/NEWS.d/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing files from the repository
Hm. For the file used for lookup, I see the point of keeping it. But in general, I don't see the point of keeping files we no longer need -- that's what VCS systems are for! On Wed, Nov 29, 2017 at 2:28 PM, Serhiy Storchaka wrote: > 29.11.17 21:00, Guido van Rossum пише: > >> That sounds a bit excessive. Is there a recent incident that inspired >> this proposal? >> > > The concrete inspiration is issue32159 [1]. I am still not sure that > removing these scripts is needed. But there were other cases in which I was > not sure about the rationale of removing files. > > https://bugs.python.org/issue32159 > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% > 40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Third and hopefully final post: PEP 557, Data Classes
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. The only significant changes since the last version are: - changing the "compare" parameter to be "order", since that more accurately reflects what it does. - Having the combination of "eq=False" and "order=True" raise an exception instead of silently changing eq to True. There were no other issues raised with the previous version of the PEP. So with that, I think it's ready for a pronouncement. Eric. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes
I plan to accept this on Monday if no new objections are raised. On Nov 29, 2017 3:28 PM, "Eric V. Smith" wrote: > I've posted a new version of PEP 557, it should soon be available at > https://www.python.org/dev/peps/pep-0557/. > > The only significant changes since the last version are: > > - changing the "compare" parameter to be "order", since that more > accurately reflects what it does. > - Having the combination of "eq=False" and "order=True" raise an exception > instead of silently changing eq to True. > > There were no other issues raised with the previous version of the PEP. > > So with that, I think it's ready for a pronouncement. > > Eric. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% > 40python.org > ___ Python-Dev mailing list [email protected] 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
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 > [email protected] > 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 [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes
On 11/29/2017 03:26 PM, Eric V. Smith wrote: > I've posted a new version of PEP 557, it should soon be available at > https://www.python.org/dev/peps/pep-0557/. > > The only significant changes since the last version are: > > - changing the "compare" parameter to be "order", since that more > accurately reflects what it does. > - Having the combination of "eq=False" and "order=True" raise an > exception instead of silently changing eq to True. > > There were no other issues raised with the previous version of the PEP. Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is. Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__
2017-11-12 10:24 GMT+01:00 Nick Coghlan :
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
I understand the rationale of the PEP, but I dislike the proposed
implementation.
End users will start to get warnings that they don't understand and
cannot fix, so these warnings would just be annoying.
For scripts written to only be run once and then deleted, again, these
warnings are just annoying since the script is going to be deleted
anyway.
It's like the annoying ResourceWarning (in debug mode) when I write
open(filename).read() in the REPL. I know that it's bad, but the code
will only be run once and lost when I quit the REPL, so who cares?
(not me, stop bothering me with good programming practices, I do know
them, let me write crappy code!) On the REPL case, I have no strong
opinion.
For developers who want to see warnings, the warnings are not shown
for applications using an entry point and any code base larger than a
single file (warnings outside the __main__ module).
--
In practice, I'm running tests with python -Wd (to see ResourceWarning
in my case), and I'm happy with that :-) If tests pass with -Wd,
you're good.
This is why I implemented a new "development mode", python3 -X dev, in
Python 3.7 which "shows all warnings except of BytesWarning". (This
mode is already mentioned in Nick's PEP.)
https://docs.python.org/dev/using/cmdline.html#id5
My advice is to always run your tests with -X dev. If they pass with
-X dev, you are good.
I'm not even sure that developers should use -X dev to test their code
manually. I see it as a "cheap linter". I don't want to run a linter
each time I run Python.
The "-X dev" option is smarter than -Wd: it adds the default filter
*at the end*, to respect -b and -bb options for the BytesWarning.
Release build:
$ ./python -c 'import pprint, warnings; pprint.pprint(warnings.filters)'
[('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0)]
-Wd on the release build adds a filter at the start:
$ ./release.python -Wd -c 'import pprint, warnings;
pprint.pprint(warnings.filters)'
[('default', None, , None, 0), <~~~ HERE
('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0),
('ignore', None, , None, 0)]
Debug build:
$ ./python -c 'import pprint, warnings; pprint.pprint(warnings.filters)'
[('ignore', None, , None, 0),
('default', None, , None, 0)]
-X dev adds a default filter *at the end*:
$ ./python -X dev -c 'import pprint, warnings; pprint.pprint(warnings.filters)'
[('ignore', None, , None, 0),
('default', None, , None, 0),
('default', None, , None, 0)] <~~~ HERE
Note: you can combine -X dev with -W if you want ;-) (It works as expected.)
Victor
___
Python-Dev mailing list
[email protected]
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
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes
On 11/29/2017 6:51 PM, Carl Meyer wrote: On 11/29/2017 03:26 PM, Eric V. Smith wrote: I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. The only significant changes since the last version are: - changing the "compare" parameter to be "order", since that more accurately reflects what it does. - Having the combination of "eq=False" and "order=True" raise an exception instead of silently changing eq to True. There were no other issues raised with the previous version of the PEP. Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is. Oops, sorry about that! I think you're probably right. attr.has(), which is the equivalent attrs API, returns True for both classes and instances (although interestingly, the code only talks about it working on classes). https://github.com/ericvsmith/dataclasses/issues/99 Eric. ___ Python-Dev mailing list [email protected] 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
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 < [email protected]> 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mariocj89%40gmail.com > ___ Python-Dev mailing list [email protected] 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
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 [email protected] 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
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer wrote: > On 11/29/2017 03:26 PM, Eric V. Smith wrote: > > I've posted a new version of PEP 557, it should soon be available at > > https://www.python.org/dev/peps/pep-0557/. > > > > The only significant changes since the last version are: > > > > - changing the "compare" parameter to be "order", since that more > > accurately reflects what it does. > > - Having the combination of "eq=False" and "order=True" raise an > > exception instead of silently changing eq to True. > > > > There were no other issues raised with the previous version of the PEP. > > Not quite; I also raised the issue of isdataclass(ADataClass) returning > False. I still think that's likely to be a cause of bug reports if left > as-is. > I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
