[issue44600] match/case statements trace incorrectly in 3.10.0b4

Łukasz Langa added the comment: New changeset 5502ee052fb4257ad7438dd1130c80e1a9c4bc7f by Miss Islington (bot) in branch '3.10': bpo-44600: Refactor new tracing tests (GH-27396) (GH-27404) https://github.com/python/cpython/commit/5502ee052fb4257ad7438dd1130c80e1a9c4bc7f -- nosy:

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- pull_requests: +25937 pull_request: https://github.com/python/cpython/pull/27404 ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: New changeset 38ddc8beb38d9a685de296a58b0741850e4853e5 by Brandt Bucher in branch 'main': bpo-44600: Refactor new tracing tests (GH-27396) https://github.com/python/cpython/commit/38ddc8beb38d9a685de296a58b0741850e4853e5 --

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- pull_requests: +25930 pull_request: https://github.com/python/cpython/pull/27397 ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Brandt Bucher : -- pull_requests: +25929 pull_request: https://github.com/python/cpython/pull/27396 ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

miss-islington added the comment: New changeset 01601aa7360ae51e74a64dbe957288096bb364fd by Miss Islington (bot) in branch '3.10': [3.10] bpo-44600: Fix line numbers for pattern matching cleanup code (GH-27346) (GH-27356)

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Brandt Bucher : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +25897 pull_request: https://github.com/python/cpython/pull/27356 ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: New changeset 4214f470f0cb9b6fef9a90758756fbc00ba95b5a by Charles Burkland in branch 'main': bpo-44600: Fix line numbers for pattern matching cleanup code (GH-27346) https://github.com/python/cpython/commit/4214f470f0cb9b6fef9a90758756fbc00ba95b5a

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Charles Burkland : -- keywords: +patch nosy: +chaburkland nosy_count: 6.0 -> 7.0 pull_requests: +25887 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27346 ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Yup, I plan on having it in this weekend. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Pablo Galindo Salgado : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Pablo Galindo Salgado added the comment: The release candidate is soon, so I would recommend to land a fix as soon as possible so it can be tested for some time before is released, if that is possible. -- nosy: +pablogsal ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Two other things we realized while working on this: - The first occurrence of line 15 in the example output should be marked as incorrectly traced. - We should emit a NOP to show coverage of "case _" (that fix will be part of the same PR). --

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Yeah, this is actively being worked on. Thanks for asking. If anything changes, I’ll let you know and you can pick it up then! -- ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Jack DeVries added the comment: @brandtbucher, is anyone working on this yet? I'd like to take a crack at it this week if it's still available! -- nosy: +jack__d ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Thanks, that test framework looks good for this. My initial hunch (just from looking at this) is that this has to do with how we handle cleanup after failed matches. Our "fail pop" blocks probably have whatever the last line number compiled was (which I

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Ammar Askar added the comment: Brandt, maybe this regression test from a previous tracing bug might be useful for the test writing: https://github.com/python/cpython/pull/22026/files#diff-8b73bfc55514d8add8904c5f4d1d24b7b644ebfccba8d846085303577aa94dd6 -- nosy: +ammar2

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Thanks, I'll take a closer look at this soon (most likely this coming week). Out of curiosity, do we have a standard way of writing regression tests for correct line numbers like this? Of the top of my head, it seems like we could either statically compare

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Mark Shannon : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44600] match/case statements trace incorrectly in 3.10.0b4

New submission from Ned Batchelder : Some simple match/case statements show incorrect tracing. Below is the code to run, as well as the output. Output lines with initial stars are incorrect: they incorrectly indicate that case bodies are executing when they are not. Sorry for the bulk here

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Also (because some of the people who might be interested are nosied on this issue), I’ve been working a bit on general performance benchmarks for our pattern-matching implementation: https://github.com/brandtbucher/patmaperformance I still need something

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Sorry, I’ve been out on vacation this weekend. I didn’t realize that there was already a PR for this… I’m honestly not sure that it’s totally ready yet. While I absolutely agree that compiling efficient decision trees lies in our future, it certainly seems to

