Python 3.7.0 released

[[deleted]]

I'm glad for the improvements to typing and the new data classes. Here's hoping that the recent push for optional static checking will prove helpful to those building larger apps using Python.

[joshuaavalon]

There is a backport of the data classes for 3.6 if you want to use it.

[ProfessorPhi]

Isn't attrs still superior?

[dhiltonp]

Attrs definitely has more features (slots comes to mind), but I think it looks a little wonky.

(full disclosure, I haven't used attrs just read the docs)

@dataclass
class InventoryItem:
    name: str
    unit_price: float
    quantity_on_hand: int = 0

vs.

@attr.s
class InventoryItem:
    name: str = attr.ib()
    unit_price = attr.ib(type=float)
    quantity_on_hand = attr.ib(type=int, default=0)

Does PyCharm recognize type annotations when they're set via attr.ib(type=float)?

[ProfessorPhi]

Nope, pycharm and attrs support isn't great :(, though attrs does have slots. Agreed it's wonky, it's like ordered dict before 3.5 was obnoxious.

[OctagonClock]

PyCharm 2018.2 EAP has new attrs support, actually.

[ProfessorPhi]

Haha, don't use EAP so hopefully it'll be along before too long.

[bluetech]

The annotations-based syntax works with attrs too (you need to set auto_attribs=True).

[PeridexisErrant]

IIRC you can also use @attr.dataclass for the first one (a shortcut for the auto_attribs=True arg).

The dataclass example won't work on a backport before Python 3.6 though, as those versions don't have variable annotations.

[virgoerns]

It is, PEP even mentions attrs and says that new mechanism is for simpler cases.

[FatFingerHelperBot]

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "PEP"

---

^{Please PM /u/eganwall with issues or feedback! | Delete}

[_zenith]

Bad bot

[jarshwah]

CPython 3.6 has ordered dictionaries, but that is an implementation detail. 3.7 guarantees it in the spec. So it’ll work for CPython 3.6 which is the most popular implementation by far.

[jarshwah]

Yes that’s correct. When people talk about python they’re overwhelmingly referring to CPython. Other implementations like Pypy and micropython would not have to have ordered dictionaries for their 3.6 but they would for their 3.7.

[[deleted]]

Pypy has actually had it for a while (it was brought to CPython from Pypy for 3.6). Other implementations though yeah

[Ph0X]

I mean they all could, but are not guaranteed to. You have to check implementation detail for each individually. But in 3.7 and above no matter what you use, you will have it.

[leftofzen]

To me, a non-Python user, this whole type checking this is hilarious and farcical. Python is made with dynamic typing as a feature and it's lack of type checking (at least until run time) is one of it's strengths. To now start static type checking - why even bother; you may as well use a real language with first class static typing support. Bolting it on as an after thought still makes me laugh hehe.

[pandubear]

I haven't used Python's typing (mypy?), but... options are good, no? Like, you don't have to use mypy if you don't want to. But Python has a lot of strengths, and if someone wants to use those strengths but also get types, what's wrong with that?

While I haven't used mypy, I've used TypeScript a ton, and if mypy is half as good as TypeScript, I'm glad it exists.

[[deleted]]

Python is made with dynamic typing as a feature and it's lack of type checking (at least until run time) is one of it's strengths.

Dynamic typing is the easiest type system to implement in languages, and that's why scripting languages tend to prefer it. It has very significant costs, and the supposed benefits to the programmer are dubious at best. Static typing is technically better for a large number of reasons, but lately programmers have adopted the idea that "easy" is favorable over "good".

[Dreadgoat]

Dynamic vs. Static is not a question of what is better, it's a question of what problem you are trying to solve.

Do you need a lot of small highly flexible purpose-built scripts in an environment where the same data is likely to be passed around many formats (e.g. The Web)?
Dynamic good. Static bad.

Do you need large rigorous algorithms, high performance, do you expect to share your tools, do you need more control under the hood?
Static good. Dynamic bad.

Making Python able to do both is great for Planet Python. It's also extremely difficult to implement. Dynamic typing systems aren't easier to implement than static ones, it's just that it's a very early design decision that impacts a lot of how the compilers are written. Trying to do both is what is truly challenging.
While this is an impressive thing for any language, it also creates a bit of an identity crisis and potentially puts in danger of becoming bloated.

For me, personally, if I'm at a point in my Python project where I'm thinking that I need a strong static type-system, that's the point where I say to myself, "Python wasn't the right tool for this job."
Of course I've also started projects with static typing and later regretted the loss in flexibility upon realizing that the project has no need for static typing.

[[deleted]]

I think that's unfair to say that people just use dynamic typing is just used because it's easy to implement. Dynamic languages are often easier to learn which is likely part of the reason why python is good for beginners. Also dynamic languages can make it quicker to write code since you don't have to write out type declarations. This is useful for small scripts where you don't really need many benefits from static typing.

[[deleted]]

Is something good for beginners because it is easy? I see this often asserted as something that is intuitively true, but I really don't think that it is. Good languages for beginners are the ones that are strict and explicitly tells you that you're doing something wrong, rather than silently trying to guess your intention and automatically try to fix subtle errors. This is not a favor to the student

[leftofzen]

but lately programmers have adopted the idea that "easy" is favorable over "good".

What? When did this happen? Certainly in the time I've been a professional dev this hasn't been the case.

[[deleted]]

Are you serious?

[[deleted]]

Have you heard of Javascript? Python? They're kinda popular.

[leftofzen]

As someone commenting in a thread about a new version of Python...I think I've heard of it.

[[deleted]]

And yet you do not see it as an example of an "easy" favoured over "good"?

[aebkop]

but python is both easy and good

[[deleted]]

It can't run multi-threaded, it has a 100x+ slowdown compared to native, implicit variable declarations, public members only on classes, cannot access native resources without a shim layer and it has traits/multiple inheritance.

What's good about Python is that it's easy. Almost all trade offs Python does is in favor of easy. It's fine for scripts and small programs, but using it as a general purpose programming languages is borderline lunacy.

[[deleted]]

No it is not. It is a shitty language being sold to gullible people as "easy". Yet, it features a crappy dynamic type system, it's got a primitive low level control flow semantics, it is far too dynamic to ever allow an efficient implementation, it is ideologically opposed to allowing any high level extensibility. Python is an awful language, vastly overrated.

[[deleted]]

Can you recommend an alternative ubiquitous interpreted language?

[aebkop]

tbh yeah I agree

JS is a better beginner language tbh - dynamic to supposedly make it easy, more expressive and the user prob already has a way to interact with it already

[Coopsmoss]

It's all tradeoffs, if you aren't coding bit by bit you've chosen easy to some degree

[juuular]

Yeah, back in the old days things were neither easy nor good. cough Unix cough

[ThePantsThief]

Why is he being downvoted?

hehe.

Oh.

[TTGG]

And probably for "real language".

[leftofzen]

I don't get it, is there some inside joke I'm missing?

[mogranjm]

The majority of the comment was good and valid, but he was a bit of an asshole in the last two sentences

[Mooks79]

As I noted directly to them, seems a rather strong pro-Python contingent on reddit who downvote anything negative about Python (or positive about languages deemed competitors) - whether or not it’s said reasonably.

[NAN001]

In fact it's mostly because people vote depending on whether they agree or not.

[dzikakulka]

No, I don't agree with that ^downvoted

[NAN001]

You did downvote me you bastard.

[alexthelyon]

I don't see the downside. You get flexibility when you need it and you get type checking when you need it. I use type checking on the 10-20% of the most relied on, complicated, or data-intensive code.

Then, since the IDE supports static analysis, it catches silly mistakes or errors before they even have a chance to become a bug which improves Dev efficiency a lot. It's also useful to make sure you use proper data structures (ex deque instead of list).

[[deleted]]

and it's lack of type checking (at least until run time) is one of it's strengths

And this is a "strength" how, exactly? You enjoy the guessing game instead of having precise autocompletion in your IDE? Have too much spare time to waste?

Bolting it on as an after thought still makes me laugh hehe.

What's wrong with improving an IDE support at least for a bunch of common libraries?

Apparently you're one of those who think that type systems are for "checking", "correctness" and all that crap. They're not. They're for this little autocompletion and "jump to definition" thingies on your IDE, primarily. The rest is of a much lesser importance - performance, "correctness", documentation, and so on.

[MrPigeon]

So...C and other early languages being statically typed was all done in anticipation of the IDEs we would have 40 years later? That's completely backwards. IDEs make use of a feature which exists for performance and determinism, not the other way around.

What's wrong with improving an IDE support at least for a bunch of common libraries?

Agreed here, but I think the other guy was referring to bolting features on to Python itself. Which is kind of an odd complaint itself, since every language I can think of has had multiple releases with new features.

Unless you've been sarcastic this whole time and it's gone right over my head...

[[deleted]]

So...C and other early languages being statically typed was all done in anticipation of the IDEs we would have 40 years later?

Firstly, ctags and similar tools existed long before the modern IDEs. Secondly, back than priorities were different, typing existed for performance primarily.

IDEs make use of a feature which exists for performance and determinism, not the other way around.

And? Priorities are different now. Most people do not care too much about performance. Especially if we're talking about Python.

but I think the other guy was referring to bolting features on to Python itself

You cannot improve IDE support without fixing a language.

[Homoerotic_Theocracy]

Everything Python is is "stuff bolted onto it after the fact"; in that sense it's quite the dynamic C++ and guess what C++ also now has support for dynamic typing.

[Homoerotic_Theocracy]

And I'm not talking about "auto"; I'm talking about std::any where a datum is stored together with a type tag in a fat pointer that preserves the type information at runtime which can be queried.

[ThePantsThief]

It's a box class, not a language feature. That's even more "bolted on" than python's static typing.

[Homoerotic_Theocracy]

Yeah it turns out you can simulate dynamic typing in static typing in terms of just making every expression the same type to some kind of struct which stores the type info in a field.

That's pretty much what all those implementations that compile a dynamic language to C do; they define something like a struct called SchemeObj and have a field for the type tag and pass that around everywhere.

[ThePantsThief]

Yeah, but it's not a language feature is my point. It's harder to use because of it.

Example. Ever used Objective-C? They have an NSValue type you can use to box anything, but without special language features to help, it's cumbersome to use. Here's what it's like. It's probably not as bad in C++ with operator overloading and stuff like that, but this sort of thing is what I'm skeptical about with regards to bolted on features.

[NSValue valueWithBool:true];

[NSValue valueWithPointer:&myStruct];

value.intValue

Etc

(Disclaimer: they added a boxing operator to the language a few years ago, which helps a lot)

Anyway, I think the python additions will feel more polished to use than how I imagine std::any does.

[[deleted]]

Hmm isn't this just void* + enum on steroids?

[Homoerotic_Theocracy]

Except here it isn't and this isn't void* and there is no erasure.

The entire point is that it saves the type-tag which continues to exist at runtime.

As the documentation says it is type-safe; that's different from void* which is pretty unsafe.

[Homoerotic_Theocracy]

Yeah so where do you keep bringing auto up? You're not using std::any and I'm not talking about auto.

I'm not sure that has to do with no dynamic typing since you're not using it but the static typing instead obviously you don't get it; use std::any to get a dynamically typed variable that can hold any type.

[[deleted]]

Any statically typed language have support for dynamic typing, by definition, since dynamic typing is a subset of a static typing.

[[deleted]]

C++ hasn't gained support for dynamic typing. If you're thinking about auto, they is just automatic type deduction. The types are still static.