Python Feature Request: Explicit variable declarations

[Steve Holden]

Dennis Lee Bieber wrote: [...]
Lists behave as described above, integers and floats don't.

By the way, a classic language like C has features like this too;
they're called pointers.

I think that after a += 1, a memory location with a 6 is created and now
a points to that because += has assignment buried in it.

This is the difference between mutable and immutable types.

>>> a = 5
>>> b = a
>>> a += 1
>>> a 6
>>> b 5
>>> a = [1,2,3,4,5]
>>> b = a
>>> a += [6,7,8]
>>> a [1, 2, 3, 4, 5, 6, 7, 8]
>>> b [1, 2, 3, 4, 5, 6, 7, 8]
>>>

regards
Steve

 

[Jorgen Grahn]

I would like to have something like the "option explicit" statement in
Visual Basic which turns on C-like checking for declaration of
variables. This is highly helpful for people who are coming from C/C+
+, for people who are learning programming using Python,

As a C and C++ programmer (not a C/C++ programmer), I have to say that
it doesn't bother me much. An optional feature like this would just
annoy me if I encountered code using it.

....

where the user has inadvertantly typed "g" before "n" and will later
wonder why his application is not working as expected.

Well, he won't *wonder* -- Python will be rather explicit about it.
"Later" is the key word here -- this bug may lay around waiting for
ten years before someone triggers it.

/Jorgen

 

[Kumar McMillan]

(e-mail address removed) wrote:
But, if you have masochistic tendencies and want a lot of overhead in
your programming, you can always bind yourself mercilessly to classes:


class C(object):
declared = ['bob', 'carol', 'ted', 'alice']
def __setattr__(self, anattr, aval):
if anattr not in C.declared:
raise TypeError, "Just can't hook you up, bro."
else:
self.__dict__[anattr] = aval

You could also do this with __slots__, like:
.... __slots__ = ['bob','carol','ted','alice']
....Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'C' object has no attribute 'x'


although, I personally have never found the need nor desire to use __slots__

E.g.:

py> class C(object):
... declared = ['bob', 'carol', 'ted', 'alice']
... def __setattr__(self, anattr, aval):
... if anattr not in C.declared:
... raise TypeError, "Just can't hook you up, bro."
... else:
... self.__dict__[anattr] = aval
...
py> c = C()
py> c.bob = 42
py> c.bob
42
py> c.x = 69
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 5, in __setattr__
TypeError: Just can't hook you up, bro.


Extending this ugliness to type-checking is left as an exercise for the
reader. Using metaclasses for such nonsense is left as an exercise for
metaclass maniacs.

James

 

[Alex Martelli]

As a C and C++ programmer (not a C/C++ programmer), I have to say that

Yeah, I wonder, what's C divided by C++ -- maybe about 0.731...?


Alex

 

[Marc 'BlackJack' Rintsch]

Yeah, I wonder, what's C divided by C++ -- maybe about 0.731...?

Isn't it 1 unless `C` is 0? The increment happens after the division,
right?

Ciao,
Marc 'BlackJack' Rintsch

 

[Gabriel Genellina]

Yeah, I wonder, what's C divided by C++ -- maybe about 0.731...?

C/C++ == 1 most of the time (being C of any integer type, of course - for
arbitrary instances, see the always missing documentation).

 

[Beliavsky]

Hello. Please tell me whether this feature request is sane (and not
done before) for python so it can be posted to the python-dev mailing
list. I should say first that I am not a professional programmer with
too much technical knowledge.

I would like to have something like the "option explicit" statement in
Visual Basic which turns on C-like checking for declaration of
variables.

The thoughts of the inventor of Python on "Adding Optional Static
Typing to Python" are at http://www.artima.com/weblogs/viewpost.jsp?thread=86641
.. I wonder if the idea will be implemented in Python 3.0.

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

Hello. Please tell me whether this feature request is sane (and not
done before) for python so it can be posted to the python-dev mailing
list. I should say first that I am not a professional programmer with
too much technical knowledge.

I would like to have something like the "option explicit" statement in
Visual Basic which turns on C-like checking for declaration of
variables. This is highly helpful for people who are coming from C/C+
+, for people who are learning programming using Python, and even
professionals, since this helps prevent typo errors like:

