variable declaration

[Fredrik Lundh]

and __debug__, too, it seems:

you left out the "python -O" line.

... if __debug__:
... global x
... x = 42
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined

yup, but unlike the two others, that's a CPython -O implementation issue.
(I'd say bug, in this case).

neither standard CPython (without -O) nor Jython behave this way.

</F>

 

[Antoon Pardon]

Yes and no. I *am* looking at it from an implementation point of view, but
dictionaries have nothing to do with the relevant part of the implementation.

The CPython *_FAST opcodes relate to functions' local variables. Behind the
scenes they are implemented as integer indexing operations into a pre-sized C
array. Operations don't come much faster than that

I don't follow. AFAIR my remark here above was about the STORE opcode.
But you seem to react to it as if I am talking about STORE_FAST.

Could a rebinding operation *theoretically* be quicker for the other cases which
involve a real dictionary (or something that looks like one)? Well, perhaps.
Although I can't see how the rebinding operation would gain a benefit that a
standard binding operation wouldn't gain if placed at the exact same point.

Well it probably wouldn't be quicker, but it wouldn't be slower either
as you asserted earlier.

 

[Brian van den Broek]

Brian van den Broek said unto the world upon 2005-02-07 20:36:

Steve Holden said unto the world upon 2005-02-07 17:51:

Hi,

Steve's example makes my brain hurt.

I'd appreciate it if someone could tell me if I am understanding the
example correctly. (My grasp of the terminology and issues at play is a
bit shaky.)

Thanks for any confirmation of my understanding / rectification of same.
Best,

Brian vdB

Thanks to everyone whose contributed to this sub-thread! I've learned
a lot.

And, for posterity, some one wrote me off-list to correct my claim
that in

if False:
# thousands of lines of code here

the thousands of lines "would never get executed". Simplifying their
example, they pointed out:
.... print 'Surprise!'
....
Surprise!
Which leads me naturally to the differences between 'if False:' and
'if ):' that Duncan Booth pointed to. (Where'd I put the Tylenol.)

Thanks again to all,

Brian vdB

 

[top]

Alex Martelli wrote:
[snip]

I disagree: compile time is when the compiler is running (for example,
the compiler is the component which diagnoses syntax errors, while other
errors are diagnosed ``at runtime'').

[snip]

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

If this happens at compile-time, I'd like to know how.
Thanks,

 

[Fredrik Lundh]

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

If this happens at compile-time, I'd like to know how.

$ python sample.py
File "sample.py", line 1
try: prijnt projnt
^
SyntaxError: invalid syntax

</F>

 

[Alex Martelli]

Alex Martelli wrote:
[snip]

I disagree: compile time is when the compiler is running (for example,
the compiler is the component which diagnoses syntax errors, while other
errors are diagnosed ``at runtime'').

[snip]

That thing about syntax errors is news to me. I thought they were
caught at runtime, since you can catch them as exceptions, as in:

try: prijnt projnt
except SyntaxError: print "See, it gets caught"

Nope:

kallisti:~/cb alex$ cat a.py
try: prijnt projnt
except SyntaxError: print "See, it gets caught"

kallisti:~/cb alex$ python a.py
File "a.py", line 1
try: prijnt projnt
^
SyntaxError: invalid syntax
kallisti:~/cb alex$

If this happens at compile-time, I'd like to know how.

You can catch SyntaxError when it happens (e.g) on an explicit call to
the built-in function ``compile'', or, say:
.... except SyntaxError: print "caught!"
....
caught!

Here, the compilation of a.py (which has the error, see the cat above)
happens AFTER the try/except itself has been compiled, and while the try
clause is executing (compiling happens as part of import of a .py unless
the .pyc file is already there & updated); so the exception handler can
of course catch the exception.


Alex

 

[Thomas Bartkus]

"Alexander Zatvornitskiy"

The worst thing is that in such calculations you often receive plausible

results.
<snip>

Exactly so!

An ordinary spelling error gets promoted to a logic error that is damn
difficult to detect, let alone trace! Before one even tries, it behooves
one to spell check his variables. An additional step that counters Python's
procedural simplicity.

"i" comes before "e" except after "c" OR whenever I make a typo!
Thomas Bartkus

 

[Jeff Shannon]

Another example. Let say you have variable PowerOfGenerator in your program.
But, it is only active power, so you have to (1)rename PowerOfGenerator to
ActivePowerOfGenerator, (2)calculate ReactivePowerOfGenerator, and (3)calculate
new PowerOfGenerator by formula
PowerOfGenerator=sqrt(ReactivePowerOfGenerator**2+ActivePowerOfGenerator**2)
With var declarations, on step (1) you just rename PowerOfGenerator to
ActivePowerOfGenerator in the place of its declaration, and compile your
program. Compiler will show you all places where you have to rename variables.
After it, on step (3) you can safely and peacefully add new PowerOfGenerator
variable.

You can also get all places where said variable exists by using grep,
or your editor's search feature. I don't see how a var declaration
gains you anything over 'grep PowerOfGenerator *.py' ...

Jeff Shannon
Technician/Programmer
Credit International

 

[Arthur]

Alexander Zatvornitskiy


'global' is an ugly wart, to all intents and purposes working "as if" it
was a declaration. If I had to vote about the one worst formal defect
of Python, it would surely be 'global'.

Venturing in - again - over my head. Brave or stupid.

But the fact that I cannot dissect Python byte code, doesn't mean I
can't follow the logic or illogic of an argument. Or hear, or
interpret reasonably well what I hear.

I will accept that global is a horribly wart for reasons that I don't
understand. (worse than print>> for more reasons I don't understand
as well ?)

But making the argument that it is a wart *because* it is declarative,
and therefore a violation of Python's purity is hard for me.

"""
The fact that in Python there are ONLY statements, NO declarations, is
a completely different LEVEL of issue -- a totally deliberate design
choice taken in full awareness of all of its implications.
"""

Global is there. It was put there by someone who presumably knows his
declaratives. So simply as a matter of logic, your assertion doesn't
hold up.

And as we learn, what is true of Python today is not necessarily what
is true of Python tomorrow. And my understanding of the arguments
surrounding the decorator debate suggested to me that there is
decently strong sentiment among a segment of the folks who represent
"the community" much better than do I, that if there indeed has been
any purist stricture about the use of declaratives in the kanguage, it
may be wise to loosen it.

Why is it logical to believe that a language that is purely anything
will best do. Python prides itself on being multi-paradigm, thought
I. Except Ales says no declarations allowed, with great authority.

Do they belong in any language? Solve problems in any language?

If so, why is that Python is denied them?

Ultimately I don't think Guido chooses to be restricted by these kinds
of notions of purity. And suspect that if and when declarations best
solve real problems, they will brought to bare - without regard to
such notions.

I am sure you could if you wanted provide a highly competent - OK
brilliant - answer to why given this and that aspect of Python it
can't and won't and shouldn't be..

But you are a polemicist at heart, it seems to me - on observation
from non-techncial discussion.

So all my technical limitations aside, I still don't think I could
decipher where polemics ends, and analysis begins.

Squash me like a bug, it you like. But I am not - just so you know -
meaning to be even unfriendly, much less hostile.


Art

Fortunately, it's reasonably easy to avoid the ugliness, by avoiding
rebinding (within functions) global variables, which tend to be easy.

What you keep demanding is a way to inject far worse ugliness, and in a
context in which the typical behavior of pointy-haired bosses will be to
make it unavoidable for many of the people who work with Python. I am
strongly convinced that, if you had your wish, the total amount of
happiness in the world would be quite substantially diminished, and I
will do anything I can to stop it from happening.

AM> Another false assertion, and a particularly ill-considered one in ALL
AM> respects. Presence and absence of files, for example, is an ...
Here, you take one detail and bravely fight with it. Just try to understand
meaning of my sentence, in all. It will help

I tear ONE of your examples to pieces in gory detail, because it's not
worth doing the same over and over again to every single piece of crap
you filled that sentence with -- very similar detailed arguments show
how utterly inane the whole assertion is.

There IS no meaning to your (several) sentences above-quoted, that it
can help anybody to "try to undestand": it's simply an insanely bad
attempt at totally invalid parallels.

AM> In brief: you're not just wrong, you're so totally, incredibly,
AM> utterly and irredeemably wrong that it's not even funny.
Hey, take it easy! Relax, reread that piece of text. It was written with smile
on my lips. Here it is for your convenience:

Do yourself a favor: don't even _try_ to be funny in a language you have
so much trouble with. Your communication in English is badly enough
impaired even without such lame attempts at humor: don't made bad things
even worse -- the result is NOT funny, anyway, just totally garbled.

I'm not a native English speaker, either, so I keep a careful watch on
this sort of thing, even though my English would appear to be a bit
better than yours.

Again, skip small details and take a look on the problem "in general".

Here is,

There IS no ``problem "in general"'': Python does a pretty good job of
diagnosing as many errors as can be diagnosed ***without demanding
absurdities such as redundancy on the programmer's part***. Period.

again, the main idea:
========
Or, maybe, we will ask interpreter to find and prevent as many errors as he
can?

To show how absurd that would be: why not force every line of the
program to be written twice, then -- this would help diagnose typos,
because the interpreter could immediately mark as errors any case in
which the two copies aren't equal. Heck, why stop at TWICE -- even MORE
errors will be caught if every line has to be written TEN times. Or a
million. Why not? *AS MANY ERRORS AS [it] CAN* is an *ABSURD*
objective, if you don't qualify it with *WHILE AVOIDING ANY ENFORCED
REDUNDANCY* introduced solely for that purpose.

As soon as you see that such redundancy is a horror to avoid, you will
see that Python's design is essentially correct as it is.

You wrote about "substantial cost" of var declarations. Yes, you are
write. But think about the cost of lack of var declarations. Compare time
that programmer will waste on search for the reason of bug caused by such
typo, plus time what programmer will waste while remembering exact
variable name.

I've been programming essentially full-time in Python for about three
years, plus a few more years before then when I used Python as much as I
could, even though my salary was mostly earned with C++, Visual Basic,
Java, perl, and so on. My REAL LIFE EXPERIENCE programming in Python
temms me that the time I've "wasted on search" etc due to the lack of
variable declaration is ***FUNDAMENTALLY NOTHING AT ALL***. Other
hundreds of thousands of man-hours of similar Python programming
experience on the part of hundreds of other programmers essentially
confirm these findings.

Your, what, TENS?, of man-hours spent programming in Python tell you
otherwise. Fine, then *USE ANOTHER LANGUAGE* and be happy, and let US
be just as happy by continuing to use Python -- almost all languages do
things the way you want, so ***leave alone*** the few happy oases such
as Python and Ruby where programmers can happily avoid the idiotic
redundancy of variable declarations, and not even PHBs can impose
otherwise.

Compare it with time for looking on message:
===
Traceback (most recent call last):
File "<pyshell#16>", line 5, in -toplevel-
epselon
NameError: name 'epselon' is not defined, in strict mode
===
and fixing it, plus time on typing three letters (or less).

Like experience shows in all cases of such idiotic redundancies, the
real waste of time comes in the BAZILLION cases where your program WOULD
be just fine -- except you missed one redundancy, so you have to go and
put it in to make the gods of redundancy happy again. That happens with
VASTLY higher frequency than the cases where the enforced redundancy
saves you a comparable amount of time by catching some error earlier.

Plus, the FALSE confidence coming from redundancy works against you by
kidding you into believing that a BAZILLION other typos can't still be
lurking in your code, just because you've eliminated one TINY subset of
such typos (typos in names of variables that happen to leave the mangled
names syntactically valid BUT different from any other variable) -- and
*ONLY* that tiny subset of such typos which happened on the left of a
plain '=' (since all others, happening on the RIGHT of an '=' or on the
left of an _augmented_ '=', were already caught), and ONLY regarding
barenames (such typos on any but the rightmost component of compound
names were already caught intrinsically, and catching those on the
rightmost component is trivially easier than introducing a {YECCCCHH}
'vars' as you so stubbornly insist)...

Basically you're focusing on maybe ONE IN A MILLION of the errors you
could make and want to pervert the whole foundation of Python, and
seriously hamper the productivity of hundreds of thousands of Python
programmers in every normal case!, to save maybe two minutes in such a
one-in-a-million case.

I consider this one of the worst ideas to have been proposed on this
newsgroup over the years, which _IS_ saying something. Oh, you're not
the only one, for sure -- there must have been a dozen before you, at
least. Fortunately, even though almost each and every one of them has
wasted more of everybody's time with such ideas, than even their
scare-tactics claim of ``wastes of time'' due to lack of declarations
could account for, Python is still intact. A few of the stubborn lovers
of declarations tried doing without, and, to their astonishment, found
out that everybody else, with years of Python experience, was right, and
they, without ANY such experience, were wrong (just incredible, eh?!);
others have gone away to find their bliss in Perl, PHP, or whatever --
good riddance, and don't let the door slam behind you as you go, please.


Alex

 

[Caleb Hattingh]

Alexander

PowerOfGenerator=TakeFromSensor()
if PowerOfGenerator>xxx:
....
RecalcPower(PowerOfGenerator)
PutToTheDatabase(PowerOfGenerator)
....
Here, python will not help you. The worst thing is that in such
calculations
you often receive plausible results.

(I think PyChecker has come up before, but...) If you like, you could make
a text-file index of all the variable names allowed in your program, and
parse all the python code to ensure that only those variable names are
used. I believe this would
a) solve your problem
b) require less than a morning's work
c) not force everyone else to have to deal with variable declarations that
will be only an annoyance 95% percent of the time.

