Re: [Python-ideas] A comprehension scope issue in PEP 572

... [Guido] >> You should really read Tim's initial post in this thread, where he >> explains his motivation. [Nick] > I did, and then I talked him out of it by pointing out how confusing it > would be to have the binding semantics of "x := y" be context dependent. Ya, that was an effective

Re: [Python-ideas] Inline assignments using "given" clauses

Hi all. I've been lurking for a little while on this discussion and I thought I might contribute some thoughts. One of my hurdles for ":=" is understanding when I should use it rather than "=". Should I use it everywhere? Should I use it only where I can't use regular "="? Is it a personal

Re: [Python-ideas] High Precision datetime

You don't mention the option of allowing time.microseconds to be a float, and I was curious about that since if it did work, then that might be a relatively smooth extension of the current API. The highest value you'd store in the microseconds field is 1e6, and at values around 1e6,

Re: [Python-ideas] High Precision datetime

In fairness, Pandas, datetime64, and Arrow are really the same thing. I don't know about Pendulum or Delorean. A common standard would be great, or at least strong interoperability. I'm sure the authors of those projects would want that... Arrow is entirely about interoperability, after all. On

Re: [Python-ideas] PEP 572: about the operator precedence of :=

Tim Peters wrote: Umm ... that's the opposite of what the Reference Manual says "lower":means: """ 6.16. Operator precedence The following table summarizes the operator precedence in Python, from lowest precedence (least binding) to highest precedence (most binding). """ Which is also in

Re: [Python-ideas] High Precision datetime