[issue44283] Add jump table for certain safe match-case statements

Mark Shannon added the comment: This is going in the wrong direction. Rather than add more complex instructions for use only by pattern matching, we need to simplify the individual operations and re-use existing instructions. That way pattern matching can benefit from the general performance

[issue44283] Add jump table for certain safe match-case statements

Raymond Hettinger added the comment: > How common match-case statements with literal integers? Nothing is common yet because the feature hasn't been released ;-) I suspect that if match-case were optimized for integer constants, they would be used. In discussions about case stateme

[issue44283] Add jump table for certain safe match-case statements

Serhiy Storchaka added the comment: How common match-case statements with literal integers? I expect that in most cases such magic numbers are not used directly, but as named constants. -- nosy: +serhiy.storchaka ___ Python tracker <ht

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Here are some benchmarks: PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf compare_to .\main.json .\PR-26697.json Running Release|x64 interpreter... 1: Mean +- std dev: [main] 117 us +- 4 us -> [PR-26697] 122 us +- 3 us: 1.04x slower

[issue44283] Add jump table for certain safe match-case statements

Change by Dennis Sweeney : -- keywords: +patch pull_requests: +25282 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26697 ___ Python tracker ___

[issue44283] Add jump table for certain safe match-case statements

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: > Are you sure you want to do this? No, not yet. But there has been some positive feedback here, and it seems like an interesting project to prototype. :) > This optimisation is not applicable if the matched values are given symbolic > names. You would be

[issue44283] Add jump table for certain safe match-case statements

Anders Munch added the comment: Are you sure you want to do this? This optimisation is not applicable if the matched values are given symbolic names. You would be encouraging people to write bad code with lots of literals, for speed. -- nosy: +AndersMunch

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Hi Brandt, I would welcome your collaboration/mentorship in whatever capacity makes sense. I sent an email to bra...@python.org from sweeney.dennis...@gmail.com. -- ___ Python tracker

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: I'm hoping we can get something close that for free by just waiting... the faster-cpython folks are working on a tagged-pointer implementation of integers as we speak. I've been looking for a new project, so I'd love to help work on this issue (if you're

[issue44283] Add jump table for certain safe match-case statements

Change by Kshitiz Arya : -- nosy: +Kshitiz17 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Very interesting -- that is shorter than I thought also! If we really wanted to optimize the tar out of this, we could probably find a way to re-use just the PyDictKeysObject to find the index into a C-array of integer jump targets and not have to worry

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: For anyone curious, I had some free time today and took a stab at creating a minimal _frozendict type (sharing as much implementation with dict as possible) to see how difficult it would be. It was actually much simpler than I thought... just a few dozen

[issue44283] Add jump table for certain safe match-case statements

Change by Ken Jin : -- nosy: +kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: FWIW PEP 603 includes a graph (Figure 2) of dict.get versus hamt.get performance as the mappings grow, and it seems the hamt is roughly 1.4x slower on inputs of sizes between 10 and 1000. -- ___ Python tracker

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: > If I understand your proposal, that would mean that calling a function with a > N-case constant-pattern match would require N hashes and N insertions into a > dict (including memory allocation), followed by O(1) lookup. Wouldn't that > eliminate any hope

[issue44283] Add jump table for certain safe match-case statements

then "case 1" wouldn't be *that* much more likely than "case 20", so a slowdown on case 1 wouldn't matter too much if the average gets better. I'm under the impression that match-case statements would frequently be used only once per function call. If I understand your proposa

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Hm. I’m not sure if the HAMT makes much sense. We don’t really care about efficient mutation or copies... constant-time lookups seem to be overwhelmingly the most valuable factor here. I personally think that creating some sort of hashable dict and teaching

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: At first I thought of matches with only the int/str/None cases and then I saw the easy generalization, but yeah, each contiguous block seems better. One solution to the code hashability/lookup speed apparent dilemma: writing the equivalent of this in C:

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Seems like a good idea as long as we're careful about the implementation. I've just jotted down a few notes here: - We should probably break the table upon encountering a guard. - We probably can't get away with storing a dictionary in the code object's

