Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
Please, Mike, can you stop? The race is over and your horse has lost. I really value all the input I've received during the months of discussion (including your research into what other languages do), but in the end my "evaluation function" (to use somewhat hip lingo :-) is different from yours. For a while I seriously considered "EXPR as NAME", but when comparing examples written in one style vs. another I just liked "NAME := EXPR" better every time. In addition to the problems with "with" (which everyone has read about already) and the general rule that "as" is preceded by specific syntax that predicts it (i.e. "import", "except" or "with"), I found that when skimming the code it was easier to miss the definition of NAME with the "as" form than with the ":=" variant. There was also someone who posted that they believe that the problems with evaluation order (alluded to in the PEP) would be solved by the "as" form. However that's not the case -- in fact I believe that Python would have to generate exactly the same bytecode for "EXPR as NAME" as for " NAME := EXPR", since in both cases it comes down to "LOAD EXPR; STORE NAME" (in pseudo bytecode). So neither form supports things like "x == (x := f())" since this comes down to LOAD x LOAD f CALL STORE x COMPARE with either syntax variant (again, in pseudo bytecode). On Wed, Jul 4, 2018 at 5:09 PM Mike Miller wrote: > Recently on Python-Dev: > > On 2018-07-03 15:24, Chris Barker wrote: > > On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka < > storch...@gmail.com> > > > > > I believe most Python users are not > > > professional programmers -- they are sysadmins, scientists, > hobbyists > > > and kids -- > > > > [citation needed] > > > > fair enough, but I think we all agree that *many*, if not most, Python > users > > are "not professional programmers". While on the other hand everyone > involved > > in discussion on python-dev and python-ideas is a serious (If not > > "professional") programmer. > > > Python Audience - wants clarity: > > Not sure I'd say that most users are not professionals, but one major > strength > of Python is its suitability as a teaching language, which enlarges the > community every year. > > Additionally, I have noticed a dichotomy between prolific "C programmers" > who've > supported this PEP and many Python programmers who don't want it. While > C-devs > use this construct all the time, their stereotypical Python counterpart is > often > looking for simplicity and clarity instead. That's why we're here, folks. > > > Value - good: > > Several use cases are handled well by PEP 572. However it has been noted > that > complexity must be capped voluntarily relatively early—or the cure soon > becomes > worse than the disease. > > > Frequency - not much: > > The use cases for assignment-expressions are not exceedingly common, > coming up > here and there. Their omission has been a very mild burden and we've done > without for a quarter century. > > Believe the authors agreed that it won't be used too often and won't > typically > be mis- or overused. > > > New Syntax - a high burden: > > For years I've read on these lists that syntax changes must clear a high > threshold of the (Value*Frequency)/Burden (or VF/B) ratio. > > Likewise, a few folks have compared PEP 572 to 498 (f-strings) which some > former > detractors have come to appreciate. Don't believe this comparison applies > well, > since string interpolation is useful a hundred times a day, more concise, > clear, > and runs faster than previous functionality. Threshold was easily cleared > there. > > > Conclusion: > > An incongruous/partially redundant new syntax to perform existing > functionality > more concisely feels too low on the VF/B ratio IMHO. Value is good though > mixed, frequency is low, and burden is higher than we'd like, resulting in > "meh" > and binary reactions. > > Indeed many modern languages omit this feature specifically in an effort > to > reduce complexity, ironically citing the success of Python in support. > Less is > more. > > > Compromise: > > Fortunately there is a compromise design that is chosen often these days > in new > languages---restricting these assignments to if/while (potentially > comp/gen) > statements. We can also reuse the existing "EXPR as NAME" syntax that > already > exists and is widely enjoyed. > > This compromise design: > > 1 Handles the most common cases (of a group of infrequent cases) > 0 Doesn't handle more obscure cases. > 1 No new syntax (through reuse) > 1 Looks Pythonic as hell > 1 Difficult to misuse, complexity capped > > Score: 4/5 > > PEP 572: > > 1 Handles the most common cases (of a group of infrequent cases) > 1 Handles even more obscure cases. > 0 New syntax > 0 Denser look: more colons, parens, expression last > 0 Some potential for misuse, complexity
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 2018-07-05 10:52, Ivan Pozdeev via Python-Dev wrote: > Perhaps, however I'm not advocating using "EXPR as NAME" with "with" as it wouldn't be useful enough, only limited to if/while/comp. -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On Thu, Jul 05, 2018 at 08:52:24PM +0300, Ivan Pozdeev via Python-Dev wrote:
> * Same goes for `except`: doesn't accept expressions, same semantic.
py> def make_exception(arg):
... return ValueError if arg else TypeError
...
py> expr = [make_exception]
py> try:
... 1+"1"
... except expr[0](None) as err:
... print("caught", type(err))
... print(err)
...
caught
unsupported operand type(s) for +: 'int' and 'str'
--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 05.07.2018 3:22, Chris Angelico wrote: Python uses "as NAME" for things that are quite different from this, so it's confusing I wrote in https://mail.python.org/pipermail/python-dev/2018-June/154066.html that this is easily refutable. Looks like not for everybody. Okay, here goes: The constructs that currently use `as' are: * import module as m * except Exception as e: * with expr as obj: * In `with', there's no need to assign both `expr' and its __enter__() result -- because the whole idea of `with' is to put the object through `__enter__', and because a sane `__enter__()' implementation will return `self' anyway (or something with the same semantic -- i.e. _effectively_ `self'). But just in case, the double-assignment can be written as: with (expr as obj) as ctx_obj: by giving "as" lower priority than `with'. As I said, the need for this is nigh-nonexistent. * `import' doesn't allow expressions (so no syntactic clash here), but the semantic of "as" here is equivalent to the AE, so no confusion here. * Same goes for `except`: doesn't accept expressions, same semantic. So, with "as" only `with' becomes the exception -- and an easily explainable one since its whole purpose is to implicitly call the context manager interface. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 2018-07-05 04:28, Ivan Pozdeev via Python-Dev wrote: This is as intended. I wanted to show my summary and Chris' refuttal, with links to both original posts. Because my letter is much shorter than the originals while carrying the same message. Also to show that I've made the same mistake, which puts things in perspective: how an outsider could get the wrong idea. There will always be a long tail of new languages doing any and everything. Which new languages are actually being used? The more limited ones. Static typing, fewer foot-guns. Arguably Elixir should have been in the original list, but it is practically unknown compared to Kotlin, for example. -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 2018-07-04 17:22, Chris Angelico wrote: - the "if expr as name:" syntax is able to handle only the tiniest proportion of cases, because many MANY situations require a condition after that. You can't write this, for instance: if f(x) as spam < 0: print(spam) The original use cases didn't ask for these compound conditions. In fact many of the other threads this week are advising folks to break up an expression with compound conditions due to lack of readability. The common cases described: - compute value once in a comprehension - loop and a half (reading file, socket) - common regex match More complex cases can be handled the old way. > Python uses "as NAME" for things that > are quite different from this, so it's confusing), It's less confusing, and limited. No one bats an eyelash after using "as" day after day in Python and SQL. Good day, -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 2018-07-04 23:20, Steven D'Aprano wrote: It simply isn't true that modern languages are moving away from assignment expressions. Some are. Some aren't. Even those that don't support assignment expressions in general usually support special syntax to allow it in a few contexts. The older post you are referring and this thread describe the exact situation in your last sentence. The limited assignment "compromise" is a common solution nowadays, just as this thread discusses. Repeating "it won't work" when it has been shown to work well in several languages is nonsensical. Yes, the available solutions are not perfect, but I still maintain "as" is less disruptive and doesn't reverse 25 year-old design choices, but rather works with them. -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 05.07.2018 9:20, Steven D'Aprano wrote: On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote: And https://mail.python.org/pipermail/python-dev/2018-June/154160.html disproves the "chosen often these days in new languages". Ivan, I think you may have linked to the wrong page. That page was Chris kindly referring you to my post here: https://mail.python.org/pipermail/python-ideas/2018-May/050938.html This is as intended. I wanted to show my summary and Chris' refuttal, with links to both original posts. Because my letter is much shorter than the originals while carrying the same message. Also to show that I've made the same mistake, which puts things in perspective: how an outsider could get the wrong idea. which refutes Mike's original, biased selection of a handful of languages. Which he then misrepresented as not including assignment expressions when half of them actually do, at least in a limited form. (3 out of the 5 of Mike's examples include *at least* some limited assignment expression. My survey found 13 out of 18 modern languages have at least some form of assignment expression. See link above for details.) It simply isn't true that modern languages are moving away from assignment expressions. Some are. Some aren't. Even those that don't support assignment expressions in general usually support special syntax to allow it in a few contexts. But even if we pretended that, let's say, Go for example has no assignment expressions (it actually does, but limited only to the special case of if statements), what conclusion should we draw? That Rob Pike is ever so much a better language designer than Guido? Maybe he is, maybe he isn't, but Go is just eight years old. Python is 27. When Python was 8, it lacked a lot of features we find indispensible now: https://www.python.org/download/releases/1.5/whatsnew/ Who is to say that when Go is 27, or even 10, it won't have added assignment expressions? Some of Go's choices seem a bit... idiosyncratic. Strings are still ASCII byte-strings. Unicode text is relegated to a seperate type, "runes", the naming of which is a tad patronising and contemptuous of non-ASCII users. There are no exceptions or try...finally. The designers bowed to public pressure and added a sort of poor-man's exception system, panic/recover, but for most purposes, they still requiring the "check a flag to test success" anti-pattern. The designers are actively opposed to assertions. I dare say a lot of Python's choices seem strange to Go programmers too. Rather than saying "Go got it right", maybe we should be saying "Go got it wrong". We can also reuse the existing "EXPR as NAME" syntax that already exists and is widely enjoyed. For the record, with "as", Victor Stinner's examples from the 5 Jul 2018 00:51:37 +0200 letter would look like: Enough with the "as" syntax. This discussion has been going on since FEBRUARY, and "as" was eliminated as ambiguous months ago. Stop beating that dead horse. -- Regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote: > And https://mail.python.org/pipermail/python-dev/2018-June/154160.html > disproves the "chosen often these days in new languages". Ivan, I think you may have linked to the wrong page. That page was Chris kindly referring you to my post here: https://mail.python.org/pipermail/python-ideas/2018-May/050938.html which refutes Mike's original, biased selection of a handful of languages. Which he then misrepresented as not including assignment expressions when half of them actually do, at least in a limited form. (3 out of the 5 of Mike's examples include *at least* some limited assignment expression. My survey found 13 out of 18 modern languages have at least some form of assignment expression. See link above for details.) It simply isn't true that modern languages are moving away from assignment expressions. Some are. Some aren't. Even those that don't support assignment expressions in general usually support special syntax to allow it in a few contexts. But even if we pretended that, let's say, Go for example has no assignment expressions (it actually does, but limited only to the special case of if statements), what conclusion should we draw? That Rob Pike is ever so much a better language designer than Guido? Maybe he is, maybe he isn't, but Go is just eight years old. Python is 27. When Python was 8, it lacked a lot of features we find indispensible now: https://www.python.org/download/releases/1.5/whatsnew/ Who is to say that when Go is 27, or even 10, it won't have added assignment expressions? Some of Go's choices seem a bit... idiosyncratic. Strings are still ASCII byte-strings. Unicode text is relegated to a seperate type, "runes", the naming of which is a tad patronising and contemptuous of non-ASCII users. There are no exceptions or try...finally. The designers bowed to public pressure and added a sort of poor-man's exception system, panic/recover, but for most purposes, they still requiring the "check a flag to test success" anti-pattern. The designers are actively opposed to assertions. I dare say a lot of Python's choices seem strange to Go programmers too. Rather than saying "Go got it right", maybe we should be saying "Go got it wrong". > >We can also reuse the existing "EXPR as NAME" syntax that already > >exists and is widely enjoyed. > > > > For the record, with "as", Victor Stinner's examples from the 5 Jul 2018 > 00:51:37 +0200 letter would look like: Enough with the "as" syntax. This discussion has been going on since FEBRUARY, and "as" was eliminated as ambiguous months ago. Stop beating that dead horse. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On 05.07.2018 2:52, Mike Miller wrote: Recently on Python-Dev: On 2018-07-03 15:24, Chris Barker wrote: > On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka > > > I believe most Python users are not > > professional programmers -- they are sysadmins, scientists, hobbyists > > and kids -- > > [citation needed] > > fair enough, but I think we all agree that *many*, if not most, Python users > are "not professional programmers". While on the other hand everyone involved > in discussion on python-dev and python-ideas is a serious (If not > "professional") programmer. Python Audience - wants clarity: Not sure I'd say that most users are not professionals, but one major strength of Python is its suitability as a teaching language, which enlarges the community every year. Additionally, I have noticed a dichotomy between prolific "C programmers" who've supported this PEP and many Python programmers who don't want it. While C-devs use this construct all the time, their stereotypical Python counterpart is often looking for simplicity and clarity instead. That's why we're here, folks. Value - good: Several use cases are handled well by PEP 572. However it has been noted that complexity must be capped voluntarily relatively early—or the cure soon becomes worse than the disease. Frequency - not much: The use cases for assignment-expressions are not exceedingly common, coming up here and there. Their omission has been a very mild burden and we've done without for a quarter century. Believe the authors agreed that it won't be used too often and won't typically be mis- or overused. New Syntax - a high burden: For years I've read on these lists that syntax changes must clear a high threshold of the (Value*Frequency)/Burden (or VF/B) ratio. Likewise, a few folks have compared PEP 572 to 498 (f-strings) which some former detractors have come to appreciate. Don't believe this comparison applies well, since string interpolation is useful a hundred times a day, more concise, clear, and runs faster than previous functionality. Threshold was easily cleared there. Conclusion: An incongruous/partially redundant new syntax to perform existing functionality more concisely feels too low on the VF/B ratio IMHO. Value is good though mixed, frequency is low, and burden is higher than we'd like, resulting in "meh" and binary reactions. Indeed many modern languages omit this feature specifically in an effort to reduce complexity, ironically citing the success of Python in support. Less is more. Compromise: Fortunately there is a compromise design that is chosen often these days in new languages---restricting these assignments to if/while (potentially comp/gen) statements. https://mail.python.org/pipermail/python-dev/2018-July/154343.html : "Any construct that accepts an expression and uses its result but doesn't allow to insert an additional line in the middle qualifies." If/when is not enough. And https://mail.python.org/pipermail/python-dev/2018-June/154160.html disproves the "chosen often these days in new languages". We can also reuse the existing "EXPR as NAME" syntax that already exists and is widely enjoyed. For the record, with "as", Victor Stinner's examples from the 5 Jul 2018 00:51:37 +0200 letter would look like: while expr as x: while input.readline() as line: while (c//n as q) < n: while (self.__read(1) as s) and s != NUL: while (self.next() as tarinfo) is not None: pass while (match() as m) and (m.end() as j) == i: This compromise design: 1 Handles the most common cases (of a group of infrequent cases) 0 Doesn't handle more obscure cases. 1 No new syntax (through reuse) 1 Looks Pythonic as hell 1 Difficult to misuse, complexity capped Score: 4/5 PEP 572: 1 Handles the most common cases (of a group of infrequent cases) 1 Handles even more obscure cases. 0 New syntax 0 Denser look: more colons, parens, expression last 0 Some potential for misuse, complexity uncapped Score: 2/5 Thanks for reading, happy independence, -Mike Very fitting, given the recent mentions of "dictatorship" and all :-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru -- Regards, Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On Wed, Jul 04, 2018 at 04:52:54PM -0700, Mike Miller wrote: > Additionally, I have noticed a dichotomy between prolific "C programmers" > who've supported this PEP and many Python programmers who don't want it. Prolific C programmers like me, hey? *shakes head in a combination of amusement and bemusement* -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"
On Thu, Jul 5, 2018 at 9:52 AM, Mike Miller wrote: > Compromise: > > Fortunately there is a compromise design that is chosen often these days in > new languages---restricting these assignments to if/while (potentially > comp/gen) statements. We can also reuse the existing "EXPR as NAME" syntax > that already exists and is widely enjoyed. > > This compromise design: > > 1 Handles the most common cases (of a group of infrequent cases) > 0 Doesn't handle more obscure cases. > 1 No new syntax (through reuse) > 1 Looks Pythonic as hell > 1 Difficult to misuse, complexity capped > > Score: 4/5 PLEASE can people stop rehashing this one and go and read previous discussions and the PEP? Your first point is a failure, not a success - the "if expr as name:" syntax is able to handle only the tiniest proportion of cases, because many MANY situations require a condition after that. You can't write this, for instance: if f(x) as spam < 0: print(spam) So it fails the first, fails the second, is identical on the third (it's still new syntax, just reusing a keyword - that's no better than ":="), is dubious on the fourth (Python uses "as NAME" for things that are quite different from this, so it's confusing), and scores a definite win only on the fifth - it's hard to misuse because it's nerfed to oblivion. This is old news. It's not a compromise design - it's a failed previous iteration that is already mentioned in the PEP. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