On 05/10/2018 10:30 AM, Ed Page wrote: Alternatives - My company create our own datetime library - Continued fracturing of time ... ecosystem (datetime, arrow, pendulum, delorean, datetime64, pandas.Timestamp Or, team up with one of those (if you can). -- ~Ethan~

Re: [Python-ideas] Sorry for yet another self discussion

On Thu, May 10, 2018 at 07:58:12PM +, stefano wrote: > The disturbing part of the "self parameter" is the asymmetry of the > definition and the call. Why is that disturbing? There is always some asymmetry between *defining* a function and *calling* a function. Function definitions:

Re: [Python-ideas] High Precision datetime

> Is there interest in a PEP for extending time, datetime / timedelta for arbitrary or extended precision fractional seconds? Having seen the utter disaster that similar ideas brought to numpy, I would say: no. On the other hand, nanoseconds are slowly making their way to the stdlib and to add

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> ... >> So long as I'm the only one looking at real-life use cases, mine is >> the only evidence I care about ;-) I don't really care about >> contrived examples, unless they illustrate that a proposal is >> ill-defined, impossible to implement as intended, or likely to have >> malignant

Re: [Python-ideas] Inline assignments using "given" clauses

On 10 May 2018 at 11:10, Guido van Rossum wrote: > Please no, it's not that easy. I can easily generate a stream of +1s or > -1s for any proposal. I'd need well-reasoned explanations and it would have > to come from people who are willing to spend significant time writing it up

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-10 16:44 GMT+03:00 Guido van Rossum : > I'm sorry, but unless there's a sudden landslide of support for 'given' in > favor of ':=', I'm really not going to consider it. > > I'd pronounce "if (x := y) > 0" as either "if y (assigned to x) is greater > than zero" or "if x

Re: [Python-ideas] Inline assignments using "given" clauses

On 5/10/2018 9:44 AM, Guido van Rossum wrote: I'm sorry, but unless there's a sudden landslide of support for 'given' in favor of ':=', I'm really not going to consider it. I'd pronounce "if (x := y) > 0" as either "if y (assigned to x) is greater than zero" or "if x (assigned from y) is

Re: [Python-ideas] Inline assignments using "given" clauses

Only the BDFL has a vote with non-zero weight. But I'll contribute my zero-weighted preference for :=. On Thu, May 10, 2018, 4:01 PM Ryan Gonzalez wrote: > Probably going to completely lose this, but would it be possible to have a > vote? +1 for either 'given' and/or ':='? >

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 5/10/2018 9:53 AM, Guido van Rossum wrote: On Thu, May 10, 2018 at 3:32 AM, Terry Reedy > wrote: On 5/9/2018 11:33 PM, Guido van Rossum wrote: I now think that the best way out is to rule `:=` in the top level expression of an

Re: [Python-ideas] Have a "j" format option for lists

-1 on idea. Far too many edge cases that can't be handled... Or absurd complexity added to format mini-language if it tries to handle them (and still fails). On Thu, May 10, 2018, 3:57 PM Eric V. Smith wrote: > On 5/10/18 12:28 PM, Facundo Batista wrote: > > 2018-05-10 10:34

Re: [Python-ideas] Inline assignments using "given" clauses

Probably going to completely lose this, but would it be possible to have a vote? +1 for either 'given' and/or ':='? On Thu, May 10, 2018 at 2:48 PM Guido van Rossum wrote: > Yes. > > On Thu, May 10, 2018, 13:18 Alexander Belopolsky < > alexander.belopol...@gmail.com> wrote: >

[Python-ideas] Sorry for yet another self discussion

I know that "self" parameter have been discussed a lot, but still I didn't find this proposal. If it was instead take my sincere apologies and please forget this mail. The disturbing part of the "self parameter" is the asymmetry of the definition and the call. So I was thinking: why not do define

Re: [Python-ideas] Have a "j" format option for lists

On 5/10/18 12:28 PM, Facundo Batista wrote: 2018-05-10 10:34 GMT-03:00 Chris Angelico : Ideally, it will handle *any* iterable. If it's to handle arbitrary iterables, it can't be the normal style of "take this string, pass it to the object's __format__ method, and let it

Re: [Python-ideas] Inline assignments using "given" clauses

Yes. On Thu, May 10, 2018, 13:18 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > On Thu, May 10, 2018 at 9:44 AM, Guido van Rossum > wrote: > > I'm sorry, but unless there's a sudden landslide of support for 'given' > in > > favor of ':=', I'm really not going

Re: [Python-ideas] High Precision datetime

I have to agree with David that this seems too specialized to make room for in the stdlib. On Thu, May 10, 2018, 15:16 David Mertz wrote: > This feels specialized enough to belong in a third party library. If that > library can behave as transparently as possible interacting

Re: [Python-ideas] High Precision datetime

This feels specialized enough to belong in a third party library. If that library can behave as transparently as possible interacting with Python datetime, so much the better. But the need is niche enough I don't think it belongs in standard library. ... this as someone who actually worked in a

Re: [Python-ideas] Have a "j" format option for lists

09.05.18 15:39, Facundo Batista пише: authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela' In the case of the list of book or article authors it would be better to get "John, Mary and Estela" or "John, Mary, and Estela". In other cases "John,

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 2018-05-10 11:05, Tim Peters wrote: So long as I'm the only one looking at real-life use cases, mine is the only evidence I care about ;-) I don't really care about contrived examples, unless they illustrate that a proposal is ill-defined, impossible to implement as intended, or likely to

Re: [Python-ideas] A comprehension scope issue in PEP 572

Just a quickie - I'm out of time for now. [Guido] >> That's just one of several "don't do that" situations. *What will happen* >> is perhaps hard to see at a glance, but it's perfectly well specified. Not >> all legal code does something useful though, and in this case the obvious >> advice

[Python-ideas] High Precision datetime

Greetings,   Is there interest in a PEP for extending time, datetime / timedelta for arbitrary or extended precision fractional seconds?   My company designs and manufactures scientific hardware that typically operate with nanoseconds -- sometimes even attoseconds -- levels of precision.  We’re

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Nick Coghlan ] > How would you expect this to work in cases where the generator expression > isn't immediately consumed? If "p" is nonlocal (or global) by default, then > that opens up the opportunity for it to be rebound between generator steps. > That gets especially

Re: [Python-ideas] Have a "j" format option for lists

On Fri, May 11, 2018 at 2:28 AM, Facundo Batista wrote: > 2018-05-10 10:34 GMT-03:00 Chris Angelico : >> A "!j" flag >> could take an iterable, format each element using the given format, >> and then join them. The letter "j" makes good sense then, as

Re: [Python-ideas] Inline assignments using "given" clauses

On Thu, May 10, 2018 at 9:44 AM, Guido van Rossum wrote: > I'm sorry, but unless there's a sudden landslide of support for 'given' in > favor of ':=', I'm really not going to consider it. How much support was there for ":="? Are you serious about bringing back Pascal and Algol

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 10 May 2018 at 17:38, Ethan Furman wrote: > On 05/10/2018 09:29 AM, M.-A. Lemburg wrote: >> >> On 10.05.2018 15:57, Guido van Rossum wrote: >>> >>> On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote: > > To a (former Pascal) programmer, a := 1 doesn't read like an

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 10 May 2018 at 23:22, Guido van Rossum wrote: > On Thu, May 10, 2018 at 5:17 AM, Nick Coghlan wrote: > >> How would you expect this to work in cases where the generator expression >> isn't immediately consumed? If "p" is nonlocal (or global) by default,

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 05/10/2018 09:29 AM, M.-A. Lemburg wrote: On 10.05.2018 15:57, Guido van Rossum wrote: On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote: To a (former Pascal) programmer, a := 1 doesn't read like an operator. It's an assignment expression. If embedded expressions is where Python is

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 10.05.2018 15:57, Guido van Rossum wrote: > On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote: > >> To a (former Pascal) programmer, a := 1 doesn't read like an >> operator. It's an assignment expression. If embedded expressions >> is where Python is heading, it should be

