Posted Aug 31, 2007 22:55 UTC (Fri) by mikachu (guest, #5333)
[Link]
If you click the link, the first sentence that loads is:
"Python 3000 (a.k.a. "Py3k", and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases."
Python 3.0a1 released
Posted Aug 31, 2007 23:01 UTC (Fri) by Lobais (guest, #36605)
[Link]
Fair talk. Anyhow the name shouldn't be the important point.
I think much of what they are doing with the language is nice, like the greater focus on iterators instead of lists. I very much like the "a, b, *rest = iterator" syntax.
However I really don't see the motivation for those print statement changes:
# Also, print and print (x, y) behave differently without warning: the former used to add a newline in 2.x, but does nothing in 3.0; the latter used to print the repr() of a tuple in 2.x, but prints the individual values in 3.0.
# Youll be finding yourself typing print x a lot in interactive mode. Time to retrain your fingers. :-)
I kinda liked the old way, and they refer to no PEP's for the changes. Do you know why they did this?
print and input were warts
Posted Sep 1, 2007 0:42 UTC (Sat) by AnswerGuy (guest, #1256)
[Link]
From an educational perspective, trying to teach Python as a first programming language, print and input/raw_input were warts.
In most languages they are functions --- taking a list of arguments,
possibly returning a value. In Python <3.0 print is a statement. As for input/raw_input --- don't even get me started on that. Let's just say that an "input()" function that defaults to evaluating it's results in your interpreter is a VERY BAD idea for beginning programmers! (I tell students to just add a statement at the beginning of their programs: input=raw_input ... and not to think about it 'til they're ready to learn about evaluation). Additionally print didn't really use sys.stdout consistently ... which causes other problems.
Sure, as idioms for experience programmers this is no big deal. Get used to it and move on. But for trying to teach some of the most basic *and* fundamental principles of programming it's inelegant to have some of the first things you teach be (warty) exceptions to the rest of the design.
I'm glad they made those changes to print and input/raw_input. input (evaluated) is dead, long live input (safe/data oriented)!
JimD
Re: print and input were warts
Posted Sep 1, 2007 8:06 UTC (Sat) by larryr (guest, #4030)
[Link]
for trying to teach some of the most basic *and* fundamental principles of programming it's inelegant to have some of the first things you teach be (warty) exceptions to the rest of the design.
std::cout << "hello world" << std::endl;
woohooo
Larry
Re: print and input were warts
Posted Sep 1, 2007 10:01 UTC (Sat) by rsidd (subscriber, #2582)
[Link]
C++ should not be taught to beginning programmers.
Re: print and input were warts
Posted Sep 1, 2007 11:35 UTC (Sat) by proski (subscriber, #104)
[Link]
Ugly misuse of the bit shift operator for something totally different, attained by overriding operators.
Re: print and input were warts
Posted Sep 1, 2007 14:04 UTC (Sat) by pr1268 (subscriber, #24648)
[Link]
Well, I teach C++ to beginning programmers (as a lab instructor) - I tell the students to put using namespace std; in their programs after the preprocessor statements and then forget about it. This enables them to dispense with the std:: crap each time.
Not that I don't agree with you; some students think C++ is totally counter-intuitive. I learned C before C++ (in 1997) and, IMO it was/is much easier to learn. (After all, it is a much smaller language.)
Adding to this discussion, one of the senior faculty at the university I attend/work at has said that students as young as 4th grade can learn Python (although, I'm still trying to learn it myself!).
Re: print and input were warts
Posted Sep 1, 2007 16:32 UTC (Sat) by asamardzic (guest, #27161)
[Link]
Well, I teach C++ to beginning programmers (as a lab instructor) - I tell the students to put using namespace std; in their programs after the preprocessor statements and then forget about it. This enables them to dispense with the std:: crap each time.
Piece of advice indeed - then why do you think C++ standard library is put into this "crap" namespace at the first place?
Btw, now when Python 3000 seems to materialize after all, let's hope that Perl 6 will soon too...
Re: print and input were warts
Posted Sep 2, 2007 5:35 UTC (Sun) by bronson (subscriber, #4806)
[Link]
> then why do you think C++ standard library is put into this "crap" namespace at the first place?
For 400,000 line behemoths. It certainly was NOT added for the one-page programs beginning programmers write.
Perl 6 Essentials came out 4 years ago! I lost patience last year and unsubscribed from everything. I check back in periodically because I find their work fascinating but really, if Perl6 were tradeable, I'd short it. :)
Re: print and input were warts
Posted Sep 2, 2007 10:13 UTC (Sun) by asamardzic (guest, #27161)
[Link]
> then why do you think C++ standard library is put into this "crap" namespace at the first place?
For 400,000 line behemoths. It certainly was NOT added for the one-page programs beginning programmers write.
Yeah, this seems to be common belief, but I'm not so sure about it. I wear kind of instructor hat too, and my experience is that once you teach them to put using namespace std; there and forget about it, they will never learn what was all about it, and will keep using it this way forever. And I don't think doing it always this way is good practice, also I don't see what's the big problem with explaining what's std:: about, and using it even in simplest code.
Perl 6 Essentials came out 4 years ago! I lost patience last year and unsubscribed from everything. I check back in periodically because I find their work fascinating but really, if Perl6 were tradeable, I'd short it. :)
Agreed completely. Switched to Python (for my script language needs) even before Perl 6 process started (not much because of language per se, but mostly because stuff I'm working with - OpenGL, Open Inventor, Qt, MPI, etc. - has more/better wrappers in Python than in Perl), but followed it with great interest anyway. Especially Parrot was looking like great idea to me, unfortunately there was lots of wandering there too, and Python community wasn't that interested in supporting the idea of common runtime...
Anyway, I think the issue somewhat touched above - that of most appropriate language as first programming language - is very interesting, but also very difficult. C is used for this at my place, and I have mixed feelings about it; on the other side, I'd wholeheartedly agree that C++ is completely inappropriate for something alike. During last time, I'm more and more inclined to think that Python actually may be most appropriate...
Re: print and input were warts
Posted Sep 3, 2007 20:24 UTC (Mon) by chromatic (guest, #26207)
[Link]
... let's hope that Perl 6 will soon too...
How exactly does "hope" help to finish a free software project?
Re: print and input were warts
Posted Sep 3, 2007 22:22 UTC (Mon) by asamardzic (guest, #27161)
[Link]
How exactly does "hope" help to finish a free software project?
Not directly, but - does it hurt either? It wasn't my intention to bash/whine above; while I don't like much the direction it took (please consider that just an opinion of a random guy with a very particular needs and very particular view on alike languages), I'm still crossing my fingers for Perl 6.
Re: print and input were warts
Posted Sep 4, 2007 12:33 UTC (Tue) by niner (subscriber, #26151)
[Link]
The biggest problem with Perl 6 is not that it takes quite some years to develop this new and extremely improved language (it took Perl 20 years to get to the point where Perl 5 is now), it's the expectations that were generated much too early.
Perl 5 is here and it's useful and is still being actively developed. But if you want to use Perl 6, you even can do so today. There are several implementations in varying states of completeness. Much of the new stuff is already working, it's just not all and everything. But it already allows you to develop whatever you want. It's just that there are still some features in the queue that will make it even easier.