Is there a specific reason you want this added to the *language* itself?

Thanks
Caleb

 

[Elspeth Thorne]

> You may say: give better names for your variables! Ha, I'am often don't
> understand that they mean! They are written for me by an engineer!

Hang on, though - if you don't understand what you are programming, then
how can you check if it's correct? Regardless of variable names,
declarations, or anything else. And besides which - is/was there
anything preventing you from using different variable names within the
code (which are understandable to you), then displaying different names
to the user (eg an engineer) when an error occurs?

You'd hit the same issues (precisely the same issues) with any language,
if you flat-out do not know what you are doing - or trying to do.


Admittedly, I have somewhat limited experience, so my word is not
gospel, or even necessarily well-informed.

But it seems to me that declaring your variables would not fix the
underlying problem here - the programmer's lack of understanding of the
task.


Elspeth.

 

[Caleb Hattingh]

Jeff

I fully agree. As I stated in a message to alexander, it is quick and
easy even to write a simple project-specific tool for checking that only
allowed variable names exist in all the project files.

Compared to having to work with tons of effectively useless variable
declarations forever (perhaps even only in other peoples code who decided
to use the "option"), it is not much to ask (I work in pascal a lot - I
know all about tons and tons of declarations).

thx
Caleb

 

[Eric Pederson]

