Mailman 3 October 2009 - Python-ideas

Re: [Python-ideas] Proposal: Moratorium on Python language changes
by Eric Smith Oct. 21, 2009

Oct. 21, 2009

Sorry for top posting and replying to a random message. I'm on a mobile device, and I fear a decision will be reached before I'm back at a real computer. It would be a shame to prevent any enhancements that would enable us to move forward on the distutils front, now that we finally have some momentum there. I'm thinking primarily of namespace packages (can't easily search for Martin's PEP just now). Most of the work will be in libraries, but adding a few core features might make things easier … [View More]or better. But even if that didn't make the cut, I'm at least +0 on the idea. -- Eric. "Guido van Rossum" <guido(a)python.org> wrote: >On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python(a)rcn.com> wrote: >> [Guido van Rossum] >>> Note, the moratorium would only cover the language itself plus >>> built-in functions, not the standard library. >> >> That makes sense. >> >> There may be a few areas that still have some rough edges where you >> may want to allow changes if needed (tweaks to the nested with-statement >> syntax, bytes/text interaction, star-args unpacking, or string formatting). >> These areas probably have not been exercised much and there may still be >> problems that need to be ironed-out. I don't have anything specific >> in mind. Am just thinking that those features aren't yet mature. > >No, the moratorium would freeze the language at the 3.1 version, at >least for 3.2 and 2.7 and possibly 3.3 (see my earlier post). Allowing >for exceptions like these provides too much wiggle room. (E.g is the >decorator syntax broken?) > >Outright bugs in the implementation should be excepted (subject to >discussion) but the accepted grammar and semantics should be frozen >unless they are unimplementable. > >> Also, do you know if there any plans afoot to do something with function annotations? > >I don't. Giving them more semantics would fall under the moratorium; >however some implementations might have optional extensions that >don't. I can also see that implementations which support interaction >with APIs defined in other languages (chiefly IronPython and Jython) >might define semantics for function annotation syntax in certain cases >where it benefits interaction with other languages -- this would be in >code that is naturally restricted to that implementation anyway. > >>> I also want to exclude >>> details of the CPython implementation, including the C API from being >>> completely frozen -- for example, if someone came up with (otherwise >>> acceptable) changes to get rid of the GIL I wouldn't object. >> >> FWIW, I have pending updates for the set/frozenset implementation >> (no api change). > >If it's just performance that's fine. If there's more I'd like to hear >more details first. > >> Also, I'm hoping the recently submitted C implementation for decimal >> gets accepted (as performance issues seem to be slowing broader >> use of the module). It looks like substantial work has already >> been done. > >I don't think that "work on a feature has already begun" should be an >argument for granting an exception. However I expect that in this >specific case this falls under the library, which is not directly >covered by the moratorium. I think I saw that it could be made >optional, so that if the C implementation isn't found the Python >implementation still works? > >>> But the moratorium would clearly apply to proposals for anonymous >>> blocks, "yield from" (PEP 380), changes to decorator syntax, and the >>> like. (I'm sure it won't stop *discussion* of those proposals, and >>> that's not the purpose of the moratorium; but at least it will stop >>> worries elsewhere that such proposals might actually be *accepted* any >>> time soon.) >> >> Are you rejecting PEP 380? > >No, just deferring it. It didn't make Python 3.1 so I think we'll have >to live without it for a long time no matter what. It could be >revisited once the moratorium is lifted (for 3.3 or 3.4). > >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) >_______________________________________________ >Python-ideas mailing list >Python-ideas(a)python.org >http://mail.python.org/mailman/listinfo/python-ideas > [View Less]

4 4

Re: [Python-ideas] Syntax for making stuct / record / namedtuples
by Arnaud Delobelle Oct. 21, 2009

Oct. 21, 2009

