[Python-Dev] Propose to close PEP 254 -- Making Classes Look More Like Types
This PEP is an empty stub that is unlikely to ever get filled-out in a way that adds anything beyond what is already implemented and documented. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote: > Nick Coghlan wrote: >> And here we see why I'm such a fan of the term 'deferred expression' >> instead of 'anonymous function'. > > But isn't a function just a deferred expression with a name :-) According to the specific meaning of 'expression' in the Python grammar? No. > Isn't that because lambda's have the limitation of not allowing > statements, only expressions? I know this limitation avoids side-effects > and has significance in some formal (functional?) languages... but is > that what Python is? Personally, I believe it has to do with two things, one practical and one more stylistic/philosophical. Firstly, Python uses significant whitespace between statements, and to delineate sections of compound statements. Within expressions however, whitespace is essentially insignificant (except where it affects the tokenisation). Trying to embed suites (where whitespace can be significant) inside expressions (where whitespace is generally insiginificant) tends to result in a horrible mess, or else some rather unPythonic concepts (e.g. using something other than indentation to demarcate the suite). Secondly, trying to cram too much functionality into a single line is a questionable activity. The 'deferred expression' approach taken with lambdas is a hint that if the thing you're trying to defer is more complex than a single expression, it may be worth giving it a proper name via 'def'. > In the Python I use, lambda's are always used where > you are too lazy to define a function to do it's job. In simple cases, naming the expression to be deferred results in it gaining a prominence it doesn't deserve, possibly obscuring the purpose of the main statement. In such cases, deferred expressions are a better solution - it's merely unfortunate that Python's current syntax for the practice anything to write home about. > To me, anonymous procedures/functions would be a superset of "deferred > expressions", and if the one stone fits perfectly in the slingshot we > have and can kill multiple birds... why hunt for another stone? Because there is already a solution for the large birds - *named* functions. Unfortunately, using a named function for a simple deferred expression is like using a catapult to kill a canary. > If there really is a serious practical reason why they must be limited > to expressions, why not just raise an exception or something if the > "anonymous function" is too complicated... You'd still need a definition of 'too complicated' - which we already have for deferred expressions. Specifically "unable to be expressed as a single Python expression". >> Anyway, the AlternateLambdaSyntax Wiki page has a couple of relevant >> entries under 'real closures'. > > Where is that wiki BTW? I remember looking at it ages ago but can't find > the link anymore. http://wiki.python.org/moin/AlternateLambdaSyntax Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
On Sat, 18 Jun 2005, Michael Hudson wrote: > > The shortest way I know of going from 2149871625L to -2145095671 is > the still-fairly-gross: > v = 2149871625L ~int(~v&0x) > -2145095671 > >> I suppose the best thing is to introduce an "unsignedint" type for this >> purpose. > > Or some kind of bitfield type, maybe. > > C uses integers both as bitfields and to count things, and at least in > my opinion the default assumption in Python should be that this is > what an integer is being used for, but when you need a bitfield it can > all get a bit horrible. > > That said, I think in this case we can just make fcntl_ioctl use the > (new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just > be able to use 2149871625L and be happy (I think, haven't tried this). Thanks for the reply. I think I will go ahead and add some extension types to Python. Thankfully, Python is extensible with new objects. It is also useful (to me, anyway) to be able to map, one to one, external primitives from other systems to Python primitives. For example, CORBA and SNMP have a set of types (signed ints, unsigned ints, etc.) defined that I would like to interface to Python (actually I have already done this to some degree). But Python makes it a bit more difficult without that one-to-one mapping of basic types. Having an unsigned int type, for example, would make it easier to interface Python to SNMP or even some C libraries. In other words, Since the "Real World" has these types that I must sometimes interface to, it is useful to have these same (predictable) types in Python. So, it is worth extending the basic set of data types, and I will add it to my existing collection of Python extensions. Therefore, I would like to ask here if anyone has already started something like this? If not, I will go ahead and do it (if I have time). -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Donovan Baarda <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > Donovan Baarda wrote: > > > >>As I see it, a lambda is an anonymous function. An anonymous function is > >>a function without a name. > > > > > > And here we see why I'm such a fan of the term 'deferred expression' > > instead of 'anonymous function'. > > But isn't a function just a deferred expression with a name :-) A function in Python is actually a deferred sequence of statements and expressions. An anonymous function in Python (a lambda) is a deferred expression. > > Python's lambda expressions *are* the former, but they are > > emphatically *not* the latter. > > Isn't that because lambda's have the limitation of not allowing > statements, only expressions? I know this limitation avoids side-effects > and has significance in some formal (functional?) languages... but is > that what Python is? In the Python I use, lambda's are always used where > you are too lazy to define a function to do it's job. I've generally seen people use lambdas for things that don't require names in the current context; i.e. callbacks with simple executions. > To me, anonymous procedures/functions would be a superset of "deferred > expressions", and if the one stone fits perfectly in the slingshot we > have and can kill multiple birds... why hunt for another stone? Are "deferred expressions" perhaps another way of spelling "function closure"? > Oh yeah Raymond: on the "def defines some variable name"... are you > joking? You forgot the smiley :-) 'def' happens to bind the name that follows the def to the function with the arguments and body following the name. > I don't get what the problem is with mixing statement and expression > semantics... from a practial point of view, statements just offer a > superset of expression functionality. Statements don't have a return value. To be more precise, what is the value of "for i in xrange(10): z.append(...)"? Examine the selection of statements available to Python, and ask that question. The only one that MAY have a return value, is 'return' itself, which really requires an expression to the right (which passes the expression to the right to the caller's frame). When you have statements that ultimately need a 'return' for a return value; you may as well use a standard function definition. > If there really is a serious practical reason why they must be limited > to expressions, why not just raise an exception or something if the > "anonymous function" is too complicated... Define "too complicated"? > I did some fiddling and it seems lambda's can call methods and stuff > that can have side effects, which kinda defeats what I thought was the > point of "statements vs expressions"... I guess I just don't > understand... maybe I'm just thick :-) There is nothing stopping anyone from modifying anything in a lambda... a = list(...) pop = lambda:a.pop() lcycle = lambda: a and a.append(a.pop(0)) rcycle = lambda: a and a.insert(0, a.pop()) popany = lambda: a and a.pop(random.randrange(len(a))) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
Keith Dart <[EMAIL PROTECTED]> wrote: > Therefore, I would like to ask here if anyone has already started > something like this? If not, I will go ahead and do it (if I have time). If all you need to do is read or write C-like types to or from memory, you should spend some time looking through the 'struct' module if you haven't already. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
On Sun, 19 Jun 2005, Josiah Carlson wrote:
>
> Keith Dart <[EMAIL PROTECTED]> wrote:
>
>> Therefore, I would like to ask here if anyone has already started
>> something like this? If not, I will go ahead and do it (if I have time).
>
> If all you need to do is read or write C-like types to or from memory,
> you should spend some time looking through the 'struct' module if you
> haven't already.
I know about 'struct'. However, it will just convert to Python "native"
types. C unsigned become Python longs.
u = struct.pack("I", 0xfffe)
struct.unpack("I", u)
(4294967294L,)
In SNMP, for example, a Counter32 is basically an unsigned int, defined
as "IMPLICIT INTEGER (0..4294967295)". One cannot efficiently translate
and use that type in native Python. Currently, I have defined an
"unsigned" type as a subclass of long, but I don't think that would be
speed or storage efficient.
On the other hand, adding my own type won't help with the ioctl()
problem, since it won't know about it.
--
-- ~
Keith Dart <[EMAIL PROTECTED]>
public key: ID: F3D288E4
=
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Josiah Carlson wrote: > Donovan Baarda <[EMAIL PROTECTED]> wrote: > >>Nick Coghlan wrote: >> >>>Donovan Baarda wrote: [...] >>But isn't a function just a deferred expression with a name :-) > > > A function in Python is actually a deferred sequence of statements and > expressions. An anonymous function in Python (a lambda) is a deferred > expression. in the end though, a sequence of statements that completes with a "return value" is, when treated as a black box, indistinguishable from an expression. Originally I thought that this also had to be qualified with "and has no side-effects", but I see now that is not the case. [...] >>Oh yeah Raymond: on the "def defines some variable name"... are you >>joking? You forgot the smiley :-) > > > 'def' happens to bind the name that follows the def to the function with > the arguments and body following the name. Yeah, but we don't use "def" to bind arbitary variables, only functions/procedures. So in python, they are intimately identified with functions and procedures. >>I don't get what the problem is with mixing statement and expression >>semantics... from a practial point of view, statements just offer a >>superset of expression functionality. > > > Statements don't have a return value. To be more precise, what is the > value of "for i in xrange(10): z.append(...)"? Examine the selection of > statements available to Python, and ask that question. The only one > that MAY have a return value, is 'return' itself, which really requires > an expression to the right (which passes the expression to the right to > the caller's frame). When you have statements that ultimately need a > 'return' for a return value; you may as well use a standard function > definition. Hmmm. For some reason I thought that these kind of things would have a return value of None, the same as a function without an explicit return. I see now that this is not true... >>If there really is a serious practical reason why they must be limited >>to expressions, why not just raise an exception or something if the >>"anonymous function" is too complicated... > > > Define "too complicated"? I was thinking that this is up to the interpreter... depending on what the practical limitations are that cause the limitation in the first place. For example... if it can't be reduced to an "expression" through simple transforms. But look... I've gone and created another monster thread on "alternatives to lambda"... I'm going to shut up now. -- Donovan Baarda ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Donovan Baarda wrote:
> I don't get what the problem is with mixing statement and expression
> semantics... from a practial point of view, statements just offer a
> superset of expression functionality.
>
> If there really is a serious practical reason why they must be limited
> to expressions, why not just raise an exception or something if the
> "anonymous function" is too complicated...
>
> I did some fiddling and it seems lambda's can call methods and stuff
> that can have side effects, which kinda defeats what I thought was the
> point of "statements vs expressions"... I guess I just don't
> understand... maybe I'm just thick :-)
The whole point is that you are able to do all the basic control flow
operations like IF, FOR and WHILE using simple expressions ( like in
Pythons lambda ), the lambda statement itself and recursion. Therefore
lambda expressions constitute a Turing complete language and they also
do so in Python. Different to many FP languages lambda plays no central
role in Python because statements won't be reduced to lambda expressions
( or some kind of ). They are merely an add-on.
Reduction provides often the advantage to make expressions/statements
scriptable what they are not in Python. Python is strong in scripting
classes/objects ( a big plus of the language ) but you can't simply use
the language to prove that
lambda x,y: x+y*y
lambda x,y: y**2+x
are essentialy the same functions with different implementations [1]. I
think this is a severe lack of expressibility and has nothing to do with
the silly objection that one has to write one more line for a simple
callback - o.k. I admit that I'm lazy too ;)
Regards,
Kay
[1] Not without hacking the parse tree. Doing so one might finally end
up accessing the expression in a simple modifieable manner:
>>> (lambda x,y: x+y*y).expr
('+',(x,'*',(y,y)))
>>> (lambda x,y: y**2+x).expr
('+',(('**',(y,2)),x))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reduction provides often the advantage to make expressions/statements > scriptable what they are not in Python. Python is strong in scripting > classes/objects ( a big plus of the language ) but you can't simply use > the language to prove that > > lambda x,y: x+y*y > lambda x,y: y**2+x > > are essentialy the same functions with different implementations [1]. Except that they are not. Think of __pow__, think of __add__ and __radd__. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org 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 for RFE 46738 (first draft)
Simon> I hacked things a bit, and instead of sending XML, sent pickles Simon> inside the XML response. I've done the same thing (I think I may have used marshal). It works fine as long as you know both ends are Python. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 294 -- Type Names in the types Module
Raymond> Suggest rejecting this PEP and making a note for Py3.0 to Raymond> either sync-up the type names or abandon the types module Raymond> entirely. I thought the types module was already deprecated, at least verbally if not officially. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
>> As I see it, a lambda is an anonymous function. An anonymous function >> is a function without a name. We already have a syntax for a >> function... why not use it. ie: >> >> f = filter(def (a): return a > 1, [1,2,3]) Kay> You mix expressions with statements. You could remove the "return" and restrict the body of the def to an expression: f = filter(def (a): a > 1, [1,2,3]) That looks almost exactly like a lambda, but uses "def" and parenthesizes the argument list. It seems to me that would remind people "this is a function". Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Reinhold Birkenfeld wrote: >> >>lambda x,y: x+y*y >>lambda x,y: y**2+x >> >> are essentialy the same functions with different implementations [1]. > > > Except that they are not. Think of __pow__, think of __add__ and __radd__. You know the difference between the concept of a function and it's infinitely many representations? That's why formal definitions exist. > > Reinhold > > Just for refresh: "Formally, a function f from a set X of input values to a set Y of possible output values (written as f : X -> Y) is a relation between X and Y which satisfies: 1. f is total, or entire: for all x in X, there exists a y in Y such that x f y (x is f-related to y), i.e. for each input value, there is at least one output value in Y. 2. f is many-to-one, or functional: if x f y and x f z, then y = z. i.e., many input values can be related to one output value, but one input value cannot be related to many output values. A more concise expression of the above definition is the following: a function from X to Y is a subset f of the cartesian product X × Y, such that for each x in X, there is a unique y in Y such that the ordered pair (x, y) is in f." http://en.wikipedia.org/wiki/Function_%28mathematics%29 Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Skip Montanaro wrote: > >> As I see it, a lambda is an anonymous function. An anonymous function > >> is a function without a name. We already have a syntax for a > >> function... why not use it. ie: > >> > >> f = filter(def (a): return a > 1, [1,2,3]) > > Kay> You mix expressions with statements. > > You could remove the "return" and restrict the body of the def to an > expression: > > f = filter(def (a): a > 1, [1,2,3]) > > That looks almost exactly like a lambda, but uses "def" and parenthesizes > the argument list. It seems to me that would remind people "this is a > function". Yes, but skipping the name of a function ( anonymizing it ) is not a strong reason to disallow statements in the anonymus function body. The crucial issue is the notation of callable expressions that are not statements but can be defined inside of other expressions ( e.g. inside a filter() call as in the example ). That's why I prefer notations that emphasize the expression character. Using the arrow notation ( (args) -> expr ) would be fine for me but I would not deselect Python in favor for Java if ( expr from (args) ) is used instead. To me it's a "judean popular front" vs "popular front of judea" kind of thing. Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Nick Coghlan wrote: > Donovan Baarda wrote: > >>As I see it, a lambda is an anonymous function. An anonymous function is >>a function without a name. > > > And here we see why I'm such a fan of the term 'deferred expression' > instead of 'anonymous function'. > > Python's lambda expressions *are* the former, but they are > emphatically *not* the latter. Lambda's have inputs and outputs like a function, so they can be used in place of functions. A simple deferred expression wouldn't be the same thing since it would use local names directly, but not at the time the expression is created, and couldn't (easily) be used in place of a function call. addxy = defer x+y # do this later for x in range(10): for y in range(10): print addxy# prints sums of x,y This is basically a limited single expression macro. (Which I believe isn't wanted.) A better example might be as used in a dictionary in place of a case statement. ie.. case['add'] = defer x+y, etc... Regards, Ron (Reply to this in python-list if it would be better discussed there.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 --Simple Implicit Lambda
Donovan Baarda <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > Donovan Baarda <[EMAIL PROTECTED]> wrote: > > > >>Nick Coghlan wrote: > >> > >>>Donovan Baarda wrote: > [...] > >>But isn't a function just a deferred expression with a name :-) > > > > > > A function in Python is actually a deferred sequence of statements and > > expressions. An anonymous function in Python (a lambda) is a deferred > > expression. > > in the end though, a sequence of statements that completes with a > "return value" is, when treated as a black box, indistinguishable from > an expression. Originally I thought that this also had to be qualified > with "and has no side-effects", but I see now that is not the case. Lambdas/anonymous functions are generally used when they are simple and are either to be applied _now_, or passed as a callback to someone else (sometimes people use the x = lambda..., but that is laziness, def/return is clearer). Are either of the following two examples easy to read? rslt = (def (arg): #body that handles arg ... )(argument_passed_to_fcn) foo((def (arg): #body that handles arg ... ), foo_arg, ...) I personally think they are horrible. Both of the above would be easier to read as... def _throw_away(arg): #body that handles arg ... rslt = _throw_away(argument_passed_to_fcn) foo(_throw_away, ...) > [...] > >>Oh yeah Raymond: on the "def defines some variable name"... are you > >>joking? You forgot the smiley :-) > > > > > > 'def' happens to bind the name that follows the def to the function with > > the arguments and body following the name. > > Yeah, but we don't use "def" to bind arbitary variables, only > functions/procedures. So in python, they are intimately identified with > functions and procedures. Being that this entire thread is about functions, perhaps there was an implied "function" in there? Also, with the right decorator, it becomes an arbitrary assignment method in Python 2.4 ... >>> def assign(val): ... return lambda a:val ... >>> @assign(5) ... def foo(arg): pass ... >>> foo 5 >>> > >>If there really is a serious practical reason why they must be limited > >>to expressions, why not just raise an exception or something if the > >>"anonymous function" is too complicated... > > > > > > Define "too complicated"? > > I was thinking that this is up to the interpreter... depending on what > the practical limitations are that cause the limitation in the first > place. For example... if it can't be reduced to an "expression" through > simple transforms. Care to write the transformation library for all Python statements? Care to see that multi-line anonymous function I described above? I certainly hope not. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
Kay Schluehr wrote: > Reinhold Birkenfeld wrote: > >>> >>>lambda x,y: x+y*y >>>lambda x,y: y**2+x >>> >>> are essentialy the same functions with different implementations [1]. >> >> >> Except that they are not. Think of __pow__, think of __add__ and __radd__. > > You know the difference between the concept of a function and it's > infinitely many representations? That's why formal definitions exist. I must say that I don't understand what you're after. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 276 -- Simple iterator for ints
On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The principal use case was largely met by enumerate(). From PEP 276's +1 for reject it. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gcmodule issue w/adding __del__ to generator objects
At 10:15 PM 6/18/2005 -0400, Phillip J. Eby wrote: >Okay, I think I see why you can't do it. You could guarantee that all >relevant __del__ methods get called, but it's bloody difficult to end up >with only unreachable items in gc.garbage afterwards. I think gc would >have to keep a new list for items reachable from finalizers, that don't >themselves have finalizers. Then, before creating gc.garbage, you walk the >finalizers and call their finalization (__del__) methods. Then, you put >any remaining items that are in either the finalizer list or the >reachable-from-finalizers list into gc.garbage. > >This approach might need a new type slot, but it seems like it would let us >guarantee that finalizers get called, even if the object ends up in garbage >as a result. In the case of generators, however, close() guarantees that >the generator releases all its references, and so can no longer be part of >a cycle. Thus, it would guarantee eventual cleanup of all >generators. And, it would lift the general limitation on __del__ methods. > >Hm. Sounds too good to be true. Surely if this were possible, Uncle Timmy >would've thought of it already, no? Guess we'll have to wait and see what >he thinks. Or maybe not. After sleeping on it, I realized that the problems are all in when and how often __del__ is called. The idea I had above would end up calling __del__ twice on non-generator objects. For generators it's not a problem because the first call ends up ensuring that the second call is a no-op. However, the *order* of __del__ calls makes a difference, even for generators. What good is a finally: clause if all the objects reachable from it have been finalized already, anyway? Ultimately, I'm thinking that maybe we were right not to allow try-finally to cross yield boundaries in generators. It doesn't seem like you can guarantee anything about the behavior in the presence of cycles, so what's the point? For a while I played around with the idea that maybe we could still support 'with:' in generators, though, because to implement that we could make frames call __exit__ on any pending 'with' blocks as part of their tp_clear operation. This would only work, however, if the objects with __exit__ methods don't have any references back to the frame. In essence, you'd need a way to put the __exit__ objects on a GC-managed list that wouldn't run until after all the tp_clear calls had finished. But even that is tough to make guarantees about. For example, can you guarantee in that case that a generator's 'with:' blocks are __exit__-ed in the proper order? Really, if we do allow 'with' and 'try-finally' to surround yield, I think we're going to have to tell people that it only works if you use a with or try-finally in some non-generator code to ensure that the generator.close() gets called, and that if you end up creating a garbage cycle, we either have to let it end up in gc.garbage, or just not execute its finally clause or __exit__ methods. Of course, this sort of happens right now for other things with __del__; if it's part of a cycle the __del__ method never gets called. The only difference is that it hangs around in gc.garbage, doing nothing useful. If it's garbage, it's not reachable from anywhere else, so it does nobody any good to have it around. So, maybe we should just say, "sucks to be you" and tp_clear anything that we'd otherwise have put in gc.garbage. :) In other words, since we're not going to call those __del__ methods anyway, maybe it just needs to be part of the language semantics that __del__ isn't guaranteed to be called, and a garbage collector that can't find a safe way to call it, doesn't have to. tp_dealloc for classic classes and heap types could then just skip calling __del__ if they've already been cleared... oh wait, how do you know you've been cleared? Argh. Another nice idea runs up on the rocks of reality. On the other hand, if you go ahead and run __del__ after tp_clear, the __del__ method will quickly run afoul of an AttributeError and die with only a minor spew to sys.stderr, thus encouraging people to get rid of their silly useless __del__ methods on objects that normally end up in cycles. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gcmodule issue w/adding __del__ to generator objects
Sigh. Looks like Guido already used the time machine to bring up these ideas five years ago: http://mail.python.org/pipermail/python-dev/2000-March/002514.html And apparently you went back with him: http://mail.python.org/pipermail/python-dev/2000-March/002478.html So I give up, 'cause there's no way I can compete with you time travellers. :) Although I do wonder -- why was __cleanup__ never implemented? The only clue seems to be Guido's comment that he "[finds] having a separate __cleanup__ protocol cumbersome." It certainly seems to me that having a __cleanup__ that allows an object to handle itself being garbage would be handy, although it's only meaningful to have a __cleanup__ if you also have a __del__; otherwise, there would never be a reason to call it. Maybe that's the reason it was considered cumbersome. At 04:16 PM 6/19/2005 -0400, Phillip J. Eby wrote: >At 10:15 PM 6/18/2005 -0400, Phillip J. Eby wrote: > >Okay, I think I see why you can't do it. You could guarantee that all > >relevant __del__ methods get called, but it's bloody difficult to end up > >with only unreachable items in gc.garbage afterwards. I think gc would > >have to keep a new list for items reachable from finalizers, that don't > >themselves have finalizers. Then, before creating gc.garbage, you walk the > >finalizers and call their finalization (__del__) methods. Then, you put > >any remaining items that are in either the finalizer list or the > >reachable-from-finalizers list into gc.garbage. > > > >This approach might need a new type slot, but it seems like it would let us > >guarantee that finalizers get called, even if the object ends up in garbage > >as a result. In the case of generators, however, close() guarantees that > >the generator releases all its references, and so can no longer be part of > >a cycle. Thus, it would guarantee eventual cleanup of all > >generators. And, it would lift the general limitation on __del__ methods. > > > >Hm. Sounds too good to be true. Surely if this were possible, Uncle Timmy > >would've thought of it already, no? Guess we'll have to wait and see what > >he thinks. > >Or maybe not. After sleeping on it, I realized that the problems are all >in when and how often __del__ is called. The idea I had above would end up >calling __del__ twice on non-generator objects. For generators it's not a >problem because the first call ends up ensuring that the second call is a >no-op. > >However, the *order* of __del__ calls makes a difference, even for >generators. What good is a finally: clause if all the objects reachable >from it have been finalized already, anyway? > >Ultimately, I'm thinking that maybe we were right not to allow try-finally >to cross yield boundaries in generators. It doesn't seem like you can >guarantee anything about the behavior in the presence of cycles, so what's >the point? > >For a while I played around with the idea that maybe we could still support >'with:' in generators, though, because to implement that we could make >frames call __exit__ on any pending 'with' blocks as part of their tp_clear >operation. This would only work, however, if the objects with __exit__ >methods don't have any references back to the frame. In essence, you'd >need a way to put the __exit__ objects on a GC-managed list that wouldn't >run until after all the tp_clear calls had finished. > >But even that is tough to make guarantees about. For example, can you >guarantee in that case that a generator's 'with:' blocks are __exit__-ed in >the proper order? > >Really, if we do allow 'with' and 'try-finally' to surround yield, I think >we're going to have to tell people that it only works if you use a with or >try-finally in some non-generator code to ensure that the generator.close() >gets called, and that if you end up creating a garbage cycle, we either >have to let it end up in gc.garbage, or just not execute its finally clause >or __exit__ methods. > >Of course, this sort of happens right now for other things with __del__; if >it's part of a cycle the __del__ method never gets called. The only >difference is that it hangs around in gc.garbage, doing nothing useful. If >it's garbage, it's not reachable from anywhere else, so it does nobody any >good to have it around. So, maybe we should just say, "sucks to be you" >and tp_clear anything that we'd otherwise have put in gc.garbage. :) > >In other words, since we're not going to call those __del__ methods anyway, >maybe it just needs to be part of the language semantics that __del__ isn't >guaranteed to be called, and a garbage collector that can't find a safe way >to call it, doesn't have to. tp_dealloc for classic classes and heap types >could then just skip calling __del__ if they've already been cleared... oh >wait, how do you know you've been cleared? Argh. Another nice idea runs >up on the rocks of reality. > >On the other hand, if you go ahead and run __del__ after tp_clear, the >__del__
[Python-Dev] misplaced PEP
At the www.python.org/peps page, PEP 281 is erroneously listed in the "Finished PEPs (done, implemented in CVS)" section. Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with embedded python
___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] misplaced PEP
Well, it's fixed now. Thanks to whomever took care of it. --- Nick Jacobson <[EMAIL PROTECTED]> wrote: > At the www.python.org/peps page, PEP 281 is > erroneously listed in the "Finished PEPs (done, > implemented in CVS)" section. > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
