> For example, let's project dates for closing 2.6 and 3.0 now, and add
> them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Following another informal policy, we were going for an 18 months
release cycle at some time (2.6 clearly took longer), which would
mean
-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 br
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
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
> 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 unavaila
-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 2.2
-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 release
> 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
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.
Y
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
reasona
> 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* do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all.
Sorry for spamming several mailing list.
After many hours of hard work, I'm proud to present a preview of pybsddb
4.7.3, able to compile and work under Python 2.3, 2.4, 2.5, 2.6b2 and 3.0b2.
You can try it out downloading it directly from m
On Wed, 13 Aug 2008 15:35:15 + (UTC), Antoine Pitrou <[EMAIL PROTECTED]>
wrote:
Barry Warsaw 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
Barry Warsaw 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
of.
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:
http://fusil.hacho
>> (*) 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.
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
repos
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 accordingly.
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 bet
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 ar
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 bot
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 slide
> (*) 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.
__
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 any
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 the
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, cha
Guido van Rossum python.org> writes:
>
> On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen 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 probl
27 matches
Mail list logo