On 21 Oct 2009, at 16:56, Bruce Leban wrote: > Reading your code I have no idea what these lines mean > > > autoassign(function) -> method > autoassign(*argnames) -> decorator > autoassign(exclude=argnames) -> decorator > > Reading the code, what I *think* this does > > """Decorator that assigns all function parameters to attributes of > the class. > You can specify a list of parameters to process or a list of > parameters to … [View More]

2 1

Syntax for making stuct / record / namedtuples
by Eero Nevalainen Oct. 21, 2009

Oct. 21, 2009

From the (creative) laziness department: Whenever my module A needs to pass a lot of data to module B, I find myself making a factory function in module B for creating the datastructures def my_factory_function(a, b, c): # input checking res.a = a res.b = b res.c = c return res I believe this is fairly common. Since the fields are already defined in the function signature, I'd prefer to not repeat myself and write something like this: def my_factory_function(a, b,… [View More]

8 9

Re: [Python-ideas] Syntax for making stuct / record / namedtuples
by wxyarv Oct. 21, 2009

Oct. 21, 2009

>>Whenever my module A needs to pass a lot of data to module B, I find >>myself making a factory function in module B for creating the datastructures >> >>def my_factory_function(a, b, c): >> # input checking >> res.a = a >> res.b = b >> res.c = c >> return res >> >>I believe this is fairly common. >> >>Since the fields are already defined in the function signature, I'd >>prefer to not … [View More]

2 1

Re: [Python-ideas] [Python-Dev] Proposal : Python Trusted Computing API
by geremy condra Oct. 20, 2009

Oct. 20, 2009

On Mon, Oct 19, 2009 at 2:29 AM, Abhiram Kasina <abhiram.casina(a)gmail.com> wrote: > Hi > > Trusted Computing (TC) is a technology developed and promoted by the Trusted > Computing Group (TCG)[3]. So, basically the group came up with these chips > called TPM chips which are present on most motherboards nowadays. The main > purpose of it is to enhance security so that infected executables don't run. > It also provides memory curtaining such that cryptographic keys won'… [View More]t be > accessible and many other features. There was a criticism on this from the > FOSS community as well that it enables DRM. No wonder, it is being pushed by > Intel, Microsoft, AMD, etc.. I personally have grave concerns about this technology, independent of who is advancing it- just reading the links you provide makes it clear that its primary purpose is to restrict the degree of control a user can exercise over their own data, programs, and machine. Is it any wonder that the same people who find DRM abhorrent find the technologies used to advance it equally distasteful? > But personally I think its a good idea from security point of view. Besides sealed storage and memory curtaining- which I admit have seductive security implications- all of the supposed advantages of a TPM can be replicated using non-interactive zero knowledge proofs. I'd rather we put that capability into the standard library- but I strongly doubt that's going to happen any time soon. > So, currently there is an TSS (TCG Software Stack)[1] API written in C. And > TrustedJava[2] is a project which ported it to Java and is going to be > included in the standard API of Java soon. They have 2 versions of it. One > is a simple wrapper on top of the API and the other is a whole > implementation of the stack in Java. > > My proposal is we create an API for it in python. I also suspect that if this were a simple undertaking, there wouldn't be a 'we' in this sentence. > Reason: I am a developer in Umit and I think Python is a very good platform > for developing applications. So, why not create an API which helps in > developing secure applications? If you were suggesting adding a crypto API to python, I'd be all for it- but you're suggesting adding the ability to have Python software vendors remotely cripple the code on your machine. I just can't get behind that, and while you're sure to hear wildly divergent opinions on this board, I suspect that mine will not be an uncommon sentiment. Geremy Condra [View Less]

4 4

Remove GIL with CAS instructions?
by geremy condra Oct. 20, 2009

Oct. 20, 2009

On Tue, Oct 20, 2009 at 7:31 PM, Sturla Molden <sturla(a)molden.no> wrote: > Casey Duncan skrev: >> >> I doubt anyone here would disagree with that, but to be taken seriously, >> you'll need to be *much* more specific. Enlighten us. > > I just showed you thread-safe incref and decref that don't require a lock. > > How specific should I be? > I suspect it's going to take working code- after all, if it isn't worth your time to implement, I don't think … [View More]

1 0

breaking cycles that include __del__
by Daniel Stutzbach Oct. 20, 2009

Oct. 20, 2009

Right now, the presence of __del__ method prevents cycles from being collected. It is possible for an application to rummage through gc.garbage and break links between objects. However, for a large application this may be inefficient or inelegant for several reasons: - It may be most natural to break the links on objects of type Foo, even though Foo is a minority of items (e.g., if Foo is parent node with many children). - It's difficult to know how frequently to sift through the garbage - … [View More]

6 15

What about feature X?
by Michael Foord Oct. 20, 2009

Oct. 20, 2009

An interesting list of what it takes to add a new feature from Eric Lippert, one of the C# team: http://blogs.msdn.com/ericlippert/archive/2009/10/05/why-no-extension-prope… As I'm fond of pointing out, the answer to every question of the form "why doesn't product X have feature Y?" is the same. It's because in order for a product to have a feature, that feature must be: - thought of in the first place - desired - designed - specified - implemented - tested - documented … [View More]

2 1

What about feature X?
by Michael Foord Oct. 20, 2009

Oct. 20, 2009

An interesting list of what it takes to add a new feature from Eric Lippert, one of the C# team: http://blogs.msdn.com/ericlippert/archive/2009/10/05/why-no-extension-prope… As I'm fond of pointing out, the answer to every question of the form "why doesn't product X have feature Y?" is the same. It's because in order for a product to have a feature, that feature must be: - thought of in the first place - desired - designed - specified - implemented - tested - documented … [View More]

1 0

Re: [Python-ideas] a new lambda syntax
by 小翼 Oct. 20, 2009

Oct. 20, 2009

Okay...but, Two--no, Three question: - is it necessary to implement it? - is it diffcult to implement it? - is it helps to import Python statement? if so, I will try to implement it (I'm trying to read the source of Python, but it sames too complicated :-(

1 0