Guido van Rossum guido at python.org writes:
On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen janssen at parc.com wrote:
Is it using fork()? Threads?
No on fork(), yes on threads.
Hmm... I don't believe that io.py is thread-safe.
There is an issue open for the BufferedWriter + threads
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus,
Antoine Pitrou wrote:
As Martin suggested in this issue's comments, a simple fix would be to wrap most
methods with an instance-specific mutex. I don't know how that would affect
performance.
For 3.0, I think correctness is more important than speed. At this
stage, we may have to live with
On 2008-08-13 04:57, Guido van Rossum wrote:
And there's a reason for this slow uptake of Python 2.5: as more
and more servers run 64-bit OSes, the Py_ssize_t changes cause
serious trouble with Python C extensions that were not updated
by their authors.
I'm not sure what that has to do with
(*) slides:
http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf
Hilarious! Seems like that would have been a riot of a session to attend.
(I'm kicking myself for attending some other uninteresting talk when yours was
on.)
Trent.
I'm planning on re-presenting it at the local google office in the
next couple of weeks. I might try and arrange for it to be recorded
and put online. At the moment we seem to have a real lack of concrete
information for people about the transition. If I had time (ha! HA!)
I'd try to turn the
Last time I looked at it, the C API wasn't nailed down yet. That's why
I passed over it entirely for my tutorial. The only advice I was able
to give was that if your extension is just a wrapper around existing C
code, you might be better off rewriting it using ctypes. That way it
should work on
M.-A. Lemburg wrote:
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries
On Wed, 2008-08-13 at 22:20 +1000, Anthony Baxter wrote:
Last time I looked at it, the C API wasn't nailed down yet. That's why
I passed over it entirely for my tutorial. The only advice I was able
to give was that if your extension is just a wrapper around existing C
code, you might be better
On 2008-08-13 15:20, Steve Holden wrote:
M.-A. Lemburg wrote:
Perhaps we should just document the maintenance of Python releases
more clearly and also plan for a final bug fix release 3 years after
the initial branch release. That way developers and users can also
adjust their plans
Why not migrate support for older releases to interested parties outside of
the regular developer team? Presuming there is someone out there with the
interest in maintaining, say, Python 2.2, they could take over the entire
responsibility for making releases, continuing to use the Subversion
(*) slides:
http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf
Trent Hilarious! Seems like that would have been a riot of a session
Trent to attend. (I'm kicking myself for attending some other
Trent uninteresting talk when yours was on.)
Indeed.
Le Wednesday 13 August 2008 15:27:42 Hrvoje Nikšić, vous avez écrit :
Given that ctypes doesn't work on a number of popular architectures,
including x86_64 (the last time I looked), I'd hardly call that better
off. :-(
I wrote a debugger based on ptrace using ctypes:
Barry Warsaw barry at python.org writes:
The goal
should be to produce something like a unittest-ng, distribute it via
the Cheeseshop, and gather consensus around it for possible inclusion
in Python 2.7/3.1.
There is already unittest, nose, py.test, trial... perhaps others I don't know
On Wed, 13 Aug 2008 15:35:15 + (UTC), Antoine Pitrou [EMAIL PROTECTED]
wrote:
Barry Warsaw barry at python.org writes:
The goal
should be to produce something like a unittest-ng, distribute it via
the Cheeseshop, and gather consensus around it for possible inclusion
in Python 2.7/3.1.
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
You mean, they installed it *without*
On Wed, 13 Aug 2008, Antoine Pitrou wrote:
[...]
nose itself is not a completely independent piece of work but a discovery-based
unittest extension (although a very big extension!). For that reason, Michael
Foord's suggestion to gradually modernize and improve the stdlib unittest sounds
On 2008-08-13 22:32, Martin v. Löwis wrote:
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
What I was trying to say is that you only see a single source download,
which someone then takes, compiles and possibly redistributed or
integrates into a product. As a result a single download can
easily map to quite a few installations - and that's what we should
base our assumptions on.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 1:53 AM, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 10:29 AM, [EMAIL PROTECTED] wrote:
Why not migrate support for older releases to interested parties
outside of
the regular developer team? Presuming there is someone out there
with the
interest in maintaining, say, Python
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added now. Nothing
that gets added to the source repository ever becomes
On Wed, Aug 13, 2008 at 4:11 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added
Ben Finney wrote:
Michael Foord [EMAIL PROTECTED] writes:
The full list of changes proposed […] and not shot down was
something like:
[…]
assertLessThan
assertGreaterThan
assertLessThanOrEquals
assertGreaterThanOrEquals
[…]
Brett Cannon [EMAIL PROTECTED] writes:
Is any of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 7:11 PM, Martin v. Löwis wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such
25 matches
Mail list logo
