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

[Andrew Dalke]

Dave Benjamin:

And so are modules...

True. But there's only rough consistancy on how those are
capitalized.

Andrew
(e-mail address removed)

 

[Patrick Maupin]

True, but I'd still prefer this one (+ editor macro) in most cases to
(ab)using numbers as symbols (this was my main point;

I think comp.lang.lisp is the group for language features which
mortals cannot cope with absent the aid of editor machinery

Pat

 

[Dave Benjamin]

Dave Benjamin:

True. But there's only rough consistancy on how those are
capitalized.

I thought the old rule of thumb was that if its main purpose was to expose a
class, name it after that class (and capitalize), otherwise, name it after
the concept it represents, in lower case.

If you were to use a module as a singleton value or namespace, would you
capitalize it?

Just curious,
Dave

 

[Michele Simionato]

Douglas Alan:

Can someone remind me as to why [None, True, False] are
capitalized? They clash annoyingly with the common coding
convention that capitalizes only classes.

Here's a conjecture -- those are singletons, and note that classes
are singletons too.

Andrew
(e-mail address removed)

Better to say: singletons are classes. But True and False are not
classes (no '__base__' attribute, for instance) so they are not
singletons.

I think using smallcaps would have been more consistent.
BTW, I would have been favorable to "Staticmethod", "Classmethod", "Super",
etc. since they are all classes. But it is useless to protest now :-(

Michele Simionato

 

[Andrew Dalke]

Dave Benjamin:

I thought the old rule of thumb was that if its main purpose was to expose a
class, name it after that class (and capitalize), otherwise, name it after
the concept it represents, in lower case.

For the most part, yes. But consider 'cStringIO'. And why is
'gzip' not named GzipFile? (Or both named 'Gzip'?)

If you were to use a module as a singleton value or namespace, would you
capitalize it?

Just curious,

I'm trying to think of a time when I've used a module as anything
other than a module, that is, where the normal module naming
guidelines applied. I can't think of one.

I have used a class as a singleton, eg, if I really need
to know if one argument was passed in or two. (This
is rarely needed and should almost never be used in
real code.)

class _default:
pass

def f(a, b = _default):
if b is _default:
print "One parameter"
else:
print "Two parameters"

Here I used lower-case. I think that's what I normally do.
However, I'm one who would have had that 'True' and
'False' be in lower-case. My comment about how the
singleton nature affects the capitalization was conjecture.

I've not seen that conjecture presented before. I'm now
wondering if it doesn't actually make some decent sense,
so that my own singletons -- where there is a fundamental
expectation for singleton-ness in the object model and
not just an aspect of the implementation -- will get a
leading capitalization.

To make things even more complicated, it wasn't until
the MOP that it was possible to have a true user-defined
singleton instance.

(Hmm. If I have an Atom class with a reference to
an Element then the Element should be a singleton and
will be named Tungston or Scandium or Helium ... or
maybe W, Sc, He. In any case, leading upper case.)

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Michele Simionato

Better to say: singletons are classes. But True and False are not
classes (no '__base__' attribute, for instance) so they are not
singletons.

I don't follow your statement.

Not all singletons are classes. Imported modules are
singletons, yes? And as an implementation choice the
numbers -1 to 100 are singletons as are the single character
byte strings. (Implementation choice since the spec requires
that None references a singleton but not that 1 and 3-2
always reference the same object.)
Traceback (most recent call last):
Traceback (most recent call last):

I think using smallcaps would have been more consistent.

Well, I do too. Just conjecturing.

Andrew
(e-mail address removed)

 

[Alex Martelli]

Michele Simionato wrote:
...

BTW, I would have been favorable to "Staticmethod", "Classmethod",
"Super", etc. since they are all classes. But it is useless to protest now
:-(

Well, understanding is never useless. So could you please clarify why
you think of (e.g.) staticmethos as needing a different capitalization
from (e.g.) int?
<type 'type'>

Why is staticmethod "a class" to you while int presumably isn't?

To me, personally, all of this debates only underscores yet again the
one serious "ergonomic" defect in Python's syntax -- case sensitivity.

The desire to distinguish between uppercased "classes" and lowercased
"types" when they're becoming undistinguishable by design in the
language is (in my warped worldview) due to having case sensitivity
in the language at all. Ah well, I've basically lost that debate in
the past, already!


Alex

 

[Michele Simionato]

Michele Simionato

I don't follow your statement.

Not all singletons are classes. Imported modules are
singletons, yes? And as an implementation choice the
numbers -1 to 100 are singletons as are the single character
byte strings. (Implementation choice since the spec requires
that None references a singleton but not that 1 and 3-2
always reference the same object.)

It is solely a matter of conventions. I am used to the definition
"a singleton is a class with only one instance". According to this
definition a singleton is a class. But it is true that a lot of
people extend the meaning to modules or numbers, so you are also
right. It is unfortunate that many concept in CS are not very well
defined (or, even if well defined, the right definition is not
universally known).

Michele

 

[Michele Simionato]

Michele Simionato wrote:
...

Well, understanding is never useless. So could you please clarify why
you think of (e.g.) staticmethos as needing a different capitalization
from (e.g.) int?

<type 'type'>

Why is staticmethod "a class" to you while int presumably isn't?

Actually, I would prefer "Int" over ""int"
I am not sure I would like to impose the capitalization (the way Ruby
does) but I would be happier with a strict standard code convention
saying "classes are capitalized". Of course, I am not proposing to
change anything. It is a very minor annoyance I can very well live
with.

To me, personally, all of this debates only underscores yet again the
one serious "ergonomic" defect in Python's syntax -- case sensitivity.

The desire to distinguish between uppercased "classes" and lowercased
"types" when they're becoming undistinguishable by design in the
language is (in my warped worldview) due to having case sensitivity
in the language at all. Ah well, I've basically lost that debate in
the past, already!

I never understood why you advocate case insensitivity. I would expect
case insensitivity to be a source of bugs: for instance, identifiers
with similar names could be confused (es. myfunction vs. myFunction):
one would expect them to be different (at least people coming from
case insensitive languages) whereas they would be the same.
Also, now I can write

ONE=1

and

def one(): return 1

and it is clear that the first name (ONE) refers to a constant
whereas the second name (one) refers to something which is not a constant.
In a case insensitive language I am sure I would risk to override constants
with functions. When I learned C (coming from Basic and Pascal) I
thought case sensitivity was a good idea, why you don't think so?
(you are free to point me to old posts if this, as I suspect, has
been debated to death already

Michele

 

[JCM]

To me, personally, all of this debates only underscores yet again the
one serious "ergonomic" defect in Python's syntax -- case sensitivity.

You know this has been discussed repeatedly with opinions expressed on
both sides. Calling it a defect is just incitive.

 

[Hallvard B Furuseth]

When reading complex expressions at speed, I have found that bumping
into a '\' in the absence of another continuation indicator (eg.
indentation) improves my ability to comprehend what I am reading.

So use indentation.

Once again, this is one of those "4am'ers":

a = x/y+(1^2+(3+u(b(4**5)))//3

+ 4)

 

[Alex Martelli]

Michele Simionato wrote:
...

Actually, I would prefer "Int" over ""int"

A consistent preference -- which will never be satisfied, of course.

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'?

I consider such a desire to distinguish callables that are for the
most part quite polymorphic, such as types/classes on one hand and
factory functions on the other, quite misplaced. Python is all about
signature-based polymorphism: why should we sacrifice the wonders of
this on the altar of "Capitalization"?!

saying "classes are capitalized". Of course, I am not proposing to
change anything. It is a very minor annoyance I can very well live
with.

To me, case sensitivity is somewhat more than a minor annoyance,
though I still live with it because the case-insensitive languages
I know of (such as Lisp) have many more things I don't really like.

I never understood why you advocate case insensitivity. I would expect
case insensitivity to be a source of bugs: for instance, identifiers
with similar names could be confused (es. myfunction vs. myFunction):
one would expect them to be different (at least people coming from
case insensitive languages) whereas they would be the same.

People coming from (an exclusive diet of) case _sensitive_ (not, as you
say, INsensitive!) languages would surely expect these identifiers to
be separate, but there are enough people coming from case INsensitive
languages (Pascal, Fortran, Basic, Lisp, ...) to basically even this
factor out. One factor that makes me prefer insensitivity is that
people who meet Python as their _first_ programming language quite
rightly see case-sensitivity as just one more hassle being thrown at
them, since in real life people aren't really case-sensitive. E.g.,
intel's trademark is all-lowercase, but on the website they keep
referring to themselves as uppercase-I Intel and nobody's confused;
hostnames and protocols in URL's are case-insensitive, too, so people
don't particularly have a connection of computers with case-sensitivity;
so are filenames in Windows, the most widespread OS, and MacOS, widely
considered the most user-friendly one (in the default filesystem,
although since it has Unix underneath you can use a case-insensitive
FS on it if you deliberately go for it); etc, etc, ad nauseam.

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. 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, ...

Basically, you end up looking all of these things up -- again and
again and again -- for no good reason. Case-sensitivity inevitably
causes that, because people sometimes think of e.g. "zipfile" as ONE
word, sometimes as two, so they uppercase the 'f' or not "wantonly".

Some will inevitably say that's just the fault of the human beings
who choose each of these many names -- case sensitivity as an abstract
ideal is pristine and perfect. To which, my witty repartee is "Yeah,
right". When you present me a language whose entire libraries have
been written by superhumanly perfect beings my attitude to case
sensitivity may change. Until you do, I'll surmise that _most_ such
languages and libraries ARE going to be written by humans, and there
really is no added value in me having to memorize or constantly look
up the capitalization of all of these names -- misspellings are bad
enough (and fortunately are generally acknowledged as mistakes, and
fixed, when found, which isn't the case for capitalization issues).

Moreover, many of the distinctions you're supposed to be drawing
with this precious capitalization, allegedly worth making me and a
zillion learners suffer under silly gratuitous mnemonic load, are
distinctions I'd much rather *NOT* see, such as ones between types
and classes (traditionally), or types/classes and factory functions.
Some factory functions get capitalized, like threading.RLock, cause
it's "sorta like a class", some don't, because, hey, it's a function.
More useless distinction and more memorization.

But at least constants, I hear some claim? THOSE are invariably
ALWAYS spelled in all-uppercase...?

"Sure", say I, "just like math.pi"...

Also, now I can write

ONE=1

and

def one(): return 1

and it is clear that the first name (ONE) refers to a constant
whereas the second name (one) refers to something which is not a constant.

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. 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...

In a case insensitive language I am sure I would risk to override
constants with functions.

Why is that any more likely than 'overriding' (e.g.) types (in the old
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 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.

When I learned C (coming from Basic and Pascal)
I thought case sensitivity was a good idea, why you don't think so?

When I learned C (coming from a lot of languages, mostly case
insensitive) I thought case sensitivity was a ghastly idea, and I
still do. 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.

(you are free to point me to old posts if this, as I suspect, has
been debated to death already

Oh, this isn't the first round, but it isn't the second one, either.
It's essentially a discussion on how languages should be designed,
rather than anything that could ever concretely change in Python:
the very existence of "indistinguishable except for spelling" names
such as fileinput and FileInput, random and Random, etc, etc, makes
it certain that this characteristic can never be changed.

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


Alex

 

[Alex Martelli]

You know this has been discussed repeatedly with opinions expressed on
both sides. Calling it a defect is just incitive.

Nice word (I admit I had to look it up, but don't feel too bad about
that, because American Heritage didn't know it either. But, so
what? Particularly when carefully starting a sentence with "To me,
personally", I _DO_ get to express my opinions, you know, even though
you consider them "[adj] arousing to action or rebellion" (and I
disagree with your opinion of them: I am convinced that no action nor
rebellion can ever remove from Python the wart of case-sensitivity).

If and when people design their own little languages they're quite
likely to model some of their aspects on languages they do know. I
_do_ hope to "arouse to action" some would-be designer of some such
specialized language, enough that they'll consider making said future
minilanguage case-insensitive; if they do, I think the overall amount
of happiness in the world will be (albeit minutely) increased.


Alex

 

[Jay O'Connor]

To me, personally, all of this debates only underscores yet again the
one serious "ergonomic" defect in Python's syntax -- case sensitivity.

Prior to Python I was using Smalltalk, which is case sensitive. Like
'case statements' it's something that even after using Python quite
some time I never really even thought about whether the language had
it or not.

 

[Hallvard B Furuseth]

I like some of your suggestions, like enum. Some
particular dislikes:

6) The colon is optional after for,if,try,enum etc. if it is
followed by a new line.

Sounds to me like this would just make code harder to read, for very
little gain. And harder to parse for editors.

7) Built-in regex'es. It would be nice to have built-in regular
expressions. Probably, some RE functionality can be shared
with the built-in string class, like presently we can write
'x'.encode('y'). For example $str can produce a regex object
and then s==re can return true if s matches re. This would be
very good for the switch construction (see below).
E.g.
id = $ "[A-Za-z_][A-Za-z0-9_]*"
if token == id: return token

'token == id' should test if token is the same regexp, not if it
matches. I prefer id.match(token). OTOH, it would be an advantage if
one could write something like $"...".match(token) and have this
automatically perform re.compile, so one didn't have to put regexps one
wanted to be compiled in a variable outside the loop using them.

I don't really care much, though - beacuse I don't use python regexps
much. I use Perl for regexpy code. Decide for yourself if that's an
argument for or against such a change to Python

10) Until loop -- repeat the loop body at least one time
until the condition is true.

until <postcond>
<stmts>

It's the same as:

<stmts>
while not <postcond>
<stmts>

Very surprising semantics. I'd expect that to be the same as:

while not <postcond>
<stmts>

If the while should be executed at the end, put it at the end:

while 1:
<stmts>
until <postcond #1>
<more stmts>

12) Selection statement.
Yes!

14) Conditional expression. Yes, I'd love it.

cond ? yes : no

Yes! But too late, the vote was lost.

16) Depreciated/obsolete items:
-- No else for while,for,try etc -- they sound very unnatural;

Thanks for bringing this up. I've been wishing there was a way to say
what 'try: ... except: ... else: ...' says, and I didn't know that there
already was one.

 

[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.

|>oug

 

[Dave Brueck]

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

 

[JCM]

JCM wrote:

Nice word (I admit I had to look it up, but don't feel too bad about
that, because American Heritage didn't know it either. But, so
what? Particularly when carefully starting a sentence with "To me,
personally", I _DO_ get to express my opinions, you know, even though
you consider them "[adj] arousing to action or rebellion" (and I
disagree with your opinion of them: I am convinced that no action nor
rebellion can ever remove from Python the wart of case-sensitivity).

I took your "To me, personally" to refer to your opinion about what
the debate underscores, not about whether case-sensitivity is a wart.
In any case, not an interesting enough tangent to continue (in my
opinion...).

 

[Peter Hansen]

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.

Not a bad idea... although the implementation would probably require
something like using a special suffix to represent the colour, so the
file could still be saved as ASCII. The editor would of course have
to be smart enough to translate this suffix into the appropriate colour,
and then suppress the suffix. I'm sure vi and that other editor,
whatever it's called, could do that.

Of course, we could also specify the colour separately with new
keywords. We could have different keywords for different things,
such as integers, floats, strings, etc. That way you could reuse
the same variable name for different types of data, without worrying
about conflict. You could see at a glance which was which!

You could also allow custom defined types... let's call them
"type defs" for short. Then you could customize the colouring
for just about any type of variables.

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... ;-)

-Peter

 

[Jay O'Connor]

Not a bad idea... although the implementation would probably require
something like using a special suffix to represent the colour, so the
file could still be saved as ASCII. The editor would of course have
to be smart enough to translate this suffix into the appropriate colour,
and then suppress the suffix. I'm sure vi and that other editor,
whatever it's called, could do that.

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