[Python-Dev] PEP 367: New Super
Here is my modified version of PEP 367. The reference implementation in it is pretty long, and should probably be split out to somewhere else (esp. since it can't fully implement the semantics). Cheers, Tim Delaney PEP: 367 Title: New Super Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman <[EMAIL PROTECTED]> Author: Tim Delaney <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Apr-2007 Python-Version: 2.6 Post-History: 28-Apr-2007, 29-Apr-2007 (1), 29-Apr-2007 (2), 14-May-2007 Abstract This PEP proposes syntactic sugar for use of the ``super`` type to automatically construct instances of the super type binding to the class that a method was defined in, and the instance (or class object for classmethods) that the method is currently acting upon. The premise of the new super usage suggested is as follows:: super.foo(1, 2) to replace the old:: super(Foo, self).foo(1, 2) and the current ``__builtin__.super`` be aliased to ``__builtin__.__super__`` (with ``__builtin__.super`` to be removed in Python 3.0). It is further proposed that assignment to ``super`` become a ``SyntaxError``, similar to the behaviour of ``None``. Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. "super type" will refer to the actual builtin type named "super". A "super instance" is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Because the new ``super`` semantics are not backwards compatible with Python 2.5, the new semantics will require a ``__future__`` import:: from __future__ import new_super The current ``__builtin__.super`` will be aliased to ``__builtin__.__super__``. This will occur regardless of whether the new ``super`` semantics are active. It is not possible to simply rename ``__builtin__.super``, as that would affect modules that do not use the new ``super`` semantics. In Python 3.0 it is proposed that the name ``__builtin__.super`` will be removed. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) can be made without explicitly creating a ``super`` instance (although doing so will still be supported via ``__super__``). Every function will have an implicit local named ``super``. This name behaves identically to a normal local, including use by inner functions via a cell, with the following exceptions: 1. Assigning to the name ``super`` will raise a ``SyntaxError`` at compile time; 2. Calling a static method or normal function that accesses the name ``super`` will raise a ``TypeError`` at runtime. Every function that uses the name ``super``, or has an inner function that uses the name ``super``, will include a preamble that performs the equivalent of:: super = __builtin__.__super__(, ) where is the class that the method was defined in, and is the first parameter of the method (normally ``self`` for instance methods, and ``cls`` for class methods). For static methods and normal functions, will be ``None``, resulting in a ``TypeError`` being raised during the preamble. Note: The relationship between ``super`` and ``__super__`` is similar to that between ``import`` and ``__import__``. Much of this was discussed in the thread of the python-dev list, "Fixing super anyone?" [1]_. Open Issues --- Determining the class object to use ''' The exact mechanism for associating the method with the defining class is not specified in this PEP, and should be chosen for maximum performance. For CPython, it is suggested that the class instance be held in a C-level variable on the function object which is bound to one of ``NULL`` (not part of a class), ``Py_None`` (static method) or a class object (instance or class method). Should ``super`` actually become a keyword? ''' With this proposal, ``super`` would become a keyword to the same extent that ``None`` is a keyword. It is possible that further restricting the ``super`` name may simplify implementation, however some are against the actual keyword- ization of super. The simplest solution is often the correct solution and the simplest solution may well not be adding additional keywords to the language when they are not needed. Still, it may solve other open issues. Closed Issues - super used with __call__ attributes ''' It was considered that it might be a problem that instantiating super instances the classic way, because calling
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On Fri, 2007-05-11 at 13:06 -0700, Guido van Rossum wrote: > > attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])') > > But wouldn't it be just as handy to teach the re module about \u and > \U, just as it already knows about \x (and \123 octals)? And \n, \r, etc. Implementing \u in re is not only useful, but also consistent. ___ 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] Summary of Tracker Issues
On Mon, May 14, 2007, "Martin v. L?wis" wrote: > Skip(?): >> >> In the meantime (thinking out loud here), would it be possible to keep >> search engines from seeing a submission or an edit until a trusted person >> has had a chance to approve it? > > It would be possible, but I would strongly oppose it. A bug tracker > where postings need to be approved is just unacceptable. Could you expand this, please? It sounds like Skip is just talking about a dynamic robots.txt, essentially. Anyone coming in to the tracker itself should still see everything. Moreover, this restriction only comes into play for postings from new people, which should limit the load. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ 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] New operations in Decimal
Tim Peters wrote: > I'm with Raymond on this one, especially given the triviality of > implementing the revised spec's new logical operations. Exactly. I already implemented part of it, and took less than read this thread, ;). The cost of having it is lines of code in decimal.py. The benefit is that you can claim you comply to the standard. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Draft PEP: Maintenance of Python Releases
"Martin v. Löwis" writes: > The objective is to reduce load for the release manager. Any kind of > release that is worth anything takes several hours to produce, in > my experience (if it could be made completely automatic, it wouldn't > be good, since glitches would not be detected). I absolutely agree. > See PEP 101. A release involves many more steps, and it's not clear > whether a release candidate could be skipped. My point is that if those steps are required for a release, the branch is not "immediately releasable" by my standards if they're not done. Especially if a release candidate is required. I guess you only meant that a security commit must meet the technical requirements of any other commit (plus being a security fix, of course), so that the release process can be started at any time? In general, I recognize the burden on the release engineer, and obviously any burdensome policy needs his OK. But I think the policy should be *effective* too, and I just don't see that a policy that allows such long lags is a more effective security response than a policy that says "the tarballs are deprecated due to security fixes; get your Python by importing the branch, not by fetching a tarball." ___ 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] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 14, 2007, at 11:32 AM, Stephen J. Turnbull wrote: > In general, I recognize the burden on the release engineer, and > obviously any burdensome policy needs his OK. But I think the policy > should be *effective* too, and I just don't see that a policy that > allows such long lags is a more effective security response than a > policy that says "the tarballs are deprecated due to security fixes; > get your Python by importing the branch, not by fetching a tarball." Like many other activities we do, if we find ourselves blocking because of resource constraints, we should recruit additional volunteers to reduce the load on any one person. Anthony does a masterful job as release manager, but maybe he would rather someone else perform security releases. (It's not a bad idea anyway so that others have experience doing releases too.) We should decide what's right for security releases and then assess whether we need to recruit in order to perform that activity the way we want to. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkiEFXEjvBPtnXfVAQL1TQP+IbelPCGvkd8IEGvDLIguJxM4B437AJPh I6sluVGP3EjOcVbHTh8EgiqvWn+DaKQUIIkxqt+CEX/ghOXwv4X2z73Qnc8VB5jG W6ghV6diiYwmD8xOGUUvuIk4Rr+qV4Me22p38E1aZY7UP9ub9o6ofsGe19rjNjoX nQBs7PUMqPQ= =Onzb -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] Draft PEP: Maintenance of Python Releases
Martin v. Löwis wrote: >> I don't understand the point of a "security release" made up to a year >> after commit, especially in view of the first quoted paragraph. > > The objective is to reduce load for the release manager. Any kind of > release that is worth anything takes several hours to produce, in You can always can make a checkout of the security-manteined-only branch, if you're in a particular hurry (maybe the PEP should say something about this). Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] [Python-3000] PEP 367: New Super
At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote: >Determining the class object to use >''' > >The exact mechanism for associating the method with the defining class is >not >specified in this PEP, and should be chosen for maximum performance. For >CPython, it is suggested that the class instance be held in a C-level >variable >on the function object which is bound to one of ``NULL`` (not part of a >class), >``Py_None`` (static method) or a class object (instance or class method). Another open issue here: is the decorated class used, or the undecorated class? ___ 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] Draft PEP: Maintenance of Python Releases
> My point is that if those steps are required for a release, the branch > is not "immediately releasable" by my standards if they're not done. > Especially if a release candidate is required. But how does that help in practice? If you find after the release that the branch was not in a releasable state, will you fire your employee that caused the mess-up? Even though no problems are expected, you still have to *check* whether there are problems, and that is time-consuming. Better safe than sorry (at least, this is what I understand Anthony Baxter's position on release engineering is - and I agree with that view). > I guess you only meant that a security commit must meet the technical > requirements of any other commit (plus being a security fix, of > course), so that the release process can be started at any time? Exactly. I wouldn't require the release manager to actually commit all security patches - and requiring so would be the only way to guarantee that the branch is releasable (i.e. you have to release it to be sure). > In general, I recognize the burden on the release engineer, and > obviously any burdensome policy needs his OK. But I think the policy > should be *effective* too, and I just don't see that a policy that > allows such long lags is a more effective security response than a > policy that says "the tarballs are deprecated due to security fixes; > get your Python by importing the branch, not by fetching a tarball." In effect, this is what the PEP says. That's intentional (i.e. it is my intention - others may have different intentions). It's the repository that holds the security patches; the tarballs (and the version number bumps) are just a convenience. 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] Draft PEP: Maintenance of Python Releases
> We should decide what's right for security releases and then assess > whether we need to recruit in order to perform that activity the way we > want to. I disagree. If you would like to see a certain policy implemented, you need to locate the volunteers *first*, and only then you can start setting a policy that these volunteers can agree to. When the volunteers then run away, or become inactive, the policy needs revisiting. 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] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 14, 2007, at 5:32 PM, Martin v. Löwis wrote: >> We should decide what's right for security releases and then assess >> whether we need to recruit in order to perform that activity the >> way we >> want to. > > I disagree. If you would like to see a certain policy implemented, you > need to locate the volunteers *first*, and only then you can start > setting a policy that these volunteers can agree to. When the > volunteers > then run away, or become inactive, the policy needs revisiting. These are not mutually exclusive positions, but that's unimportant because in this specific case, I'm confident we can summon the necessary manpower. Still, I'm in agreement with you that the repository holds the security patches and that the tarballs are a convenience. They are an important convenience though, so I would say that they should be released in a timely manner after the commit of the security patches. I don't think we need to be that exact about spelling out when that happens. (I personally would like to see it within "weeks" of a security patch, not "months" or "years".) Also, I would like to document explicit that it is the responsibility of the PSRT (or its designate) to commit security patches to revision control. The act of committing these patches is a public event and has an important impact on any embargoes agreed upon by the PSRT with other organizations. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkjYFHEjvBPtnXfVAQIAfAQAq8052/15WnMqrEyReXJRgeJqtklKzg3f xwVaOdEQjnp0QXAg7tMf29kCxLq6kW6al8DMUPHQcaV9cH7sQcMAon0V9LwiXlwU 3d0Mbvb5RUlpRmfDniQeGljCyCLJZbk+nUbrWbLAtIsrzMaW4FaPUkTUza1ZSIHX nKhsh7fifiM= =kYxd -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] Draft PEP: Maintenance of Python Releases
> Still, I'm in agreement with you that the repository holds the security > patches and that the tarballs are a convenience. They are an important > convenience though, so I would say that they should be released in a > timely manner after the commit of the security patches. I don't think > we need to be that exact about spelling out when that happens. > > (I personally would like to see it within "weeks" of a security patch, > not "months" or "years".) Couldn't that lead to many more 2.x.y releases in the "security fixes" period than in the "active maintenance" period? For active maintenance, we don't do roll security fixes into releases more often than every six months. I would dislike a quick succession of 2.3.7, 2.3.8, 2.3.9, etc. (also because these numbers should not grow above 10 :-) > Also, I would like to document explicit that it is the responsibility of > the PSRT (or its designate) to commit security patches to revision > control. The act of committing these patches is a public event and has > an important impact on any embargoes agreed upon by the PSRT with other > organizations. I also disagree. Regular committers should continue to do that. I haven't seen a single activity from the PSRT (or, perhaps one), so for all I can tell, it doesn't exist. If a security patch is reported to the Python bug tracker, it's as public as it can get. If PSRT members (who are they, anyway) also happen to be committers, they can commit these changes at the time the PSRT deems appropriate. If they are not committers, they need to post the patch to SF as anybody else. (you can tell that I come from a country where people are quite skeptical about the secret service). 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] Summary of Tracker Issues
>> I think a single-click button "Spammer" >> should allow committers to lock an account and hide all messages >> and files that he sent, but that still requires somebody to implement >> it. > >I'd expect that to be pretty effective -- like graffiti artists, >spammers want their work to be seen, and a site that quickly removes >them will not be worth the effort for them. Unfortunately, the spammers are using automated tools to locate, register on and post to victim sites. The tools are distributed (running on compromised PCs) and massively parallel, so they really don't care that some of their posts are never seen. I'm reluctant to mention the name of one particular tool I'm aware of, but as well as the above, it also has OCR to defeat CAPTCHA, and automatically creates throw-away e-mail accounts with a range of free web-mail providers for registration purposes. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ 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] Draft PEP: Maintenance of Python Releases
"Martin v. Löwis" writes: > > In general, I recognize the burden on the release engineer, and > > obviously any burdensome policy needs his OK. But I think the policy > > should be *effective* too, and I just don't see that a policy that > > allows such long lags is a more effective security response than a > > policy that says "the tarballs are deprecated due to security fixes; > > get your Python by importing the branch, not by fetching a tarball." > > In effect, this is what the PEP says. That's intentional (i.e. it > is my intention - others may have different intentions). It's the > repository that holds the security patches; the tarballs (and the > version number bumps) are just a convenience. It's not the intentions of the Python developers that is my concern here. In effect, I can read this PEP as saying "we don't take security seriously enough to release in a timely fashion, why should you go to the effort of getting sources and applying patches?" and I fear that many users will do so. I think that the label of "release" is important. ___ 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] Draft PEP: Maintenance of Python Releases
> > In effect, this is what the PEP says. That's intentional (i.e. it > > is my intention - others may have different intentions). It's the > > repository that holds the security patches; the tarballs (and the > > version number bumps) are just a convenience. > > It's not the intentions of the Python developers that is my concern > here. In effect, I can read this PEP as saying "we don't take > security seriously enough to release in a timely fashion, why should > you go to the effort of getting sources and applying patches?" and I > fear that many users will do so. I think that the label of "release" > is important. [Not sure who "you" is above: who should or should not go to the effort of getting sources, and what patches should they apply?] I don't think I can be more plain than that: yes, I do not take security seriously enough to release security fixes for old Python versions more than once a year. As a user, it's easy to demand things, and people really have to learn that in open source, all things are done by volunteers, and that demanding gets you nowhere. To get a better service, somebody really has to volunteer and offer it. 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] Draft PEP: Maintenance of Python Releases
> | I think we would need to restrict the total number of releases > | made per year. The one-year limit may be debatable, and immediate > | releases might be possible, as long as there is some provision > | that releases are not made at a too-high rate. > > I would agree, but... > has there been more that the one security release that I know about? No, but I believe this partly due to the fact that Linux distributors don't provide their security patches, or that they get applied only to the current maintenance branch, and not to older branches. If this policy gets implemented, I believe there would be more security patches than those we had seen - this single one was only in response to some demanding users. 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] Draft PEP: Maintenance of Python Releases
> You can always can make a checkout of the security-manteined-only > branch, if you're in a particular hurry (maybe the PEP should say > something about this). Indeed. I can add explicit wording to say that. 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] Summary of Tracker Issues
Aahz schrieb: > On Mon, May 14, 2007, "Martin v. L?wis" wrote: >> Skip(?): >>> In the meantime (thinking out loud here), would it be possible to keep >>> search engines from seeing a submission or an edit until a trusted person >>> has had a chance to approve it? >> It would be possible, but I would strongly oppose it. A bug tracker >> where postings need to be approved is just unacceptable. > > Could you expand this, please? It sounds like Skip is just talking about > a dynamic robots.txt, essentially. Anyone coming in to the tracker > itself should still see everything. I must have misunderstood Skip then - I thought he had a scheme in mind where an editor would have approve postings before they become visible to tracker users; the tracker itself cannot distinguish between a search engine and a regular (anonymous) user. As for a dynamically-expanding robots.txt - I think that would be difficult to implement (close to being impossible). At best, we can have robots.txt filter out entire issues, not individual messages within an issue. So if a spammer posts to an existing issue, no proper robots.txt can be written. Even for new issues: they can be added to robots.txt only after they have been created. As search engines are allowed to cache robots.txt, they might not see that it has been changed, and fetch the issue that was supposed to be blocked. 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] Summary of Tracker Issues
> I'm reluctant to mention the name of one particular tool I'm aware > of, but as well as the above, it also has OCR to defeat CAPTCHA, and > automatically creates throw-away e-mail accounts with a range of free > web-mail providers for registration purposes. Right. We considered CAPTCHA, but some people were immediately opposed to using it, both for the reason that spammers still get past it in an automated manner, and that it might lock out certain groups of legitimate users. So I have personally given up on that path. 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] Summary of Tracker Issues
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |> I'm reluctant to mention the name of one particular tool I'm aware | > of, but as well as the above, it also has OCR to defeat CAPTCHA, and | > automatically creates throw-away e-mail accounts with a range of free | > web-mail providers for registration purposes. | | Right. We considered CAPTCHA, but some people were immediately opposed | to using it, both for the reason that spammers still get past it in | an automated manner, and that it might lock out certain groups of | legitimate users. So I have personally given up on that path. I have not noticed any spam on the very public SF tracker (or have I just missed it?) while I saw some my first visit to our hardly public trial site. Any ideas on why the difference? tjr ___ 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] Summary of Tracker Issues
"Andrew McNamara" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I'm reluctant to mention the name of one particular tool I'm aware | of, but as well as the above, it also has OCR to defeat CAPTCHA, and How about asking a Python specific question, with answered filled in rather that multiple choice selected: I would be willing to make up a bunch. The initials of Python's founder. The keyword for looping by condition. The char that signals a name-binding statement. (I am intentionally avoiding question words and ? that would signal Test Question to automated software.) If we anticipate users rather than programmers to register (as if so, it would be nice to collect that info to formulate sensible responses), then questions like The orb that shines in the sky during the day. | automatically creates throw-away e-mail accounts with a range of free | web-mail providers for registration purposes. Either don't accept registrations from such accounts (as other sites have done), or require extra verification steps or require approval of the first post. How many current legitimate registered users use such? Terry Jan Reedy ___ 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
