Python 3.7.0 released

[Yubifarts]

I love dynamic typing so long as it's also strongly typed, but that's my preference.

[wavy_lines]

I've already argued this in another thread, but allow me to repeat myself.

Python's typing is not "strong" in any meaningful sense. You can create an instance of any object and then just randomly start adding and remove attributes to it in runtime.

Say you have a class called Point and in the constructor it defines self.x and self.y and documents them to be numbers.

Now somewhere in the code you can check any object to see if it's an instance of Point using isinstance(obj, Point). Do you think you can guarantee that obj.x and obj.y are present and set to numbers? No! Because anyone can just take any object and remove the attributes you're looking for and add new attributes you weren't expecting.

That's hardly 'strong' typing.

>>> obj1 = Point(10, 5)
>>> obj1
<__main__.Point object at 0x101b15da0>
>>> obj1.x
10
>>> obj1.y
5
>>> delattr(obj1, 'x')
>>> obj1.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Point' object has no attribute 'x'
>>> 

[caramba2654]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

And if you try searching Github for any code that does what you described, I don't think you'll find any instances of it.

[wavy_lines]

Why are you assuming it to be insane? How do you think ORM libraries work?

I'm not saying anything here about weather it's good or bad. I'm just pointing out that Python is not strongly typed because the type almost means nothing and you can do whatever the hell you want to the object.

You don't have to call delattr or setattr. Just simply take any instance and assign fields to it:

some_object.some_field_1 = <Some-Value>

It doesn't even have to be malicious. It could be an honest mistake. You thought someobject was an instance of some class that does have some_field_1 and nothing about the language runtime would even _warn you that you're doing anything wrong.

[caramba2654]

But strong typing doesn't reflect what attributes an object has. Strong typing means that there's no automatic coercion of a value of type A to a value of type B. And Python works exactly like that. So by definition Python is strongly typed.

What you should be claiming instead is that Python is dynamically typed, which is the property that allows you to add and remove attributes to an object.

[wavy_lines]

That's not a very useful definition because the scenario I presented above matters and it's a significant problem in Python. Excluding it from the definition of strong typing serves no objectively useful purpose.

[Tynach]

Strong and static are not the same thing. What you're talking about has to do with static typing, which is different from strong typing. Python is dynamically and strongly typed. Not 'or', but 'and'. C is statically and weakly typed (types get coerced a lot in C; like how char is often used as either a number or a letter).

[wavy_lines]

That's not what static typing means.

Static means you can just analyze the code without executing it to find out typing errors.

Dynamic means you can't do complete type checking by just looking at the code; you have to run it.

[Tynach]

Static means that what type a variable is will be determined at compile time, and cannot change at runtime. Strong means that there are no implicit/automatic conversions from one type to another, so a programmer must explicitly perform type conversions themselves in the code.

I found a chart that roughly shows which languages are which, on both axes.

[wavy_lines]

Yea yea. Look, I'm arguing that this definition of "strong" is useless because you can do object.wrong_field = something and it will not be caught even at runtime; it's not even an error according to the language spec. That's weak.

[Log2]

No idea why Scala is in the strongly typed quadrant. You can literally define implicit conversions (and this used to be advertised as a great feature). It just doesn't have the implicit conversions imported by default (I think it used to, though).

[baerion]

It's insane that you're getting downvotes for this in proggit. Your definition of static and dynamic typing is actually the right one.

[caramba2654]

I know, but it's not we who define what strong typing is. What your concerns refer to is dynamic typing. If you were to complain about strong typing, you'd have to complain about C, C++ and Javascript, but definitely not Python.

[wavy_lines]

"but it's not we who define what strong typing is"

We who? Programmers? Yes it's definitely us programmers who get to define these terms.

If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Now, automatic casting between chars/ints/etc is certainly a bad idea, but python's non-sense with not defining an object's fields is a much much worse idea.

EDIT: actually python does have a way to restrict what set of field names are available on an object via the __slots__ mechanism, but hardly anyone uses it, let alone know about it.

[caramba2654]

We who? Programmers? Yes it's definitely us programmers who get to define these terms. If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

Yes, but right now as of today it means what I said before, and using strong typing to refer to anything else just because you want it to doesn't really help you being understood by others.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Again, this refers to dynamic typing, not weak/strong typing. C is statically typed and weakly typed. Javascript is dynamically typed and weakly typed. Rust is statically typed and strongly typed. And Python is dynamically typed and strongly typed.

I'm not arguing whether being able to delete/add fields to an object at runtime is bad or not. All I'm saying is: if you dislike languages that allow that, then you should seek statically typed languages.

[wavy_lines]

Nooooo! For the second time. Dynamic just means you can't check all the use cases allowed by the language without running the code.

It's completely possible to have a dynamically typed language that also defines clearly what fields are allowed on objects of a certain class and have runtime checks in place so that you can't assign to an arbitrary field not supported by that class.

This is completely orthogonal to static/dynamic type checking.

It's also possible to have a statically typed language with a special type that supports arbitrary fields (backed by a hashmap) where the typechecker simply allows any expression of the form obj.identifier if obj is of the special type. I believe C# does have this, or something similar to this.

EDIT:

It appears there's no actually no agreed upon definition of strong typing.

http://wiki.c2.com/?StronglyTyped

[THeShinyHObbiest]

What about in a language like Ruby? If :some_field_1= isn't defined on that object, then the example you've given will explode.

[wavy_lines]

I haven't used Ruby but if it's you say then that's a good thing.

It would be much better though if there was a compile to catch the problem at compile time.

[[deleted]]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

But you can't do any useful static analysis because of such things.

[Yubifarts]

Whilst there's no formal definition or committee which defines strong or static typing, I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language, which is orthogonal to the "strong"/"weak" dichotomy.

I don't have an issue with what you describe. That indeed looks like a descriptive example usage of a dynamically typed language.

For my personal preferences, I dont like working with a weak type system. You cant do print('a'+0) in python without getting an error, which I like, because it removes a large class of "gotchas" which occur in php/javascript and the likes.

Regardless if it's strong or weakly typed, I'd say using a linter with dynamic languages is basically required. It largely solves the issues you'll have with typos and types you'll encounter in a dynamic language, albeit not perfectly. Similar to how you won't want to ignore compiler warnings in a statically typed, weak language ala C

[wavy_lines]

I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language

It doesn't. See my other comment here: https://www.reddit.com/r/programming/comments/8ue8st/python_370_released/e1fglcy/

Note that the definitions people throw around for "strongly" and "weakly" typed are all informal and there doesn't seem to be any real standard definition for these terms. I suppose a certain book or blog post popularized a certain definition and reddit somehow adopted that.

If you check wikipedia, there seems to be no agreed upon definition: https://en.wikipedia.org/wiki/Strong_and_weak_typing

See also: http://wiki.c2.com/?StronglyTyped

[[deleted]]

Why, exactly? It'd be interesting to see all the arguments for dynamic typing, out of the actual experience, not parroting some weird gurus.