Re: [Python-ideas] Have a "j" format option for lists

2018-05-10 10:34 GMT-03:00 Chris Angelico : >> >> Ideally, it will handle *any* iterable. > > If it's to handle arbitrary iterables, it can't be the normal style of > "take this string, pass it to the object's __format__ method, and let > it interpret it". That's why I suggested

Re: [Python-ideas] Inline assignments using "given" clauses

On Thu, 10 May 2018 at 16:49, Ed Kellett wrote: > On 2018-05-10 16:10, Guido van Rossum wrote: > > Please no, it's not that easy. I can easily generate a stream of +1s or > -1s > > for any proposal. I'd need well-reasoned explanations and it would have > to > > come

Re: [Python-ideas] Inline assignments using "given" clauses

On 2018-05-10 16:10, Guido van Rossum wrote: > Please no, it's not that easy. I can easily generate a stream of +1s or -1s > for any proposal. I'd need well-reasoned explanations and it would have to > come from people who are willing to spend significant time writing it up > eloquently. Nick has

Re: [Python-ideas] Inline assignments using "given" clauses

Please no, it's not that easy. I can easily generate a stream of +1s or -1s for any proposal. I'd need well-reasoned explanations and it would have to come from people who are willing to spend significant time writing it up eloquently. Nick has tried his best and failed to convince me. So the bar

Re: [Python-ideas] Inline assignments using "given" clauses

