On Sat, 18 Jun 2022 at 13:13, Brendan Barnwell wrote:
>
> On 2022-06-17 14:23, Chris Angelico wrote:
> > I've just pushed a change to the wording. Let's see if it makes a
> > difference.
> >
> >> I think the PEP would benefit from a fully explicit definition of
> >> exactly when and how
On 2022-06-17 14:23, Chris Angelico wrote:
I've just pushed a change to the wording. Let's see if it makes a difference.
I think the PEP would benefit from a fully explicit definition of
exactly when and how the late-bound defaults would be evaluated. For
instance, by demonstrating an
On Sat, 18 Jun 2022 at 12:36, Steven D'Aprano wrote:
> I expect Chris will be annoyed at me raising this, but one way of
> implementing this would be to introduce a generalised "lazy evaluation"
> mechanism, similar to what Haskell does, rather than special-casing
> late-bound defaults. Then
On Fri, Jun 17, 2022 at 06:32:36AM +0100, Rob Cliffe wrote:
> The bar for adding a new hard keyword to Python is very high.
Likewise for new syntax.
> The suggestion is to add a new keyword to a PEP which absolutely doesn't
> need it,
*shrug*
The match...case statement didn't "need"
On Sat, 18 Jun 2022 at 06:17, Brendan Barnwell wrote:
>
> On 2022-06-17 07:53, Chris Angelico wrote:
> > On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
> >>
> >> On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
> >> >
> >> > There are several ways to make this clearly sane.
> >> >
> >> > #
On 2022-06-17 07:53, Chris Angelico wrote:
On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
>
> There are several ways to make this clearly sane.
>
> # Clearly UnboundLocalError
> def frob(n=>len(items), items=>[]):
Um, I didn't see that as
Hi everyone,
Today was the 3rd time I came across a situation where it was needed to
retrieve all the positions of the line endings (or beginnings) in a very
long python string as efficiently as possible. First time, it was needed in
prompt_toolkit, where I spent a crazy amount of time looking
Also in reply to Paul & Stephen, …
Yes. I really like the idea of using the ellipsis in the expression on the
left. It avoids any breaking changes, avoids adding new semantics to '*', and
also reads quite well.
___
Python-ideas mailing list --
On 6/17/2022 10:53 AM, Chris Angelico wrote:
The only two possible behaviours are:
1) It does the single obvious thing: n defaults to the length of
items, and items defaults to an empty tuple.
2) It raises UnboundLocalError if you omit n.
...
Would you prefer that I simply mandate that it be
On Sat, 18 Jun 2022 at 02:14, Paul Moore wrote:
>
> On Fri, 17 Jun 2022 at 15:55, Chris Angelico wrote:
> >
> > On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
> > >
> > > On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
> > > >
> > > > There are several ways to make this clearly sane.
> >
On Fri, 17 Jun 2022 at 15:55, Chris Angelico wrote:
>
> On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
> >
> > On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
> > >
> > > There are several ways to make this clearly sane.
> > >
> > > # Clearly UnboundLocalError
> > > def frob(n=>len(items),
Chris Angelico writes:
> but at very least, if it isn't *obvious*, it should at least be
> *unsurprising* if you then get UnboundLocalError.
+1 I think this (== "obvious in hindsight") is probably a better
criterion than "obvious" (from the definition) when an error *will* be
raised. (That's
On 2022-06-17 14:10, Jonathan Fine wrote:
Hi
Consider
>>> a, b, *_ = iter('abdef')
>>> a, b, None = iter('abdef')
File "", line 1
SyntaxError: can't assign to keyword
If providing this feature is found to be a good idea, it might be better
to use 'None' or even a new
On Sat, 18 Jun 2022 at 00:21, Paul Moore wrote:
>
> On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
> >
> > There are several ways to make this clearly sane.
> >
> > # Clearly UnboundLocalError
> > def frob(n=>len(items), items=>[]):
>
> Um, I didn't see that as any more obvious than the
Steve Jorgensen writes:
> That leads me to want to change the proposal to say that we give
> the same meaning to "_" in ordinary destructuring that it has in
> structural pattern matching,
This is already valid syntax with different semantics. Given the
existence of islice, there's really no
On Fri, 17 Jun 2022 at 14:19, Mauricio Villegas via Python-ideas
wrote:
>
> Look at the following example:
>
> ```
> def some_function(f1: int):
> assert isinstance(f1, int)
>
> def other_function(f0: str, **kwargs):
> assert isinstance(f0, str)
> some_function(**kwargs)
>
>
On Fri, 17 Jun 2022 at 14:15, Chris Angelico wrote:
>
> There are several ways to make this clearly sane.
>
> # Clearly UnboundLocalError
> def frob(n=>len(items), items=>[]):
Um, I didn't see that as any more obvious than the original example. I
guess I can see it's UnboundLocalError, but
Hi Mauricio,
I'd advise starting a discussion on typing-sig (
https://mail.python.org/archives/list/typing-...@python.org/) or creating
an issue on the python/typing repo (https://github.com/python/typing). The
folks interested in typing generally hang out in those places, so those are
usually
Steve D'Aprano wrote of an incompleteness in this PEP
This is not just some minor, trivial implementation issue, it cuts right
> to the core of this feature's semantics [...]
For comparison, please look at the PEP for the statistics module. Steve
wrote both PEP and the standard library module.
Look at the following example:
```
def some_function(f1: int):
assert isinstance(f1, int)
def other_function(f0: str, **kwargs):
assert isinstance(f0, str)
some_function(**kwargs)
other_function(f0='a', f1='b')
```
I would expect a static type checker to warn that f1='b' is wrong
On Fri, 17 Jun 2022 at 23:05, Paul Moore wrote:
>
> On Fri, 17 Jun 2022 at 13:54, Andrew Jaffe wrote:
> >
> > Is there a *reason* why you are leaving this unspecified? To put it more
> > baldly, is there any reason (e.g., difficulty of parsing?) why allowing
> > these "forward" references should
Hi
Consider
>>> a, b, *_ = iter('abdef')
>>> a, b, None = iter('abdef')
File "", line 1
SyntaxError: can't assign to keyword
If providing this feature is found to be a good idea, it might be better to
use 'None' or even a new keyword rather than '*'. Obvious benefits is it
On Fri, 17 Jun 2022 at 22:55, Andrew Jaffe wrote:
>
> First, let me state that I am in favour of the proposal (although still
> mildle prefer the ":=" spelling).
>
> On 17/06/2022 13:33, Chris Angelico wrote:
> > On Fri, 17 Jun 2022 at 22:14, Steven D'Aprano wrote:
> >>
> >> If we have:
> >> ```
On Fri, 17 Jun 2022 at 13:54, Andrew Jaffe wrote:
>
> Is there a *reason* why you are leaving this unspecified? To put it more
> baldly, is there any reason (e.g., difficulty of parsing?) why allowing
> these "forward" references should *not* be allowed? It seems that
> "n=>len(items), items=[]"
OT:
On Fri, Jun 17, 2022 at 7:35 AM Rob Cliffe
>
> def for(bar=[] later, baz=timenow() later, bam=inc(baz) later):
> Not only is the second one longer and repetitious, it adds more **words**.
> People are used to distinguishing between words and symbols and do it
> easily.
>
You have just
First, let me state that I am in favour of the proposal (although still
mildle prefer the ":=" spelling).
On 17/06/2022 13:33, Chris Angelico wrote:
On Fri, 17 Jun 2022 at 22:14, Steven D'Aprano wrote:
If we have:
```
items = ['spam', 'eggs']
def frob(n=>len(items), items=[]):
print(n)
On Fri, 17 Jun 2022 at 21:35, Steve Jorgensen wrote:
>
> Steve Jorgensen wrote:
> > Restarting this with an improved title "Bare" vs "Raw", and I will try not
> > to digress so much in the new thread.
> > My suggestion is to allow a bare asterisk at the end of a desctructuring
> > expression to
On Fri, 17 Jun 2022 at 12:34, Steve Jorgensen wrote:
>
> Although that would be a breaking change, it is already conventional to use
> "_" as a variable name only when we specifically don't care what it contains
> following its assignment, so for any code to be affected by the change would
>
On Fri, 17 Jun 2022 at 22:14, Steven D'Aprano wrote:
>
> On Thu, Jun 16, 2022 at 08:31:19AM +1000, Chris Angelico wrote:
> > On Thu, 16 Jun 2022 at 08:25, Steven D'Aprano wrote:
>
> > > Under the Specification section, the PEP explicitly refers to
> > > behaviour which "may fail, may succeed",
On Thu, Jun 16, 2022 at 08:31:19AM +1000, Chris Angelico wrote:
> On Thu, 16 Jun 2022 at 08:25, Steven D'Aprano wrote:
> > Under the Specification section, the PEP explicitly refers to
> > behaviour which "may fail, may succeed", and different behaviour which
> > is "Highly likely to give an
On Fri, Jun 17, 2022 at 02:36:48AM -, Steve Jorgensen wrote:
> Is there anything that I can do, as a random Python user to help move
> this to the next stage?
If you think the PEP is as complete and persuasive as possible right
now, you can offer moral support and encouragement. Or you can
Steve Jorgensen wrote:
> Restarting this with an improved title "Bare" vs "Raw", and I will try not to
> digress so much in the new thread.
> My suggestion is to allow a bare asterisk at the end of a desctructuring
> expression to indicate that additional elements are to be ignored if present
>
On Fri, Jun 17, 2022 at 02:50:50AM -, Steve Jorgensen wrote:
> What are people's impressions of this idea. Is it valuable enough to
> pursue writing a PEP?
I don't think it is useful enough to dedicate syntax to it. If you are
proposing this idea, it is your job to provide evidence that it
33 matches
Mail list logo
