Steve Holden wrote:
We now have zone servers in the OpenSolaris test farm, and
I plan to add guest os servers in the next few weeks using
ldoms (sparc) and xvm (x64). The zone servers provide whole
root zones, which should be a good development environment
for most projects. Check it out:
http:
-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
-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
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):
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
[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
On Tue, Jan 27, 2009 at 5:16 PM, Jake McGuire wrote:
> Another vaguely related change would be to store string and unicode objects
> in the pickler memo keyed as themselves rather than their object ids.
That wouldn't be difficult to do--i.e., simply add a type check in
Pickler.memoize and another
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
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
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.
>
>
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
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
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
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
Register here:
http://us.pycon.org/2009/register/
Information (rates etc.):
http://us.pycon.org/2009/registration/
Hotel information & reservations:
http://us.pycon.org/2009/about/hotel/
Early bird registration ends February 21, so don't delay!
-- David Goodger, PyCon 2009 Chair
___
-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
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
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
Raymond Hettinger schrieb:
> [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.
On Tue, Jan 27, 2009 at 4:54 PM, Antoine Pitrou wrote:
> Daniel Stutzbach stutzbachenterprises.com> writes:
> > Would it be much trouble to also compare performance with Python 2.6?
>
> Here are the results on trunk.
>
Thanks, Antoine! To make comparison easier, I put together the results into
Raymond Hettinger rcn.com> writes:
>
> Also, 3.0 is a special case because it is IMO a broken release.
> AFAICT, it is not in any distro yet.
I have access to an Ubuntu 8.10 box and:
$ apt-cache search python3.0
idle-python3.0 - An IDE for Python (v3.0) using Tkinter
libpython3.0 - Shared Pytho
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.
In the interests of our users, I vote for sooner than later.
Also, 3.0 is a special case
[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 w
> - 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:
-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
(a
On Tue, Jan 27, 2009 at 14:44, Antoine Pitrou wrote:
> Raymond Hettinger 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2009, at 5:36 PM, Brett Cannon wrote:
On Tue, Jan 27, 2009 at 14:31, "Martin v. Löwis"
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
ou
[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?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
Daniel Stutzbach 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 **
Martin v. Löwis 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 o
On Tue, Jan 27, 2009 at 4:44 PM, Antoine Pitrou wrote:
> Now here are some performance figures. Text I/O is done in utf-8 with
> universal
> newlines enabled:
>
Would it be much trouble to also compare performance with Python 2.6?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC
On Tue, Jan 27, 2009 at 4:44 PM, Antoine Pitrou wrote:
> Raymond Hettinger 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 remaini
Raymond Hettinger 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 implem
Antoine Pitrou wrote:
> There is an SVN branch with a complete rewrite (in C) of the IO stack. You can
> find it in branches/io-c. Apart from a problem in _ssl.c, it should be quite
> usable. Your tests and observations are welcome!
And I'll look at that _ssl.c problem.
Bill
___
On Tue, Jan 27, 2009 at 2:24 PM, Raymond Hettinger wrote:
>
> [Guido van Rossum]
>>
>> My only thought is that whatever you do, target Python 3.1, not 3.0.1.
>
> Of course.
> Do you have any thoughts on the most useful display format?
> What do you want to see from pprint(mydict.items())?
Perhaps
On Tue, Jan 27, 2009 at 14:31, "Martin v. Löwis" 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 can have
> 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
http://mail.python.org/mailman/listinfo/python-d
> 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 f
[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 bug
[Guido van Rossum]
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
Of course.
Do you have any thoughts on the most useful display format?
What do you want to see from pprint(mydict.items())?
Raymond
___
Python-Dev mailing
On Jan 27, 2009, at 12:39 PM, Martin v. Löwis wrote:
I may have misunderstood how unpickling works
Perhaps I have misunderstood your patch. Posting it to Rietveld might
also be useful.
It is not immediately clear to me how Rietveld works. But I have
created an issue on tracker:
http://bu
On Tue, Jan 27, 2009 at 2:12 PM, Benjamin Peterson wrote:
> On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger wrote:
>> It is becoming the norm in 3.x for functions to return iterators,
>> generators, or views whereever possible.
>
>> Do you guys have any thoughts on the subject?
>
> Maybe a sol
Raymond Hettinger wrote:
>
I quite like the idea of something along those lines. For example:
try:
itr = iter(obj)
except TypeError:
pass
else:
return "" % (obj.__class__.__name__,
))
Doing this only in pprint also reduces the chances of accidentally
con
On Tue, Jan 27, 2009 at 2:06 PM, Oleg Broytmann wrote:
> On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote:
>>
>
> I like the idea, and I prefer this formatting. Also bear in mind there
> are infinite generators, and there are iterators that cannot be reset. For
> infinite ge
On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger wrote:
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
> Do you guys have any thoughts on the subject?
Maybe a solution like this could help with bugs like #2610?
--
Regards,
Ben
On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote:
>
I like the idea, and I prefer this formatting. Also bear in mind there
are infinite generators, and there are iterators that cannot be reset. For
infinite generators pprint() must have a parameter, say, 'max_items', and
pr
Benjamin Peterson 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 would be a
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
On Tue, Jan 27, 2009 at 1:46 PM, Raymond Hettinger wrote:
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
>
> I had a thought that pprint() ought to be taught to p
On Tue, Jan 27, 2009 at 3:19 PM, Raymond Hettinger wrote:
> If 3.1 goes out right away, then it doesn't matter if 3.0 looks ridiculous.
> All eyes go to the latest release. Better to get this done before more
> people download 3.0 to kick the tires.
It seems like we are arguing over the version
It is becoming the norm in 3.x for functions to return iterators, generators,
or views whereever possible.
I had a thought that pprint() ought to be taught to print iterators:
pprint(enumerate(seq))
pprint(map(somefunc, somedata))
pprint(permutations(elements))
pprint(mydict.items()
Hello Kevin,
> As an interested observer, but not yet user of the 3.x series, I was wondering
about progress on restoring io performance and what release those improvements
were slated for.
There is an SVN branch with a complete rewrite (in C) of the IO stack. You can
find it in branches/io-c. A
On Tue, Jan 27, 2009 at 5:04 PM, Jesse Noller wrote:
> Hi Mart,
>
> This is a better discussion for the python-ideas list. That being
> said, there was a thread discussing this last year, see:
>
> http://mail.python.org/pipermail/python-dev/2008-October/083176.html
>
> -jesse
>
Indeed, sorry. In
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 third-party developers spend time migrating code.
We neede
>> 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 thos
On Tue, Jan 27, 2009 at 12:28 PM, "Martin v. Löwis" 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 year - and no
> I may have misunderstood how unpickling works
Perhaps I have misunderstood your patch. Posting it to Rietveld might
also be useful.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Tue, Jan 27, 2009 at 3:22 PM, Benjamin Peterson 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.) It would fix the hugest
> mistakes in the initial release most of which have been done committed
> since December. I'm
> 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 Jan 27, 2009, at 11:40 AM, Martin v. Löwis wrote:
Hm. This would change the pickling format though. Wouldn't just
interning (short) strings on unpickling be simpler?
Sure - that's what Jake had proposed. However, it is always difficult
to select which strings to intern - his heuristics (IIUC
On Tue, Jan 27, 2009 at 1:00 PM, Raymond Hettinger 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 IO
> performa
> Just set a size limit, e.g. 30 or 100. It's just a heuristic. I
> believe somewhere in Python itself I intern string literals if they
> are reasonably short and fit the pattern of an identifier; I'd worry
> that the pattern matching would slow down unpickling more than the
> expected benefit thou
On Tue, Jan 27, 2009 at 11:40 AM, "Martin v. Löwis" wrote:
>> Hm. This would change the pickling format though. Wouldn't just
>> interning (short) strings on unpickling be simpler?
>
> Sure - that's what Jake had proposed. However, it is always difficult
> to select which strings to intern - his h
-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.
I
> Hm. This would change the pickling format though. Wouldn't just
> interning (short) strings on unpickling be simpler?
Sure - that's what Jake had proposed. However, it is always difficult
to select which strings to intern - his heuristics (IIUC) is to intern
all strings that appear as dictionary
On Tue, Jan 27, 2009 at 11:29, Barry Warsaw 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
>> wrote:
>>>
>>> With the extensive changes in the works, Python 3.0.1 is shaping
-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
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 usab
From: "Guido van Rossum"
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, huge performan
On Tue, Jan 27, 2009 at 11:00 AM, Raymond Hettinger 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 IO
> perform
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 IO performance.
I propose to make the new release more attractive by backpo
On Tue, Jan 27, 2009 at 10:43 AM, "Martin v. Löwis" wrote:
>> Interning the strings on unpickling makes the pickles smaller, and at
>> least for cPickle actually makes unpickling sequences of many objects
>> slightly faster. I have included proposed patches to cPickle.c and
>> pickle.py, and woul
> Note: under CE, you can actually encounter datatype misalignments, since it
> runs on CPUs that don't emulate them. I wonder if the same doesn't also apply
> to win64
I don't think you can get misalignment traps on AMD64. Not sure about
IA-64: I know that the processor will trap on misalig
> Interning the strings on unpickling makes the pickles smaller, and at
> least for cPickle actually makes unpickling sequences of many objects
> slightly faster. I have included proposed patches to cPickle.c and
> pickle.py, and would appreciate any feedback.
Please submit patches always to the
On Tue, Jan 27, 2009 at 6:23 AM, Jesse Noller wrote:
> On Tue, Jan 27, 2009 at 4:49 AM, Jake McGuire wrote:
>> Instance attribute names are normally interned - this is done in
>> PyObject_SetAttr (among other places). Unpickling (in pickle and cPickle)
>> directly updates __dict__ on the instanc
So, if anyone wants to run a Sun buildbot or whatever, Jim would be the
person to contact. Synchronize on this list to ensure Jim doesn't get
multiple approaches, please.
regards
Steve
Original Message
Subject: Re: [PSF-Board] I've got a surprise for you!
Date: Tue, 27 Jan 2009
> From: eckha...@satorlaser.com
> To: python-dev@python.org
> Subject: Re: [Python-Dev] FormatError() in callproc.c under win32
> Date: Tue, 27 Jan 2009 12:16:01 +0100
> CC: coder_infi...@hotmail.com
>
> On Monday 26 January 2009, Martin v. Löwis wrote:
> > > In callproc.c from trunk is a funct
Jesse Noller wrote:
> On Tue, Jan 27, 2009 at 9:50 AM, Mart Sõmermaa wrote:
>> As most of you know there's constant struggle on the JavaScript front to get
>> even faster performance out of interpreters.
>> V8, TraceMonkey and SquirrelFish have brought novel ideas to interpreter
>> design, wouldn'
On Tue, Jan 27, 2009 at 9:50 AM, Mart Sõmermaa wrote:
> As most of you know there's constant struggle on the JavaScript front to get
> even faster performance out of interpreters.
> V8, TraceMonkey and SquirrelFish have brought novel ideas to interpreter
> design, wouldn't it make sense to reap th
As most of you know there's constant struggle on the JavaScript front to get
even faster performance out of interpreters.
V8, TraceMonkey and SquirrelFish have brought novel ideas to interpreter
design, wouldn't it make sense to reap the best bits and bring them to
Python?
Has anyone delved into t
On Tue, Jan 27, 2009 at 4:49 AM, Jake McGuire wrote:
> Instance attribute names are normally interned - this is done in
> PyObject_SetAttr (among other places). Unpickling (in pickle and cPickle)
> directly updates __dict__ on the instance object. This bypasses the
> interning so you end up with
Instance attribute names are normally interned - this is done in
PyObject_SetAttr (among other places). Unpickling (in pickle and
cPickle) directly updates __dict__ on the instance object. This
bypasses the interning so you end up with many copies of the strings
representing your attribut
Jim Walker wrote:
[Trent's announcement]
>
> Great stuff Trent! I was wondering how you were doing.
>
> I really appreciate what it takes to put these open resources
> together ;) There's a lot of moving parts :)
>
> Cheers,
> Jim
>
> BTW.
>
> We now have zone servers in the OpenSolaris test f
On Monday 26 January 2009, Martin v. Löwis wrote:
> > In callproc.c from trunk is a function called SetException(), which calls
> > FormatError() only to discard the contents. Can anyone enlighten me to
> > the reasons thereof?
>
> Interestingly enough, the code used to say
>
>PyErr_SetString(P
On Monday 26 January 2009, Thomas Heller wrote:
> Ulrich Eckhardt schrieb:
> > In callproc.c from trunk is a function called SetException(), which calls
[...]
> > My third approach would be to filter out the special error codes first
> > and delegate all others to PyErr_SetFromWindowsErr(). The lat
83 matches
Mail list logo
