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).
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