[issue44283] Add jump table for certain safe match-case statements

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44283] Add jump table for certain safe match-case statements

Raymond Hettinger added the comment: Big +1 from me. This would make use of match-case more compelling. -- nosy: +rhettinger ___ Python tracker ___

[issue44283] Add jump table for certain safe match-case statements

New submission from Dennis Sweeney : Anecdotally, a few people I've talked to have expected that match-case statements would improve performance in the same way that switch-cases sometimes do in C-like languages. While this is impossible in general without changing semantics (since

Re: Case Statements

o. Command line parsing is a case where switch >>>>>> statements are often used, e.g. in shell scripts. >>>>> >>>>> I've seen at least six different ways of simulating switches, so >>>>> those >>>>> people who want them, can have t

Re: Case Statements

On 16/03/2016 15:27, Antoon Pardon wrote: Op 16-03-16 om 15:02 schreef Mark Lawrence: On 16/03/2016 13:38, Antoon Pardon wrote: Op 16-03-16 om 12:07 schreef Mark Lawrence: Raise the item on the python-ideas mailing list for the umpteenth time then, and see how far you get. I don't care

Re: Case Statements

On 20/03/2016 08:01, Rustom Mody wrote: On Wednesday, March 16, 2016 at 5:51:21 PM UTC+5:30, Marko Rauhamaa wrote: BartC : On 16/03/2016 11:07, Mark Lawrence wrote: but I still very much doubt we'll be adding a switch statement -- it's a "sexy" language design issue I did *NOT* write the

Re: Case Statements

(~ "equal?"). >The "case" form makes use of the operator "eqv?" that is missing from >Python ("eqv?" compares numbers numerically but is otherwise the same >as "eq?"). > > > Marko I think it needs to be mentioned: Almo

Re: Case Statements

Op 16-03-16 om 18:24 schreef Mark Lawrence: > On 16/03/2016 15:27, Antoon Pardon wrote: >> Op 16-03-16 om 15:02 schreef Mark Lawrence: >>> On 16/03/2016 13:38, Antoon Pardon wrote: Op 16-03-16 om 12:07 schreef Mark Lawrence: > > Raise the item on the python-ideas mailing list for the

Re: Case Statements

On Thursday 17 March 2016 16:45, Gregory Ewing wrote: > Steven D'Aprano wrote: >> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: >> >>>orig = globals()[cls.__name__] >> >> I wouldn't want to rely on it working with decorator syntax either. Even >> if it does now, I'm not sure that's a

Re: Case Statements

On Thu, Mar 17, 2016 at 8:23 PM, Antoon Pardon wrote: > Op 17-03-16 om 03:02 schreef Chris Angelico: >> On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano >> wrote: >> >>> I wouldn't want to rely on it working with decorator syntax either. Even

Re: Case Statements

On Thu, 17 Mar 2016 12:15 am, l0r0m0a0...@gmail.com wrote: > What hath I wrought? Dr Ray Stantz: Fire and brimstone coming down from the skies! Rivers and seas boiling! Dr Egon Spengler: Forty years of darkness! Earthquakes, volcanoes... Winston Zeddemore: The dead rising from the grave! Dr

Re: Case Statements

What hath I wrought? -- https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

t;eq?") and "==" (~ "equal?"). The "case" form makes use of the operator "eqv?" that is missing from Python ("eqv?" compares numbers numerically but is otherwise the same as "eq?"). Yes, a few scripting languages can do interesti

Re: Case Statements

