Mailing List Archive

On 7/12/20 9:04 AM, Daniel Moisset wrote:
>
> The existing implementation has optimizations here.  If that's
> important, we could achieve the same result with a little dataflow
> analysis to optimize away the dead store.  We could even
> special-case optimizing away dead stores /only/ to '_' and /only/
> in match/case statements and all would be forgiven.
>
> This might work, although it's quite different to what python does in
> general (are you supposed to see the value of `_` in a debugger? or in
> `locals()`?  )


All excellent points.  The debugger question is easier to answer. 
Debuggers for compiled code have dealt with this for years; I'm unsure
of the exact wording but gdb prints something like "<value optimized out>".

As for locals(), my first thought was "suppress the optimization in the
presence of a locals() call".  I dimly recall a precedent where the
presence of locals() in a function body affected code generation, though
sadly it escapes me at the moment**.  Anyway, that seems like a nasty
hack, and it only handles one method of extracting a locals
dict--there's several more, including sys._getframe and
inspect.getframeinfo.  And then the user could rebind those and we
wouldn't notice.  This seems like a non-starter.

Having thought about it some, I propose it'd be acceptable to do dead
store optimization if-and-only-if optimizations are explicitly enabled,
e.g. with "-O".  Allowing explicitly-enabled optimizations to observably
affect runtime behavior does have some precedent, e.g. "-OO" which
breaks doctest, docopt, etc.  It'd be a shame if the existence of
locals() et al meant Python could never ever perform dead store
optimization.


Your other (elided) point is correct too, about sequence matching for a
sequence we don't care about not being as cheap and simple as a store
and an extra reference.


Cheers,


//arry/

** Or maybe I'm confused and thinking of something else entirely.  Maybe
it was "import * inside a function body disables fast locals in Python
2"?  But that doesn't seem to be true either.

On 7/11/2020 7:54 PM, Greg Ewing wrote:
>
> I can see that being a reasonable choice if you're using 8-space
> indents, but I don't see that done much in Python.
>
> Also, directly translating this into Python leads to something that
> looks like a mistake:
>
>     match x:
>     case 1:
>         ...
>     case 2:
>         ...
>
> and as has been pointed out, the alternative of putting x on the
> next line is unprecedented in Python.

If the 2 levels of indenting are really offensive, surely we could teach
editors, black, ourselves, etc. to indent the match statement as:

match pt:
  case (x, y):                # <-- indent by two spaces
    return Point3d(x, y, 0)   # <-- indent by 2 more spaces, for a
total of 4

if x:
    return x  # <-- normally indent by 4 spaces

I used to do something similar with C switch statements.

I guess you couldn't use this trick if you were using tabs. Another
reason to not use them!

Eric

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MZWH24XT5PDP3THWC6LL6Q4ITAASAKON/
Code of Conduct: http://python.org/psf/codeofconduct/

On Jul 11, 2020, at 13:28, MRAB <python@mrabarnett.plus.com> wrote:

> Another possibility is:
>
> match:
> ...
> case ...:
> case ...:

It’s ugly, but you could introduce and require a (soft) keyword on the line after match, e.g.

match:
# Can’t really use `with` here although I think it reads better.
as expression
case …

I still wish cases lined up under match, but it’s not a deal breaker for me.

-Barry

On 07/11/2020 03:31 PM, Guido van Rossum wrote:
> On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman wrote:
>> On 07/11/2020 10:29 AM, 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 enough to express in code is another question, as is whether or not anyone but me would follow this "obvious" convention.  So I'm not convinced  the difference justifies the existence a second syntax.  But I'm also not sure it doesn't, particularly if that distinction were given in the PEP and in documentation for the match statement.
>>
>> This is exactly how I would use it.
>
> Hm... Just the fact that people have been arguing both sides so convincingly makes me worry that something bigger is amiss.

I think it just means there are several "right" ways to do it, we just need to pick one. I'll be happy to use whatever we end up with*.

--
~Ethan~


* I hope. ;-)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TJFM23YDMTMIKMQL74P3FHFGD3H5JM3T/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings <larry@hastings.org> wrote:

> Having thought about it some, I propose it'd be acceptable to do dead
> store optimization if-and-only-if optimizations are explicitly enabled,
> e.g. with "-O". Allowing explicitly-enabled optimizations to observably
> affect runtime behavior does have some precedent, e.g. "-OO" which breaks
> doctest, docopt, etc. It'd be a shame if the existence of locals() et al
> meant Python could never ever perform dead store optimization.
>