Arthur artfully argued:

What if:

There was a well conducted market survey conclusive to the effect that
adding optional strict variable declaration would, in the longer run,
increase Python's market share dramatically.

It's always good to examine one's objectives and motives. I am an enthusiast for marketing Python, but why? Would I get something out of Python being the language du jour? If everyone starts using Python when I am an old hand with the language, will it elevate me? Is a world where people use a programming language called "Python" necessarily a better world?

For me the answer to those questions is no.

So what would I like?

Just the option to use Python when and where it suits me and my tasks - and the continued excellent quality development and maintenance of Python and Python libraries.

It just would.

Right!

All the cool kids (and if you want to be popular you need to):

smoke/smoke dope/get tatoo'd/fight/climb the water tower/get pierced/get drunk/call their girlsfriends a b!#ch/shop lift/ditch school/put their fingers into an electrical outlet


Declare variables?

Hey, what's one more compromise to get popular?!


(I shudder thinking where that slippery slope leads)




[Nothing above is meant to imply I haven't done stupid things; rather perhaps that I've already done more than enough to know better; and, by the way, I'm still not "popular". I'd hope GvR and the crew "keep Python Python"]




Eric Pederson
http://www.songzilla.blogspot.com

 

[Nick Coghlan]

I don't follow. AFAIR my remark here above was about the STORE opcode.
But you seem to react to it as if I am talking about STORE_FAST.