l0r0m0a0...@gmail.com: > Gratified to see that with all this back-and-forth this thread still > has a sense of humor. Perhaps, we can all just agree to disagree? :) I might agree with you if you tell me what we disagree about. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

On Wed, 16 Mar 2016 09:34 pm, BartC wrote: > (BTW why does Python have 'elif' when if-else is all that is really > needed?) To save indentation. if condition: block else: if other: block else: if third: block else: block versus:

Re: Case Statements

On 16/03/2016 19:41, BartC wrote: On 16/03/2016 09:51, Mark Lawrence wrote: On 16/03/2016 09:35, Antoon Pardon wrote: So I guess those who would like a case statement in Python can only hope a core developer gets bitten by a nasty bug while using one of those ways of simulating switches.

Re: Case Statements

On Thu, 17 Mar 2016 10:14 am, Chris Angelico wrote: > On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon > wrote: >> It can be yes. Look at decorators. They don't provide functionality >> we wouldn't have without them. > > Really? Okay, try implementing this without

Re: Case Statements

On Thu, Mar 17, 2016 at 11:19 AM, Steven D'Aprano wrote: > On Thu, 17 Mar 2016 10:14 am, Chris Angelico wrote: > >> On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon >> wrote: >>> It can be yes. Look at decorators. They don't provide functionality

Re: Case Statements

BartC : > On 16/03/2016 11:07, Mark Lawrence wrote: >> but I still very much doubt we'll be adding a switch statement -- >> it's a "sexy" language design issue > > That's the first time I've heard a language feature common in C > described as sexy. Scheme has a "switch"

Re: Case Statements

On 16/03/2016 21:43, Mark Lawrence wrote: On 16/03/2016 19:41, BartC wrote: That article appears to try to do without using a new switch byte-code, as the author doesn't see the point. My code to implement a 'switch' byte-code (for integer expression and constant integer case-expressions) is

Re: Case Statements

Gratified to see that with all this back-and-forth this thread still has a sense of humor. Perhaps, we can all just agree to disagree? :) -- https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

Chris Angelico wrote: So maybe it's a language guarantee that hasn't been written down somewhere, The Language Reference says: [the decorator] is invoked with the function object as the only argument. The returned value is bound to the function name instead of the function object. The

Re: Case Statements

Op 17-03-16 om 03:02 schreef Chris Angelico: > On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano wrote: > >> I wouldn't want to rely on it working with decorator syntax either. Even if >> it does now, I'm not sure that's a language guarantee. > That's the thing, though. It's

Re: Case Statements

On 16/03/2016 13:38, Antoon Pardon wrote: Op 16-03-16 om 12:07 schreef Mark Lawrence: Raise the item on the python-ideas mailing list for the umpteenth time then, and see how far you get. I don't care enough. I do care about people using valid arguments. Arguments have been made for and

Re: Case Statements

Op 16-03-16 om 15:02 schreef Mark Lawrence: > On 16/03/2016 13:38, Antoon Pardon wrote: >> Op 16-03-16 om 12:07 schreef Mark Lawrence: >>> >>> Raise the item on the python-ideas mailing list for the umpteenth time >>> then, and see how far you get. >> >> I don't care enough. I do care about people

Re: Case Statements

Steven D'Aprano wrote: On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: orig = globals()[cls.__name__] I wouldn't want to rely on it working with decorator syntax either. Even if it does now, I'm not sure that's a language guarantee. The following idiom relies on similar behaviour:

Re: Case Statements

On 16/03/2016 13:27, Steven D'Aprano wrote: On Thu, 17 Mar 2016 12:15 am, l0r0m0a0...@gmail.com wrote: What hath I wrought? Dr Ray Stantz: Fire and brimstone coming down from the skies! Rivers and seas boiling! Dr Egon Spengler: Forty years of darkness! Earthquakes, volcanoes... Winston

Re: Case Statements

