"Pretendere" in Italian means "to demand", it's a false friend with the
English "pretend". I don't know whether Marco is Italian (the false
friend might also be there between Spanish or whatever other romance
language he speaks and English, for all I know). From a native Italian
speaker's
I vaguely remember reading some discussion about Annotated and, for what
little it's worth, I disagree with the consensus.
For now all that comes to mind is either stuffing the information in
docstrings (which would be kind of an involution, seeing as that was the
way for annotating type
I don't have any decent proposal at the moment but I think coming up
with a way to annotate side-effects of functions (including
typeguard-ness) could come in handy. If we anticipate needing that,
perhaps it would be beneficial to come up with that feature before
implementing this PEP, lest we
I'm sorry, I've been skipping around the discussion a bit, but I'm fairly
certain this suggestion hasn't been proposed yet.
It's perhaps a bit too different from what has been proposed thus far but
maybe that's exactly what's needed to convince the minds, since as far as I
see it most of the
I think it's important to remember that many novice programmers today learn
python as their first language.
While i don't think the python tutorial is the right place for teaching how
to program, i also think it would be best if it didn't make too many
assumptions on the reader's knowledge.
When
Re: symbol for lookup
Whatever happened to the proposal of using . as prefix?
If memory serves, the main objection was about it being hard to see, but is
it really? We use fixed width fonts for a reason, and there are other
places a dot is quite critical (has any php programmer ever mistaken a
On 18/07/2020 11:09, Steven D'Aprano wrote:
On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote:
We don't, after all,
confuse function calls for references to a function, or vice-versa.
Beginners do. Frequently. Sometimes it is quite a hurdle for them to
learn to write `function
On 18/07/2020 02:10, Guido van Rossum wrote:
[...] it was quickly pointed out by my co-authors that this doesn't
fly, because when the parser sees `case other_3d_point:` it doesn't
know whether you meant this as a capture pattern (binding the variable
`other_3d_point`) or as a pattern object.
On 16/07/2020 19:00, Rhodri James wrote:
On 16/07/2020 17:37, Steve Holden wrote:
While I understand the point of view that says that match ... :
should encapsulate a sequence of indented suites, it seems to me that
match/case/case/.../else has a natural affinity with
Recent discussion on the store vs. load syntax issues of PEP 622
prompted a (yet unripe) idea that could hopefully spur some progress.
What if cases required some sort of MatchCase (name pending) object
which could be preconstructed by the user if needed, but also inferred
on the fly if
On 13/07/2020 19:17, Guido van Rossum wrote:
I find it debatable that we should have this at all, since there are
other interpretations possible, and honestly I doubt that it’s a
common use case. That’s why we’re holding off.
Fair enough. All it would do would be save code in a guard
On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote:
No, that would not be impossible but fraught with problems. This is
discussed in the PEP:
https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names
The PEP goes into no detail of what these problems (or "number of
On 13/07/2020 00:20, Guido van Rossum wrote:
The need for a wildcard pattern has already been explained -- we
really want to disallow `Point(x, y, y)` but we really need to allow
`Point(z, _, _)`. Generating code to assign the value to `_` seems odd
given the clear intent to *ignore* the
On 12/07/2020 11:38, Larry Hastings wrote:
In that case, I'd like to make a specific pitch for "don't make '_'
special". (I'm going to spell it '_' as it seems to be easier to read
this way; ignore the quotes.)
IIUC '_' is special in two ways:
1) we permit it to be used more than once in a
On 11/07/2020 19:29, Jim J. Jewett wrote:
To me, "else:" has a slightly different meaning than "case _:" case _:
essentially a default, ensuring that the match logic is complete.
else: OK, the subject of this match failed, here is our fallback
logic. Whether this distinction is important
On 11/07/2020 00:57, Paul Sokolovsky wrote:
The PEP itself in "rejected" ideas makes an argument against it:
indented stuff after a line ending with ":" must be a *statement*. It
would be totally nuts for that to be something else, e.g. an expression:
Good point.
That of course leads us to
On 10/07/2020 12:33, Greg Ewing wrote:
A thought about the indentation level of a speculated "else" clause...
Some people have argued that "else" should be at the outer level,
because that's the way it is in all the existing compound statements.
However, in those statements, all the actual
On 09/07/2020 01:27, Ethan Furman wrote:
On 07/08/2020 10:44 AM, Ethan Furman wrote:
So namespaced variables only... is there a recommendation on
handling global() and local() type variables?
Okay, some off-list discussion clarified that for me:
- easiest way is to use a guard
```
On 08/07/2020 12:30, Rhodri James wrote:
Any name used as a pattern is a catch-all. The only difference
between "case dummy:" and "case _:" is that "_" doesn't bind to the
thing being matched, but "dummy" does bind to it.
I meant catch-all as in "case _:" (or "else:"). I apologise for the
On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote:
I used to be in this "camp", however, a (I think valid) point was
raised that "else:" is not a (full) alternative. Due to the
restriction on repeated names (e.g. Point(x, x) is illegal), if you
want to "throw away" intermediate matches, you will
On 03/07/2020 21:55, Rob Cliffe wrote:
I don't like the .name syntax (grit on Tim's monitor; does not
suggest the meaning). Nor am I keen on "expressions" being
interpreted differently after 'case' than elsewhere in Python. But I
don't know what syntax (where necessary) to suggest.
+1
Is there a reason, after all, why we should mark constant patterns as
special, and not the opposite?
On 02/07/2020 19:10, Walter Dörwald wrote:
On 1 Jul 2020, at 18:54, Brandt Bucher wrote:
Walter Dörwald wrote:
This looks strange to me. In all other cases of variable lookup the
22 matches
Mail list logo
