, meaning you didn't have to remember what was
allowed and what wasn't; so I hope the same will happen with the walrus
operator.
Best wishes
Rob Cliffe
On 09/10/2023 02:17, Dom Grigonis wrote:
Is there a reason why this is not allowed?
return (self.mode := self.mode_valid(mode
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
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
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
with a large memory footprint that is only
needed temporarily.
Best wishes
Rob Cliffe
PS Ooh, not quite true. I have used it to delete a variable that should
no longer be needed to detect accidental illegitimate use of said variable.
RC___
Python-ideas
nary minus
operator twice, and changing that would break existing code.
Python is not going to be turned into C. I suspect that by "Pythonic"
you really mean "I'm familiar with it, it feels natural and intuitive TO
ME". Other people's mileage will vary.
Best wishes
Rob Cl
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
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
, seems like a good
solution. It means *you* control what meaning it has in the contexts
where it appears.
Best wishes
Rob Cliffe
On 07/06/2023 17:43, Dom Grigonis wrote:
This has been bugging me for a long time. It seems that python doesn’t
have a convention for “Undefined” type.
When I started
l. )
Also the OP's request was for generators, not for any iterator.
Nonetheless, I do not support the proposal, for backward compatibility
reasons. I *can* imagine sane code that relies on the existing behaviour.
Best wishes
Rob Cliffe
___
Python-ideas ma
ow would this affect the implementation of the compiler/interpreter?
Best wishes
Rob Cliffe
On 27/04/2023 14:45, haael wrote:
In examples in the web very often we see unfinished or partial code,
where the ellipsis "..." is used in place of missing instructions.
Idea: make ellip
parameter `color`
Is there any reason you can't write
pfr =r"\mathjax{{color}}{{text}}".replace("{color}", "blue")
result =r"\mathjax{{color}}{{text}}".replace("{text}", "Spanish") Best wishes
Rob Cliffe
_
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:
>>>
there to be other
use cases in other code).
Best wishes
Rob Cliffe
On 10/03/2023 06:49, constan...@christoph.net wrote:
Then we're back to square one, doing this would be more confusing than
just adding the sep to the joined string. In my opinion, this proposal
just isn't needed. The equivalent solution
ions by Bruce
Leban and others.
Best wishes
Rob Cliffe
On 11/03/2023 17:13, Antoine Rozo wrote:
It's not that tricky to have the lstrip/rstrip behaviour with a join:
def space_join(*args):
first, *middle, last = args
return ' '.join((first.rstrip(), *(s.strip() for s in middle),
last.ls
mething "
would evaluated to
" foo bar something "
Far from stripping the left side over and over, it doesn't strip it at
all! (Or the right side.)
This is trickier to write using join. And if the first or last string
can be blank, or all whitespace, it is trickier still.
As
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
nwin\pywin\framework\scriptutils.py:564:
win32ui.SetStatusText('Failed to ' + what + ' - ' + str(details) )
win32ui.SetStatusText('Failed to' & what & '-' & str(details) )
Personally, I think that examples such as the last, where multiple
components are all joined with '&
() is passed an empty sequence? This is debatable,
but I think it should return the separator if requested to add it
at the beginning or end, and double it up if both are requested.
This would preserve identities such as
sep.join(seq, ) == sep + sep.join(seq)
Best wishes
Rob Cliffe
EXAMPLES WHERE
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 tho
ou would like single space separators?
Perhaps where you're not laying out a table, but constructing a
human-readable string? So
s1 + ' ' + s2 + ' ' + s3
or
' '.join((s1, s3, s3))
would become
s1 & s2 & s3
saving you a bit of typing. Just sayin'.
Best wishes
Rob Cliffe
I admit
all whitespace,
so that it can be understood as working similarly to strip().
(2) The definition could be simplified to
s1.rstrip() + ' ' + s2.lstrip()
(leave an initial/final space when one string is whitespace only).
Again the operator would be associative.
subclassing str, you would probably want __str__ and
__repr__ (if you were not overriding them) to return plain strings.
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
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
)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> rf'{2+2}'
'4'
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe sen
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
UNLESS there is an
enclosing scope of "def function():", so there's no issue of what they
do if they are simply mainlined, and (I think) a well defined result
if they are not.
What about getting an untrapped exception? Again, your suggestion would
mean that only the local scope is exite
g it something else would be
better to avoid confusion.
Best wishes
Rob Cliffe
On 21/06/2022 21:53, David Mertz, Ph.D. wrote:
Here is a very rough draft of an idea I've floated often, but not with
much specification. Take this as "ideas" with little firm commitment
to details fro
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
PEP about it.
Best wishes
Rob Cliffe
On 18/06/2022 16:42, David Mertz, Ph.D. wrote:
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 Chr
anyone?) Well, maybe caching ONE value
(the last one accessed) is reasonable, so you could stand still but not
go backwards. But it's still adding overhead.
Best wishes
Rob Cliffe
On 09/06/2022 10:28, Stephen J. Turnbull wrote:
Mathew Elman writes:
> would it not be possible to have slic
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 noise
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 perh
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
r is it still too controversial, or is there some other obstacle?
In case it's not clear, I support the PEP. I think it plugs an obvious gap.
Best wishes
Rob Cliffe
On 13/06/2022 09:38, Steve Jorgensen wrote:
To clarify my statement about readability of the '@' prefix option…
I think tha
n() according
to demand.
Of course, for non-reusable iterators it would be forbidden to go
backwards (or even remain in the same place):
agen[42]
agen[41]
ValueError: Generator has been used up past the slice point. (Better
wordings are doubtless available.)
I realise this is aski
not allow square-bracket indexing of
generators instead of having to import and utilize islice for that?
Because generators don't have a common (sub-)type, so there's no class
to put the relevant __getitem__ method on.
How so?
>>> def mygen(): yield 42
...
>>> type(mygen())
d feasible?
People can always choose not to use the keyword form.
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/li
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
voiding re-evaluating an expression. Or,
possibly, when there is some other compelling reason (sorry, can't think
of an example offhand).
Best wishes
Rob Cliffe
On 08/05/2022 17:38, Steven D'Aprano wrote:
On Sun, May 08, 2022 at 04:00:47PM +0100, Rob Cliffe wrote:
Yes, I know unrest
alth
while Response(status=200, json={"stats": stats}) := health_check():
print(stats)
time.sleep(5)
See above - shouldn't try to assign to a literal.
Best wishes,
Rob Cliffe
___
Python-ideas mailing list -- python-idea
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 str.replace() has a completely
differe
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
. If the element is not found it raises StopIteration. It
should raise ValueError.
Rob Cliffe
--- Original Message ---
On Friday, March 11th, 2022 at 4:02 PM, Rob Cliffe
wrote:
On 11/03/2022 19:30, wfdc wrote:
> I could (I believe) write "count" as an (ineffic
which you wrote in another post:
Do you see why it's useful to have immutability?
Best wishes
Rob Cliffe
--- Original Message ---
On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D.
wrote:
So it appears the "problem" this is intended to solve is "
demonstrate. So there is no strong need for a new method for it.
Best wishes
Rob Cliffe
On 10/03/2022 03:42, wfdc via Python-ideas wrote:
Add a "replace" method to tuples that returnsa new tuple with the
element at a given index replaced with a given value. Example
implementation:
d
will be a subjective one. That's no reason not to have the choice.
Of course, this has to be weighed against the cost of the proposed
change. I'm +0.5 for it.
Best wishes
Rob Cliffe
Let's just keep Python readable rather than see how much we can cram
on a line.
On Wed, Mar 2, 2022, 2:56 PM
. That's no reason not to have the choice.
Of course, this has to be weighed against the cost of the change.
Best wishes
Rob Cliffe
Let's just keep Python readable rather than see how much we can cram
on a line.
On Wed, Mar 2, 2022, 2:56 PM Jeremiah Paige wrote:
I have on a few occasions
'else'.
Best wishes
Rob Cliffe
On 02/03/2022 19:53, Jeremiah Paige wrote:
I have on a few occasions wanted a for..in..if statement and if it
existed would
have used it. However, I agree that the level of change a new
statement type
brings to the language is probably too high for this feature
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 +, Rob Cliffe via Python-ideas wrote:
I have
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:
ile it is too narrow to insist that they only be used with that
meaning, this use doesn't feel like a good fit.
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail
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 +, 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 some
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
g multiple if...then indentation levels.
Of course it can be spelled as
for _ in '1':
for _ in ['once']:
etc. etc., so this is only a cosmetic need.
Best wishes
Rob Cliffe
On 01/03/2022 15:19, Eric Fahlgren wrote:
As you probably suspect, yes, it comes up every couple of years.
Here's one of
.
So I think it is up to you to provide further convincing examples in
favour of your idea.
Best wishes
Rob Cliffe
On 05/02/2022 20:18, Mirmojtaba Gharibi wrote:
Hello there,
I have an idea for initializing a variable the first time it’s
created; it can especially be helpful with containe
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
should create dicts). If you want an empty frozenset, you
would have to do it the same way you do it for sets: either
frozenset() or f{*()}.
[snip]
An alternative might be to allow {,} for an empty set, which would
then let you have f{,} for an empty frozenset.
I like it!
Rob Cliffe
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
On 17/01/2022 00:16, Steven D'Aprano wrote:
On Sun, Jan 16, 2022 at 01:11:13PM +, 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[1, 2, 3]
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
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
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
enforced by default at "compile time"
This can't be done, in view of Python's dynamic nature. As I understand
it, it is impossible to check at compile time the type of an argument
that is about to be passed to a function, unless it is a constant (e.g.
a literal int, float, str etc.)
Best
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 "
e function
body, not the function header.*__*
*_
potatochowder.com: [paraphrased] Computation of default belongs in
the function body.
Brendan Barnwell: "Just think that computation (as of defaults)
should be in the function body, not the signature."
I don't find this a
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
examples (in Python pseudo-code perhaps) showing how
*deferred evaluation* would be useful for a concrete task? (Solving an
equation. Drawing a graph. Analysing a document. Manufacturing a
widget. Planning a journey. Firing a missile. Anything! You name it.)
Best wishes
Rob Cliffe
On 08/12
to disparage anyone's motives. I am sure all the posts
were made sincerely and honestly. But without examples (of how deferred
objects would be useful), if *feels to me* (no doubt wrongly) as if
people are using a fig leaf to fight against this PEP.
Best wishes
Rob Cliffe
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 are.
For value
On 06/12/2021 23:13, Steven D'Aprano wrote:
On Mon, Dec 06, 2021 at 10:17:06AM +, 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(arg=[])` "do
that it it a hack) of needing a sentinel value.
Best wishes
Rob Cliffe
You lose encapsulation (the cached value is no longer part of the
function object) and efficiency.
Compiled languages with good optimizing compilers may be able to
optimize away some of that cost. If your language supports stat
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
he wrong word, I think I mean "basic
feature". (And AFAIU can not really be implemented with existing syntax
- well, Turing-complete and all that, but I hope you know what I mean.)
As witness, 12 of the 16 languages that Steven d'Aprano surveyed provide
it. YMMV.
Best wishes
Rob Cliffe
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.
symbol `*`.
Not to mention the half-dozen or so uses of colon (introduce a suite,
slicing, dictionary displays, annotations, lambdas). Anybody still have
a problem with them? Raise your hand and I'll give you your money back.
Best wishes
Rob Cliffe
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
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
mething like, respectively,
"LateBound('[]')"
"[]"
I am sure there is code that uses inspect.signature that would be
broken, but isn't that inevitable anyway?
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-i
ot;credits" or "license" for more information.
>>> def f(x=...):
... try: print("You passed x as", x)
... except UnboundLocalError: print("You didn't pass x")
...
>>> f()
You passed x as Ellipsis
So I must agree with Steven that this should not
That's a hack.
You have to write something that you don't actually intend.
(3) 2% of functions is a lot of functions.
Best wishes
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pytho
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
for debugging.
Best wishes
Rob Cliffe
since the whole (i.e., the ternary expression) is completely finished
by the time you would be able to access it. This is not the case with
a function definition. The function definition leaves behind a
function object, and that function object needs to &q
to use it as a sentinel.
There are also circumstances when you start off thinking that None will
never be a valid argument value, but later you have to cater for it.
Now it does start to look as if you used a hack.
Best wishes
Rob Cliffe
___
Py
ven worse than `=>`, and `=:` is just *begging* to
confuse newcomers "why do we have THREE different assignment symbols?"
You can't have it both ways. Either you re-use `:=`, or you add a third
symbol.
(There would be no actual conflict with the walrus operator.)
Best w
oose which, if any, linter they use, and how strict they want it to
be. But I can also understand that some people might want the
interpreter to also have a built-in linter to flag mistakes.
+1. This just feels like it has "this is a job for linters" written all
over it. YMMV.
Be
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
ore default such as "late" or "defer". Others?
I believe Chris currently favors a.
Please. I have more than once advocated
x:=default
(and there is no clash with the walrus operator, even if others have
said/implied that
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
On 03/11/2021 18:28, Stephen J. Turnbull wrote:
Chris Angelico writes:
> While it's possible to avoid some of those, we can't hold the
> language back because *someone who doesn't understand* might
> misunderstand.
Opposing the proposal wasn't the point of quoting Steve, the point was
On 31/10/2021 21:54, David Mertz, Ph.D. wrote:
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
PEP 671 will be USEFUL to Python programmers. We want it! (When
do we want it? Now!)
This feels dishonest. I believe I qualify as a Python programmer. I
started using Python
ow!)
Best wishes
Rob Cliffe
[snip]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
1 - 100 of 300 matches
Mail list logo
