[Python-Dev] On decorators implementation
I noticed (via using them) that decorations are applied to methods before they become methods. This choice flattens down the implementation to no differentiating methods from functions. 1) I have to apply euristics on the wrapped function type when I use the function as an index key. if type(observed) is types.MethodType: observed=observed.im_func things like this are inside my decorators. 2) The behavior of decorations are not definable. I imagine that a method implementation of them inside the type metaclass could be better specified by people. This probably ends up in metamethods or something I can't grasp Thanks Paolino ___ 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] On decorators implementation
Paolino wrote: > I imagine that a method implementation of them inside the type metaclass > could be better specified by people. What you ask for is unimplementable. Method objects are created only when the method is accessed, not (even) when the class is created. Watch this: >>> class X: ... def foo(self): ... pass ... >>> x=X() >>> type(x.foo) >>> type(X.__dict__['foo']) So even though the class has long been defined, inside X's dictionary, foo is still a function. Only when you *access* x.foo, a method object is created on the fly: >>> x.foo is x.foo False Therefore, a decorator function cannot possibly get access to the method object - it simply doesn't exist. Regards, Martin ___ 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] Admin access using svn+ssh
It turns out that svn+ssh with a single account has limitations: you can only set the tunnel user when you are using a restricted key. In PEP 347, the plan is that the current SF project admins get shell access to the pythondev account, which just has been created. To resolve this, project admins need two different SSH keys: one for accessing the shell, and one for regular commit activities. I would suggest that the default key is used for regular commits, and a separate key is created for shell access. I described this a bit in the PEP, essentially, in .ssh/config, I have Host pythondev Hostname dinsdale.python.org User pythondev IdentityFile ~/.ssh/pythondev So when I do "ssh pythondev", I get the shell account; when I do "svn co svn+ssh://[EMAIL PROTECTED]/python/trunk/Modules", I use my default identity, which gets tunneled as "Martin v. Loewis". Regards, Martin ___ 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] wush.net details
I made a service request at wush.net, asking for more details about their service. There was a first response within 6 hours, asking for more time to prepare an answer. I said I don't need one urgently, and, with apologies, got a response one week later. I added the essence to the PEP; namely: - The machine would be a Virtuozzo Virtual Private Server (VPS), hosted at PowerVPS. - The default repository URL would be http://python.wush.net/svn/projectname/, but anything else could be arranged - we would get SSH login to the machine, with sudo capabilities. - They have a Web interface for management of the various SVN repositories that we want to host, and to manage user accounts. While svn+ssh would be supported, the user interface does not yet support it (although he said they might have something in September) - For offsite mirroring/backup, they suggest to use rsync instead of download of repository tarballs. So it seems that the "regular" administrative overhead would be roughly the same on wush.net and python.org: we would have to maintain account information ourselves; the initial setup might be easier due to the UI wizard help. I understand that the hope when using a commercial service is that its availability is higher, due to us paying somebody for the availability. Of course, Bob Ippolito's report is discouraging here. Regards, Martin ___ 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] PEP 347: Migration to Subversion
Guido van Rossum wrote: > On the hosting issue, I'm still neutral -- I expect we'll be able to > support the current developer crowd easily on svn.python.org, but if > we ever find ther are resource problems (either people or bandwidth > etc.) I just received a recommendation for wush.net which specializes > in svn hosting. $90/month for 5 Gb of disk space sounds like a good > deal and easily within the PSF budget. I also have wush.net in the PEP, see my separate message. I'm not sure what it really is that we get over what we get from XS4ALL for free. >From the day-to-day maintenance, they seem comparable: they do backup for us, and we have to maintain accounts ourselves. Of course, wush.net has a Web GUI for maintenance activities (create repositories, create accounts, manage access control). I left out bandwidth details so far: we get 200GB/mo; after this, it is $50/200GB. Another issue might be server load. I don't know how many VPS they host on a single machine, or what their hardware is, but in either case, pythondev developer svn would be shared with something else (other VPSs for wush.net, regular pydotorg activities on python.org). Only day-to-day experience will tell whether this is acceptable. The critical issue seems to be availability: if the service goes down, when will it come back? Bob's experience is discouraging, but then, there also was a python.org outage from time to time (e.g. when MoinMoin consumed all CPU). As for the money itself: 90$/month certainly is not an issue at all. So far, I haven't received any other specific referrals for SVN hosters. Regards, Martin ___ 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] Collecting SSH keys
I have setup a test installation on svn.python.org, so that developers can see how this would work. So if you are currently a sf.net/projects/python developer, please send me your SSH key before August 27 or after September 12. We will use real names for commit messages, so if you have specific preferences about the spelling of your name, please indicate them. The repository will be discarded after the testing, so feel free to make any changes you want. It's not decided yet whether the repository will eventually run on python.org, but it seems clear to me that we likely will use svn+ssh for developer access, unless testing reveals disadvantages of doing so. Please also look at the result of the conversion; if you find any issues, please report them. There is currently no anonymous WebDAV access to the repository. Regards, Martin ___ 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] Collecting SSH keys
Martin v. Löwis wrote: > I have setup a test installation on svn.python.org, so that > developers can see how this would work. > > So if you are currently a sf.net/projects/python developer, > please send me your SSH key before August 27 or after > September 12. We will use real names for commit messages, > so if you have specific preferences about the spelling > of your name, please indicate them. What about people with a whole host of ssh keys? I have a different key for each system I use (currently at least 6). Will this be supported? Will the different keys identify the same person? > The repository will be discarded after the testing, so > feel free to make any changes you want. > > It's not decided yet whether the repository will eventually > run on python.org, but it seems clear to me that we likely > will use svn+ssh for developer access, unless testing > reveals disadvantages of doing so. > > Please also look at the result of the conversion; if you > find any issues, please report them. > > There is currently no anonymous WebDAV access to the > repository. > > Regards, > Martin > ___ > Python-Dev mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/sjoerd.mullender%40cwi.nl -- Sjoerd Mullender signature.asc Description: OpenPGP digital 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] Collecting SSH keys
Sjoerd Mullender wrote: > What about people with a whole host of ssh keys? I have a different key > for each system I use (currently at least 6). Will this be supported? > Will the different keys identify the same person? That would be possible, yes. You should send a single file containing all of them, and, each time something changes, resend the entire file. All of your keys would identify "Sjoerd Mullender". I don't know how this scales in OpenSSH having an authorized_keys file with hundred or more keys. On the wire, this seems safe, as it apparently is the client which offers various keys, and the server which then accepts or rejects them. Regards, Martin ___ 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] Deprecating builtin id (and moving it to sys())
Guido> The built-in namespace is searched last for a reason -- the Guido> design is such that if you don't care for a particular built-in Guido> you don't need to know about it. In my mind there are three classes of builtins from the standpoint of overriding. Pychecker complains if you override any of them, but I think that many times it does so unnecessarily. The first class includes those builtins that you will likely find in many code samples and should just never be overridden. For me these include "abs", "map", "list", "int", "range", "zip", the various exceptions, etc. The second class of builtins consists of objects or functions that are fairly special-purpose. You might not really care if they are overridden, depending on context. For me this class includes "compile", "id", "reload", "execfile", "ord", etc. Finally, there is the subset of builtins that is included almost solely as a convenience for use at the interpreter prompt. They include "quit", "exit" and "copyright". I could care less if I override them in my code, and don't think pychecker should either. Skip ___ 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] Admin access using svn+ssh
On Sun, 2005-08-21 at 09:12, "Martin v. Löwis" wrote: > It turns out that svn+ssh with a single account has limitations: > you can only set the tunnel user when you are using a restricted > key. In PEP 347, the plan is that the current SF project admins > get shell access to the pythondev account, which just has been > created. > > To resolve this, project admins need two different SSH keys: > one for accessing the shell, and one for regular commit activities. I may be totally misunderstanding, but to get shell access wouldn't I avoid using the pythondev account and just use my own account? I'd only need the pythondev account to access the svn repository, right? (And actually, it might be possible to set up group permissions and membership so that I could access the repo with either). The number of people who need shell access should be pretty small. I'm also a little confused about the pep. What does "admin access to the pythondev account" mean? Do you mean the people who are going to be managing users that can access svn? In that case, I think the system admins (i.e. those who already have shell access to dinsdale) would be the people managing user access to svn. > I would suggest that the default key is used for regular commits, > and a separate key is created for shell access. I described this > a bit in the PEP, essentially, in .ssh/config, I have > > Host pythondev > Hostname dinsdale.python.org > User pythondev > IdentityFile ~/.ssh/pythondev > > So when I do "ssh pythondev", I get the shell account; when I do > "svn co svn+ssh://[EMAIL PROTECTED]/python/trunk/Modules", > I use my default identity, which gets tunneled as "Martin v. Loewis". I'm confused again; are you saying that we should have a host named pythondev.python.org? I'm not sure that's necessary. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Admin access using svn+ssh
On Sun, Aug 21, 2005, Barry Warsaw wrote: > On Sun, 2005-08-21 at 09:12, "Martin v. L?wis" wrote: >> >> I would suggest that the default key is used for regular commits, >> and a separate key is created for shell access. I described this >> a bit in the PEP, essentially, in .ssh/config, I have >> >> Host pythondev >> Hostname dinsdale.python.org >> User pythondev >> IdentityFile ~/.ssh/pythondev >> >> So when I do "ssh pythondev", I get the shell account; when I do >> "svn co svn+ssh://[EMAIL PROTECTED]/python/trunk/Modules", >> I use my default identity, which gets tunneled as "Martin v. Loewis". > > I'm confused again; are you saying that we should have a host named > pythondev.python.org? I'm not sure that's necessary. No, pythondev is simply an SSH alias for dinsdale -- the server knows nothing about it. I don't quite understand the "User pythondev" line, though -- I think that's a mistake. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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] Admin access using svn+ssh
Barry Warsaw wrote: > I may be totally misunderstanding, but to get shell access wouldn't I > avoid using the pythondev account and just use my own account? You could do that (or use the root account); I can't: I don't have a ssh account on dinsdale. An even if I had, I couldn't write to pythondev's authorized_keys2. > I'm also a little confused about the pep. What does "admin access to > the pythondev account" mean? Do you mean the people who are going to be > managing users that can access svn? Correct. > In that case, I think the system > admins (i.e. those who already have shell access to dinsdale) would be > the people managing user access to svn. Ok: to whom should I forward the ssh keys then which I'm currently collecting? >>Host pythondev >> Hostname dinsdale.python.org >> User pythondev >> IdentityFile ~/.ssh/pythondev >> >>So when I do "ssh pythondev", I get the shell account; when I do >>"svn co svn+ssh://[EMAIL PROTECTED]/python/trunk/Modules", >>I use my default identity, which gets tunneled as "Martin v. Loewis". > > > I'm confused again; are you saying that we should have a host named > pythondev.python.org? I'm not sure that's necessary. Not at all. This is rather an OpenSSH convenience mechanism to avoid typing hostname and user name all the time. I introduce a local alias pythondev, which means I want to access [EMAIL PROTECTED], using the key pythondev.pub. Regards, Martin ___ 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] Admin access using svn+ssh
Aahz wrote: >>>Host pythondev >>> Hostname dinsdale.python.org >>> User pythondev >>> IdentityFile ~/.ssh/pythondev >>> >>I'm confused again; are you saying that we should have a host named >>pythondev.python.org? I'm not sure that's necessary. > > > No, pythondev is simply an SSH alias for dinsdale -- the server knows > nothing about it. I don't quite understand the "User pythondev" line, > though -- I think that's a mistake. That's intentional. "ssh pythondev" now becomes equivalent to ssh -l pythondev -i ~/.ssh/pythondev dinsdale.python.org IOW, the User option is equivalent to specifying the -l option. Regards, Martin ___ 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
