[Python-Dev] Running 2.7 tests on OS X
I want to try to submit a patch for 2.7, but I don't know how to run the tests for the 2.7 branch. `./configure` doesn't seem to create a `python.exe` file on the 2.7 branch on OS X Mavericks, and I do need this file according to this guide: http://docs.python.org/devguide/ Anybody know how I should do this? ___ 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
[Python-Dev] Re: bz2.BZ2File doesn't support name?
I am new and I am just lurking here, so please pardon me if I say or do anything out of place. I saw your patch Mr. Diwan and I want to say that instead of making `filename` attribute, it would be better to change it to `name`, just to adhere to standards. And changing the name method to something else or even removing it. ___ 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/XEKHBJRPTE2DIV5HHHQRENYXJPBK3N7Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
I'm very new to this mailing list so I'm not sure it's my place to email, but
I'd like to weigh in and maybe it will be useful. If not you can always ignore
;)
I think adding the Walrus operator is trying to solve a problem that doesn't
exist. Compare the example from the PEP:
def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
To the one without:
def make_point_3d(pt):
match pt:
case (x := _, y := _):
return Point3d(x, y, 0)
case (x := _, y := _, z := _):
return Point3d(x, y, z)
case Point2d(x := _, y := _):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
It's a lot more typing, it's a lot more ugly, and I'd argue it's not any more
explicit than the earlier one. We still have all the same variables, except now
we have to follow them with a ritualistic ":= _" to capture them. Normally we
use the underscore to discard or hide something (at least that's how I've
always used it), and suddenly it is used when we want to keep the thing it
stands for?!
Also, I understand Python doesn't look like Haskell or Rust or whatever, but
you also have people coming from those languages to Python, and people going to
those languages from Python. Having a different syntax from what literally
everybody else does will lead to a lot of confusion. I think the default option
should be to have it like the current proposal (and everybody else), and update
it only if there is a good reason to do so. "We don't want to look like the
rest" should not be an argument. I think Python not looking like anything else
is a result of the readability and simplicity goals of Python, not because the
goal was to look different.
Finally, I asked an actual Python newbie (our trainee) about his opinion, and
he said he didn't think the walrus example was any more useful. Of course, N=1,
not an experiment, doesn't measure mistakes in practice, etc. But let's make
sure it's an actual problem before we go complicate the syntax.
Again, first time mailing here and I don't know if it's my place (can I even
mail into this list?), but I hope the perspective is of some use.
Rik
P.S. I never had issues with list comprehensions, because it's basically how
you write down sets in mathematics (which is what I studied).
"Joao S. O. Bueno" wrote:
“”
“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 match
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
Hi Rob, thank you! :) I think I understand the point, but I still don't agree with it. I find it hard to come up with a concrete use case where you would like to name a parameter without specifying it. Suppose we want case Status(user, n_messages, replies, unicode:=_) Then it might be a little useful for us to type the non-captured arguments explicitly because it's easier to remember the signature that way. Alternatively, if you want to capture an arg like this and you have more than a few positional arguments, you should probably just match on a keyword argument (or refactor your code so your API's are simpler). Also, what would we type if we wanted to capture a keyword argument? Something like this? case Status(user, n_messages, replies, unicode=unicode:=_) Surely that must be a horrible joke! (N.B. I suppose this is an argument against this specific syntax rather than capturing) Additional potentials I came up with are checking for the number of arguments (when it's a lot, so typing all the underscores becomes hard to count), like: match pt: case (a, b, c, d, e, f, g, h): manage_len_8(pt) case (a, b, c, d, e, f, g, h, i, j, k): manage_len_11(pt) But in that case why not use an if-else, like so. if len(pt)==8: manage_len_8(pt) elif len(pt)==11: manage_len_11(pt) There must be use cases I haven't thought of, but I think they will all fall prey to similar objections as the above two. I'm open to being proven wrong, though! The thing about explicitness is, sure, it is better than implicitness. But beautiful is also better than ugly, and simple better than complex, etc. etc. I think they mean nothing without specific use cases to know what it actually means for this thing in this context. I think case(x:=_, y:=_, z) is exactly as explicit as case(x, y, _) (it names x and y explicitly), with the added drawbacks of - Confusing the meaning of "_", which (at least in my mind) means "discard". - Deviating from other languages with pattern matching (which, presumably, also have bikeshedded on this point), increasing the surprise level for people who are either coming to Python from there, or going from Python to there. - Requiring extra (weird-looking) syntax for the default case of capturing variables. Again, maybe I'm just having trouble finding good use cases (either that, or I have no intuition for programming :P). Let me know if you have some! Rik P.S. If I'm out of line or violating etiquette with anything, please let me know. I'm open to help. ___ 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/N4H42GTG237PBG5B4N6ZF4DQAX4X3HEE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context. 2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had to explicitly capture every variable. I just want to write down what the thing looks like and have the interpreter figure out the correct bindings. Extra binding syntax will get in the way rather than be helpful. Python Dev wrote: “+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter. On 31.07.2020 13:42, Larry Hastings wrote: “ On 7/31/20 12:36 AM, Tobias Kohn wrote:“And since pattern matching is really a new feature to be introduced to Python, a feature that can be seen in different lights, there is no 'Python-Programmer intuition' that would apply in this case. ” It's not fair to say "intuition doesn't apply because it's new syntax". There are plenty of examples of intuition serving a Python programmer well when encountering new syntax. A Python programmer's intuition is informed by existing syntax and conventions in the language. When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed. Take for example list comprehensions. Python 1 programmers hadn't seen “a = [x for x in y] ” But they knew what square brackets meant in that context, it meant "creates a new list". And they knew what "for x in y" meant, that meant iteration. Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately. The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics. For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different. Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key. Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time. Cheers, /arry ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan”” [attachment.txt] ___ 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/4L7LXGVYTMHPF5I54Z2DVSIKSL75ES6H/ Code of Conduct: http://python.org/psf/codeofconduct/
