[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
On Tue, Jul 28, 2020 at 2:12 PM Jim J. Jewett wrote: > ah... we may have been talking past each other. > > Steve Dower wrote: > > On 25Jul2020 2014, Jim J. Jewett wrote: > > > But it sounds as though you are saying the benefit > > [of storing the line numbers in an external table, I thought, > but perhaps Pablo Galindo Salgado and yourself were > talking only of the switch from an lnotab string to an opaque > co_linetable?] > > > > is irrelevant; it is just inherently too expensive to ask programs > that are already dealing > > > with internals and trying to optimize performance to make a mechanical > change from: > > > code.magic_attrname > > > to: > > > magicdict[code] > > > What have I missed? > > > You've missed that debugging and profiling tools that operate purely on > > native memory can't execute Python code, so the "magic" has to be easily > > representable in C such that it can be copied into whichever language is > > being used (whether it's C, C++, C#, Rust, or something else). > > Unless you really were talking only of the switch to co_linetable, I'm > still > missing the problem. To me, it still looks like a call to: > > PyAPI_FUNC(PyObject *) PyObject_GetAttrString(PyObject *, const char > *); > > with the code object being stepped through and "co_lnotab" > would be replaced by: > > PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key); > > using that same code object as the key, but getting the dict from > some well-known (yet-to-be-defined) location, such as sys.code_to_lnotab. > > Mark Shannon and Carl Shapiro had seemed to object to the PEP because > the new structure would make the code object longer, and making it smaller > by a string does seem likely to be good. But if your real objections are > to > just to replacing the lnotab format with something that needs to be > executed, then I apologize for misunderstanding. > Introspection of the running CPython process is happening from outside of the CPython interpreter itself. Either from a signal handler or C/C++ managed thread within the process, or (as Pablo suggested) from outside the process entirely. Calling CPython APIs is a non-option in all of those situations. That is why I suggested that the "undocumented" new co_linetable will be used instead of the disappeared co_lnotab regardless of documentation or claimed stability guarantees. It sounds like an equivalent read only data source for this purpose. It doesn't matter to anyone with such a profiler if it is claimed to be unspecified. The data is needed, and the format shouldn't change within a stable python major.minor release (we'd be unlikely to anyways even without that guarantee). Given this, I suggest at least specifying valuable properties of it such as "read only, never mutated" even if the exact format is intentionally left as implementation defined, subject to change between minor releases structure. -gps > > -jJ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/WUEFHFTPVTOPA3EFHACDECT3ZPLGGTFJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/MQHSIXLAUL2ZSRORRDJEF3I3T73XP772/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
I'm still only intermittently keeping up on python-dev, but my main concern
with the first iteration remains in this version, which is that it doesn't
even *mention* that the proposed name binding syntax inherently conflicts
with the existing assignment statement lvalue syntax in two areas:
* dotted names (binds an attribute in assignment, looks up a constraint
value in a match case)
* underscore targets (binds in assignment, wildcard match without binding
in a match case)
The latter could potentially be made internally consistent in the future by
redefining "_" and "__" as soft keywords that don't get bound via normal
assignment statements either (requiring that they be set via namespace dict
modification instead for use cases like il8n).
https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard
presents a reasonable rationale for the usage, so it's only flaw is failing
to mention the inconsistency.
The former syntactic conflict presents a bigger problem, though, as it
means that we'd be irrevocably committed to having two different lvalue
syntaxes for the rest of Python's future as a language.
https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern
is nominally about this problem, but it doesn't even *mention* the single
biggest benefit of putting a common prefix on value constraints: it leaves
the door open to unifying the lvalue syntax again in the future by keeping
the proposed match case syntax a strict superset of the existing assignment
target syntax, rather than partially conflicting with it.
More incidentally, the latest write-up also leaves out "?" as a suggested
constraint value prefix, when that's the single character prefix that best
implies the question "Does the runtime value at this position equal the
result of this value constraint expression?" without having any other
existing semantic implications in Python.
Cheers,
Nick.
P.S. I feel I should mention that the other reason I like "?" as a
potential prefix for value constraints is that if we require it for all
value constraint expressions (both literals and name lookups) I believe it
could offer a way to unblock the None-aware expressions PEP by reframing
that PEP as a shorthand for particular case matches.
None coalescence ("a ?? b") for example:
match a:
case ?None:
_expr_result = b
case _match:
_expr_result = _match
Or a None-severing attribute lookup ("a?.b"):
_match_expr = a
match _match_expr:
case ?None:
_expr_result = _match_expr
case _match:
_expr_result = _match.b
Since these operations would be defined in terms of *equality* (as per PEP
622), rather than identity, it would also allow other sentinels to benefit
from the None-aware shorthand by defining themselves as being equal to None.
On Thu., 9 Jul. 2020, 1:07 am Guido van Rossum, wrote:
> Today I’m happy (and a little trepidatious) to announce the next
> version of PEP 622, Pattern Matching. As authors we welcome Daniel F
> Moisset in our midst. Daniel wrote a lot of the new text in this
> version, which introduces the subject matter much more gently than the
> first version did. He also convinced us to drop the `__match__`
> protocol for now: the proposal stands quite well without that kind of
> extensibility, and postponing it will allow us to design it at a later
> time when we have more experience with how `match` is being used.
>
> That said, the new version does not differ dramatically in what we
> propose. Apart from dropping `__match__` we’re dropping the leading
> dot to mark named constants, without a replacement, and everything
> else looks like we’re digging in our heels. Why is that? Given the
> firestorm of feedback we received and the numerous proposals (still
> coming) for alternative syntax, it seems a bad tactic not to give up
> something more substantial in order to get this proposal passed. Let
> me explain.
>
> Language design is not like politics. It’s not like mathematics
> either, but I don’t think this situation is at all similar to
> negotiating a higher minimum wage in exchange for a lower pension,
> where you can definitely argue about exactly how much lower/higher
> you’re willing to go. So I don’t think it’s right to propose making
> the feature a little bit uglier just to get it accepted.
>
> Frankly, 90% of the issue is about what among the authors we’ve dubbed
> the “load/store” problem (although Tobias never tires to explain that
> the “load” part is really “load-and-compare”). There’s a considerable
> section devoted to this topic in the PEP, but I’d like to give it
> another try here.
>
> In case you’ve been avoiding python-dev lately, the problem is
> this. Pattern matching lets you capture values from the subject,
> similar to sequence unpacking, so that you can write for example
> ```
> x = range(4)
> match x:
> case (a, b, *rest):
> print(f"first={a}, second={b}, rest={re
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro wrote:
>
>
> On Fri, 17 Jul 2020 at 12:26, wrote:
>
>> Hello everyone,
>> (...)
>> But... looking at the examples, it wasn't very obvious that some
>> variables were catching variables and some others were matching ones.
>> I then read in details some rules about how to discover what is a
>> captured variable. But I'm not sure everybody will do this...
>>
>> Zen of Python tells us that "explicit is better than implicit". I know
>> this is not a rule written in the stone, but I think here, it applies
>> very well.
>>
>>
I Also dislike the idea of undotted names being assigned, with not extra
visual clues,
and the scenario described by Emmanuel, in the other e-mail about
people changing variables when they think they are making a match
(essentially introducing the _same_ problem that `if (SPAM = 0):` had in C
which Python used to justify assignment not being an expression for over
20 years).
So, in adding to the bikeshed color possibilities, alongside
the "x=, y=" in this first e-mail or the "_ as x, _ as y" from Gustavo,
I present the possibility of making the Walrus mandatory for capture.
Maybe it is a bit "too much typing" - (Walrus will require 5-6 keystrokes
with the surrounding spaces), but I think the final look can be pleasantly
intuitive:
match my_point:
case (x := _, y := _) | Point2d(x := _, y := _):
return Point3d(x, y, 0)
> Guido said :
>> > We’re really looking
>> > for a solution that tells you when you’re looking at an individual
>> > case which variables are captured and which are used for
>> > load-and-compare.
>> >
>> > Marking up the capture variables with some sigil (e.g. $x or
>> > x?)
>> > or other markup (e.g. backticks or ) makes this common case ugly
>> > and inconsistent: it’s unpleasant to see for example
>> >
>> > case %x, %y:
>> > print(x, y)
>>
>> Guido talk about a "sigil", which seems to be a meaningless mark only
>> here to help the parser understand what the dev was writing.
>>
>> I propose that this "sigil" be the affectation mark : "=". Look :
>>
>> z = 42
>> match pt:
>> case x=, y=, z:
>> print(x, y, "z == 42")
>>
> (...)
Gustavo Carneiro wrote:
> I kind of agree it is nicer to be more explicit. But somehow x= looks
> ugly. It occurred to me (and, again, apologies if already been mentioned),
> we might use the `as` keyword here.
>
> The example above would become:
>
> def make_point_3d(pt):
> match pt:
> case (as x, as y):
> return Point3d(x, y, 0)
> case (as x, as y, as z):
> return Point3d(x, y, z)
> case Point2d(as x, as y):
> return Point3d(x, y, 0)
> case Point3d(_, _, _):
> return pt
> case _:
> raise TypeError("not a point we support")
>
> If having "as x" as a standalone expression without anything to the left
> of "as" causes confusion, we could instead mandate the use of _ thus:
>
> case (_ as x, _ as y):
> return Point3d(x, y, 0)
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/EZGTHXOYTHRQ6JCEP7B26IA5RVGHEZAC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano wrote: > On Sat, Jul 18, 2020 at 09:25:45AM -, > emmanuel.coir...@caissedesdepots.fr 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: > > You do a nice job arguing that matching is a nice feature to have - and I guess we are past this point. But I don't see one thing in the above characters pointing that using an undifferentiated name by itself in the match/case construct will be better than trying to find a way to differentiate it, and having significant gains in readability and "learnability" Yes, people aren't born knowing Haskell, but then, one of the strong points in Python is (or used to be) it _not looking_ like Haskell. Having a differentiation sign for assignment would also allow matching against values in variables just work in a very intuitive way, just like it would have happened with the ".variable_name" in the first version. (I've written another e-mail on the thread, but since this scatters around: my current bikeshed color is to _require_ the walrus op for assignments like in: `case (x := _, y := _): ...` ) js -><- http://tom.loria.fr/wiki/index.php/Main_Page > > > -- > Steven > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/2EGPJJXDTAKQVSY75PBE3A7BWCBXAKMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