Antoon Pardon : > Op 16-03-16 om 20:27 schreef Marko Rauhamaa: >> Antoon Pardon : >>> Look at decorators. They don't provide functionality we wouldn't have >>> without them. So we don't actually need them. Do you argue that >>>

Re: Case Statements

On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: > Yes... in theory. But try rewriting my example to avoid decorator > syntax. It won't work, because of this line: > > orig = globals()[cls.__name__] That's a nasty, dirty piece of code, and I hope you are thoroughly ashamed of having

Re: Case Statements

Op 17-03-16 om 01:31 schreef Chris Angelico: > On Thu, Mar 17, 2016 at 11:19 AM, Steven D'Aprano wrote: >> On Thu, 17 Mar 2016 10:14 am, Chris Angelico wrote: >> >>> On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon >>> wrote: It can be yes.

Re: Case Statements

On 16/03/2016 11:07, Mark Lawrence wrote: I don't want to discourage you too much, but I think that adding a switch statement comes *very* low on the list of improvements we would like to make in Python 3.5. We should probably focus on speed ... OK, you're coming round... but I still very

Re: Case Statements

On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon wrote: > It can be yes. Look at decorators. They don't provide functionality > we wouldn't have without them. Really? Okay, try implementing this without decorators: def monkeypatch(cls): orig =

Re: Case Statements

