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
12 matches
Mail list logo
