Python: Even a Feature That You Do Not Use Can Bite You • Hacker News Board

Re: Python: Even a Feature That You Do Not Use Can Bite You

#21

Post by cv1010 » Sat, Feb 23, 2019, 3:48 PM UTC

I wonder why most people defend this feature. The problem is not the annotation, you can do that in ML, too:

  Poly/ML 5.6 Release
  > 5 : int;
  val it = 5: int

But you cannot just use 42 where a type is expected:

  > 5 : 42;
  poly: : error:  expected but 42 was found
  Static Errors

It's pretty silly that Python did not develop an actual type system if annotations like that are supported.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#22

Post by zimablue » Sat, Feb 23, 2019, 3:52 PM UTC

cv1010 wrote: post #21

I wonder why most people defend this feature. The problem is not the annotation, you can do that in ML, too: Poly/ML 5.6 Release > 5 : int; val it = 5: int But you cannot just use 42 where a type is expected: > 5 : 42; poly: : error: expected but 42 was found Static Errors It's pretty silly that Python did not develop an actual type system if annotations like that are supported.

In the void of enforcing a speficic one, you allow people flexibility to do custom things.

For instance linters not understanding type specificatins beyond a certain complexity but still using them in your code and some custom decorator to check them at run/dev time

Re: Python: Even a Feature That You Do Not Use Can Bite You

#23

Post by zimablue » Sat, Feb 23, 2019, 3:53 PM UTC

Instead of the weirdly alarmist nature of the article, it would be a more fair point to make that colons are now very overloaded in python syntax.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#24

Post by masklinn » Sat, Feb 23, 2019, 3:57 PM UTC

benatkin wrote: post #11

masklinn wrote: post #3

I mean technically it's a feature you're using, just unintentionally. Kinda like setting a mutable object as a default argument. But I'll admit I got bit by exactly this recently, wrote up an "assignment" using a colon instead of an equal sign and it didn't do anything, but didn't fail either. Somewhat frustratingly, pycharm didn't warn about it either. I should probably check their bug tracker to see if somebody alr…

I don't think so, because 42 is not a type in Python (it could be one day, though - in TypeScript, 42 can be used as a type, basically an enum with only one value). I think (naively) that it should throw an error.

Annotations were specifically designed as general-purpose, not specifically type annotations. So the ability to put arbitrary expressions in annotations was very much intended.

In fact, the type hints of the typing module are not actually types.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#25

Post by masklinn » Sat, Feb 23, 2019, 4:00 PM UTC

goodside wrote: post #8

Understanding the basic syntax for assignment isn’t a high bar to clear. While it’s maybe not ideal to use colons for both the “assignment-like” separator between keys and values inside dictionaries and the annotation of types, introducing any new syntax features into a language that’s been around for decades is never without compromise. Colons are also used at the end of block statements and in index ranges and nobo…

The problem is not understanding, it's fat-fingering (especially when dict literals and dict comps use `:`).

> type annotations just delayed your runtime error by one line.

Or it introduces a subtle bug because this was intended as a reassignment or somesuch.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#26

Post by masklinn » Sat, Feb 23, 2019, 4:01 PM UTC

Pxtl wrote: post #19

painful wrote: post #15

This is an idiotic article because a static analyzer like mypy will find this in a hurry: > error: Invalid type: try using Literal[42] instead? If you don't use the analyzer, the problem is you.

The question, then, is why that kind of analysis isn't built into the compiler?

> Despite considerable discussion about a standard type parameterisation syntax, it was decided that this should also be left to third-party libraries. ([7], [8], [9]).

> Despite yet more discussion, it was decided not to standardize a mechanism for annotation interoperability. Standardizing interoperability conventions at this point would be premature. We would rather let these conventions develop organically, based on real-world usage and necessity, than try to force all users into some contrived scheme. ([14], [15], [16]).

Re: Python: Even a Feature That You Do Not Use Can Bite You

#27

Post by mjw1007 » Sat, Feb 23, 2019, 4:08 PM UTC

larkeith wrote: post #12

This is a weird article to me. There seems to be an implicit condemnation of Python for this new feature resulting in non-error, unexpected behavior under certain typoes, despite the fact that that is true for literally any typo that results in valid code in any language (such as, e.g., = instead of ==). I don't understand how it would be possible to add a new syntactic option without being "bit". Regarding type hint…

There were some people who thought that trying to bolt a type system on to Python was a bad idea.

A common response to them was "you don't have to use it; you can ignore it and you're no worse off than you were before". I think it's reasonable for him to point out that this isn't quite true.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#28

Post by daveFNbuck » Sat, Feb 23, 2019, 4:12 PM UTC

larkeith wrote: post #12

This is a weird article to me. There seems to be an implicit condemnation of Python for this new feature resulting in non-error, unexpected behavior under certain typoes, despite the fact that that is true for literally any typo that results in valid code in any language (such as, e.g., = instead of ==). I don't understand how it would be possible to add a new syntactic option without being "bit". Regarding type hint…

I read it as a more general cautionary tale rather than an attack on this particular feature or language. Be aware of new features, because even ones you don't know about and don't use can cause you problems. Or alternatively for language developers, be aware that new features can make the language harder to use even for people who don't use them.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#29

Post by daveFNbuck » Sat, Feb 23, 2019, 4:15 PM UTC

steven2012 wrote: post #18

This isn't a good article to post. It's just one person complaining about a change he didn't know about. It's really just a syntax change. I probably wouldn't have chosen that particular syntax using colons, or I would have forced another keyword like "set" in front of it, but it is what it is. He created a bug and he likely won't do it again, so problem solved.

I also didn't know about this change but now I do because this article was posted.

Re: Python: Even a Feature That You Do Not Use Can Bite You

#30

Post by benatkin » Sat, Feb 23, 2019, 4:16 PM UTC

masklinn wrote: post #24

benatkin wrote: post #11

Earlier quoted context omitted.

I don't think so, because 42 is not a type in Python (it could be one day, though - in TypeScript, 42 can be used as a type, basically an enum with only one value). I think (naively) that it should throw an error.

Annotations were specifically designed as general-purpose, not specifically type annotations. So the ability to put arbitrary expressions in annotations was very much intended. In fact, the type hints of the typing module are not actually types.

Ah, I see, good to know.

What I wanted when I found the PEP a few days ago were docstrings for instance variables, which isn't one of the things that this provides, so I stopped reading. I ended up using properties but it's a bit verbose.

It's great that typings are in a module so it can be extended or replaced!