If it just needs a stream of +1s, I personally like the "given" approach much more than the ":=" approach, for all of the many reasons repeated many times in the various email chains. (I preferred it as "as", but that's been struck down already) (and if it's between ":=" and not having them at

Re: [Python-ideas] Inline assignments using "given" clauses

On 10/05/18 14:44, Guido van Rossum wrote: I'm sorry, but unless there's a sudden landslide of support for 'given' in favor of ':=', I'm really not going to consider it. OK, this is my ha'p'th in favour of 'given', for what little it's worth. The more I see of general assignment expressions,

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On Thu, May 10, 2018 at 5:04 AM, M.-A. Lemburg wrote: > To a (former Pascal) programmer, a := 1 doesn't read like an > operator. It's an assignment expression. If embedded expressions > is where Python is heading, it should be made very clear where > the embedded expression

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On Thu, May 10, 2018 at 3:32 AM, Terry Reedy wrote: > On 5/9/2018 11:33 PM, Guido van Rossum wrote: > > I now think that the best way out is to rule `:=` in the top level >> expression of an expression statement completely >> > > I would like to be able to interactively enter >

Re: [Python-ideas] Inline assignments using "given" clauses

I'm sorry, but unless there's a sudden landslide of support for 'given' in favor of ':=', I'm really not going to consider it. I'd pronounce "if (x := y) > 0" as either "if y (assigned to x) is greater than zero" or "if x (assigned from y) is greater than zero". On Thu, May 10, 2018 at 6:39 AM,

Re: [Python-ideas] Have a "j" format option for lists

On Thu, May 10, 2018 at 11:13 PM, Facundo Batista wrote: >> I would like to see you flesh out the idea. In particular, I'd like to see >> you >> address cases where: >> 1. The underlying members in the collection are not strings. Besides the >> basic >>types such

Re: [Python-ideas] A comprehension scope issue in PEP 572

On Thu, May 10, 2018 at 5:17 AM, Nick Coghlan wrote: > On 9 May 2018 at 03:06, Guido van Rossum wrote: > >> So the way I envision it is that *in the absence of a nonlocal or global >> declaration in the containing scope*, := inside a comprehension or

Re: [Python-ideas] Have a "j" format option for lists

2018-05-10 8:02 GMT-03:00 Rhodri James : > On 09/05/18 20:56, Facundo Batista wrote: >> >> 2018-05-09 13:48 GMT-03:00 Rhodri James : >> >>> -1 until you give me an actual spec rather than a curious example. >>> >>> Sorry if that sounds a bit rude, but I

Re: [Python-ideas] Have a "j" format option for lists

> I would like to see you flesh out the idea. In particular, I'd like to see you > address cases where: > 1. The underlying members in the collection are not strings. Besides the basic >types such as numbers, it would also be nice to be able to apply formats >recursively so that one can

Re: [Python-ideas] Have a "j" format option for lists

2018-05-09 21:45 GMT-03:00 Steven D'Aprano : > On Wed, May 09, 2018 at 04:56:38PM -0300, Facundo Batista wrote: >> 2018-05-09 13:48 GMT-03:00 Rhodri James : >> >> > -1 until you give me an actual spec rather than a curious example. >> > >> > Sorry if that

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 9 May 2018 at 03:06, Guido van Rossum wrote: > So the way I envision it is that *in the absence of a nonlocal or global > declaration in the containing scope*, := inside a comprehension or genexpr > causes the compiler to assign to a local in the containing scope, which is >

Re: [Python-ideas] Have a "j" format option for lists

On 5/10/18 7:02 AM, Rhodri James wrote: If so, does anything in that string need escaping, like say braces or other "j"s? I'm not sure if format specifiers currently allow arbitrary text (I don't think they do, but I'm not sure), which might make this a more serious undertaking than it first

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Thu, May 10, 2018 at 08:55:44AM +0100, Barry Scott wrote: > This idea requires the same sort of machinery in python that I was > hoping for to implement the short circuit logging. I'm working on an idea for delayed evaluation of expressions, and I think your idea of logging below would make

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 10 May 2018 at 13:33, Guido van Rossum wrote: > (I vaguely recall this has been brought up before, but I'm too lazy to > find the subtread. So it goes.) > > PEP 572 currently seems to specify that when used in expressions, the > precedence of `:=` is lower (i.e. it binds

Re: [Python-ideas] Runtime assertion with no overhead when not active

On 10 May 2018 at 17:55, Barry Scott wrote: > On 7 May 2018, at 18:52, Guido van Rossum wrote: > > On Mon, May 7, 2018 at 6:24 AM, Serhiy Storchaka > wrote: > >> I just don't understand why you need a new keyword for writing

Re: [Python-ideas] Have a "j" format option for lists

On 09/05/18 20:56, Facundo Batista wrote: 2018-05-09 13:48 GMT-03:00 Rhodri James : -1 until you give me an actual spec rather than a curious example. Sorry if that sounds a bit rude, but I spend most of my time trying to find Be sorry, it was rude. On reflection,

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On Wed, May 9, 2018, 11:53 PM Guido van Rossum wrote: > Oh, I hadn't even though of combining the two in one statement. That > example is truly horrible (on first skim I didn't even notice it used two > different assignment operators!) and strengthens my confidence that we >

Re: [Python-ideas] A comprehension scope issue in PEP 572

On 9 May 2018 at 03:57, Tim Peters wrote: > These all match my expectations. Some glosses: > > [Guido] > > We should probably define what happens when you write [p := p for p in > > range(10)]. I propose that this overwrites the loop control variable > rather > > than

Re: [Python-ideas] Inline assignments using "given" clauses

On 8 May 2018 at 04:19, Brett Cannon wrote: > My brain wants to drop the variable name in front of 'given': > > if given m = pattern.search(data): > > while given m = pattern.search(remaining_data): > > Maybe it's because the examples use such a short variable name? > Does

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On Thu, May 10, 2018 at 7:04 PM, M.-A. Lemburg wrote: > Not sure whether this was discussed before (I'm not really > following the discussion), but what happens if you write: > > check = 0 and (a := 1) > > ? Will "a" get assigned or not ? No, it won't. It's the same as any other

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 10.05.2018 05:52, Guido van Rossum wrote: >> I would have := bind more tightly than the comma. Consider: >> >> a = 1, x := 2, 3 >> >> IMO the only sane interpretation is "x = 2; a = 1, 2, 3". Effectively, >> the := operator does not like to play with commas; we've already ruled >> out "a, b :=

Re: [Python-ideas] Runtime assertion with no overhead when not active

> On 7 May 2018, at 18:52, Guido van Rossum wrote: > > On Mon, May 7, 2018 at 6:24 AM, Serhiy Storchaka > wrote: > I just don't understand why you need a new keyword for writing runtime checks. > > Oh, that's pretty clear.

Re: [Python-ideas] PEP 572: about the operator precedence of :=

On 5/9/2018 11:33 PM, Guido van Rossum wrote: I now think that the best way out is to rule `:=` in the top level expression of an expression statement completely I would like to be able to interactively enter >>> a: = f(2,4) to have 'a' echoed as well as bound. -- Terry Jan Reedy

Re: [Python-ideas] PEP 572: about the operator precedence of := (Guido van Rossum)

> > Is there a more appropriate mechanism to showing support for a 'EXPR given x = EXPR' approach, as suggested by Nick Coghlan? Then, keeping the binding rules the same for statement assign, requiring parenthesis, would keep things consistent. I personally prefer it to := for the reasons I