It's published as part of the tracker repo, although I'm not sure exactly
where it lives.
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Nov 29, 2011 6:50 AM, "Jesus Cea" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 28/11/11 06:06, Nick Coghla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/11/11 06:06, Nick Coghlan wrote:
>> So, in this context, if the tracker "create patch" diff from
>> BASE, it is not "safe" to merge changes from mainline to the
>> branch, because if so "create patch" would include code not
>> related to my work.
Hi,
On Mon, 28 Nov 2011 01:30:53 -0800
Raymond Hettinger wrote:
>
> On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
>
> > Hi,
> > our current deprecation policy is not so well defined (see e.g. [0]), and
> > it seems to me that it's something like:
> > 1) deprecate something and add a Depre
Antoine Pitrou writes:
> Actually, we don't often get patches for new features. Many new
> features are implemented by core developers themselves.
Right. That's not inconsistent with what I wrote, as long as would-be
feature submitters realize what the standards for an acceptable
feature patch
On Tue, 29 Nov 2011 00:19:50 +0900
"Stephen J. Turnbull" wrote:
>
> Deprecated features are pretty much irrelevant to the height of the
> bar for new features. The problem is that there are a limited number
> of folks doing long term maintenance of the standard library, and an
> essentially unli
Matt Joiner writes:
> This is a great argument. But people want to see new, bigger better
> things in the standard library, and the #1 reason cited against this
> is "we already have too much". I think that's where the issue lies:
> Either lots of cool nice stuff is added and supported (we all
On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 12:37:59 -0500
> Brett Cannon wrote:
> > On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote:
> >
> > > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski >
> > > wrote:
> > > > The problem is not with maintaining the m
On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano wrote:
> Xavier Morel wrote:
>
>> Not being too eager to kill APIs is good, but giving rise to this kind of
>> living-dead APIs is no better in my opinion, even more so since Python has
>> lost one of the few tools it had to manage them (as Depreca
On 28/11/2011 13:36, Petri Lehtinen wrote:
Raymond Hettinger wrote:
How about we agree that actually removing things is usually bad for users.
It will be best if the core devs had a strong aversion to removal.
Instead, it is best to mark APIs as obsolete with a recommendation to use
something el
On Nov 28, 2011, at 03:36 PM, Petri Lehtinen wrote:
>Raymond Hettinger wrote:
>> That may serve a notion of tidyness or somesuch but in reality it is
>> a PITA for users making it more difficult to upgrade python versions
>> and making it more difficult to use published recipes.
>
>I'm strongly ag
Raymond Hettinger wrote:
> How about we agree that actually removing things is usually bad for users.
> It will be best if the core devs had a strong aversion to removal.
> Instead, it is best to mark APIs as obsolete with a recommendation to use
> something else instead.
>
> There is rarely a need
On 2011-11-28, at 13:06 , Nick Coghlan wrote:
> On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel wrote:
>> Not being too eager to kill APIs is good, but giving rise to this kind of
>> living-dead APIs is no better in my opinion, even more so since Python has
>> lost one of the few tools it had to m
On 12:14 pm, st...@pearwood.info wrote:
Xavier Morel wrote:
Not being too eager to kill APIs is good, but giving rise to this kind
of
living-dead APIs is no better in my opinion, even more so since Python
has
lost one of the few tools it had to manage them (as DeprecationWarning
was
silenced b
Xavier Morel wrote:
Not being too eager to kill APIs is good, but giving rise to this kind of
living-dead APIs is no better in my opinion, even more so since Python has
lost one of the few tools it had to manage them (as DeprecationWarning was
silenced by default). Both choices are harmful to us
On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel wrote:
> Not being too eager to kill APIs is good, but giving rise to this kind of
> living-dead APIs is no better in my opinion, even more so since Python has
> lost one of the few tools it had to manage them (as DeprecationWarning was
> silenced b
On 2011-11-28, at 10:30 , Raymond Hettinger wrote:
> On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
> How about we agree that actually removing things is usually bad for users.
> It will be best if the core devs had a strong aversion to removal.
> Instead, it is best to mark APIs as obsolete with
On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
> Hi,
> our current deprecation policy is not so well defined (see e.g. [0]), and it
> seems to me that it's something like:
> 1) deprecate something and add a DeprecationWarning;
> 2) forget about it after a while;
> 3) wait a few versions unt
17 matches
Mail list logo
