RELEASED Python 3.0 final
Barry Warsaw
Hash: SHA1
On behalf of the Python development team and the Python community, I
am happy to announce the release of Python 3.0 final.
Python 3.0 (a.k.a. "Python 3000" or "Py3k") represents a major
milestone in Python's history, and was nearly three years in the
making. This is a new version of the language that is incompatible
with the 2.x line of releases, while remaining true to BDFL Guido van
Rossum's vision. Some things you will notice include:
* Fixes to many old language warts
* Removal of long deprecated features and redundant syntax
* Improvements in, and a reorganization of, the standard library
* Changes to the details of how built-in objects like strings and
dicts work
* ...and many more new features
While these changes were made without concern for backward
compatibility, Python 3.0 still remains very much "Pythonic".
We are confident that Python 3.0 is of the same high quality as our
previous releases, such as the recently announced Python 2.6. We will
continue to support and develop both Python 3 and Python 2 for the
foreseeable future, and you can safely choose either version (or both)
to use in your projects. Which you choose depends on your own needs
and the availability of third-party packages that you depend on. Some
other things to consider:
* Python 3 has a single Unicode string type; there are no more 8-bit
strings
* The C API has changed considerably in Python 3.0 and third-party
extension modules you rely on may not yet be ported
* Tools are available in both Python 2.6 and 3.0 to help you migrate
your code
* Python 2.6 is backward compatible with earlier Python 2.x releases
We encourage you to participate in Python 3.0's development process by
joining its mailing list:
http://mail.python.org/mailman/listinfo/python-3000
If you find things in Python 3.0 that are broken or incorrect, please
submit bug reports at:
For more information, links to documentation, and downloadable
distributions, see the Python 3.0 website:
http://www.python.org/download/releases/3.0/
Enjoy,
- -Barry
Barry Warsaw
ba...@python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSTc3pXEjvBPtnXfVAQI69wP/dPHh8IL3GxziEV9QzlveKG+KyZb2X16x
fxJnTCiXAbiAhT5C+m43OEnbF1PJgMDKtcZ5b7aQb4TQ0mJxISTQh0RfLCpArmlo
tdTbzCLnh13KzB+3sUHCx+MeQNXERoWDV8hLz+4Ae71UsuUGynhtyP7ZJMJDue8j
so2gv3fOMSs=
=vkiy
-----END PGP SIGNATURE-----
alex23
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 3.0 final.
Thanks to you and everyone involved for your efforts!
Dotan Cohen
> On behalf of the Python development team and the Python community, I am
> happy to announce the release of Python 3.0 final.
>
Congratulations!
I have been learning Python 2.x while paying strict attention to the
3.x [in]compatibility issue. So, I have been waiting for this day
since I've started with Python!
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
Dotan Cohen
http://www.python.org/download/releases/3.0/
The text "This is a proeuction release" should probably read "This is
a production release". It would give a better first impression :)
Barry Warsaw
Hash: SHA1
On Dec 3, 2008, at 9:13 PM, Dotan Cohen wrote:
> On this page:
> http://www.python.org/download/releases/3.0/
>
> The text "This is a proeuction release" should probably read "This is
> a production release". It would give a better first impression :)
Fixed, thanks!
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSTc/WHEjvBPtnXfVAQL8TwP+M2Ryv7WY36ICEvzGU4EzlRG/gI4MolQe
cD8DJUJfQuR6INTot/t7vTcL8oDHq7q9OHbfvd3jmSwH/ZytsMz2OvJUYlKDQjwG
BcQRpioprcesoU6cufSmKAUiUP+L0RTAMmT0WDbbeCzzMZRq3Humd4Zs43nL26NT
uFb83Dk6yWA=
=qPjn
-----END PGP SIGNATURE-----
James Mills
+1
--JamesMills
--
--
-- "Problems are solved by method"
Ed Leafe
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 3.0 final.
Props to all the folks whose hard work made this possible! You guys
rock!
-- Ed Leafe
Daniel Fetchinson
> am happy to announce the release of Python 3.0 final.
>
uname -a
Linux fetch 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux
tar xzvf Python-3.0.tgz
cd Python-3.0
./configure
make
Failed to find the necessary bits to build these modules:
_tkinter
To find the necessary bits, look in setup.py in detect_modules() for
the module's name.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Chris Rebert
Do you have Tcl/Tk and their dev libs installed? Tkinter is based on Tcl/Tk.
Also, that error isn't fatal, it just means that Tkinter won't be
installed because it can't find the libs.
Cheers,
Chris
--
Follow the path of the Iguana...
http://rebertia.com
> To find the necessary bits, look in setup.py in detect_modules() for
> the module's name.
>
>
> Cheers,
> Daniel
>
>
>
>
> --
> Psss, psss, put it down! - http://www.cafepress.com/putitdown
Daniel Fetchinson
I thought I didn't have to download tcl/tk stuff separately. At least
I never did that for python 2.x but maybe somewhere they are installed
on my box anyway. But why I have this issue with 3.0 I don't quite
get, of course you are right, it's not fatal.
Carl Banks
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 3.0 final.
Congratulations! This is a great day for the Python community.
Carl Banks
Ben Finney
I'm rather disappointed that crucial information was not given in this
announcement: Where is the release party? The public needs to know!
:-)
Congratulations, and thanks to the entire Python team.
--
\ “I used to work in a fire hydrant factory. You couldn't park |
`\ anywhere near the place.” —Steven Wright |
_o__) |
Ben Finney
Iain King
Props. I just looked through the What's New and the change log, but I
couldn't find the answer to something: has any change been made to
how tabs and spaces are used as indentation? Can they still be
(inadvisably) mixed in one file? Or, more extremely, has one or the
other been abolished?
Iain
Gerhard Häring
> [...] Props. I just looked through the What's New and the change log, but I
> couldn't find the answer to something: has any change been made to
> how tabs and spaces are used as indentation? Can they still be
> (inadvisably) mixed in one file? Or, more extremely, has one or the
> other been abolished?
As you have probably guessed: nothing changed here.
Also see: http://www.python.org/dev/peps/pep-0666/
-- Gerhard
Ionut Vancea
On Thu, Dec 4, 2008 at 1:51 AM, Barry Warsaw <ba...@python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> We will continue to
> support and develop both Python 3 and Python 2 for the foreseeable future,
> and you can safely choose either version (or both) to use in your projects.
> Which you choose depends on your own needs and the availability of
> third-party packages that you depend on.
I would like to ask, how long will Python 2 be developed? Just for curiosity.
Thank you for your work.
Cheers,
-
===
Ioan Vancea
http://www.vioan.ro
Istvan Albert
Ionut Vancea
On Thu, Dec 4, 2008 at 1:54 PM, Roy H. Han
<starsareblu...@gmail.com> wrote:
> Hi,
>
> This is great, however, the link to the What's New page appears to be
> broken.
> http://docs.python.org/dev/3.0/whatsnew/3.1.html
replace 3.1 with 3.0 :), so it has to be:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
Cheers,
--
greg
> am happy to announce the release of Python 3.0 final.
Way to go and congratulations!
--greg
J Kenneth King
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 3.0 final.
Yay!
Thanks for all the great work.
bearoph...@lycos.com
> As you have probably guessed: nothing changed here.
> Also see:http://www.python.org/dev/peps/pep-0666/
What? Do you mean it's possible to mix tabs and spaces still? Why?
Bye,
bearophile
Daniel Fetchinson
>> Also see:http://www.python.org/dev/peps/pep-0666/
>
> What? Do you mean it's possible to mix tabs and spaces still? Why?
Why not?
sk...@pobox.com
>>> As you have probably guessed: nothing changed here.
>>> Also see:http://www.python.org/dev/peps/pep-0666/
>>
>> What? Do you mean it's possible to mix tabs and spaces still? Why?
Daniel> Why not?
Because it has historically been a source of errors in a mixed development
environment (people using text editors with different tab stops). Better to
not allow them to be mixed.
Skip
Andreas Waldenburger
<fetch...@googlemail.com> wrote:
> >> As you have probably guessed: nothing changed here.
> >> Also see:http://www.python.org/dev/peps/pep-0666/
> >
> > What? Do you mean it's possible to mix tabs and spaces still? Why?
>
> Why not?
>
+1
--
My real email address is constructed by swapping the domain with the
recipient (local part).
Andreas Waldenburger
Whenever has it been a pythonic ideal to "not allow" stuff? You get
warnings. Everything else is up to you.
/W
sk...@pobox.com
Andreas> Whenever has it been a pythonic ideal to "not allow" stuff? You
Andreas> get warnings. Everything else is up to you.
It's more than warnings. With properly crafted combinations of spaces and
tabs you can get code which looks like it has a certain indentation to the
human observer but which looks like it has different indentation (and thus
different semantics) to the byte code compiler. There is often no warning.
Skip
George Sakkis
Amazing.. was it a conscious decision to keep the current behavior in
3.x or it was not even considered dropping it ?? Does anyone have a
link where this was decided ?
George
"Martin v. Löwis"
>
There won't be a 2.10 release of Python. Whether that means that 2.9
will be the last one, or whether development stops earlier, remains to
be seen.
Regards,
Martin
Roger Vossler
Congratulations to the Python 3.0 team!! Great! I was able to
download the Python 3.0
documentation. Looks good. Any hints when the Mac OSX version of
Python 3.0 will
be available?
Cheers, Roger.....
James Stroud
> On behalf of the Python development team and the Python community, I am
> happy to announce the release of Python 3.0 final.
comp.lang.python3k ?
Ben Finney
> comp.lang.python3k ?
The language has undergone an incompatible divide. Hopefully the
community need not do the same.
--
\ “People come up to me and say, ‘Emo, do people really come up |
`\ to you?’” —Emo Philips |
_o__) |
Ben Finney
bearoph...@lycos.com
> Whenever has it been a pythonic ideal to "not allow" stuff? You get
> warnings. Everything else is up to you.
It's a strong source for bugs, especially for newbies, that I have
hoped to see removed from Python3 (my first request of this was years
ago). I was nearly sure to see this wart removed from Python3, and now
I hear it's presents still. I don't understand why they haven't fixed
it.
Then this is the third thing I don't like of Python3 (the other two
being the removal of automatic tuple unpacking in function signature
and the wart of literals for empty set/dict).
Bye,
bearophile
Andreas Waldenburger
>
> Andreas> Whenever has it been a pythonic ideal to "not allow"
> Andreas> stuff? You get warnings. Everything else is up to you.
>
> It's more than warnings. With properly crafted combinations of
> spaces and tabs you can get code which looks like it has a certain
> indentation to the human observer but which looks like it has
> different indentation (and thus different semantics) to the byte code
> compiler. There is often no warning.
>
I just looked at "python --help", it seems that there is no warning per
default.
My point is: If you mix tabs and spaces in a way that breaks code,
you'll find out pretty easily, because your program will not work. It's
your choice, and I think it's pretty nice that Python lets you
choose. After all, some people are of the "indentation for structure,
spaces for alignment" faction. Why make their life harder?
bearoph...@lycos.com
> My point is: If you mix tabs and spaces in a way that breaks code,
> you'll find out pretty easily, because your program will not work.
- Most newbies don't know that.
- Sometimes it may produce wrong results.
- And even if you are an expert when you go changing a little a source
code that mixes tabs and spaces you usually break the code.
Is this enough for you?
Bye,
bearophile
Andreas Waldenburger
No.
While you are right on all accounts, forcing uniformity would still
interfere with (some) people's coding styles, "wrong" as they might be.
Python is not Gnome.
Maybe having Python issue warnings for inconsistent whitespace per
default might be a good idea. But that's about as far as I would go.
Peter Pearson
>
> It's more than warnings. With properly crafted
> combinations of spaces and tabs you can get code which
> looks like it has a certain indentation to the human
> observer but which looks like it has different indentation
> (and thus different semantics) to the byte code compiler.
> There is often no warning.
Fascinating. Has anybody developed demo code that looks,
during code review, as if it prints a Snoopy calendar, but
really, during execution, emails your password file to
Minsk? The security implications are intriguing. What's the
most underhanded thing anybody has seen done?
--
To email me, substitute nowhere->spamcop, invalid->net.
Terry Reedy
> Andreas Waldenburger:
>> Whenever has it been a pythonic ideal to "not allow" stuff? You get
>> warnings. Everything else is up to you.
>
> It's a strong source for bugs, especially for newbies, that I have
> hoped to see removed from Python3 (my first request of this was years
> ago). I was nearly sure to see this wart removed from Python3, and now
> I hear it's presents still. I don't understand why they haven't fixed
> it.
Did you or someone fine a specific rejection of disallowing mixture in
3.0, or did no one specifically suggest it and offer to make the change?
Fernando H. Sanches
Python has "not allowed stuff" for a long time.
For example, it disallows statements in lambdas.
"Disallowing" is not bad. Disallowing bad practices (like mixing tabs
and spaces) is actually good!
I agree that the tab/space thing should be changed. Would it be too
hard to make the parser see if the indentation is consistent in the
whole file? This is a annoying source of problems, specially since you
can't tell a whitespace from a tab just looking at it.
And I personally disliked most of the changes (specially the ones on
map and reduce). I hope functional programming doesn't get even more
hindered in future releases, because I believe these changes only made
Python weaker.
Well, anyway, congratulations for everyone for Python 3 release. Some
of the changes were a real improvement (like the Unicode sources). And
I hope that, in the end, these changes help making Python a better
language.
Andreas Waldenburger
<fernando...@gmail.com> wrote:
> On Dec 4, 5:45 pm, Andreas Waldenburger <geekm...@usenot.de> wrote:
> > On Thu, 4 Dec 2008 11:52:38 -0600 s...@pobox.com wrote:
> > [snip]
> > Whenever has it been a pythonic ideal to "not allow" stuff? You get
> > warnings. Everything else is up to you.
> >
> > [snip]
>
> Python has "not allowed stuff" for a long time.
>
> For example, it disallows statements in lambdas.
>
Which is sensible (for Python) because it does not have block
delimiters.
Also, lambdas are syntactic sugar for special use cases. It's not
like they are needed at all. But sometimes mixing tabs and spaces can
be needed (think coding standards).
What else is disallowed?
> "Disallowing" is not bad. Disallowing bad practices (like mixing tabs
> and spaces) is actually good!
>
This presupposes that mixing tabs and spaces is "bad". That's like
saying C++ is bad.
> I agree that the tab/space thing should be changed. Would it be too
> hard to make the parser see if the indentation is consistent in the
> whole file?
Maybe not, but it would be rather hard to agree on what can be
called consistent and what can not, I think. You can mix spaces and
tabs consistently, just as you can use any one consistently.
> This is a annoying source of problems, specially since
> you can't tell a whitespace from a tab just looking at it.
>
There are editors that let you show different symbols for spaces and
tabs (I know, I know ...).
> And I personally disliked most of the changes (specially the ones on
> map and reduce). I hope functional programming doesn't get even more
> hindered in future releases, because I believe these changes only made
> Python weaker.
>
+1
Steven D'Aprano
> Andreas Waldenburger:
>> Whenever has it been a pythonic ideal to "not allow" stuff? You get
>> warnings. Everything else is up to you.
>
> It's a strong source for bugs, especially for newbies, that I have hoped
> to see removed from Python3 (my first request of this was years ago). I
> was nearly sure to see this wart removed from Python3, and now I hear
> it's presents still. I don't understand why they haven't fixed it.
"It"? Context please... snipping unnecessarily quoted text is a good
thing, but please leave enough context for people to know what you're
talking about.
I think you're talking about mixed spaces/tabs in the one module.
Frankly, I question just how "strong" a source of bugs it really is. Oh,
I don't doubt that there are circumstances where it can cause bugs, but I
don't remember the last time the solution to some newbie's problem on
comp.lang.python was "use spaces or tabs but not both". My gut feeling is
that you have to have a fairly unusual set of circumstances before it
causes actual bugs.
So perhaps nobody on the python-dev team have fixed it yet because nobody
cares enough to do the work, or it's unexciting and tedious to fix. Or
maybe python-dev *think* they've fixed it, and the fact that it isn't
fixed is a bug that needs reporting.
> Then this is the third thing I don't like of Python3 (the other two
> being the removal of automatic tuple unpacking in function signature and
> the wart of literals for empty set/dict).
Er, what do you mean? What wart?
--
Steven
Steven D'Aprano
> Fernando H. Sanches <fernando...@gmail.com> wrote:
>> And I personally disliked most of the changes (specially the ones on
>> map and reduce). I hope functional programming doesn't get even more
>> hindered in future releases, because I believe these changes only made
>> Python weaker.
>
> The functional programming aspect of Python is one of my favorite parts,
> having a mixed background in functional/non-functional languages.
map is still a built-in.
reduce is moved to functools.
I think the only change to map is that instead of returning a list, it
returns an iterator. What this means is that Python's functional
programming aspect is now lazy, and that's a good thing.
--
Steven
Aahz
Ben Finney <bignose+h...@benfinney.id.au> wrote:
>James Stroud <jst...@mbi.ucla.edu> writes:
>>
>> comp.lang.python3k ?
>
>The language has undergone an incompatible divide. Hopefully the
>community need not do the same.
Pish and tosh. James was clearly making a funny; there's not *that* much
difference between 2.x and 3.x.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Ben Finney
> In article <874p1ju...@benfinney.id.au>,
> Ben Finney <bignose+h...@benfinney.id.au> wrote:
> >James Stroud <jst...@mbi.ucla.edu> writes:
> >>
> >> comp.lang.python3k ?
> >
> >The language has undergone an incompatible divide. Hopefully the
> >community need not do the same.
>
> Pish and tosh. James was clearly making a funny; there's not *that*
> much difference between 2.x and 3.x.
You appear to assume I was not going along with the funny. To be
expected, I suppose, given the well-documented context lossage in a
message-based medium.
I hereby recommend “pish and tosh” for use by anyone who wants to
counter someone's point. It beats by a country furlong the invective
that has become regrettably common here in recent months.
--
\ “I was once walking through the forest alone and a tree fell |
`\ right in front of me, and I didn't hear it.” —Steven Wright |
_o__) |
Ben Finney
bearoph...@lycos.com
>I think you're talking about mixed spaces/tabs in the one module.<
Right.
>My gut feeling is that you have to have a fairly unusual set of circumstances before it causes actual bugs.<
I don't mix tab and spaces in my code, and my editor is able to
convert them, so after the first few days of Python coding, it more or
less never caused me problems.
But such thing in code written by others has caused me enough
troubles, I am generally unable to edit such code keeping it
functional, so I have to (sometimes by trial and error) convert it to
a space only (or tabs only) format.
Such troubles aren't that large compared for example to the usual
troubles I receive writing and comping C++ code, but enough compared
to the usual smoothness of coding in Python :-)
>Er, what do you mean? What wart?<
Not using {:}/{} as literals for empty dict/set.
Bye,
bearophile
Hendrik van Rooyen
"Ben Finney" <bignose+h...@benfinney.id.au> wrote:
>I hereby recommend “pish and tosh” for use by anyone who wants to
>counter someone's point. It beats by a country furlong the invective
>that has become regrettably common here in recent months.
I second the motion to use pish and tosh for a first level of disagreement.
I recommend the rather archaic "Balderdash" as the next step in the
escalation of disagreement...
- hendrik
Dotan Cohen
> I second the motion to use pish and tosh for a first level of disagreement.
>
> I recommend the rather archaic "Balderdash" as the next step in the
> escalation of disagreement...
>
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
Mensanator
As a W.C. Fields fan, I love his "non-swearing"
vocabulary:
- Drat
- Dag nab it
- Holy Mother of Pearl!
etc.
>
> - hendrik
MRAB
But don't say B*****m. :-)
http://www.bbc.co.uk/cult/hitchhikers/guide/belgium.shtml
William McBrine
> I agree that the tab/space thing should be changed. Would it be too hard
> to make the parser see if the indentation is consistent in the whole
> file?
*Something* has changed. I had a piece of code where, without realizing
it, I had a tab mixed in with the spaces at the start of one line in a
block. In 2.5, it worked, silently. In 3.0, I got an indentation error.
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- pass it on