"Steven D'Aprano" <st...@pearwood.info> wrote in message
news:53159540$0$2923$c3e8da3$76491...@news.astraweb.com...

It's that "explicitly" part that doesn't follow. Having to manage types
is the most tedious, boring, annoying, *unproductive* part of languages
like Java, C and Pascal. Almost always, you're telling the compiler stuff
that it can work out for itself.

Isn't creating classes in Python similar to creating types elsewhere?

In the same way that managing jumps for GOTO has been automated with for
loops, while, etc., and managing memory has been automated, there's no
good reason not to allow the compiler to manage types. Dynamically typed
languages like Python do so at runtime. Type inference simply allows
statically typed languages to do the same only at compile time.

Eliminating 'goto' is simple code-generation logic; type inference is more
of an art.

But declaring variables is not just about specifying a type; it registers
the name too so that misspelled names can be picked up very early rather
than at runtime (and that's if you're lucky).

# Yes
[1, 3, 4, 2, 5, 9]
(1, "hello", None, 3.5)

# No
[1, "hello", None, 3.5]


That is, lists are for collections of data of arbitrary length, tuples
are for records or structs with dedicated fields.

That convention is a bit weaker these days than it used to be. Tuples now
have list-like methods, and we have namedtuple for record/struct-like
objects with named fields.

(Aren't tuples immutable? They wouldn't work well for records then, because it would be impossible to change a field of a record.)

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to