Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On 2 April 2015 at 16:38, PJ Eby wrote: > > IOW, there's no need to modify the core just to have *that* feature, > since if you control the base class you can already do what PEP 487 > does in essentially every version of Python, ever. If that's all PEP > 487 is going to do, it should just be a PyPI package on a > stdlib-inclusion track, not a change to core Python. It's not > actually adding back any of the dynamicness (dynamicity? > hookability?) that PEP 3115 took away. The specific feature that PEP 487 is adding is the ability to customise creation of subclasses without risking the introduction of a metaclass conflict. That allows it to be used in situations where adopting any of the existing metaclass based mechanisms would require a potential compatibility break (as well as being far more approachable as a mechanism than the use of custom metaclasses). The gap I agree this approach leaves is a final post-namespace-execution step that supports establishing any class level invariants implied by decorators and other functions used in the class body. Python 2 allowed that to be handled with a dynamically generated __metaclass__ and PEP 422 through __autodecorate__, while PEP 487 currently has no equivalent mechanism. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OpenBSD buildbot has many failures
On 1 April 2015 at 17:32, Victor Stinner wrote: > Currently, there is an IRC bot on #python-dev which notify when buildbot > color changes. Or sometiles I chceck the huge waterfall page. By the way, it > became difficult to browse this page because there are too many offline > buildbots. The categorised links at https://www.python.org/dev/buildbot/ can be a bit more usable (but the stable links naturally exclude the systems we've never got working reliably in the first place). An idea that's been kicking around for a while has been to start using BuildBot's ephemeral test client support to kick off fresh VMs in Rackspace for x86_64 testing on the OS versions available there rather than relying solely on donated test systems. Unfortunately there are enough unknowns involved in that that we don't even know how hard its likely to be to set up without someone being in a position to contribute the time to start figuring it out. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 02, 2015 at 06:46:11PM +1000, Nick Coghlan wrote: > On 2 April 2015 at 16:38, PJ Eby wrote: > > IOW, there's no need to modify the core just to have *that* feature, > > since if you control the base class you can already do what PEP 487 > > does in essentially every version of Python, ever. If that's all PEP > > 487 is going to do, it should just be a PyPI package on a > > stdlib-inclusion track, not a change to core Python. It's not > > actually adding back any of the dynamicness (dynamicity? > > hookability?) that PEP 3115 took away. > > The specific feature that PEP 487 is adding is the ability to > customise creation of subclasses without risking the introduction of a > metaclass conflict. That allows it to be used in situations where > adopting any of the existing metaclass based mechanisms would require > a potential compatibility break (as well as being far more > approachable as a mechanism than the use of custom metaclasses). > > The gap I agree this approach leaves is a final > post-namespace-execution step that supports establishing any class > level invariants implied by decorators and other functions used in the > class body. Python 2 allowed that to be handled with a dynamically > generated __metaclass__ and PEP 422 through __autodecorate__, while > PEP 487 currently has no equivalent mechanism. Perhaps PEP 422 should be back in the running then (possible reduced in scope, I haven't read it in a while), along with PEP 487, since they seem to target different areas. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 2, 2015 at 4:46 AM, Nick Coghlan wrote: > On 2 April 2015 at 16:38, PJ Eby wrote: >> >> IOW, there's no need to modify the core just to have *that* feature, >> since if you control the base class you can already do what PEP 487 >> does in essentially every version of Python, ever. If that's all PEP >> 487 is going to do, it should just be a PyPI package on a >> stdlib-inclusion track, not a change to core Python. It's not >> actually adding back any of the dynamicness (dynamicity? >> hookability?) that PEP 3115 took away. > > The specific feature that PEP 487 is adding is the ability to > customise creation of subclasses without risking the introduction of a > metaclass conflict. That allows it to be used in situations where > adopting any of the existing metaclass based mechanisms would require > a potential compatibility break But metaclass conflicts are *also* fixable in end-user code, and have been since 2.2. All you need to do is use a metaclass *function* that automatically merges the metaclasses involved, which essentially amounts to doing `class MergedMeta(base1.__class__, base2.__class__,...)`. (Indeed, I've had a library for doing just that since 2002, that originally ran on Python 2.2,.) On Python 3, it's even easier to use that approach, because you can just use something like `class whatever(base1, base2, metaclass=noconflict)` whenever a conflict comes up. (And because the implementation wouldn't have to deal with classic classes or __metaclass__, as my Python 2 implementation has to.) IOW, *all* of PEP 487 is straightforward to implement in userspace as a metaclass and a function that already exist off-the-shelf in Python 2... and whose implementations would be simplified by porting them to Python 3, and dropping any extraneous features: * http://svn.eby-sarna.com/PEAK/src/peak/util/Meta.py?view=markup (the `makeClass` function does what my hypothetical `noconflict` above does, with a slightly different API, and support for classic classes, __metaclass__, etc., that could all be stripped out) * http://svn.eby-sarna.com/DecoratorTools/peak/util/decorators.py?view=markup (see the `classy_class` metaclass and `classy` mixin base that implement features similar to `__init_subclass__`, plus others that could be stripped out) Basically, you can pull out those functions/classes (and whatever else they use in those modules), port 'em to Python 3, make any API changes deemed suitable, and call it a day. And the resulting code could go to a stdlib metaclass utility module after a reasonable break-in period. > (as well as being far more > approachable as a mechanism than the use of custom metaclasses). Sure, nobody's arguing that it's not a desirable feature. I *implemented* that mechanism for Python 2 (eight years ago) because it's easier to use even for those of us who are fully versed in the dark metaclass arts. ;-) Here's the documentation: http://peak.telecommunity.com/DevCenter/DecoratorTools#meta-less-classes So the feature doesn't even require *stdlib* adoption, let alone changes to Python core. (Heck, I wasn't even the first to implement this feature: Zope had it for Python *1.5.2*, in their ExtensionClass.) It's a totally solved problem in Python 2, although the solution is admittedly not widely known. If the PEP 487 metaclass library, however, were to just port some bits of my code to Python 3 this could be a done deal already and available in *all* versions of Python 3, not just the next one. > The gap I agree this approach leaves is a final > post-namespace-execution step that supports establishing any class > level invariants implied by decorators and other functions used in the > class body. Python 2 allowed that to be handled with a dynamically > generated __metaclass__ and PEP 422 through __autodecorate__, while > PEP 487 currently has no equivalent mechanism. Right. And it's *only* having such a mechanism available by *default* that requires a language change. Conversely, if we *are* making a language change, then adding a hook that allows method decorators to access the just-defined class provides roughly the same generality that Python 2 had in this respect. All I want is the ability for method decorators to find out what class they were added to, at the time the class is built, rather than having to wait for an access or invocation that may never come. This could be as simple as __build_class__ or type.__call__ looking through the new class's dictionary for objects with a `__used_in_class__(cls, name)` method, e.g.: for k, v in dict.items(): if hasattr(v, '__used_in_class__'): v.__used_in_class__(cls, k) This doesn't do what PEP 487 or 422 do, but it's the bare minimum for what I need, and it actually allows this type of decorator to avoid any frame inspection because they can just add a __used_in_class__ attribute to the functions being decorated. (It actually also eliminates another common use for metaclasses and c
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 2, 2015 at 1:42 PM, PJ Eby wrote: > If the PEP 487 metaclass library, > however, were to just port some bits of my code to Python 3 this could > be a done deal already and available in *all* versions of Python 3, > not just the next one. Just for the heck of it, here's an actual implementation and demo of PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy of 3.3 handy): https://gist.github.com/pjeby/75ca26f8d2a7a0c68e30 The first module is just a demo that shows the features in use. The second module is the implementation. Notice that the actual *functionality* of PEP 487 is just *16 lines* in Python 3... including docstrings and an `__all__` definition. ;-) The other 90 lines of code are only there to implement the `noconflict` feature for fixing metaclass conflicts... and quite a lot of *those* lines are comments and docstrings. ;-) Anyway, I think this demo is a knockout argument for why PEP 487 doesn't need a language change: if you're writing an __init_subclass__ method you just include the `pep487.init_subclasses` base in your base classes, and you're done. It'll silently fail if you leave it out (but you'll notice that right away), and it *won't* fail in third-party subclasses because the *third party* didn't include it. In contrast, PEP 422 provided a way to have both the features contemplated by 487, *and* a way to allow method-level decorators to discover the class at class creation time. If there's going to be a language change, it should include that latter feature from the outset. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
Hi everyone, for those new to the discussion, I am the author of PEP 487, which has been discussed here: https://mail.python.org/pipermail/python-ideas/2015-February/032249.html > The concern is twofold: it breaks proper information hiding/DRY, *and* > it fails silently. It should not be necessary for clients of package > A1 (that uses a decorator built using package B2) to mixin a metaclass > or decorator from package C3 (because B2 implemented its decorators > using C3), just for package A1's decorator to work properly in the > *client package's class*. (And then, of course, this all silently > breaks if you forget, and the breakage might happen at the A1, B2, or > C3 level.) I am just not capable to understand things at such an abstract level, would it be possible to give a simple example on what and how you did things in python 2? > IOW, there's no need to modify the core just to have *that* feature, > since if you control the base class you can already do what PEP 487 > does in essentially every version of Python, ever. If that's all PEP > 487 is going to do, it should just be a PyPI package on a > stdlib-inclusion track, not a change to core Python. It's not > actually adding back any of the dynamicness (dynamicity? > hookability?) that PEP 3115 took away. That was my point. You can find the PyPI package at: https://pypi.python.org/pypi/metaclass Greetings Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
Hi everyone, > > If the PEP 487 metaclass library, > > however, were to just port some bits of my code to Python 3 this could > > be a done deal already and available in *all* versions of Python 3, > > not just the next one. > > Just for the heck of it, here's an actual implementation and demo of > PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy > of 3.3 handy): The implementation mentioned in PEP 487 itself even works on python 2.7. The whole point of PEP 487 was to reduce PEP 422 so much that it can be written in python and back-ported. This is also discussed in PEP 487. An updated discussion of PEP 487 can be found here: https://mail.python.org/pipermail/python-ideas/2015-March/032538.html Now you want to be able to write decorators whose details are filled in at class creation time. Currently this is typically done by a metaclass. With PEP 487 in place this can also be done using a mixin class. Your point is that you want to be able to use your decorators without having to ask users to also inherit a specific class. I personally don't think that's desirable. Many frameworks out there have such kind of decorators and mandatory base classes and that works fine. The only problem remains once you need to inherit more than one of those classes, as their metaclasses most likely clash. This is what PEP 487 fixes. It fixes this with just some handful lines of python code, but I consider that shortness an advantage. So my opinion is that it is not too hard a requirement to ask a user to inherit a specific mixin class for the sake of using a decorator. What do other people think? Greetings Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] version of freshly built 2.7 python
I just built the latest version of Python 2.7 on my development machine -- or so I thought. When I invoke it, I get: Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) Why am I not seeing 2.7.9? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On 3 April 2015 at 08:24, Martin Teichmann wrote: > Hi everyone, > >> > If the PEP 487 metaclass library, >> > however, were to just port some bits of my code to Python 3 this could >> > be a done deal already and available in *all* versions of Python 3, >> > not just the next one. >> >> Just for the heck of it, here's an actual implementation and demo of >> PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy >> of 3.3 handy): > > The implementation mentioned in PEP 487 itself even works on > python 2.7. > > The whole point of PEP 487 was to reduce PEP 422 so much that > it can be written in python and back-ported. This is also discussed in > PEP 487. An updated discussion of PEP 487 can be found here: > https://mail.python.org/pipermail/python-ideas/2015-March/032538.html > > Now you want to be able to write decorators whose details > are filled in at class creation time. Currently this is typically done > by a metaclass. With PEP 487 in place this can also be > done using a mixin class. > > Your point is that you want to be able to use your decorators > without having to ask users to also inherit a specific class. > I personally don't think that's desirable. Many frameworks out > there have such kind of decorators and mandatory base classes > and that works fine. The only problem remains once you need to > inherit more than one of those classes, as their metaclasses > most likely clash. This is what PEP 487 fixes. It fixes this with > just some handful lines of python code, but I consider that > shortness an advantage. > > So my opinion is that it is not too hard a requirement to ask > a user to inherit a specific mixin class for the sake of using > a decorator. What do other people think? If I'm understanding PJE's main concern correctly it's that this approach requires explicitly testing that the decorator has been applied correctly in your automated tests every time you use it, as otherwise there's a risk of a silent failure when you use the decorator but omit the mandatory base class that makes the decorator work correctly. I'm actually OK with the "mandatory base class" approach myself - it's the way most Python frameworks operate, and it acts as a visible indicator of the "concept space" a particular class is operating in (e.g. "Django Form", "SQL Alchemy Model") rather than having that information be implicit in the decorators being used. However, I'm also now wondering if it may be possible to reach out to the pylint authors (similar to what Brett did for the "pylint --py3k" flag) and ask for a way to make it easy to register "base class, decorator" pairs where pylint will complain if it sees a particular method decorator but can't determine at analysis time if the named base class is in the MRO for the class defining the method. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann wrote: > The whole point of PEP 487 was to reduce PEP 422 so much that > it can be written in python and back-ported. As I said earlier, it's a fine feature and should be in the stdlib for Python 3. (But it should have a `noconflict` feature added, and it doesn't need a language change.) However, since my specific use case was the one PEP 422 was originally written to solve, and PEP 487 does not address that use case, it is not a suitable substitute *for PEP 422*. This is also not your fault; you didn't force Nick to withdraw it, after all. ;-) My main concern in this thread, however, is ensuring that either the use case behind PEP 422 doesn't get dropped, or that Nick is now okay with me implementing that feature by monkeypatching __build_class__. Since he practically begged me not to do that in 2012, and IIRC *specifically created* PEP 422 to provide an alternative way for me to accomplish this *specific* use case, I wanted to see what his current take was. (That is, did he forget the history of the PEP, or does he no longer care about userspace code hooking __build_class__? Is there some other proposal that would be a viable alternative? etc.) > Now you want to be able to write decorators whose details > are filled in at class creation time. Not "now"; it's been possible to do this in Python 2 for over a decade, and code that does so is in current use by other packages. The package providing this feature (DecoratorTools) was downloaded 145 times today, and 3274 times in the past month, so there is active, current use of it by other Python 2 packages. (Though I don't know how many of them depend directly or indirectly upon this particular feature.) Currently, however, it is not possible to port this feature of DecoratorTools (or any other package that uses that feature, recursively) to Python 3, due to the removal of __metaclass__ and the lack of any suitable substitute hook. > Your point is that you want to be able to use your decorators > without having to ask users to also inherit a specific class. > I personally don't think that's desirable. Many frameworks out > there have such kind of decorators and mandatory base classes > and that works fine. The intended use case is for generic method decorators that have nothing to do with the base class per se, so inheriting from a specific base-class is an anti-feature in this case. > The only problem remains once you need to > inherit more than one of those classes, as their metaclasses > most likely clash. This is what PEP 487 fixes. No, it addresses the issue for certain *specific* metaclass use cases. It does not solve the problem of metaclass conflict in general; for that you need something like the sample `noconflict` code I posted, which works for Python 3.1+ and doesn't require a language change. > So my opinion is that it is not too hard a requirement to ask > a user to inherit a specific mixin class for the sake of using > a decorator. If this logic were applied to PEP 487 as it currently stands, the PEP should be rejected, since its use case is even *more* easily accomplished by inheriting from a specific mixin class. (Since the feature only works on subclasses anyway!) Further, if the claim is that metaclass conflict potential makes PEP 487 worthy of a language change, then by the same logic method decorators are just as worthy of a language change, since any mixin required to use a method decorator would be *just as susceptible* to metaclass conflicts as SubclassInit. (Notably, the stdlib's ABCMeta is a common cause of metaclass conflicts in Python 2.6+ -- if you mix in anything that implements an ABC by subclassing it, you will get a metaclass conflict.) Finally, I of course disagree with the conclusion that it's okay to require mixins in order for method decorators to access the containing class, since it is not a requirement in Python 2, due to the availability of the __metaclass__ hook. Further, PEP 422 was previously approved to fix this problem, and has a patch in progress, so I'm understandably upset by its sudden withdrawal and lack of suitable replacement. So personally, I think that PEP 422 should be un-withdrawn (or replaced with something else), and PEP 487 should be retargeted towards defining a `metaclass` module for the stdlib, including a `noconflict` implementation to address metaclass conflict issues. (Mine or someone else's, as long as it works.) PEP 487 should not be a proposal to change the language, as the provided features don't require it. (And it definitely shouldn't pre-empt a separately useful feature that *does* require a language change.) At this point, though, I mostly just want to get some kind of closure. After three years, I'd like to know if this is a yea or nay, so I can port the thing and move on, whether it's through a standardized mechanism or ugly monkeypatching. Honestly, the only reason I'm even discussing this in the first
Re: [Python-Dev] version of freshly built 2.7 python
Are you building from mercurial or a source tarball? On 4/2/2015 21:29, Ethan Furman wrote: I just built the latest version of Python 2.7 on my development machine -- or so I thought. When I invoke it, I get: Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) Why am I not seeing 2.7.9? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version of freshly built 2.7 python
On Thursday, April 2, 2015, Ethan Furman wrote: > I just built the latest version of Python 2.7 on my development machine -- > or so I thought. When I invoke it, I get: > > Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) > > Why am I not seeing 2.7.9? > https://hg.python.org/cpython/rev/1beb3e0507fa/ I'd say update and try again. Taking a wild guess as to why you're on the wrong revision, if you use the hg 'share' extension to keep separate working copies of each branch, remember that 'hg pull --update' doesn't update if you already have all changesets from the server due to a pull in another 'shared' copy. Hope this helps, -- Zach -- Sent from Gmail Mobile ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On 04/03/2015 02:31 PM, Nick Coghlan wrote: If I'm understanding PJE's main concern correctly it's that this approach requires explicitly testing that the decorator has been applied correctly in your automated tests every time you use it, as otherwise there's a risk of a silent failure when you use the decorator but omit the mandatory base class that makes the decorator work correctly. Could the decorator be designed to detect that situation somehow? E.g. the first time the decorated method is called, check that the required base class is present. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 2, 2015 at 10:29 PM, Greg Ewing wrote: > On 04/03/2015 02:31 PM, Nick Coghlan wrote: >> >> If I'm understanding PJE's main concern correctly it's that this >> approach requires explicitly testing that the decorator has been >> applied correctly in your automated tests every time you use it, as >> otherwise there's a risk of a silent failure when you use the >> decorator but omit the mandatory base class that makes the decorator >> work correctly. > > > Could the decorator be designed to detect that situation > somehow? E.g. the first time the decorated method is called, > check that the required base class is present. No, because in the most relevant use case, the method will never be called if the base class isn't present. For more details, see also the previous discussion at https://mail.python.org/pipermail/python-dev/2012-June/119883.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On 04/03, Greg Ewing wrote: > On 04/03/2015 02:31 PM, Nick Coghlan wrote: >> If I'm understanding PJE's main concern correctly it's that this >> approach requires explicitly testing that the decorator has been >> applied correctly in your automated tests every time you use it, as >> otherwise there's a risk of a silent failure when you use the >> decorator but omit the mandatory base class that makes the decorator >> work correctly. > > Could the decorator be designed to detect that situation > somehow? E.g. the first time the decorated method is called, > check that the required base class is present. That feels like a horrible work-around. The proper place for setup code is in the set up. -- ~Ethan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)
On Thu, Apr 2, 2015 at 9:31 PM, Nick Coghlan wrote: > On 3 April 2015 at 08:24, Martin Teichmann wrote: > However, I'm also now wondering if it may be possible to reach out to > the pylint authors (similar to what Brett did for the "pylint --py3k" > flag) and ask for a way to make it easy to register "base class, > decorator" pairs where pylint will complain if it sees a particular > method decorator but can't determine at analysis time if the named > base class is in the MRO for the class defining the method. Will it *also* check the calling chain of the decorator, or any other thing that's called or invoked in the class body,to find out if somewhere, somehow, it asks for a class decoration? If not, it's not going to help with this use case. There are many ways to solve this problem by re-adding a hook -- you and I have proposed several, in 2012 and now. There are none, however, which do not involve putting back the hookability that Python 3 took out, except by using hacks like sys.set_trace() or monkeypatching __build_class__. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version of freshly built 2.7 python
On 04/02, Alexander Walters wrote: > On 4/2/2015 21:29, Ethan Furman wrote: >> >> I just built the latest version of Python 2.7 on my development machine -- >> or so I thought. When I invoke it, I get: >> >>Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) >> >> Why am I not seeing 2.7.9? > > Are you building from mercurial or a source tarball? Mercurial: ethan@code:~/source/python/python2.7$ hg parent changeset: 90450:1beb3e0507fa branch: 2.7 parent: 90434:b428b803f71f user:Zachary Ware date:Thu Apr 24 13:20:27 2014 -0500 files: Lib/test/test_itertools.py description: Issue #21346: Fix typos in test_itertools. Patch by Brian Kearns. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version of freshly built 2.7 python
On Thu, Apr 2, 2015 at 10:19 PM, Ethan Furman wrote: > On 04/02, Alexander Walters wrote: >> On 4/2/2015 21:29, Ethan Furman wrote: >>> >>> I just built the latest version of Python 2.7 on my development machine -- >>> or so I thought. When I invoke it, I get: >>> >>>Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) >>> >>> Why am I not seeing 2.7.9? >> >> Are you building from mercurial or a source tarball? > > Mercurial: > > ethan@code:~/source/python/python2.7$ hg parent > changeset: 90450:1beb3e0507fa > branch: 2.7 > parent: 90434:b428b803f71f > user:Zachary Ware > date:Thu Apr 24 13:20:27 2014 -0500 > files: Lib/test/test_itertools.py > description: > Issue #21346: Fix typos in test_itertools. Patch by Brian Kearns. That's almost a year old. Update it? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version of freshly built 2.7 python
On 04/02, Brian Curtin wrote: > On Thu, Apr 2, 2015 at 10:19 PM, Ethan Furman wrote: >> On 04/02, Alexander Walters wrote: >>> On 4/2/2015 21:29, Ethan Furman wrote: I just built the latest version of Python 2.7 on my development machine -- or so I thought. When I invoke it, I get: Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) Why am I not seeing 2.7.9? >>> >>> Are you building from mercurial or a source tarball? >> >> Mercurial: >> >> ethan@code:~/source/python/python2.7$ hg parent >> changeset: 90450:1beb3e0507fa >> branch: 2.7 >> parent: 90434:b428b803f71f >> user:Zachary Ware >> date:Thu Apr 24 13:20:27 2014 -0500 >> files: Lib/test/test_itertools.py >> description: >> Issue #21346: Fix typos in test_itertools. Patch by Brian Kearns. > > That's almost a year old. Update it? A fresh pull only garnared 13 new commits, and an hg update in the 2.7 directory changed nothing. I even tried updating to default, then back to 2.7, but I get the same parent. hg branches shows default90453:d84a69b7ba72 2.790450:1beb3e0507fa 3.190264:c7b93519807a 2.690100:23a60d89dbd4 3.490451:901b9afc918e (inactive) 3.390266:a8445ead2f9e (inactive) 3.290265:0a7d4cdc4c8d (inactive) hmmm... those numbers are about 5000 off! Okay, deleting and recloning... Okay, the revisions are matching up now -- don't know what happened, but nothing a simple nuke couldn't solve! Now-wondering-if-I-ever-did-an-hg-pull'ly yrs, ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
