Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sat, Nov 29, 2014 at 3:27 PM, Donald Stufft wrote: > As promised in the "Move selected documentation repos to PSF BitBucket > account?" thread I've written up a PEP for moving selected repositories from > hg.python.org to Github. FWIW, I'm a pretty solid -1 to this PEP. Don't get me wrong, I

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Specifically, which features are most ideal here? - [ ] Userbase - [ ] TTW editing only over SSL (see: Zope 2) - [ ] Pull Requests (see also: BitBucket, Torvalds rant) - [ ] Simple Issue Tagging - [ ] Pingbacks - [ ] CI Integration On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft wrote: > > > O

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 12:06 AM, Ben Finney wrote: > > Nick Coghlan writes: > >> 1. I strongly believe that the long term sustainability of the overall >> open source community requires the availability and use of open source >> infrastructure. > > I concur. This article http://mako.cc/writing

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, Nov 30, 2014 at 4:06 PM, Ben Finney wrote: > I don't get a vote. So I'm glad there are some within the Python core > development team that can see the mistakes inherent in depending on > non-free tools for developing free software. While this is a laudable view, this kind of extreme stanc

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Nick Coghlan writes: > 1. I strongly believe that the long term sustainability of the overall > open source community requires the availability and use of open source > infrastructure. I concur. This article http://mako.cc/writing/hill-free_tools.html> makes the arguments well, IMO. > 2. I also

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 29, 2014, at 9:01 PM, Donald Stufft wrote: > >> >> The PEP should also cover providing clear instructions for setting up >> git-remote-hg with the remaining Mercurial repos (most notably CPython), as >> well as documenting a supported workflow for generating patches based on the >>

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

All the use cases seem to be about adding some kind of getattr hook to modules. They all seem to involve modifying the CPython C code anyway. So why not tackle that problem head-on and modify module_getattro() to look for a global named __getattr__ and if it exists, call that instead of raising Att

Re: [Python-Dev] PEP 479

On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett wrote: > I have a strong suspicion that I'm missing something; I have been > persuaded both directions too often to believe I have a grip on the > real issue. > > So I'm putting out some assumptions; please tell me if I'm wrong, and > maybe make them

[Python-Dev] PEP 479

I have a strong suspicion that I'm missing something; I have been persuaded both directions too often to believe I have a grip on the real issue. So I'm putting out some assumptions; please tell me if I'm wrong, and maybe make them more explicit in the PEP. (1) The change will only affect situat

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 29, 2014, at 8:12 PM, Nick Coghlan wrote: > > > On 30 Nov 2014 09:28, "Donald Stufft" > wrote: > > > > As promised in the "Move selected documentation repos to PSF BitBucket > > account?" thread I've written up a PEP for moving selected repositories from > > h

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, Nov 30, 2014 at 11:37 AM, Donald Stufft wrote: > I also don’t know how to do this. When I’m doing multiple things for CPython > my “branching” strategy is essentially using hg diff to create a patch file > with my “branch” name (``hg diff > my-branch.patch``), then revert all of my > chang

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 29, 2014, at 7:43 PM, Antoine Pitrou wrote: > > On Sun, 30 Nov 2014 00:15:55 + (UTC) > Alex Gaynor wrote: >> >> The seconds experience I have is that of Django's migration to git and >> github. >> For a long time we were on SVN, and we were very resistant to moving to >> DVCS in

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 30 Nov 2014 09:28, "Donald Stufft" wrote: > > As promised in the "Move selected documentation repos to PSF BitBucket > account?" thread I've written up a PEP for moving selected repositories from > hg.python.org to Github. > > You can see this PEP online at: https://www.python.org/dev/peps/pep-

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Sun, 30 Nov 2014 00:15:55 + (UTC) Alex Gaynor wrote: > > The seconds experience I have is that of Django's migration to git and github. > For a long time we were on SVN, and we were very resistant to moving to > DVCS in > general, and github in particular. Multiple times I said that I did

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 29, 2014, at 7:15 PM, Alex Gaynor wrote: > > Donald Stufft stufft.io> writes: > >> >> [words words words] >> > > I strongly support this PEP. I'd like to share two pieces of information. Both > of these are personal anecdotes: > > For the past several years, I've been a contributo

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sun, Nov 30, 2014 at 12:05 AM, Steven D'Aprano wrote: > On Sun, Nov 30, 2014 at 11:07:57AM +1300, Greg Ewing wrote: >> Nathaniel Smith wrote: >> >So pkgname/__new__.py might look like: >> > >> >import sys >> >from pkgname._metamodule import MyModuleSubtype >> >sys.modules[__name__]

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 29, 2014, at 6:27 PM, Donald Stufft wrote: > > [lots of words] Just FYI, I’ve pushed an update to the PEP. Nothing major just some grammatical fixes and such. The revision is here: https://hg.python.org/peps/rev/6c6947dbd13f For whatever it's worth, the person who submitted that patc

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Donald Stufft stufft.io> writes: > > [words words words] > I strongly support this PEP. I'd like to share two pieces of information. Both of these are personal anecdotes: For the past several years, I've been a contributor on two major projects using mercurial, CPython and PyPy. PyPy has a stro