Assuming you're still talking about how to implement wildcards, it really
sounds like you're willing to add a lot of complexity just to have a
"consistent" treatment of `_`. But why would you care so much about that
consistency? When I write `for x, _, _ in pts` the main point is not that I
can write `print(_)` and get the z coordinate. The main point is that I am
not interested in the y or the z coordinates (and showing this to the
reader up front). The value assigned to `_` is uninteresting (even in a
debug session, unless you're debugging Python itself).

Using the same character in patterns makes intuitive sense to anyone who is
familiar with this convention in Python. Furthermore it also makes sense to
anyone who is familiar with patterns in other languages: *all* languages
with structural pattern matching that we found at uses `_` -- C#, Elixir,
Erlang, Scala, Rust, F#, Haskell, Mathematica, OCaml, Ruby, and Swift.
(That's a much stronger precedent than the use of `?` in shell and regular
expressions IMO. :-)

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 value.

Using `?` as the wildcard has mostly disadvantages: it requires changes to
the tokenizer, it could conflict with other future uses of `?` (it's been
proposed for type annotations as a shorter version of Optional, and there's
PEP 505, which I think isn't quite dead yet), and Python users have no
pre-existing intuition for its meaning.

A note about i18n: it would be unfortunate if we had to teach users they
couldn't use `_` as a wildcard in patterns in code that also uses `_` as
part of the i18n stack (`from gettext import gettext as _` -- see gettext
stdlib docs). This is a known limitation on the `for x, _, _ in ...` idiom,
which I've seen people work around by writing things like `for x, __, __ in
...`. But for patterns (because the pattern code generation needs to know
about wildcards) we can't easily use that workaround. However, the solution
of never assigning to `_` (by definition, rather than through dead store
optimization) solves this case as well.

So can we please lay this one to rest?

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On 2020-07-12 23:20, Guido van Rossum wrote:
[snip]
> 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 value.
>
> Using `?` as the wildcard has mostly disadvantages: it requires changes
> to the tokenizer, it could conflict with other future uses of `?` (it's
> been proposed for type annotations as a shorter version of Optional, and
> there's PEP 505, which I think isn't quite dead yet), and Python users
> have no pre-existing intuition for its meaning.
>
FWIW, I don't think this use of '?' would conflict with the other
suggested uses because this use would be initial in an expression,
whereas the other uses would be non-initial.

[snip]
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/D33YT2KBNVZS27JJIYA5BDWPIP5IWB7M/
Code of Conduct: http://python.org/psf/codeofconduct/

On 7/11/2020 6:31 PM, Guido van Rossum wrote:

> Hm... Just the fact that people have been arguing both sides so
> convincingly makes me worry that something bigger is amiss. I think
> we're either better off without `else` (since the indentation of `case
> _` cannot be disputed :-), or we have to revisit the reasons for
> indenting `case` relative to `match`. As MRAB said, it's a case of
> picking the least inelegant one.

The more I think about adjusting IDLE's smart indenter to indent case
suites once, with 2 half size indents, the more I would prefer to
special case 'match' to have no indent (if there were no suite allowed)
than special case 'match' and 'case' to indent 1/2 Indent.

Problem 1. Indent increments can be set to an odd number of spaces!
(.rst files use 3 space indents.)

Problem 2. Dedent (with Backspace) could no longer be the simple
expression I expect it currently is, such as new-indent = current-indent
spaces // current indent size.
IDLE would have to search backwards to find the appropriate header line,
which might not be the most recent one. A stack of indent (delta,size)
pairs would have to be recalculated from the most recent non-indented
compound header line when the cursor is moved around.

Note that current indent may not be an indent size multiple number due
to PEP8 vertical alignments, such as with function parameters or arguments.3

if a:
def fg(param1, # comment
param2, # 11 space indent
| # Backspace moves cursor left 3 spaces.

The flexibility of the peg parser needs to be used with care because it
can allow constructs that are difficult for people and non-peg code to
read and process.

--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SSP5EZIPOK74S26HF2GJZI4WJG7VJONZ/
Code of Conduct: http://python.org/psf/codeofconduct/

On 13/07/20 7:12 am, Larry Hastings wrote:
> I dimly recall a precedent where the
> presence of locals() in a function body affected code generation,

The presence of exec used to do that, which is why it was a
statement rather than a function. But I don't think locals()
ever did -- how would the compiler know that it was calling
the builtin locals function and not something else?

--
Greg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JCMENW5LTSWB62NPEDEYQK36J3ANJRGI/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Jul 12, 2020 at 7:36 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:

> On 13/07/20 7:12 am, Larry Hastings wrote:
> > I dimly recall a precedent where the
> > presence of locals() in a function body affected code generation,
>
> The presence of exec used to do that, which is why it was a
> statement rather than a function. But I don't think locals()
> ever did -- how would the compiler know that it was calling
> the builtin locals function and not something else?
>

super() does something similar:

>>> class A:
... def super_locals(self):
... super
... return locals()
... def superless_locals(self):
... return locals()
...
>>> A().super_locals()
{'self': <__main__.A object at 0x000001FF53BCE6D8>, '__class__': <class
'__main__.A'>}
>>> A().superless_locals()
{'self': <__main__.A object at 0x000001FF53BCE7B8>}

The compiler changes what local variables exist if there is a read from a
variable named 'super', in order to support zero-argument super() calls. It
presumably could do the same sort of thing for locals(). I don't think this
is a good idea, since locals() is a debugging tool, and changing reality
based on the presence of debugging calls may make life more difficult for
the user.

-- Devin

On 13/07/20 3:28 pm, Devin Jeanpierre wrote:
> The compiler changes what local variables exist if there is a read from
> a variable named 'super',

That's fairly harmless if there's a false positive. But
accidentally getting all your locals de-optimised would be
annoying.

--
Greg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WPN7TNWEONPAEVDWG7J7FHFNOYQUSD2B/
Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum writes:

> [several reasons why not binding _ is a no-op<wink/>, and]

> A note about i18n: [...]. So can we please lay this one to rest?

Yes, please! I was just about to ask about that. I could not believe
that in July 2020 people were ignoring I18N, especially the fact that
I18N workers are mostly language specialists, not programmers, and are
quite dependent on programmers and UI/UX workers following "the usual
conventions".

Yes, mostly the message catalogs are produced by software that can be
taught to understand other conventions. But often translators *do*
need to read source to get context for the (usually) English "key"
into the message catalogs.

Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YUV64JUL32HZDPI43B2Q5BO7MQSBBS4H/
Code of Conduct: http://python.org/psf/codeofconduct/

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 value.

Would it be impossible for the parser to interpret Point(x, y, y) as
"the second and third arguments of Point must have the same value in
order to match. Bind that value to y"? Since the value has to be the
same, it doesn't matter whether y binds to the first or the second (or
the nth) instance of it.

That said, in time and with all the arguments brought to the table, I
personally came to accept special-casing _, although I don't especially
like it. From my point of view, the biggest issue to solve is the load
vs. store decision and its syntax.

On Mon, 13 Jul 2020 at 09:30, Federico Salerno <salernof11@gmail.com> wrote:

> 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 value.
>
> Would it be impossible for the parser to interpret Point(x, y, y) as "the
> second and third arguments of Point must have the same value in order to
> match. Bind that value to y"? Since the value has to be the same, it
> doesn't matter whether y binds to the first or the second (or the nth)
> instance of it.
>
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

On 12/07/2020 23:20, Guido van Rossum wrote:
> So can we please lay this one to rest?

Sure. One small thing before we leave it; I've decided I don't care
about the special cases of not using _. to lead class names, but
forbidding **_ in mapping patterns seems unnecessary. I know it's
redundant, but I can imagine using it for emphasis. I can't think of
anywhere else the language forbids something just because it isn't
needed, though I didn't get a lot of sleep last night and I could well
be missing something obvious :-)

Can I use pattern matching to pull byte strings apart? I thought I
could, but trying it out in the playground didn't work at all. :-(

--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WD2E3K5TWR4E6PZBM4TKGHTJ7VDERTDG/
Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Jul 13, 2020 at 04:35 Rhodri James <rhodri@kynesim.co.uk> wrote:

> On 12/07/2020 23:20, Guido van Rossum wrote:
> > So can we please lay this one to rest?
>
> Sure. One small thing before we leave it; I've decided I don't care
> about the special cases of not using _. to lead class names, but
> forbidding **_ in mapping patterns seems unnecessary. I know it's
> redundant, but I can imagine using it for emphasis. I can't think of
> anywhere else the language forbids something just because it isn't
> needed, though I didn't get a lot of sleep last night and I could well
> be missing something obvious :-)


I’d rather not. And the argument about disallowing obviously redundant
syntax seems weak. My worry about allowing this is that it’ll be cargo
culled and we’ll see it used not for emphasis (of what? The obvious?) but
because people think it’s needed. And that’s just clutter.


Can I use pattern matching to pull byte strings apart? I thought I
> could, but trying it out in the playground didn't work at all. :-(


It’s explicitly forbidden by the PEP, because we don’t want str or bytes to
accidentally match sequence patterns. You could do ‘match list(b):’ if you
really wanted to, but I think there are better tools for parsing bytes or
strings.

—Guido

--
--Guido (mobile)

On 13/07/2020 15:33, Guido van Rossum wrote:
> On Mon, Jul 13, 2020 at 04:35 Rhodri James <rhodri@kynesim.co.uk> wrote:
>

[Re: forbidding **_ in mapping patterns]

>
>
> I’d rather not. And the argument about disallowing obviously redundant
> syntax seems weak. My worry about allowing this is that it’ll be cargo
> culled and we’ll see it used not for emphasis (of what? The obvious?) but
> because people think it’s needed. And that’s just clutter.

Fair enough. I'd likely use it to remind myself of cases when there
will always be more keys in the mapping, but a comment will do just as well.

>> Can I use pattern matching to pull byte strings apart? I thought I
>> could, but trying it out in the playground didn't work at all. :-(
>
>
> It’s explicitly forbidden by the PEP, because we don’t want str or bytes to
> accidentally match sequence patterns. You could do ‘match list(b):’ if you
> really wanted to, but I think there are better tools for parsing bytes or
> strings.

:-( As an embedded engineer, pulling apart network protocols was the
first use I thought of for matching. Ah well.

--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FDWO3SN3FTKUOMYCO3HRYDCPWMBGBM4P/
Code of Conduct: http://python.org/psf/codeofconduct/

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
subtleties") are, but it does mention how

> we decided to make repeated use of names within the same pattern an
> error; we can always relax this restriction later without affecting
> backwards compatibility
which does hint at the fact that the problems are not insurmountable
hurdles.

All in all not an urgent feature, but it would be nice to have from the
get-go if there is agreement and it is doable.


@PEP authors: Incidentally, I am eager to start contributing and see
this PEP advance—if there's anything I can do, including possibly
non-code "dirty work" please let me know.
I was thinking of collecting all the objections and points of contention
of the PEP and the current progress on each in one place so that the
pros and cons can be evaluated more clearly. Would that be useful?

On Mon, Jul 13, 2020 at 10:07 Federico Salerno <salernof11@gmail.com> wrote:

> 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
> subtleties") are, but it does mention how
>
> we decided to make repeated use of names within the same pattern an error;
> we can always relax this restriction later without affecting backwards
> compatibility
>
> which does hint at the fact that the problems are not insurmountable
> hurdles.
>
> All in all not an urgent feature, but it would be nice to have from the
> get-go if there is agreement and it is doable.
>
>
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.

>
> @PEP authors: Incidentally, I am eager to start contributing and see this
> PEP advance—if there's anything I can do, including possibly non-code
> "dirty work" please let me know.
> I was thinking of collecting all the objections and points of contention
> of the PEP and the current progress on each in one place so that the pros
> and cons can be evaluated more clearly. Would that be useful?
>

Thanks for offering, but we’ve got that under control.

—Guido

> --
--Guido (mobile)

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 condition
after all.

> Thanks for offering, but we’ve got that under control.
I wasn't trying to imply otherwise. :)

On 7/12/20 3:20 PM, Guido van Rossum wrote:
> On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings <larry@hastings.org
> <mailto:larry@hastings.org>> wrote:
>
> Having thought about it some, I propose it'd be acceptable to do
> dead store optimization if-and-only-if optimizations are
> explicitly enabled, e.g. with "-O".  Allowing explicitly-enabled
> optimizations to observably affect runtime behavior does have some
> precedent, e.g. "-OO" which breaks doctest, docopt, etc.  It'd be
> a shame if the existence of locals() et al meant Python could
> never ever perform dead store optimization.
>
>
> Assuming you're still talking about how to implement wildcards, it
> really sounds like you're willing to add a lot of complexity just to
> have a "consistent" treatment of `_`. But why would you care so much
> about that consistency?

I'm a fan of the Zen guidance here: "special cases aren't special enough
to break the rules".

More on this topic in a moment--rather than reorder paragraphs, let me
return to this below.


> Using the same character in patterns makes intuitive sense to anyone
> who is familiar with this convention in Python. Furthermore it also
> makes sense to anyone who is familiar with patterns in other
> languages: *all* languages with structural pattern matching that we
> found at uses `_` -- C#, Elixir, Erlang, Scala, Rust, F#, Haskell,
> Mathematica, OCaml, Ruby, and Swift. (That's a much stronger precedent
> than the use of `?` in shell and regular expressions IMO. :-)

Python hasn't been afraid to go its own way syntactically in the past. 
Consider the conditional (ternary) operator.  Most languages I've
encountered with a conditional operator just copy C's syntax, with '?'
and ':' (PHP, C#, Java).  Some languages don't need a conditional
operator, as their existing flow control already works just fine (FORTH,
Rust).  Python's syntax for the conditional operator was neither, and
was AFAIK unique--but this syntax was judged the most Pythonic, so it won.

Similarly, AFAIK Python's "None" is unique.  Most other languages I've
seen use the word "null", albeit with varying capitalization.

So I'm unconcerned about Python using a different token for the wildcard
pattern.  Python already doesn't look like other languages, Python's
proposed syntax for pattern matching isn't exactly like the pattern
matching syntax of other languages.  I don't understand why it's so
important that it look like other languages in this one specific respect.

As for leveraging the convention of using '_' for values you don't care
about in Python--that's actually why I /don't/ like it as the wildcard
pattern.  To date, everyone who uses '_' understands it's just an
identifier, no different from any other identifier.  I imagine I18N
programmers avoid this convention for exactly that reason--there's
nothing special about '_', so they need to take care to not overwrite or
occlude it with a don't-care value.

However, if I understand PEP 622 correctly, the places you use '_' as
the wildcard pattern are also places where you could put an identifier. 
But in this one context, '_' doesn't behave like the other identifiers,
even though in every other context in Python it still does.  This is the
"special case" that "breaks the rules" I alluded to above.

Consistency with the longstanding semantics of '_', and consistency with
other identifiers, is much more important to me than consistency with
other languages for the pattern matching wildcard token.


> Using `?` as the wildcard has mostly disadvantages: it requires
> changes to the tokenizer, it could conflict with other future uses of
> `?` (it's been proposed for type annotations as a shorter version of
> Optional, and there's PEP 505, which I think isn't quite dead yet),
> and Python users have no pre-existing intuition for its meaning.

One reason I prefer '?' for the wildcard pattern is precisely /because/
users have no pre-existing intuition as to its meaning.  Unlike '_', the
user would have no preconceived notion about its semantics to unlearn. 
Also, it doesn't behave like an identifier, and accordingly it doesn't
look like an identifier.  This strikes me as harmonious.

Is changing the tokenizer to support '?' as a token a big deal? You
mention two other existing proposals to use it as a token--surely this
is a bridge we'll have to cross sooner or later.


My goal in starting this discussion was to see if we could find a
compromise everyone could live with.  People who want to use '_' for
wildcard pattern could do so, people who didn't like '_' having a
special meaning in this one context would be appeased. The message I'm
getting is "this compromise won't work".  Okay, fair enough.  I don't
plan to pursue it any further.


Cheers,


//arry/

Larry Hastings wrote:

> As for leveraging the convention of using '_' for values you don't care
> about in Python--that's actually why I /don't/ like it as the wildcard
> pattern.  To date, everyone who uses '_' understands it's just an
> identifier, no different from any other identifier.

Not quite... I understand it more like a file in /tmp
I don't use it for anything I will want later, just in case.

> However, if I understand PEP 622 correctly, the places you use '_' as
> the wildcard pattern are also places where you could put an identifier. 
> But in this one context, '_' doesn't behave like the other identifiers,
> even though in every other context in Python it still does.  This is the
> "special case" that "breaks the rules" I alluded to above.
> Consistency with the longstanding semantics of '_', and consistency with
> other identifiers, is much more important to me than consistency with
> other languages for the pattern matching wildcard token.

If a normal variable name is re-used, I would expect it to have the same meaning.

I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been postponed, but it could still happen later, and it would be a problem if that ever became legal without requiring the two bindings to match. I do NOT assume that they will match if the variable happens to be _, though I suppose others might.

-jJ
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E3BMB3BWC7NXKAQKY33EVLTPWCIU7RAS/
Code of Conduct: http://python.org/psf/codeofconduct/

On 07/14/2020 09:22 AM, Jim J. Jewett wrote:
> Larry Hastings wrote:
>
>> As for leveraging the convention of using '_' for values you don't care
>> about in Python--that's actually why I /don't/ like it as the wildcard
>> pattern.  To date, everyone who uses '_' understands it's just an
>> identifier, no different from any other identifier.
>>
>> However, if I understand PEP 622 correctly, the places you use '_' as
>> the wildcard pattern are also places where you could put an identifier.
>> But in this one context, '_' doesn't behave like the other identifiers,
>> even though in every other context in Python it still does.  This is the
>> "special case" that "breaks the rules" I alluded to above.
>> Consistency with the longstanding semantics of '_', and consistency with
>> other identifiers, is much more important to me than consistency with
>> other languages for the pattern matching wildcard token.

Looking at other languages for inspiration is great, but like Larry I think we should make sure our constructs fit with Python, not with them.

> I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been postponed, but it could still happen later, and it would be a problem if that ever became legal without requiring the two bindings to match. I do NOT assume that they will match if the variable happens to be _, though I suppose others might.

If we use `?` instead of `_`, then repeated `?` won't be a problem, and repeated `_` should be disallowed.

Since `_` is a normal variable name, the requirement for their values to match (when that is finally implemented) would make sense, and shouldn't be a burden to remember given that that the "don't care" symbol is a `?`.

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AD7OYFKDIQIXGP3L27JK6FCX372TSU52/
Code of Conduct: http://python.org/psf/codeofconduct/

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
try/except/except/.../finally/else, and nobody seems to think that the
excepts should be indented. Or the finally. And naturally the match/else
case are at the same indentation level, just as for/else, while/else and
try/finally. So why, exactly, should case be indented?

My apologies for being a Bear of Very Little Brain.


On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
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 code belonging to the
> statement is indented to the same level:
>
> if a:
> ....
> elif b:
> ....
> else:
> ....
>
> ^
> |
> Code all indented to this level
>
> But if we were to indent "else" to the same level as "match",
> the code under it would be at a different level from the rest.
>
> match a:
> case 1:
> ....
> case 2:
> ....
> else:
> ....
> ^ ^
> | |
> Code indented to two different levels
>
> This doesn't seem right to me, because all of the cases, including
> the else, are on the same footing semantically, just as they are in
> an "if" statement.
>
> --
> Greg
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ACH4QXCURTNEGKFQXEWET5NQ6DIABSQZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

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
> try/except/except/.../finally/else, and nobody seems to think that the
> excepts should be indented. Or the finally. And naturally the match/else
> case are at the same indentation level, just as for/else, while/else and
> try/finally. So why, exactly, should case be indented?

My take on the difference would be that "try" tries out a suite, while
"match" matches an expression. If we did:

match:
<expression>
case <pattern>:
<suite>

then having an indented section which must be a single expression would
be unique in Python syntax. I could easily see people being confused
when the slew of statements they would inevitably decide they must be
able to put there, and soon we'd have cats and dogs living together and
the downfall of civilisation as we know it.

Alternatively:

match <expression>:
case <pattern>:
<suite>

would be the one place in Python where you end a line with a colon and
*don't* indent the following line. Writers of simple formatters and the
like (such as Python-mode in Emacs) would curse your name, etc, etc.

> My apologies for being a Bear of Very Little Brain.

Nah, don't apologise. This is one of those things that everyone has
opinions on, because there doesn't seem to be an obvious Right Answer.

--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JYDDPBDO56EQWTFSWY2NNDNT2NDHWXG5/
Code of Conduct: http://python.org/psf/codeofconduct/

On 2020-07-16 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
> try/except/except/.../finally/else, and nobody seems to think that the
> excepts should be indented. Or the finally. And naturally the match/else
> case are at the same indentation level, just as for/else, while/else and
> try/finally. So why, exactly, should case be indented?
>
> My apologies for being a Bear of Very Little Brain.
>
[snip]
For all other statement structures (if, while, try, etc.), the first
line ends with a colon and the second line is indented (and is a
statement). Therefore the cases should be indented.

However, for all other statement structures (if, while, try, etc.), the
other parts of the structure itself (elif, else, except, etc.) aren't
indented. Therefore the cases shouldn't be indented.

Either way, it's inelegant.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4W2J5SLLOTLPMMFIZ4KTAC4THJMDCWBW/
Code of Conduct: http://python.org/psf/codeofconduct/