I've been talking about rebinding function local variables all along - which
means STORE_FAST. I may not have made that explicit, though.

However, even in the general case, "check it already exists and overwrite it if
it does" is going to be slower than "just store it".

The reason is that, if checking for the existence of the name first somehow
provides a speed advantage (I still can't see how it could), then the latter
case of unconditional storage can check for the names existence *just to get the
speed advantage* (the difference being that the name gets bound irrespective of
whether it originally existed or not).

Anything that could be used to speed up a rebinding, could most likely be used
to speed up a standard binding at the same point in the code. So, while it might
be possible to get rebinding code which isn't any slower than a standard
binding, it seems practically impossible to do anything to get rebinding code to
be *faster*.

Cheers,
Nick.

P.S. FWIW, there is no such thing as a STORE opcode, there are only STORE_* opcodes:

Py> print "\n".join([oc for oc in opcode.opname if "STORE" in oc])
STORE_SLICE+0
STORE_SLICE+1
STORE_SLICE+2
STORE_SLICE+3
STORE_SUBSCR
STORE_NAME
STORE_ATTR
STORE_GLOBAL
STORE_FAST
STORE_DEREF

 

[Alexander Zatvornitskiy]

Hi, Steve!

SH> If your colloquial English is good enough to understand the word
SH> "bollocks" then you might begin to realize how irritating your
SH> arguments are becoming.
Well, I have a dictionary. Let's look. "Man with grey bollocks - wise,
experienced man".Hm, I'am realy have some experience in some areas

SH> If, as you suggest, def were a declaration, then it should either not
SH> be possible to write
SH> if __debug__:
SH> def func(x):
SH> print x, "is bollocks"

if __debug__:
~S=0

S=5 #error in non-debug mode.
print S

That's not the same I suppose from the beginning, but it also can be helpfull.
More exactly, it is not 'variable declaration' but 'variable definition'.
SH> You are, of course, entitled to your opinion, self-serving though it
SH> may be. A friendly idiot is still an idiot.

No comments.
SH> Please don't insult the martellibot.

It was not an insult. It is not in my rules, as I said before. It's just an
advice. "global" is in Python, but he is still alive - hence it's not as big
problem as he say.

SH> He did, after all, write "Python
SH> in a Nutshell" and co-edited the "Python Cookbook", and he has
SH> established a reputation with his consistent long-term contribution to
SH> Python and this newsgroup. Instead, ask yourself why your remarks
SH> engender such a response from a pillar of the Python community. What
SH> are your credentials?


Well, for python community - 0. Now, you can only read my messages and think
about them. After all, idiot who made contribution is still idiot, isn't it?
(it's not about A.M., of course)

Alexander, (e-mail address removed)

 

[Alexander Zatvornitskiy]

Hi, Elspeth!

ET> Hang on, though - if you don't understand what you are programming,
ET> then how can you check if it's correct?
....skipped...
ET> You'd hit the same issues (precisely the same issues) with any
ET> language, if you flat-out do not know what you are doing - or trying
ET> to do.

ET> Admittedly, I have somewhat limited experience, so my word is not
ET> gospel, or even necessarily well-informed.

I will inform you Let say you are working with the team of engineers. They
develop a project of new building, and they need some calculations of solidness
of metall constructions, specific for such kind of building. Such calculations
are rather complex, so they can't wrote program (or smth else) themselves. But
they can wrote and explain algorithm with calculations.
If you want understand their formulas, you must learn theoretical mechanicks,
resistance of materials, builder's standarts and rules (I'm not sure I
translate titles of the disciplines correctly). It will take a year, minimum.
But you have no such time - deadline is much closer

As for me, I _HATE_ such kind of job But sometimes it happens. And, after
some years, when you see the final result of such job, you fill some special
feelings. It differ from result of purely programmer's work. The result is big,
real, it may work for people during tens (or may be hundred) years.

Main problem in programming - programmer "look to the wrong place" or "overlook
coefficient", ... . Main weapon to fight with them - tests. We do it this way.
After engineer wrote an "algorithm", he take a calculator and began to work
according to it (it also help him to find "bugs"). Final result, and all
intermediate results are written. Every separate part of calculations (separate
function in program) tested separately and in whole.

But tests are not a silver bullet. static checking is also very usefull. What's
why I feel variable declaration (or explicit variable definition) may help.

Alexander, (e-mail address removed)

 

[Antoon Pardon]

you left out the "python -O" line.


yup, but unlike the two others, that's a CPython -O implementation issue.
(I'd say bug, in this case).

neither standard CPython (without -O) nor Jython behave this way.

If people here are so against declarations, how do they feel about
statements that don't seem like declarations but have a declarative
effect anyway?

Because that is what assignment statements in python essentially are.
If assignments wouldn't have a declarative effect then code like
the following should work:

x = 42

def f():
if False:
x = 20
return x

f()


If the x = 20 would be a pure executing statement, then how come
its presence has an effect on the return statement even when it
isn't executed. And we can play the same trick here. calling python -O
and feeding it this program but with the False replaced by __debug__
will make this "work".

So having come to the conclusion that some statements have a declarative
effect, I would prefer to have the declaration and the assignment be
seperated in two different statements. That would make the declaration
explicit instead of being implicit now and explicit is better than
implicit.

Of course the other solution, simply removing the declarative effect from
assignments, could work too and might even be preferable but I fear
it would produce strange behaviour.

 

[Antoon Pardon]

I've been talking about rebinding function local variables all along - which
means STORE_FAST. I may not have made that explicit, though.

However, even in the general case, "check it already exists and overwrite it if
it does" is going to be slower than "just store it".

The reason is that, if checking for the existence of the name first somehow
provides a speed advantage (I still can't see how it could), then the latter
case of unconditional storage can check for the names existence *just to get the
speed advantage* (the difference being that the name gets bound irrespective of
whether it originally existed or not).

Anything that could be used to speed up a rebinding, could most likely be used
to speed up a standard binding at the same point in the code. So, while it might
be possible to get rebinding code which isn't any slower than a standard
binding, it seems practically impossible to do anything to get rebinding code to
be *faster*.

Well it seems you have some fair points. I'll just stop here stating
that I would like to have it, even if it proved to be slower. Speed
is not that big a factor in the things I write. I just would like
to ask a question relating semantics. Supose the following code.

x = 42

def f():
x := 21 # or x .= 42 I don't remember what you used exactly

f()
print x


What do you feel should happen. I can think of two possibilities.

1) It raises an exception because x is not locally bound.

2) it prints 21.


I think the second option would be the more interesting one as
it would allow to get rid of the global statement and it would
allow for rebinding names within nested scopes.

 

[Nick Coghlan]

Well it seems you have some fair points. I'll just stop here stating
that I would like to have it, even if it proved to be slower. Speed
is not that big a factor in the things I write.

Oh, certainly. I wasn't suggesting the speed hit was enough to kill the idea - I
was just pointing it was something that you would use when correctness and being
explicit was considered more important than a small price in speed. And if the
name check got optimised out like an assert does. . . Hey, that gives me an idea
(see below).

I just would like
to ask a question relating semantics. Supose the following code.

x = 42

def f():
x := 21 # or x .= 42 I don't remember what you used exactly

Alex used ':=' in a couple of examples, but you'll have to ask him his reasons.

I used '.=' instead mainly because I think colons are ugly, but also because
':=' has the ability to trigger confusion due to its slightly different use in
those languages which use it for assignment (Eiffel and Pascal come to mind. . .
since Pascal uses it, I guess Delphi does too).

What do you feel should happen. I can think of two possibilities.

1) It raises an exception because x is not locally bound.