[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

As promised in the "Move selected documentation repos to PSF BitBucket account?" thread I've written up a PEP for moving selected repositories from hg.python.org to Github. You can see this PEP online at: https://www.python.org/dev/peps/pep-0481/ I've also reproduced the PEP below for inline disc

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sun, Nov 30, 2014 at 11:07:57AM +1300, Greg Ewing wrote: > Nathaniel Smith wrote: > >So pkgname/__new__.py might look like: > > > >import sys > >from pkgname._metamodule import MyModuleSubtype > >sys.modules[__name__] = MyModuleSubtype(__name__, docstring) > > > >To start with, the '

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, Nov 29, 2014 at 8:37 PM, Nathaniel Smith wrote: [...] > The python-ideas thread did also consider several methods of > implementing strategy (c), but they're messy enough that I left them > out here. The problem is that somehow we have to execute code to > create the new subtype *before* w

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 11/28/2014 09:34 AM, Demian Brecht wrote: > > I primarily use git for development. Having little or no effort to > context switch to work on CPython in any capacity (PEPs, code, etc) > would be hugely beneficial for me. Having a well defined workflow in > the docs (perhaps alongside "Lifecycle

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Nathaniel Smith wrote: So pkgname/__new__.py might look like: import sys from pkgname._metamodule import MyModuleSubtype sys.modules[__name__] = MyModuleSubtype(__name__, docstring) To start with, the 'from pkgname._metamodule ...' line is an infinite loop, Why does MyModuleSubtyp

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

What if we'd have metaclass semantics on module creation? Eg, suppose the default: __metaclass__ = ModuleType What if Python would support __prepare__ for modules? Thanks, -- Ionel M. On Sat, Nov 29, 2014 at 11:36 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> Are these really all o

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Guido van Rossum wrote: Are these really all our options? All of them sound like hacks, none of them sound like anything the language (or even the CPython implementation) should sanction. If assignment to the __class__ of a module were permitted (by whatever means) then you could put this in a

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Nathaniel Smith wrote: Option 4: Add a new function sys.swap_module_internals, which takes two module objects and swaps their __dict__ and other attributes. By making the operation a swap instead of an assignment, we avoid the lifecycle pitfalls from Option 3. Didn't I see somewhere that modul

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, 29 Nov 2014 20:02:50 + Nathaniel Smith wrote: > > > > Option 1b: have __class__ assignment delegate to a tp_classassign slot > > on the old class, so that typeobject.c doesn't have to be cluttered with > > many special cases. > > I'm intrigued -- how would this help? It would allow M

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On 29/11/14 19:37, Nathaniel Smith wrote: [snip] - The "new module" object has to be a subtype of ModuleType, b/c there are lots of places that do isinstance(x, ModuleType) checks (notably It has to be a *subtype* is does not need to be a *subclass* class M: ...__class__ = ModuleType

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, Nov 29, 2014 at 11:32 AM, Antoine Pitrou wrote: > On Sat, 29 Nov 2014 01:59:06 + > Nathaniel Smith wrote: >> >> Option 1: Make it possible to change the type of a module object >> in-place, so that we can write something like >> >>sys.modules[__name__].__class__ = MyModuleSubclass

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, Nov 29, 2014 at 4:21 AM, Guido van Rossum wrote: > Are these really all our options? All of them sound like hacks, none of them > sound like anything the language (or even the CPython implementation) should > sanction. Have I missed the discussion where the use cases and constraints > were

Re: [Python-Dev] PEP 479 and asyncio

On Sat, Nov 29, 2014 at 9:07 AM, Nick Coghlan wrote: > Guido wrote a specific micro-benchmark for that case in one of the > other threads. On his particular system, the overhead was around 150 > ns per link in the chain at the point the data processing pipeline was > shut down. In most scenarios

Re: [Python-Dev] PEP 479 and asyncio

On 30 November 2014 at 02:45, Olemis Lang wrote: > On 11/28/14, Guido van Rossum wrote: > [...] >> >> @Olemis: You never showed examples of how your code would be used, so it's >> hard to understand what you're trying to do and how PEP 479 affects you. >> > > The intention is not to restart the d

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On 29/11/14 01:59, Nathaniel Smith wrote: Hi all, [snip] Option 3: Make it legal to assign to the __dict__ attribute of a module object, so that we can write something like new_module = MyModuleSubclass(...) new_module.__dict__ = sys.modules[__name__].__dict__ sys.modules[__name_

Re: [Python-Dev] PEP 479 and asyncio

On 11/28/14, Guido van Rossum wrote: [...] > > @Olemis: You never showed examples of how your code would be used, so it's > hard to understand what you're trying to do and how PEP 479 affects you. > The intention is not to restart the debate . PEP is approved , it's done ... but ... as a side-e

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On 29 November 2014 at 21:32, Antoine Pitrou wrote: > On Sat, 29 Nov 2014 01:59:06 + > Nathaniel Smith wrote: >> >> Option 1: Make it possible to change the type of a module object >> in-place, so that we can write something like >> >>sys.modules[__name__].__class__ = MyModuleSubclass >>

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 29 November 2014 at 03:34, Demian Brecht wrote: > On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon wrote: >> >> I suspect if we make sure we add Bitbucket and GitHub login support to the >> issue tracker then that would help go a fair distance to helping with the >> GitHub pull of reach (and if

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Sat, 29 Nov 2014 01:59:06 + Nathaniel Smith wrote: > > Option 1: Make it possible to change the type of a module object > in-place, so that we can write something like > >sys.modules[__name__].__class__ = MyModuleSubclass > > Option 1 downside: The invariants required to make __class