Re: [Python-Dev] Deprecation policy
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 until someone notices it; > 4) actually remove it; > > I suggest to follow the following process: > 1) deprecate something and add a DeprecationWarning; > 2) decide how long the deprecation should last; > 3) use the deprecated-remove[1] directive to document it; > 4) add a test that fails after the update so that we remember to remove > it[2]; 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 to actually remove support for something in the standard library. 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. Raymond___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 a recommendation to use > something else instead. > There is rarely a need to actually remove support for something in the > standard library. The problem with "deprecating and not removing" (and worse, only informally deprecating by leaving a note in the documentation) is that you end up with zombie APIs: there are tons of tutorials & such on the web talking about them, they're not maintained, nobody really cares about them (but users who found them via Google) and they're all around harmful. It's the current state of many JDK 1.0 and 1.1 APIs and it's dreadful, most of them are more than a decade out of date, sometimes retrofitted for new interfaces (but APIs using them usually are *not* fixed, keeping them in their state of partial death), sometimes still *taught*, all of that because they're only informally deprecated (at best, sometimes not even that as other APIs still depend on them). It's bad for (language) users because they use outdated and partially unmaintained (at least in that it's not improved) APIs and it's bad for (language) maintainers in that once in a while they still have to dive into those things and fix bugs cropping up without the better understanding they have from the old APIs or the cleaner codebase they got from it. 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 users, but in the long run I do think zombie APIs are worse. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 by default). Both choices are harmful to users, but in the long run > I do think zombie APIs are worse. But restricting ourselves to cleaning out such APIs every 10 years or so with a major version bump is also a potentially viable option. So long as the old APIs are fully tested and aren't actively *harmful* to creating reasonable code (e.g. optparse) then refraining from killing them before the (still hypothetical) 4.0 is reasonable. OTOH, genuinely problematic APIs that ideally wouldn't have survived even the 3.x transition (e.g. the APIs that the 3.x subprocess module inherited from the 2.x commands module that run completely counter to the design principles of the subprocess module) should probably still be considered for removal as soon as is reasonable after a superior alternative is made available. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 users, but in the long run I do think zombie APIs are worse. I would much rather have my code relying on "zombie" APIs and keep working, than to have that code suddenly stop working when the zombie is removed. Working code should stay working. Unless the zombie is actively harmful, what's the big deal if there is a newer, better way of doing something? If it works, and if it's fast enough, why force people to "fix" it? It is a good thing that code or tutorials from Python 1.5 still (mostly) work, even when there are newer, better ways of doing something. I see a lot of newbies, and the frustration they suffer when they accidentally (carelessly) try following 2.x instructions in Python3, or vice versa, is great. It's bad enough (probably unavoidable) that this happens during a major transition like 2 to 3, without it also happening during minor releases. Unless there is a good reason to actively remove an API, it should stay as long as possible. "I don't like this and it should go" is not a good reason, nor is "but there's a better way you should use". When in doubt, please don't break people's code. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On 12:14 pm, [email protected] 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 by default). Both choices are harmful to users, but in the long run I do think zombie APIs are worse. I would much rather have my code relying on "zombie" APIs and keep working, than to have that code suddenly stop working when the zombie is removed. Working code should stay working. Unless the zombie is actively harmful, what's the big deal if there is a newer, better way of doing something? If it works, and if it's fast enough, why force people to "fix" it? It is a good thing that code or tutorials from Python 1.5 still (mostly) work, even when there are newer, better ways of doing something. I see a lot of newbies, and the frustration they suffer when they accidentally (carelessly) try following 2.x instructions in Python3, or vice versa, is great. It's bad enough (probably unavoidable) that this happens during a major transition like 2 to 3, without it also happening during minor releases. Unless there is a good reason to actively remove an API, it should stay as long as possible. "I don't like this and it should go" is not a good reason, nor is "but there's a better way you should use". When in doubt, please don't break people's code. +1 Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 manage them (as DeprecationWarning was
>> silenced by default). Both choices are harmful to users, but in the long run
>> I do think zombie APIs are worse.
>
> But restricting ourselves to cleaning out such APIs every 10 years or
> so with a major version bump is also a potentially viable option.
>
> So long as the old APIs are fully tested and aren't actively *harmful*
> to creating reasonable code (e.g. optparse) then refraining from
> killing them before the (still hypothetical) 4.0 is reasonable.
Sure, the original proposal leaves the deprecation timelines as TBD and I hope
I did not give the impression of setting up a timeline (that was not the
intention). Ezio's original proposal could simply be implemented by having the
second step ("decide how long the deprecation should last") default to "the
next major release", I don't think that goes against his proposal, and in case
APIs are actively harmful (e.g. very hard to use correctly) the deprecation
timeline can be accelerated specifically for that case.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 to actually remove support for something in > the standard library. > > 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 against breaking backwards compatiblity between minor versions (e.g. 3.2 and 3.3). If something is removed in this manner, the transition period should at least be very, very long. To me, deprecating an API means "this code will not get new features and possibly not even (big) fixes". It's important for the long term health of a project to be able to deprecate and eventually remove code that is no longer maintained. So, I think we should have a clear and working deprecation policy, and Ezio's suggestion sounds good to me. There should be a clean way to state, in both code and documentation, that something is deprecated, do not use in new code. Furthermore, deprecated code should actually be removed when the time comes, be it Python 4.0 or something else. Petri ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 against breaking backwards compatiblity between minor >versions (e.g. 3.2 and 3.3). If something is removed in this manner, >the transition period should at least be very, very long. +1 It's even been a pain when porting between Python 2.x and 3. You'll see some things that were carried forward into Python 3.0 and 3.1 but are now gone in 3.2. So if you port from 2.7 -> 3.2 for example, you'll find a few things missing (the intobject.h aliases come to mind). For those reasons I think we need to be conservative about removing stuff. Once the world is all on Python 3 we can think about removing code. Cheers, -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 else instead. There is rarely a need to actually remove support for something in the standard library. 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 against breaking backwards compatiblity between minor versions (e.g. 3.2 and 3.3). If something is removed in this manner, the transition period should at least be very, very long. We tend to see 3.2 -> 3.3 as a "major version" increment, but that's just Python's terminology. Nonetheless, our usual deprecation policy has been a *minimum* of deprecated for two releases and removed in a third (if at all) - which is about five years from deprecation to removal given our normal release rate. The water is muddied by Python 3, where we may deprecate something in Python 3.1 and remove in 3.3 (hypothetically) - but users may go straight from Python 2.7 to 3.3 and skip the deprecation period altogether... So we should be extra conservative about removals in Python 3 (for the moment at least). To me, deprecating an API means "this code will not get new features and possibly not even (big) fixes". It's important for the long term health of a project to be able to deprecate and eventually remove code that is no longer maintained. The issue is that deprecated code can still be a maintenance burden. Keeping deprecated APIs around can require effort just to keep them working and may actively *prevent* other changes / improvements. All the best, Michael Foord So, I think we should have a clear and working deprecation policy, and Ezio's suggestion sounds good to me. There should be a clean way to state, in both code and documentation, that something is deprecated, do not use in new code. Furthermore, deprecated code should actually be removed when the time comes, be it Python 4.0 or something else. Petri ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 DeprecationWarning was >> silenced by default). Both choices are harmful to users, but in the long >> run I do think zombie APIs are worse. > > I would much rather have my code relying on "zombie" APIs and keep working, > than to have that code suddenly stop working when the zombie is removed. > Working code should stay working. Unless the zombie is actively harmful, > what's the big deal if there is a newer, better way of doing something? If > it works, and if it's fast enough, why force people to "fix" it? > > It is a good thing that code or tutorials from Python 1.5 still (mostly) > work, even when there are newer, better ways of doing something. I see a lot > of newbies, and the frustration they suffer when they accidentally > (carelessly) try following 2.x instructions in Python3, or vice versa, is > great. It's bad enough (probably unavoidable) that this happens during a > major transition like 2 to 3, without it also happening during minor > releases. > > Unless there is a good reason to actively remove an API, it should stay as > long as possible. "I don't like this and it should go" is not a good reason, > nor is "but there's a better way you should use". When in doubt, please > don't break people's code. 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 want our favourite things in the standard lib for this reason), and or the old stuff lingers... I'm sure a while ago there was mention of a "staging" area for inclusion in the standard library. This attracts interest, stabilization, and quality from potential modules for inclusion. Better yet, the existing standard library ownership is somehow detached from the CPython core, so that changes enabling easier customization to fit other implementations (jpython, pypy etc.) are possible. tl;dr old stuff blocks new hotness. make room or separate standard library concerns from cpython > > > > -- > Steven > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
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 modified directory. The > > > > problem was always things like changing interface between the C > > > > version and the Python version or introduction of new stuff that does > > > > not run on pypy because it relies on refcounting. I don't see how > > > > having a subrepo helps here. > > > > > > Indeed, the main thing that can help on this front is to get more > > > modules to the same state as heapq, io, datetime (and perhaps a few > > > others that have slipped my mind) where the CPython repo actually > > > contains both C and Python implementations and the test suite > > > exercises both to make sure their interfaces remain suitably > > > consistent (even though, during normal operation, CPython users will > > > only ever hit the C accelerated version). > > > > > > This not only helps other implementations (by keeping a Python version > > > of the module continuously up to date with any semantic changes), but > > > can help people that are porting CPython to new platforms: the C > > > extension modules are far more likely to break in that situation than > > > the pure Python equivalents, and a relatively slow fallback is often > > > going to be better than no fallback at all. (Note that ctypes based > > > pure Python modules *aren't* particularly useful for this purpose, > > > though - due to the libffi dependency, ctypes is one of the extension > > > modules most likely to break when porting). > > > > > > > And the other reason I plan to see this through before I die > > Uh! Any bad news? :/ Sorry, turn of phrase in English which didn't translate well. I just meant "when I get to it, which could quite possibly be a *long* time from now". This year has been absolutely insane for me personally (if people care, the details are shared on Google+ or you can just ask me), so I am just not promising anything for Python on a short timescale (although I'm still hoping the final details for bootstrapping importlib won't be difficult to work out so I can meet a personal deadline of PyCon). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 want our > favourite things in the standard lib for this reason), and or the old > stuff lingers... 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 unlimited supply of one-off patches to add cool new features (not backed by a long term warranty of maintenance by the contributor). So deprecated features do add some burden of maintenance for the core developers, as Michael points out -- but removing *all* of them on short notice would not really make it possible to *add* features *in a maintainable way* any faster. > I'm sure a while ago there was mention of a "staging" area for > inclusion in the standard library. This attracts interest, > stabilization, and quality from potential modules for inclusion. But there's no particular reason to believe it will attract more contributors willing to do long-term maintenance, and *somebody* has to maintain the staging area. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New features
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 unlimited supply of one-off patches to add cool new > features (not backed by a long term warranty of maintenance by the > contributor). Actually, we don't often get patches for new features. Many new features are implemented by core developers themselves. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New features
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 are. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
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 DeprecationWarning; > > 2) forget about it after a while; > > 3) wait a few versions until someone notices it; > > 4) actually remove it; > > > > I suggest to follow the following process: > > 1) deprecate something and add a DeprecationWarning; > > 2) decide how long the deprecation should last; > > 3) use the deprecated-remove[1] directive to document it; > > 4) add a test that fails after the update so that we remember to remove > > it[2]; > > 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. Well, it's not like we aren't already conservative in deprecating things. > Instead, it is best to mark APIs as obsolete with a recommendation to use > something else instead. > There is rarely a need to actually remove support for something in the > standard library. > 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 agree with Xavier's answer that having recipes around which use outdated (and possibly inefficient/insecure/etc.) APIs is a nuisance. Also, deprecated-but-not-removed APIs come at a maintenance and support cost. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Long term development external named branches and periodic merges from python
-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. > > No, "Create Patch" is smarter than that. What it does (or tries to > do) is walk back through your branch history, trying to find the > last point where you merged in a changeset that it recognises as > coming from the main CPython repo. It then uses that revision of > the CPython repo as the basis for the diff. Oh, that sounds quite the right way. Clever. > So if you're just working on a feature branch, periodically > pulling from hg.python.org/cpython and merging from default, then > it should all work fine. So, my original question is answered as "yes, you can merge in changes from mainline, and 'create patch' will work as it should". Good!!. Thanks!!!. >> Anybody knows the mercurial command used to implement "create >> patch"?. > > It's not a single command - it's a short script MvL wrote that > uses the Mercurial API to traverse the branch history and find an > appropriate revision to diff against. Publish out somewhere would be useful, I guess. This is a problem I have found in a few other projects. I can see even a modifier for "hg diff" for a future mercurial version :-). Could be implemented as a command line command using "revsets"?. Propose a new revset to mercurial devels? - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM KjAMzrgPcSA= =zViH -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Long term development external named branches and periodic merges from python
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 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. > > > > No, "Create Patch" is smarter than that. What it does (or tries to > > do) is walk back through your branch history, trying to find the > > last point where you merged in a changeset that it recognises as > > coming from the main CPython repo. It then uses that revision of > > the CPython repo as the basis for the diff. > > Oh, that sounds quite the right way. Clever. > > > So if you're just working on a feature branch, periodically > > pulling from hg.python.org/cpython and merging from default, then > > it should all work fine. > > So, my original question is answered as "yes, you can merge in changes > from mainline, and 'create patch' will work as it should". > > Good!!. Thanks!!!. > > >> Anybody knows the mercurial command used to implement "create > >> patch"?. > > > > It's not a single command - it's a short script MvL wrote that > > uses the Mercurial API to traverse the branch history and find an > > appropriate revision to diff against. > > Publish out somewhere would be useful, I guess. This is a problem I > have found in a few other projects. I can see even a modifier for "hg > diff" for a future mercurial version :-). > > Could be implemented as a command line command using "revsets"?. > Propose a new revset to mercurial devels? > > - -- > Jesus Cea Avion _/_/ _/_/_/_/_/_/ > [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ > jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ > . _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I > kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ > QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM > KjAMzrgPcSA= > =zViH > -END PGP SIGNATURE- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
