Am I the only one who would love these extentions? - Python 3.0 proposals (long)

[Peter Otten]

With a large enough palette, you could just reuse the same variable
name for everything, needing only to respect the proper colour for
correct behaviour. Imagine never having to think up variable names
more complicated than "foo".

def foo(foo, foo):
foo = foo + foo.foo()
return [foo for foo in foo(foo.foo) if foo != foo]

(I can't show the proper colourization of the above in the primitive
Usenet medium, so you'll just have to trust me that it works...)

Yes, definitely not a bad idea... ;-)

See http://www.cnn.com/2000/TECH/computing/09/07/smell.digiscents.reut/
about the now overdue "click-and-sniff" computers.
So, with technology fast advancing, you'd probably better start training
your dog to track down bugs and, ahem... code smells. On the internet,
everybody will know you're coding without a dog soon

Peter

 

[Kristian Ovaska]

while True:
foo()
how do you know that foo() doesn't twiddle Python's builtins?

If could also happen in the loop, right in front of the compiler's
observing eye:

def fun():
import __builtin__
return (setattr, __builtin__, 'True', 0)

while True:
f, builtins, name, value = fun()
f(builtins, name, value)

I recall from theory courses that determining any nontrivial semantic
feature of a program is, in the general case, impossible. Maybe
static-binding languages give enough hints in the syntax that some
analyzis could be done, but Python is very dynamic...

 

[Michael Geary]

Douglas Alan:

I agree with Alex. Case sensitivity is evil! When color
monitors started becoming common, I began to worry
that programming languages would come to allow you
to have blue variable names, and red and green variables
names, and they would all be different. Or maybe even
variable names in mixed color! Then in mixed color and
font. I better be quiet now, lest I give anyone ideas.

Too late.

http://www.colorforth.com/

-Mike

 

[Nick Vargish]

I better be quiet now, lest I give anyone ideas.

Too late... have you seen this?

http://www.colorforth.com/

Chuck Moore, a wild and crazy guy... (I mean that in a good way.)

Nick

 

[Douglas Alan]

Too late... have you seen this?

http://www.colorforth.com/

See? I'm not paranoid -- they really are out to get me!

|>oug

 

[Ron Adam]

There's a guy named Roedy Green, I believe, who hangs out in
comp.lang.somethingorother who has been advocating something pretty
close to this for a while. Except that he advocates using a database
based code management so you could store more meta information about
the code in the DB along with the text. This shows up onc.l.smalltalk
occasionally because most Smalltalk implementations do not use
text-file based code management so it fits in well with Smalltalk
schemes already

Sounds a bit like the windows registry. Since it's there, why not
put a bunch of other stuff in it. <sarcastically> Wouldn't that
just be fantastic. <and even more sarcastically> Then we could have
everything in one convenient place!

I hope nobody is thinking of that approach seriously. It may work
well in places where the use is naturally limited in both scope and
degree, but it becomes unmanageable when the size and content are
allowed to grow with no limits on them.

_Ron Adam

 

[Dave Benjamin]

With a large enough palette, you could just reuse the same variable
name for everything, needing only to respect the proper colour for
correct behaviour. Imagine never having to think up variable names
more complicated than "foo".

def foo(foo, foo):
foo = foo + foo.foo()
return [foo for foo in foo(foo.foo) if foo != foo]

(I can't show the proper colourization of the above in the primitive
Usenet medium, so you'll just have to trust me that it works...)

Yes, definitely not a bad idea... ;-)

See http://www.cnn.com/2000/TECH/computing/09/07/smell.digiscents.reut/
about the now overdue "click-and-sniff" computers.
So, with technology fast advancing, you'd probably better start training
your dog to track down bugs and, ahem... code smells. On the internet,
everybody will know you're coding without a dog soon

Hah! With luck, we can reduce the entire discipline of refactoring to merely
applying a perfume bottle to our monitors. We can start a business around
aromatherapy-oriented programming! I can almost smell it now... =)

 

