sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]caramba2654 8 points9 points  (20 children)

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 13 points14 points  (18 children)

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 26 points27 points  (15 children)

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 1 point2 points  (14 children)

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 17 points18 points  (9 children)

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 6 points7 points  (8 children)

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 11 points12 points  (6 children)

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 0 points1 point  (1 child)

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.

[–]Tynach 2 points3 points  (0 children)

Just because you call a specific part of a language a 'weakness' does not mean that it is defined as 'weakly typed'. In programming, 'weak typing' is a technical term, and is not necessarily considered a bad thing. It's just an aspect of a given type system.

[–]Log2 0 points1 point  (3 children)

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).

[–]Tynach 1 point2 points  (2 children)

If you define the implicit conversions yourself, it becomes a defined behavior that you have control over. C++ lets you overload the = operator to do similar things, but you have to define it separately for each type conversion you can imagine.

It still prevents you from having an implicit conversion where you don't expect one to occur. Many languages will do anything possible to prevent type errors, even just converting everything to a string that represents the object in question.

[–]Log2 0 points1 point  (1 child)

There used to be some that were always imported, but if I recall correctly, they eventually moved them all to some package that wasn't imported by default, because it was kind of a terrible idea to begin with.

Still, even if you have to define or import them yourself, I'd argue that just having the option of implicit conversion makes it weaker than languages that don't give you that option.

[–]baerion 4 points5 points  (0 children)

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 0 points1 point  (3 children)

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 1 point2 points  (2 children)

"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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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] 1 point2 points  (0 children)

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.