Really excited for the new syntax, thank you everyone involved for making Python better each day. IMO Python's most powerful feature is its' amazing community. :)
Depends no? If your "100%" is based on the after value rather than the before value, you have added 100%. Though I guess there is an implicit expectation that it is the before value that is used.
I've really taken to writing a lot of Hy [0] -- somewhat irresponsibly, since Hy is maintained by a ragtag band of brilliant mavericks; but `hy2py` works great if you `eval-when-compile` most of your macros. Anyway, Hy syntax is
```
(with [f open(file 'r)] (do stuff))
```
rather than
```
with open(file,'r') as f:
```
I switch [1] to Python (often to write tests in a language the node.js crew will be able to skim) and the one thing that trips me always is the wrong ordering of the `with` statement in straight Python. You don't say `for range(10) as x`...
I hope the Hy crew do the sensible thing about case statements. I don't even know what the sensible thing is, though.
[0] http://hylang.org
[1] Yes, you can import Hy code from Python and vice-versa!
That doesn't resolve (at least not obviously to me) the ambiguity where you want to match a Point where the first value is equal to the existing variable x, while the second value is anything and you want to capture it in a new variable y.
I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this:
case Point(x, y?):
For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module:
Fortunately we have tools like Docker and to a lesser extent Python Virtual Environments to help deal with this in a sane way.
But yeah for 1 off zero dependency Python scripts I won't be using the new features until major distros ship with 3.10 by default. Part of the appeal to me of Python is most distros and operating systems have it installed by default. Being able to curl down a single file and run it is really nice. For that to work requires using a version of Python that most folks have by default. That means coding against 3.6's features (at least we can use f-strings now!).
Ugh. I hate this rapid release cycle with introduction of new syntax. One of my colleagues keeps insisting on using the latest and greatest version all the time so everything he writes keeps breaking everyone's environments since they're not savvy to upgrade python, install packages and point the IDE to the new python installation.
It's a total 180 from when he pushed python 2 when it only had a few years until it's EOL.
Like f-strings look nice and all but there's nothing wrong with the format method and there's always the locals hack to achieve the same thing.
Maybe I've been working with Python for too long but I don't see the value in Python's pattern matching. if/elif/else are all four letters just like case and I remember reading that Guido didn't want a match and case construct.
Maybe I am just grumpy but I feel like Python the simple language that drew in a lot of developer is going the C++ way of adding features for the sake of adding features.
Have a look at the the tutorial pep and you'll realize like I did, that pattern matching and case switches solve very different use cases, and that if-else are a long shot from pattern matching.
This is nice and all, but part of me feels like having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern).
>having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern).
This is a near content-less critique, which amounts to:
"shaping code around what's returned by functions looks like a design pattern (and implied: design patterns are bad)"
Well, design patterns are neither bad, nor good. They are what they are: a high level description of common solutions to common problems.
By themselves design patterns are not problems or problematic.
It's applying them where they don't fit the problem - or where something simpler will suffice - that's problematic (common e.g. to J2EE era Java).
Some also say that design problems point to a language deficiency (that is, make up for a lack of language feature, like e.g. closures or dynamic typing).
If we accept the above folk wisdom, built-in pattern matching would be the exact opposite of what you say.
It wouldn't be a "design pattern smell" but rather a first-class feature that frees you from having to workaround its lack with design patterns.
But I'd go further and say that the complain is nonsensical anyway.
What exactly does "having code structured around the shape of tuples returned by function" even mean?
If there's a need to extract values from the results of a function (e.g. in a parser, a protocol handler, etc.) then we don't have alternatives, we will structure our code "around the shapes returned".
The question if whether we will do it through ad-hoc solutions (like chained "if" statements, a series of switch/case, etc.), through some convoluted design pattern like a Visitor, or by first class support for exactly our need. This first class support is exactly what pattern matching syntax offers.
And far from being some smell/Python novelty, it's an old staple found in Haskell, ML, Ocaml, Lisp, and several other places besides...
Exciting! Especially I like the named attribute matching [1] and dict matching [2]. Scala does not have that. If you have a case (data) class with 13 parameters, you need to match on all of them, instead of doing `MyClass(param=value)`. Similarly you can not easily pattern match on `Map` (`dict`).
One thing which I am missing though is matching on f-strings. Such a powerful feature in Scala.
I don’t understand what you are saying? In scala you do not have to match on all parameters. You can use the underscore operator to skip the other attributes.
Also you can match a map since every map is just a sequence of Tuples in scala. However why would you ever do this? It is really impractical for large sequences and if I have only a very limited number of attributes I would not use a map I guess.
Anyone have a clever solution for optionally using new python features while still supporting lower python 3 versions? For packaging purposes. Could put try except blocks everywhere or selectively import 3.10 modules vs <=3.9 modules, for example.
I find that new features aren’t necessary for their functionality, but they often can make code more terse, so having “duplicate” code with the same functionality but without new terseness kind of defeats the purpose. I suppose having two versions of the same module lets you end support for an old version pretty simply, but is that useful?
I think there are packages that detect the python version and do some crazy stuff in setup.py. But I think the most responsible thing for a widely used library to do is hold back on using new python features until they are a few years old.
[+] [-] kamyarg|5 years ago|reply
> Union[int, float] -> int | float
Really excited for the new syntax, thank you everyone involved for making Python better each day. IMO Python's most powerful feature is its' amazing community. :)
btw there is a small typo @ https://docs.python.org/3.10/whatsnew/3.10.html:
> Pattterns -> Patterns
Does anyone know where it needs to be fixed?
[+] [-] ktpsns|5 years ago|reply
[+] [-] vgwilliams|5 years ago|reply
[deleted]
[+] [-] Uzomidy|5 years ago|reply
[+] [-] SuchAnonMuchWow|5 years ago|reply
(a, b, c, d) = range(4)
[+] [-] DemocracyFTW|5 years ago|reply
It was twice as cold on Monday than it was on Sunday. /duck
[+] [-] collyw|5 years ago|reply
[+] [-] tpoacher|5 years ago|reply
[+] [-] ghego1|5 years ago|reply
[+] [-] xyzal|5 years ago|reply
[+] [-] Already__Taken|5 years ago|reply
[+] [-] guram11|5 years ago|reply
[+] [-] prionassembly|5 years ago|reply
``` (with [f open(file 'r)] (do stuff))
```
rather than
``` with open(file,'r') as f:
```
I switch [1] to Python (often to write tests in a language the node.js crew will be able to skim) and the one thing that trips me always is the wrong ordering of the `with` statement in straight Python. You don't say `for range(10) as x`...
I hope the Hy crew do the sensible thing about case statements. I don't even know what the sensible thing is, though.
[0] http://hylang.org [1] Yes, you can import Hy code from Python and vice-versa!
[+] [-] quietbritishjim|5 years ago|reply
I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this:
For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module:[+] [-] bluefox|5 years ago|reply
[+] [-] nickjj|5 years ago|reply
But yeah for 1 off zero dependency Python scripts I won't be using the new features until major distros ship with 3.10 by default. Part of the appeal to me of Python is most distros and operating systems have it installed by default. Being able to curl down a single file and run it is really nice. For that to work requires using a version of Python that most folks have by default. That means coding against 3.6's features (at least we can use f-strings now!).
[+] [-] GloriousKoji|5 years ago|reply
It's a total 180 from when he pushed python 2 when it only had a few years until it's EOL.
Like f-strings look nice and all but there's nothing wrong with the format method and there's always the locals hack to achieve the same thing.
[+] [-] smitty1e|5 years ago|reply
[+] [-] singularity2001|5 years ago|reply
ideally even with file extensions: .py3 runs on all python3 versions .py38 runs on all python3.9 versions and above
[+] [-] belval|5 years ago|reply
Maybe I am just grumpy but I feel like Python the simple language that drew in a lot of developer is going the C++ way of adding features for the sake of adding features.
[+] [-] wodenokoto|5 years ago|reply
https://www.python.org/dev/peps/pep-0636/
> and I remember reading that Guido didn't want a match and case construct.
look at who the sponsor of that pep is.
[+] [-] tus89|5 years ago|reply
[+] [-] coldtea|5 years ago|reply
This is a near content-less critique, which amounts to:
"shaping code around what's returned by functions looks like a design pattern (and implied: design patterns are bad)"
Well, design patterns are neither bad, nor good. They are what they are: a high level description of common solutions to common problems.
By themselves design patterns are not problems or problematic.
It's applying them where they don't fit the problem - or where something simpler will suffice - that's problematic (common e.g. to J2EE era Java).
Some also say that design problems point to a language deficiency (that is, make up for a lack of language feature, like e.g. closures or dynamic typing).
If we accept the above folk wisdom, built-in pattern matching would be the exact opposite of what you say.
It wouldn't be a "design pattern smell" but rather a first-class feature that frees you from having to workaround its lack with design patterns.
But I'd go further and say that the complain is nonsensical anyway.
What exactly does "having code structured around the shape of tuples returned by function" even mean?
If there's a need to extract values from the results of a function (e.g. in a parser, a protocol handler, etc.) then we don't have alternatives, we will structure our code "around the shapes returned".
The question if whether we will do it through ad-hoc solutions (like chained "if" statements, a series of switch/case, etc.), through some convoluted design pattern like a Visitor, or by first class support for exactly our need. This first class support is exactly what pattern matching syntax offers.
And far from being some smell/Python novelty, it's an old staple found in Haskell, ML, Ocaml, Lisp, and several other places besides...
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] _ZeD_|5 years ago|reply
[+] [-] mrkeen|5 years ago|reply
[+] [-] KptMarchewa|5 years ago|reply
[+] [-] vletal|5 years ago|reply
One thing which I am missing though is matching on f-strings. Such a powerful feature in Scala.
[1] https://www.python.org/dev/peps/pep-0636/#adding-a-ui-matchi...
[2] https://www.python.org/dev/peps/pep-0636/#going-to-the-cloud...
[+] [-] 0x008|5 years ago|reply
Also you can match a map since every map is just a sequence of Tuples in scala. However why would you ever do this? It is really impractical for large sequences and if I have only a very limited number of attributes I would not use a map I guess.
[+] [-] dividedbyzero|5 years ago|reply
[+] [-] ksm1717|5 years ago|reply
I find that new features aren’t necessary for their functionality, but they often can make code more terse, so having “duplicate” code with the same functionality but without new terseness kind of defeats the purpose. I suppose having two versions of the same module lets you end support for an old version pretty simply, but is that useful?
[+] [-] aflag|5 years ago|reply
[+] [-] a-dub|5 years ago|reply
[+] [-] bjoli|5 years ago|reply
I tried to use Hy, but even with the most glaring difference mitigated, python felt nothing like lisp. I was still writing very much python.
[+] [-] wk_end|5 years ago|reply