While I have not been involved in the release process for like 15 years or
more, I would like to point out that breaking changes mean the distros are
less likely to ship them, and be less likely to trust updates.
Trying to get RH &c to stop shipping 1.5.2 was a huge effort.
Always, any time when
I strongly urge another release candidate. But then, I am not doing the
work, so take that advice for what it is...
On Oct 14, 2009 10:18 AM, "Barry Warsaw" wrote:
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that
the idea of a release ...
No, but let's do one anyway!
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
As a data point, I just presented a tutorial here at OSCON on Python 3
Porting, and had a number of people asking about C API changes. I
punted for my talk (*) because things are still in flux. Plus I only
had 3 hours. I did suggest that if your extension is just glue to a C
library, you should con
; Neal Norwitz and Ralf Grosse-Kunstleve have access to that
> machine.
Neal's on leave all this month, I believe.
--
Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015
Level 3 The Teahouse, 28 Clarendon St, Sth Melbourne Australia 3205
On Monday 10 September 2007, Paul Dubois wrote:
> As a small boy I once knew wrote, I must not use bad words. (:->
It's OK to use them about Barry, though, surely?
*wave* Hi Barry.
--
Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015
Level 3 The Teahouse, 28 Claren
f>-- cPython,
> not such much.
We don't break down "major" or "minor" features, but according to
the What's New In Python 2.5 doc:
> A search through the
> SVN change logs finds there were 353 patches applied and 458 bugs
> fixed between Pyt
, I
> am entirely opposed to any use of JavaScript.
What about flash, instead, then?
/ducks
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
fix releases
- only one maintenance branch (most recent) for the bugfix releases
- the last bugfix release of the previous release after a new major
release.
I'm OK with these being formalised - but any additional requirements
I'd like to discuss first :-)
Anthony
--
Anthony Baxter
tions?
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
Ok, things seem to be OK. So the release25-maint branch is unfrozen.
Go crazy. Well, a little bit crazy.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
clude:
Bug fixes. According to the release notes, at least 150
have been fixed.
Highlights of the previous major Python release (2.5) are
available from the Python 2.5 page, at
http://www.python.org/2.5/highlights.html
Enjoy this release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
Python Re
x27;t strike me as critical enough to need
that - and I'm not happy to do the release and just hope. I'll roll
them all back.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
g/2.5/highlights.html
Enjoy this release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ndrew fixed the latter, yay!)
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
n!
Thanks,
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
addressed
(well, to "Python Contributors"), which is a step ahead of most of
them.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
of the data for each transfer.
>
> I agree. I withdrew my original "multimedia library" idea and
> submitted a proposal for the creation of two standard Image and
> Sound classes.
Ideally you'd hook this into the standard library's existing sound
file handli
I'm moving house today and tomorrow, and don't expect to have
internet access connected up at home til sometime next week. In the
meantime, if there's urgent 2.5.1 related issues, bear with me, as
I'll only be on email during the working day. cc Neal (hi Neal :)
is the best bet. Also, the cygwi
this,
I can't remember if you were one of these). My standard response to
this is that people who really feel like this are welcome to pick a
release, say, 2.3, and take on the process of backporting the
relevant bugfixes back to that release, and cutting new releases,
&c.
--
Anthon
ink anyone would mind. There is (as Martin also stated)
zero chance that I will do this additional work. It scratches no
itches for me, and has the potential to add an enormous amount to
my workload of doing a new release.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]&g
x in any way shape or
form.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
e specific version this
problem would go away.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
quot; but hell, there's a lot of
different components that make up Python. That would be a
maintenance and management nightmare.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing l
pen as a possibility for a future PEP.
A good first step would be to contribute something like this to the
Python Cookbook, if it isn't already there.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
On Thursday 15 February 2007 21:48, Steve Holden wrote:
> Greg Ewing wrote:
> > Steve Holden wrote:
> >> A further data point is that modern machines seem to give
> >> timing variabilities due to CPU temperature variations even if
> >> you always eat exactly the same thing.
> >
> > Oh, great. Now w
s()/items(). The globals() and
locals() builtins also provide an alternate view with "different
notation to access it". Since you're creating the view explicitly,
I really don't see the problem - any more than say, creating a set
from a list, or a dict from a list, or the like.
On Wednesday 14 February 2007 07:39, Aahz wrote:
> My point is that I suspect that general objects are not used much
> with getattr/setattr. Does anyone have evidence counter to that?
> I think that evidence should be provided before this goes much
> further; perhaps all that's needed is educatio
turn in performance on a very
> > marginal feature.
>
> The performance question is important, certainly. Initial
> reaction on python-ideas was that a 1% cost would not count as
> substantial
I'd disagree. Those 1% losses add up, and it takes a heck of a lot
of work to
ax that currently
causes this problem the most) is with webpages and with printed
books with code. Sure, everyone can pick a font for coding that
they can read, but that's not the only way you read code. This is
my issue with the foo.(bar) syntax. The period is far far too small
and easy
On Monday 12 February 2007 18:38, Neil Toronto wrote:
> Anthony Baxter wrote:
> > I have to say that I'm not that impressed by either the 1-arg
> > or 2-arg versions. Someone coming across this syntax for the
> > first time will not have any hints as to what it means - an
I have to say that I'm not that impressed by either the 1-arg or
2-arg versions. Someone coming across this syntax for the first
time will not have any hints as to what it means - and worse, it
looks like a syntax error to me. -1 from me.
___
Python-De
On Monday 12 February 2007 13:57, Brett Cannon wrote:
> On 2/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Actually, the regenerating should happen immediately after
> > > commit, as this bumps the revision number of the asdl f
can always make 2.6 warn about
the floatobject's __mod__ function being called if the -W py3k
option is on, that gets us part of the way there. And if we have
a "-3" option or the like that also turns on maximum 3.x compat,
that will enable true division, producing the warning.
add "except a as b" to 2.6 - we're just not
ripping out the old way of doing it.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Pytho
On Wednesday 17 January 2007 05:52, James Y Knight wrote:
> Yes, this is it. As a refinement: if the New Way can easily be
> backported to 2.5,
Um - 2.5 is _done_. Released. In maintenance mode. New features will
not be getting backported to a 2.5.x release.
Anthony
--
Anthony
idea (in another email) of trying to look up
globals would probably cause a horrible performance issue, but it
may be possible to do _something_ clever.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
on't see a path forward that doesn't involve something painful,
so long as 3.0 is going to be the clean break. As I mentioned,
though, I'd like as far as possible to make it so that 2.6 (with a
flag) can be at least vaguely compatible with 3.0.
Anthony
--
Anthony
de does not have to entail dulling the trusty old blade.
I completely disagree here. We cannot simply ignore 3.0 in the 2.x
series. We need to provide (as much as possible) an upgrade path
for people who write and use code in the language.
Anthony
--
Antho
changed raise A, B into raise A(B)
applied to the trunk. This makes it much easier to apply patches to
both the 3.0 branch and the trunk. Similar changes should be
applied to remove, for instance, use of <> and dict.has_key from
the stdlib. Simply put, I'd like the stdlib between 2 and 3
ad.
Checking a single C global int is hardly going to make a huge impact
at all.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
off by default, and won't go through the warnings mechanism at all
unless you specify the command line flag.
I've had a number of people say that this is something they would
really, really like to see - the idea is both to let people migrate
more easily, and provide reassuranc
cc'ing python-dev - followups should probably go there, rather than
the p3yk list.
So here's my latest plan:
- Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning
(or maybe just of Warning)
- Add a -W py3k shortcut, which is the same as
"-W once:Py3kDeprecationWarning"
- Add a C
On Friday 05 January 2007 17:40, Gregory P. Smith wrote:
> Whoever is subscribed to python-dev with a broken corporate
> autoresponder that sends everyone who posts to the list this
> useless response multiple times please unsubscribe yourself. Its
> highly annoying and entirely useless since its
On Wednesday 27 December 2006 12:15, Jenny Zhao (zhzhao) wrote:
> Hi Python developers,
>
> I am using python to write a testing tools, currently this tool
> only supports skinny protocol. I am planning to add SIP and MGCP
> support as well, wondering if you have written these protocol
> stacks be
On Sunday 24 December 2006 00:19, Andrew MacIntyre wrote:
> Of course, if the project management decide that even the EMX
> support should be removed from the official tree - so be it; I
> will just have to maintain the port outside the official tree.
I feel that so long as there's an active maint
LSB,
> actually.
Well, I don't know what sort of public statement you want to issue,
but will this do? (Wearing my release manager hat)
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
__
hon. It's worth noting that the entirety
of the Python stdlib is a required package, so it doesn't cause
issues.)
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing
or 2.6. note that read
I agree that a warning seems best. If someone (for whatever reason) is
flinging floats around where they actually meant to have ints, going straight
to an error from silently truncating and accepting it seems a little bit
harsh.
Anthony
--
Anthony Baxter <[EMAIL P
On Friday 10 November 2006 13:45, A.M. Kuchling wrote:
> OK, I'll backport it; thanks!
>
> (It's not fixing a frequent data-loss problem -- the patch just
> assures that when flush() or close() returns, data is more likely to
> have been written to disk and be safe after a subsequent system
> crash
ails. I'm happy for it to go into release25-maint (particularly because
the consequences of the bug are so dire).
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev maili
uilding is a tiny part of the problem... or am I missing something?
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
completely appropriate, too.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
known issues, please see:
http://www.python.org/2.3.6
Highlights of this new release include:
- A fix for PSF-2006-001, a bug in repr() for unicode strings
on UCS-4 (wide unicode) builds.
- Two other, less critical, security fixes.
Enjoy this release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
P
.
This solution doesn't require changes to the buildslave code at all - only to
the buildmaster and to regrtest.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Py
rity related bugs) will get a new release, and then
only with the serious bugfixes applied.
One active maintenance branch is quite enough to deal with, IMHO.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
ease notes, and known issues, please see:
http://www.python.org/2.3.6
Highlights of this new release include:
- A fix for PSF-2006-001, a bug in repr() for unicode strings
on UCS-4 (wide unicode) builds.
- Two other, less critical, security fixes.
Enjoy this release,
Anthony
Anthony Baxter
Thanks to the folks involved in this prcocess - I'm looking forward to getting
the hell away from SF's bug tracker. :-)
Anthony
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
tion becomes better understood.
Anyway, all of the above is open to disagreement or other opinions - if you
have them, let me know.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev maili
strings on UCS-4 (wide unicode) builds.
Enjoy this release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)
pgpHQFKzDQCYF.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@pyt
Ah - the svn-apache server was down. I've restarted it. We should probably put
some monitoring/restarting in place for those servers - if someone wants to
volunteer a script I'll add it to cron, or I'll write it myself when I get a
chance.
(I was testing with svn+ssh, it was the http version th
On Wednesday 18 October 2006 00:59, Grig Gheorghiu wrote:
> FYI -- can't do svn checkouts/updates from the trunk at this point.
>
> starting svn operation
> svn update --revision HEAD
> in dir /home/twistbot/pybot/trunk.gheorghiu-x86/build (timeout 1200 secs)
> svn: PROPFIND request failed on '/pr
edge wants to review that it can
be checked in. It _should_ be good, and probably needs to be applied to
release25-maint and the trunk as well.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
u're willing to
> coordinate, is there anything we can do to help?
Less than a normal release, since I'm not going to worry about changing the
docs, the windows installers or the mac installers. I'll look at it next
week, once 2.4.4 final is done.
Anthony
--
Anthony Baxter
On Tuesday 17 October 2006 18:54, Fredrik Lundh wrote:
> Martin v. L�wis wrote:
> > In 2.3.6, there wouldn't just be that change, but also a few other
> > changes that have been collected, some relevant for Windows as well
>
> why not just do a "2.3.5+security" source release, and leave the rest to
releases having new capabilities.
Since it wasn't possible in earlier than 2.5 either, I'd say it's on the
edge of being a bugfix. Let's be conservative and not backport it, since it's
also a pretty marginal feature.
Anthony
--
all
sorts of minor variations there - for instance, often in a non-final release,
we don't have an unpacked version of the documentation (but sometimes we do,
wah).
The killer bits for me are all the other places. For instance, updating the
sidebar menu quicklinks for 2.4.4 to 2.5. The
ne, macteagle. For some reason builds fail on it right now - Ronald
might be able to supply more details as to why.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
have to have an overall infrastructure that lets you make
> incremental tweaks to the tool chain, so things can get a little better
> all the time. Pyramid obviously isn't such a system.
I can't disagree with this.
--
Anthony Baxter <[EMAIL PROTECTED]>
It'
27;s insane :-)
The bit of the website that's dealing with the actual files is not the tricky
bit - I have a dinky little python script that generates the download table.
The problems are with the other bits of the pages. I keep thinking "next
release, I'll automate it furthe
> portable code at all.
"One" might say that. I wouldn't. It stays out until 2.6.
Sorry
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
ng to watch out for is that I (or whoever) can still do local
work on a bunch of different files, then check it in all in one hit once it's
done and checked. This was an issue I had with the various wiki-based
proposals, I haven't seen many wikis that allow this.
--
Anthony Baxte
t does take the time is the website - fixing that is a major
investment of time, which I also don't have. Yes, had I spent the probably
20+ hours I've spent doing website stuff I could have made it a bit better,
but that's what I know _now_ :)
--
Anthony Baxter <[E
On Friday 13 October 2006 05:30, Georg Brandl wrote:
> I'm I the only one who feels that the website is a big workflow problem?
Assuming you meant "Am I", then I absolutely agree with you.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too l
supported. There's plenty of platforms we "support" which don't have
buildslaves, but they're all variants of Unix - I'm happy that they are all
mostly[1] sane.
Anthony
[1] Offer void on some versions of HP/UX, Irix, AIX
--
Anthony Baxter <[EMAIL PROTECTED]&
On Friday 13 October 2006 06:25, Barry Warsaw wrote:
> On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote:
> > Mostly it is easy for me, with the one huge caveat. As far as I
> > know, the Mac
> > build is a single command to run for Ronald, and the Doc build
> > simi
On Thursday 12 October 2006 18:18, Fredrik Lundh wrote:
> Anthony Baxter wrote:
> > 16 releases in 12 months would just about make me go crazy.
>
> is there any way we could further automate or otherwise streamline or
> distribute the release process ?
It's already pretty
I've had a couple of queries about whether PSF-2006-001 merits a 2.3.6.
Personally, I lean towards "no" - 2.4 was nearly two years ago now. But I'm
open to other opinions - I guess people see the phrase "buffer overrun" and
they get scared.
Plus once 2.4.4 final is out next week, I'll have cut
ghts of the previous major Python release (2.4) are available
from the Python 2.4 page, at
http://www.python.org/2.4/highlights.html
Enjoy this release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)
pgpzcYkwpfnHG.pgp
Descri
The release24-maint branch is frozen for the 2.4.4c1 release from 00:00UTC on
the 11th of October. That's about 7 hours from now.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Py
On Friday 29 September 2006 00:30, Jeremy Hylton wrote:
> On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > I'd like to propose that the AST format returned by passing PyCF_ONLY_AST
> > to compile() get the same guarantee in maintenance branches as the
> > b
The plan for 2.4.4 is to have a release candidate on October 11th, and a final
release on October 18th. This is very likely to be the last ever 2.4 release,
after which 2.4.4 joins 2.3.5 and earlier in the old folks home, where it can
live out it's remaining life with dignity and respect.
If y
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
compile() get the same guarantee in maintenance branches as the bytecode
format - that is, unless it's absolutely necessary, we'll keep it the same.
Otherwise anyone trying to write tools to manipulate the AST is in for
n and agreement
on python-dev first.
Thanks to everyone for helping make 2.5 happen. It's been a long slog there,
but I think we can all be proud of the result.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Could people please treat the release25-maint branch as frozen for a day or
two, just in case we have to cut an ohmygodnononokillme release? Thanks,
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happ
ref, uuid and ctypes. As well, a new
higher-performance profiling module (cProfile) was
added.
Extra-special thanks on behalf of the entire Python
community should go out to Neal Norwitz, who's done
absolutely sterling work in shepherding Python 2.5
through to it's final release.
Enjoy th
ed on the last few
releases, I'd expect the release process to take around 18 hours (timezones
are a swine).
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
during the release cycle) that we'll probably need a 2.5.1 in about
3 months.
3. We delay the release until it's fixed.
I'm strongly leaning towards (2) at this point. (1) would probably require
another release candidate, while (3) would result in another release
candidate and
Ok - we're looking at a final release in 7 days time. I really, really, really
don't want to have to cut an rc3, so unless it's a seriously critical
brown-paper-bag bug, let's hold off on the checkins. Documentation, I don't
mind so much - particularly any formatt
giref, uuid and ctypes. In addition, a new profiling
module "cProfile" was added.
Enjoy this new release,
Anthony
Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)
___
Python-Dev mailing list
Please log a bug - this is probably something suitable for fixing in 2.5.1. At
the very least, if it's going to be limited to 127 characters, it should
check that and raise a more suitable exception.
___
Python-Dev mailing list
Python-Dev@python.org
h
out 12 hours from now.
This is for 2.5rc2. Once this is out, I'd like to see as close to zero changes
as possible for the next week or so until 2.5 final is released.
My god, it's getting so close...
Anthony
--
Anthony Baxter <[EMAIL PROTECTED
re for bugfixes, only. It's possible that this could be considered a
bugfix, but as I said right now I'm dubious.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-D
ly large patch for a release candidate but if
> prudence suggests deferring it, it should be a *definite* for 2.5.1 and
> subsequent releases.
Possibly. I remain unconvinced.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
On Friday 08 September 2006 02:56, Kristján V. Jónsson wrote:
> Hello All.
> I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5)
> which allows unicode paths in sys.path and uses the unicode file api on
> windows. This is tried and tested on 2.5, and backported to 2.3 and is
On Tuesday 05 September 2006 00:52, Gustavo Carneiro wrote:
> 3. Signals can be delivered to any thread, let's assume (because
> of point #1 and not others not mentioned) that we have no control over
> which threads receive which signals, might as well be random for all
> we know;
Note that
On Tuesday 05 September 2006 00:05, Nick Maclaren wrote:
> Anthony Baxter isn't exaggerating the problem, despite what you may
> think from his posting.
If the SF bugtracker had a better search interface, you could see why I have
such a bleak view of this area of Python. What's t
f this going into 2.5.
Signals and threads combined are an complete *nightmare* of platform-specific
behaviour. I'm -1000 on trying to change this code now, _after_ the first
release candidate. To say that "that path lies madness" is like
saying "Pacific Ocean large, wet, full of fis
t; The patch is ready-to-go.
> Nick, please go ahead and backport.
I think this is suitable for 2.5. I'm thinking, though, that we need a second
release candidate, given the number of changes since rc1.
--
Anthony Baxter <[EMAIL PROTECTED]>
It&#
1 - 100 of 347 matches
Mail list logo