[Jay O'Connor]

I hope nobody is thinking of that approach seriously. It may work
well in places where the use is naturally limited in both scope and
degree, but it becomes unmanageable when the size and content are
allowed to grow with no limits on them.

If you mean color-coded code with meaning, I don't know.

but if you mean using databases for source-code management, it works
very well and I much prefer it to text file based approaches.

 

[Tim Jarman]

I wouldn't mind having a standard module include something like this:

class Enumerate(object):
def __init__(self, names):
for number, name in enumerate(names.split()):
setattr(self, name, number)

WORK = Enumerate('NONE WRITE READ SENDFILE CONNECT ACCEPT')

I like it better than C-style enums because it's clear that the element
comes from a particular enumeration, e.g.:

workFlags = WORK.WRITE

-Dave

I knocked this up when I was after something similar:

<code linewrap_alert="on">
# Utility class to manage a set of named integer constants within a namespace.

class Enum(object):
"""Class to manage a set of named integer constants within a namespace.

Examples:

Enum("RED", "GREEN", "BLUE") creates constants RED=1, GREEN=2, BLUE=3.
Enum(RED=1, GREEN=2, BLUE=4) creates constants RED=1, GREEN=2, BLUE=4.
Enum("RED", "GREEN", "BLUE", BLACK=0) creates BLACK=0, RED=1, GREEN=2,
BLUE=3.

These values are created as attributes of the Enum instance, thus:

constants = Enum("RED", "GREEN", "BLUE")
constants.RED # -> 1
"""
def __init__(self, *names, **pairs):
"""Create an attribute for each name.

Positional arguments are assigned a sequential integer value
starting from 1.
Named arguments are assigned the supplied value.
"""
self._lookup = {}
value = 1
for name in names:
setattr(self, name, value)
self._lookup[value] = name
value += 1

for name, value in pairs.items():
if hasattr(self, name):
raise ValueError("Name %s specified more than once." %
name)
setattr(self, name, value)
self._lookup[value] = name
value += 1


def lookup(self, value):
"""Return the name corresponding to a given value.

Example:

constants = Enum("RED", "GREEN", "BLUE")
constants.lookup(1) # returns "RED"
"""
return self._lookup[value]

def isValid(self, value):
"""Return True if value is a valid constant, False otherwise.

Example:

constants = Enum("RED", "GREEN", "BLUE")
constants.isValid(1) # returns True
constants.isValid(42) # returns False
"""
return self._lookup.has_key(value)

def __repr__(self):
"""Make a nice description of enum contents."""
desc = ["<enum object at %x: " % id(self)]
bits = []
for value, name in self._lookup.items():
bits.append("%s: %d" % (name, value))
desc.append(", ".join(bits))
desc.append(">")
return "".join(desc)

</code>

I don't claim that this is the One True Answer but it works for me. It has the
advantage of going both ways - it can be handy for debugging if you can map
the value 42 to the name SPAM.

regards,

Tim J (an ex-Delphi programmer

 

[Ron Adam]

I agree with Alex. Case sensitivity is evil! When color monitors
started becoming common, I began to worry that programming languages
would come to allow you to have blue variable names, and red and green
variables names, and they would all be different. Or maybe even
variable names in mixed color! Then in mixed color and font. I
better be quiet now, lest I give anyone ideas.

|>oug

I also agree with you and Alex. Although I may differ on the
reasoning.

Since python tends to go the way of user practicality in many cases,
this seems to me to be counter to that. The only reason to use case
sensitivity is as a way to differentiate names. In my opinion its
not needed in python because there are other better ways to
differentiate names.

This is one of the items that consistently caused me errors as I
learned python. It is nearly opposite of some other languages which
used case to emphasize syntax and language specific keywords but
were in them selves non-case sensitive.

For example if a variable was a built in constant, the editor would
capitalize it for me. By doing that it helps to increase readability
and reduce programming errors in the same way that editors use colors.
At the same time it is much easier to type in lowercase and not have
to worry about putting the caps in the right place. That has both
benefits of easy to type lower case and the improved readability of
using mixed case.

Since python is an objective language, many of the names are
properties of objects and follow the form of <object>.<name>. This
feature of python is in my opinion more than enough to keep names from
interfering with each other in most cases. Thus 'foo.True' can be
different from the built in 'True'. And entering 'true' can and
should work in place of 'True' so that both forms are acceptable.
Personally I like 'True' to be capitalized but I don't want to have to
remember to type it in that way.

I think case is a useful tool and adds readability to programs when
used, but I don't think requiring it is necessary. If I have so
many variables that I run out of meaningful names, (I have yet to
write a program that does that), then I probably need to make better
use of lists and tuples.

_Ron Adam

 

[Georgy Pruss]

I like it. Thanks!
G-:

| > I like some of your suggestions, like enum.
|
| I wouldn't mind having a standard module include something like this:
|
| class Enumerate(object):
| def __init__(self, names):
| for number, name in enumerate(names.split()):
| setattr(self, name, number)
|
| WORK = Enumerate('NONE WRITE READ SENDFILE CONNECT ACCEPT')
|
| I like it better than C-style enums because it's clear that the element
| comes from a particular enumeration, e.g.:
|
| workFlags = WORK.WRITE
|
| -Dave
|
|

 

[Ron Adam]

If you mean color-coded code with meaning, I don't know.

but if you mean using databases for source-code management, it works
very well and I much prefer it to text file based approaches.

Both.

But as for using databases for source-code management, I don't think
it should be necessary. The source code itself should contain all the
information required to construct an application. Thus, makefiles
and/or database oriented sorce-code management tools shouldn't be
needed.

My reference to the windows registry was an example of how a seemingly
good idea can become a problem. The registry contains so much
information now it's difficult to manage and is a security risk. The
reference earlier to using a database for keeping all sorts of meta
information is a very similar situation in my opinion.

I'm definitely not against using databases. It's the separation of
related content in such a way that the source code is incomplete
without the other, that I don't like.

_Ron Adam

 

[Rainer Deyke]

The only reason to use case
sensitivity is as a way to differentiate names.

No. The only reason to use case sensitivity is to let the programmer
recognize names immediately without mentally translating them into a common
case. A language which allows 'sWord' as an alias for 'Sword' is
unnecessarily difficult to read.

Differentiating names is an undesired side effect of case sensitivity.

 

[Georgy Pruss]

| <...>
| languages and libraries ARE going to be written by humans, and there
| <...>
| distinctions I'd much rather *NOT* see, such as ones between types
| <...>
| But at least constants, I hear some claim? THOSE are invariably
| ALWAYS spelled in all-uppercase...?
| <...>

Alex, you ARE case-sensitive! And even *MORE* than that. <g>

G-:

 

[Ron Adam]

No. The only reason to use case sensitivity is to let the programmer
recognize names immediately without mentally translating them into a common
case. A language which allows 'sWord' as an alias for 'Sword' is
unnecessarily difficult to read.

Differentiating names is an undesired side effect of case sensitivity.

Once side of this is from the programmers point of view and the other
is from the machine interpreter point of view.

From the interpreters view, case sensitivity is used to differentiate
names in name space.

From the programmers view, it helps us to recognize names.

I don't believe they are mutually exclusive. You can still have caps
and identifiable variables without requiring case sensitivity.

A smart editor can implement case insensitivity without changing
Python. This isn't true case insensitive but it has the same effect
from a programmers point of view. It would need to correct case at
some point to do it. So call it case correcting instead of case
insensitive.


Which would you choose from the following?

As I type in a program:

1: I get an error for using the wrong case at compile time. Then
have to find the problem and correct it. Then try to recompile.

2: I'm very careful to make sure and look up all the proper names
which takes quite a bit of additional time. The program compiles and
runs normally if I didn't have any typos. If I did, then the result
is the same as #1.

3. The editor doesn't do anything special and the compiler ignores
case differences and it compiles and runs normally. I only have to
remember the correct spellings. I can use any editor I choose or have
available with the same result.

4: The editor or IDE matches what I enter to the names and then
substitutes the proper case of the name at some definitive point.
This ensures that the case is correct and the program compiles and
runs normally. If I choose a different editor then see #1 or #2.

5. The editor or IDE matches corrects the case as in #4, and the
compiler which is case insensitive compiles and runs normally. I can
choose any editor. If it doesn't support case correcting then see #3.



My preferences would be in order:

#5, #3, #4, #1, #2

Numbers 1 and 2 are really the same, but #1 is what I'm most likely to
do. Numbers 5 and 3 are basically the same, but #5 uses case
correcting while editing. Number 4 is possible to do now, but I
don't know of any editors that currently do it. It would be a nice
option to include in one I think.

_Ron Adam

 

[Rainer Deyke]

Which would you choose from the following?

Here are the options I see, in order of preference:

1. The compiler enforces a consistent capitalization scheme, preferably
all_lower_case. Note that MixedCase is only consistent if PsychoTheRapist
is a different identifier than Psychotherapist. Different syntactical
elements (identifiers vs keywords) are allowed to use different schemes.

2. Traditional case sensitivity: Bob and bOb are different identifiers.

3. Case insensitity.

What your editor does is an orthogonal issue and irrelevant to me; what my
editor does is let me type what I want without correcting me.

 

[Michele Simionato]

So, when I used to have a factory function (as 'int' was), and change
it into a type (or class, same thing), I should rename it and break all
existing programs that would otherwise keep working just fine? Or
would you prefer to bloat the built-in namespace (or module namespace
where such refactoring is going on) by having both 'int' _and 'Int'?

This is one of the reasons why I said "I am not sure if I want to
enforce the capitalization or if I want a code convention".
A code convention would be better for the situation you are talking
about; the situation I had in mind was a class with an (abused)
__new__ method, such that it works as a function (i.e. does not
return instances of the class). Using a lowercase would document
the fact that the class is intended to be used as a function.
But these are very rare cases, so probably I could live with an
enforced capitalization too.

People coming from (an exclusive diet of) case _sensitive_ (not, as you
say, INsensitive!)

Oops! You understood, it was a misprint

But people's expectations when they first meet Python are only a
part of it. More relevant is, how usable are the two possibilities?
Case sensitivity means you must basically memorize several more bits
to go with each name -- for no good reason whatsoever. You must
remember that module FCNTL has an all-uppercase name, htmllib all-lower,
cStringIO weirdly mixed, mimetypes lower, MimeWriter mixed, etc, etc --
totally wasted mnemonic effort.

This is more a problem of inconsistent conventions. It is true that
it will disappear with case insensitivity enforced, but somewhat I
don't feel it a reason strong enough.

Then you get into the single modules
for more of the same -- unless you can know what is conceptualized as
"a class" vs "a type" vs "a function" memorization's your only hope,
and if you DO know it's still learning by rote, incessantly (ah yes,
class dispatcher in module asyncore, that's LOWER-case, ah yes, the
'error' exception class, that's lowercase in sunaudiodev, it's
lowercase in socket, and in anydbm, and thread -- it's uppercase Error
in sunau, and also in shutil, and multifile, and binhex ... and
functions are supposed to start lowercase? Yeah right, look at
imaplib and weep. or stat. or token... And you think your troubles
are over once you've got the casing of the FIRST letter right? HA!
E.g., would the letter 'f' in the word 'file' be uppercased or not
when it occurs within a composite word? Take your pick...
shelve.DbfilenameShelf, zipfile.BadZipfile, zipfile.ZipFile,
mimify.HeaderFile, ...

You are exaggerating a bit. Yes, you are right in your complaints,
but in my experience I never had headaches due to case sensitivity.

Except that it is, unless your design intention (unlikely though
possible) is that the user will rebind name 'one' in your module
to indicate some other function object. Unless such is your meaning,
names 'one' and 'ONE' are "constants" in exactly the same sense: you
do not intend those names to be re-bound to different objects. One
of the objects is callable, the other is not, but that's quite another
issue. One is technically immutable -- the other one isn't (you can
set arbitrary attributes on it) but it IS hashable (the attributes
don't enter into the hash(one) computation) which is more often than
not the key issue we care about when discussing mutability.

You are still exaggerating. 99% of times uppercase constants denote
numbers or strings. I don't remember having ever seen an all uppercase
function, even if I am sure you do

So,
what IS "a constant" in Python? If you wanted to bind a name (asking
implicitly that it never be re-bound) to a "indisputably mutable" (not
hashable) object, how would you capitalize that? Python itself does
not seem to care particularly. E.g.:

Traceback (most recent call last):


I can rebind f.func_defaults, NOT f.func_name -- but they have exactly
the same capitalization. So, no guidance here...

Yeah, having read-only attributes distinguished by some code convention
(underscores or capitalization) would be a possibility, but what if in
a future version of Python the read-only attribute becomes writable? I
am use you had this are argument in the back of you mind. Nevertheless,
notice that this is an argument against a too strict code convention,
not against case insensitivity.

Why is that any more likely than 'overriding' (e.g.) types (in the old

oops again, I meant "shadowing" instead of 'overriding' but you understood

convention which makes them lowercase) or "variables" (names _meant_
to be re-bound, but not necessarily to functions)? And if you ever use
one-letter names, is G a class/type, or is it a constant?

I often use lowercase for constants, for instance in mathematical formulas:

a=1
b=2
y=a*x+b

Readability counts more than foolish consistency. Please, remember that
I am not advocating *enforcing* capitalization, even if I would welcome
a more consistent usage of capitalization in the standard library.
What I say is that case sensitivity is convenient, it gives me more
indentifiers for free.

For instance, I can define a matrix type, overload "*" and write the
multiplication of a matrix "A" times a vector "a" as

b=A*a

Much more readable to me, that something like

b=a_matrix*a

or even

b=c*a # c is a matrix

Mathematical formulas are the first reason why I like case sensitivity.

I consider the desire to draw all of these distinctions by lexical
conventions quite close to the concepts of "hungarian notation", and
exactly as misguided as those.

<horrified> Hungarian notation is an abomination you cannot put on

Much later I met the concept of "case _preservation_" --
an identifier is to be spelled with the same case throughout, and
using a different casing for it is either impossible or causes an
error -- and THAT one is a concept I might well accept if tools did
support it well (but I suspect it's more suitable for languages
where there are declarations, or other ways to single out ONE
spelling/capitalization of each identifier as the "canonical, mandated"
one -- I'm not sure how I'd apply that to Python, for example).
As long as I could input, e.g., simplexmlrpcserver and have the
editor (or whatever tool) change it to SimpleXMLRPCServer (or
whatever other SpelLing they've chOseN) I wouldn't mind as much.

Case preservation is an interesting concept which would solve some
of my objections against case insensitivity, but not all of them. We would
need more letters!

For example, Scheme and Lisp are case insensitive, but they are richer
than Python in the character set of their identifiers: so they can
distinguish a class from an instance writing something like "c"
for the instance and "c*" or "c#" or "c-" etc. for the class. How would
you do that in Python? "c" for the class and "ac" for the instance? Not
readable at all, IMHO. And think again to mathematical formulae, they
would really suffer from case insensitivity.

Perhaps it's exactly because the discussion is totally moot, that
it keeps getting hot each time it's vented (wanna bet...?-).

You won

Alex

Michele

 

[Ron Adam]

Here are the options I see, in order of preference:

1. The compiler enforces a consistent capitalization scheme, preferably
all_lower_case. Note that MixedCase is only consistent if PsychoTheRapist
is a different identifier than Psychotherapist. Different syntactical
elements (identifiers vs keywords) are allowed to use different schemes.

So to you, it is an advantage to be able to use names with the same
spelling and different case combinations for different things. And
you prefer to let the compiler catch your errors when you try and run
your programs in a traditional code, compile, debug, repeat sequence.
Is that correct?

To me, I find the use of names spelled the same with caps in different
places, that are used for different things, to be ambiguous. I would
also prefer as little repetitive debugging as possible.

Not to mention my memory for spelling, including differing case
arrangements, is definitely not one of my strong points as you would
see if I didn't use a spelling checker. So my preferences differ from
yours in this manner for personal reasons. I don't think either of us
is alone in our views.

2. Traditional case sensitivity: Bob and bOb are different identifiers.

So what is the difference between 'Bob' and 'bOb'? I have no idea.
Even though they are supposedly following some consistent scheme, the
caps don't really help me that much.

Since the bulk of python code is in the form of modules, many of
which are written by different people at different times, and by
third parties, it would be very difficult (if even possible) to
rename and enforce everything to follow a consistent naming scheme.

3. Case insensitity.

Then 'Bob and 'bOb' would be the same thing. Even though they look a
little different, I can understand this. Simple, easy to remember,
easy to use.

What your editor does is an orthogonal issue and irrelevant to me; what my
editor does is let me type what I want without correcting me.

And I believe that's the way it should be for you if that's what you
want. That was options #1,#2, and #3 in my list.

If an option for case insensitivity were implemented it would just be
a matter of doing a lower() function on all source code as a first
step in the compile process. Then case in the source code need not
matter, or you could choose to have it matter if that's what you want.
It probably isn't that simple. I haven't looked into the source code
far enough yet. Doing so would probably cause errors in existing
programs where names do use same spelling/different case for different
things. And it may also break calls to .dll's and .pyd files. There
would also need to be a switch to turn it one way or the other for
compatibility purposes.

Using a case correcting editor is one way of doing it that doesn't
change pythons core and lets the programmer choose the behavior they
want.

_Ron Adam

 

[Paul Foley]

Case preservation is an interesting concept which would solve some
of my objections against case insensitivity, but not all of them. We would
need more letters!

Case preservation is the "worst of both worlds"

For example, Scheme and Lisp are case insensitive, but they are richer

Scheme is case insensitive; Lisp isn't (the Common Lisp reader
canonicalizes case (by default), but internally it's case-sensitive;
Emacs Lisp doesn't even do that; etc.)

than Python in the character set of their identifiers: so they can
distinguish a class from an instance writing something like "c"
for the instance and "c*" or "c#" or "c-" etc. for the class. How would

We don't do that, though. Well, ISLISP idiomatically uses <c> for
class names, but Common Lisp has no such convention. Classes have
their own namespace, though, so you don't need to name them in some
special way to avoid clashing with other things. You can use c for a
class and c for an instance and c for a function, etc., all at the
same time with no ambiguity.

 

[Paul Foley]

Then 'Bob and 'bOb' would be the same thing. Even though they look a
little different, I can understand this. Simple, easy to remember,
easy to use.

But "Bob" and "Barb" wouldn't be the same thing, even though they look
a little different...Americans saying "Bob" pronounce it so that I
think they're saying "Barb" (or perhaps "Baab"), so I think these two
(three) identifiers should be the same, to avoid confusion! Heh.