sunlognitude = sunlongitude + 180.0

where the user has inadvertantly typed "g" before "n" and will later
wonder why his application is not working as expected.

if you find declarative static typing programmer-friendly, then Python
is definitively not for you, and you'd better look for something else
(Java ?). FWIW, the first and main reason for stating typing is about
compiler's hint and raw performances, not "type-safety".

(A professional programmer with restricted technical knowledge and
absolutely no need for this kind of "help")

 

[Eduardo \EdCrypt\ O. Padoan]

The thoughts of the inventor of Python on "Adding Optional Static

Typing to Python" are at http://www.artima.com/weblogs/viewpost.jsp?thread=86641
. I wonder if the idea will be implemented in Python 3.0.

No. He says it in another newer post and in PEP 3099, AFAIK.

 

[Dennis Lee Bieber]

Yeah, I wonder, what's C divided by C++ -- maybe about 0.731...?

Unless it should be interpreted as (C/C)++, which would result in 2
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Bjoern Schliessmann]

Unless it should be interpreted as (C/C)++, which would result in
2

No, since postfix ++ "returns before and increments after". But what
you say is true for ++(C/C).

Regards,


Björn

 

[Dennis Lee Bieber]

No, since postfix ++ "returns before and increments after". But what
you say is true for ++(C/C).

Good thing I never embedded ++ in any formula beyond loop indices
and pointer stepping...

Now, how has the compiler built that formula

load "C"
load "C"
divide ; giving 1
load "C"
inc
store "C" ; giving "C" + 1
pop ; returning the 1 from the divide

or, on a nonstack/register machine did it build

load r1, "C" ; pre-increment temporary denominator
load r2, "C" ; increment copy
inc r2
stor r2, "C" ; giving "C" + 1
load r2, "C" ; numerator (if I have my terms correct)
divide r2, r1 ; r2/r1, not r1/r2

<G>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[mwm]

Dennis Lee Bieber wrote:
> On 14 Apr 2007 06:35:34 -0700, "jamadagni" <[email protected]> declaimed
> the following in comp.lang.python:
> In Python, the "variable" NAME does NOT define storage; unlike most
> other classical languages where the "variable name" is a storage
> address, and the value of the RHS is COPIED to that address. Python does
> not do such copying. Names are references to the RHS object itself.
>
> a = 5
>
> means that somewhere in memory is an integer object with the value "5";
> the name "a" is now "pasted onto" that integer object.
>
> b = a
>
> finds the object that has the name "a" stuck to it, and sticks a second
> name "b" onto the same object. There is still only one "5" in memory.

I can try this in interactive mode:
>>> a = 5
>>> b = a
>>> a += 1
>>> print b
5

So, if /a/ and /b/ where pointing to the *same* "5" in memory, then I
would expect b to be increased, just as a. But after increasing a, b is
still 5...

Ah, but you didn't increase a, you made it refer (bound it) to a different location. Integers in python are immutable - you can't change them. Ever. Unlike C (and similar) languages, "=" does not change the value of a variable, it makes the variable refer to the value of the right hand side. Since a +=1 is a shorthand for a = a +1, it changes a to refer to the value 6, without changing the old value. You can check this with the id function:


>>> a = 5
>>> b = 5
>>> id(a) == id(b), id(a) == id(5)
(True, True)
>>> a += 1
>>> id(a) == id(b)
False
>>>

Lists behave as described above, integers and floats don't.

Lists are mutable, integers and floats aren't. l += [stuff] (if l is a list) is a shorthand for l.append([stuff]). If you write it out as l = l + [stuff], then an old value won't change:

>>> lx = [1, 2, 3]
>>> ly = lx
>>> lx += [23]
>>> ly
[1, 2, 3, 23]
>>> lx = lx + [45]
>>> lx
[1, 2, 3, 23, 45]
>>> ly
[1, 2, 3, 23]
>>>

By the way, a classic language like C has features like this too;
they're called pointers.

Yup. In python, every variable is a pointer. So it manages to be both call-by-value and call-by-reference at the same time (it's sometimes called call-by-object-reference). If you're passed a reference to an immutable object, you can't change the value of the variable in the calling routine. If you're passed a reference to a mutable object, you can.