Weekly Edition
Return to the Development page
| |||||||||||||||||||
Python 3.0a1 released
The release is available from http://python.org/download/releases/3.0/ I'll send a longer announcement to python-list and python-announce-list. Please blog about this if you have a blog! Thanks to all who helped out! It's been a great ride. -- --Guido van Rossum (home page: http://www.python.org/~guido/) (Log in to post comments)
Python 3.0a1 released Posted Aug 31, 2007 14:03 UTC (Fri) by jdahlin (subscriber, #14990) [Link] It will be interesting to see the adoption rate of Python 3.0, it's a safe bet that we still have to care about 2.x for the next couple of years.
Python 3.0a1 released Posted Aug 31, 2007 16:39 UTC (Fri) by Lobais (guest, #36605) [Link] Nooo! What happened to Python 3000? Perhaps the joke died after Windows 2000 got deprecated, but it still sounds much more original than 3.0.
Python 3.0a1 released Posted Aug 31, 2007 16: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 17: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.
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 Aug 31, 2007 18:42 UTC (Fri) by AnswerGuy (subscriber, #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,
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 2: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 4: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 5: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 8: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 10:32 UTC (Sat) by asamardzic (subscriber, #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 1, 2007 23:35 UTC (Sat) 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 4:13 UTC (Sun) by asamardzic (subscriber, #27161) [Link]
> then why do you think C++ standard library is put into this "crap" namespace at the first place?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 14:24 UTC (Mon) by chromatic (subscriber, #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 16:22 UTC (Mon) by asamardzic (subscriber, #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 6: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.
print statement replacement (Python 3.0a1 released) Posted Sep 4, 2007 6:37 UTC (Tue) by elr (subscriber, #17404) [Link] See PEP 3105 for a distillation of the history of this change.
Python 3 should include namespace for libraries and a CPAN repo Posted Aug 31, 2007 17:18 UTC (Fri) by dag- (subscriber, #30207) [Link] What I think is really missing in the python world is a proper namespace and collection for python modules (that is protected by an organisation).
In other words, a CPAN for python.
As a packagers it is still a big problem to package pySomething, pySOMETHING, python-SomeThing or Something. We convert this to fit into the python-something (lowercase) namespace, but still other packagers use the upstream name or something else (eg. python-pySomething).
Having an organisation take care of the namespace and manages the collection as a whole will further help to advance the python community as a while. Whereas now I have seen different modules being developed in parallel which divides the effort.
Python 3 should include namespace for libraries and a CPAN repo Posted Aug 31, 2007 18:11 UTC (Fri) by ArbitraryConstant (guest, #42725) [Link] meh
I find CPAN to be far too fickle and complex. Whenever possible, I'll use an OS's package manager instead. Which as it turns out is the same thing I do for Python, C libs, and pretty much anything else.
Python 3 should include namespace for libraries and a CPAN repo Posted Sep 1, 2007 7:03 UTC (Sat) by peace (guest, #10016) [Link] What I think Dag is saying is that the reason your package manager gets Perl right is that the Perl community has made it easy for package managers to package Perl modules. You may not like CPAN proper but is does apply a consistency to Perl modules that Python lacks.
As for cheese shop, close only cuts it if packagers such as Dag can rely on it in the same way that they can CPAN. Meaning it's Comprehensive and up to date.
Python 3 should include namespace for libraries and a CPAN repo Posted Sep 1, 2007 13:03 UTC (Sat) by ArbitraryConstant (guest, #42725) [Link] > What I think Dag is saying is that the reason your package manager gets> Perl right is that the Perl community has made it easy for package managers > to package Perl modules.
If that's so, then why does the package manager get Python/C/etc right as well?
Particularly given that CPAN sometimes needs external C libraries, I think it's appropriate to delegate the task to package managers.
Python 3 should include namespace for libraries and a CPAN repo Posted Sep 4, 2007 12:20 UTC (Tue) by jdivine (subscriber, #18042) [Link] Anecdotally, fewer Python packages seem to be available through native package managers, possibly because CPAN makes it easier to find and package the Perl modules.
Whenever possible, I install Perl or Python packages (all software in general, really) through the OS's package manager. That said, it's not always possible:
- the package might not be provided
I use Python more than Perl these days and I really miss Python's lack of a CPAN equivalent. CheeseShop and easy_install don't match up at all.
Python 3 should include namespace for libraries and a CPAN repo Posted Aug 31, 2007 20:04 UTC (Fri) by zooko (subscriber, #2589) [Link] The closest thing to CPAN is the Python Cheese Shop:
Python 3 should include namespace for libraries and a CPAN repo Posted Sep 1, 2007 13:33 UTC (Sat) by chrism (subscriber, #4713) [Link] More importantly, easy_install (http://peak.telecommunity.com/DevCenter/EasyInstall), which ispart of setuptools is willing to attempt to install any package that's on PyPi (aka the cheeseshop) as well as its dependencies if any. E.g.::
[chrism@kingfish chrism]$ easy_install dateutil
Installed /Users/chrism/opt/Python-2.4.3/lib/python2.4/site-packages/dateutil-1.2-py2.4.egg
|
|||||||||||||||||||