Python3k extended grammar
Roy Katz
(apologies in advance as to the applicability of this message to such a
general group)
I checked out the TYPE-SIG material.. It's really interesting.
I agree that grammars which take into account the type of an object are
in quite demand in Python; however, as a (practical) programmer I take
offense at the creation of (yet) more keywords and operators. For
example, take the function declaration grammar:
def func( x: Integer, y: Integer ) -> Integer:
what's the rational behind using the -> operator, rather than sticking to
'return'?
def func( x, y ) return Integer:
IMHO it's just another operator or keyword to bloat my language.
Same thing with the proposed 'decl' operator. Why another keyword?
What's wrong with the following:
int = Integer
def add( (int) x, (int) y ) # specifies type of the parameter
return int; # specifies the return type
raise exGenException: # specifies the exceptions thrown
z = x + y # body
return z # exit.
No added keywords there. I understand that the above is more verbose,
however, I believe this approach is vastly more consistent with the
traditional grammar. Then again, this is only my personal preference.
Another question: to whoever proposed the following notation:
x: [ Integer ]
what happens when we have a list of list of strings?
x: [[ StringType ]]
am I correct here?
As I see it, we have a grammar spectrum with Pascal and Java on one side,
(which places the burden on the programmer to declare, detail and
categorize every little nuance), and perl on the other -- a language
which IMHO is reconfigurable ad nauseum. (what kind of situation
necessates changing the starting array index from 0, anyway?).
Roey Katz
Jewish Programmer.
Oy.
Manus Hand
post with it, since my question is only tangentially related, but....
(By the way, I agree with Roy that the less new syntax and fewer
new keywords the better! Anyway, as to my own question....)
It was with a large degree of alarm that I read that "the language
(Py3K) will be somewhat incompatible." There didn't seem to be
anyplace at python.org that explains this any further. Maybe it has
been rehashed before, but could the scope of Py3K be spelled out
for those of us who fear it?
Things like talk about having to declare variables and their
types and having to specify function return types scare
me. They scare me to death. I love Python, but if stuff like
that becomes required, I will stick with 1.6 forever. If
someone will reassure me that I won't *have* to use typing
and declaration, then I will be happier. Much.
One of the features I love about (and rely on) in Python is complete
type freedom. I have countless functions that accept different types
as parameters and return differently typed results. A function that
usually returns an integer could return a None (or a list or a class
instance, or who knows), etc., etc.
Maybe I'm just weird, but "if type(theVar) == type([])"
(or "assert" in place of "if"), etc., is all the typechecking I ever
wanted. I'm a runtime flexibility (dynamic code generation,
etc.) addict and I know I'm not alone.
Again, I apologize for intruding on Roy's posting, but it would
put my mind at ease if Py3K were spelled out somewhere.
If the right place to look for Py3K details is in the type-sig (which
is where Roy found stuff), let me know and I'll look there. I hate
bothering the group with something most of you already know,
but well, I'm scared.
And seeing that Roy found that Py3K might introduce all sorts of
new syntactic constructs like -> for "returns" (talk about asking
to confuse anyone coming from C/C++!!) and (presumably)
reserved words, like "Integer," etc., it makes me think I might
have *reason* to be scared.
Thanks for any responses,
Manus
Paul Prescod
>
> ...
>
> It was with a large degree of alarm that I read that "the language
> (Py3K) will be somewhat incompatible." There didn't seem to be
> anyplace at python.org that explains this any further. Maybe it has
> been rehashed before, but could the scope of Py3K be spelled out
> for those of us who fear it?
There is no predefined scope. Your only hope is faith in Guido.
Seriously.
> Things like talk about having to declare variables and their
> types and having to specify function return types scare
> me.
Nobody has, as far as I know, ever spoken about having to declare
variable types in Python. Many, many people have asked to be *allowed*
to declare variables in Python. There is a big difference.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Just how compassionate can a Republican get before he has to leave the
GOP and join Vegans for Global Justice? ... One moment, George W. Bush
is holding a get-to-know-you meeting with a bunch of gay Republicans.
The next he is holding forth on education or the environment ... It is
enough to make a red-blooded conservative choke on his spotted-owl
drumstick. - April 29th, Economist
Martijn Faassen
> This is a dumb question, and I know I shouldn't be following Roy's
> post with it, since my question is only tangentially related, but....
> (By the way, I agree with Roy that the less new syntax and fewer
> new keywords the better! Anyway, as to my own question....)
I agree here too. While the types-SIG has come up with many good
thoughts, I don't think the proposed syntax is ideal yet. Though
perhaps it's more a question of getting used to it. Still, the ':'
is overloaded a lot already in Python, and -> looks a trifle
odd if it's used in just one place. the 'return' proposal looks
prettier to me. But then I change my syntax preference daily. :)
> It was with a large degree of alarm that I read that "the language
> (Py3K) will be somewhat incompatible." There didn't seem to be
> anyplace at python.org that explains this any further. Maybe it has
> been rehashed before, but could the scope of Py3K be spelled out
> for those of us who fear it?
Nobody knows yet. It's possible that it'll be case insensitive,
which is of course incompatible. Oh, and 1/2 might give you
a float.
Rather minor changes. Then of course..
> Things like talk about having to declare variables and their
> types and having to specify function return types scare
> me. They scare me to death. I love Python, but if stuff like
> that becomes required, I will stick with 1.6 forever. If
> someone will reassure me that I won't *have* to use typing
> and declaration, then I will be happier. Much.
Right; if it was required to declare variables, I'd be scared too.
Luckily it's never been the plan to make such declarations required.
They're always optional.
That didn't stop some of us paranoid folks from worrying on the types-SIG,
though. I was wondering if there mightn't be subtle pressures towards
the idea that full type annotation is good Python style, somehow,
and worried about this ghostly image. Not so much by the language
(though there's the const-correctness infection in C++), as by the
culture surrounding the language. Currently type annotations are
just too vague to be really worried about such spectres, though.
So the short answer is: don't worry, they'll be optional. We understand
the enormous value of dynamic type-checking in the Python world.
Plans about Py3k are completely vague, however, so I'm probably talking
through my hat. :)
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Robin Becker
def x(IntType y, FloatType z=1.0) StringType:
.....
looks sufficient. The one thing python has going for it is a lack of
spurious keywords and punctuation. It would be a disaster if the clean
language got too dirty.
The thing I don't understand is what
the actual type names would be ie IntType, StringType, ..., classId or
some newly introduced names Int, String etc.
Would partial typing be allowed eg ListType
--
Robin Becker
Robert
As a newbie..."return" makes it much easier read and understand
Bob
Roy Katz <ka...@Glue.umd.edu> wrote in message
news:Pine.GSO.4.21.00051...@z.glue.umd.edu...
Courageous
>
> uggh...keep "return"...out with "->"...nuff said!
Well, just in case someone mistakes us for a committee :)-
I agree. One of python's saving grace's is the approachability
of its syntax. Python's syntax is wonderfully lightweight,
devoid of the usual mess of symbols which weigh down other
languages. Let's keep it that way.
C/
Steven D. Arnold
> int = Integer
> def add( (int) x, (int) y ) # specifies type of the parameter
> return int; # specifies the return type
> raise exGenException: # specifies the exceptions thrown
>
> z = x + y # body
> return z # exit.
I like your style better than the alternative; note I haven't read the
TYPE-SIG stuff in detail yet. I agree that the spirit of python seems to
favor making things as clear as possible, avoiding either perl-style
terseness or COBOL-style wordiness. The words that you use make the
meaning clearer to me than do the symbols.
>(what kind of situation
>necessates changing the starting array index from 0, anyway?).
Perhaps for UNIX nice values, which range from -20 to 20. I don't so much
dislike the idea itself; it's just that setting a variable such as:
$[ = -20;
...almost couldn't be uglier. On the other hand, python's pleasant class
interface makes you want to write a class to handle nice values, if they
needed special management, and just keep lists zero-based so everyone can
easily maintain it.
steve
--
Steven D. Arnold Que quiero sera ste...@permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard." -- John F. Kennedy
Roy Katz
> Nobody has, as far as I know, ever spoken about having to declare
> variable types in Python. Many, many people have asked to be *allowed*
> to declare variables in Python. There is a big difference.
As one who enjoys programming both little (albeit elegant) scripts and
large projects alike, I feel safe with Python as a 'stable' language
set. Here's a list of Unqualified Rumors we've been compiling:
1. Python 3000 may be case-insensitive.
2. It may allow type-checking.
3. It may have a more thorough garbage collection mechanism.
4. dividing integers may yield a float.
I don't really have an issue with (1) personally; however,
I find scripts such as
IMPORT OS, OS.PATH
DIRNAMES = '..'
OPENFILES = []
FOR N IN OS.LISTDIR( DIRNAME ):
F = OPEN( OS.PATH.JOIN( DIRNAME, N )
OPENFILES.APPEND( F )
*really* difficult to comprehend (and perhaps, even *with*
case-insensitivity, and assuming even then that this doesn't break any
existing code), but if it helps budding programmers, I understand.
for (4) my only concern is that int/float promotion would at least
remain consistent. For me, this is confusing as it is:
a = 5 # just practice variables
b = 3
c = float(a) / float(5) # force c to be a float (supposedly)
if we have explicitly declared float types to work with, then this
wouldn't even be an issue for me. But again, I could still write a
module to implement this and then have its / operator overloaded.
What I would like to know is where I can get information. So many people
have asked about p3k in this group; I've searched python.org and Starship
and have come up with relatively little. The TYPES-SIG (whose archives
are accessible from Python.org) sheds light on the types issue (then
again, I have issues with their proposals).
Roey
btw -- the above is just my preference. Whatever aids new students in
learning to program, so be it (at least I'll have Python 1.x).
François Pinard
> 1. Python 3000 may be case-insensitive.
Horror, hell, and damnation! April 1st should be far behind us by now!
I would hate[1] writing with inconsistent casing, with nothing on my side
to help me writing consistently. I much prefer what Python is, today, on
that regard. So, how do I register my vote? Where do I leave my tears? :-)
Besides, is there any real need behind case-insensitiveness? Or is it
just another step forward (backward? :-) on that road that would drive us
towards a click-on-the-pink-button-and-hear-the-soft-sound version of Python?
--------------------
[1] Scheme did this to us. Hopefully, I found an implementation which
was deviant enough from the standard to be usable. Under option, of course.
--
François Pinard http://www.iro.umontreal.ca/~pinard
e...@harvee.billerica.ma.us
> uggh...keep "return"...out with "->"...nuff said!
>
> As a newbie..."return" makes it much easier read and understand
hmmm. am I the only one that read -> as yields?
> > def func( x: Integer, y: Integer ) -> Integer:
I see this definition as reading:
Given two integers (x,y), func yields integer
man, I gotta stop reading Dykstra before bedtime...
--- eric
Hrvoje Niksic
> Manus Hand <mjh...@concentric.net> wrote:
> > This is a dumb question, and I know I shouldn't be following Roy's
> > post with it, since my question is only tangentially related, but....
>
> > (By the way, I agree with Roy that the less new syntax and fewer
> > new keywords the better! Anyway, as to my own question....)
>
> I agree here too. While the types-SIG has come up with many good
> thoughts, I don't think the proposed syntax is ideal yet.
The proposed syntax looks like a Pascal-inspired abomination. I hope
it dies as soon as possible.
> Nobody knows yet. It's possible that it'll be case insensitive,
*vomit*
So every instance of "foo = Foo()" where Foo is the class and foo is
the instance will have to be changed to something really ugly.
> Oh, and 1/2 might give you a float.
Yuck.
> Right; if it was required to declare variables, I'd be scared too.
> Luckily it's never been the plan to make such declarations required.
> They're always optional.
I'm still scared of people with a Java mindset declaring always
everything. But then again, I guess the absence of method overloading
will effectively prevent that. Unless the types SIG plans to add that
too.
Guido van Rossum
> Roy Katz <ka...@Glue.umd.edu> writes:
>
> > 1. Python 3000 may be case-insensitive.
>
> Horror, hell, and damnation! April 1st should be far behind us by now!
>
> I would hate[1] writing with inconsistent casing, with nothing on my side
> to help me writing consistently. I much prefer what Python is, today, on
> that regard. So, how do I register my vote? Where do I leave my tears? :-)
Python is not a democracy. Voting doesn't help. Crying may... :-)
> Besides, is there any real need behind case-insensitiveness? Or is it
> just another step forward (backward? :-) on that road that would drive us
> towards a click-on-the-pink-button-and-hear-the-soft-sound version of Python?
This is all taken way out of proportion. I promise that Python 3000
won't suddenly be introduced without further discussion. Every issue
will discussed here and elsewhere and we'll explain why we want to
change the design. We'll also explain what we're going to do for
compatibility.
In the mean time, we're too busy with Python 1.6 to be able to answer
each question about Py3k. Once 1.6 is released I promise to create a
FAQ about Py3k.
Some quick answers: for case insensitivity, we'll have tools that
enforce consistent casing (and maybe the case insensitivity will be in
the tools alone).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Courageous
> Python is not a democracy.
The success and future of python is a democracy of the most
brutal kind.
C/
William Tanksley
That's right: and Guido is both the teeming masses AND the guillotine.
Seriously, though, the future of Python is not up to any democracy --
because even if a majority doesn't like it, it won't be hurt. We don't
need any vote (although we can always leave).
>C/
--
-William "Billy" Tanksley
Courageous
> >> Python is not a democracy.
>
> >The success and future of python is a democracy of the most
> >brutal kind.
>
> That's right: and Guido is both the teeming masses AND the guillotine.
>
> Seriously, though, the future of Python is not up to any democracy --
> because even if a majority doesn't like it, it won't be hurt. We don't
> need any vote (although we can always leave).
I appreciate what you're trying to say, but if Python ever
becomes a mainstream programming language, I can guarantee
you that it will outgrow Guido.
I don't know a thing about the Guido, and don't have a thing
against him; to the contrary, I'm rather fond of his language.
(Thanks, Guido!) Be that as it may, there comes a time when the
founder of something ceases to have true dictatorial power
over his creation, sooner or later.
It's generally a bad idea to opine "it's my way or the highway,"
especially in a setting like this, where the more you say it,
the less and less true it will become. Conversely, the more
he listens to what his users have to say, even if it's just
a token vote, the more likely he is to see continued success
and growth of this beautiful language.
Hope I haven't offended anyone,
C/
Stephen
statement, especially considering you took out half of that line. Here, let
me add it back in:
>> Python is not a democracy. Voting doesn't help. Crying may... :-)
Then, later, His Holy Majesty The Creator expressed that they wouldn't be
doing anything just arbitrarily and without discussion here/etc...
Someone still has to make a decision, though... and having a vision about
how you want something to end up (like, i'd assume, His Holy Majesty The
Creator should have, being The Creator, and everything. ) would be a rather
good thing in the whole decision making process.
:-)
--Stephen
Courageous <jkra...@san.rr.com> wrote in message
news:39260B99...@san.rr.com...
Will Rose
: Francois Pinard <pin...@IRO.UMontreal.CA> writes:
:> Roy Katz <ka...@Glue.umd.edu> writes:
:>
:> > 1. Python 3000 may be case-insensitive.
:>
:> Horror, hell, and damnation! April 1st should be far behind us by now!
:>
:> I would hate[1] writing with inconsistent casing, with nothing on my side
:> to help me writing consistently. I much prefer what Python is, today, on
:> that regard. So, how do I register my vote? Where do I leave my tears? :-)
: Python is not a democracy. Voting doesn't help. Crying may... :-)
:> Besides, is there any real need behind case-insensitiveness? Or is it
:> just another step forward (backward? :-) on that road that would drive us
:> towards a click-on-the-pink-button-and-hear-the-soft-sound version of Python?
: This is all taken way out of proportion. I promise that Python 3000
: won't suddenly be introduced without further discussion. Every issue
: will discussed here and elsewhere and we'll explain why we want to
: change the design. We'll also explain what we're going to do for
: compatibility.
: In the mean time, we're too busy with Python 1.6 to be able to answer
: each question about Py3k. Once 1.6 is released I promise to create a
: FAQ about Py3k.
: Some quick answers: for case insensitivity, we'll have tools that
: enforce consistent casing (and maybe the case insensitivity will be in
: the tools alone).
Well, either make it ALL UPPER CASE or all lower case, I don't care;
please do not, repeat not, make it case-preserving and case-insensitive.
That way madness lies.
This a deal-breaker for me; I've written a fair bit of Python, but
haven't spent a lot of time on it and still have a great deal to learn.
If Py3k is going that route, I need to stop wasting time now and resume
my fight with Perl. When will the Py3k FAQ be out? July/August?
Will
c...@cts.com
Dieter Maurer
> > to help me writing consistently. I much prefer what Python is, today, on
> > that regard. So, how do I register my vote? Where do I leave my tears? :-)
>
> Python is not a democracy. Voting doesn't help. Crying may... :-)
Dieter
Martijn Faassen
> Roy Katz <ka...@Glue.umd.edu> writes:
>> 1. Python 3000 may be case-insensitive.
> Horror, hell, and damnation! April 1st should be far behind us by now!
Oh, ick, too late. I see this thread exploded. I suppose it's too late
to throw in references to Haskell, non-euclidian geometry and evolutionary
biology to douse the flames, hm?
Martijn Faassen
> Yet, here are some of the reasons why I am considering making Python
> case-insensitive:
> (1) Randy Pausch, a professor at CMU, found, when teaching Python to
> non-CS students in the context of Alice (www.alice.org), that the
> number one problem his students were having was to remember that case
> matters in Python. (The number two problem was 1/2 == 0; there was no
> significalt number three problem.)
Minor data point: I haven't had any trouble explaining case-sensitivity
to the bunch of people I've been teaching Python so far. That's about
10 people, most of them fairly computer-savvy, though some aren't. I don't
know enough about Alice, but I recall the setting was people using Alice
primarily for the 3d capabilities, and being gradually introduced to Python
as something secondary to extend Alice's possibilities. Am I correct in that
there wasn't a teacher introducing it? Was it discovered through exploration?
If there's a teacher around it really isn't so hard to explain or remember
the case-sensitive part, is it? So far I haven't found it to be an issue,
at least. Computers are picky anyway. I've had more trouble with explaining
the indentation, and the whole *concept* of block structure. The syntax issue
is something minor in the whole picture of learning something. I recall
learning the weird greek alphabet was the easiest part about learning
ancient Greek.
This is not to say that syntax doesn't matter; it does -- especially the
way it relates to the underlying semantics. Compare alphabetic versus
iconic writing systems, for instance.
> (2) I've met many people who are experienced and accomplished Python
> programmers but who still, when referring to Python modules or
> functions in an informal context (e.g. email), make up their own case
> conventions. E.g. people will write me about the String module or
> about FTPLib.
This sounds a bit much like DWIM, though. I'm sure these same people
also get their braces or indentation wrong at some points. Perhaps they
get tripped up by single element tuples. The whole idea of a syntax
check is to make sure that the code conforms to some basic surface rules.
If it doesn't, it's likely to be unclear to the reader, too.
Many of the arguments for block structure by indentation can be made
for case insensitivity: a good programmer is supposed to indent/
case-consistent *anyway*, so why not let the environment enforce it?
> I also know some of the things I plan to do to make the transition
> painless and to make the usual problems with case insensitivity more
> palatable. E.g. I may add a case insensitivity feature to IDLE which
> makes sure that all identifiers are written in a consistent case, I
> may add flags to pre-Py3k Python interpreters to turn on case
> insensitivity or case sensitivity or a special warning mode.
You'll have trouble getting the current coders get rid of all the:
foo = Foo()
Where Foo is a class. This should be quite common (as it's a useful
idiom).
Martijn Faassen
> Ben Wolfson wrote in comp.lang.python:
>> On 21 May 2000 18:22:26 GMT, scarblac...@pino.selwerd.nl (Remco
>> Gerlich) wrote:
>>
>> >Besides, it's apparently easier
>> >to use for newbies, who have never learned that 'Friend' and 'friend' are
>> >completely unrelated words.
>>
>> Then they should learn that they are.
> Why? I don't see a lot of added benefit. If case insensitivity is both
> easier to learn and easier to read, that sounds like Python to me.
Python also has indentation marks block structure. You know, the lack of
'free form' blocks that's often bemoaned by people who haven't actually
tried it (and some who have, of course, but few). I'd say the lack of
free form casing would fit this general philosophy, and have the same
type of benefit: more readable code.
Martijn Faassen
[snip]
> Suspicions are most easily dispelled/confirmed via evidence, and
> taking the trouble to do this has the pleasant side-effect that you
> can either cease expending effort worrying, or move directly to taking
> positive action to correct the problem.
I've seen quite a few variant ways to spell Pascal keywords. Uppercase,
lowercase, and so on. That wasn't very pretty in my opinion.
Martijn Faassen
[snip]
> "Python is case sensitive. While we, as programmers, were com-
> fortable with this language feature, our user community suffered
> much confusion over it. At least 85% of users who were observed
> using the Alice tutorial made a case error at some point during the
> experience.
This is about *Alice*, not about Python, the programming language.
Is this the same Alice tutorial that comes with Alice when you download it?
There's not a single line of Python in that. There *are* Python names
in there, but not a line of Python code, as far as I recall.
> While explaining the case rule was simple enough
> ("upper and lower case mean different things to Alice"), this was
> not sufficient to instill a "case aware" sense in our users. Of the
> users who had problems with case, most continued to type case-
> incorrect tokens in their programs for a short period.
This would indicate that they were writing Python code later. Note the
'short period'.
> Coming to
> terms with case sensitivity is a difficult skill for many to learn, a
> fact that can often be lost on experienced programmers."
"Coming to terms with indentation is a difficult skill for many to learn,.."
"Coming to terms with variables.."
"Coming to terms with mutable versus immutable variables.."
There are a lot of things that we could do to make Python easier to
learn for newbies. Let the editor mark names that refer to
immutable objects in a special color. I think case insensitivity
is insignificant to what you can do with a decent IDE, except that
it trips up half of the experienced programmers. :)
You-can-do-case-insensitivity-with-a-decent-IDE-ly yours,
François Pinard
> Incidentally, let me remark as a Python newbie on a pleasant surprise.
> [...] I'm quite astonished at the quality and civility of comp.lang.python.
Some correspondents had commended Python to me for a long time, but I was
involved in some big Perl programming, and was not ready for the effort of
any big change. Yet, the Perl community was letting me with a bad taste
in the mouth. When I was described the qualities of `comp.lang.python'
as a group, it was the real push that convinced me to dive and try.
Of course, I then hesitated for a few weeks, because of the size of the
conversion ask. But Python proved itself to me fast enough, and this is
on the way of the translation that I discovered most of its virtues, often
with surprise and pleasure. I still read Perl, and even write it once in
a while. But I've done the transition, and Python is now my place! :-)
François Pinard
> > If you mean those oscilloscopes which simultaneously drove the X and Y
> > coordinates, with separate analogic hardware for each character, the only
> > one I knew were the CDC 6x00 consoles, and these were pretty expensive
> Hmmm, my first thought would have been Tektronix storage display
> tubes...
Yes, of course. Tektronix were also vector drawing, characters included.
Those were not cheap, but in no way as expensive as the CDC 6x00 consoles.
> The infamous "killer" displays (hearsay, but I've heard that
> the vacuum in a cracked display tube was sufficient to drive the gun
> end out the front of the tube to impale the user <G>)
Surely, the glass of the bigger Tektronix memory displays was getting
dangerously hot, we could not touch them, and people were joking about
baking eggs on them :-).
The CDC 6x00 consoles were no memory display, they ought to be refreshed
by continuously redisplaying their whole contents, and one of the eleven
computers making up the machine was dedicated to that sole clever task.
Since then, I've _never_ seen anything like these (not even approaching)
for "feeling" in real time how an operating system behaves inside.
François Pinard
> François Pinard <pin...@iro.umontreal.ca> wrote:
> > Roy Katz <ka...@Glue.umd.edu> writes:
> >> 1. Python 3000 may be case-insensitive.
> > Horror, hell, and damnation! April 1st should be far behind us by now!
> Oh, ick, too late. I see this thread exploded. I suppose it's too late
> to throw in references to Haskell, non-euclidian geometry and evolutionary
> biology to douse the flames, hm?
There are modest tries with Teletypes and such things :-)
P.S. - Do you read this message in the list? I got two rejects with:
<pytho...@python.org>: Command time limit exceeded:
"/home/mailman/mail/wrapper post python-list"
Martijn Faassen
> On Sat, 20 May 2000, Thomas Malik wrote:
>> 1. case insensitivity sounds like complete nonsense to me. Who needs it,
>> actually ?
> The "E" in CP4E, according to quite a few usability studies.
Does anyone have a list of URLs or somethings that we can check out?
(besides the alice docs)
Regards,
Martijn Faassen
> Mike Fletcher wrote:
>>
>> Personally, I have been bit by case problems probably five or six times (in
>> five years or so). That said, I find working with case insensitive
>> languages difficult to the point where I will not use them.
> The truth of the matter is that, irrespective of whether or
> not a language is case sensitive or not, using inconsistent
> case for the same thing is an extraordinarily bad idea, and
> would be extremely poor engineering practice.
It's the indentation argument all over again, in fact:
The truth of the matter is that, irrespective of whether or
not a language is indentation sensitive or not, using inconsistent
indentation is an extraordinarily bad idea, and
would be extremely poor engineering practice.
Since Python enforces the indentation issue, but the same philosophy
it ought to enforce the case issue. And does. :)
Thomas Wouters
> P.S. - Do you read this message in the list? I got two rejects with:
> <pytho...@python.org>: Command time limit exceeded:
> "/home/mailman/mail/wrapper post python-list"
This is a known problem with the list... (that is, I talked with Barry about
it, and he rewrote parts of Mailman in response to some discussion we had,
and it hasn't helped :-) It's my belief now that it isn't Mailman-specific,
just that the list is so incredibly large that sending all messages out
takes longer than Postfix is prepared to wait.
The message is probably archived properly, is probably posted to the
newsgroup properly, and even sent to a fair number of the lists recipients,
but maybe (probably) not everyone. The problem is probably related to a cron
job on the machine, or some such, as it always happens at CET mornings,
which is like 2 AM for the machine in question ;) So, if you usually catch
up on the newsgroups while enjoying a cup of coffe or a bit of breakfast,
before heading to work, like me, you can expect a couple of these bounces
;-P
I imagine Barry has been insanely busy the last few weeks aranging the move
to sourceforge of Python and Mailman, among other things, but I hope he'll
be able to tune those Postfix timing parameters sometime soon... I'm
purposely avoiding postings before noon localtime to avoid the bounces ;-P
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Ken Walter
if the file is to be considered case insensitive or not.
Then everyone can have it their way.
If one of the choices turns out to be bad, it will fall into disuse.
Ken Walter
Remove -zamboni to reply
All the above is hearsay and the opinion of no one in particular
ne...@cswcasa.com
reread my original message the tone came across as much more hostile than
I intended; this is a subject that seems to come up every few weeks and
swallow the newsgroup whole, and I'm afraid I took out some of my
frustrations on you. Sorry.
Basically, there are so many more fundamental changes being discussed --
such as true garbage collection, type/class unification, lexical
scoping, rich comparisons, strong typing, a new iteration protocol --
that I'm amazed and a little dismayed that something as relatively
trivial as case-sensitivity is dominating the discussion.
I mean, in a year or two it'll be tried out in IDLE, people will stare
at it, and then someone will point out there are a hundred thousand
Python programmers with 25 million lines of Python code that will be
broken by such a change, and then the idea will be dropped. It doesn't
matter whether the idea is objectively good or bad (I think it's a very
good idea); Python will have grown so much that the threshold for
justifiable backwards-incompatible change will have risen above the
benefit it will provide.
I hope (but fear that I'm wrong) that the same is not true of the
iteration protocol -- there's a critical need to be able to iterate
over trees and linked-lists cleanly. This is IMO more significant
than GC or even type-class unification, and it's the major reason I'm
rooting for Stackless, since it permits Sather-style coroutine-based
iterators to be implemented in Python.
François Pinard [mailto:pin...@iro.umontreal.ca] wrote:
> ne...@brick.cswv.com (Neel Krishnaswami) écrit:
>
> > Suspicions are most easily dispelled/confirmed via evidence
>
> The evidence of one is not necessarily the evidence of the
> other. I'm grown up enough to know that :-). Some evidences
> are also more credible :-).
>
> > and taking the trouble to do this has the pleasant side-effect
> > that you can either cease expending effort worrying, or move
> > directly to taking positive action to correct the problem.
>
> I'm not sure I understand you fully. My overall feeling is
> that our goal, here, is more about _not_ correcting a false
> problem, than having to take positive action for correcting a
> problem which might not have to be.
--
Neel Krishnaswami
ne...@cswcasa.com
Martijn Faassen
>> François Pinard <pin...@iro.umontreal.ca> wrote:
>> > Roy Katz <ka...@Glue.umd.edu> writes:
>> >> 1. Python 3000 may be case-insensitive.
>> > Horror, hell, and damnation! April 1st should be far behind us by now!
>> Oh, ick, too late. I see this thread exploded. I suppose it's too late
>> to throw in references to Haskell, non-euclidian geometry and evolutionary
>> biology to douse the flames, hm?
> There are modest tries with Teletypes and such things :-)
Yeah, I noticed afterwards. Not that I didn't contribute to the
case sensitivity discussion! :)
> P.S. - Do you read this message in the list? I got two rejects with:
> <pytho...@python.org>: Command time limit exceeded:
> "/home/mailman/mail/wrapper post python-list"
I read it through the newsgroup (comp.lang.python), not through the
mailing list gateway.
Martijn Faassen
[snip]
> It's much better to say "the language is case-insensitive" and to have the
> tools correct case as you write.
You forgot this, didn't you? :)
Or-the-same-with-"the language is case-sensitive"-ly yours,
Fredrik Lundh
> Obviously, this is confusing. But is the problem in the case-sensitivity,
> or in the error message? Suppose that instead, a newbie saw:
>
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> NameError: No such variable as 'X'.
>
> Or even better:
>
> NameError: No such variable as 'X'. Did you mean 'x' instead?
or the ABC way:
>>> PUT 3 IN x
>>> PRINT X
There's something I can't resolve in your command
PRINT X
*** The problem is: you haven't told me HOW TO PRINT X
okay, okay, I get the point...
case-sensitive-ly yrs /F
Dirck Blaskey
Russell Wallace <rwal...@esatclear.ie> wrote in message
news:392877...@esatclear.ie...
> ...
> Quick question: Any chance of removing the requirement for colons at the
> end of class, def, if, for, while lines? That's the only thing about
> Python's syntax I truly dislike, and I still keep tripping up on it;
> pretty nearly all the rest I find fine.
When I brought this up a couple of months ago, no one seemed to think
it was a good idea. I implemented the hack just for fun, though I haven't
actively been using it. (Fired it up recently during a discussion:
"do single line if statements need colons?" on c.l.python).
The primary argument seemed to be:
1) Guido doesn't like Optional Anything (...One-Obvious-Way...)
2) The colons make the code *slightly* more readable
If you are interested in the whole discussion or want the code,
it's available at http://www.danbala.com/python/colopt
d
Pete Shinners
the topic covered further.
i see the point of using insensitive casing to make the language
more flexible. also allowing users to 'alter' the style of the
language to best fit with their project.
i do see the annoyance of working with a project, and then needing
to use a module which uses a strongly different capitialization
scheme that the rest of the project.
if you are considering loosening the 'case' requirements for
the language, consider also loosening the 'underscoring' of
object names.
it may sound like a honky wild idea, but it seems any arguments
used for case insensitive can also be used with 'optional'
underscoring.
example. if i read in someone's module, and it uses the
popular "all words separated with capitals"
(GetValue, ClearScreen), but i prefer to use "all words
separated with underscores" (get_value, clear_screen)
(obviously optional underscores would be restricted to
between letters, to preserve python's current special
meanings for leading and trailing underscores.
(perhaps this is up for discussion with python3k, heh))
if the argument is making the language more flexible to meet
different users styles, how far does that go? when do things
become too confusing?
i'm interested to see where this goes either way, but here's
certainly food for thought.
i've never used a case insensitive language. and actually,
i've never even thought about it. it's hard to imagine if
i would end up preferring it or not?
PS, no offense intended with my case insensitive writing
style :]
Andrew Dalke
>you might know enough German to know the difference between
> "Dort haben sie etwas hingelegt"
>and
> "Dort haben Sie etwas hingelegt"
>
>One is "There they've put something down" and the other is "There
>you've put something down." Okay, so it's the only word in German
>that I'm aware of that changes meaning with capitalization... but
>nontheless it proves there *are* words that mean different things
>because of their capitalization.
In English, an example is:
Where is the polish container?
Where is the Polish container?
The first is where you might keep shoe shine, and the second is a
container made in Poland. Unlike the following, the two words are
even pronounced differently!
Here's another:
Do you like china? -- asking about ceramic preferences
Do you like China? -- asking about country preferences
Stretching some,
That is my french toast. -- bread dunked in a mixture of eggs and milk,
then toasted on the stove top
That is my French toast. -- toast from France, or a congratulatory
remark to be made in French.
Switching to names of people instead of countries:
If it weren't for Faith ... -- person named Faith helped out
If it weren't for faith ... -- belief helped out
And corporate names:
What was next? -- curious about ordering
What was NeXT? -- curious about the company Jobs started after
leaving Apple.
Andrew
da...@acm.org
e...@harvee.billerica.ma.us
> Here's a way to make your vote count: explain what it is about case
> sensitive languages that you hate. Then we can have a discussion
> about it.
okay, here's why I don't like case sensitive languages. I program by
voice. I know blind programmers that listen to code. An aural
interface and case sensitivity are not a good match.
--- eric
Martijn Faassen
[snip]
> I hope (but fear that I'm wrong) that the same is not true of the
> iteration protocol -- there's a critical need to be able to iterate
> over trees and linked-lists cleanly. This is IMO more significant
> than GC or even type-class unification, and it's the major reason I'm
> rooting for Stackless, since it permits Sather-style coroutine-based
> iterators to be implemented in Python.
I'd like to see something like that. For other inputs on this and
other things, I think the algorithms part of C++'s STL may be worth
investigating (keep the few neat bits, throw away the rest), and for
a really out there thing I've recently been playing a bit with the
language K (that is, I've read some of the manual), at www.kx.com
K's a bit in the style of APL (though I don't know APL). All I've been
doing is translating some of the operators to Python classes, but since
I can't think in K yet I haven't accomplished a lot. :)
Regards,
Dieter Maurer
> "During the course of development, we tried very hard not to
> modify the Python language. /.../ Unfortunately, we were ulti-
> mately forced to abandon pure Python when testing revealed
> two flaws in the language that made Python unusable by our
> target audience: integer math and case sensitivity."
Q: Is the Alice projects target audience identical to that of Python?
> "Python is case sensitive. While we, as programmers, were com-
> fortable with this language feature, our user community suffered
> much confusion over it.
Seems that programmers have few problems with case insensitivity.
Rather, they like it, because they can name similar things with
similar words (only different in case).
We have such things in German, too: e.g. Essen (substantive) and essen (verb).
For German, it would be wrong to have: "Essen" == "essen".
However, even otherwise case insensitive languages would respect
case in string constants (whose content are considered outside
the language).
> "I note with some embarrassment that Hypercard, Pascal and LOGO
> were designed for novice or infrequent programmers and each was
> case insensitive. It may be that Microsoft's Visual Basic programming
> environment provides the best of both worlds by following the user
> to type in a case-insensitive way, while the programming environment
> applies the proper case to the program text on behalf of the user
> whenever possible."
I just reread the Pascal specification.
Nothing suggests that Pascal was supposed to be a case insentive
language.
Dieter
Dieter Maurer
> (1) Randy Pausch, a professor at CMU, found, when teaching Python to
> non-CS students in the context of Alice (www.alice.org), that the
> number one problem his students were having was to remember that case
> matters in Python. (The number two problem was 1/2 == 0; there was no
> significalt number three problem.)
Naming conventions are, however, (I think) not well documented
and, at least for module names, inexistant or not adhered to.
In my view, the way out should not be to give up case sensitivity
but to document and adhere to simple naming conventions.
> (2) I've met many people who are experienced and accomplished Python
> programmers but who still, when referring to Python modules or
> functions in an informal context (e.g. email), make up their own case
> conventions. E.g. people will write me about the String module or
> about FTPLib.
It this really a reason to have the same variability in
formal as in informal contexts?
> I also know some of the things I plan to do to make the transition
> painless and to make the usual problems with case insensitivity more
> palatable. E.g. I may add a case insensitivity feature to IDLE which
> makes sure that all identifiers are written in a consistent case, I
Oh no!
Either I have case insensitivity and can use it (inconsistent writing
for the same object, such that I do not need to always consult
a dictionary)
or I have case sensitivity and can use that (giving similar
but different objects names different only in case).
But having case insensitivity but being forced to use the
names as if the language were case sensitive seems really ill
for me.
Dieter
Unknown
this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
yoU'Re sAyING IT'S UnACcePtABlE -- A vOte. but YoU doN't sAy *WHy*
yoU vOtE thAt waY, so YOUr VOTE geTS mULtIplIED By zERO (RAtheR THan
bY tHE SIze of yOUR DePaRTment Or tHe CApITAL OF YOUR bANK, AS YOu
SeEm tO HOPe By brINgiNG THEM iNto ThE ARgumENT :-).
hERE'S A waY To MAKe YOuR votE cOuNt: ExPLAIn wHat It is abOUT CASE
sENsitiVE lANGUAGES ThAt YOu HaTE. then wE caN HAVe A diScUssION
abOUt It.
i aM a veRY caSE-sEnSitIVE PERsoN MYSElf: IT bOThErS Me whEN pEoPLE
DON't starT thEiR SENtEnCES witH CapITAL LeTters OR WheN THEy reFER To
themsElVes As "I" iN lOwErcASE -- oR WHen pEOpLe REFer To pyThOn aS
"PythON" OR "PyTHOn". (COme tO thINK Of It, it bOtheREd ME WheN yOU
Wrote "gERMAN" InsteAd Of "gErMAN" :-).
YEt, here aRe SOme of the ReAsoNs WHy I AM conSIdeRInG MaKIng pYTHoN
cASe-insENsiTivE:
(1) RAnDY PAUsCH, a pRofESsor AT cMU, FOUnD, WheN TeacHIng PythON TO
NON-cs STUDENtS iN the cONTExT of alIce (wWW.aliCe.org), tHAt tHE
number ONE pROBLeM hIs STudentS WERe HavinG WAS to rEmEMBER thaT CASe
mAttErs in PYthoN. (ThE nUMBER TWO pRoblEM waS 1/2 == 0; ThERE wAS no
SiGNIFICalT nUMBER ThREE prOBLEm.)
(2) i'VE MET Many PEoplE wHO ARE EXpErieNCED aND AcComPLishED PyThON
progRaMmERS But WhO StILl, WHEN ReFerRiNG tO pytHoN mODulEs Or
FunctIoNS In AN iNFOrmaL ConteXT (e.G. EMAil), make up thEIr OWN cASe
CoNVENtIOnS. e.g. PeopLE WilL wrITe Me AbOut ThE sTRING MoDuLE OR
ABouT FTplIB.
I AlSo kNOw SoMe OF the THInGS i pLan TO DO tO mAke The TRansitION
PaInleSS anD to MAkE ThE USUAL PrObleMS With CAse INsEnSItIVITy mOrE
palATABle. e.g. I MaY add A CAsE iNseNSiTiviTy FeatURE TO iDLe WHIch
makES sURE tHAT All IDEnTifIers ARe WriTtEn In A consIStenT caSe, i
may aDd fLAgS to PRE-py3k pYthon InterpReTeRS to tuRN oN CAse
INSensiTIvITY oR Case sensiTiVIty OR A SpecIaL Warning mode.
--
--GUIDO van rOSsum (hoME PaGe: HTTp://wWw.PythOn.oRg/~GuidO/)
--
HttP://www.PYthOn.ORG/MaiLman/LIStiNfO/pYthoN-LISt
I know I am being ridiculous.
However, I am having trouble imagining how removing case-sensitivity from the language could improve usablility for
any programmer, regardless of his/her skill level. Most people seem to have no particular trouble with case-sensitivity in
natural languages; why should a computer language be any different? On the other hand, maybe I am just too ingrained in my old
thought patterns.
Best,
Ben
Ivan Van Laningham
Ben Cornett wrote:
>
> this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
>
I bet you wrote a Python program to do this, didn't you? Post the code!
<oPerAtOrs-ArE-stAndinG-bY>-lY y'RS,
iVaN
----------------------------------------------
Ivan Van Laningham
Axent Technologies, Inc.
http://www.pauahtun.org
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Unknown
>
> this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
>
> http://www.python.org/mailman/listinfo/python-list
You have been warned. No more silliness! Now let's have something military.
(Or at least something completely different.)
Unknown
> Hi All--
>
> Ben Cornett wrote:
> >
> > this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
> >
>
>
> <oPerAtOrs-ArE-stAndinG-bY>-lY y'RS,
> iVaN
> ----------------------------------------------
> Ivan Van Laningham
> Axent Technologies, Inc.
> http://www.pauahtun.org
> http://www.foretec.com/python/workshops/1998-11/proceedings.html
> Army Signal Corps: Cu Chi, Class of '70
> Author: Teach Yourself Python in 24 Hours
>
> http://www.python.org/mailman/listinfo/python-list
You caught me ;-)
I'm a python addict and I can't help myself.
######################################
#!/usr/bin/env python
import sys
import string
import whrandom
for s in sys.stdin.readlines ():
for l in s:
if l in string.letters:
if whrandom.randint (0,1):
l = string.upper (l)
else:
l = string.lower (l)
sys.stdout.write (l)
#######################################
Simple, but effective.
Best,
Ben
François Pinard
> Then everyone can have it their way. If one of the choices turns out
> to be bad, it will fall into disuse.
In arts, compromises yield mediocre results. The personality and vision
of the artist has to go through. I like to see Python as a piece of art.
I just hope the artist will not get too tainted by usability studies :-).
Courageous
>
> this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
That is, perhaps, the most apropos 'flame' I've seen in a
long, long time.
:)-
C/
Albert Wagner
one-way street. There is more information in case-sensitivity. The
people of the case insensitive fork can easily convert everything to
upper or lower case. But then the information is gone and cannot be
reconstructed.
Hamish Lawson wrote:
>
> If case insensitivity was introduced, I propose that there
> should be a command-line switch to revert to case sensivity for
> backwards compatibility (my own preference would actually be to
> keep case sensitivity as the default and have a switch to make
> it case-insensitive if desired).
>
> Hamish Lawson
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
--
Small is Beautiful
John W. Baxter
<die...@handshake.de> wrote:
> > "I note with some embarrassment that Hypercard, Pascal and LOGO
> > were designed for novice or infrequent programmers and each was
> > case insensitive. It may be that Microsoft's Visual Basic
> > programming
> > environment provides the best of both worlds by following the user
> > to type in a case-insensitive way, while the programming
> > environment
> > applies the proper case to the program text on behalf of the user
> > whenever possible."
> I just reread the Pascal specification.
> Nothing suggests that Pascal was supposed to be a case insentive
> language.
However, some very commonly used implementations were/are
case-insensitive. I suspect Wirth started Pascal when it wasn't much of
an issue: what you got from keyboards was upper case.
And I think I remember that not all implementations made
A_NAME == ANAME
either, although it was common (what the "optional" underscore did to
8-character name significance varied as well, IIRC).
I tended to write Pascal code in lower case, then run a utility to
convert the keywords to upper case. Until I decided I didn't like it
that way (there are so few keywords one really shouldn't need help
remembering them, and some things that "feel like" keywords aren't).
--John (who is unable to comment on Visual Basic)
--
John W. Baxter Port Ludlow, WA USA jwb...@scandaroon.com
Albert Wagner
German, would prefer to ignore case, just as they would prefer to ignore
punctuation and grammer. Case sensitivity adds expressiveness to a
language, yet with no real overhead. Case carries additional
information for the readers of a language, information that is lost and
obscured when case is ignored.
--
Small is Beautiful
Paul Prescod
>
> I find it bizarre that case sensitivity would be the greatest hurdle to
> CP4E.
Human beings are bizarre. That's why we must do user interface testing
and learn from the results.
> When we teach our children to write we teach them case sensitivity, I do not
> remember any governing body suggesting we should drop case sensitivity from
> written language in order that 'everyone' will therefore be able to write.
What governing body would do such a thing?
> I also cannot believe that this is a difficult lesson to learn.
It isn't a case of learnability. It's about repetitive mistakes. In my
XML classes, case sensitivity is the premier source of bugs which I, as
an expert, can diagnose very quickly but which my students spend minutes
or even hours trying to figure out.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Just how compassionate can a Republican get before he has to leave the
GOP and join Vegans for Global Justice? ... One moment, George W. Bush
is holding a get-to-know-you meeting with a bunch of gay Republicans.
The next he is holding forth on education or the environment ... It is
enough to make a red-blooded conservative choke on his spotted-owl
drumstick. - April 29th, Economist
Paul Prescod
> the language could improve usablility for any programmer, regardless of
> his/her skill level. Most people seem to have no particular trouble with
> case-sensitivity in natural languages;
If you review the variety of formatting conventions in this list, you'll
find that that is not the case. Guido himself documented how people
speak of the String and FTPLib modules and python programming language.
> why should a computer language be any different? On the other hand,
> maybe I am just too ingrained in my old thought patterns.
I prefer case sensitivity. But I think that most of the arguments people
make in favor of it are bunk.
1. If you spend time with newbies -- especially Windows-trained newbiews
-- you will note the case sensitivity is a problem.
2. Code written in a case insensitive language is roughly as robust and
readable as that in a case sensitive language.
The most honest arguments are "case sensitivity feels cleaner" and that
it "is more popular with existing programmers."
Arthur Siegel
> "During the course of development, we tried very hard not to
> modify the Python language. /.../ Unfortunately, we were ulti-
> mately forced to abandon pure Python when testing revealed
> two flaws in the language that made Python unusable by our
> target audience: integer math and case sensitivity."
>Q: Is the Alice projects target audience identical to that of Python?
To the best that I can comprehend the target audience are 'animators', or
let's say graphic
artists. Alice's specifc purpose is to allow its audience to get as much 3D
world-building
done as possible, given and fully accepting that this audience has no
current or future interest
in programming.
We have to draw the CP4E line someplace. Perhaps everyone except those with
an active lack of
interest. Alice's audience. Which is in no way a shot at Alice or its
mission.
Until Guido's recent post up here I was willing to accept the possibility
that it was me - that
I had misinterpreted and misunderstood the importance he attached to Alice.
But, he announced here
unequivocally that the Alice studies are central to his thinking about the
future of Python.
The future of Python.
Personally, don't care much about whether Python is or is not case
sensitive. If Guido concludes
a case insensitive Python is the more elegant Python, I certainly have no
basis or reason to
doubt his judgement. The question is way out of my league, but I'll go
every time with a track
record - and Guido's as a designer is impeccable in my view.
But the assessment of the relevancy of the Alice study seems to me cake.
That question I can handle.
Very, very little.
Is Guido simply being devilish in posing this to us?
On the issue itself - that of case - I've come full circle. I accept
Guido's instinctual design decisions
on faith, and if that is what P3K is in the end about I would be amazed if I
or anyone else were disappointed.
They boo-ed when Dylan went electric.
But for me its about the instincts of a designer, and the faith of a fan.
Not science.
So much the better.
François Pinard
> > The most honest arguments are "case sensitivity feels cleaner" and that
> > it "is more popular with existing programmers."
> It seems to me that the important argument in this context is "case
> insensitivity will break millions of lines of existing code, and perhaps
> split the user base if a significant number of existing users refuse to
> switch". I can see good arguments either way - overall it doesn't
> strike me as a major issue - but I'm dubious about changing it at this
> stage.
It seems many of us a a reason against it. My main reason for praying
that Guido will stand by what he gave us so far, is that Python is a clean
language, and that case insensitiveness is an open door to sloppiness right
from the lowest level and initial contact with the language. That will
corrupt everything from down up in the long run. It's not really a thing
we should do to children, and not either a thing children should do to us.
François Pinard
> Why is case sensitivity a language barrier for those who don't want it?
> If you don't want two cases, choose one and use that one alone. On the
> other hand, case insensitivity can be a big headache for people who need
> two cases.
The problem is that it is not to be a personal taste and thing. We live
in a world of inter-human relations, and computers are instruments in
these exchanges. Python programs are being shared, and children (and
adult newcomers) will also learn to share as well in their apprenticeship.
Python should stay designed so these exchanges are as meaningful as possible,
and case confusion directly goes against peaceful exchanges. The natural
sloppiness of many people should not get conveyed and imposed to others,
without Python somewhat imposing its distinct legibility features.
It just does not fit together to have a clean syntax with a sloppy
tokenizer. This is tearing apart the own elegance of the language, and
somewhat destroying one of the quality which made it attractive. I quite
understand that some people just do not mind, and that children may not
see the benefit by themselves, right away. It is even likely that studies
might even demonstrate that a bit of learning is needed: let's keep calm!
John W. Baxter
<pa...@prescod.net> wrote:
> The most honest arguments are "case sensitivity feels cleaner" and that
> it "is more popular with existing programmers."
Not to mention "I just like it better" (where "I" is the speaker, not
Baxter in particular).
I (Baxter in particular) don't plan to abandon the language just because
it becomes case-insensitive, if in the long run it does. I'll be
slightly displeased, is all.
--John
Courageous
> The illiterate in every language, computer or natural, English or
> German, would prefer to ignore case, just as they would prefer to ignore
> punctuation and grammer.
God, please forgive those who demean the illiterate
and misspell grammar.
*merciless laughter resonates throughout the room*
>:)
C/
William Tanksley
>The illiterate in every language, computer or natural, English or
>German, would prefer to ignore case, just as they would prefer to ignore
>language, yet with no real overhead. Case carries additional
>information for the readers of a language, information that is lost and
>obscured when case is ignored.
Wait a 'mo, though. Information is only carried when there is a choice.
In a case insensitive language I, the programmer, can use capitalization
to convey information to my reader in a way that the compiler won't
notice.
So case insensitivity provides _more_ information-carrying capacity. I've
always wanted to have covert channels in my Python code. I mean, aside
from the comments :-).
But this isn't an argument _for_ case insensitivty, just a dismissal of
your argument against. In fact, I've never seen an argument about which I
cared less. I'm completely case insensitivity insensitive.
>Small is Beautiful
--
-William "Billy" Tanksley
Andrew Henshaw
>
>this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
>
The interesting thing about this is that I could read it. A case-insensitive
compiler couldn't handle a single case flip. That's why I don't understand
the argument that (English-speaking) humans are case sensitive. In general
we're not. We prefer that everyone follow case-usage rules, but we don't
require it. In my opinion, that's the way programming should work. I would
like to read a program that followed case usage for readability; but, I
don't want an interpreter to barf when case is ignored.
If I name a function 'Function', then I'm doing it for readability; but, when
I'm in the interpreter, I want to type 'function'. Particularly because of
its interactive environment, I find the argument for a case-preserving,
case-insensitive Python very compelling.
Andrew Henshaw
Neel Krishnaswami
> ne...@cswcasa.com wrote:
> [snip]
> > I hope (but fear that I'm wrong) that the same is not true of the
> > iteration protocol -- there's a critical need to be able to iterate
> > over trees and linked-lists cleanly. This is IMO more significant
> > than GC or even type-class unification, and it's the major reason I'm
> > rooting for Stackless, since it permits Sather-style coroutine-based
> > iterators to be implemented in Python.
>
> I'd like to see something like that. For other inputs on this and
> other things, I think the algorithms part of C++'s STL may be worth
> investigating (keep the few neat bits, throw away the rest), and for
> a really out there thing I've recently been playing a bit with the
> language K (that is, I've read some of the manual), at www.kx.com
> K's a bit in the style of APL (though I don't know APL). All I've
> been doing is translating some of the operators to Python classes,
> but since I can't think in K yet I haven't accomplished a lot. :)
I've been meaning to learn J or K for a while. My interest was
intiated the language Charity. It was the claim of the Charity authors
that a large subset of interesting programs could be written as
compositions of a fixed set of combinator fns, and that programs
written in this way are much easier to optimize because you can have a
lot of information about the structure of the combinators. Charity is
really a toy language though (numbers are built from Peano's axioms!).
J and K are apparently languages that really stress this, *and* are
real languages, so I'm interested in learning one of them. However,
they look enough like line noise that I've put it off. I shall have to
rectify this RSN...
Neel
Russell Wallace
> The most honest arguments are "case sensitivity feels cleaner" and that
> it "is more popular with existing programmers."
It seems to me that the important argument in this context is "case
insensitivity will break millions of lines of existing code, and perhaps
split the user base if a significant number of existing users refuse to
switch". I can see good arguments either way - overall it doesn't
strike me as a major issue - but I'm dubious about changing it at this
stage.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace
Huaiyu Zhu
>
> "During the course of development, we tried very hard not to
> modify the Python language. /.../ Unfortunately, we were ulti-
> mately forced to abandon pure Python when testing revealed
> two flaws in the language that made Python unusable by our
> target audience: integer math and case sensitivity."
Why is case sensitivity a language barrier for those who don't want it?
If you don't want two cases, choose one and use that one alone.
On the other hand, case insensitivity can be a big headache for people who
need two cases.
> "Python is case sensitive. While we, as programmers, were com-
> fortable with this language feature, our user community suffered
> much confusion over it. At least 85% of users who were observed
> using the Alice tutorial made a case error at some point during the
> experience. While explaining the case rule was simple enough
> ("upper and lower case mean different things to Alice"), this was
> not sufficient to instill a "case aware" sense in our users. Of the
> users who had problems with case, most continued to type case-
> incorrect tokens in their programs for a short period. Coming to
> terms with case sensitivity is a difficult skill for many to learn, a
> fact that can often be lost on experienced programmers."
This quotation alone proves nothing wrong with case sensitivity.
It might just be that Alice uses a difficult or inconsistent style for case.
Have they tried only using lower case for names in Alice?
Have they tried automatic lower case for anything the user entered?
Those who favor case insensitivity seem to argue for two things:
(1) It is really important to write things in different case.
(2) Case should not matter to compilers.
Or is there something else that I missed?
--
Huaiyu Zhu hz...@knowledgetrack.com
JB
case-insensitive would be the worst thing that could happen to the
language in my opinion. I don't want the compiler to change x to X, I
don't want an environment that will change myvar to MyVar. If Guido
wants to make a language for newbies then he should do that and leave
Python as the maturing and 'real' programming language that it is. The
character 'x' is NOT the character 'X' to any machine and to most
humans. Why the hell would you want to pretend that that isn't the case?
Will Rose
: Ben Cornett wrote:
:>
:>this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
:>
: ...snip...
: The interesting thing about this is that I could read it. A case-insensitive
: compiler couldn't handle a single case flip. That's why I don't understand
: the argument that (English-speaking) humans are case sensitive. In general
: we're not. We prefer that everyone follow case-usage rules, but we don't
: require it. In my opinion, that's the way programming should work. I would
: don't want an interpreter to barf when case is ignored.
: If I name a function 'Function', then I'm doing it for readability; but, when
: I'm in the interpreter, I want to type 'function'. Particularly because of
: its interactive environment, I find the argument for a case-preserving,
: case-insensitive Python very compelling.
A lot of people feel as you do; but I, personally, see 'function' and
'Function' as two different tokens, and would be very irritated if a
compiler treated them as identical. I'm afraid that's just the way
I (and others) read code; I don't understand why we got that way, any
more than I understand the attitude that all capitalization is equivalent.
It seems to be some basic difference in reading or comprehension.
OTOH, I'd find a monocase language, either upper or lower case, more
readable than the case-preserving / case-insenstive combination, if
Python has to be simplified for students.
Will
c...@cts.com
Neil Hodgson
possible,
> and case confusion directly goes against peaceful exchanges. The natural
> sloppiness of many people should not get conveyed and imposed to others,
> without Python somewhat imposing its distinct legibility features.
Some of us want 'case insensitivity' to lessen sloppiness by allowing
only one capitalisation of each name.
Neil
François Pinard
> Some of us want 'case insensitivity' to lessen sloppiness by allowing
> only one capitalisation of each name.
Orderly naming of modules is a matter of convention. If the conventions
are inadequate, these might be improved where they need to be. Tainting a
whole language around a few inadequacies would be a gross over-reaction.
Moshe Zadka
> The truth of the matter is that, irrespective of whether or
> not a language is indentation sensitive or not, using inconsistent
> indentation is an extraordinarily bad idea, and
> would be extremely poor engineering practice.
>
> Since Python enforces the indentation issue, but the same philosophy
> it ought to enforce the case issue. And does. :)
Perhaps the behaviour should be case-consistent but not
case-differentiating. I probably managed to lose everyone, so let me
explain:
>>> A=1
>>> a
Traceback (innermost last):
File "<stdin>", line 1, in ?
NameError: a
>>> a=1
Traceback (innermost last):
File "<stdin>", line 1, in ?
NameError: A already exists
(Thanks for Guido for giving me a copy of the binaries of 2003 Python.
This is without the --readable-error-messages switch)
--
Moshe Zadka <mos...@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
Neil Hodgson
> > only one capitalisation of each name.
>
> Orderly naming of modules is a matter of convention. If the conventions
> are inadequate, these might be improved where they need to be. Tainting a
> whole language around a few inadequacies would be a gross over-reaction.
'tainting'? I don't see how I'm corrupting Python. Moshe's example
follows what I want, which is
editWin = CreateWindow()
editwin = editWin.WithToolBar()
to give me a clear error message:
line 2: "editwin" is an incorrect capitalisation of "editWin",
preferrably with a red underline under the 'w' and 'W'
Neil
Tim Peters
> ...
> there are so many more fundamental changes being discussed --
> such as true garbage collection, type/class unification, lexical
> scoping, rich comparisons, strong typing, a new iteration protocol --
> that I'm amazed and a little dismayed that something as relatively
> trivial as case-sensitivity is dominating the discussion.
It's OK to be dismayed, but not amazed: the other things involve hard
technical tradeoffs, while anyone can weigh in on case-sensitivity with
about as much credibility as anyone else (I've kept a complete list of the
scholarly citations presented on this issue, and will embed it in the period
at the end of this sentence <wink>).
> ...
> there's a critical need to be able to iterate over trees and
< linked-lists cleanly. This is IMO more significant than GC or
> even type-class unification,
Opinions vary widely on the relative importance here, of course. Depends on
whether the last program you wrote leaked memory, or drove you nuts trying
to iterate cleanly <0.9 wink>.
> and it's the major reason I'm rooting for Stackless, since it
> permits Sather-style coroutine-based iterators to be
> implemented in Python.
Alas, that won't sell Stackless. My read is that Guido is secretly in favor
of a powerful iterator protocol, but semi-coroutines can be implemented via
much simpler means than Stackless -- even in ways that will work for JPython
too. Stackless needs a killer app unique to it, or to get perceived as a
single solution to several problems as pressing as pleasant iterators.
that-rarest-of-beasts-a-case-sensitive-windows-guy-ly y'rs - tim
Christian Tanzer
Paul Prescod <pa...@prescod.net> wrote:
> I prefer case sensitivity. But I think that most of the arguments people
> make in favor of it are bunk.
Amen. It's just a matter of taste (or mayby acculturation?).
Having used both case-sensitive and case-insensitive languages, I think
its a non-issue. After a day or two, one just doesn't notice anymore.
Personally, I prefer case-sensitivity. Judicious use of case increases
the readability of programs. OTOH, misuse of case leads to horrible
results.
> 1. If you spend time with newbies -- especially Windows-trained newbiews
> -- you will note the case sensitivity is a problem.
>
> 2. Code written in a case insensitive language is roughly as robust and
> readable as that in a case sensitive language.
>
> The most honest arguments are "case sensitivity feels cleaner" and that
> it "is more popular with existing programmers."
IMHO, the problem starts with changing the case policy midstream. I'd
happily accepted a case-insensitive Python when I started to use it.
I'm not amused to have the language changed after two years of intense
programming in it. It'd be a nightmare to check several hundred Python
modules for errors introduced by such a change. The dynamic nature of
Python doesn't help here, either :-(
--
Christian Tanzer tan...@swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
Martijn Faassen
[snip]
> I prefer case sensitivity. But I think that most of the arguments people
> make in favor of it are bunk.
> 1. If you spend time with newbies -- especially Windows-trained newbiews
> -- you will note the case sensitivity is a problem.
I haven't observed this, though I might not've spent time with enough
Windows-trained newbies. Newbies, definitely, though.
> 2. Code written in a case insensitive language is roughly as robust and
> readable as that in a case sensitive language.
"Code written in an indentation insensitive language is roughly as robust
and readable as that in an indentation sensitive language."
Do you, or do you not, agree with that?
> The most honest arguments are "case sensitivity feels cleaner" and that
> it "is more popular with existing programmers."
Yes, just like the way Python uses indentation. :)
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Moshe Zadka
> Hi All--
>
> Ben Cornett wrote:
> >
> > this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
> >
>
> I bet you wrote a Python program to do this, didn't you? Post the code!
#released to the public domain by Moshe Zadka
import sys, string, random
functions = [string.lower, string.upper]
s = sys.stdin.read()
for c in s:
sys.stdout.write(random.choice(functions)(c))
Mikael Olofsson
On 23-May-00 Paul Prescod wrote:
> The most honest arguments are "case sensitivity feels cleaner" and that
> it "is more popular with existing programmers."
CP4EEP - CP4E except programmers...
/Mikael
-----------------------------------------------------------------------
E-Mail: Mikael Olofsson <mik...@isy.liu.se>
WWW: http://www.dtr.isy.liu.se/dtr/staff/mikael
Phone: +46 - (0)13 - 28 1343
Telefax: +46 - (0)13 - 28 1339
Date: 23-May-00
Time: 08:49:23
This message was sent by XF-Mail.
-----------------------------------------------------------------------
Martijn Faassen
> Wait a 'mo, though. Information is only carried when there is a choice.
> In a case insensitive language I, the programmer, can use capitalization
> to convey information to my reader in a way that the compiler won't
> notice.
> So case insensitivity provides _more_ information-carrying capacity. I've
> always wanted to have covert channels in my Python code. I mean, aside
> from the comments :-).
Hm, but this covert channel would be exposed to Python! We can start using
it to build automated tests and parsers, like docstrings! After all,
Py3k's introspection facilities would allow us to examine the case of
a particular method. :)
Martijn Faassen
> Martijn Faassen <m.fa...@vet.uu.nl> wrote:
[snip]
>> I'd like to see something like that. For other inputs on this and
>> other things, I think the algorithms part of C++'s STL may be worth
>> investigating (keep the few neat bits, throw away the rest), and for
>> a really out there thing I've recently been playing a bit with the
>> language K (that is, I've read some of the manual), at www.kx.com
>> K's a bit in the style of APL (though I don't know APL). All I've
>> been doing is translating some of the operators to Python classes,
>> but since I can't think in K yet I haven't accomplished a lot. :)
> I've been meaning to learn J or K for a while. My interest was
> intiated the language Charity. It was the claim of the Charity authors
> that a large subset of interesting programs could be written as
> compositions of a fixed set of combinator fns, and that programs
> written in this way are much easier to optimize because you can have a
> lot of information about the structure of the combinators. Charity is
> really a toy language though (numbers are built from Peano's axioms!).
Right, the same claims are made by the K people, it seems. You can
highly optimize vector operations.
> J and K are apparently languages that really stress this, *and* are
> real languages, so I'm interested in learning one of them. However,
> they look enough like line noise that I've put it off. I shall have to
> rectify this RSN...
One of the applications of K appears to be a database system that is
way more compact and way faster than traditional databases. In fact,
it sounds quite a bit like metakit, in that it's column based. They give
this as an example of the power of K.
K does looks like line noise, though. Very much so. :) And I've found that
Python code is only 3 times as long or so, while being more readable.
(and a lot slower) This from a very limited experiment!
Martijn Faassen
> Ben Cornett wrote:
>>
>>this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
>>
> The interesting thing about this is that I could read it. A case-insensitive
> compiler couldn't handle a single case flip. That's why I don't understand
> the argument that (English-speaking) humans are case sensitive. In general
> we're not. We prefer that everyone follow case-usage rules, but we don't
> require it. In my opinion, that's the way programming should work. I would
> like to read a program that followed case usage for readability; but, I
> don't want an interpreter to barf when case is ignored.
if 1:
print "This is "
print "incorrectly indented"
print "code"
Now let's paraphrase:
"The interesting this about this is that I could read it. A indentation
based compiler couldn't handle a single indentation misalignment. That's why
I don't understand the argument that humans are indentation sensitive. In
general we're not. We prefer that everyone follow indentation-usage rules,
but we don't require it. In my opinion, that's the way programming should work.
I would like to read a program that followed indentation usage for readability;
but, I do'nt want an interpreter to barf when indentation is ignored."
Do you, or do you not, think about Python's indentation system this way?
Martijn Faassen
> On 22 May 2000, Martijn Faassen wrote:
>> The truth of the matter is that, irrespective of whether or
>> not a language is indentation sensitive or not, using inconsistent
>> indentation is an extraordinarily bad idea, and
>> would be extremely poor engineering practice.
>>
>> Since Python enforces the indentation issue, but the same philosophy
>> it ought to enforce the case issue. And does. :)
> Perhaps the behaviour should be case-consistent but not
> case-differentiating. I probably managed to lose everyone, so let me
> explain:
>>>> A=1
>>>> a
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> NameError: a
>>>> a=1
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> NameError: A already exists
> (Thanks for Guido for giving me a copy of the binaries of 2003 Python.
> This is without the --readable-error-messages switch)
While that would throw out the niceness of things like:
foo = Foo()
It would be better than the case insensitive alternative. I think the
point here is that we're already using case to distinguish between
two different things (class versus instance, also between constant
and non-constant), and we'd lose that ability then. Also, I don't think
this would help a lot in the newbie example. Your example might confuse
newbies even more. ("I'm trying to assign to A and now I can't because A
already exists?")
Moshe Zadka
> >>>> A=1
> >>>> a
> > Traceback (innermost last):
> > File "<stdin>", line 1, in ?
> > NameError: a
> >>>> a=1
> > Traceback (innermost last):
> > File "<stdin>", line 1, in ?
> > NameError: A already exists
>
> > (Thanks for Guido for giving me a copy of the binaries of 2003 Python.
> > This is without the --readable-error-messages switch)
[Martijn]
> Also, I don't think
> this would help a lot in the newbie example. Your example might confuse
> newbies even more. ("I'm trying to assign to A and now I can't because A
> already exists?")
Let me re--run the examples with --reable-error-messages:
>>> a = 1
>>> A
NameError: "A" is not a defined name. Perhaps you mea n"a"?
>>> A = 1
NameError: "a" is defined, and "A" differs only by case
Is that understandable enough?
Blake Winton
>Mike Fletcher <mfl...@tpresence.com> wrote:
>I think the problem is not case-sensitive vs. case-insensitive, it's
>case-sensitive/case-preserving vs. case-insensitive/case-preserving.
>I have no problem reading COBOL or early BASIC in monocase (apart
>from the obvious problems of the languages). It's when one token
>can have several different forms that the problems start.
Well, there we go. Perhaps we can have something which is neither
case-sensitive, nor case-insensitive, based on the following principles.
1) Your variables can be named anything you want.
2) Any variable which differs from a preceeding one only by case
generates an error.
It should be _very_ easy to tell which variable generated the error, and
how to fix it, but in order to "encourage" newer programmers to think
more methodically, I feel that the compiler shouldn't make the change
for them. Perhaps the IDE, in beginner mode, would be nicer.
I suppose that's similar to case-sensitive, but I feel it differs in two
main points. Firstly, the error messages would be much nicer to users.
Secondly, people wouldn't get confused by stuff like "abc=aBc", since
the second form would be disallowed.
>It would be nice if the language enforced reasonable default rules,
Something like Java's guidelines?
>I'd suggest enforcing the use of upper or lower case only, rather than
>mixed case. That seems the least bad option; not much more of a
>nuisance than the current whitespace rules.
Speaking as someone who had to use Modula-3, Ugh!
(Modula 3's largest mis-feature, for me at least, was that all keywords
had to be typed in ALL-UPPERCASE. My little finger got really sore
after four months of programming. :P)
Move beyond the C64!
Bill gave us the shift key for a reason, let's use it! ;)
Later,
Blake.
--
7:25am up 31 days, 11:36, 4 users, load average: 1.19, 1.06, 1.02
Martijn Faassen
> [Martijn]
>> Also, I don't think
>> this would help a lot in the newbie example. Your example might confuse
>> newbies even more. ("I'm trying to assign to A and now I can't because A
>> already exists?")
> Let me re--run the examples with --reable-error-messages:
[snip]
> Is that understandable enough?
Yeah, I temporarily forgot about the 'with-readable-error-messages'
flag you mentioned when I posted. Thanks. :)
Still-want-my-"foo=Foo()"-though-ly yours,
Aahz Maruch
<ne...@cswcasa.com> wrote:
>
>Basically, there are so many more fundamental changes being discussed --
>such as true garbage collection, type/class unification, lexical
>scoping, rich comparisons, strong typing, a new iteration protocol --
>that I'm amazed and a little dismayed that something as relatively
>trivial as case-sensitivity is dominating the discussion.
Thing is, I don't think any of these changes directly impacts the "look"
of Python code, particularly at the visceral level. And the "look" of
Python is what sold many of us on the language, *particularly* those of
us who were initially suspicious because of the whitespace
straightjacket.
Computer history is littered with examples of people who took a really
great idea and in the name of "improvement" pushed it in the wrong
direction. I for one would not want to see Guido's name added to that
list.
--
--- Aahz (Copyright 2000 by aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"Not everything in life has a clue in front of it...." --JMS
Radovan Garabik
: ...
:> Oh, and 1/2 might give you
:> a float.
:>
:> Rather minor changes. Then of course..
:>
: Uff, hard hammer that, rather. How do you do integer division, then ? And
I rather like pascal approach with div: 5 div 2 = 2
: what is it good for, anyway ? I mean, what's the advantage of it for
: breaking many exisiting programs ?
hmmm... clearer syntax, less confusing arithmetics?
I agree that the sheer number of existing application outweights these
advantages.
: I'm surely not against improvements in the Python language, but
: 1. case insensitivity sounds like complete nonsense to me. Who needs it,
: actually ?
my words :-)
: 2. promoting integer divisions to float sounds quite stupid to me:
: (x/y) * y + x % y == x should always hold true in any sane language
should it?
or rather:
(x div y) * y + x % y
which is more readable?
I am parsing the first expression as:
take x, divide by y, multiply by y, (that's x again), add x modulo .. oops,
what is the definition of % for real numbers.. oops, what if x and y are
integers... ok, I finally got it!
whereas I parse the second expression as:
take x, do integer division (ok, so x and y have to be integers), multiply by y
(remainder remains) etc etc...
oh, it introduces another keyword... a disaster
/ should not be used for integer division. I consider this a design flaw
(FORTRAN or C suffer from this too, but there it is acceptable, since these
languages were _not_ written to be easily readable).
It should either promote operands to float, or to newly introduced rational
type. Floats have their problems. Rational numbers have their problems.
But float division is useful in physics. Rational division
is useful if you want to have the result as exact as possible, e.g. in
mathematics or logic. Integer division is unnatural, integer numbers are
ring, not field.
If you do some intensive computation in a loop using float division, you end
up with rounding errors.
If you use rational divisions, you face the danger of _really big_
nominators and denumerators, with unexpected overflows, unless you make them
long integers and loose performance...
Which is better default? Hard to decide.... But certainly not integer
division.
: about the optional(!) static typing, good idea. But no new interpunctuation
: or keywords, please!
why not, when it is justified? after all, complex numbers were not in python
from the beginning....
: One reason why i've never learned Perl is that basically every character on
: my keyboard is being used for some builtin variable or one of n ways to
: write down an attribute access. We don't need that in Python.
I fully agree.
Like using / to denote two _completely_ different things: integer division
and float division
Sorry for flaming, I got carried away :-)
--
-----------------------------------------------------------
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__ garabik @ melkor.dnp.fmph.uniba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Andrew M. Kuchling
> this IS An exAmple oF WHat I meaNt WHEn I SAid "vOtIng DoesN'T HElP".
<torgo>
thE masTEr WOuLd nOT aPPrOVe.
</torgo>
There's a reason it's called Python 3000, after all.
--
A.M. Kuchling http://starship.python.net/crew/amk/
Immediately I know that I've been sucked into hell and I can't get out. So
anything that Adam Sandler is in, I just can't help it.
-- Kevin Murphy of MST3K
Andrew M. Kuchling
> Speaking as someone who had to use Modula-3, Ugh!
> (Modula 3's largest mis-feature, for me at least, was that all keywords
> had to be typed in ALL-UPPERCASE. My little finger got really sore
> after four months of programming. :P)
I always liked that feature. Since I usually programmed on a plain
console (still do), there weren't many options for syntax
highlighting. Writing all the keywords in uppercase made program
structure, as opposed to lowercase variable names, leap out at you.
Syntax colouring without colour, in a way.
--amk
François Pinard
> Writing all the keywords in uppercase made program structure, as opposed
> to lowercase variable names, leap out at you. Syntax colouring without
> colour, in a way.
I quite understand. Nowadays, best would be to leave automatic upper casing,
at display time only, being an editor feature, and leave the language alone.
Russell Wallace
>
> bwi...@tor.dhs.org (Blake Winton) writes:
> > Speaking as someone who had to use Modula-3, Ugh!
> > (Modula 3's largest mis-feature, for me at least, was that all keywords
> > had to be typed in ALL-UPPERCASE. My little finger got really sore
> > after four months of programming. :P)
>
> I always liked that feature. Since I usually programmed on a plain
> console (still do), there weren't many options for syntax
> structure, as opposed to lowercase variable names, leap out at you.
> Syntax colouring without colour, in a way.
I remember hating that when doing Modula-2 in college. To me, the
important things are my identifiers, the keywords are plumbing
(especially with a Pascal-family language that uses so damn many of the
things), so shouting the plumbing at me while hiding the important stuff
is the worst possible combination.
(I'd have kept Caps Lock on and at least got equal status for
everything, but that wasn't the style the lecturers used so they'd
probably have marked me down for it.)
Jack-Sprat-would-eat-no-fat-ly-y'rs,
Paul Jackson
richard_chamberlain wrote:
> When we teach our children to write we teach them case sensitivity,
Ah - but we teach them that case is partially context sensitive.
Formal names are always capitalized, but most words are only
capitalized at the start of a sentence.
Can you imagine it being that "light" meant of little weight,
whereas a "LIGHT" was a photon emitter, "LIghT" a stream of
photons, and to "liGHt" something was to set fire to it?
--
Still, I would caution Guido against making too much of the
Alice work. At least in my couple of attempts to introduce
myself and my son to it, it was not particularly compelling
(in contrast to, say, Pokemon), nor intuitive, nor (at least
on my Windows system) stable (that is, it kept crashing).
Granted, I sometimes joke that I dream in 'C', and have to
translate to English for my shrink (which is to say I'm an old
hacker). But in my view there is a difference between coding
programs in an editor, and working in an end user environment.
Perhaps there is someway to enable case INsensitive frontends
to Python 3000, while still working with the current case
sensitivity "under the covers". Sort of like the difference
between having a (mostly) case INsensitive WYSIWYG structured
document composer frontend, over a (somewhat more) case
sensitive XML.
--
That is, instead of thinking of this as a problem of how to
make case INsensitivity palatable to the hackers, rather think
of this as a problem of how to _present_ case sensitivity to
the End User, in a way that is sensitive their natural language
(e.g., English) sensibilities.
... I sense that I should shut up now ...
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
Martijn Faassen
> richard_chamberlain wrote:
>> When we teach our children to write we teach them case sensitivity,
> Ah - but we teach them that case is partially context sensitive.
> Formal names are always capitalized, but most words are only
> capitalized at the start of a sentence.
> Can you imagine it being that "light" meant of little weight,
> whereas a "LIGHT" was a photon emitter, "LIghT" a stream of
> photons, and to "liGHt" something was to set fire to it?
But in fact 'bill' and 'Bill' do have different meanings. There are
more such examples. But in general, there are conventions that have to
do with capitals. In English if something starts with a capital it
may be:
* the starting word of a sentence
* a name
(and probably some other cases)
On the net, all capitals is commonly interpreted as SHOUTING.
In Python there are other conventions, but the principle is the
same. Capitals are used with class names, for instance, while all-caps
are often used for constants. The idiom is different, but the fact
that there *is* a consistent idiom for the use of capitals is similar.
> Still, I would caution Guido against making too much of the
> Alice work. At least in my couple of attempts to introduce
> myself and my son to it, it was not particularly compelling
> (in contrast to, say, Pokemon), nor intuitive, nor (at least
> on my Windows system) stable (that is, it kept crashing).
I can definitely concur with the crashing bit. I never got the
cool 3d drawing extension working on one machine, and on another
machine it worked but seemed to cause crashing. Also that machine
seemed to have nonworking sound, which also caused Alice to crash.
Regards,
Robin Becker
<bwi...@tor.dhs.org> writes
....
>
>Well, there we go. Perhaps we can have something which is neither
>case-sensitive, nor case-insensitive, based on the following principles.
>1) Your variables can be named anything you want.
>2) Any variable which differs from a preceeding one only by case
> generates an error.
I want to maintain full case sensitivity; algebra is taught that way,
English is taught that way; why not Python? I explicitly want to code
stuff like
for s in S:
....
foo = Foo()
initial = INITIAL
I never regarded case insensitivity or otherwise as being anything to do
with the style or otherwise of how variables are named. It's a
convenience that initialValue is slightly more readable than
initialvalue.
The whole argument that, for a short term gain in popularity amongst
toddlers or whatever, you should dumb down a good programming language
seems pretty flawed to me. Give them a dumbed down language and leave
the standard language to be used by more advanced users. Others have
already mentioned the studies on what the correct 'style' of programming
language should be (oo or otherwise).
I started writing with non joined up letters and progressed to cursive
non capitals etc etc. If Python is the CP4E language, just what is the
lower IQ level for inclusion in E?
--
Robin Becker
Andrew Henshaw
>>>
>> The interesting thing about this is that I could read it. A case-insensitive
>> compiler couldn't handle a single case flip. That's why I don't understand
>> the argument that (English-speaking) humans are case sensitive. In general
>> we're not. We prefer that everyone follow case-usage rules, but we don't
>> require it. In my opinion, that's the way programming should work. I would
>> like to read a program that followed case usage for readability; but, I
>> don't want an interpreter to barf when case is ignored.
>
>if 1:
> print "This is "
> print "incorrectly indented"
> print "code"
>
>Now let's paraphrase:
>
>"The interesting this about this is that I could read it. A indentation
>based compiler couldn't handle a single indentation misalignment. That's why
>I don't understand the argument that humans are indentation sensitive. In
>general we're not. We prefer that everyone follow indentation-usage rules,
>but we don't require it. In my opinion, that's the way programming should work.
>I would like to read a program that followed indentation usage for readability;
>but, I do'nt want an interpreter to barf when indentation is ignored."
>
>Do you, or do you not, think about Python's indentation system this way?
>
up here so that I could address it in this same context.
Python's indentation rules provide for instruction grouping. There **must**
be some mechanism to indicate grouping, and indentation fills that need in
Python. If indentation is not used, then block tokens are commonly used.
These are both acceptable solutions to the problem. Your argument
seems to be incomplete in that you haven't provided a replacement solution to
the grouping problem. Given this argument, one must ask "Indentation
provides a reasonable solution to a difficult compilation problem, what
difficult compilation problem is solved by case sensitivity?"
Perhaps your solution to instruction grouping is recognition of grouping by
context. If your carefully chosen example was representative of most code
then I would, perhaps, agree with you. However, if your code stopped with the
second print statement, or was not an artifically-separated sentence, then I
would say that the flow of control was ambiguous.
Andrew Henshaw
Martijn Faassen
> Martijn Faassen wrote:
[snip my indentation argument]
>>Do you, or do you not, think about Python's indentation system this way?
> You've (basically) made this argument in other threads, but I'm glad it showed
> up here so that I could address it in this same context.
Okay. I've been pushing it for a while now to get it into Python's
meme space.
> Python's indentation rules provide for instruction grouping. There **must**
> be some mechanism to indicate grouping, and indentation fills that need in
> Python. If indentation is not used, then block tokens are commonly used.
> These are both acceptable solutions to the problem. Your argument
> seems to be incomplete in that you haven't provided a replacement solution to
> the grouping problem.
Naturally this would be block tokens, indeed.
> Given this argument, one must ask "Indentation
> provides a reasonable solution to a difficult compilation problem, what
> difficult compilation problem is solved by case sensitivity?"
Consistency again. block tokens are the accepted way in almost all
programming languages to group instructions. Python for some reason uses
indentation. What is this reason?
* it looks better (once you're used to it) shorter, just as readable
* we get more consistent indentation practices, as it *matters*
> Perhaps your solution to instruction grouping is recognition of grouping by
> context. If your carefully chosen example was representative of most code
> then I would, perhaps, agree with you. However, if your code stopped with the
> second print statement, or was not an artifically-separated sentence, then I
> would say that the flow of control was ambiguous.
Why do people want case sensitivity?
* it looks better if cases are consistent
* we get more consistent case-spellings, as it *matters*
(the third reason is to be able to have more possible 'names')
I'd still maintain indentation and case-spelling have very many parallels. If
you indeed think that Python would've been just as nice with block tokens,
go ahead and argue for case insensitivity (or whatever you like). If you
however think the indentation rules *add* to Python's readability/consistency,
then most arguments for case insensitivity seem to fall apart.
Les Schaffer
> The whole argument that, for a short term gain in popularity amongst
> toddlers or whatever, you should dumb down a good programming
> language seems pretty flawed to me.
ahh. finally a voice of sanity.
in the latest Python-URL! announcement it was said in regards to case
sensitivity issue:
A few noteworthy posts in the thread:
GvR, on the rationale for the potential change:
http://www.python.org/pipermail/python-list/2000-May/057990.html
So i went to the link and discovered, not one, but two, count em, TWO
"reasons".
1.) Reason number one: young people might learn python better when its
case-insensitive.
2.) Reason number two: Guido gets mail with the words FTPlib and
String in the body of the text.
With overpowering reasons like this from the author of Python and the
one who said this:
> This is an example of what I meant when I said "voting doesn't
> help".
> You're saying it's unacceptable -- a vote. But you don't say *why*
> you vote that way, so your vote gets multiplied by zero
i dread the changes that will be upcoming in the Python community. i
mean, GvR gives us a whole sermonon on how we should be cAREFUL in
expressing the wHYS involved in the debate. Then he sets the level of
the discussion to unimagined lows by virtue of the "reasons" he puts
forward.
i can only venture a guess as to why things are headed this
way. Everyone who codes smells money, IPO money. So they figure if
they can twiddle their language to meet the masses, the unwashed
masses who can't learn case-sensitivity, OR SO THE EXPERTS TELL US,
then there is a fortune to be made.
Absurd notion, right?
But consider this, if python weren't suddenly (maybe thats the wrong
word) emerging as an excellent scripting language at a time when IPO
mania was at its peak (well maybe slightly post peak now), would we be
having these "in-depth" discussions about the optimization of the
langauge via case-insensivity based on towering arguments like 1. and
2. above?
Anyway, tahts as absurd as i can get. i just can't think of any other
reason why the language and newsgroup has to waste its time with a
discussion on case-sensitivity.
disGrunTledly-YOurs
lES sCHAFFER
Will Rose
[...]
: i dread the changes that will be upcoming in the Python community. i
: mean, GvR gives us a whole sermonon on how we should be cAREFUL in
: expressing the wHYS involved in the debate. Then he sets the level of
: the discussion to unimagined lows by virtue of the "reasons" he puts
: forward.
: i can only venture a guess as to why things are headed this
: way. Everyone who codes smells money, IPO money. So they figure if
: they can twiddle their language to meet the masses, the unwashed
: masses who can't learn case-sensitivity, OR SO THE EXPERTS TELL US,
: then there is a fortune to be made.
: Absurd notion, right?
Right.
The people in this newsgroup generally like Python, want Python to be
improved but not broken, and admire Guido's design skills. Hence the
long discussions over various aspects of language internals and
presentation. If you re-read Guido's posts on this specific
change, you'll find that his reasons are nothing to do with IPO money.
(As far as I know, he's working under a government grant of some sort,
but I could well be wrong.) He wants to make the language easier to
use for the inexperienced, which is a laudable aim. It's not clear
exactly how this can be achieved with the least impact on the
expressiveness of the language, and its use by more experienced users.
There are things I like about the current Python, and things I dislike,
and things (like stackless / uthreads) that I hope will be added. (I
doubt, tho', they will be). However, Guido's the final arbiter and he
seems to be doing a superb job; to complain that it's all a question
of possible IPO money seems remarkably mean-spirited.
Will
c...@cts.com
François Pinard
> Anyway, thats as absurd as I can get. I just can't think of any other
> reason why the language and newsgroup has to waste its time with a
> discussion on case-sensitivity.
We live in the terror of the damage to come. If we loose our precious
time into these discussions, this is because we are moved by despair... :-)
I like Python, but I begin to resent Guido, who did this to us.
Aahz Maruch
Les Schaffer <godz...@netmeg.net> wrote:
>
>i can only venture a guess as to why things are headed this
>way. Everyone who codes smells money, IPO money. So they figure if they
>can twiddle their language to meet the masses, the unwashed masses who
>can't learn case-sensitivity, OR SO THE EXPERTS TELL US, then there is
>a fortune to be made.
>
>Absurd notion, right?
Yes, it *is* an absurd notion. And a rather pejorative one, to boot.
Perhaps you should consider an apology?
--
--- Aahz (Copyright 2000 by aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"Yes, but would you kick any of them out of bed?"
"That depends: do we have to do anything with them in the bed, or
are they just in the bed?" -- AM/SJM
Blake Winton
>Neil Hodgson wrote:
>> While I /know/ that Unix file names are case sensitive, that doesn't stop
>> me from mistyping them. This is something Windows and Macintosh do right -
>> removing a cause of error for no real limitation in functionality.
>The Macintosh solution to the problem of mistyped file names
>is not to require users to type file names at all, other than
>when creating the file. That has nothing to do with case
>sensitivity!
Aha! Perfect! We should re-write IDLE, so that for any given variable,
you only type it once, and then whenever you want to use it after that,
you click and drag it to the appropriate place! Genius! ;)
Later,
Blake.
--
1:01pm up 2 days, 5:08, 1 user, load average: 0.00, 0.00, 0.00
Tres Seaver
Paul Prescod <pa...@prescod.net> wrote:
>> However, I am having trouble imagining how removing case-sensitivity from
>> the language could improve usablility for any programmer, regardless of
>> his/her skill level. Most people seem to have no particular trouble with
>> case-sensitivity in natural languages;
>
>If you review the variety of formatting conventions in this list, you'll
>find that that is not the case. Guido himself documented how people
>speak of the String and FTPLib modules and python programming language.
>
>> why should a computer language be any different? On the other hand,
>> maybe I am just too ingrained in my old thought patterns.
>
>I prefer case sensitivity. But I think that most of the arguments people
>make in favor of it are bunk.
>
>1. If you spend time with newbies -- especially Windows-trained newbiews
>-- you will note the case sensitivity is a problem.
>
>2. Code written in a case insensitive language is roughly as robust and
>readable as that in a case sensitive language.
As one who has worked for a long time in a case-insensitive language
(ObjectPascal), I cannot disagree more strongly. ObjectPascal code
which is written by case-neglecting programmers is painful to read,
and harder to maintain. It *also* tends to be sloppier, and therefore
buggier, in other ways (fencposts, etc.)
Case sensistivity provides exactly the same kind of benefit as indentation:
it reduces the space in which individual "style" impacts the code, in order
to increase sharability of code.
Tres.
--
---------------------------------------------------------------
Tres Seaver tse...@digicool.com http://www.zope.org
Digital Creations
Paul Wright
Blake Winton <bwi...@iname.com> wrote:
>On Mon, 22 May 2000 15:30:21 +1200, Greg Ewing wrote:
>>Neil Hodgson wrote:
>>> While I /know/ that Unix file names are case sensitive, that doesn't stop
>>> me from mistyping them. This is something Windows and Macintosh do right -
>>> removing a cause of error for no real limitation in functionality.
>>The Macintosh solution to the problem of mistyped file names
>>is not to require users to type file names at all, other than
>>when creating the file. That has nothing to do with case
>>sensitivity!
>
>Aha! Perfect! We should re-write IDLE, so that for any given variable,
>you only type it once, and then whenever you want to use it after that,
>you click and drag it to the appropriate place! Genius! ;)
Or include the excellent feature in Vim which completes words or lines
using existing occurrences in the same file or in a user defined
dictionary. A decent Unix shell does completion for filenames too, of
course.
--
----- Paul Wright ------| Memes do not exist. Tell your friends.
-paul....@pobox.com--|
http://pobox.com/~pw201 |
Ian Parker
s.net>, Tres Seaver <tse...@starbase.neosoft.com> writes
Tres
I've also worked for a very long time in case-insensitive languages.
I'd thought that I wasn't too bothered either way. However, you've just
persuaded me that case sensitivity probably is better.
--
Ian Parker