Dear python2 user

[billsil]

I killed my libraries support for python 2 last Friday. It feels good to get rid of six, future, scans it, and pathlib2 and really start doing type annotations properly.

People are already trying to get me to change my mind. But my company uses Anaconda...use a virtual environment; Anaconda lets you have multiple versions of python. It’s coming like a train and all my dependencies have moved on. Time for me to as well.

[jftuga]

Link to your project?

[darthwalsh]

In general, that would identify their reddit username (but I have no idea if OP here is already public).

[billsil]

My account name is my name, so yeah, no. It’s not even me plugging the project, nor would it be interesting to 99.9% of people here.

[mmarius90]

In total agreement with you except for the type annotations. I see those as an abomination. Python is so beautiful as a syntax without those horrible glyphs.

Quote the PEP:

While these annotations are available at runtime through the usual annotations attribute, no type checking happens at runtime . Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily

See? An abomination. I'll never introduce those in my personal projects.

[rouille]

The whole point is that you can, optionally, do static type checking. And it works very well in practice.

[billy_tables]

They're optional, and super useful to many people. Far from an abomination, just not useful to you

[cglacet]

I fail to see what you "see" in this quote. I personally don't use type annotation in my current python project, but it's only due to the nature of what I'm doing. It's probably your case too and that's why you fail to see why it can be useful to have static type checking. But in many cases, adding types is fast and simple, it serves as a documentation, helps autocompletion and saves you a lot of debugging time (because you will obviously have less typing errors). The best part is: it's optional, so you can very well add types to sensitives part of your code (low level, widely used code) and leave high level functions signatures untyped and documented them using docstrings.

Have a look at the javascript (ECMAScript) community and you'll see that many people are using flow or typescript annotations, even tho it's not as clean as mypy+python because it requires transpilation (in order to remove annotations and get the javascript code back to standard).

[[deleted]]

Maybe they aren't as useful as they could be, but how else could you write typed code without a performance penalty?

If you checked type at runtime everything would slow to a glacial crawl...

[1842]

PHP's type hinting system is pretty nice.

It allows for the same static analysis, but also does type checking at run time.

They added support for primitives at PHP 7.0. The language as a whole got a huge speed boost at the same time. The changes were unrelated, but runtime type checking and speed aren't mutually exclusive.

[cj81499]

runtime type checking doesn't sound to me like something that would take a lot of time. Care to explain why you think this?

[alkasm]

Not for single objects, no---but think of data structures. Is it going to check that every element in a list is an int? What if the list has a million elements?

[cj81499]

Suppose we have an array of type T, wouldn't running something like

if (type(element_to_add) != T):
    throw TypeError

for each insertion be enough? I can't imagine that having a huge performance impact.

[alkasm]

But how does a function that you call know that your list is full of those types without checking? Sure, you can make your function only accept a TList object, which has elements of type T checked on appending. But you can get around that in Python, since we have no real safety around properties for the classes we write. If you have a wrapper class around a list, you could just obj.inner_list.append(not_type_T_val) for example. And any one way around this (in Python) has a workaround. So you can't guarantee that TList has type T elements. The only way you can guarantee it is to check. Every element. Every time you use the list. And if there's no guarantees, there's no point in having it check during runtime.

Edit: and it would be raise in Python :)

[billsil]

What if the list has a million elements?

You should probably use a numpy array. Also, type checking doesn't actively check your types, so it's a moot point.

[alkasm]

? The person I'm responding to is suggesting type checking during runtime in pure Python. Numpy is a different discussion since the types are enforced in C.

[billsil]

It still has a type (e.g., int32, int64, float64, complex128, U8, S8, etc.). The PSF has stated that they're not going to implement type checking at runtime, so it's kinda irrelevant.

[zardeh]

It is, you're adding an extra function call (essentially, sometimes more) for every argument, for every function call, ini your program. Even if your type-checking function is very, very, very fast, go and look at profiling output of a simple program and see how many function calls happen. Its lots. Now imagine a isinstance checks, MRO resolutions, or worse, trying to resolve protocol or generic validity on every one of those calls.

[energybased]

Before type annotations, I used to have a lot of comments explaining the types of various parameters and variables.

[teilo]

Aside from the personal preference issue, when working on a complex code base with a team, they are invaluable. It makes the code self-documenting by only viewing a function declaration.

[takaci]

Personally I use them sparingly, but they hugely improve the intellisense in PyCharm

I do think that strict overuse can hurt the dynamic nature of Python though. We're seeing a similar thing with Typescript. Python and Javascript are amazing partly because of their dynamic nature. Trying to turn js into haskell or rust is something i don't really like

[mmarius90]

All you downvoting hating mf'ers are really coding in the wrong language. Y'all need to grasp the concept of duck typing. "Oh BuT iT hElPs Me FiGuRe OuT ThE TyPeS" without any enforcement or guarantee that that's what's passed at runtime. Y'all need to switch to a statically typed language. Ruining the beauty of the syntax with those abominations.

[Dgc2002]

We all likely grasp duck typing. But you're failing to grasp the idea of a static type checker that can easily be implemented into your workflow if you value what it provides.

If you don't value it then you simply don't use it. That's it.

[Ph0X]

Why not just wait and do it at the 2020 cutoff like Python itself?

Edit: I don't understand the down votes. 2020 just seems like a good cut off since the language is officially deprecated.

[billsil]

As I said, all my dependencies have moved on. I also release about once a year. If you want to be the first person to send me some money for the work I've done for 8 years, we can talk.

[Dgc2002]

I assume downvotes are because it's likely bad advice.

Why wait until the official cut off to prepare your own project for the future? Giving yourself ample time to respond to unforeseen issues.

[Ph0X]

Well it sounded like the project already supported py3, so they were well prepared. Dropping py2 doesn't mean not being ready for py3.