It’s 2 options:
a) It is a special constant - the only one with such property. Then it would be
used solely for this purpose. I don’t think you can prevent someone from using
it for something else. But I don’t think this case of misusage is a big
exception to the way things are. As this would b
I think the question is, how is that fundamentally different than the
value "None". Once you create this "special value", some function will
decide to make it have a meaning as a passed in value, and then need a
DIFFERENT "special value" as a default.
On 7/23/23 1:13 AM, Dom Grigonis wrote:
O
Or maybe you are not listening to what I am saying.
It would only take effect for arguments, which have default value.
So.
dict().__setitem__(key, NotGiven)
type(NotGiven)
Exception(NotGiven)
getattr(NotGiven, name)
Ok, maybe there are some crucial functions, which have argument defaults. But
a
On Sun, 23 Jul 2023 at 14:08, Dom Grigonis wrote:
>
> IT IS AN OBJECT. Never said otherwise.
One that you can't do any of the operations I described. There is no
way to use it as an object.
> `inspect.getcallargs` can seemingly be modified for such behaviour. I just
> wrote a decorator, which d
IT IS AN OBJECT. Never said otherwise.
`inspect.getcallargs` can seemingly be modified for such behaviour. I just
wrote a decorator, which does what I proposed using `inspect` module for a
chosen sentinel value. The issue is that it would be a bottleneck if used on
any callable, which is contin
On Sun, 23 Jul 2023 at 12:20, Dom Grigonis wrote:
>
>
> > There is no way to have a value that isn't a value, in Python. The
> > concept doesn't make sense and would break all kinds of things.
> > (That's why, when a special function like __getitem__ has to be able
> > to return literally anything
> There is no way to have a value that isn't a value, in Python. The
> concept doesn't make sense and would break all kinds of things.
> (That's why, when a special function like __getitem__ has to be able
> to return literally anything, it signals "nothing to return" by
> raising an exception.)
On Sun, 23 Jul 2023 at 09:15, Dom Grigonis wrote:
> This works ok:
>
> ```
> def foo(bar=None):
> if bar is None:
> bar = A()
>
> class A:
> pass
> ```
>
> If PEP is aiming to replace the latter example, then it would be great if it
> kept all of its advantages. I.e. not having to
1. Not if it is exactly as described in PEP.
2. No.
3. -
4. Couple of points here. One check and one orthogonal idea, which would make
this PEP very attractive to me.
I would definitely like use this functionality if both of below points were
satisfied/achievable. If any of those weren't satisfi
On Sat, 29 Apr 2023 at 23:01, wrote:
>
> Ad 4) Wouldn't "<=" be a little more logical than "=>"? The perceived
> direction of the "flow" of the default value is exactly opposite, i.e., the
> default value is always evaluated and then put *into* the argument.
>
Using arrows to represent informat
Ad 4) Wouldn't "<=" be a little more logical than "=>"? The perceived direction
of the "flow" of the default value is exactly opposite, i.e., the default value
is always evaluated and then put *into* the argument.
For example:
def bisect_right(a, x, lo=0, hi<=len(a), *, key=None):
__
On Mon, 26 Dec 2022 at 10:02, wrote:
>
> I didn't realize def foo(x, y=[]) had this strange artifact but it totally
> makes sense, TIL. I did not get the right idea reading the PEP though, since
> currently the motivation reads:
>
> > Optional function arguments, if omitted, often have some sort
I didn't realize def foo(x, y=[]) had this strange artifact but it totally
makes sense, TIL. I did not get the right idea reading the PEP though, since
currently the motivation reads:
> Optional function arguments, if omitted, often have some sort of logical
> default value. When this value dep
On Mon, 26 Dec 2022 at 04:53, Steven D'Aprano wrote:
>
> On Sat, Dec 24, 2022 at 11:34:19AM -0500, Shironeko wrote:
> >
> > Is the => syntax needed? as far as I can think of, the only time where
> > late evaluation is needed is when the expression references the other
> > arguments.
>
> You are mi
On Sat, Dec 24, 2022 at 11:34:19AM -0500, Shironeko wrote:
>
> Is the => syntax needed? as far as I can think of, the only time where
> late evaluation is needed is when the expression references the other
> arguments.
You are missing the most common case, the motivating case, for
late-bound d
Is the => syntax needed? as far as I can think of, the only time where late
evaluation is needed is when the expression references the other arguments. So
the rule “if the expression reference other arguments it will get evaluated at
function call time” should suffice right?
In effect:
def
On Wed, 21 Sept 2022 at 11:27, Michael Scott Cuthbert wrote:
>
> [Michael Cuthbert:]
> > > I'm rather surprised though that the typing advantages of the pep have
> > > not been emphasized enough.
>
> [Chris Angelico]
> > That would be because I personally don't use that kind of strict
> > typing,
[Michael Cuthbert:]
> > I'm rather surprised though that the typing advantages of the pep have not
> > been emphasized enough.
[Chris Angelico]
> That would be because I personally don't use that kind of strict
> typing, so it's not something I'm really qualified to talk about.
> Would you like t
On Sat, 17 Sept 2022 at 09:40, Michael Scott Cuthbert wrote:
>
> Very late addition to these long threads -- I'm loving the proposal. I'm
> rather surprised though that the typing advantages of the pep have not been
> emphasized enough.
That would be because I personally don't use that kind of
Very late addition to these long threads -- I'm loving the proposal. I'm
rather surprised though that the typing advantages of the pep have not been
emphasized enough. I have a lot of code that in order to get correct typing in
a strict mode does something like this:
```
def move_pitches(pitc
On Wed, 27 Jul 2022 at 08:39, Stanislav Zmiev wrote:
> 4) If "no" to question 1, is there some other spelling or other small
> change that WOULD mean you would use it? (Some examples in the PEP.)
> defer keyword that Andre proposed is a better option, in my opinion. However,
> I don't like the en
1) If this feature existed in Python 3.11 exactly as described, would
you use it?
Definitely not. It significantly increases cognitive burden on the reader. If
python didn't have pattern matching, walrus, ternary expressions, etc -- then
maybe I would consider this as something harmless. But righ
On 2022-06-20 22:54, Chris Angelico wrote:
You are welcome to dislike the PEP on the basis that the existing
language is better than it would be with this feature. I personally
disagree, but that's what opinions are. But to object on the mere
basis that something MIGHT, despite demonstrated evide
I will post to a different thread for my actual semi-proposal. But to
answer the claim that late-bound arg defaults and late-bound
everything-else are unrelated, and to start with an early version of what
I'd actually want, I wrote this:
https://github.com/DavidMertz/peps/blob/master/pep-.rst
On Tue, 21 Jun 2022 at 10:01, Paul Moore wrote:
> PS To be clear, my objections to the PEP aren't based on deferred
> evaluation. So I'm an impartial 3rd party on this matter. I *do* have
> problems with the PEP, so I have an interest in seeing the PEP fairly
> reflect the lack of consensus, and
On Tue, 21 Jun 2022 at 09:20, Chris Angelico wrote:
>
> On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote:
> > I'm not talking about a "full and detailed specification". That's
> > *still* more than is needed for a valid debate (at this point). But
> > what *is* needed is a more complete explanation
On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote:
> I'm not talking about a "full and detailed specification". That's
> *still* more than is needed for a valid debate (at this point). But
> what *is* needed is a more complete explanation of how deferred
> evaluation would work, and some plausible (n
On Tue, 21 Jun 2022 at 06:27, Chris Angelico wrote:
>
> Okay, here's a compromise.
>
> Go and write a full and detailed specification of the Python-visible
> semantics of deferred evaluation objects, including how they would be
> used to implement late-bound argument defaults.
I'm going to ignore
On Tue, 21 Jun 2022 at 15:48, Brendan Barnwell wrote:
>
> On 2022-06-20 22:26, Chris Angelico wrote:
> > Okay, here's a compromise.
> >
> > Go and write a full and detailed specification of the Python-visible
> > semantics of deferred evaluation objects, including how they would be
> > used to imp
On 2022-06-20 22:26, Chris Angelico wrote:
Okay, here's a compromise.
Go and write a full and detailed specification of the Python-visible
semantics of deferred evaluation objects, including how they would be
used to implement late-bound argument defaults.
Go and actually do some real work on y
wt., 21 cze 2022 o 05:20 Steven D'Aprano napisał(a):
> The point is, Rob thought (and possibly still does, for all I know) that
> lazy evaluation is completely orthogonal to late-bound defaults. The PEP
> makes that claim too, even though it is not correct. With a couple of
> tweaks that we have
On Tue, 21 Jun 2022 at 13:17, Steven D'Aprano wrote:
>
> On Tue, Jun 21, 2022 at 12:13:08AM +1000, Chris Angelico wrote:
>
> > Nice analogy. It doesn't hold up.
> >
> > Consider this function:
> >
> > def f(stuff, max=>len(stuff)):
> > stuff.append(1)
> > print(max)
> >
> > f([1,2,3])
> >
On Tue, 21 Jun 2022 at 13:07, Steven D'Aprano wrote:
>
> On Tue, Jun 21, 2022 at 03:15:32AM +0100, Rob Cliffe wrote:
>
> > Why do people keep obscuring the discussion of a PEP which addresses
> > Problem A by throwing in discussion of the (unrelated) Problem B?
> > (Chris, and I, have stated, ad n
On Tue, Jun 21, 2022 at 12:13:08AM +1000, Chris Angelico wrote:
> Nice analogy. It doesn't hold up.
>
> Consider this function:
>
> def f(stuff, max=>len(stuff)):
> stuff.append(1)
> print(max)
>
> f([1,2,3])
>
> How would you use lazy evaluation to *guarantee* the behaviour here?
By
On Tue, Jun 21, 2022 at 03:15:32AM +0100, Rob Cliffe wrote:
> Why do people keep obscuring the discussion of a PEP which addresses
> Problem A by throwing in discussion of the (unrelated) Problem B?
> (Chris, and I, have stated, ad nauseam, that these *are* unrelated
> problems.
Chris says:
"E
On 18/06/2022 15:51, Stephen J. Turnbull wrote:
> This raises another choice: should lazy defaults be evaluated before
> entering the body of the function, or at the point where the parameter
> is used? Which would be more useful?
Both are potentially useful.
Yes, both *ARE* potentially
On Tue, 21 Jun 2022 at 10:13, Rob Cliffe via Python-ideas
wrote:
>
> On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
>
> On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
>>
>> Sorry again, but IMO discussing any model except one where late-bound
>> defaults are evaluated at function call time is just addi
On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
Sorry again, but IMO discussing any model except one where
late-bound defaults are evaluated at function call time is just
adding FUD.
It's definitely rude to repeatedly state that anyone who's
On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
Sorry again, but IMO discussing any model except one where
late-bound defaults are evaluated at function call time is just
adding FUD.
It's definitely rude to repeatedly state that anyone who's
On Mon, 20 Jun 2022 at 21:19, Steven D'Aprano wrote:
> > (4) The guarantee that a late-bound default WILL be executed at
> > function call time, can be useful, even essential (it could be
> > time-dependent or it could depend on the values - default or otherwise -
> > of other parameters whose
On Sun, Jun 19, 2022 at 02:21:16AM +0100, Rob Cliffe via Python-ideas wrote:
> Sorry, but I think all this talk about lazy evaluation is a big red herring:
> (1) Python is not Haskell or Dask.
Python is not Haskell, but we stole list comprehensions and pattern
matching from it. Python steals
@Chris
My bottom line, as I wrote before, is that even if this were
introduced, I probably will continue to default to
def foo(arg=None):
if arg is None:
arg = default
in my own code until I start seeing "def foo(arg=>default)" in a lot
of code I read. Since Mailman gene
On Mon, 20 Jun 2022 at 05:02, David Mertz, Ph.D. wrote:
>
> On Sun, Jun 19, 2022 at 2:24 PM Chris Angelico wrote:
>>
>> > def frobnicate(data, verbose=os.environ.get('LEVEL')==loglevel.DEBUG):
>> > ...
>>
>> Is there any value in not putting that into a global constant?
>
>
> Probably not.
On Sun, Jun 19, 2022 at 2:24 PM Chris Angelico wrote:
> > def frobnicate(data,
> verbose=os.environ.get('LEVEL')==loglevel.DEBUG): ...
>
> Is there any value in not putting that into a global constant?
>
Probably not. I was just inventing an ad hoc example to show what I
meant. I didn't se
On Mon, 20 Jun 2022 at 03:06, David Mertz, Ph.D. wrote:
>>
>> > I guess '>=' also looks "confusable", but it's far less common in
>> > signatures, and the meaning is further away.
>>
>> It's no less valid than your other examples, nor less common (why
>> would you have "==" in a function signatur
>
> > I guess '>=' also looks "confusable", but it's far less common in
> signatures, and the meaning is further away.
>
> It's no less valid than your other examples, nor less common (why
> would you have "==" in a function signature, for instance?).
>
I guess I probably use `==` more often in fu
On Sun, Jun 19, 2022, 12:02 PM Chris Angelico
> I've no idea what you mean by "sophistical" here. Please explain?
>
1. of or characteristic of sophists or sophistry
2. clever and plausible, but unsound and tending to mislead
a sophistical argument
3. using sophistry
Plato's dialog _The Sophis
On Mon, 20 Jun 2022 at 01:37, David Mertz, Ph.D. wrote:
>
> Unfortunately, in relation to this PEP, I find your arguments tend to be
> sophistical. They ate not generally so in other threads, but for whatever
> reason your attachment to this has a different quality.
>
I've no idea what you me
Unfortunately, in relation to this PEP, I find your arguments tend to be
sophistical. They ate not generally so in other threads, but for whatever
reason your attachment to this has a different quality.
There's an interesting point you raise though. You seem to feel that
closely related meanings
On Mon, 20 Jun 2022 at 00:06, David Mertz, Ph.D. wrote:
>
> On Sun, Jun 19, 2022, 3:27 AM Chris Angelico
>>
>> > I'm still -1 because I don't think the purpose alone is close to worth the
>> > cost of new syntax... And especially not using sigils that are confusing
>> > to read in code.
>> >
>>
On Sun, Jun 19, 2022, 3:27 AM Chris Angelico
> > I'm still -1 because I don't think the purpose alone is close to worth
> the cost of new syntax... And especially not using sigils that are
> confusing to read in code.
> >
> > The topic of "late binding in function signatures" simply isn't
> *orth
On Sun, 19 Jun 2022 at 13:44, David Mertz, Ph.D. wrote:
>
> On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
>>
>> Sorry again, but IMO discussing any model except one where late-bound
>> defaults are evaluated at function call time is just adding FUD.
>
>
> It's definitely rude to repeatedly state that
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
> Sorry again, but IMO discussing any model except one where late-bound
> defaults are evaluated at function call time is just adding FUD.
>
It's definitely rude to repeatedly state that anyone who's opinion is
different from yours is "adding FUD" and does
Sorry, but I think all this talk about lazy evaluation is a big red herring:
(1) Python is not Haskell or Dask.
(2) Lazy evaluation is something Python doesn't have, and would be
a HUGE amount of work for Chris (or anyone) to implement (much more, I
would think, than he has already put i
On 18/06/2022 03:28, Steven D'Aprano wrote:
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.
I would suggest less so, provided that it was previously illegal,
because it's backward-compatible,
I think the example that Steven gave, and Stephen approximately repeats is
good.
def func(items=[], n=later len(items)):
items.append("Hello")
print(n)
func()
> I guess Chris will say 0 and David will say 1, but I might be wrong about
either of them.
This is correct. And
On Sat, 18 Jun 2022 at 15:53, Stephen J. Turnbull
wrote:
> I don't find that burdensome enough to want syntax, and I can't guess
> how quickly I'd start using it if available, that probably depends on
> how often the community seems to be using it (ie, in the code I'm
> reading).
To be honest, I
Steven D'Aprano writes:
> The match...case statement didn't "need" keywords either, we could have
> picked symbols instead if we wanted to look like APL. Remember that
> keywords have advantages as well as disadvantages. Given the existence
> of community support for keywords, the PEP shoul
Chris Angelico writes:
> And there we have it. People are complaining loudly, but then ALSO
> saying that they don't support the proposal anyway. Why are you
> bothering to debate this if you've already made your decision?
I can't speak for Brendan, but I have two reasons for discussing
despit
On Sat, 18 Jun 2022 at 03:45, Chris Angelico wrote:
> > This raises another choice: should lazy defaults be evaluated before
> > entering the body of the function, or at the point where the parameter
> > is used? Which would be more useful?
> >
> > # `defer n=len(items)`
> > def func(items
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 t
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 late-
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" keyword
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.
> >> >
> >> > # C
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
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 p
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 a
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 orig
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 honest
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. I
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
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=[]" m
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 ar
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 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", an
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 erro
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
On 15/06/2022 23:01, Steven D'Aprano wrote:
On Wed, Jun 15, 2022 at 01:58:28PM +0100, Rob Cliffe via Python-ideas wrote:
Please. This has been many times by several people already. No-one is
going to change their mind on this by now. There's no point in
rehashing it and adding noise to the
On 17/06/2022 04:23, David Mertz, Ph.D. wrote:
I've been scolded that I'm not allowed to post unless I support the PEP.
Please do not misrepresent me. That is NOT what I said.
Rob Cliffe
Nonetheless, I reiterate that I oppose it. There is no "preponderance"
of support, but perhaps a slim majo
I've been scolded that I'm not allowed to post unless I support the PEP.
Nonetheless, I reiterate that I oppose it. There is no "preponderance" of
support, but perhaps a slim majority of the small number who have commented
(5 vs 3, I think).
On Thu, Jun 16, 2022, 10:38 PM Steve Jorgensen wrote:
Is there anything that I can do, as a random Python user to help move this to
the next stage? I'm happy to go along with whatever the preponderance of
responses here seem to think in terms of which syntax choice is best. Although
I have a slight preference, all of the options seem decent to me.
On Thu, 16 Jun 2022 at 08:25, Steven D'Aprano wrote:
>
> On Thu, Jun 16, 2022 at 12:02:04AM +1000, Chris Angelico wrote:
> > On Wed, 15 Jun 2022 at 22:38, Steven D'Aprano wrote:
> > > There's no consensus that this feature is worth the added complexity, or
> > > even what the semantics are. The P
On Thu, Jun 16, 2022 at 12:02:04AM +1000, Chris Angelico wrote:
> On Wed, 15 Jun 2022 at 22:38, Steven D'Aprano wrote:
> > There's no consensus that this feature is worth the added complexity, or
> > even what the semantics are. The PEP punts on the semantics, saying that
> > the behaviour may var
On Wed, Jun 15, 2022 at 01:58:28PM +0100, Rob Cliffe via Python-ideas wrote:
> Please. This has been many times by several people already. No-one is
> going to change their mind on this by now. There's no point in
> rehashing it and adding noise to the thread.
Rob, there's no rule that only "
On Wed, 15 Jun 2022 at 22:38, Steven D'Aprano wrote:
> There's no consensus that this feature is worth the added complexity, or
> even what the semantics are. The PEP punts on the semantics, saying that
> the behaviour may vary across implementations.
Excuse me? I left one or two things open-ende
On Wed, 15 Jun 2022 at 14:04, Rob Cliffe via Python-ideas
wrote:
>
> Please. This has been many times by several people already. No-one is going
> to change their mind on this by now. There's no point in rehashing it and
> adding noise to the thread.
To be fair, the only real point in re-ope
Please. This has been many times by several people already. No-one is
going to change their mind on this by now. There's no point in
rehashing it and adding noise to the thread.
Best wishes
Rob Cliffe
On 15/06/2022 13:43, David Mertz, Ph.D. wrote:
As well as all the matters Steven raises, I
As well as all the matters Steven raises, I continue to dislike the
proposal for the same reason I did on earlier rounds. I believe a general
"deferred computation" mechanism is useful, but that one limited to the
context of function parameters does more harm than good is scoped narrowly
to that s
On Tue, Jun 14, 2022 at 11:59:44AM +0100, Rob Cliffe via Python-ideas wrote:
> I used to prefer `:=` but coming back to this topic after a long
> interval I am happy with `=>` and perhaps I even like it more, Chris.😁
> The PEP status is "Draft". What are the chances of something happening
> any
On Mon, Jun 13, 2022 at 07:41:12AM -0400, Todd wrote:
> This has been proposed many times. You can check the mailing list history.
> Such proposals have been even less popular then PEP 671, since it requires
> a new keyword, which is generally avoided at nearly all costs,
Now that Python is using
On Wed, Jun 15, 2022 at 10:44:28AM -, Mathew Elman wrote:
> Could this be the behaviour of passing in an Ellipsis? e.g.
>
> def foo(defaults_to_one=1):
> return defaults_to_one
>
> assert foo(...) == foo()
It isn't clear to me whether your question is a request for clarification
(does t
On Wed, 15 Jun 2022 at 20:45, Mathew Elman wrote:
>
> Could this be the behaviour of passing in an Ellipsis? e.g.
>
> def foo(defaults_to_one=1):
> return defaults_to_one
>
> assert foo(...) == foo()
>
> def bar(something=...):
> return foo(something)
>
> assert bar() == foo()
>
> def baz(
Could this be the behaviour of passing in an Ellipsis? e.g.
def foo(defaults_to_one=1):
return defaults_to_one
assert foo(...) == foo()
def bar(something=...):
return foo(something)
assert bar() == foo()
def baz(arg): # no defaults
return arg
assert baz(...) == ...
The only plac
On Tue, 14 Jun 2022 at 21:00, Rob Cliffe via Python-ideas
wrote:
>
> I used to prefer `:=` but coming back to this topic after a long
> interval I am happy with `=>` and perhaps I even like it more, Chris.😁
> The PEP status is "Draft". What are the chances of something happening
> any time soon,
I used to prefer `:=` but coming back to this topic after a long
interval I am happy with `=>` and perhaps I even like it more, Chris.😁
The PEP status is "Draft". What are the chances of something happening
any time soon, i.e. the PEP being considered by the Steering Committee?
Or is it still
On Sun, Jun 12, 2022, 16:22 Bluenix wrote:
> I stumbled upon PEP 671 again today, and for what it's worth I fully agree
> with everything said here.
>
> For the same reasons as you listed, I am generally opposed to PEP 671.
> Wrapping functions in one way or another is extremely common and this P
1 - 100 of 373 matches
Mail list logo