BartC : > On 16/03/2016 14:31, Marko Rauhamaa wrote: >> Scheme has this: > >> (case (die10) >> ((1 3 5 7 9) >>=> (lambda (n) >> n)) >> (else >>=> (lambda (n) >> (/ n 2 >> >> which maps 1, 3, 5, 7 and 9 onto themselves

Re: Case Statements

Op 16-03-16 om 20:27 schreef Marko Rauhamaa: > Antoon Pardon : > >> Look at decorators. They don't provide functionality we wouldn't have >> without them. So we don't actually need them. Do you argue that >> introducing them wasn't progress? > I do. Way to miss the

Re: Case Statements

On 16/03/2016 09:51, Mark Lawrence wrote: On 16/03/2016 09:35, Antoon Pardon wrote: So I guess those who would like a case statement in Python can only hope a core developer gets bitten by a nasty bug while using one of those ways of simulating switches. So that core developers can waste

Re: Case Statements

On Thu, 17 Mar 2016 05:48 pm, Chris Angelico wrote: > On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano > wrote: >> I don't think that property is a similar situation. I think what happens >> here is that the first call to property sets: >> >> # @property def

Re: Case Statements

On 16/03/2016 13:15, l0r0m0a0...@gmail.com wrote: What hath I wrought? The Comfy Chair :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano wrote: > On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: > >> Yes... in theory. But try rewriting my example to avoid decorator >> syntax. It won't work, because of this line: >> >> orig = globals()[cls.__name__] > >

Re: Case Statements

On Thu, Mar 17, 2016 at 4:45 PM, Gregory Ewing wrote: > Steven D'Aprano wrote: >> >> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: >> >>>orig = globals()[cls.__name__] >> >> >> I wouldn't want to rely on it working with decorator syntax either. Even >> if >>

Re: Case Statements

BartC <b...@freeuk.com>: > Yes, a few scripting languages can do interesting things with switch or > case statements. Perl for example (where I think it is created out other > language features, but it looks a regular part of the syntax). > > Even Ruby has one. It does

Re: Case Statements

On Thu, Mar 17, 2016 at 5:29 PM, Steven D'Aprano wrote: > I don't think that property is a similar situation. I think what happens > here is that the first call to property sets: > > # @property def x... > x = property(x) > > Then the second decorator does: >

Re: Case Statements

Antoon Pardon : > Look at decorators. They don't provide functionality we wouldn't have > without them. So we don't actually need them. Do you argue that > introducing them wasn't progress? I do. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: Case Statements

Op 17-03-16 om 09:57 schreef Marko Rauhamaa: > Antoon Pardon : > >> Op 16-03-16 om 20:27 schreef Marko Rauhamaa: >>> Antoon Pardon : Look at decorators. They don't provide functionality we wouldn't have without them. So we don't

Re: Case Statements

On 16/03/2016 14:31, Marko Rauhamaa wrote: BartC : Even Ruby has one. case when this when that That's a different topic. Yes but, if Ruby has it, why shouldn't Python? (Aren't they rivals or something?) which is exactly equivalent to if this...

Re: Case Statements

Op 17-03-16 om 00:14 schreef Chris Angelico: > def monkeypatch(cls): > orig = globals()[cls.__name__] > print("Monkeypatch",id(cls),"into",id(orig)) > for attr in dir(cls): > if not attr.startswith("_"): > setattr(orig,attr,getattr(cls,attr)) > return orig > >

Re: Case Statements

On Thu, Mar 17, 2016 at 9:53 PM, Steven D'Aprano wrote: > On Thu, 17 Mar 2016 05:48 pm, Chris Angelico wrote: > >> Okay. Let's try this. > [...] >> Decorators work. Now let's try NOT using decorators. > > You are still using a decorator. You're just not using @ decorator

Re: Case Statements

On 16/03/2016 11:16, BartC wrote: On 16/03/2016 11:07, Mark Lawrence wrote: I don't want to discourage you too much, but I think that adding a switch statement comes *very* low on the list of improvements we would like to make in Python 3.5. We should probably focus on speed ... OK, you're

Re: Case Statements

programmer. I have no interest what other languages use switch/case statements for, as we've on the PYTHON mailing list. There once were multiple ways to simulate a conditional expression. And it was generally thought that using if else statements instead of a conditional expression was unlikely

Re: Case Statements

e >>> people who want them, can have them. if-elif chains are not likely to >>> kill any Python programmer. >>> >>> I have no interest what other languages use switch/case statements >>> for, as we've on the PYTHON mailing list. >> >> There once were

Re: Case Statements

languages, but is generally considered more flexible and readable than the if-elif, was missing in Python. (your link "Switch Statement Code Smell" not withstanding) Have a great day :) Switch and case statements are such a waste of time that, in order to understand them you have t

Re: Case Statements

statements are often used, e.g. in shell scripts. I've seen at least six different ways of simulating switches, so those people who want them, can have them. if-elif chains are not likely to kill any Python programmer. I have no interest what other languages use switch/case statements for, as we've

Re: Case Statements

t; statements are often used, e.g. in shell scripts. > > I've seen at least six different ways of simulating switches, so those > people who want them, can have them. if-elif chains are not likely to > kill any Python programmer. > > I have no interest what other languages use s

Re: Case Statements

Christian Gollwitzer : > That happens indeed if one were to simulate polymorphism using switch > statements, but not for other cases. There are not many other cases. Decoding is the only generally valid case I can think of. > In Python, you need to go the other way round, you

Re: Case Statements

where switch statements are often used, e.g. in shell scripts. I've seen at least six different ways of simulating switches, so those people who want them, can have them. if-elif chains are not likely to kill any Python programmer. I have no interest what other languages use switch/case state

Re: Case Statements

Am 16.03.16 um 05:26 schrieb Mark Lawrence: So you would rather write something like:- switch (x): case COW: moo() break case DUCK: quack() break default IDUNNO: panic() than:- x.makeNoise() No sane person would do that. But just because you selected the

Re: Case Statements

On 16/03/2016 01:55, jj0gen0i...@gmail.com wrote: You have apparently mistaken me for someone who's worried. I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than

Re: Case Statements

onsidered more > flexible and readable than the if-elif, was missing in Python. (your link > "Switch Statement Code Smell" not withstanding) > > Have a great day :) Switch and case statements are such a waste of time that, in order to understand them you have to mentally use

  1   2   >