New statement proposal for Python

[David LeBlanc]

Alex;

Thanks for your response!

In article <9gclvm02tte at enews1.newsguy.com>, aleaxit at yahoo.com says...
> "David LeBlanc" <whisper at oz.nospamnet> wrote in message
> news:9gbsdv$8ft$9 at 216.39.170.247...
>     ...
> > alias where (argument) substition is done! At least conceptually the body
> > of a function replaces it at invocation time.)
> 
> Fortunately ***NOT***!!!  Such a horrible "conceptual"
> choice for a function-execution model would put pay to
> any chance of *RECURSION*.

Actually so, in fact some languages do just that as a performance 
enhancer, but not worth arguing - nor does it address the original point. 
Arguing against an aside isn't useful. BTW, i'm not english, but I 
believe the expression is "put paid to". I think it came from the days of 
wooden ships when seams in the hull where "paid" (stuffed) with oakum and 
tar. Hmmm.. maybe that's where the expression "get stuffed" came from but 
I digress ;-) (NOT meant personally <g>.)

> > read so nicely to be able to say "if something is true" rather then "if
> > something is not 0" (saves on typing too :-)).
> 
> Such "read so nicely" tests would of course not work as
> expected (with or without alias).  The object None, for
> example, evaluates as false, but if you test its identity
> with 0, you will of course find they're not *identical*
> (how COULD they be -- they're different in every respect,
> the ONLY thing they have in common is evaluating as false!).

Introducing alias does not introduce immunity to incorrect programming. 
It does make easier to correct one line that's substituted 1,000 times 
then it is to substitute all 1,000 lines you did in error.

> It seems to me that the LAST thing we need is encouraging
> "read so nicely" forms that do NOT do what a naive newbie
> might expect.  It is absolutely fundamental that the
> newbie learns to write his/her logical tests as:
>     if something:
>         ...
> and
>     if not something:
>         ...
> and *NOT*
>     if something is 1:
>         ...
> or
>     if something is 0:
>         ...
> or any "aliases" of these flawed forms.

If "naive newbie" makes a programming error he/she is going to make a 
programming error whether or not alias is present. This helps, it does 
not guarantee that you won't make mistakes.

> > Other suggestions to import large libraries or make modules instances are
> > not things calculated to gladden the heart of a newbie who seeks
> > simplicity,
> 
> The module-instance (the const.py example I gave) would of course
> be made by a NON-newbie, the newbie would just USE it.  Why would
> "a newbie who seeks simplicity" consider:
> 
>     const.magic = 23
> 
> less simple than
> 
>     alias magic : 23

It's not less simple - nor is it more complex. Your forgot the "import 
const" bit needed for your part unless one does what you suggest and 
manually add it to the default libraries (which then is loaded by every 
program - I don't know if Python does "lazy loading", so this might not 
be a valid arguement). What fun for a newbie!

The thing that an alias does address that your method does not is that if 
the newbie does "const.magic = 23" and then he/she imports some nice 
module, he/she is not going to be confused by the imported module's 
changing the value of magic...
 
> ?!?!  The former uses exactly the same syntax as any other binding,
> requiring the newbie to learn absolutely no new syntax.  The latter
> requires the newbie to learn one more "simple keyword-statement", with
> a syntax totally different from that of all OTHER simple keyword
> statements.  It seems to me that your claim that all of the extra
> conceptual and syntactical baggage FAVOURS simplicity, when common
> sense suggests extra baggage REDUCES simplicity, is an extraordinary
> claim, and thereby requires extraordinary proof.

What "simple keword" syntax are you referring to? It does follow the idea 
of key : value in dictionaries and that many other statements have one 
part separated from another by a colon.

