On Tue, Jun 23, 2009, Vincent R. wrote:
I wanted to know if you have some patch to compile python 3.x on mingw
platform because I found some but doesn't work very well :
This question belongs on comp.lang.python, please re-post there.
--
Aahz (a...@pythoncraft.com) *
Barry Warsaw wrote:
A quick reminder that I am planning to release Python 3.0.1 this Friday,
February 13.
Cool :)
Should I hold the tracker cleanup until then (the posting part, not
the searching)? I'd hate to bury some important report in a sea of
ancientness.
Daniel
PS: Are you aiming at
On Thu, Feb 12, 2009 at 6:28 AM, Daniel (ajax) Diniz aja...@gmail.com wrote:
Barry Warsaw wrote:
A quick reminder that I am planning to release Python 3.0.1 this Friday,
February 13.
Cool :)
Should I hold the tracker cleanup until then (the posting part, not
the searching)? I'd hate to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2009, at 7:52 AM, Benjamin Peterson wrote:
On Thu, Feb 12, 2009 at 6:28 AM, Daniel (ajax) Diniz
aja...@gmail.com wrote:
Barry Warsaw wrote:
A quick reminder that I am planning to release Python 3.0.1 this
Friday, February 13.
Cool
Just my 2 eurocents:
I think version numbers communicate a couple of things. One thing the
communicate is that if you go from x.y.0 to x.y.1 (or from x.y.34 to
x.y.35 for that matter) you signify that this is a bug fix release,
and that the risk of any of your stuff breaking is close to zero,
2009/1/31 Martin v. Löwis mar...@v.loewis.de:
Notice that bdist_wininst doesn't really work in 3.0. So you likely
won't see many packages until 3.0.1 is released.
Ah, that might be an issue :-)
Can you point me at specifics (bug reports or test cases)? I could see
if I can help in fixing
Can you point me at specifics (bug reports or test cases)? I could see
if I can help in fixing things.
See r69098.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
2009/1/31 Martin v. Löwis mar...@v.loewis.de:
Can you point me at specifics (bug reports or test cases)? I could see
if I can help in fixing things.
See r69098.
Thanks. So 3.0.1 and later will be fine - my apologies, I hadn't quite
understood what you said.
Paul.
Guido van Rossum schrieb:
Frankly, I don't really believe the users for whom those rules were
created are using 3.0 yet. Instead, I expect there to be two types of
users: people in the educational business who don't have a lot of
bridges to burn and are eager to use the new features; and
Aahz aahz at pythoncraft.com writes:
There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
You're probably right that what Raymond wants to is best not done for
3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
production release of Python for PEP6
On 2009-01-30 11:40, Antoine Pitrou wrote:
Aahz aahz at pythoncraft.com writes:
There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
You're probably right that what Raymond wants to is best not done for
3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
2009/1/30 Steve Holden st...@holdenweb.com:
Most consistently missing from this picture has been effective
communications (in both directions) with the user base.
Serious question: does anybody know how to get better communication
from the user base? My impression is that it's pretty hard to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 5:09 PM, Aahz wrote:
The problem is that the obvious candidate for doing the vetting is the
Release Manager, and Barry doesn't like this approach. The vetting
does
need to be handled by a core committer IMO -- MAL, are you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:27 PM, Raymond Hettinger wrote:
The problem is that the obvious candidate for doing the vetting is
the
Release Manager, and Barry doesn't like this approach. The vetting
does
need to be handled by a core committer IMO --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:40 PM, Guido van Rossum wrote:
On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger pyt...@rcn.com
wrote:
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after feature freeze), the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 7:43 PM, Raymond Hettinger wrote:
We should have insisted that bsddb not be taken out until a
replacement
was put in. The process was broken with the RM insisting on feature
freeze early in the game but letting tools like
Paul Moore p.f.mo...@gmail.com wrote:
Serious question: does anybody know how to get better communication
from the user base? My impression is that it's pretty hard to find out
who is actually using 3.0, and get any feedback from them. I suppose a
general query on clp might get some
On Thu, Jan 29, 2009 at 8:25 PM, Raymond Hettinger pyt...@rcn.com wrote:
[Guido van Rossum]
Sorry, not convinced.
No worries. Py3.1 is not far off.
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external
Paul Moore wrote:
Serious question: does anybody know how to get better communication
from the user base?
One of the nice things about Python is that the downloads are truly free
-- no required 'registration'. On the other hand, there is no option
to give feedback either.
If PSF/devs
Serious question: does anybody know how to get better communication
from the user base? My impression is that it's pretty hard to find out
who is actually using 3.0, and get any feedback from them.
I think the bug tracker is a way in which users communicate with
developers. There have been 296
On 2009-01-29 01:59, Stephen J. Turnbull wrote:
I think there is definitely something to the notion that the 3.x
vs. 3.0.y distinction should signal something, and I personally like
MAL's suggestion that 3.0.x should be marked some sort of beta in
perpetuity, or at least until 3.1 is ready to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no
features in micro releases' rule, then fine; but we have to be *really
clear about it*. Are we? (The 3.0 release page calls it
On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
If we intend for 3.0 to be a 'beta release', or to weaken the 'no
features in micro releases' rule, then fine; but we have to be *really
clear about it*. Are we? (The 3.0 release page calls it
production-ready.)
On Thu, Jan 29, 2009 at 8:59
Guido van Rossum wrote:
[...]
Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's always been okay
to add slightly immature features at a major release, as
On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden st...@holdenweb.com wrote:
Guido van Rossum wrote:
[...]
Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's
I think it sets bad precedence to downgrade our confidence in the
release. Again, my position is that it's better to stick to the same
development processes we've always used, fix the most egregious problems
in 3.0.1 with no API changes, but spend most of our energy on a 3.1
release in 6
From: Guido van Rossum gu...@python.org
On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly
Raymond Hettinger wrote:
From: Guido van Rossum gu...@python.org
On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for
On Wed, Jan 28, 2009, M.-A. Lemburg wrote:
Why don't we just mark 3.0.x as experimental branch and keep updating/
fixing things that were not sorted out for the 3.0.0 release ?! I
think that's a fair approach, given that the only way to get field
testing for new open-source software is to
[Aahz]
At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after
On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger pyt...@rcn.com wrote:
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after feature freeze), the bsddb code was
ripped out (good riddance). This had the unfortunate side-effect of
crippling shelves
On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly. OTOH, it is basically a
performance fix for shelves whose API won't change at all. The part that is
visible
and incompatible is that 3.0.1 shelves won't be readable by 3.0.0.
A couple additional thoughts FWIW:
* whichdb() selects from multiple file formats, so 3.0.1 would still
be able to read 3.0.0 files. It is the 2.x shelves that won't be
readable at all under any scenario.
* If you're thinking that shelves have very few users and that
3.0.0 has had few
Raymond Hettinger python at rcn.com writes:
* If you're thinking that shelves have very few users and that
3.0.0 has had few adopters, doesn't that mitigate the effects
of making a better format available in 3.0.1? Wouldn't this
be the time to do it?
There was already another
Raymond Hettinger writes:
My preference is to *not* mark it as experimental.
Don't take the word experimental too seriously. It's clearly an
exaggeration given the current state of 3.0.x. What is meant is an
explicit announcement that the stability rules chosen in response to
the
On Fri, Jan 30, 2009, Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
* If you're thinking that shelves have very few users and that
3.0.0 has had few adopters, doesn't that mitigate the effects
of making a better format available in 3.0.1? Wouldn't this
be the time
Don't take the word experimental too seriously. It's clearly an
exaggeration given the current state of 3.0.x. What is meant is an
explicit announcement that the stability rules chosen in response to
the bool-True-False brouhaha will be relaxed for the 3.0.x series
*only*.
The name for
Martin v. Löwis writes:
Don't take the word experimental too seriously. What is meant
is an explicit announcement that the stability rules will be
relaxed for the 3.0.x series *only*.
The name for that shouldn't be experimental, though. I don't think
it needs any name at all.
On Thu, Jan 29, 2009 at 4:58 PM, Raymond Hettinger pyt...@rcn.com wrote:
A couple additional thoughts FWIW:
* whichdb() selects from multiple file formats, so 3.0.1 would still
be able to read 3.0.0 files. It is the 2.x shelves that won't be
readable at all under any scenario.
* If
[Guido van Rossum]
Sorry, not convinced.
No worries. Py3.1 is not far off.
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external deployment and battle-testing for the module?
Raymond
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves
As Guido said, shelves are *already* fast in 3.0, if you are
using the right operating system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
[Scott David Daniels]
Comparison of three cases (including performance rations):
MB/S MB/SMB/S
in C in py3k in 2.7 C/3k 2.7/3k
** Text append **
10M write 1e6 units at a time261.00 218.000 1540.000
Hello,
Raymond Hettinger python at rcn.com writes:
MB/S MB/SMB/S
in C in py3k in 2.7 C/3k 2.7/3k
** Text append **
10M write 1e6 units at a time261.00 218.000 1540.000 1.20 7.06
20K
2009/1/28 Antoine Pitrou solip...@pitrou.net:
When writing large chunks of text (4096, 1e6), bookkeeping costs become
marginal and encoding costs dominate. 2.x has no encoding costs, which
explains why it's so much faster.
Interesting. However, it's still slower in terms of perception. In
2.x,
Le Wednesday 28 January 2009 11:55:16 Antoine Pitrou, vous avez écrit :
2.x has no encoding costs, which explains why it's so much faster.
Why not testing io.open() or codecs.open() which create unicode strings?
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
Paul Moore p.f.moore at gmail.com writes:
It would be helpful to limit this cost as much as possible - maybe
that's simply ensuring that the default encoding for open is (in the
majority of cases) a highly-optimised one whose costs *don't* dominate
in the way you describe
As I pointed out,
Victor Stinner victor.stinner at haypocalc.com writes:
Le Wednesday 28 January 2009 11:55:16 Antoine Pitrou, vous avez écrit :
2.x has no encoding costs, which explains why it's so much faster.
Why not testing io.open() or codecs.open() which create unicode strings?
The goal is to test
2009/1/28 Antoine Pitrou solip...@pitrou.net:
Paul Moore p.f.moore at gmail.com writes:
It would be helpful to limit this cost as much as possible - maybe
that's simply ensuring that the default encoding for open is (in the
majority of cases) a highly-optimised one whose costs *don't*
Le Wednesday 28 January 2009 12:41:07 Antoine Pitrou, vous avez écrit :
Why not testing io.open() or codecs.open() which create unicode strings?
There is no doubt that io.open() and codecs.open() in 2.x are much slower
than the io-c branch. However, nobody is expecting very good performance
On Wed, Jan 28, 2009 at 4:32 AM, Steve Holden st...@holdenweb.com wrote:
I think that both 3.0 and 2.6 were rushed releases. 2.6 showed it in the
inclusion (later recognizable as somewhat ill-advised so late in the
day) of multiprocessing; 3.0 shows it in the very fact that this
discussion has
Paul Moore p.f.moore at gmail.com writes:
As I pointed out, utf-8, utf-16 and latin1 decoders have already been
optimized
in py3k. For *pure ASCII* input, utf-8 decoding is blazingly fast (1GB/s
here).
The dataset for iobench isn't pure ASCII though, and that's why it's not
as fast.
Ah,
2009/1/28 Antoine Pitrou solip...@pitrou.net:
If you look at how utf-8 decoding is implemented (in unicodeobject.c), it's
quite obvious why it is so :-) There is a (very) fast path for chunks of pure
ASCII data, and (fast but not blazingly fast) fallback for non ASCII data.
Thanks for the
Le mercredi 28 janvier 2009 à 16:54 +, Paul Moore a écrit :
I do think it's worth taking care over the default encoding, though.
Quite apart from performance, getting correct behaviour is
important. I can't speak for Unix, but on Windows, the following
behaviour feels like a bug to me:
On 2009-01-27 22:19, Raymond Hettinger wrote:
From: Martin v. Löwis mar...@v.loewis.de
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
I think it should be released earlier and completely supplant 3.0
before
PS Can anyone comment on why Python defaults to utf-8 on Windows?
Don't panic. It doesn't, and you are misinterpreting what you are
seeing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Paul Moore wrote:
Hmm, I just checked and on Windows, it
appears that sys.getdefaultencoding() is UTF-8. That seems odd - I
would have thought the majority of Windows systems were NOT set to use
UTF-8 by default...
In Python 3, sys.getdefaultencoding() is utf-8 on all platforms, just
as it
print(open(a1).read())
Traceback (most recent call last):
File stdin, line 1, in module
File D:\Apps\Python30\lib\io.py, line 1491, in write
b = encoder.encode(s)
File D:\Apps\Python30\lib\encodings\cp850.py, line 19, in encode
return
2009/1/28 Martin v. Löwis mar...@v.loewis.de:
Paul Moore wrote:
Hmm, I just checked and on Windows, it
appears that sys.getdefaultencoding() is UTF-8. That seems odd - I
would have thought the majority of Windows systems were NOT set to use
UTF-8 by default...
In Python 3,
2009/1/28 Martin v. Löwis mar...@v.loewis.de:
print(open(a1).read())
Traceback (most recent call last):
File stdin, line 1, in module
File D:\Apps\Python30\lib\io.py, line 1491, in write
b = encoder.encode(s)
File D:\Apps\Python30\lib\encodings\cp850.py, line 19, in encode
On Wed, Jan 28, 2009 at 10:29 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Notice that the determination of the specific encoding used is fairly
elaborate:
- if IO is to a terminal, Python tries to determine the encoding of
the terminal. This is mostly relevant for Windows (which uses,
by
Paul Moore wrote:
2009/1/28 Martin v. Löwis mar...@v.loewis.de:
print(open(a1).read())
Traceback (most recent call last):
File stdin, line 1, in module
File D:\Apps\Python30\lib\io.py, line 1491, in write
b = encoder.encode(s)
File D:\Apps\Python30\lib\encodings\cp850.py, line 19,
This a very helpful explanation. Is it in the docs somewhere, or if it
isn't, could it be?
I actually don't know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
2009/1/28 Martin v. Löwis mar...@v.loewis.de:
Well, first try to understand what the error *is*:
py unicodedata.name('\u0153')
'LATIN SMALL LIGATURE OE'
py unicodedata.name('£')
'POUND SIGN'
py ascii('£')
'\\xa3'
py ascii('£'.encode('cp850').decode('cp1252'))
'\\u0153'
So when Python
Steven Bethard wrote:
On Wed, Jan 28, 2009 at 10:29 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Notice that the determination of the specific encoding used is fairly
elaborate:
- if IO is to a terminal, Python tries to determine the encoding of
the terminal. This is mostly relevant for
On Wed, 28 Jan 2009 18:52:41 +, Paul Moore p.f.mo...@gmail.com wrote:
2009/1/28 Martin v. Löwis mar...@v.loewis.de:
Well, first try to understand what the error *is*:
py unicodedata.name('\u0153')
'LATIN SMALL LIGATURE OE'
py unicodedata.name('£')
'POUND SIGN'
py ascii('£')
'\\xa3'
py
Michael Foord wrote:
M.-A. Lemburg wrote:
Why don't we just mark 3.0.x as experimental branch and keep updating/
fixing things that were not sorted out for the 3.0.0 release ?! I think
that's a fair approach, given that the only way to get field testing
for new open-source software is to
On Wed, Jan 28, 2009 at 11:52 AM, Paul Moore p.f.mo...@gmail.com wrote:
Ah, I see. That is entirely obvious. The key bit of information is
that the default io encoding is cp1252, not cp850. I know that in
theory, I see the consequences often enough (:-)), but it isn't
instinctive for me. And
On Wed, Jan 28, 2009 at 1:42 PM, Adam Olsen rha...@gmail.com wrote:
It'd also help if the file repr gave the encoding:
+1
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com
___
Python-Dev mailing list
[Adam Olsen]
It'd also help if the file repr gave the encoding:
+1 from me too. That will be a big help.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Terry Reedy wrote:
Michael Foord wrote:
M.-A. Lemburg wrote:
Why don't we just mark 3.0.x as experimental branch and keep updating/
fixing things that were not sorted out for the 3.0.0 release ?! I think
that's a fair approach, given that the only way to get field testing
for new
Steve Holden wrote:
2.6 showed it in the
inclusion (later recognizable as somewhat ill-advised so late in the
day) of multiprocessing;
Given the longstanding fork() bugs that were fixed as a result of that
inclusion, I think that ill-advised is too strong... could it have done
with a little
It might also be a good idea to take the download link off the front
page of python.org: until that happens newbies are going to keep coming
along and downloading it because it's the newest.
It was (and probably still is) Guido's position that 3.0 *is* the
version that newbies should be using.
2009/1/28 Raymond Hettinger pyt...@rcn.com:
[Adam Olsen]
It'd also help if the file repr gave the encoding:
+1 from me too. That will be a big help.
Definitely. People *are* going to get confused by encoding errors -
let's give them all the help we can.
Paul
Martin v. Löwis writes:
It might also be a good idea to take the download link off the front
page of python.org: until that happens newbies are going to keep coming
along and downloading it because it's the newest.
It was (and probably still is) Guido's position that 3.0 *is* the
Stephen J. Turnbull wrote:
Martin v. Löwis writes:
It might also be a good idea to take the download link off the front
page of python.org: until that happens newbies are going to keep coming
along and downloading it because it's the newest.
By that logic, I would suggest removing 2.6
Terry Reedy wrote:
Stephen J. Turnbull wrote:
Martin v. Löwis writes:
It might also be a good idea to take the download link off the front
page of python.org: until that happens newbies are going to keep
coming
along and downloading it because it's the newest.
By that logic, I
On Tue, Jan 27, 2009 at 11:00 AM, Raymond Hettinger pyt...@rcn.com wrote:
With the extensive changes in the works, Python 3.0.1 is shaping-up to be a
complete rerelease of 3.0 with API changes and major usability fixes. It
will fully supplant the original 3.0 release which was hobbled by poor
From: Guido van Rossum gu...@python.org
In that case, I recommend just releasing it as 3.1. I had always
anticipated a 3.1 release much sooner than the typical release
schedule.
That is great idea. It's a strong cue that there is
a somewhat major break with 3.0 (removed functions,
API fixes,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2009, at 2:05 PM, Guido van Rossum wrote:
On Tue, Jan 27, 2009 at 11:00 AM, Raymond Hettinger pyt...@rcn.com
wrote:
With the extensive changes in the works, Python 3.0.1 is shaping-up
to be a
complete rerelease of 3.0 with API changes
On Tue, Jan 27, 2009 at 11:29, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2009, at 2:05 PM, Guido van Rossum wrote:
On Tue, Jan 27, 2009 at 11:00 AM, Raymond Hettinger pyt...@rcn.com
wrote:
With the extensive changes in the works, Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2009, at 2:39 PM, Brett Cannon wrote:
I was going to object on principle to Raymond's suggestion to rip
out the
operator module functions in Python 3.0.1.
I thought it was for 3.1?
Sorry, I probably misread Raymond's suggestion.
On Tue, Jan 27, 2009 at 1:00 PM, Raymond Hettinger pyt...@rcn.com wrote:
With the extensive changes in the works, Python 3.0.1 is shaping-up to be a
complete rerelease of 3.0 with API changes and major usability fixes. It
will fully supplant the original 3.0 release which was hobbled by poor
At the moment, there are 4 release blockers for 3.0.1. I'd like to see
3.0.1 released soon (within the next month.)
I agree. In December, there was a huge sense of urgency that we
absolutely must have a 3.0.1 last year - and now people talk about
giving up 3.0 entirely.
Releasing 3.1 6 months
On Tue, Jan 27, 2009 at 3:22 PM, Benjamin Peterson benja...@python.orgwrote:
At the moment, there are 4 release blockers for 3.0.1. I'd like to see
3.0.1 released soon (within the next month.) It would fix the hugest
mistakes in the initial release most of which have been done committed
since
On Tue, Jan 27, 2009 at 12:28 PM, Martin v. Löwis mar...@v.loewis.de wrote:
At the moment, there are 4 release blockers for 3.0.1. I'd like to see
3.0.1 released soon (within the next month.)
I agree. In December, there was a huge sense of urgency that we
absolutely must have a 3.0.1 last
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
It sounds like my approval of Raymond's removal of certain (admittedly
obsolete) operators from the 3.0 branch was premature. Barry at least
thinks those
From: Martin v. Löwis mar...@v.loewis.de
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
I think it should be released earlier and completely supplant 3.0
before more third-party developers spend time migrating
Benjamin Peterson benjamin at python.org writes:
At the moment, there are 4 release blockers for 3.0.1. I'd like to see
3.0.1 released soon (within the next month.) It would fix the hugest
mistakes in the initial release most of which have been done committed
since December. I'm sure it
[Benjamin Peterson]
It seems like we are arguing over the version number of basically the
same thing. I would like to see 3.0.1 released in early February for
nearly the reasons you name. However, it seems to me that there are
two kinds of issues: those like __cmp__ removal and some silly IO
My preference is to drop 3.0 entirely (no incompatable bugfix release)
and in early February release 3.1 as the real 3.x that migrators ought
to aim for and that won't have incompatable bugfix releases. Then at
PyCon, we can have a real bug day and fix-up any chips in the paint.
I would fear
The IO-in-C branch cannot be reasonably pulled in release30-maint, but it will
be ready for 3.1.
Even if 3.1 is released in February?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Jan 27, 2009 at 14:31, Martin v. Löwis mar...@v.loewis.de wrote:
My preference is to drop 3.0 entirely (no incompatable bugfix release)
and in early February release 3.1 as the real 3.x that migrators ought
to aim for and that won't have incompatable bugfix releases. Then at
PyCon, we
Raymond Hettinger python at rcn.com writes:
What is involved in finishing io-in-c?
Off the top of my head:
- fix the _ssl bug which prevents some tests from passing (issue #4967)
- clean up io.py (and decide what to do with the remaining Python code:
basically, the parts of StringIO which are
On Tue, Jan 27, 2009 at 4:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
Raymond Hettinger python at rcn.com writes:
What is involved in finishing io-in-c?
Off the top of my head:
- fix the _ssl bug which prevents some tests from passing (issue #4967)
- clean up io.py (and decide what to
Martin v. Löwis martin at v.loewis.de writes:
The IO-in-C branch cannot be reasonably pulled in release30-maint, but it
will
be ready for 3.1.
Even if 3.1 is released in February?
No, unless we take some risks and rush it in.
(technically, it seems to work, but it's such a critical piece
Daniel Stutzbach daniel at stutzbachenterprises.com writes:
Would it be much trouble to also compare performance with Python 2.6?
Here are the results on trunk. Keep in mind Text IO, while it's still `open(r,
filename)`, does not mean the same thing.
=== 2.7 I/O (trunk) ===
** Binary input
On Tue, Jan 27, 2009 at 14:44, Antoine Pitrou solip...@pitrou.net wrote:
Raymond Hettinger python at rcn.com writes:
What is involved in finishing io-in-c?
Off the top of my head:
- fix the _ssl bug which prevents some tests from passing (issue #4967)
- clean up io.py (and decide what to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2009, at 3:48 PM, Martin v. Löwis wrote:
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
It sounds like my approval of Raymond's removal of certain
- fix the _ssl bug which prevents some tests from passing (issue #4967)
I see you've already got a patch for this. I'll try it out.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Martin]
I would fear that than 3.1 gets the same fate as 3.0. In May, we will
all think what piece of junk was that 3.1 release, let's put it to
history, and replace it with 3.2. By then, users will wonder if there
is ever a 3.x release that is any good.
I thought the gist of Guido's idea
1 - 100 of 130 matches
Mail list logo
