[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

2020-07-18 Thread Inada Naoki 
It seems great improvement, but I am worrying about performance.

Adding more attributes to the code object will increase memory usage
and importing time. Is there some estimation of the overhead?

And I am worrying precise tracing blocks future advanced bytecode optimization.
Can we omit precise tracing and line number information when
optimization (`-O`) is enabled?

Regards,

On Fri, Jul 17, 2020 at 11:49 PM Mark Shannon  wrote:
>
> Hi all,
>
> I'd like to announce a new PEP.
>
> It is mainly codifying that Python should do what you probably already
> thought it did :)
>
> Should be uncontroversial, but all comments are welcome.
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/BMX32UARJFY3PZZYKRANS6RCMR2XBVVM/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Inada Naoki  
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AXA6MDF7R63LV5MULB2K5MJ4MNI3ZDK6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns

2020-07-18 Thread Federico Salerno 

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.


This could be solved. One option would be to make pattern objects 
callable, such that when you write:


my_pattern = MatchCase("something")

match stuff:
    case my_pattern():
    ...

my_pattern() is used as a pattern object, and a single identifier like 
my_pattern is interpreted, as expected by the current version of the 
PEP, as a capture. I believe this is not subtle enough to be confusing 
to anyone who learns the feature as a whole. We don't, after all, 
confuse function calls for references to a function, or vice-versa.


Also with your proposal the compiler would not be able to tell that x, 
y and z are local variables, because they are only mentioned inside 
string literals.
I was hoping the implementation of MatchCase could take care of this. I 
suppose it would require MatchCase to have access to locals() everywhere 
it's called; would this be a problem?

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4WURK7EVXC5SPZKIRACEAM32RRK2HTY5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns

