On 12/08/2016 12:07, Steven D'Aprano wrote:
On Fri, 12 Aug 2016 07:38 pm, BartC wrote:
'year' has been spelled wrongly
How do you know?
I know because my intention was to create a RECORD, with a specific set
of members or fields. With records, you usually don't just create
arbitrary named members as you go along.
But in Python, the mechanism and syntax used to create such members is
the same as used for ad-hoc attributes. This was the point I was making
about sometimes it can be a little too dynamic.
There are broadly two tactics that a language can take when it comes to
attribute (or more widely, variable) names:
(1) Editing is cheap, but compiling and testing code is expensive
No, compiling is cheap too.
The first time I ever compiled a full-sized application (not a particular
large one either, it was a text editor a little more featureful than
Notepad) it took something like nine hours to compile on a Mac SE (this was
circa 1990).
That is completely crazy even for 1990. I was using my own tools then
and the time to re-compile a 50,000-line application would have been
measured in seconds. Certainly not minutes anyway (I wouldn't have had
the patience!).
How mad would I have been if, eight hours and thirty minutes
into the compilation, the compiler suddenly stopped with an error caused by
a mistyped variable name?
Today, I could probably compile the equivalent program in a minute.
I'm actually working on a compiler now that could compile a 50Kloc
application in about 1/16th of a second (to byte-code; perhaps 1/8th of
a second to in-memory native code).
A pass that merely checks that names have been declared has effectively
zero cost.
It *absolutely makes sense* to require variable declarations (possibly
including type information, where it cannot be inferred)
My example was specifically about attribute names where pre-declaring
the set of allowed attributes would not be onerous, would be usefully
self-documenting, and would allow more errors to be picked up.
(Of course the design of Python makes that impractical because it would
require the byte-code compiler to see inside imported modules before
execution is commenced.)
Turn it around though: one of the reasons why languages like Ruby,
Javascript, Lua, Python, Perl etc are so ridiculously productive is that
you don't have to keep stopping to declare variables just to satisfy the
compiler. Need a new variable? Just assign to it and keep going -- there's
no, or very little, mental task switching.
Another reason why such languages are so productive is the availability of
an interactive REPL where you can try out code interactively. How clumsy
and awkward the REPL would be if you had to keep declaring variables ahead
of time.
I agree when it comes to variables. But it /does/ allow these extra
errors to creep in that are not detected until that particular fragment
of code is executed.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
