feature suggestion

F

flexibal

hi there.

i didnt know if i should post it at python-dev or here, so i'll start
here. i'd like to suggest a new language feature for python that allows
you to explicitly declare a variable.

as we all know, just doing
v = 5
declares a new variable named 'v'... but we are people, and we do make
typos... and it's very disturbing to find your program crashing after
two weeks of operation, over a NameError... because a certain branch in
your code, that was previously never taken, had finally been taken.

i've written several large-scale projects in python by now... i find it
excellent for automated testing and other infrastructural needs... but
mistyped variable-, function-, class-, and module- names been a PITA
for me ever since i've started to use python.

python is a scripting language after all, and should preserve its
scripting nature. but adding features that help you verify your python
code should also be included.

BASIC has the "OPTION EXPLICIT" feature that forces you to explicitly
declare all variables, and i see no reason why python should have a
similar mechanism.

either you start python with some commandline switch, or with a
language construct, you should be able to turn on explicit variable
declaration.

first proposal:
===============StrictError: name 'y' not explicitly declared

the syntactic format can be debated, of course. here 'decl' is used as
a built-in function that adds the name 'x' to a list of
"explicitly-declared-variables", and when setattr is called, it makes
sure the variable's name is within this list.

this is also fit for dynamic code, but suffers from still having to
execute the code before it is enforced. problems will remain in things
like:

decl("x")
x = 5
if x == 6:
y = 7

second proposal:
================
syntactic verification, at parsing time. for example:

my-prog.py:
-------------

##decl x
##decl y, z
x = 5
y = 6
z = 8
a = 6


when this program will be ran with the -strict option, like 6th line
will generate a SyntaxError: name 'a' not explicitly declared.

this strategy can verify all sorts of dead-branches, as demonstrated
above, but is not fit for dynamic code.

---

personally, i like the second proposal more, because it adds no new
language constructs, only a new commandline switch and meta-comments,
and is totally backwards compatible.






-Tomer
 
S

Scott David Daniels

flexibal said:
hi there.

i didnt know if i should post it at python-dev or here, so i'll start
here.

Good choice. Python-dev is not a location for you to propose work for
other people to do for you.
BASIC has the "OPTION EXPLICIT" feature that forces you to explicitly
declare all variables, and i see no reason why python should have a
similar mechanism.
What you are looking for is "pychecker" -- use google and find that;
you will be able to find many of the code problems you talk about
here.
syntactic verification, at parsing time. for example:
my-prog.py:
-------------
##decl x
##decl y, z
x = 5
y = 6
z = 8
a = 6 ### causes and error

This is _not_ a syntax error, syntax can be checked locally, without
memory. "a = 6" is not a syntax error because you can tell exactly
valid what form the statement has, and the form of every expression
in the statement. "a = 6 5" _is_ a syntax error; there is no way to
interpret "6 6" as an expression, and there is no way to interpret
"<statement> 6" as a statement. So, even if your proposal were to
be implemented, it would probably be an "access to undeclared
identifier" error.


--Scott David Daniels
(e-mail address removed)
 
M

moma

Do not miss the discussion topic/thread:

"Optional Static Typing" (from 12/23/2004)

The referral article is very interesting, even for a newbie.

Introduction of (optional) types will "legitimate" the Python language
even more, while it keeps the fast scripting nature unspoilt.
 
J

John Machin

flexibal said:
hi there.

i didnt know if i should post it at python-dev or here, so i'll start
here. i'd like to suggest a new language feature for python that allows
you to explicitly declare a variable.

as we all know, just doing
v = 5
declares a new variable named 'v'...

Does it? Who other than yourself comprise the "we" to whom you refer?
but we are people, and we do make
typos... and it's very disturbing to find your program crashing after
two weeks of operation, over a NameError... because a certain branch in
your code, that was previously never taken, had finally been taken.

Google for "code coverage".
i've written several large-scale projects in python by now... i find it
excellent for automated testing and other infrastructural needs

You need to test that your testing equipment works.
... but
mistyped variable-, function-, class-, and module- names been a PITA
for me ever since i've started to use python.

python is a scripting language after all, and should preserve its
scripting nature. but adding features that help you verify your python
code should also be included.

BASIC has the "OPTION EXPLICIT" feature that forces you to explicitly
declare all variables, and i see no reason why python should have a
similar mechanism.

Most Python developers would agree with what you wrote, but not with
what the context shows you meant. Have you ever considered reading what
you have written before submitting it for execution? Google for "desk
checking".
either you start python with some commandline switch, or with a
language construct, you should be able to turn on explicit variable
declaration.

first proposal: [snip]
second proposal:
================
syntactic verification, at parsing time. for example:

my-prog.py:
-------------

##decl x
##decl y, z
x = 5
y = 6
z = 8
a = 6


when this program will be ran with the -strict option, like 6th line
will generate a SyntaxError: name 'a' not explicitly declared.

and also SyntaxError: name 's' declared but never used

Your proposal needs some augmentation:

(1) Have an environment variable DWIM_LEVEL -- if the edit distance
(with variable substitution penalties depending on keyboard proximity)
between a "not declared" name and a "declared but not used" name is
within the requested tolerance, then Python should assume equivalence
and continue silently.

(2) Recursively, this should be applied to the environment variable
itself, lest one type (say) SWIM_LEVEL or DIM_LEVEL.

(3) Have an ALTERNATE_METHOD_NAME option to cater for known problems
like "center" vs "centre", "-ise" vs "-ize", etc
I look forward to the discussion of your PEP.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top