2020-07-18 Thread Steven D'Aprano 
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()` instead of `function`.

And even experienced developers sometimes forget to put parentheses 
after file.close, or at least we used to before context managers.

(I know I did. I don't think I'm alone.)


-- 
Steven
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2CYL73OEJEB3KPULON4NIC6ETKJ235VZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread emmanuel . coirier 
Terry Reedy wrote:

> A major points of Kohn's post is that 'case' is analogous to 'def' and 
> match lists are analogous to parameter lists.  In parameter lists, 

I'm sorry to disagree, but match lists share very few things in common with 
today's parameters list, and introduce a full new concept of "matching" vs 
"binding/capturing" that doesn't exists with the function definition.

> untagged simple names ('parameter names') are binding targets. 
> Therefore, untagged simple names in match lists, let us call them 'match 
> names' should be also.  I elaborated on this in my response to Tobias.

This approach, for me, seems to come from functionnal languages where pattern 
matching is a thing. The proposed "match" clause tends to mimic this approach, 
and it can be a good thing. But the Python's function definition has not been 
inspired by functionnal programming from the ground, and I think it would be an 
error to reason this way, because people not used to pattern matching in 
functionnal programming won't understand anything (imagine that comprehension 
lists are a big thing for many learners). That's why I think reasonning in such 
a theorical point of view will leads many python developpers to a dead end.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AENMRD23UGV6D5KI25RSQSCJ3YGCGBUY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread emmanuel . coirier 
Ethan Furman wrote:
> The problem with any kind of sigil/keyword is that it becomes line noise 
> -- we would have to train ourselves to ignore them in order to see the 
> structure and variables we are actually interested in.  Once we become 

Every syntax element can become noise once we're used to it. This is how Groovy 
is built from Java : they removed everything that can be removed, and still be 
"understandable" by the compiler. The result is the language being counter 
intuitive for people that don't do Groovy everyday... Can I write thing like 
this ? Seems to work... And with that ? Works too, but I don't know if it 
produces the same effect...

We can also think about syntax elements as strucural elements like pillars, 
helping the thought to elaborate while reading the code. Pillars are 
constraints for people in a building (they block your view, you have to bypass 
them, ...), but they helps building bigger constructions, and we're all used to 
them.

In this slightly modified example from the PEP :

match entree[-1]:
case Sides.SPAM:
response = "Have you got anything without Spam?"
case "letuce": 
response = "blablabla"
case side:
response = f"Well, could I have their Spam instead of the {side} 
then?"
case 1542 | "plop": 
response = "blablabla2"

It's difficult for someone not mastering this feature to see immediatly that 
"side" will get it's value changed and that the last case will never match.

match entree[-1]:
case Sides.SPAM:
response = "Have you got anything without Spam?"
case "letuce": 
response = "blablabla"
case side=:
response = f"Well, could I have their Spam instead of the {side} 
then?"
case 1542 | "plop": 
response = "blablabla2"

Here we immediatly see that the first two cases don't work in the same way as 
the third, because there is "something more". It will even maybe indicate that 
the last case is useless...

> adept at ignoring them, we will again have difficulties when debugging 
> as we won't easily see them.
> Besides which, the problem is solved:
> 
> namespace.var is a lookup
> var is a store

These rules can't be deduced from a few examples, or from experience from other 
languages. You have to explicitly learn them. Since newcomers won't propably 
learn them first (if at all), they won't understand how it works, and they will 
propably introduce bugs hard to debug. They'll think it's a kind of "swith 
case" new construct, and will use it that way, completly ignoring the 
"capturing" property that shows in some cases and not in others. 

match entree[-1]:
case Sides.SPAM:
# newcomers will understand that entree[-1] == Sides.SPAM and write 
the code they need

SPAM = "spam"
match entree[-1]:
case SPAM:
# newcomers will understand that entree[-1] == "spam" and write the 
code they need
# ignoring that now, in the following code, SPAM == anything but 
"spam"
# introducing a bug anywhere in the following code where SPAM is 
expected to hold the
# initial value

Only a unit test case that test that SPAM has changed can detect this kind of 
bug. Generally speaking, unit test cases don't test values of "constants" 
before and after a test case. So it won't even help.

Here, we can argue that match is not a "switch case" like syntax, but newcomers 
from C, Java, Javascript, whatever WILL use it like a "switch case", and WILL 
read code where it will be used like that. Even if it's not the main use case, 
it will be used for that, because of 50 years of history of C that we can't 
ignore. Adding a "=" or something else will at least ring a bell.

We can argue that constants should be namespaced, but is it a general way of 
doing ? People can write "from module import SPAM" or "import module; 
module.SPAM". This is equivalent, but in one case, it may introduce a bug.

Do not forget that Python will be used by many more newcomers, new learners, 
new developers, data scientists, people with unknow backgrounds, and perhaps 
few, or no experience in programming. IMHO Python strength is that it's syntax 
is easy to learn because it is easy to deduce. The some rules that are 
counter-intuitive like the "else" clause for the loops can't cause any harm if 
misused because their misuse is detected immediatly, and we can avoid writing 
them (and most people do). 

On the other hand, "capturing" variables mixed with "match" variables is 
counter-intuitive unless you explicitly learn the rules. You can't deduce it 
(there rules don't exist anywhere else). This feature is central of the PEP and 
will be used, and will introduce subtle bugs when misused.

That's why I consider the rules you stated is not the right way for this 
feature, and that we should be explicit.
___
Python-Dev mailing

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread Koos Zevenhoven 
On Sat, Jul 18, 2020 at 3:46 AM Terry Reedy  wrote:

>
> A major points of Kohn's post is that 'case' is analogous to 'def' and
> match lists are analogous to parameter lists.  In parameter lists,
> untagged simple names ('parameter names') are binding targets.
> Therefore, untagged simple names in match lists, let us call them 'match
> names' should be also.  I elaborated on this in my response to Tobias.
>
>
There are indeed analogous aspects, although not in the most
straightfoward/obvious ways. Still, perhaps even more so than there is
analogy with assignment targets.

This is related to one of my concerns regarding PEP 622. It may be tempting
to see pattern matching as a form of assignment. However, that is quite a
stretch, both conceptually and as a future direction. There is no way these
'match expressions' could be allowed in regular assignments – the way names
are treated just needs to be different. And allowing them in walrus
assignments doesn't make much sense either.

Conceptually, it is strange to call this match operation an assignment.
Most of the added power comes from checking that the object has a certain
structure or contents – and in many cases, that is the only thing it does!
As a (not always) handy side product, it is also able to assign things to
specified targets. Even then, the whole pattern is not assigned to, only
parts of it are.

In mathematics, assignment (definition) and re-assignment is often denoted
with the same sign as equality/identity, because it is usually clear from
the context, which one is in question. Usually, however, it matters which
one is in question. Therefore, as we well know, we have = for assignment,
== for equality, and := to emphasize assignment. Matching is closer to ==,
or almost :==.

So, in many ways, is the assignment that is special, not the matching. It
is also the main thing that differentiates this from the traditional
switch–case construct, which the proposed syntax certainly resembles.

—Koos
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PZWA6F7A5HVQSSJU27KXOBWYVFJZLUF2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns

2020-07-18 Thread Federico Salerno 

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()` instead of `function`.

