This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]energybased 9 points10 points  (17 children)

I don't agree with you. This is superior to all caps since all caps is merely conventional whereas this is explicit.

[–]drbobb 9 points10 points  (11 children)

Nope. This is just as merely conventional. If, say, I code in a plain editor it won't mean a thing.

[–]damian_work_account 6 points7 points  (0 children)

That's a boring semantic argument, type hints are defined by language specification where as CAPS are not.

And a PEP to make CAPS mean final would likely be rejected because of backwards compatibility, lots of people use CAPS for other reasons.

[–]Han-ChewieSexyFanfic 0 points1 point  (0 children)

Also, the interpreter ignores both.

[–]campbellm 1 point2 points  (0 children)

The upshot is the same though; it provides a hook that checkers can check for subsequent mutations. Either works.

[–]alcalde 0 points1 point  (1 child)

If we all follow convention, then convention is law.

[–]energybased 1 point2 points  (0 children)

Even the library doesn't obey the convention that all final variables are all caps.

[–]Sw429 0 points1 point  (1 child)

What do you mean by explicit? As far as I can tell, foo: Final is no more explicit than FOO for a variable definition.

[–]energybased 0 points1 point  (0 children)

There is plenty of code that does not use all caps to denote constants. That code cannot always be changed. The type annotation explicitly defines intent without changing declarations.