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!
The trunk is frozen from 00:00 UTC Tuesday the 11th of July. This is
in about 16 hours or so time. As usual, unless you're a member of the
release team, please don't checkin past that time until I send an
email that the release is done.
Thanks,
Anthony
--
Anthony Baxter <[EM
anyway_ be considered "pedantry", and it makes me
quite grumpy to have it described in that way.
> For the users, it
> is a net win if this goes in.
In the case of this feature, that's true.
Anthony
--
Anthony Baxter <
ct warning. But
that really will have to wait until post-beta2 at this point.
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
e, sqlite3,
wsgiref 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)
pgplW1DKoGpz0.pgp
Description: PGP signature
__
beta2 is done, so trunk is unfrozen. Remember, we're still in feature
freeze, so new features need approval before being committed.
Thanks!
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
__
s I missed?
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/mai
one better. No way at all will it be in 2.5. And I'd be a
firm -1 on adding in to 2.6 as well. It encourages bad coding. You
shouldn't be searching lists and tuples like that unless you know
what you're doing.
Anthony
--
Anthony Baxter
Contributions are welcome, as long as they fix this entire issue
> "for good" (i.e. in all URL-processing code, and considering all
> relevant RFCs).
For 2.5, should we at least detect that it's unicode and raise a
useful error?
--
Anthony Baxter <[EMAIL PROTEC
Making strftime accept 0s is fine to be checked in, since it's a
regression (an understandable one, but what the hell). Making it
accept less than 9 items and have useful defaults should wait for 2.6
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Wednesday 12 July 2006 21:55, Georg Brandl wrote:
> >> Should we accept at least the very common options "--help" and
> >> "--version" in 2.5?
> >
> > Guido pronounced on this in May
>
> Late it comes, but here is a patch for getopt.c implementing
> this pronouncement. I think there's no need to
but because it breaks real code -- undocumented be
> damned.
>
> Are we going to fix it, without allowing those crashes again?
I already said "yes" for 2.5. Brett, can you work up a patch?
Anthony
--
Anthony Baxter <[EMAIL PROTECTE
FWIW, I tend to run a few project(*) test suites when doing minor
releases (2.x.y), just to make sure I don't break things. For major
releases, it's a fair bit more work - something like Twisted or Zope3
play at such a low level with the Python interfaces that there's
nearly always breakages or
time
(requiring extra monitoring by people like myself and Neal), or we
branch earlier, requiring double commits to the trunk and the branch
for bugfixes.
I also strongly doubt that making a longer "release candidate" cycle
would lead to any significant additional testing by end-use
y enough, so does release management.
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
Unsubscr
e is feasible? And if there's not going to be a feature
freeze, there's hardly any point to people doing testing until there
_is_ a feature freeze, is there? Oh, great, my code works with 2.5b1.
Oops. 2.5b9 added a new feature that broke my code, but I didn't test
with that.
A
y forking much earlier.
This approach would also make it extremely difficult to plan for
releases. I know that my free time varies across the course of the
year, and I need _some_ sort of plan for when the release will happen
so I can make sure I have the time free to spend on it.
Anthony
--
the workload for bugfixes. SVN is
better than CVS, but it's still not great when it comes to
backporting fixes between branches.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
On Thursday 27 July 2006 16:40, Martin v. Löwis wrote:
> Collin Winter wrote:
> > Is it intentional that Python 2.5 is (currently) shipping with
> > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and
> > 2.4.3) shipped with distutils 2.4.1? Judging from my own tests,
> > distutils 2.4.1 f
inevitable - there's a lot of new stuff in 2.5.
Does anyone disagree with making the next release beta3?
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Pyth
done.
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
nts to
generators to produce a coroutine kind of functionality, and
a brand new AST-based compiler implementation.
New modules added include hashlib, ElementTree, sqlite3,
wsgiref and ctypes. In addition, a new profiling module
"cProfile" was added.
Enjoy this new release,
Anthony
Anthony
The trunk is unfrozen now. Sorry about the delay - combination of a laptop
motherboard replacement and a DSL provider with a network that was .. ahem...
slightly slow.
I'm still planning to branch at 2.5c1, the next release. That then opens the
trunk up for all the bad craziness that's planned
I'm nervous about this change being made at this stage of the release process.
It seems to me to have a chance of causing breakages - admittedly a small
chance, but one that's higher than I'd like.
I'd also like to make sure that the PCBuild8 directory is updated at the same
time - with the rec
> > Similarly, rangeiter_next will need to use PyInt_FromSsize_t .
>
> Feel free to submit a patch for Python 2.6. I expect the 2.5 release
> managers to reject this on the basis of being a new feature.
Absolutely correct. At this point in the release process, there's going
lease process for 2.5c1. This will be done after
the repository is updated to identify itself as '2.5c1'. Once this is done, I
plan on doing all further 2.5 releases from the release25-maint branch. I
will no longer care about the trunk's stability :-)
Anthony
--
Anthony Baxter
I really don't care any more about this. My initial concern (and why I
requested the change) was that there are no more official separate distutils
releases. I don't see how keeping a bunch of version numbers in the stdlib
that just track the main version number is a sane use of developer time -
docs can be built.
So long as you don't break anything, doc changes are fine. Remember that post
RC1 you'll need to checkin to both release25-maint and trunk.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
pt too broad. I wouldn't suggest
> applying this late in the release cycle, except that it seems sort of
> like the memory errors that are still being patched.
I'd be concerned that this might cause other obscure behaviour changes, and so
I&#
the release is done -
at that point, the trunk is then available for 2.6 checkins.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http
s a bit late for the release candidate :-) but I agree - if it can't
be fixed before 2.5 final, it should be reverted.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing lis
t here, or if you have
to send private email, send it to both of us. If this policy offends you,
please reply and let me know what you'd prefer.
Right now, I don't really care about the trunk - although if you break the
buildbot, I'm sure Neal will be very cranky at you :-)
qlite3,
wsgiref, 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)
pgpC2XcpH5jvO.pgp
Description: PGP signature
_
On Friday 18 August 2006 00:47, Martin v. Löwis wrote:
> Anthony Baxter schrieb:
> > Right now, I don't really care about the trunk - although if you break
> > the buildbot [...]
>
> Thanks for reminding me. I just added a buildbot builder for the 2.5
> branch (actu
Fixing docs is fine - please checkin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hould go in.
Sounds fine to me. Making buildbot less red == goodness.
--
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/listin
about changing distutils' version number? :-)
I'd very much like to do this, but I figured this was a good first step.
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Pytho
f the original patch, I have reviewed it and I'm for it.
I agree with Neal's comment - this needs tests to make sure it doesn't break
again. It's OK to apply it with the tests.
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to
On Sunday 27 August 2006 05:06, Jack Howarth wrote:
>I discovered that gcc 4.2 exposes a flaw with
> signed integer overflows in python. This bug and the
> necessary fix has been discussed in detail on the gcc
> mailing list. I have filed a detailed bug report and
> the recommended patch pr
On Wednesday 30 August 2006 08:57, Tim Peters wrote:
> Speaking of which, I saw no feedback on the proposed patch in
>
> http://mail.python.org/pipermail/python-dev/2006-August/068502.html
>
> so I'll just check that in tomorrow.
Fine with me!
thanks,
Anthony
--
Anthon
-maint and release23-maint. Let me
know if you can't do the backport...
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
At this point, I'd say the documentation patches should go in - the other
patches are probably appropriate for 2.5.1. I only want to accept critical
patches between now and 2.5 final.
Thanks for the patches (and particularly for the unittest! woo!)
Anthony
_
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&#
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
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
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 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
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.
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
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
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
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
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
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
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
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
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
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.
___
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
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
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 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
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
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
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
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 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
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
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
> 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
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
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'
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
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
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
--
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
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
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.
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
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
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
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
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
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
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.
.
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
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
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:
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
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
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
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
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
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.
__
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
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 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
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
1 - 100 of 347 matches
Mail list logo