And even experienced developers sometimes forget to put parentheses
after file.close, or at least we used to before context managers.

(I know I did. I don't think I'm alone.)


I consider myself far from being an experienced developer, but I cannot 
in all honesty say I'm likely to forget parens after file.close any more 
than after any function call. Perhaps it comes down to being used to 
some other language I have never worked with.


I can see why beginners would find the distinction between func and 
func() to be challenging at first, but that is something that subsides 
relatively often. Most likely way before one needs to be aware of the 
intricacies of a complex feature such as pattern matching, considering 
Python, contrary to e.g. Rust or functional languages, is not built 
around that concept and has survived without it thus far. Pattern 
matching would be useful and nice, but not essential to the point that a 
beginner would have to learn it before getting a solid grasp on how 
functions are called or referenced.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread Steven D'Aprano 
On Sat, Jul 18, 2020 at 09:25:45AM -, [email protected] 
wrote:

> This approach, for me, seems to come from functionnal languages where
> pattern matching is a thing. The proposed "match" clause tends to 
> mimic this approach, and it can be a good thing. But the Python's 
> function definition has not been inspired by functionnal programming 
> from the ground, and I think it would be an error to reason this way, 
> because people not used to pattern matching in functionnal programming 
> won't understand anything (imagine that comprehension lists are a big 
> thing for many learners).

It is true that beginners sometimes struggle a bit to grok comprehension 
syntax. I know I did.

And yet, despite that, comprehensions have turned out to be one of the 
most powerful and popular features of Python, sometimes *too* popular. 
It is sometimes hard to convince both beginners and even experienced 
devs that comprehensions are not the only tool in their toolbox, and not 
every problem is a nail.

You say: "people not used to pattern matching in functionnal programming
won't understand anything" but people using Haskell weren't born knowing 
the language. They had to learn it.

It's been sometimes said that functional programmers are smarter, elite 
programmers a level above the average OOP or procedural programmer, but 
that's mostly said by functional programmers :-) and I'm not entirely 
sure that its true. In any case, I don't think that any (actual or 
imaginary) gap between the ability of the average Haskell programmer and 
the average Python programmer is so great that we should dismiss pattern 
matching as beyond the grasp of Python coders.

In any case, functional languages like Haskell, F# and ML are not the 
only languages with pattern matching. Non-FP languages like C#, Swift, 
Rust and Scala have it, and even Java has an extension providing pattern 
matching:

http://tom.loria.fr/wiki/index.php/Main_Page


-- 
Steven
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JC4HWW6DAJAWZLJAW6ACBT5IARA25M2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread Emily Bowman 
On Sat, Jul 18, 2020 at 3:29 AM  wrote:

> > adept at ignoring them, we will again have difficulties when debugging
> > as we won't easily see them.
> > Besides which, the problem is solved:
> >
> > namespace.var is a lookup
> > var is a store
>
> These rules can't be deduced from a few examples, or from experience from
> other languages. You have to explicitly learn them. Since newcomers won't
> propably learn them first (if at all), they won't understand how it works,
> and they will propably introduce bugs hard to debug. They'll think it's a
> kind of "swith case" new construct, and will use it that way, completly
> ignoring the "capturing" property that shows in some cases and not in
> others.
>
> match entree[-1]:
> case Sides.SPAM:
> # newcomers will understand that entree[-1] == Sides.SPAM and
> write the code they need
>
> SPAM = "spam"
> match entree[-1]:
> case SPAM:
> # newcomers will understand that entree[-1] == "spam" and
> write the code they need
> # ignoring that now, in the following code, SPAM == anything
> but "spam"
> # introducing a bug anywhere in the following code where SPAM
> is expected to hold the
> # initial value
>

If a constant's actually constant, as in

SPAM: Final = "spam"

then it'll throw an error. Likewise, the first time it does something
totally unexpected like insert something into what they thought held a
match pattern, it'll break their initial assumptions and hopefully get them
to read the documentation, to form a more accurate mental model.

As long as

> namespace.var is a lookup
> var is a store

is big, bold, and front & center in the docs, I think everyone will catch
on very quickly and wrap their vars in a class, even if they never use it
for more than a glorified switch-case. Designing an entire feature around
what someone who's never encountered it before thinks it might do doesn't
seem useful, since anyone could bring any number of assumptions.

