[Python-3000] Q's 2 U's; Perceptions, growing into langs

[Linda W.]

>  Care to give any examples of 'unbeautifying' other than the print

> statement -> print function conversion?
???Care to?...not really :-)  I __really__ am not familiar enough with 
python, let alone the differences between the versions.
I tried to find a concise list of differences, but while I found long 
descriptions that were readable, I wasn't finding a full set of 
differences -- but part of that was, I believe, the incremental way Py3 
as been developed. 

I may be projecting more about my differences on perl versions than python.

> I would tend to disagree that the new print function is less "pretty" 
> - I've actually found it to be more consistent and 'pretty' within the 
> language. But YMMV.
----  
Ahhh....welll you know what they say, beauty is in the eye of the 
beholder. One of the things I thought was attractive about python is its 
cleanness -- from the perspective of it being nearly opposite of perl 
(which I like alot, BTW, so not trying to rag on it).  In that I mean 
how perl has more than once been described by some as looking like 'line 
noise'...:-)

>> As to what I think will happen with adoption of Python 3... I think 
>> 2.x and 3.x will coexist quite happily for a number of years (at 
>> least until a 2.7 release, possibly even a 2.8).
----
   That's what the perl folk claim somewhat of Pl5/Pl6.  But I was 
around for the Pl3-Pl4, Pl4-Pl5 transitions...I know Pl3 and Pl4 code 
could easily, often with no changes, run under Pl5 --  but Pl6 -- wish 
the creator when with a different language name so
Pl5 could evolve to fill in its gaps and holes -- but naming the new 
language is "Pl6" was intentional on L'Wall's part -- he specifically 
said he wanted to get the notoriety associated with Perl5 associated 
with his new language.  Also, IMO, deliberately or not, I think it is 
meant to bring a none-too-subtle end to Pl5 as a living, developing 
language.   But maybe Larry really reached the end of his creative 
'ropes' in trying to evolve Pl5 and just gave up the ghost by going with 
a new lang.

   Took me years before I started actually using Pl5-features like the 
object orientation (most of my p4 work had been mostly using it as a 
quick script/filter language).  When I sat down to actually try to use 
Pl5's OO features and use it as a higher-level lang (and not just a 
scripting lang), I began to run into its limitations -- and things I 
missed about high-level langs that seem to be more limited to compiled 
languages...  

I'm happy to hear there isn't the same type of schism in the Python 
community -- sounds like most things should just continue to 
'evolve'...with, what it sounds like, more 'gentle' paths to grown 
between the levels.  Hopefully Python won't hit the wall in another 8-12 
years and need a similar restart.  But we all  know what happens when 
you hang too much on to past compatibility -- you get Windows (and 
become some of the richest people on the planet...)...  compatibility 
over 'new' or 'better' seems to be what the market favors (even though 
it agreeably may not be the best technical choice).  But such are the 
limitations of a 'free market system'... 

It seemed like some of Py3's development and feature changes happened 
over a long time -- but not sure where they came from, where pl6 -- 
seems to be a complete semantic and source rewrite.  Not that the end 
result may not be good, but neither is it remotely pl5 compatible.

I do keep nudging at getting into doing something with python other than 
'hello universe', but I love all the 'verbs' in perl -- and having alot 
of experience in the environment many of those 'verbs' came from (unix 
cmd-line tools), it just feels natural to optimize 'shell' tasks into 
perl scripts... 

   But that's the area of perl-shine.  quick scripts that I can build 
up via repetitive re-edits of a previous 'line' -- under 'bash', 
(cmdline): execute, see if I am getting output I want from whatever the 
input was, no?  ESC, edit line, try again -- can have an entire little 
'1-line filter (multistatements)'.  Usually throw-aways...but if useful 
enough, can write them to a file to save and/or do proper indenting on 
them.  .

I miss that type of interactive development on the cmdline with python.  
Any thought ever been given to  allowing a cmd-line friendly syntax?  
I'm not wanting an attack or religious discussion here, BTW (**1).  But 
was thinking along the lines of something where statements could be 
separated by semi's (or embedded newlines) and indentation could be done 
using braces.
Something like (in 'bogo'-syntax):
<pipein>|\
py -e 'e=sub(x,y){x**y}; while((x,y)=<inline>) { outln (x  "**" y " = " 
e(x,y) ) }' |\
<etc>
....
I can't speak for everyone, but as someone who uses the cmdline "alot", 
it would make it much easier for me to learn and try out python "little 
bits" a time...from the cmdline...
little filter here, little filter there...etc.  then maybe they grow.  
Could even have a
python 'pretty printer' that got rid of all curly brackets and replaced 
them with
a user-specifiable amount of indentation.  The reverse might have other 
uses...dunno...

Certainly would provide a *less-steep* learning curve if one could start 
with 1-liners on the cmdline.  Not that I'd want to be able to play 
with/ and start using little snippets till I got
more comfy with syntax and standard libraries.

Perhaps I don't need to say it -- but going into a 'mode' (like a python 
interpreter
with a prompt) doesn't count as cmd-line usage.  You've still entered a 
non-command
line, special environment.


> >> BTW -- is there a CPyAN similar to perl's CP[l]AN?  Curious. <<<


Like someone said in the replies -- this list may not be the best place 
to get 'balanced' input.  Certainly -- as I *stress*....not looking to 
start 'arguments' or such...just getting input/'vague' impressions...

   Thanks for the feedback...I "hope" it was representative of the bulk 
of the Pythonisti (pythonistae?) :-) (pythonistas sounds too much like a 
south-american terrorist group... :-)

Linda

(**1) - not wanting a religious discussion here on the pluses/minus of 
enforced
   syntax. I admit, the last time I programmed in a language where 
white-space
   and columns were meaningful and essential was in a a college course 
running
   on a mainframe where the standard input was a punched cards).