[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/26/2020 9:10 PM, Ethan Furman wrote: First off, thank you for being so patient -- trying to champion a PEP can be exhausting. On 03/26/2020 05:22 PM, Dennis Sweeney wrote: So now if I understand the dilemma up to this point we have: Benefits of writing ``return self`` in the PEP:     a

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/25/2020 1:36 PM, Dennis Sweeney wrote: I'm removing the tuple feature from this PEP. So now, if I understand correctly, I don't think there's disagreement about behavior, just about how that behavior should be summarized in Python code. I think that's right. Ethan Furman wrote: It

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/24/2020 7:21 PM, Dennis Sweeney wrote: It seems that there is a consensus on the names ``removeprefix`` and ``removesuffix``. I will update the PEP accordingly. I'll also simplify sample Python implementation to primarily reflect *intent* over strict type-checking correctness, and I'll

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/24/2020 3:30 PM, Steve Dower wrote: On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/23/2020 12:02 PM, Rhodri James wrote: On 23/03/2020 14:50, Dan Stromberg wrote: I tend to be mistrustful of code that tries to guess the best thing to do, when something expected isn't found. How about: def cutprefix(self: str, pre: str, raise_on_no_match: bool=False, /) -> str:

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/22/2020 12:25 PM, Paul Ganssle wrote: Sorry, I think I accidentally left out a clause here - I meant that the rationale for /always returning a 'str'/ (as opposed to returning a subclass) is missing, it just says in the PEP: The only difference between the real implementation and the

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/22/2020 1:42 AM, Nick Coghlan wrote: On Sun, 22 Mar 2020 at 15:13, Cameron Simpson wrote: On 21Mar2020 12:45, Eric V. Smith wrote: On 3/21/2020 12:39 PM, Victor Stinner wrote: Well, if CPython is modified to implement tagged pointers and supports storing a short strings (a few latin1

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/21/2020 2:09 PM, Steven D'Aprano wrote: On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote: On 3/21/2020 11:20 AM, Ned Batchelder wrote: Why be so prescriptive? The semantics of these functions should be about what the resulting string contains.  Leave it to implementors

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

shorter than the whole string. Agreed (except the string passed to startswith should be the same as the one used in cutprefix!). Eric Victor Le sam. 21 mars 2020 à 17:45, Eric V. Smith a écrit : On 3/21/2020 12:39 PM, Victor Stinner wrote: Well, if CPython is modified to implement tagged point

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

t/whatever took place, other than comparing via equality, not identity. Eric Victor Le sam. 21 mars 2020 à 17:23, Eric V. Smith a écrit : On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 202

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 3/21/2020 11:20 AM, Ned Batchelder wrote: On 3/20/20 9:34 PM, Cameron Simpson wrote: On 20Mar2020 13:57, Eric Fahlgren wrote: On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney wrote: If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then ``s.cutprefix(pre)`` returns a

[Python-Dev] Re: Looking for a sponsor and feedback on PEP 616: string methods for removing prefixes and suffixes

I'll sponsor it. Eric On 3/20/2020 11:29 AM, Dennis Sweeney wrote: Hello all! I'm a relatively new contributor looking for a Core Dev sponsor for the following PEP: https://github.com/python/peps/pull/1332 Related: - Python-Ideas Thread:

[Python-Dev] Re: How to respond to repeated bad ideas

On 3/3/2020 2:18 AM, Serhiy Storchaka wrote: 03.03.20 01:03, Skip Montanaro пише: Atm we don't have an index of ideas, apart from pep 3099, and I'm not sure we can make one (can we?), so I do not see a way to prevent this from happening. Maybe an informational PEP which briefly lists

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 9:14 AM, Miro Hrončok wrote: On 24. 01. 20 14:02, Eric V. Smith wrote: I think the concern is that with removing so many deprecated features, we're effectively telling libraries that if they want to support 3.9, they'll have stop supporting 2.7. And many library authors aren't

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote: On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote: The proposal is to give one year to project maintainers to drop Python 2.7 support, since Python 2.7 end of support just happened a few weeks ago

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 2:02 PM, Serhiy Storchaka wrote: 21.01.20 12:37, Eric V. Smith пише: Yes (I wrote a lot of that), but '.17g' doesn't mean to always show 17 digits. See https://github.com/python/cpython/blob/master/Python/pystrtod.c#L825 where the repr (which is format_code =='r') is translated

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 1:32 PM, Chris Angelico wrote: On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote: The reason repr adds the '.0' that 'g' does not is to avoid this problem: >>> type(eval(repr(17.0))) == type(17.0) True >>> type(eval(format(17.0, '.17g'))) == type(17.0) Fal

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 11:52 AM, Steven D'Aprano wrote: I don't really care whether there's documentation for __str__() or __repr__() or something else. I'm just thinking that there should be some way to guarantee a well defined "useful" float output formatting.

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/21/2020 4:32 AM, Serhiy Storchaka wrote: 21.01.20 10:37, Eric V. Smith пише: For what it's worth, float's repr internally uses a format of '.17g'. So, format(value, '.17g') will be equal to repr(f), where f is any float. It was in Python 2, but since Python 3.1 it returns the shortest

[Python-Dev] Re: Documenting Python's float.__str__()

On 1/20/2020 10:59 PM, Karl O. Pinc wrote: Hello, There appears to be extremely minimal documentation on how floats are formatted on output. All I really see is that float.__str__() is float.__repr__(). So that means that float->str->float does not result in a different value. It would be

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

On 12/16/2019 3:05 AM, Kyle Stanley wrote: Chris Angelico wrote: > ANY object can be passed to str() in order to get some sort of valid > printable form. The awkwardness comes from the fact that str() > performs double duty - it's both "give me a printable form of this > object" and "decode

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/2019 3:35 PM, Christian Heimes wrote: On 03/12/2019 21.04, Ethan Furman wrote: On 12/03/2019 09:31 AM, Guido van Rossum wrote: I think it’s too soon to worry about this. I don’t see a reason to harass people who maintain code based that were just recently migrated. I'm happy to go

[Python-Dev] Re: Pass the Python thread state to internal C functions

On 11/12/2019 5:03 PM, Victor Stinner wrote: Hi, Are you ok to modify internal C functions to pass explicitly tstate? The last time we discussed this, there was pushback due to performance concerns. I don't recall if that was actually measured, or just a vague unease. I've long advocated

[Python-Dev] Re: Migrate typing in builtin

Ivan (who you cc'd) is a good start! Eric On 10/8/2019 8:35 AM, Philippe Prados wrote: Glups. I am not an expert of Pyhton source code. May be after this patch ;-) I think I should discuss with the authors of the module typing, to identify the best strategy. Who is he ? Philippe Le mar.

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 9/29/2019 5:13 PM, Victor Stinner wrote: It seems simpler to me to pass the structure size rather than the Python version. It avoids the risk of updating the structure without update the Python version. I also avoids to have to change the Python version immediately when PyConfig is modified.

[Python-Dev] Re: The Python 2 death march

I think Ned's concerns are real, and the sunset-python-2 page could use some wordsmithing to explain that even though support ends on Jan 1, there will be a wrap-up release some time after that, but it won't incorporate any changes made or proposed after Jan 1. Another place where that

[Python-Dev] Re: python3 -bb and hash collisions

On 9/10/2019 2:12 PM, Chris Angelico wrote: On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth wrote: On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka wrote: 22.06.19 01:08, Daniel Holth пише: Thanks. I think I might like an option to disable str(bytes) without disabling str != bytes. Unless

[Python-Dev] Re: What to do about invalid escape sequences

On 8/14/2019 11:02 AM, Random832 wrote: On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: Please no more combinations. The presence of both legal and illegal combinations is already a mild nightmare for processing and testing. idlelib.colorizer has the following re to detest legal

[Python-Dev] Re: What to do about invalid escape sequences

On 8/12/2019 2:52 AM, Greg Ewing wrote: Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple prefixes combine in the way you would expect

[Python-Dev] Re: What to do about invalid escape sequences

On 8/11/2019 4:18 PM, Glenn Linderman wrote: On 8/11/2019 2:50 AM, Steven D'Aprano wrote: On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: Or invent "really raw" in some spelling, such as rr"c:\directory\" or e for exact, or x for exact, or "c:\directory\" And that brings me

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 10:30 PM, Rob Cliffe via Python-Dev wrote: On 10/08/2019 23:30:18, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that

[Python-Dev] Re: An f-string issue [Was: Re: Re: What to do about invalid escape sequences]

n 8/10/2019 7:46 PM, Glenn Linderman wrote: Because of the "invalid escape sequence" and "raw string" discussion, when looking at the documentation, I also noticed the following description for f-strings: Escape sequences are decoded like in ordinary string literals (except when a literal is

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 2:28 PM, Jonathan Goble wrote: On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: I find the "Our deprecation warnings were even less visible than normal" argument for extending the deprecation period compelling. Outsider's 2 cents from reading this discussion (with no personal

[Python-Dev] Re: PEP 572 TargetScopeError

On 8/9/2019 11:41 AM, Tim Peters wrote: [Guido] I don't see how this debate can avoid a vote in the Steering Council. FWIW, I found Nick's last post wholly persuasive: back off to SyntaxError for now, and think about adding a more specific exception later for _all_ cases (not just walrus) in

[Python-Dev] Re: PEP 572 TargetScopeError

On 8/8/2019 7:28 PM, Barry Warsaw wrote: On Aug 8, 2019, at 14:58, Steven D'Aprano wrote: It's not a syntax error. There's nothing wrong with the syntax per-say: we still have ``target := expression``. There's a problem with the *semantics* not the syntax. I’m not sure that distinction is

[Python-Dev] Re: What to do about invalid escape sequences

On 8/5/2019 4:30 PM, raymond.hettin...@gmail.com wrote: Thanks for weighing in. I think this is an important usability discussion. IMO it is the number one issue affecting the end user experience with this release. If we could get more people to actively use the beta release, the issue

[Python-Dev] Re: Comparing dict.values()

On 7/26/2019 8:24 AM, Greg Ewing wrote: Steven D'Aprano wrote: But the basic semantics hasn't really changed: two (multi)sets of values are equal if they have the same individual values, regardless of order. Why regardless of order? Dicts have an ordering nowadays. Why shouldn't that

[Python-Dev] Re: Comparing dict.values()

On 7/25/2019 4:19 PM, Kyle Stanley wrote: Serhiy Storchaka wrote: Actually, the == operator cannot return NotImplemented. Thanks for the clarification. What is the reason for this limitation and is it only possible for the `==` operator to return one of `None`, `False`, or `True`? It

[Python-Dev] Re: Comparing dict.values()

7/25/2019 6:00 AM, Eric V. Smith wrote: On 7/25/2019 4:27 AM, Kyle Stanley wrote: Serhiy Storchaka wrote: Is there any precedence of raising an exception in the equality comparison? Does 3 == "3" returning False make more sense to you? Personally, I don't find

[Python-Dev] Re: Comparing dict.values()

On 7/25/2019 4:27 AM, Kyle Stanley wrote: Serhiy Storchaka wrote: Is there any precedence of raising an exception in the equality comparison? Does 3 == "3" returning False make more sense to you? Personally, I don't find ``3 == "3"`` to be an equivalent comparison to ``d0.values() ==

[Python-Dev] Re: Comparing dict.values()

On 7/24/2019 1:30 PM, Brett Cannon wrote: Serhiy Storchaka wrote: o you propose? What is the use case for it? If you want to compare dict value views as ordered sequences, it can be surprised that d1.values() != d2.values() when d1 == d2. It will be inconsistent with orderless comparison of

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

You’ll have to manually re-send it. -- Eric V. Smith (301) 502-0945 cell > On Jul 21, 2019, at 11:23 AM, ka...@beholdingeye.com wrote: > > Sorry for posting to the wrong list! If this could be moved I'd appreciate it. > ___ > Python-D

Re: [Python-Dev] Python in next Windows 10 update

That’s great, Steve. Thanks for all of the work (by you and others) on this. -- Eric V. Smith True Blade Systems, Inc (301) 859-4544 > On May 21, 2019, at 4:30 PM, Steve Dower wrote: > > Hi all > > Just sharing this here because I think it's important for us to be aware

Re: [Python-Dev] ast changes for "debug" f-strings

On 5/20/2019 10:32 AM, Batuhan Taskaya wrote: > This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedValue alone. I didn't for three reasons: it was expedient; it didn't require a lot of surgery to f-string parsing, which the extra Constant

[Python-Dev] ast changes for "debug" f-strings

I added an optional "expr_text" field to the FormattedValue node, which represents the text of the expression in a "debug" f-string expression. So in f'{x=}', expr_text would be "x=". This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left

Re: [Python-Dev] Redoing failed PR checks

I think you can close and reopen the PR. That’s what I’m trying on my blocked PR. -- Eric V. Smith True Blade Systems, Inc (301) 859-4544 > On May 8, 2019, at 10:07 AM, Mark Shannon wrote: > > Hi, > > How do I redo a failed PR check? > The appveyor failure for https:/

Re: [Python-Dev] Easier debugging with f-strings

. Yeah, it's all over the place. At this stage, I think discussing it here is best. On Mon, May 06, 2019 at 08:39:41PM -0400, Eric V. Smith wrote: After that lightning talk, Larry and I talked about it some more, and for a number of reasons decided that it would make more sense if the syntax

Re: [Python-Dev] Easier debugging with f-strings

Hi, Tim. Your name came up frequently as a target for this use case. I think we’ve come up with a pretty good solution. Now if I could only convince my clients to upgrade from 2.7! I’ve heard about these f-string things, and I think I would enjoy using them. Eric > On May 7, 2019, at

Re: [Python-Dev] Easier debugging with f-strings

On 5/7/19 9:49 AM, Barry Warsaw wrote: On May 7, 2019, at 03:52, Steve Holden wrote: What's not to like? My only complaint is that you steadfastly refuse use Guido’s time machine keys to make this available in 3.7. Open a feature request here: https://github.com/asottile/future-fstrings

[Python-Dev] Easier debugging with f-strings

Last fall Larry Hastings made a suggestion for adding a way to make so-called "print-based debugging" easier with f-strings. Basically the approach is that f-strings would be able to produce the text of the expression and the value of that expression, without repeating the expression in the

Re: [Python-Dev] Unicode identifiers in test files?

On 5/4/19 3:54 AM, Eric V. Smith wrote: On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression

Re: [Python-Dev] Unicode identifiers in test files?

On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise

[Python-Dev] Unicode identifiers in test files?

Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I

Re: [Python-Dev] configparser: should optionxform be idempotent?

> On Mar 8, 2019, at 12:12 AM, Steven D'Aprano wrote: > >> On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote: >> >> In any case, the word is easy enough to avoid in this case. > > I don't think we should avoid using standard terminology even if we can. > Knowledge of standard

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 6:16 PM, Eric V. Smith wrote: On 1/24/2019 5:52 PM, Chris Angelico wrote: +1. If it's something that the peephole optimizer is already allowed to change (eg "1"+"1" is constant-folded) and there is absolutely no way that it can ever be changed at run time, the

Re: [Python-Dev] Add more SyntaxWarnings?

On 1/24/2019 5:52 PM, Chris Angelico wrote: On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote: We could say that implementations are allowed to raise errors at compile time instead of run time, but aren't required to. Then it becomes a matter of "quality of implementation". For literal

Re: [Python-Dev] C API changes

On 11/26/2018 7:08 PM, Larry Hastings wrote: On 11/23/18 5:15 AM, Armin Rigo wrote: Also FWIW, my own 2 cents on the topic of changing the C API: let's entirely drop ``PyObject *`` and instead use more opaque handles---like a ``PyHandle`` that is defined as a pointer-sized C type but is not

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

> On Oct 12, 2018, at 7:03 PM, Martin Panter wrote: > >> On 12/10/2018, Eric V. Smith wrote: >>> On 10/12/2018 5:17 AM, Tal Einat wrote: >>> >>> The latest stable releases can always be found on the `Python download page >>> -<https://www.p

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

On 10/12/2018 5:17 AM, Tal Einat wrote: The latest stable releases can always be found on the `Python download page -`_. There are two recommended production-ready -versions at this point in time, because at the moment there are two branches of -stable

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

Yes, it’s https://bugs.python.org/issue34776 -- Eric > On Sep 27, 2018, at 12:05 PM, Ivan Levkivskyi wrote: > > Do we have a b.p.o. issue about this? If no, then I would recommend to open > one, so that we will not loose track of this. > > -- > Ivan > > > >> On Sat, 22 Sep 2018 at 16:32,

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

On 9/22/2018 12:41 PM, Guido van Rossum wrote: This is a good catch -- thanks for bringing it up. I'm adding Eric Smith (author of dataclasses) and Ivan Levkivskyi (co-author of typing) as well as Łukasz Langa (author of PEP 563) to the thread to see if they have further insights. I don't

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On 9/19/2018 9:25 PM, Barry Warsaw wrote: On Sep 19, 2018, at 20:34, Gregory P. Smith wrote: There's ongoing work to rewrite zipimport.c in python using zipfile itself Great timing! Serhiy’s rewrite of zipimport in Python has just landed in 3.8, although it doesn’t use zipfile. What’s in

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 8:04 PM, Victor Stinner wrote: Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit : f'{type(obj)}' becomes type(obj).__format__(''), so you can return something other than __str__ or __repr__ does. It's only by convention that an object's __format__ returns __str__: it need

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/13/2018 5:52 PM, Petr Viktorin wrote: On 09/13/18 14:08, Victor Stinner wrote: Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit : * Add !t conversion to format string I'm strongly opposed to this. This !t conversion would not be widely applicable enough to be generally useful

Re: [Python-Dev] bpo-34595: How to format a type name?

On 9/12/2018 8:33 PM, Victor Stinner wrote: Hi, For the type name, sometimes, we only get a type (not an instance), and we want to format its FQN. IMHO we need to provide ways to format the FQN of a type for *types* and for *instances*. Here is my proposal: * Add !t conversion to format

Re: [Python-Dev] Schedule of the Python 3.7.1 release?

On 9/5/2018 6:22 AM, Christian Heimes wrote: On 2018-09-05 11:56, Victor Stinner wrote: Hi, Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 scheduled. I wanted to reply when I saw that it was scheduled for 2 months ago: "3.7.1: 2018-07-xx"

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 8:14 PM, Barry Warsaw wrote: On Aug 23, 2018, at 15:23, Eric V. Smith wrote: On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update

Re: [Python-Dev] Python 2.7 EOL date

On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update We could probably make it more clear in this section and/or in https://www.python.org/dev/peps/pep-0373/#id4

Re: [Python-Dev] Finding Guido's replacement

On 7/24/2018 4:32 PM, Gregory P. Smith wrote: On Tue, Jul 24, 2018 at 12:27 PM Abdur-Rahmaan Janhangeer mailto:arj.pyt...@gmail.com>> wrote: not googler i mean google. they requested a change to a pep "They"?  nah.  "Google LLC" did not request anything. People who happen to be working

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

On 7/8/2018 8:35 PM, Terry Reedy wrote: On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: I'll use this opportunity to remind you that 3.4 build is broken -- it can't be built from start to installer with the instructions given because of outside factors (CPython has migrated from Hg to

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:59 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote: I agree with Chris in this case. That said, there is at least one place where the grammar does forbid you from doing something that would otherwise make be allowable: decorators. @lookup[0

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 1:23 PM, Chris Angelico wrote: On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote: On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote: But the PEP 8 spellings are foo(x=1) and f(x := 1). The extra spacing makes it obvious that this isn't a regular named

Re: [Python-Dev] Call for prudence about PEP-572

On 7/8/2018 5:41 AM, Giampaolo Rodola' wrote: As for "assert" what I'm concern about is the proliferation of things like this:     class Foo:         def __init__(self):             assert self.x := fun1()             assert self.y := fun2()             assert self.z := fun3() When I look

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> On Jun 27, 2018, at 9:49 AM, Steven D'Aprano wrote: > >> On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: >>> On 6/27/2018 7:08 AM, Chris Angelico wrote: >>> It gets funnier with nested loops. Or scarier. I've lost the ability >>> to d

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/27/2018 7:08 AM, Chris Angelico wrote: It gets funnier with nested loops. Or scarier. I've lost the ability to distinguish those two. def test(): spam = 1 ham = 2 vars = [key1+key2 for key1 in locals() for key2 in locals()] return vars Wanna guess what that's gonna

Re: [Python-Dev] [python-committers] 3.7.0 / 3.6.6 Update: all systems go for final releases!

Congrats, Ned. Thank you for all of your hard work! -- Eric > On Jun 26, 2018, at 2:39 AM, Ned Deily wrote: > > A quick update: after many months we are at the finish line. We are on > track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on > 2018-06-27. Since 3.7.0rc1 shipped 2

Re: [Python-Dev] Stable ABI

On 6/3/2018 10:55 AM, Christian Tismer wrote: On 03.06.18 13:18, Ronald Oussoren wrote: On 3 Jun 2018, at 12:03, Christian Tismer wrote: ... I have written a script that scans all relevant header files and analyses all sections which are reachable in the limited API context. All macros

Re: [Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?

On 5/17/2018 3:01 PM, Larry Hastings wrote: I fed this into tokenize.tokenize(): b''' x = "\u1234" ''' I was a bit surprised to see \U in the output.  Particularly because the output (t.string) was a *string* and not *bytes*. For those (like me) who have no idea how to use

Re: [Python-Dev] What is the rationale behind source only releases?

On 5/16/18 4:34 AM, Serhiy Storchaka wrote: 16.05.18 07:35, Alex Walters пише: [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence And I wish that every author who suggested the idea for Python was familiar with the Chesterton's fence principle. Indeed! It's refreshing.

Re: [Python-Dev] PEP 572 and f-strings

> On May 12, 2018, at 9:03 AM, Chris Angelico <ros...@gmail.com> wrote: > >> On Sat, May 12, 2018 at 9:11 PM, Eric V. Smith <e...@trueblade.com> wrote: >> I don't think it matters to its acceptance, but PEP 572 should at least >> mention that the := syntax

[Python-Dev] PEP 572 and f-strings

I don't think it matters to its acceptance, but PEP 572 should at least mention that the := syntax means that you cannot use assignment expressions in f-strings. As I wrote in a python-ideas email, f'{x:=4}' already has a defined meaning (even if no one is using it). Eric

Re: [Python-Dev] Slow down...

> On May 8, 2018, at 11:48 AM, Brett Cannon wrote: > > > >> On Tue, 8 May 2018 at 08:26 Craig Rodrigues wrote: >>> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: >>> On May 7, 2018, at 11:49, Craig Rodrigues

Re: [Python-Dev] PEP 575: Unifying function/method classes

On 5/3/2018 6:22 AM, Jeroen Demeyer wrote: On 2018-05-03 11:30, Victor Stinner wrote: Please don't queue backward incompatible changes for Python 4.0. You should use the regular deprecation process. I don't really see how that can be done here. As Stefan said The problem is that this change

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On 4/27/2018 8:28 AM, Steven D'Aprano wrote: On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: Now we got standard library features requiring type annotation We do? Did I miss them? Which std lib features are you referring to? (That's not a rhetorical question -- maybe I have

Re: [Python-Dev] Timeline for Pull request reviews in 3.8

Hi, Anthony. On 4/5/2018 10:57 PM, Anthony Flury via Python-Dev wrote: Can anyone enlighten me on what the expected time-line is for reviewing pull requests made on 3.8. I can give you the timeline for releases. Unfortunately, volunteer time is short for reviews. I made a few simple fixes

Re: [Python-Dev] Subtle difference between f-strings and str.format()

On 3/29/2018 12:13 PM, Nick Coghlan wrote: On 29 March 2018 at 21:50, Eric V. Smith <e...@trueblade.com> wrote: #1 seems so complex as to not be worth it, given the likely small overall impact of the optimization to a large program. If the speedup really is sufficiently imp

Re: [Python-Dev] Subtle difference between f-strings and str.format()

On 3/29/2018 6:17 AM, Jeff Allen wrote: My credentials for this are that I re-worked str.format in Jython quite extensively, and I followed the design of f-strings a bit when they were introduced, but I haven't used them to write anything. Thanks for your work on Jython. And hop on the

Re: [Python-Dev] Subtle difference between f-strings and str.format()

I’d vote #3 as well. -- Eric > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka wrote: > > There is a subtle semantic difference between str.format() and "equivalent" > f-string. > >'{}{}'.format(a, b) >f'{a}{b}' > > In the former case b is evaluated before

Re: [Python-Dev] descriptor __set_name__ and dataclasses

On 3/26/18 11:10 AM, Eric V. Smith wrote: On 3/26/18 11:08 AM, Nick Coghlan wrote: On 27 March 2018 at 00:40, Eric V. Smith <e...@trueblade.com> wrote: Would it be feasible to define `Field.__set_name__`, and have that call `default.__set_name__` when the latter exists, and be a

Re: [Python-Dev] descriptor __set_name__ and dataclasses

On 3/26/18 11:08 AM, Nick Coghlan wrote: On 27 March 2018 at 00:40, Eric V. Smith <e...@trueblade.com> wrote: https://bugs.python.org/issue33141 points out an interesting issue with dataclasses and descriptors. Given this code: from dataclasses import * class D: ""&qu

[Python-Dev] descriptor __set_name__ and dataclasses

https://bugs.python.org/issue33141 points out an interesting issue with dataclasses and descriptors. Given this code: from dataclasses import * class D: """A descriptor class that knows its name.""" def __set_name__(self, owner, name): self.name = name def __get__(self,

Re: [Python-Dev] Fix strncpy warning with gcc 8 (#5840)

On 3/6/2018 6:52 AM, Serhiy Storchaka wrote: 06.03.18 12:34, Xiang Zhang пише: https://github.com/python/cpython/commit/efd2bac1564f8141a4eab1bf8779b412974b8d69 commit: efd2bac1564f8141a4eab1bf8779b412974b8d69 branch: master author: Siddhesh Poyarekar committer:

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 3/1/2018 1:02 AM, Nick Coghlan wrote: I'm assuming you meant "3.7.0b2" here (and similarly alpha->beta for the other version numbers below) Oops, yes. Thanks. So going back to original questions above, my suggestions are: 1. What happens when a frozen dataclass inherits from a

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic is inherited by subclasses which prevents them from assigning additional attributes: >>>

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 2/22/18 9:43 PM, Nick Coghlan wrote: On 22 February 2018 at 20:55, Eric V. Smith <e...@trueblade.com> wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characte

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

I've opened https://bugs.python.org/issue32953 to track this. On 2/22/18 5:55 AM, Eric V. Smith wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic

Re: [Python-Dev] [Python-checkins] Exhaustively test dataclass hashing when no hash= value is provided. This is in anticipation of changing how non-default hashing is handled. (GH-5834) (GH-5889)

Thanks. Do you know if this gets backported to 3.7? Eric. On 2/25/2018 1:36 PM, Terry Reedy wrote: On 2/25/2018 11:56 AM, Eric V. Smith wrote: +    # specify any value in the deecorator). I fixed this through the web interface.  The CI now knows that a comment change does not need

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 2/22/18 9:43 PM, Nick Coghlan wrote: On 22 February 2018 at 20:55, Eric V. Smith <e...@trueblade.com> wrote: A related issue is that dataclasses derived from frozen dataclasses are automatically "promoted" to being frozen. @dataclass(frozen=True) ... class A

Re: [Python-Dev] Should the dataclass frozen property apply to subclasses?

On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic is inherited by subclasses which prevents them from assigning additional attributes: >>>

Re: [Python-Dev] Dataclasses, frozen and __post_init__

> On Feb 20, 2018, at 5:38 PM, Guido van Rossum <gu...@python.org> wrote: > >> On Tue, Feb 20, 2018 at 1:37 PM, Eric V. Smith <e...@trueblade.com> wrote: >>> On 2/17/2018 2:35 PM, Guido van Rossum wrote: >>> PS. I have to ponder why frozen dataclass

<    1   2   3   4   5   6   >