-Em
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BCGMP6LDBWL6LQWKESLNL5NOMJZNLMZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 622 aspects

2020-07-18 Thread Koos Zevenhoven 
PEP 622 authors,

Overall, the PEP describes the proposal quite nicely. However, I do indeed
have concerns and questions, some of which I describe in this email.

(1) Class pattern that does isinstance and nothing else.

If I understand the proposed semantics correctly, `Class()` is equivalent
to checking `isinstance(obj, Class)`, also when `__match_args__` is not
present. However, if a future match protocol is allowed to override this
behavior to mean something else, for example `Class() == obj`, then the
plain isinstance checks won't work anymore! I do find `Class() == obj` to
be a more intuitive and consistent meaning for `Class()` than plain
`isinstance` is.

Instead, the plain isinstance check would seem to be well described by a
pattern like `Class(...)`. This would allow isinstance checks for any
class, and there is even a workaround if you really want to refer to the
Ellipsis object. This is also related to the following point.

(2) The meaning of e.g. `Class(x=1, y=_)` versus `Class(x=1)`

In the proposed semantics, cases like this are equivalent. I can see why
that is desirable in many cases, although Class(x=1, ...)` would make it
more clear. A possible improvement might be to add an optional element to
`__match_args__` that separates optional arguments from required ones
(although "optional" is not the same as "don't care").

(3) Check for exhaustiveness at runtime

The PEP states:

Check exhaustiveness at runtime
> The question is what to do if no case clause has a matching pattern, and
> there is no default case. An earlier version of the proposal specified that
> the behavior in this case would be to throw an exception rather than
> silently falling through.
> The arguments back and forth were many, but in the end the EIBTI (Explicit
> Is Better Than Implicit) argument won out: it's better to have the
> programmer explicitly throw an exception if that is the behavior they want.
> For cases such as sealed classes and enums, where the patterns are all
> known to be members of a discrete set, static checkers can warn about
> missing patterns.


I don't understand this argument. Would it not be more explicit to have an
`else` or `case _` branch to say what should happen in that case?

(4) Check for exhaustiveness by static checkers

About this, the PEP states:

>From a reliability perspective, experience shows that missing a case when
> dealing with a set of possible data values leads to hard to debug issues,
> thus forcing people to add safety asserts like this:
> def get_first(data: Union[int, list[int]]) -> int:
> if isinstance(data, list) and data:
> return data[0]
> elif isinstance(data, int):
> return data
> else:
> assert False, "should never get here"
> PEP 484 specifies that static type checkers should support exhaustiveness
> in conditional checks with respect to enum values. PEP 586 later
> generalized this requirement to literal types.
> This PEP further generalizes this requirement to arbitrary patterns.


This seems reasonable. However, why is the standard for static and runtime
different? The corresponding runtime check is extremely easy and efficient
to do, so if this is an error according to static analysis, why not make it
an error at runtime too?

—Koos
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JUG5JOLDF5NKQU7UFY3ZASKQEFDRJ2JG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-07-18 Thread Terry Reedy 

On 7/18/2020 6:23 AM, [email protected] wrote:

Ethan Furman wrote:

The problem with any kind of sigil/keyword is that it becomes line noise
-- we would have to train ourselves to ignore them in order to see the
structure and variables we are actually interested in.  Once we become


[snip much]


On the other hand, "capturing" variables mixed with "match" variables is 
counter-intuitive unless you explicitly learn the rules. You can't deduce it (there rules don't 
exist anywhere else). This feature is central of the PEP and will be used, and will introduce 
subtle bugs when misused.

That's why I consider the rules you stated is not the right way for this 
feature, and that we should be explicit.


It seems to me that whether one expects simple names in case headers to 
be sources or targets depends on how one analogizes the match code in 
case headers.  If one sees it as analogous to imperative elif 
conditions, where names are value sources, then one likely expects that. 
 If one sees match code as analogous to target or parameter lists, 
where names declare binding targets, then one like expect that behavior 
instead.


Both analogies are inexact because match code needs to have both sources 
and targets.  Different people will have different preferences and 
expectations.


I happen to prefer the parameter list analogy because conditions are 
executable expressions while match code is not and by intention is 
partly to mostly declarative, with the implementation in logic and 
expressions left to the compiler.


--
Terry Jan Reedy
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LJHGWWKYBCAK64AYHISY3JC63VKEOI2G/
Code of Conduct: http://python.org/psf/codeofconduct/