> > nor would the code enlargement (my aren't I diplomatic ;))
> > win the approval of an experienced developer who doesn't want to search
> > exteraneous lines when a bug pops up - which is statistically more likely
> 
> What "code enlargement" are you talking about?  Which "exteraneous" (?)
> lines?  In a script using "module const" there may or may not be a
> single line
>     import const
> for explicitness (the alternative is having it performed implicitly
> at startup, e.g. by sitecustomize.py &c &c, placing const in the
> __builtin__ module, of course).  That's up to the "experienced
> developer" who decides constants are necessary at his/her site.

Heaven forefend the newbie using what is generally considered good 
programming experience from the start. Let them develop the bad habbit of 
using magic numbers and other obscurities and then, once the bad habbit 
is ingrained, introduce the idea of consts with meaningful names... Wow, 
wish i'd thought of that!. Maybe it was my mistake, but I was under the 
impression that one of Python's objectives was to be a teaching language. 
Better to teach good practice from the start isn't it?

(Sorry, the word is "extraneous" - i'm a prgammer not a dictionary :). I 
actually do spend considerable time on longer posts proofing.)
 
> > with more lines of code, not to mention the antics needed to do something
> > that should be as simple as possible (imho).
> 
> What "antics"?  If you want 'const' to be activated by default
> in every Python installation (e.g. in site.py), write a PEP
> proposing just that.  You DO realize, of course, that no matter
> what little chance such a PEP may have, it IS going to be at
> least a thousand times more likely to be adopted than anything
> that will introduce a new keyword and thereby break perfectly
> working code -- that's something that can *possibly* happen
> only for really momentous developments (such as the new proposed
> "yield" keyword-statement for generators) which DESPERATELY NEED
> a new statement (can't POSSIBLY work halfway-decently without).

Why? Is there something you know about how well new ideas are viewed by 
the core python team that I don't? I guess we'll never see the 
introduction of another Python keyword like... hmm... "do" since it might 
break perfectly working code? I'd be clever here and point out in Latin 
that languages that don't grow die... but I don't know Latin since it's 
dead!

Frankly, while it might not be as DRAMATIC as GENERATORS, in it's own 
quiet way, *I* think it's just as momentuous. (As for "yield" - whatever 
does a generator need yield for? My understanding of generators is that 
they produce a new value based on retained state, not actually generate a 
huge sequence - oops, there I go digressing again.)

I don't see this as anything as earthshaking as introducing nested scope 
which is going to cause far more problems in changing program structure 
(when it becomes the default) then changing the name of an identifier. 
Nor do I think that this is the first new keyword that was introduced 
since the inception of Python - of course, not having done the research 
to find 1.3 or earlier if they're publically available, I won't make such 
a bald statement.

> > One can certainly argue that this is syntactical sugar. It does however
> > serve a multitude of good purposes among which are: maintainability;
> > clarity;  consistancy; correctness; good programming habbits; - a not
> > inconsiderable set of advantages for a little sugar.
> 
> I fail to see ANY of these advantages when comparing your "alias"
> with a "const" module installed by site.py.  How is
>     alias magic : 23
> more maintainable, clearer, more consistent, more correct, or
> a better programming habit than
>     const.magic = 23
> ?!?!  Please bring SOME kind of argument for such extraordinary
> assertions... your bald statements are not "support" for them!

I suggest you read an introductory book on good programming practice. If 
you fail to see any of these advantages, then I shudder to think about 
your code quality. Seriously, please bring SOME kind of argument for 
saying that such notions are NOT a better programming habbit then... etc.

How is your suggestion that a new user:
	1. Figure out how to import a feature that's inherantly available 
in many other programming languages.
	2. Make sure to not ever change any variable meant to be constant.
	3. Figure out why the program won't work when const.magic magically 
changes because they imported a module that changed it without notice or 
warning.
	4. How are you going to ensure that developers are going to 
indentify every "meant to be constant so don't use this identifier as a 
constant" constant that they create? Heck, you can't even get programmers 
to do comments reliably and that's built in now! Forstalling the obvious 
argument, of course there is nothing that ensures that any developer is 
going to practice safe programming and use an alias... this isn't meant 
to legislate against stupidity (who was that king that decreed that the 
tide not come in?) but rather to facilitate doing things more correctly.
any better then what i've proposed?

> > Finally, this wouldn't break any code,
> 
> Puh-LEEZE.  *ANY* use of 'alias' in existing code would be
> broken.  Let's not make such obviously-false assertions...

Yeah, that was my error - of course anyone can use "alias" as an 
identifier. I refer you to my previous remarks with respect to changes in 
Python since the first version, above. At least, unlike the recent furor 
over changing the semantics of "print", this is new.

> Alex

Fred

P.S If you're confused by "Fred", I changed my identifier - oops, did I 
forget to mention that in the docs?

Dave LeBlanc