2) it prints 21.


I think the second option would be the more interesting one as
it would allow to get rid of the global statement and it would
allow for rebinding names within nested scopes.

I was thinking of the simpler version, with x .= 21 meaning roughly:

assert x or True # This will blow up if x fails to resolve
x = 21

The assertion would then blow up in your example (because x is an as yet unbound
local variable). To my mind, this follows the principle of least surprise.

I think the globals issue is better handled via the generic objects PEP, with an
alternate constructor that allows the generic object to be used to alter an
existing dictionary. Apply the trick to globals() and you're done.

And if Python were to ever acquire some sort of 'scope()' function to allow
programmatic access to scopes other than globals, generic objects would work for
using those, too.

Cheers,
Nick.

 

[Antoon Pardon]

Oh, certainly. I wasn't suggesting the speed hit was enough to kill the idea - I
was just pointing it was something that you would use when correctness and being
explicit was considered more important than a small price in speed. And if the
name check got optimised out like an assert does. . . Hey, that gives me an idea
(see below).


Alex used ':=' in a couple of examples, but you'll have to ask him his reasons.

I used '.=' instead mainly because I think colons are ugly, but also because
':=' has the ability to trigger confusion due to its slightly different use in
those languages which use it for assignment (Eiffel and Pascal come to mind. . .
since Pascal uses it, I guess Delphi does too).

I don't think that would be a big issue. Python uses '=' also
differently from a number of languages. My preference would
currently be for ':=' because I have the impression that if
you don't leave spaces the period in '.=' tends to be obscured.

x.=42 vs x:=42

seems a clear win for the second IMO.