Re: [Python-Dev] Python 3.0.1 and mingw

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) <*> htt

[Python-Dev] Python 3.0.1 and mingw

Hi, 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 : > make gcc -o python.exe \ Modules/python.o \ libpython3.0.a-lm Could not find platform independent libraries Could not find platform dependent libraries C

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

-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 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

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

On Thu, Feb 12, 2009 at 6:28 AM, Daniel (ajax) Diniz 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 bury some

Re: [Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

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

[Python-Dev] Python 3.0.1 planned for this Friday, Feb 13

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A quick reminder that I am planning to release Python 3.0.1 this Friday, February 13. Thanks to y'all's hard work, we have no showstopper bugs at the moment. The 3.0 buildbots look mostly clean and green. If we can keep it this way for about

Re: [Python-Dev] Python 3.0.1

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 d

Re: [Python-Dev] Python 3.0.1

2009/1/31 "Martin v. Löwis" : >> 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. ___

Re: [Python-Dev] Python 3.0.1

> 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: htt

Re: [Python-Dev] Python 3.0.1

2009/1/31 "Martin v. Löwis" : > 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 things. Paul. _

Re: [Python-Dev] Python 3.0.1

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, unle

Re: [Python-Dev] Python 3.0.1

> 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 2

Re: [Python-Dev] Python 3.0.1

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 wan

Re: [Python-Dev] Python 3.0.1

On Thu, Jan 29, 2009 at 8:25 PM, Raymond Hettinger 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 deploymen

Re: [Python-Dev] Python 3.0.1

> Paul Moore 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 feedback, but otherwi

Re: [Python-Dev] Python 3.0.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 8:34 PM, Stephen J. Turnbull wrote: I think that the important question is "can the 3.0.x series be made 'viable' in less than the time frame for 3.1?" If not, I really have to think it's DOA from the point of view of folks who

Re: [Python-Dev] Python 3.0.1

-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 bsd

Re: [Python-Dev] Python 3.0.1

-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 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

Re: [Python-Dev] Python 3.0.1

-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 -- MA

Re: [Python-Dev] Python 3.0.1

-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 v

Re: [Python-Dev] Python 3.0.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 1:13 PM, Guido van Rossum wrote: I'd like to find a middle ground. We can all agree that the users of 3.0 are a small minority compared to the 2.x users. Therefore I think we can bend the rules more than we have done for the rece

Re: [Python-Dev] Python 3.0.1

2009/1/30 Steve Holden : > 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 find out who is actu

Re: [Python-Dev] Python 3.0.1

On Fri, 30 Jan 2009 07:03:03 -0500, Steve Holden wrote: > Antoine Pitrou wrote: >> Raymond Hettinger 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

Re: [Python-Dev] Python 3.0.1

Antoine Pitrou wrote: > Raymond Hettinger 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 wa

Re: [Python-Dev] Python 3.0.1

On 2009-01-30 11:40, Antoine Pitrou wrote: > Aahz 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 >> pr

Re: [Python-Dev] Python 3.0.1

Aahz 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 purposes,

Re: [Python-Dev] Python 3.0.1

> 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 http://mail

Re: [Python-Dev] Python 3.0.1

[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 ___

Re: [Python-Dev] Python 3.0.1

On Thu, Jan 29, 2009 at 4:58 PM, Raymond Hettinger 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 you're think

Re: [Python-Dev] Python 3.0.1

"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 na

Re: [Python-Dev] Python 3.0.1

On Thu, 29 Jan 2009 at 16:43, Raymond Hettinger wrote: On Thu, 29 Jan 2009 at 15:40, Guido van Rossum wrote: Also you could try find shelve users (are there any?) I'm a big fan of shelves and have always used them extensively. Not sure if anyone else cares about them though. I use them.

Re: [Python-Dev] Python 3.0.1

> 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 f

Re: [Python-Dev] Python 3.0.1

On Fri, Jan 30, 2009, Antoine Pitrou wrote: > Raymond Hettinger 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 ti

Re: [Python-Dev] Python 3.0.1

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 bool-True

Re: [Python-Dev] Python 3.0.1

Raymond Hettinger 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 proposal fo

Re: [Python-Dev] Python 3.0.1

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 ado

Re: [Python-Dev] Python 3.0.1

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. Tha

Re: [Python-Dev] Python 3.0.1

On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger 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 which now f

Re: [Python-Dev] Python 3.0.1

[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 f

Re: [Python-Dev] Python 3.0.1

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

Re: [Python-Dev] Python 3.0.1

Raymond Hettinger wrote: From: "Guido van Rossum" 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 ce

Re: [Python-Dev] Python 3.0.1

From: "Guido van Rossum" 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 don't want to open

Re: [Python-Dev] Python 3.0.1

> 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

Re: [Python-Dev] Python 3.0.1

On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden 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 always been

Re: [Python-Dev] Python 3.0.1

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,

Re: [Python-Dev] Python 3.0.1

> 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

Re: [Python-Dev] Python 3.0.1

-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 prod

Re: [Python-Dev] Python 3.0.1

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

Re: [Python-Dev] Python 3.0.1

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". >

Re: [Python-Dev] Python 3.0.1

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 rem

Re: [Python-Dev] Python 3.0.1

"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 *

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 Raymond Hettinger : > [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

Re: [Python-Dev] Python 3.0.1

> 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 us

Re: [Python-Dev] Python 3.0.1

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

Re: [Python-Dev] Python 3.0.1

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 >>> fo

Re: [Python-Dev] Python 3.0.1 (io-in-c)

[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: http://mail.python.o

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Wed, Jan 28, 2009 at 1:42 PM, Adam Olsen wrote: > It'd also help if the file repr gave the encoding: > +1 -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Wed, Jan 28, 2009 at 11:52 AM, Paul Moore 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 the simple "def

Re: [Python-Dev] Python 3.0.1

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 relea

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Wed, 28 Jan 2009 18:52:41 +, Paul Moore wrote: 2009/1/28 "Martin v. Löwis" : 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('

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Steven Bethard wrote: On Wed, Jan 28, 2009 at 10:29 AM, "Martin v. Löwis" 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,

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 "Martin v. Löwis" : > 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 Pytho

Re: [Python-Dev] Python 3.0.1 (io-in-c)

> 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: http

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Paul Moore wrote: > 2009/1/28 "Martin v. Löwis" : >> print(open("a1").read()) >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "D:\Apps\Python30\lib\io.py", line 1491, in write >>> b = encoder.encode(s) >>> File "D:\Apps\Python30\lib\encodings\cp850.py", line 1

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Wed, Jan 28, 2009 at 10:29 AM, "Martin v. Löwis" 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 default, the

Re: [Python-Dev] Python 3.0.1 (io-in-c)

> Thanks for the explanation. It might be clearer to document this a > little more explicitly in the docs for open() (on the basis that > people using open() are the most likely to be naive about encodings). > I'll see if I can come up with an appropriate doc patch. Notice that the determination o

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 "Martin v. Löwis" : > print(open("a1").read()) >> Traceback (most recent call last): >> File "", line 1, in >> 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

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 "Martin v. Löwis" : > 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(

Re: [Python-Dev] Python 3.0.1 (io-in-c)

print(open("a1").read()) > Traceback (most recent call last): > File "", line 1, in > 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 codecs.charmap_encode(input,self.err

Re: [Python-Dev] Python 3.0.1 (io-in-c)

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

Re: [Python-Dev] Python 3.0.1

M.-A. Lemburg wrote: On 2009-01-27 22:19, Raymond Hettinger wrote: From: ""Martin v. Löwis"" 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

Re: [Python-Dev] Python 3.0.1 (io-in-c)

> 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 http://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Python 3.0.1

On 2009-01-27 22:19, Raymond Hettinger wrote: > From: ""Martin v. Löwis"" >> 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 t

Re: [Python-Dev] Python 3.0.1 (io-in-c)

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

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 Antoine Pitrou : > 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 explanation. > Pleas

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Paul Moore 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, t

Re: [Python-Dev] Python 3.0.1

On Wed, Jan 28, 2009 at 4:32 AM, Steve Holden 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 become necessar

Re: [Python-Dev] Python 3.0.1 (io-in-c)

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 performan

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 Antoine Pitrou : > Paul Moore 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 de

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Victor Stinner 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 the idiomatic

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Paul Moore 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, utf-8,

Re: [Python-Dev] Python 3.0.1 (io-in-c)

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/ ___

Re: [Python-Dev] Python 3.0.1 (io-in-c)

2009/1/28 Antoine Pitrou : > 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, I regularly do

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Hello, Raymond Hettinger 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 w

Re: [Python-Dev] Python 3.0.1 (io-in-c)

[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 1

Re: [Python-Dev] Python 3.0.1

-On [20090128 00:57], Barry Warsaw (ba...@python.org) wrote: >I stand by my opinion about the right way to do this. I also think >that a 3.1 release 6 months after 3.0 is perfectly fine and serves our >users just as well. When API fixes were mentioned, does that mean changes in the API which

Re: [Python-Dev] Python 3.0.1

-On [20090128 00:21], Raymond Hettinger (pyt...@rcn.com) wrote: >Also, 3.0 is a special case because it is IMO a broken release. >AFAICT, it is not in any distro yet. Hopefully, no one will keep it around >and it will vanish silently. It is in FreeBSD's ports since December. Fairly good chance it

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Raymond Hettinger wrote: [Antoine Pitrou] Now here are some performance figures. Text I/O is done in utf-8 with universal newlines enabled: That's a substantial boost. How does it compare to Py2.x equivalents? Comparison of three cases (including performance rations):

Re: [Python-Dev] Python 3.0.1

Steve Holden wrote: > Barry Warsaw wrote: [...] >> I stand by my opinion about the right way to do this. I also think that >> a 3.1 release 6 months after 3.0 is perfectly fine and serves our users >> just as well. >> > +1 > I should have been more explicit. I think that stuff that was slated for

Re: [Python-Dev] Python 3.0.1

[Matthew Wilkes] I didn't know 3.0 is considered a broken release, but teething troubles are to be expected. Knowing this, I would be reluctant to use 3.0.1, it sounds like too small a change. Not to worry. Many of the major language features are stable and many of the rough edges are qui

Re: [Python-Dev] Python 3.0.1

On 27 Jan 2009, at 23:56, Barry Warsaw wrote: Also, 3.0 is a special case because it is IMO a broken release. AFAICT, it is not in any distro yet. Hopefully, no one will keep it around and it will vanish silently. I stand by my opinion about the right way to do this. I also think that

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Benjamin Peterson a écrit : There are also several IO bugs that should be fixed before it becomes official like #5006. I looked at this one, but I discovered another a bug with f.tell(): it's now issue #5008. This issue is now closed, that I will look again to #5006. See also #5016 (f.seekab

Re: [Python-Dev] Python 3.0.1

Barry Warsaw wrote: > On Jan 27, 2009, at 6:21 PM, Raymond Hettinger wrote: > >> If something gets left in 3.0.1 and then ripped-out in 3.1, I think we're >> doing more harm than good. Very little code has been ported to 3.0 >> so far. One there is a base, all changes become more difficult. > >

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Daniel Stutzbach stutzbachenterprises.com> writes: > For the "10MB whole contents at once" test, we then have: > (assuming the code does no pipelining of disk I/O with decoding) > > 10MB / 980MB/s to read from disk = 10 ms > 10MB / 250MB/s to decode to utf8 = 40 ms > 10MB / (10ms + 40ms) = 200 MB

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Tue, Jan 27, 2009 at 6:15 PM, Antoine Pitrou wrote: > It's some arbitrary text composed of 95% ASCII characters and 5% non-ASCII. > On > this specific example, utf8 decodes at around 250 MB/s, latin1 at almost 1 > GB/s > (on the same machine on which I ran the benchmarks). > For the "10MB who

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Daniel Stutzbach stutzbachenterprises.com> writes: > > What kind of input are you using for the Text tests?  I'm kind of surprised that the conversion to Unicode results in such a dramatic slowdown, if you're feeding it plain text (characters 0x00 through 0x7f). It's some arbitrary text composed

Re: [Python-Dev] Python 3.0.1 (io-in-c)

On Tue, Jan 27, 2009 at 5:44 PM, Antoine Pitrou wrote: > Daniel Stutzbach stutzbachenterprises.com> writes: > > That's because in Python 3, the Text IO has to convert to Unicode, > correct? > > Yes, exactly. > What kind of input are you using for the Text tests? I'm kind of surprised that the

Re: [Python-Dev] Python 3.0.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 27, 2009, at 6:21 PM, Raymond Hettinger wrote: If something gets left in 3.0.1 and then ripped-out in 3.1, I think we're doing more harm than good. Very little code has been ported to 3.0 so far. One there is a base, all changes become mo

Re: [Python-Dev] Python 3.0.1 (io-in-c)

Daniel Stutzbach stutzbachenterprises.com> writes: > > Thanks, Antoine!  To make comparison easier, I put together the results into a Google Spreadsheet:http://spreadsheets.google.com/pub?key=pbqSxQEo4UXwPlifXmvPHGQ Thanks, that's much more readable indeed. > That's because in Python 3, the Te

Re: [Python-Dev] Python 3.0.1

On Tue, Jan 27, 2009 at 5:04 PM, Barry Warsaw wrote: > I have no problem with removing things that were advertised and/or > documented to be removed in 3.0 but accidentally were not. That seems like > a reasonable policy to me. However, if we did not tell people that > something was going to be

  1   2   >