New statement proposal for Python

[David LeBlanc]

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*.
> 
> > 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!).
> 
> 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.
> 
> 
> > 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
> 
> ?!?!  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.
> 
> > 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.
> 
> > 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).
> 
> 
> > 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!
> 
> 
> > 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...
> 
> 
> Alex

you mistake a simple example for how something would of necessity be 
done. it could just as esasily be "alias true : not none and not 0"

Of course you would prefer your method...

Ok, so it _might_ break some existing code... so might using const or 
magic or many other words.. such logic suggests that since cobol was 
(probably) the first "high level" language that we should all still be 
using it since to change or add anything might break older stuff.. yeah, 
a somewhat contrived example, but i'm sure you get the idea... maybe 
staying with python 1.3 vs 2.1 would be a better example.

Dave LeBlanc