Re: [Python-Dev] [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

That's awesome! A great choice. Congrats, Łukasz. Eric. On 1/27/2018 4:02 PM, Barry Warsaw wrote: As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature freeze. I think we can all give Ned a huge round of applause for his amazing work as Release Manager for Python 3.

Re: [Python-Dev] Is static typing still optional?

On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: ... 2) Change the default value for "hash" from "None" to "False".  This might take a little effort because there is currently an oddity where setting hash=False causes

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 1:55 AM, Yury Selivanov wrote: On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan > wrote: [...] Currently the answers are: - A: not hashable - B: hashable (by identity) # Wat? - C: hashable (by field hash) - D: hashable (by identity)

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 3:42 AM, Ethan Furman wrote: On 01/28/2018 07:45 AM, Eric V. Smith wrote: On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: 2) Change the default value for "hash" from "None" to "False".  This might take a

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 4:01 AM, Raymond Hettinger wrote: On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote: I think it would be a bad design to have to opt-in to hashability if using frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can have either one wi

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires that a key’s hash value is immutable (if the obje

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:17 PM, Eric V. Smith wrote: On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote: On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: I should add: This is why you shouldn't override the default (hash=None) unless you know what the consequences are. Can I ask why you want to specify hash=True? hash=Non

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 12:33 AM, Nick Coghlan wrote: For 3.7, I think we should seriously considered just straight up disallowing the "hash=True, frozen=False" combination, and instead require folks to provide their own hash function in that case. "Accidentally hashable" (whether by identity or field hash)

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:38 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: However, I don't feel very strongly about this. As I've said, I expect the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: I was specifically talking about the case of a non-frozen, hashable class. If you want to make a class frozen and hashable, then: @dataclass(frozen=True) will do just that. The

Re: [Python-Dev] Dataclasses and correct hashability

On 2/6/18 2:40 PM, Ethan Furman wrote: On a different note, should the PEP be updated with the current signature? It still talks about hash=None being the default. Once we've reached an agreement, I'll update the PEP. I don't think we're there quite yet. Eric ___

Re: [Python-Dev] Dataclasses and correct hashability

Sorry for the late reply. Still recovering from a computer failure. My only concern with this approach is: what if you don’t want any __hash__ added? Say you want to use your base class’s hashing. I guess you could always “del cls.__hash__” after the class is created, but it’s not elegant. Th

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

On 2/17/2018 2:35 PM, Guido van Rossum wrote: PS. I have to ponder why frozen dataclasses don't use `__new__`. As I'm sure everyone is now aware after the rest of this discussion: it's because the returned object isn't really immutable. That said, I have threatened to create a decorator simi

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

> On Feb 20, 2018, at 5:38 PM, Guido van Rossum wrote: > >> On Tue, Feb 20, 2018 at 1:37 PM, Eric V. Smith wrote: >>> On 2/17/2018 2:35 PM, Guido van Rossum wrote: >>> PS. I have to ponder why frozen dataclasses don't use `__new__`. >> >> As I

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: >>> @dataclass(frozen=

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 wrote: A related issue is that dataclasses derived from frozen dataclasses are automatically "promoted" to being frozen. @dataclass(frozen=True) ... class A: ... i: int ... @dataclass ...

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?

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 characterist

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 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 is inherited by

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: >>> @dataclass(frozen=

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 non

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: Xiang Zhang date: 2018-03-06T

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

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

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 wrote: Would it be feasible to define `Field.__set_name__`, and have that call `default.__set_name__` when the latter exists, and be a no-op otherwise? A clever idea

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 formatting a. This is equiv

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

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 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 important for a particular piece of code

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 i

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 m

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] 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 wrote: >>> > >>> > Would it be reasonable to request a 10 year moratorium on m

[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] PEP 572 and f-strings

> On May 12, 2018, at 9:03 AM, Chris Angelico wrote: > >> On Sat, May 12, 2018 at 9:11 PM, Eric V. Smith wrote: >> 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

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

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 tokenize

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 t

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 week

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 retu

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

Re: [Python-Dev] Fwd: zipimport

On 6/2/2015 5:20 PM, Brett Cannon wrote: > > > On Tue, Jun 2, 2015 at 5:04 PM Rose Ames > wrote: > > At pycon I talked with a few people about bugs.python.org/issue19699 > . > The consensus seemed to be that zipimport wa

Re: [Python-Dev] PEP 0420: Extent of implementation? Specifically Python 2?

On 06/19/2015 11:21 AM, triccare triccare wrote: > Greetings, > > Will this PEP be implemented in Python 2? > > And, more generally, is there a way to know the extent of implementation > of any particular PEP? PEP 420 (namespace packages) will not be implemented in Python 2. I don't think there

[Python-Dev] PEP-498: Literal String Formatting

Following a long discussion on python-ideas, I've posted my draft of PEP-498. It describes the "f-string" approach that was the subject of the "Briefer string format" thread. I'm open to a better title than "Literal String Formatting". I need to add some text to the discussion section, but I think

Re: [Python-Dev] SSH to hg.p.o okay?

I was intermittently getting that earlier. I didn't change anything on my side and it started working, maybe 5 minutes later. -- Eric. > On Aug 7, 2015, at 11:19 PM, Steve Dower wrote: > > Is hg.python.org okay for others? I'm getting the following output from all > hg commands: > > sending

Re: [Python-Dev] SSH to hg.p.o okay?

On 8/8/2015 9:15 AM, Steve Dower wrote: > Eventually I updated Mercurial and then it worked, but that didn't make > a whole lot of sense. Maybe I caught it during some maintenance? > > Seems to be okay now though. I didn't make any changes on my end when it started working. I'm guessing maintenan

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/8/2015 9:08 PM, Tim Delaney wrote: > On 8 August 2015 at 11:39, Eric V. Smith <mailto:e...@trueblade.com>> wrote: > > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that w

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 1:38 PM, Brett Cannon wrote: > > > On Sun, 9 Aug 2015 at 01:07 Stefan Behnel <mailto:stefan...@behnel.de>> wrote: > > Eric V. Smith schrieb am 08.08.2015 um 03:39: > > Following a long discussion on python-ideas, I've posted my draft of &

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 8:24 PM, Peter Ludemann wrote: > What if logging understood lambda? (By testing for types.FunctionType). > This is outside PEP 498, but there might be some recommendations on how > "lazy" evaluation should be done and understood by some functions. > > e.g.: > log.info

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 9:02 PM, Eric V. Smith wrote: > On 8/9/2015 8:24 PM, Peter Ludemann wrote: >> What if logging understood lambda? (By testing for types.FunctionType). >> This is outside PEP 498, but there might be some recommendations on how >> "lazy" evaluation should

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 08/10/2015 10:18 AM, Victor Stinner wrote: > Hi, > > I read the PEP but I don't understand how it is implemented. For me, it > should be a simple preprocessor: > > - f'x={x}' is replaced with 'x={0}'.format(x) by the compiler > - f'x={1+1}' is replaced with 'x={0}'.format(1+1) > - f'x={foo()!r

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:07 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] >> That said, there *is* one small corner where I believe f-strings add >> something helpful to the language. There is no really concise way to spell: >> >> collections.ChainM

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:26 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > >> Which brought to mind a certain thought. While I don't like: >> >> f'My name is {name}, my age next year is {age+1}' >> >> I wouldn't have any similar objection to: >> >>'My

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:31 PM, Barry Warsaw wrote: > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > >> I think I would be happy with f-strings, or perhaps i-strings if we use >> Nick's ideas about internationalisation, and limit what they can evaluate to >> name lookups, attribute lookups, and in

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:44 PM, Yury Selivanov wrote: > > > On 2015-08-10 2:37 PM, Eric V. Smith wrote: >>> Besides, any expression you have to calculate can go in a local that >>> will get >>> >interpolated. The same goes for any !r or other formatting >>&g

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 8/10/2015 6:22 PM, Victor Stinner wrote: > Le lundi 10 août 2015, Eric V. Smith <mailto:e...@trueblade.com>> a écrit : > > On 08/10/2015 10:18 AM, Victor Stinner wrote: > > Hi, > > > > I read the PEP but I don't understand how it is imp

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 6:54 PM, Victor Stinner wrote: > > PEP 498: > > """ > > > Leading whitespace in expressions is skipped > > > Because expressions may begin with a left brace ('{'), there is a > problem when parsing such expressions. For

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 8/10/2015 7:23 PM, Victor Stinner wrote: > But in any event, I don't see the distinction between calling > str.format(), and calling each object's __format__ method. Both are > compliant with the PEP, which doesn't specify exactly how the > transformation is done. > > > When I

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 7:26 PM, Victor Stinner wrote: > Le mardi 11 août 2015, Eric V. Smith <mailto:e...@trueblade.com>> a écrit : > > It sounds like you want to disallow leading spaces just to > disallow this one type of expression. > > > I would like

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:00 PM, MRAB wrote: > On 2015-08-11 00:26, Victor Stinner wrote: >> Le mardi 11 août 2015, Eric V. Smith > <mailto:e...@trueblade.com>> a écrit : >> >> It sounds like you want to disallow leading spaces just to >> disallow this one type

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:04 PM, Victor Stinner wrote: > > > Le mardi 11 août 2015, MRAB > a écrit : > > I'm a little bit surprised at seeing this: (...) > > > We may modify str.format to ignore leading spaces, but IMHO it should > not be motivated by the PEP. Agr

Re: [Python-Dev] PEP-498: Literal String Formatting

g literal functionality, like triple quotes, > line-ending backslashes, as MRAB mentions, in addition to the > concatenation rules. Good idea. Eric. > -Mike > > > On 08/07/2015 06:39 PM, Eric V. Smith wrote: >

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 08/10/2015 07:23 PM, Victor Stinner wrote: > > > Le mardi 11 août 2015, Eric V. Smith <mailto:e...@trueblade.com>> a écrit : > > Oops, I was thinking of going the other way (str.format -> f''). Yes, I > think you're correct. > > &

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/11/2015 11:09 AM, Alexander Walters wrote: > This may seam like a simplistic solution to i18n, but why not just add a > method to string objects (assuming we implement f-strings) that just > returns the original, unprocessed string. If the string was not an > f-string, it just returns self.

Re: [Python-Dev] PEP-498: Literal String Formatting

concrete changes to PEP 501. Eric. > > > On 11.08.2015 17:16, Eric V. Smith wrote: >> On 08/11/2015 11:09 AM, Alexander Walters wrote: >>> This may seam like a simplistic solution to i18n, but why not just add a >>> method to string objects (assuming we implement

Re: [Python-Dev] PEP-498: Literal String Formatting

eal one way or the other. I'll incorporate the rest of your feedback (and others) when I get back to a real computer. -- Eric. Top-posted from my phone. > On Aug 16, 2015, at 10:21 AM, Paul Moore wrote: > >> On 8 August 2015 at 02:39, Eric V. Smith wrote: >> Follo

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/16/2015 03:37 PM, Guido van Rossum wrote: > On Sun, Aug 16, 2015 at 8:55 PM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: > > Thanks, Paul. Good feedback. > > > Indeed, I smiled when I saw Paul's post. > > > Triple quoted and raw s

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/17/2015 2:24 PM, Guido van Rossum wrote: > On Mon, Aug 17, 2015 at 7:13 AM, Eric V. Smith <mailto:e...@trueblade.com>> wrote: > > [...] > My current plan is to replace an f-string with a call to .format_map: > >>> foo = 100 > >>>

[Python-Dev] PEP 498: Literal String Interpolation

PEP 498 adds a new string prefix which allows simpler string formatting by embedding expressions inside string literals. The expressions are evaluated and inserted into the resulting string value: >>> import datetime >>> name = 'Fred' >>> age = 50 >>> anniversary = datetime.date(1991, 10, 12) >>>

Re: [Python-Dev] PEP 498: Literal String Interpolation

On 08/30/2015 09:41 AM, Eric V. Smith wrote: > I have a complete implementation of PEP 498. I'll shortly create an > issue and attach the patch to it. Issue 24965. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.

Re: [Python-Dev] PEP 498: Literal String Interpolation

On 8/31/2015 4:08 PM, Yury Selivanov wrote: > > > On 2015-08-31 9:10 AM, Nick Coghlan wrote: >> On 30 August 2015 at 23:41, Eric V. Smith wrote: >>> Note there's a companion PEP 501 which extends this idea by delaying >>> converting the expression into

Re: [Python-Dev] PEP 498: Literal String Interpolation

On 8/31/2015 5:07 PM, Eric V. Smith wrote: > That's all correct. I have to say that I like PEP 501 mainly for its > non-string use cases. That is, interpolators that don't produce strings. > Note that this isn't possible with PEP 502's proposal. Let me rephrase t

[Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

I've made a number of small changes to PEP 498. I don't think any of the changes I've made in the last week are substantive. Mostly I've clarified how it works and removing some limitations. The only meaningful change is that expressions are now surrounded by parens before they're evaluated. This a

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:28 PM, Nathaniel Smith wrote: > On Sep 5, 2015 9:20 AM, "Guido van Rossum" > wrote: >> >> The processing of f-strings described by the PEP uses several phases: >> >> - find the end of the string (the final quote[s]) using the same > algorithm used for all str

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:14 PM, Gustavo Carneiro wrote: > Why not allow string concatenation without plus sign only if/when the > implementation becomes optimised to allow compile time concatenation? > This makes it crystal clear whether the concatenation is compile time or > runtime. If we allow it now, it'

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

> Actually, my current implementation doesn't use the lexer, although I > suppose it could. I'm currently manually scanning the string, keeping > track of strings and parens. To find the end of an expression, it looks > for a '!', ':', or non-doubled '}', not inside of a string or (), [], or > {}.

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 3:23 PM, Nathaniel Smith wrote: > On Sep 5, 2015 11:32 AM, "Eric V. Smith" <mailto:e...@trueblade.com>> wrote: >> Ignore the part about non-doubled '}'. The actual description is: >> >> To find the end of an expression, it looks fo

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 12:18 PM, Guido van Rossum wrote: > On Sat, Sep 5, 2015 at 2:10 AM, haypo s > wrote: > > (is it possible to indent and comment code inside a f-string?) > > > Now that's an interesting question. I think the answer must be No, > because we don't wan

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 7:12 PM, Nathaniel Smith wrote: > On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith wrote: >> On 9/5/2015 3:23 PM, Nathaniel Smith wrote: >>> On Sep 5, 2015 11:32 AM, "Eric V. Smith" >> <mailto:e...@trueblade.com>> wrote: >>>> Ignore

Re: [Python-Dev] PEP 498: Naming

On 09/08/2015 10:20 AM, Alexander Belopolsky wrote: > > On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller > wrote: > > To my knowledge there was i for interpolation, t for template, and e > for expression suggested. Any better ideas? > > > I believe someone

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/8/2015 8:27 PM, Guido van Rossum wrote: > I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who > contributed. A lot of thought and discussion went into this -- Eric > himself was against the idea when it first came up! Thanks, Guido. In the next few days I'll update the imp

[Python-Dev] PEP 498 (interpolated f-string) tweak

While finishing up the implementation of PEP 498, I realized that the PEP has an error. It says that this code: f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi' Is equivalent to: 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def' + str(expr3).__format__('') + 'ghi' But th

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/19/2015 3:22 PM, Serhiy Storchaka wrote: > On 19.09.15 14:03, Eric V. Smith wrote: >> While finishing up the implementation of PEP 498, I realized that the >> PEP has an error. It says that this code: >> >> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/19/2015 3:36 PM, Eric V. Smith wrote: > On 9/19/2015 3:22 PM, Serhiy Storchaka wrote: >> On 19.09.15 14:03, Eric V. Smith wrote: >>> Instead of calling __format__, I've changed the code generator to call >>> format(expr1, spec1). As an optimization, I might

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/20/2015 8:37 AM, Nick Coghlan wrote: > On 19 September 2015 at 21:03, Eric V. Smith wrote: >> Instead of calling __format__, I've changed the code generator to call >> format(expr1, spec1). As an optimization, I might add special opcodes to >> deal with this and

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka wrote: > >> On 20.09.15 16:51, Eric V. Smith wrote: >>> On 9/20/2015 8:37 AM, Nick Coghlan wrote: >>>> On 19 September 2015 at 21:03, Eric V. Smith wrote: >>>> Instead of calling __format__, I'

Re: [Python-Dev] Committing a bug fix

At the top of the file in the default branch, I see: What's New in Python 3.6.0 alpha 1? Which has a few things in it. Eric. On 9/28/2015 7:30 PM, Guido van Rossum wrote: > It used to be tradition to keep old news sections. Looks like the last > time we cleared it out was for 3.4.0. > > But it

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/21/2015 10:57 PM, Ryan Gonzalez wrote: > It mentions fr'...' as a formatted raw string but doesn't say anything > about rf'...'. Right now, in implementing PEP 498 support in Howl > (https://github.com/howl-editor/howl/pull/118 and > https://github.com/howl-editor/howl/commit/1e577da89efc1c1d

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/22/2015 7:32 AM, Eric V. Smith wrote: > On 10/21/2015 10:57 PM, Ryan Gonzalez wrote: >> It mentions fr'...' as a formatted raw string but doesn't say anything >> about rf'...'. Right now, in implementing PEP 498 support in Howl >> (https://git

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/22/2015 1:09 PM, Ryan Gonzalez wrote: > But it'd be weird now if fR worked but fbR didn't. Or bR (which is currently allowed) but not fbR in the future. Eric. > > On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze > wrote: > > On 22.10.2015 18:17, Ryan Gonzalez

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On Oct 27, 2015, at 4:39 PM, Mark Lawrence wrote: > >> On 27/10/2015 18:39, Sven R. Kunze wrote: >>> On 26.10.2015 20:54, Ethan Furman wrote: >>> You misunderstand -- the order of string prefixes does *not* matter, >>> so forcing us to use one is silly. >> >> I don't think so. >> >> It's better

[Python-Dev] Bytcode "magic tag"

In issue 25483 I'm adding an opcode to make f-string formatting more robust and faster. As part of that, I'm bumping the .pyc magic number. While doing that, I notice Lib/importlib/_bootstrap_external.h includes this comment: # Starting with the adoption of PEP 3147 in Python 3.2, every bump in m

Re: [Python-Dev] Bytcode "magic tag"

On 10/28/2015 10:19 AM, Barry Warsaw wrote: > On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote: > >> The "following table" is a comment, that contains a few references to >> the tag "cpython-", specifically cpython-32. It doesn't seem >>

Re: [Python-Dev] Bytcode "magic tag"

On 10/28/2015 10:22 AM, Eric Snow wrote: > On Wed, Oct 28, 2015 at 6:35 AM, Eric V. Smith wrote: >> Do I need to do anything else? Unlike what the comment in >> _boostrap_external.py suggests, this "magic tag" will not change every >> time a bytecode is added,

Re: [Python-Dev] subprocess check_output

This mailing list is for the development of future versions of Python. For questions about using Python, please use python-list: https://mail.python.org/mailman/listinfo/python-list Eric. On 12/30/2015 07:25 PM, Carlos Barera wrote: > Hi, > > Trying to run a specific command (ibstat) installed

Re: [Python-Dev] RE 25939 - _ssl.enum_certificates broken on Windows

There are already many tests that require ctypes. See for example test_uuid.py. -- Eric. > On Feb 18, 2016, at 7:18 PM, Steve Dower wrote: > > I think the test is blocked on my question of whether we are allowed to rely > on ctypes in the test suite. > > If so, it's fine as I recall. Fairly

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On 4/13/2016 7:40 AM, Victor Stinner wrote: > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Thanks for all of your work on this, Victor. It's much appreci

Re: [Python-Dev] C99

On 06/06/2016 10:11 AM, Guido van Rossum wrote: > On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden wrote: >> Guido van Rossum wrote: >> >>> I'm not sure I meant that. But if I have a 3rd party extension that >>> compiles with 3.5 headers using C89, then it should still compile with >>> 3.6 headers u

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.

On 11/05/2013 05:03 AM, vinay.sajip wrote: > http://hg.python.org/cpython/rev/5636366db039 > changeset: 86936:5636366db039 > branch: 3.3 > parent: 86933:2c191b0b5e7a > user:Vinay Sajip > date:Tue Nov 05 10:02:21 2013 + > summary: > Issue #18345: Added cookbook exa

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #18345: Added cookbook example illustrating handler customisation.

On 11/05/2013 07:55 AM, Eric V. Smith wrote: > I love all things British, but the python source code usually uses > "customiz*" (341 instances) over "customis*" (19 instance, 8 of which > are in logging). > > I realize "foolish consistency", and all

<    1   2   3   4   5   6   >