On 13/06/2024 02:20, Rob Cliffe wrote:
The os.path.commonprefix function basically returns the common initial
characters (if any) shared by a sequence of strings, e.g.
os.path.commonprefix(("Python is great!", "Python is not bad",
"Python helps")) # returns "Python "
The following was wr
The os.path.commonprefix function basically returns the common initial
characters (if any) shared by a sequence of strings, e.g.
os.path.commonprefix(("Python is great!", "Python is not bad",
"Python helps")) # returns "Python "
The following was wrong. os.path.commonprefix uses min and ma
The os.path.commonprefix function basically returns the common initial
characters (if any) shared by a sequence of strings, e.g.
os.path.commonprefix(("Python is great!", "Python is not bad",
"Python helps")) # returns "Python "
This is purely a string manipulation function which bears no rel
The fact that it is not allowed is nothing to do with the 'return'. You
*can* write
return (x := x+1)
What you can't (at present) do is use the walrus operator with an attribute:
x = (self.a := self.a + 1) # SyntaxError
I too have found times when this would be convenient.
As Stephen says
On 12/09/2023 11:54, Dom Grigonis wrote:
Yes, Thank you!
So 2 solutions now. They both solve what I have encountered. Beyond that, they
differ by:
a) f-string print(f’{=a.method}’) # ‘a.method’
No new builtin needed.
Simply reprints expression representation.
I don't unde
As for the example in your first post:
var = 710
variable_name = [k fork, v inlocals().items()ifv == 710][0]
print("Your variable name is "+ variable_name)
it does "work", but it doesn't make much sense with Python's
semantics. You could have two identifiers bound to the same object;
which o
On 08/09/2023 22:19, Christopher Barker wrote:
On Fri, Sep 8, 2023 at 11:00 AM Barry Scott
wrote:
I see no need for del to return anything, you already have the
reference in foo.
The times that foo is dropped at module level are rare enough to
not need special syntax.
I agr
On 08/09/2023 22:19, Christopher Barker wrote:
On Fri, Sep 8, 2023 at 11:00 AM Barry Scott
wrote:
I see no need for del to return anything, you already have the
reference in foo.
The times that foo is dropped at module level are rare enough to
not need special syntax.
I agr
On 04/08/2023 14:02, Niktar Lirik via Python-ideas wrote:
Hi Daniil.
Yes, you can do almost same:
tt = 5
while tt := tt - 1:
print(tt)
"almost" is right. The OP's version, as far as I can tell, wants to do
post-decrement (test tt, then decrement it) so it would "do somethin
When can we expect the results of your survey? (I responded to it.)
Best wishes
Rob Cliffe
On 17/07/2023 21:41, Dom Grigonis wrote:
Hi everyone,
I am not very keen on long discussions on such matter as I do not
think there is much to discuss: there is no technical complexity in it
and it doe
On 15/07/2023 21:08, Dom Grigonis wrote:
Just to add. I haven’t thought about evaluation. Thus, to prevent
evaluation of unnecessary code, introduction of C-style expression is
needed anyways:
1. result = bar is None ? default : bar
The below would have to evaluate all arguments, thus not a
The problem with adding a second None-like type is that gradually it
will acquire meaning as a possible value in some contexts. Maybe not in
your code, but in other people's. Then will there be a request for a
3rd such object? (4th, 5th ...?).
Defining your own sentinel object, as you do, see
On 12/06/2023 21:11, Barry wrote:
On 12 Jun 2023, at 16:55, BoppreH via Python-ideas
wrote:
Then the empty list creates hard-to-track bugs. I'm familiar with the iterator
protocol and why the behavior above happens, but couldn't it be prevented?
I don’t think so. It is not always a bug tha
Sorry, -1.
Is this really worth the hassle when you can write (more explicitly)
def my_fun():
raise NotImplementedError # todo
Python has grown steadily more complicated in its lifetime. Usually for
good reasons. But each additional feature adds to the learning curve
and the maintenance b
On 21/04/2023 23:20, Samuel Muldoon wrote:
# pfr is partially_formatted_result
pfr =r"\mathjax{{color}}{{text}}".format(color = "blue") # ERROR!
missing parameter `text`
result =r"\mathjax{{color}}{{text}}".format(text = "Spanish") # ERROR! missing
parameter `color`
Is there any reason yo
On 24/03/2023 17:30, Samuel Muldoon wrote:
*Additionally, the class named `object` should have a method named
`__mro__` and any class which inherits from `object` may override
`__mro__` or inherit the default `* *object* *.__mro__` . *
It already has an attribute of that name:
>>> object._
I did say in my first post on the subject that I couldn't decide on the
best API.
I'm hoping that someone can devise a better one that might gain support.
I also listed a large number of use cases in the stdlib (which I chose
as a conveniently available codebase. I would expect there to be othe
or s in middle),
last.lstrip()))
What is harder is to be sure that this would be the expected behaviour
when using a `&` operator on strings.
Why `' a' & 'b'` would produce `'a b'` and `' ' & 'b'` produce `'
b'` for exam
On 07/03/2023 09:54, Valentin Berlier wrote:
I'm -1 on this. You can easily make a helper that achieves the desired syntax. Presenting
"human readable data" isn't just about collapsing spaces, and having your own
helper means that you can adjust the formatting to your specific use case if nee
On 09/03/2023 05:25, Bruce Leban wrote:
On Wed, Mar 8, 2023 at 4:34 PM Rob Cliffe via Python-ideas
wrote:
It seems to me that it would be useful to be able to make the
str.join()
function put separators, not only between the items of its
operand, but
also optionally at
Bikeshedding:
1) I forgot to mention whether the '&' operator should apply to byte
strings as well as to strings.
I propose that it should (some supporting examples below).
2) Joao suggested spelling the operator '|'.
But for me: '|' suggests "or" while '&' suggests "and" and is a
more
Having had my last proposal shot down in flames, up I bob with another. 😁
It seems to me that it would be useful to be able to make the str.join()
function put separators, not only between the items of its operand, but
also optionally at the beginning or end.
E.g. '|'.join(('Spam', 'Ham', 'Eggs
You make a very powerful point, Bruce. Much more so IMO than anyone
else has so far.
Unless anyone else can find a convincing rebuttal, I withdraw my proposal.
Best wishes
Rob Cliffe
On 07/03/2023 21:49, Bruce Leban wrote:
On Sun, Mar 5, 2023 at 7:39 PM Rob Cliffe via Python-ideas
wrote
On 07/03/2023 07:26, Stephen J. Turnbull wrote:
Rob Cliffe writes:
> Perhaps where you're not laying out a table,
I'm an economist
Oh goody! *Please* tell me what our Government needs to do to grow the
UK economy and curb inflation. I'll inform my MP immediately. 😁
Seriously though ...
On 06/03/2023 15:49, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> I like the look of the & operator for concatenation, so I want to like
> this proposal. But I think I will need to see real world code to
> understand when it would be useful.
I have to second that motion. Pretty
Tl;dr: Join strings together with exactly one space between non-blank
text where they join.
I propose a meaning for
s1 & s2
where s1 and s2 are strings.
Namely, that it should be equivalent to
s1.rstrip() + (' ' if (s1.strip() and s2.strip()) else '') +
s2.lstrip()
Informally, this wil
On 20/12/2022 09:16, Steven D'Aprano wrote:
On Mon, Dec 19, 2022 at 05:53:38PM -0800, Ethan Furman wrote:
Personally, every other time I've wanted to subclass a built-in data type,
I've wanted the built-in methods to return my subclass, not the original
class.
Caveat: If you were subclassi
On 19/12/2022 03:23, David Mertz, Ph.D. wrote:
On Sun, Dec 18, 2022 at 8:29 PM Steven D'Aprano
wrote:
> However, if you want to allow these types to possibly *do*
something with
> the strings inside (validate them, canonicalize them, do a
security check,
> etc), I think I
On 17/12/2022 16:07, e...@emilstenstrom.se wrote:
Python's currently supported string types are just single letter, so the
suggestion is to require tagged strings to be at least two letters.
Er, no:
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32
bit (Intel)] on
On 04/12/2022 17:08, Chris Angelico wrote:
On Mon, 5 Dec 2022 at 04:07, Rob Cliffe via Python-ideas
wrote:
On 30/11/2022 20:27, Anony Mous wrote:
Danceswithmice wrote:
The idea is that YOU write "local:", and the interpreter, without you
ever seeing it, promotes that int
On 30/11/2022 20:27, Anony Mous wrote:
Danceswithmice wrote:
The idea is that YOU write "local:", and the interpreter, without you
ever seeing it, promotes that into a hidden function with a hidden
name and a hidden call.
---
p.f.moore wrote:
> That would make "return" in the local sco
Thank you for your proposal David. At last we have a counter-proposal
to talk about. A few points:
(1) (As I pointed out in an earlier post) There is a flaw in using the
syntax of an expression PRECEDED by a SOFT keyword:
x = later -y
With your proposal, x is assigned a deferre
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 20/06/2022 17:39, Jeremiah Paige wrote:
On Sat, Jun 18, 2022 at 5:42 PM Rob Cliffe via Python-ideas
wrote:
To me, the natural implementation of slicing on a non-reusable
iterator
(such as a generator) would be that you are not allowed to go
backwards
or even stand
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
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
To me, the natural implementation of slicing on a non-reusable iterator
(such as a generator) would be that you are not allowed to go backwards
or even stand still:
mygen[42]
mygen[42]
ValueError: Element 42 of iterator has already been used
(Apologies if I don't know the difference betw
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,
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 no
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
d version might bridge
that gap by introducing "later" or "defer" or "delay" in a narrow
context, but not foreclosing its later use more broadly.
On Wed, Jun 15, 2022 at 8:38 AM Steven D'Aprano
wrote:
On Tue, Jun 14, 2022 at 11:59:44AM +0100, Rob Cliffe v
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 09/06/2022 10:28, Paul Moore wrote:
On 09/06/2022 09:50, Paul Moore wrote:
On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
My current thinking in response to that is that using islice is a decent
solution except that it's not obvious. You have to jump outside of the thinking
about t
On 09/06/2022 09:50, Paul Moore wrote:
On Thu, 9 Jun 2022 at 01:12, Steve Jorgensen wrote:
My current thinking in response to that is that using islice is a decent
solution except that it's not obvious. You have to jump outside of the thinking
about the destructuring capability and conside
On 08/06/2022 15:40, Eric V. Smith via Python-ideas wrote:
On 6/7/2022 4:59 PM, Chris Angelico wrote:
On Wed, 8 Jun 2022 at 00:36, wrote:
Hello!
Do you know if there has been discussions around why is the default
argument is positional only in the dict methods get and pop?
I think
```
On 07/06/2022 15:28, martineznicolas41...@gmail.com wrote:
I think
```
d.get(key, default=3)
```
way more readable than
```
d.get(key, 3)
I completely agree.
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsu
I'm sorry Steven, I didn't mean to denigrate your examples.
Please note that I said I was in favour of relaxing the restrictions on
the walrus operator.
I guess I just meant that using the walrus operator generally adds extra
complexity to code and means that more effort is required to read and
On 08/05/2022 13:08, Valentin Berlier wrote:
A while ago there was a discussion about allowing "match" patterns for the
walrus operator. This would cover iterable unpacking as you suggested along with all the
patterns allowed in match statements.
if [x, y, z] := re.match(r"...").groups(
h a function should be part of the standard library.
Well, you are 1 user. Have you evidence that there are (many) others?
Best wishes
Rob Cliffe
--- Original Message ---
On Thursday, March 10th, 2022 at 8:38 PM, Rob Cliffe via Python-ideas
wrote:
This could cause confusion because st
On 11/03/2022 19:30, wfdc wrote:
> I could (I believe) write "count" as an (inefficient) 1-liner, but not "index". I suggest it's harder than
you think. (Try it!)
How much harder? Can you post your candidate?
It was you that said it could be a 1-liner. The burden of proof is on
you, if yo
On 11/03/2022 21:33, wfdc wrote:
How about something like
def index(self, x):
return next(i for i, a in enumerate(self) if a == x)
Including start and end:
def index(self, x, start=0, end=-1):
return next(i for i, a in tuple(enumerate(self))[start:end] if a == x)
No cigar. If the el
This is a common scenario on python-list or python-ideas:
Someone has an idea that they think is the greatest thing since sliced
bread. They propose it, and feel hurt / rejected when they get pushback
instead of everyone jumping up and down and saying how brilliant it is.
Sometimes they are do
This could cause confusion because str.replace() has a completely
different API.
And indeed if a replace method were added to tuples, a fair case could
be made for it having the same API, viz.
replace(old, new, count=-1)
Whereas your suggestion can be written as a simple 1-liner, as you
dem
On 02/03/2022 20:03, David Mertz, Ph.D. wrote:
I really am shocked by how many people seem to have broken ENTER keys
on their keyboards.
You mock. (As far as I remember you have always opposed new language
features/changes. Correct me if I am wrong.)
But the proposal would give people the c
On 02/03/2022 20:03, David Mertz, Ph.D. wrote:
I really am shocked by how many people seem to have broken ENTER keys
on their keyboards.
You mock. (As far as I remember you are always opposed to new language
features/changes.)
But the proposal would give people the choice of
Saving a lev
I have had precisely the same idea.
It feels better to make this feature general (if introduced at all) than
make it specific to 'for' + 'if'.
I think there would have to be a rule that any 'if' that appeared on a
line with other suite-introducing-statements could not have a
corresponding 'else
On 02/03/2022 02:01, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 12:33, Rob Cliffe via Python-ideas
wrote:
On 02/03/2022 01:02, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
wrote:
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24
On 02/03/2022 01:02, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
wrote:
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
On Tue, Mar 01, 2022 at 04:04:31PM +0000, Rob Cliffe via Python-ideas wrote:
I
On 01/03/2022 23:57, Ben Rudiak-Gould wrote:
On Tue, Mar 1, 2022 at 2:23 PM Steven D'Aprano
wrote:
try:
do_this()
if condition: raise MyBreak
do_that()
if condition: raise MyBreak
do_next_step()
if condition: rai
On 01/03/2022 22:25, Chris Angelico wrote:
class MyBreak(Exception):
pass
try:
do_this()
if condition: raise MyBreak
do_that()
if condition: raise MyBreak
do_next_step()
if condition: raise MyBreak
do_last_step
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
On Tue, Mar 01, 2022 at 04:04:31PM +0000, Rob Cliffe via Python-ideas wrote:
I have use cases for "do exactly once".
Basically a sequence of actions which can be broken off (when
Without testing, I am sure it would be slower.
I suppose it would be reasonable if exceptions are raised in multiple
places and the exceptions were given meaningful names.
Best wishes
Rob Cliffe
On 01/03/2022 17:22, om wrote:
How does `try/except` (with raise AppropriateException inside the
bl
I have use cases for "do exactly once".
Basically a sequence of actions which can be broken off (when something
goes wrong and the whole process should be aborted, or when something
succeeds and there is no need to try alternatives) at various points
with `break`. Thus avoiding multiple if...t
Hi Mirmojtaba, thanks for your suggestion.
I doubt this idea will fly with this syntax because it could easily be
confused with the walrus operator.
x := 0
is *almost* legal syntax currently. In fact
(x := 0)
is legal, and it is quite possible that at some time in the future
(Dic[fruit]:=0
On 21/01/2022 11:51, Oscar Benjamin wrote:
I really don't understand (having read everything above) why anyone
prefers {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from
some other languages might get confused (e.g. in Mathematica this is
function call syntax) but that's true of any
On 18/01/2022 19:42, MRAB wrote:
On 2022-01-18 18:54, Neil Girdhar wrote:
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for
frozendict if it ever makes it in. Also, {} should be consisten with
f{} (both shoul
I'm +1 on the idea.
I'm happy with the
f{ ... }
syntax (although I did suggest something else).
We already have letter-prefixes, let's stick to them rather than adding
something new (which conceivably might one day find another use).
Best wishes
Rob Cliffe
On 18/01/2022 15:53, Ricky Teachey
On 17/01/2022 00:16, Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 01:11:13PM +0000, Rob Cliffe via Python-ideas wrote:
How about
fs{1, 2, 3}
What does the "s" add that the set {1, 2, 3} doesn't already tell us?
It helps to distinguish it from
f(1, 2, 3)
f
already say
a = frozenset({i+1 for i in range(3)})
which is not too bad.
On Sun, 16 Jan 2022 at 14:14, Rob Cliffe via Python-ideas
wrote:
How about
fs{1, 2, 3}
?
Best wishes
Rob Cliffe
On 16/01/2022 12:41, Chris Angelico wrote:
> On Sun, Jan 16, 2022 at 11
How about
fs{1, 2, 3}
?
Best wishes
Rob Cliffe
On 16/01/2022 12:41, Chris Angelico wrote:
On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote:
While it's tempting, it does create an awkward distinction.
f(1, 2, 3) # look
Currently list.remove raises ValueError if the element is not in the list.
When called with the count argument, should it raise ValueError if there
are fewer than `count` occurrences of the element in the list?
Best wishes
Rob Cliffe
On 22/12/2021 00:09, Jeremiah Vivian wrote:
I expect some s
On 12/12/2021 06:02, Stephen J. Turnbull wrote:
Chris Angelico writes:
Of course, the *thread* is generally about argument defaults, but
"everything" in it is not specifically about defaults. In *this*
subthread Eric was arguing for waiting for a facility for *generic*
deferral of expression
Please, no, No, NO!
It has always been the policy that typing is, and will remain, optional.
On 09/12/2021 20:32, deavid wrote:
Hi, I would like to hear the opinion of Python's community on
enforcing types in the future for the language. I've been using Python
as my main language for everything
We seem to be arguing in circles and talking past each other here about
nomenclature:
f(arg=>dflt)
What does it matter if we call it "a default" or "just behaviour in the
function" or "a Jabberwocky" or ""?
The RELEVANT question should be "Is it useful"?
Best wishes
Rob Cliffe
On 09/12/20
_*Objections to PEP 671 - Summary*_
There seems to be a problem understanding what the objections to PEP 671
are. Chris A wrote:
"Part of the problem is that it is really REALLY hard to figure out what
the actual objections are. I asked, and the one clear answer I got was
one subjective opinio
On 08/12/2021 23:09, David Mertz, Ph.D. wrote:
On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas
But AIUI (i.e. practically not at all) Dask is about parallel
computing, which is not the same thing as deferred evaluation,
though doubtless they overlap. Again AIUI, parallel
/2021 22:40, David Mertz, Ph.D. wrote:
On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas
On 08/12/2021 19:27, Paul Moore wrote:
> The reason deferred objects keep coming up is because they *do*
have a much more compelling benefit - they help in a much broader
range of ca
On 08/12/2021 19:27, Paul Moore wrote:
The reason deferred objects keep coming up is because they *do* have a
much more compelling benefit - they help in a much broader range of
cases.
That may be true. I don't know.
Can anyone provide some realistic use cases? I've read the whole thread
a
On 07/12/2021 18:22, Stephen J. Turnbull wrote:
Rob Cliffe via Python-ideas writes:
> I think you're making my point.
*shrug* You wrote "object", I took you at your word.
> You're saying that the object part isn't that hard, but other parts of
> it
On 06/12/2021 23:13, Steven D'Aprano wrote:
On Mon, Dec 06, 2021 at 10:17:06AM +0000, Rob Cliffe via Python-ideas wrote:
If your language only has one, early binding is better.
That's your opinion. It's not mine. Witness the Stack Overflow
questions asking why `def f(ar
On 06/12/2021 08:45, Steven D'Aprano wrote:
On Sun, Dec 05, 2021 at 05:31:58PM -0700, Finn Mason wrote:
Also, on a kind of side note, what would be a situation where early binding
is advantageous to late binding? I can't think of one off the top of my
head.
If your language only has one, ear
On 06/12/2021 09:44, Stephen J. Turnbull wrote:
Rob Cliffe via Python-ideas writes:
> Nobody has attempted (or at least completed) a PEP, never mind an
> implementation, of a "generalized deferred object/type", in the last N
> years or decades.
Haskell anything. R
On 05/12/2021 18:37, David Mertz, Ph.D. wrote:
On Sun, Dec 5, 2021, 12:33 PM Chris Angelico
And quite frankly, the tone of this list is sounding like "shut
up, go away, don't do anything, because there are other proposals
that nobody can be bothered writing up, but if they existed,
On 05/12/2021 04:01, David Mertz, Ph.D. wrote:
The cost here is that EVERY SINGLE student learning Python needs to
add this new construct to their mental load. EVERY book and tutorial
needs to be updated. EVERY experienced developer has to spend extra
effort understanding and writing code.
On 05/12/2021 15:16, Steven D'Aprano wrote:
On Wed, Dec 01, 2021 at 12:26:33PM +, Matt del Valle wrote:
I'm sure that people will learn the many uses of the arrow symbols.
After all, people learn Perl and APL :-) Closer to home, we also learn
all the many different uses of the star symbol
Thank you for doing this research, Steven.
The designers of 12 languages have chosen to provide late binding; those
of 3 or 4 have provided early binding.
I think this is at least tenuous evidence in favour of my belief that
late binding is more useful than early binding.
Best wishes
Rob Cliffe
On 04/12/2021 01:06, Chris Angelico wrote:
On Sat, Dec 4, 2021 at 11:59 AM Rob Cliffe via Python-ideas
wrote:
On 03/12/2021 22:38, Chris Angelico wrote:
On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas
wrote:
On 03/12/2021 19:32, Adam Johnson wrote:
The first unwelcome
On 03/12/2021 22:38, Chris Angelico wrote:
On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas
wrote:
On 03/12/2021 19:32, Adam Johnson wrote:
The first unwelcome surprise was:
>>> def func(a=>[]):
... return a
...
>&g
On 03/12/2021 19:32, Adam Johnson wrote:
The first unwelcome surprise was:
>>> def func(a=>[]):
... return a
...
>>> import inspect
>>> inspect.signature(func).parameters['a'].default
Ellipsis
Here the current behaviour of returning `Ellipsis` is very unfor
On 02/12/2021 14:47, Steven D'Aprano wrote:
On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote:
I'm still unsure whether this is a cool feature or an utter abomination:
def f(x=...):
... try: print("You passed x as", x)
... except UnboundLocalError: print("You didn't pass
On 01/12/2021 06:16, Chris Angelico wrote:
I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
with some additional information about the reference implementation,
and some clarifications elsewhere.
*PEP 671: Syntax for late-bound function argument defaults*
Questions, for you
On 01/12/2021 15:39, David Mertz, Ph.D. wrote:
However, even if I assume the mythical future PEP never happens, in
terms of readability, a WORD is vastly less confusing than a
combination of punctuation that has no obvious or natural
interpretation like '=>'. Or rather, I think that spelli
On 02/12/2021 07:05, Brendan Barnwell wrote:
On 2021-12-01 18:35, Chris Angelico wrote:
In my reference implementation, there is no object that stores it;
it's simply part of the function. A good parallel is the if/else
expression:
x = float("inf") if z == 0 else y/z
Is there an object that
On 02/12/2021 03:35, Steven D'Aprano wrote:
On Wed, Dec 01, 2021 at 05:16:34PM +1100, Chris Angelico wrote:
1) If this feature existed in Python 3.11 exactly as described, would
you use it?
Yes I would, but probably not as often as counting cases of the "if
param is None: ..." idiom might le
On 01/12/2021 10:05, Steven D'Aprano wrote:
Oh great, now you're going to conflict with walrus...
def process(obj:Union[T:=something, List[T]]:=func(x:=expression)+x)->T:
We ought to at least try to avoid clear and obvious conflicts between
new and existing syntax.
Using `:=` is even w
On 26/11/2021 00:12, Steven D'Aprano wrote:
On Wed, Nov 24, 2021 at 07:15:58PM -, ehmatt...@gmail.com wrote:
One common error that I haven't seen discussed is bare logical
comparisons. They're syntactically legal so they don't raise errors,
but I have never seen a real-world use case for
On 14/11/2021 18:22, Chris Angelico wrote:
IMO it would be kinda handy to be able to combine a global statement
with an assignment, but it's not a particularly high priority for me.
It would reduce a bit of repetition, but that's all.
Agreed. Sometimes I'd like to be able to write this sort
On 05/11/2021 15:57, Stephen J. Turnbull wrote:
Still on the agenda as far as I can see:
1. Syntax. The proposals I can recall are
a. x=>default
b. *x=default
c. x=@default
d. maybe putting * or @ on the opposite component in b and c?
e. a keyword before default
Taking a step back:
Suppose Python didn't have default values AT ALL for function
parameters? Say that unpassed parameters were always set to some
sentinel value (maybe None, maybe some special value NotPassed). Would
we want to add them to the language?
Surely almost everybody would say yes.
1 - 100 of 286 matches
Mail list logo
