gratuitous new features in 2.0

[Roy Katz]

Absolutely agreed!

I don't understand for the life of me where people get off proposing (with
a straight face) the addition of 'in', 'to', '>>', or what ever else can
form a neat little grammatically correct sentence.  

Consider!:

*  'in' is used in the context of a boolean comparison;  for example,
   "1 in [1,2,3,4,5]" yields true, whereas "1 in [2,3,4,5]" is not. 

   what is the *point* of overloading this operator over the pring
statement? just so we can have a cute little "print in file, data"?
To me, this looks like a comparison.  IS print IN file? 

*  The addition of 'to' strikes me as precarious because its use is valid
only in the context of 'print'.  IMHO,  it smacks of the same inelegance
as the statement 'fron ... import *', or 'def func( *k, **kw )' and
any other statement which 'overloads' existing operators).  

*  What was ever wrong with sys.stdout.write('...')?
if you have a file open, just use its .write() method.  What was ever
so deficient about that statement as to necessate anything like a >> or a
'to' or an 'in' (or any other orderliness-breaking extension of grammar)?


That last point is what especially concerns me.  C++ is full of these
one-context throw-away grammatical oddities such as 'unsigned short
BIT_FIELD_NAME:   N' (the colon) and 'using namespace ...' (could you
*ever* put anything other than 'namespace' in the 'using'
declaration??) 

I believe the question can be summed thusly:  IS extending the grammar
(and possibly polluting it) worth reaching that extra perl (or
newbie) programmer? 


Roey Katz


On Fri, 25 Aug 2000, Neil Hodgson wrote:

> > Of the alternates proposed, "to" (which has problems with not currently
> > being a keyword, and thereby introducing some potential for code breakage,
> > but is the most intuitive word) or "in" seem the clearest.
> 
>    There has been a proposal that "to" be a keyword only in the context of
> the print statement. This is part of a wider movement towards context
> sensitive keywords in some change proposals. The renaming import proposal
> "import urllib as myurl" uses "as" in this context sensitive way.
> 
>    I don't like this trend myself but maybe that's just because I may have
> to modify some Python lexing code. I can understand the frustration caused
> by not wanting to introduce any new global keywords because they may break
> any code that uses that keyword as an identifier.
> 
>    Neil
> 
> 
> 
>