Re: [Python-Dev] Active Objects in Python

[Nick Coghlan]

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
> 
>>PEP 342's yield expressions can probably be used to help address that 
>>problem, 
>>though:
>>
>>   class SomeAO(ActiveObject):
>> def processSomeMessage(self):
>>   msg = yield
>>   # Do something with the message
>>   next_msg = yield makeSomeBlockingCall(self)
>>   # Do something with the next message
> 
> 
> I don't see how that helps, since makeSomeBlockingCall()
> is evaluated (and therefore blocks) *before* the yield
> happens.

Chris got it right - I just named the function badly. The idea is that there 
would be an interaction with the Active Object's event loop to get the actual 
result back once it was available from the thread that actually made the 
blocking call. In the meantime, *this* object could continue to handle other 
messages.

What the approach allows is to have a single physical thread with a number of 
coroutiney-type event handlers running inside it.

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] PEP 350: Codetags

[Steve Holden]

Terry Hancock wrote:
> On Monday 26 September 2005 05:35 pm, Micah Elliott wrote:
> 
>>Please read/comment/vote.  This circulated as a pre-PEP proposal
>>submitted to c.l.py on August 10, but has changed quite a bit since
>>then.  I'm reposting this since it is now "Open (under consideration)"
>>at .
> 
> 
> Overall, it looks good, but my objection would be:
> 
> 
>>:Objection: I aesthetically dislike for the comment to be terminated
>>with <> in the empty field case.
>>
>>:Defense: It is necessary to have a terminator since codetags may be
>>followed by non-codetag comments.  Or codetags could be limited to
>>a single line, but that's prohibitive.  I can't think of any
>>single-character terminator that is appropriate and significantly
>>better than <>.  Maybe [EMAIL PROTECTED] could be a terminator, but then 
>> most
>>codetags will have an unnecessary @.
> 
> 
> The <> terminator is evil.  People will hate that. If there are no fields,
> you should just be able to leave it off. This will have an additional
> advantage in that many will already have compliant codetags if you leave
> off this requirement.
> 
> You worry over the need to detect the end of the block, but wouldn't '\n\n'
> be a much more natural delimiter?  I.e.:
> 
> # TODO: This is a multi-line todo tag.
> #   You see how I've gone to the next line.
> 
> # This, on the other hand is an unrelated comment. You can tell it's not
> # related, because there is an intervening blank line.  I think people
> # do this naturally when writing comments (I know I do -- I'm fairly
> # certain I've seen other people do it).
> #
> # Whereas, as you can see, a mere paragraph break can be represented by
> # a blank comment line.
> #
> # Whitespace formatting, after all, is VERY PYTHONIC. ;-)
> # Delimiters on the other hand -- well, we prefer not to mention
> # the sort of languages that use those, right? ;-)
> 
+1

> Another possibility is to recognize lines like:
> 
> #---
> #***
> #===
> 
> I.e. a comment mark followed by a line composed of repeating characters
> as an alternative separator. These are also pretty in pretty common
> use.
> 
-0

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.pycon.org

___
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] RELEASED Python 2.4.2 (final)

[Anthony Baxter]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.4.2 (final).

Python 2.4.2 is a bug-fix release. See the release notes at the 
website (also available as Misc/NEWS in the source distribution) for 
details of the more than 60 bugs squished in this release.

For more information on Python 2.4.2, including download links for
various platforms, release notes, and known issues, please see:

http://www.python.org/2.4.2

Highlights of this new release include:

  - Bug fixes. According to the release notes, more than 60 have been
fixed, including bugs that prevented Python from working properly 
on 64 bit HP/UX and AIX systems.

Highlights of the previous major Python release (2.4) are available 
from the Python 2.4 page, at

http://www.python.org/2.4/highlights.html

Enjoy the new release,
Anthony

Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)


pgpnp6D6O8ilL.pgp
Description: PGP signature
___
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] inplace operators and __setitem__

[Reinhold Birkenfeld]

Hi,

a general question. Consider:

class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)

lst = A([1,set()])

lst[0] |= 1

lst[1] |= set([1])

Do we want lst.__setitem__ to be called in the second inplace assignment?

A case where this matters is here: http://python.org/sf/1306777

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 350: Codetags

[Terry Hancock]

On Monday 26 September 2005 05:35 pm, Micah Elliott wrote:
> Please read/comment/vote.  This circulated as a pre-PEP proposal
> submitted to c.l.py on August 10, but has changed quite a bit since
> then.  I'm reposting this since it is now "Open (under consideration)"
> at .

Overall, it looks good, but my objection would be:

> :Objection: I aesthetically dislike for the comment to be terminated
> with <> in the empty field case.
> 
> :Defense: It is necessary to have a terminator since codetags may be
> followed by non-codetag comments.  Or codetags could be limited to
> a single line, but that's prohibitive.  I can't think of any
> single-character terminator that is appropriate and significantly
> better than <>.  Maybe [EMAIL PROTECTED] could be a terminator, but then 
> most
> codetags will have an unnecessary @.

The <> terminator is evil.  People will hate that. If there are no fields,
you should just be able to leave it off. This will have an additional
advantage in that many will already have compliant codetags if you leave
off this requirement.

You worry over the need to detect the end of the block, but wouldn't '\n\n'
be a much more natural delimiter?  I.e.:

# TODO: This is a multi-line todo tag.
#   You see how I've gone to the next line.

# This, on the other hand is an unrelated comment. You can tell it's not
# related, because there is an intervening blank line.  I think people
# do this naturally when writing comments (I know I do -- I'm fairly
# certain I've seen other people do it).
#
# Whereas, as you can see, a mere paragraph break can be represented by
# a blank comment line.
#
# Whitespace formatting, after all, is VERY PYTHONIC. ;-)
# Delimiters on the other hand -- well, we prefer not to mention
# the sort of languages that use those, right? ;-)

Another possibility is to recognize lines like:

#---
#***
#===

I.e. a comment mark followed by a line composed of repeating characters
as an alternative separator. These are also pretty in pretty common
use.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.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] inplace operators and __setitem__

[James Y Knight]

On Sep 28, 2005, at 9:12 AM, Reinhold Birkenfeld wrote:

> Hi,
>
> a general question. Consider:
>
> class A(list):
> def __setitem__(self, index, item):
> # do something with index and item
> return list.__setitem__(self, index, item)
>
> lst = A([1,set()])
>
> lst[0] |= 1
>
> lst[1] |= set([1])
>
> Do we want lst.__setitem__ to be called in the second inplace  
> assignment?

Yes. Right now, you can roughly explain the behavior by stating that,  
after "x=a",  "x |= y" is the same as "x = x | y", except that "a"'s  
value is undefined (it might have changed, or it might have not).

> A case where this matters is here: http://python.org/sf/1306777

This confusion between modification of immutable types and  
modification of mutable types is why I feel that it's often best to  
simply avoid the inplace operators in favor of their explicit  
equivalents. In this case, set.update().

James
___
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] RFC: readproperty

[Jim Fulton]

Read descriptors (defining only __get__) and data descripttors have
(defining __get__ and __set__) different semantics. In particular,
read descriptors are overridden by instance data, while data
descriptors are not.  A common use of read descriptors is for lazily
computed data:

   class readproperty(object):
   "Create a read descriptor from a function"

   def __init__(self, func):
   self.func = func

   def __get__(self, inst, class_):
   if inst is None:
   return self

   return self.func(inst)

   class Spam:

   @readproperty
   def eggs(self):
   ... expensive computation of eggs

   self.eggs = result
   return result

When we ask for the eggs attribute the first time, we call the
descriptor, which calls the eggs function.  The function sets the eggs
attribute, overriding the descriptor. The next time the eggs attribute
is accessed, the saved value will be used without calling the
descriptor.

I do this often enough that I think it would be useful to include it
in python, either as a builtin (like property) or in the library.  (Or
possibly by adding an option to property to generate a read
descriptor.) I'd be happy to add this for 2.5.

Thoughts?

Jim

-- 
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] inplace operators and __setitem__

[Phillip J. Eby]

At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
>Hi,
>
>a general question. Consider:
>
>class A(list):
> def __setitem__(self, index, item):
> # do something with index and item
> return list.__setitem__(self, index, item)
>
>lst = A([1,set()])
>
>lst[0] |= 1
>
>lst[1] |= set([1])
>
>Do we want lst.__setitem__ to be called in the second inplace assignment?

Yes.  See:

http://www.python.org/2.0/new-python.html#SECTION00070

The purpose of the augmented assignment forms is to allow for the 
possibility that the item's __i*__ method may or may not exist, and may or 
may not return the same object.  In the case where there is no __i*__ form, 
or it does not return the same object, the lvalue *must* be re-bound to the 
new value, or the semantics break.


>A case where this matters is here: http://python.org/sf/1306777

I've closed it as invalid; the behavior is as-defined.

In principle, there *could* be an optimization to avoid rebinding the 
lvalue in the case where the __i*__ form did return self.  But using it for 
the purpose of allowing augmented assignment to tuple members seems dubious 
at best, and likely to create confusion about the mutability or lack 
thereof of tuples.  IMO it's better to have augmented assignment to tuple 
members always fail, so that the code has to be a little more specific 
about its intent.

___
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] RFC: readproperty

[Guido van Rossum]

On 9/28/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Read descriptors (defining only __get__) and data descripttors have
> (defining __get__ and __set__) different semantics. In particular,
> read descriptors are overridden by instance data, while data
> descriptors are not.  A common use of read descriptors is for lazily
> computed data:
>
>class readproperty(object):
>"Create a read descriptor from a function"
>
>def __init__(self, func):
>self.func = func
>
>def __get__(self, inst, class_):
>if inst is None:
>return self
>
>return self.func(inst)
>
>class Spam:
>
>@readproperty
>def eggs(self):
>... expensive computation of eggs
>
>self.eggs = result
>return result
>
> When we ask for the eggs attribute the first time, we call the
> descriptor, which calls the eggs function.  The function sets the eggs
> attribute, overriding the descriptor. The next time the eggs attribute
> is accessed, the saved value will be used without calling the
> descriptor.
>
> I do this often enough that I think it would be useful to include it
> in python, either as a builtin (like property) or in the library.  (Or
> possibly by adding an option to property to generate a read
> descriptor.) I'd be happy to add this for 2.5.
>
> Thoughts?

I like the idea of adding this functionality somewhere. I do note that
the semantics were somewhat of an accident, required by backwards
compatibility with pre-2.2 method lookup semantics.

I think we need to be real careful with chosing a name -- in Jim's
example, *anyone* could assign to Spam().eggs to override the value.
The name "readproperty" is too close to "readonlyproperty", but
read-only it ain't! "Lazy" also doesn't really describe what's going
on.

I believe some folks use a concept of "memo functions" which resemble
this proposal except the notation is different: IIRC a memo function
is always invoked as a function, but stores its result in a private
instance variable, which it returns upon subsequent calls. This is a
common pattern. Jim's proposal differs because the access looks like
an attribute, not a method call. Still, perhaps memoproperty would be
a possible name.

Another way to look at the naming problem is to recognize that the
provided function really computes a default value if the attribute
isn't already set. So perhaps defaultproperty?

(Sorry to turn this into a naming game, which is bound to produce 100s
of competing proposals that are totally unintuitive except to the
proposer. But naming is important.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] RFC: readproperty

[Phillip J. Eby]

At 10:16 AM 9/28/2005 -0400, Jim Fulton wrote:
>I do this often enough that I think it would be useful to include it
>in python, either as a builtin (like property) or in the library.  (Or
>possibly by adding an option to property to generate a read
>descriptor.) I'd be happy to add this for 2.5.
>
>Thoughts?

You mean something like defaultproperty(func), where func(ob) is called at 
most once when there is no dictionary entry for the attribute?

I started using such properties with PEAK a few years ago, and found some 
corner cases that made me decide to stick with ones that have both __get__ 
and __set__.  Mostly those cases have to do with creating class-level 
properties, which can end up being inherited by subclasses if you don't 
include __set__.  Also of course you can't hook the setting of attributes 
without a __set__.

Of course, most people aren't likely to be creating metaclass properties, 
so it's probably not a big issue for the stdlib.  But I thought *you* might 
want to know about it, in case you hadn't already encountered the issue.  :)

The other issue I found with such properties is that I really wanted to be 
able to use functions that didn't rebind the attribute value directly, 
i.e., I wanted to be able to use lambdas for short computed property 
descriptions.  However, to make this work you have to know what attribute 
name(s) the property is stored under in the class, which then leads to 
other interesting complications.  So now I use a custom C type that knows 
its name and takes two functions (a filter for values set, and a function 
to compute the default).

Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice 
if there were a descriptor hook __bind__(cls,name) that was called by 
classes during cls.__new__ or assignment to a class attribute, and which 
you could define to return a replacement descriptor.  It seems like one of 
the first metaclasses I end up writing in any new project is something to 
do this, and I believe Ian Bicking has encountered the same thing in e.g. 
SQLObject.

___
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] RFC: readproperty

[Michael Hudson]

"Phillip J. Eby" <[EMAIL PROTECTED]> writes:

> Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice 
> if there were a descriptor hook __bind__(cls,name) that was called by 
> classes during cls.__new__ or assignment to a class attribute, and which 
> you could define to return a replacement descriptor.  It seems like one of 
> the first metaclasses I end up writing in any new project is something to 
> do this, and I believe Ian Bicking has encountered the same thing in e.g. 
> SQLObject.

I've done this many times too, but I've never really felt the need to
propose a change to Python for it.  I guess one could modify the
descriptor protocol slightly, but is it worth it?  Hmm, dunno.

Cheers,
mwh

-- 
  First time I've gotten a programming job that required a drug
  test.  I was worried they were going to say "you don't have
  enough LSD in your system to do Unix programming".   -- Paul Tomblin
   -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
___
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] inplace operators and __setitem__

[Reinhold Birkenfeld]

Phillip J. Eby wrote:

>>A case where this matters is here: http://python.org/sf/1306777
> 
> I've closed it as invalid; the behavior is as-defined.
> 
> In principle, there *could* be an optimization to avoid rebinding the 
> lvalue in the case where the __i*__ form did return self.  But using it for 
> the purpose of allowing augmented assignment to tuple members seems dubious 
> at best, and likely to create confusion about the mutability or lack 
> thereof of tuples.  IMO it's better to have augmented assignment to tuple 
> members always fail, so that the code has to be a little more specific 
> about its intent.

Okay. I assume that we must accept that

s = set()
t = (s,)
t[0] |= set([1])

changes s in spite of raising TypeError.

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] inplace operators and __setitem__

[Pierre Barbier de Reuille]

Phillip J. Eby a écrit :
> At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
[...]
> Yes.  See:
> 
> http://www.python.org/2.0/new-python.html#SECTION00070
> 
> The purpose of the augmented assignment forms is to allow for the 
> possibility that the item's __i*__ method may or may not exist, and may or 
> may not return the same object.  In the case where there is no __i*__ form, 
> or it does not return the same object, the lvalue *must* be re-bound to the 
> new value, or the semantics break.
> 
> 
> 
>>A case where this matters is here: http://python.org/sf/1306777
> 
> 
> I've closed it as invalid; the behavior is as-defined.

Rather than closing this as invalid, it would be wiser to update the
documentation before ! Nothing corresponds to the current behavior.

I think that in this page :

http://docs.python.org/ref/augassign.html

The last paragraph whould be replace by :

"""
For targets which are attribute (or indexed) references, the initial
value is retrieved with a getattr() (resp. __getitem__) and the result
is assigned with a setattr() (resp. __setitem__). Notice that the two
methods do not necessarily refer to the same variable. When getattr()
refers to a class variable, setattr() still writes to an instance
variable. For example:
"""

That way it will be clearly defined in the documentation.

Now, one can wonder if the augmented assignment is really an
improvement. Lots of errors are made because they are counter-intuitive.
For example, in the standard library, I found very few uses of "+=" with
a mutable object, and none would be broken if "a += b" is to be
replaced by "a = a+b". At worst, there will be a performance issue that
will easily be fixed by using "extend" method for lists and
corresponding methods for other objects.

My opinion is, redefining the augmented assignment is a problem given
the assignment semantic, and perhaps we should get rid of it.

Pierre

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
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] inplace operators and __setitem__

[Phillip J. Eby]

At 05:15 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
>Okay. I assume that we must accept that
>
>s = set()
>t = (s,)
>t[0] |= set([1])
>
>changes s in spite of raising TypeError.

There are lots of operations that can be partially completed before raising 
an error, so I'm not sure why this case would be special.

Sets do have an update() method, however, and it's unambiguous as to being 
an in-place update.  The code above would be clearer using it, and produce 
no errors:

s = set()
t = (s,)
t[0].update([1])

___
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] inplace operators and __setitem__

[Phillip J. Eby]

At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
>Rather than closing this as invalid, it would be wiser to update the
>documentation before ! Nothing corresponds to the current behavior.

I got my information from here:

http://www.python.org/2.0/new-python.html#SECTION00070


>I think that in this page :
>http://docs.python.org/ref/augassign.html
>
>The last paragraph whould be replace by :
>
>"""
>For targets which are attribute (or indexed) references, the initial
>value is retrieved with a getattr() (resp. __getitem__) and the result
>is assigned with a setattr() (resp. __setitem__). Notice that the two
>methods do not necessarily refer to the same variable. When getattr()
>refers to a class variable, setattr() still writes to an instance
>variable. For example:
>"""
>
>That way it will be clearly defined in the documentation.

Actually, the broken part is this sentence:

"""Also, when possible, the actual operation is performed in-place, meaning 
that rather than creating a new object and assigning that to the target, 
the old object is modified instead."""

It is subtly misleading, and would be better stated as:

"""Also, when possible, the actual operation is performed in-place, meaning 
that rather than creating a new object the old object is modified 
instead.  In either case, however, the assignment to the target is still 
performed."""


>Now, one can wonder if the augmented assignment is really an
>improvement. Lots of errors are made because they are counter-intuitive.

Huh?


>For example, in the standard library, I found very few uses of "+=" with
>a mutable object, and none would be broken if "a += b" is to be
>replaced by "a = a+b". At worst, there will be a performance issue that
>will easily be fixed by using "extend" method for lists and
>corresponding methods for other objects.

The intended use case (as I understand it) for augmented assignment is to 
allow you to hint that an operation should be done in place *if* it can 
be.  It means that you are not expecting a new object to be the result, but 
are prepared for the possibility it *might* be a new object.


>My opinion is, redefining the augmented assignment is a problem given
>the assignment semantic, and perhaps we should get rid of it.

How is it a problem?  If the assignment semantic weren't what it is, what 
would it be good for?  You could just write an in-place method and be done 
with it.  The whole point is that it allows client code not to care whether 
it's in-place or not, and to allow implementations to decide (even at 
runtime) whether to return a different object or not.

___
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] RFC: readproperty

[Steven Bethard]

Jim Fulton wrote:
> A common use of read descriptors is for lazily computed data:
>
>class readproperty(object):
>"Create a read descriptor from a function"
>
>def __init__(self, func):
>self.func = func
>
>def __get__(self, inst, class_):
>if inst is None:
>return self
>
>return self.func(inst)
>
>class Spam:
>
>@readproperty
>def eggs(self):
>... expensive computation of eggs
>
>self.eggs = result
>return result

I've also needed behavior like this a few times, but I use a variant
of Scott David Daniel's recipe[1]:

class _LazyAttribute(object):
def __init__(self, calculate_function):
self._calculate = calculate_function

def __get__(self, obj, _=None):
if obj is None:
return self
try:
value = self._calculate(obj)
except AttributeError, e:
# I don't like this, but if _calculate raises an
# AttributeError and I don't catch it, the descriptor
# machinery hides it and I can't debug my code
raise Exception(e)
setattr(obj, self._calculate.func_name, value)
return value

It uses the .func_name attribute to put the "self.eggs = result" into
the property.  I like that I don't have to do the set at the end of
every function, and I'm never doing anything complicated enough that I
don't want the attribute named the same as the function that I passed
in.

[1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/363602

STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] inplace operators and __setitem__

[Pierre Barbier de Reuille]

Phillip J. Eby a écrit :
> At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
> 
>> Rather than closing this as invalid, it would be wiser to update the
>> documentation before ! Nothing corresponds to the current behavior.
> 
> 
> I got my information from here:
> 
> http://www.python.org/2.0/new-python.html#SECTION00070

I know ... I already read this page as you already posted it ;)

> 
> 
>> I think that in this page :
>> http://docs.python.org/ref/augassign.html
>>
>> The last paragraph whould be replace by :
>>
>> """
>> For targets which are attribute (or indexed) references, the initial
>> value is retrieved with a getattr() (resp. __getitem__) and the result
>> is assigned with a setattr() (resp. __setitem__). Notice that the two
>> methods do not necessarily refer to the same variable. When getattr()
>> refers to a class variable, setattr() still writes to an instance
>> variable. For example:
>> """
>>
>> That way it will be clearly defined in the documentation.
> 
> 
> Actually, the broken part is this sentence:
> 
> """Also, when possible, the actual operation is performed in-place,
> meaning that rather than creating a new object and assigning that to the
> target, the old object is modified instead."""
> 
> It is subtly misleading, and would be better stated as:
> 
> """Also, when possible, the actual operation is performed in-place,
> meaning that rather than creating a new object the old object is
> modified instead.  In either case, however, the assignment to the target
> is still performed."""

Indeed ! I missed that one :-S
Your proposal should be integrated inside documentation (if anyone knows
how to do so ...) !!!

> 
>> Now, one can wonder if the augmented assignment is really an
>> improvement. Lots of errors are made because they are counter-intuitive.
> 
> 
> Huh?
> 

Regularly, you see questions about augmented assignment on Python-tutor
mailing list, I often have question in my lab because of problems ...
most of the time people learn to avoid these operators in the end ! And
my look in the standard library confirmed my intuition about it.

> 
>> For example, in the standard library, I found very few uses of "+=" with
>> a mutable object, and none would be broken if "a += b" is to be
>> replaced by "a = a+b". At worst, there will be a performance issue that
>> will easily be fixed by using "extend" method for lists and
>> corresponding methods for other objects.
> 
> 
> The intended use case (as I understand it) for augmented assignment is
> to allow you to hint that an operation should be done in place *if* it
> can be.  It means that you are not expecting a new object to be the
> result, but are prepared for the possibility it *might* be a new object.
> 
> 
>> My opinion is, redefining the augmented assignment is a problem given
>> the assignment semantic, and perhaps we should get rid of it.
> 
> 
> How is it a problem?  If the assignment semantic weren't what it is,
> what would it be good for?  You could just write an in-place method and
> be done with it.  The whole point is that it allows client code not to
> care whether it's in-place or not, and to allow implementations to
> decide (even at runtime) whether to return a different object or not.

The problem is: this seems to be more a problem than a solution !
There is a huge difference between in-place or not, and I find it very
difficult not to consider it. If you have a use-case for this "let the
object decide about in-place operation or not" I'd be interested as I
found none.

Pierre

PS: I'm not criticizing the assignment operator semantic which is
exactly what is should be ;)

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
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] inplace operators and __setitem__

[Phillip J. Eby]

At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
>Regularly, you see questions about augmented assignment on Python-tutor
>mailing list, I often have question in my lab because of problems ...
>most of the time people learn to avoid these operators in the end ! And
>my look in the standard library confirmed my intuition about it.

Some example of the problems would help.  For the specific bug report being 
discussed, I don't understand why someone would use augmented assignment 
with an immutable lvalue, since x |= y is short for x = x | y, which is 
clearly invalid on the face of it if x is a tuple member!


>The problem is: this seems to be more a problem than a solution !
>There is a huge difference between in-place or not, and I find it very
>difficult not to consider it.

Consider string addition.  The fact that string concatenation can be 
implemented with += allows a string to consider based on its refcount to 
return a new string or to modify itself in-place.  If someone uses a = b + 
c, it may be assumed that they still desire a reference to b, and that 
therefore the operation *cannot* be done in-place.  If they use a += b, 
then this is a *hint* that an in-place operation is desirable.

So, there are two features of augmented assignment:

1. It is a shortcut for spelling out the full assignment
2. Types that override augmented assignment methods may optimize in-place 
operations, *without the need for client code to change*.


>If you have a use-case for this "let the
>object decide about in-place operation or not" I'd be interested as I
>found none.

The whole point of it is that I don't need to *care* whether a particular 
use is such or not.  I simply say what the code intends, and then if 
somebody needs to pass in something different, or the behavior of some 
other part of the system changes, then I get that for free.  Looking for a 
specific use case for that is like looking for a use case for duck 
typing.  That is, *everything* is a use case for it, because the point 
isn't the initial state of the system.  The point is what happens when you 
*change* the system.

___
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] RFC: readproperty

[Žiga Seilnacht]

Michael Hudson  python.net> writes:

> 
> "Phillip J. Eby"  telecommunity.com> writes:
> 
> > Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice 
> > if there were a descriptor hook __bind__(cls,name) that was called by 
> > classes during cls.__new__ or assignment to a class attribute, and which 
> > you could define to return a replacement descriptor.  It seems like one of 
> > the first metaclasses I end up writing in any new project is something to 
> > do this, and I believe Ian Bicking has encountered the same thing in e.g. 
> > SQLObject.
> 
> I've done this many times too, but I've never really felt the need to
> propose a change to Python for it.  I guess one could modify the
> descriptor protocol slightly, but is it worth it?  Hmm, dunno.
> 
> Cheers,
> mwh
> 

You can use something like this to find a descriptor's name:

class Private(property):

def __init__(self, permission, fget=None, fset=None, fdel=None, doc=None):
fget = fget or 'r' in permission and self.default_fget or None
fset = fset or 'w' in permission and self.default_fset or None
fdel = fdel or 'd' in permission and self.default_fget or None
super(private, self).__init__(fget, fset, fdel, doc)

def get_attribute_name(self, instance):
my_name = None
for cls in instance.__class__.mro():
for attribute_name, attribute_object in cls.__dict__.iteritems():
if attribute_object is self:
my_name = attribute_name
break
if my_name is not None:
class_name = cls.__name__
break
attribute_name = '_%s__%s' % (class_name, my_name)
self.attribute_name = attribute_name
return attribute_name

def default_fget(self, instance):
try:
attribute_name = self.attribute_name
except AttributeError:
attribute_name = self.get_attribute_name(instance)
return getattr(instance, attribute_name)

def default_fset(self, instance, value):
try:
attribute_name = self.attribute_name
except AttributeError:
attribute_name = self.get_attribute_name(instance)
setattr(instance, attribute_name, value)

def default_fdel(self, instance):
try:
attribute_name = self.attribute_name
except AttributeError:
attribute_name = self.get_attribute_name(instance)
delattr(instance, attribute_name)

___
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] RFC: readproperty

[Oleg Broytmann]

On Wed, Sep 28, 2005 at 10:16:12AM -0400, Jim Fulton wrote:
>class readproperty(object):
[skip]
> I do this often enough

   I use it since about 2000 often enough under the name CachedAttribute:

http://cvs.sourceforge.net/viewcvs.py/ppa/qps/qUtils.py

   (The current maintainer of the code is Denis Otkidach,
http://sourceforge.net/users/ods/ .)

   It seems many people reinvent this particular wheel. Which is
understandable.

   propertytools.py, anyone?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] Active Objects in Python

[Martin v. Löwis]

Bruce Eckel wrote:
> Since the enqueuing process serializes all requests to active objects,
> and since each message-task runs to completion before the next one
> starts, the problem of threads interfering with each other is
> eliminated. Also, the enqueuing process will always happen, so even if
> the queue blocks it will be for a very short, deterministic time. So
> the theory is that Active Object systems cannot deadlock (although I
> believe they can livelock).

My experience with active objects is with SDL (the Specification and
Description Language). There, the primitive communication between
objects is through one-way messages (called signals). Such a system
can deadlock if an object doesn't produce "enough" new outgoing
messages in response to incoming messages.

If all communication is through RPCs, i.e. you owe your caller
a response, then the only way to deadlock such a system is that
all active objects terminate. The interesting question then is
whether an object can terminate while processing a message, and
whether this will cause a response to be sent back.

> But what's not clear is whether this would
> require knowledge of the innards of the Python interpreter (which I
> don't have) or if it could be built using libraries.

As others have pointed out, you have to find a way to deal with the
standard library. In principle, each active object should have its
own copy of the standard library. For some modules/objects, this is
not reasonable (e.g. stdout). In OCCAM, host IO itself is (conceptually)
an occam process, so sys.stdout would have to become an active
object. In that approach, you would essentially have to rewrite
parts of the standard library, wrapping the underlying modules
appropriately.

> BTW: I think that Hoare's Communicating Sequential Processes (CSP)
> basically describes the idea of active objects but without objects.
> That is, I think active objects is CSP applied to OO.

I don't believe this is true. In CSP, communication between processes
is through rendezvous, which is quite different from active objects,
as there is no queue for incoming calls - instead, the receiving process
must expect a specific communication partner just like the sending
process; there is also no inherent request/response mechanism in
CSP.

In CSP, there is plenty of chance for deadlocks. If a process becomes
STOP (i.e. the process that will never again interact), then any
communication attempt with that process also cause the partner to
become STOP.

Regards,
Martin
___
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] RFC: readproperty

[Phillip J. Eby]

At 05:28 PM 9/28/2005 +, Žiga Seilnacht wrote:

>You can use something like this to find a descriptor's name:
 > 

The given code fails if the same property appears under more than one name 
or is used in more than one class.  It also requires the property object to 
be mutable, and is subject to inter-thread race conditions in the case of 
modification of a class.  It also doesn't work for class-level descriptors 
(added to the class' class), and I'd prefer it to use the logical 
equivalent of ob.__dict__.setdefault() rather than setattr(ob,...) so that 
it's free of (simple) race conditions in the case where one thread sets the 
attribute while another is computing the default value.

While these aren't crippling limitations in a given application, I think 
the stdlib implementation should be a bit more robust, especially since 
none of these features is very hard to implement, once you know what's 
needed.  (And I already have a robust implementation that could be cribbed 
from.)

In any case, having a stdlib version that doesn't address those issues 
wouldn't be very useful for me, as it wouldn't allow me to replace my 
custom C descriptor and metaclass.  If we added __bind__ (or something like 
it) to the descriptor protocol I could get rid of *at least* that 
metaclass, and maybe others.

___
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] RFC: readproperty

[Nick Coghlan]

Oleg Broytmann wrote:
>It seems many people reinvent this particular wheel. Which is
> understandable.
> 
>propertytools.py, anyone?

"import magic" ;)

Cheers,
Nick.

P.S. Such a module may actually be a good idea, if it reduces the variation in 
metaclass and descriptor hacks across some of the more complex framework.

-- 
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] RFC: readproperty

[Barry Warsaw]

On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:

> When we ask for the eggs attribute the first time, we call the
> descriptor, which calls the eggs function.  The function sets the eggs
> attribute, overriding the descriptor. The next time the eggs attribute
> is accessed, the saved value will be used without calling the
> descriptor.
> 
> I do this often enough that I think it would be useful to include it
> in python, either as a builtin (like property) or in the library.  (Or
> possibly by adding an option to property to generate a read
> descriptor.) I'd be happy to add this for 2.5.

I /must/ be missing something.  Why not just use property as a
decorator?

class C:
@property
def eggs(self):
print 'in eggs'
self.eggs = 7
return self.eggs

>>> c = C()
>>> c.eggs
in eggs
7
>>> c.eggs
7

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] RFC: readproperty

[Guido van Rossum]

It doesn't work that way for new-style classes.

On 9/28/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:
>
> > When we ask for the eggs attribute the first time, we call the
> > descriptor, which calls the eggs function.  The function sets the eggs
> > attribute, overriding the descriptor. The next time the eggs attribute
> > is accessed, the saved value will be used without calling the
> > descriptor.
> >
> > I do this often enough that I think it would be useful to include it
> > in python, either as a builtin (like property) or in the library.  (Or
> > possibly by adding an option to property to generate a read
> > descriptor.) I'd be happy to add this for 2.5.
>
> I /must/ be missing something.  Why not just use property as a
> decorator?
>
> class C:
> @property
> def eggs(self):
> print 'in eggs'
> self.eggs = 7
> return self.eggs
>
> >>> c = C()
> >>> c.eggs
> in eggs
> 7
> >>> c.eggs
> 7
>
> -Barry
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iQCVAwUAQzsX03EjvBPtnXfVAQK43QP/dRjW11myDXRdjXcPPuaxRQ2qtUlMyAJG
> 26sedhmrF00rvKVh7U0RaGJ/Cq5iwgEbQRmXm1pbS8UKzNZxz55qGjVDXjp7Rwgr
> KJpJzz/UWVqVClRJJGDdgasRO8GUfxTYh2YPrmXaTDPLh3uscIwpwq1oapT1R4OH
> 6xJYLrjAs9M=
> =mCyw
> -END PGP SIGNATURE-
>
>
> ___
> 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/guido%40python.org
>
>
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] RFC: readproperty

[Phillip J. Eby]

At 06:23 PM 9/28/2005 -0400, Barry Warsaw wrote:
>I /must/ be missing something.  Why not just use property as a
>decorator?
>
>class C:
> @property
> def eggs(self):
> print 'in eggs'
> self.eggs = 7
> return self.eggs
>
> >>> c = C()
> >>> c.eggs
>in eggs
>7
> >>> c.eggs
>7

Because it only works in classic classes due to a bug in descriptor handling:

 >>> class C(object):
@property
 def eggs(self):
   print 'in eggs'
   self.eggs = 7
   return self.eggs

 >>> c=C()
 >>> c.eggs
in eggs

Traceback (most recent call last):
   File "", line 1, in -toplevel-
 c.eggs
   File "", line 4, in eggs
 self.eggs = 7
AttributeError: can't set attribute


___
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] RFC: readproperty

[Greg Ewing]

Guido van Rossum wrote:
> I think we need to be real careful with chosing a name

In Eiffel, the keyword "once" is used for something
analogous -- a method that is called once the first
time it's referenced, and the return value cached.

So perhaps this could be called a "once_property".

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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] RFC: readproperty

[Phillip J. Eby]

At 01:34 PM 9/29/2005 +1200, Greg Ewing wrote:
>Guido van Rossum wrote:
> > I think we need to be real careful with chosing a name
>
>In Eiffel, the keyword "once" is used for something
>analogous -- a method that is called once the first
>time it's referenced, and the return value cached.
>
>So perhaps this could be called a "once_property".

I was actually going to propose that before I thought of defaultproperty, 
and in fact my equivalent descriptor was originally called "Once", but the 
truth is that it gets called every time you delete it and reuse it, whereas 
Eiffel's once functions are called once, period, with no way to reset 
them.  (At least, IIRC.)

___
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] RFC: readproperty

[Barry Warsaw]

On Wed, 2005-09-28 at 19:14, Phillip J. Eby wrote:

> Because it only works in classic classes due to a bug in descriptor handling:

Blah. ;)
-Barry



signature.asc
Description: This is a digitally signed message part
___
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] release24-maint is UNFROZEN. 2.4.3 around March or so.

[Anthony Baxter]

So no brown-paper-bag bugs have been reported that I've seen, so let's 
unfreeze the release24-maint branch. Note that there will be at least 
a 2.4.3, probably around Feb-March next year (around the time of 
2.5a1, as currently vaguely planned). I might also cut a final 2.4.4 
after 2.5 final is out.

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] inplace operators and __setitem__

[Pierre Barbier de Reuille]

Ok, so I took a closer look at the documentation and tried a few things
to understand better what you said and I have some remark ...

Phillip J. Eby a ecrit :
> At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
> 
>> Regularly, you see questions about augmented assignment on Python-tutor
>> mailing list, I often have question in my lab because of problems ...
>> most of the time people learn to avoid these operators in the end ! And
>> my look in the standard library confirmed my intuition about it.
> 
> 
> Some example of the problems would help.  For the specific bug report
> being discussed, I don't understand why someone would use augmented
> assignment with an immutable lvalue, since x |= y is short for x = x |
> y, which is clearly invalid on the face of it if x is a tuple member!

Well, the problem is:

>>> a = ([1,2], [3,4])
>>> a[0] += [5,6]

... a[0] *is* mutable, so the author of the bug report did not feel like
its l-value was immutable as he supposed a[0] was the l-value, however
in this case, both "a" and "a[0]" are l-values !

Otherwise, a very common problem (encounter regularly with labmates):

>>> def foo(a,b):
>>>   a += b
>>>   return a
>>> a = 3
>>> b = 4
>>> c = foo(a,b) # Works fine as intended
>>> d = [1,2]
>>> e = [3,4]
>>> f = foo(d,e) # Oops ... *d* is modified

Of course, actual code is much more complex, but the problem can be
reduced to that most of the time.

Also, on your sentence (which I find much more accurate than the current
one):
"""Also, when possible, the actual operation is performed in-place,
meaning that rather than creating a new object the old object is
modified instead.  In either case, however, the assignment to the target
is still performed."""

I would add some pseudo-code equivalence like, if "__iadd__" is defined:

a += b <=> a = a.__iadd__(b)

which I believe is true from the look at the pseudo-code generated at
compile-time. Like this, it is easier to remember and much less subject
to interpretation than with human-language sentences ;)

> 
>> The problem is: this seems to be more a problem than a solution !
>> There is a huge difference between in-place or not, and I find it very
>> difficult not to consider it.
> 
> 
> Consider string addition.  The fact that string concatenation can be
> implemented with += allows a string to consider based on its refcount to
> return a new string or to modify itself in-place.  If someone uses a = b
> + c, it may be assumed that they still desire a reference to b, and that
> therefore the operation *cannot* be done in-place.  If they use a += b,
> then this is a *hint* that an in-place operation is desirable.

However, the implementation makes no use of the operator ! First, there
is no "__iadd__" in the "str" class, second documentation says that
"a+=b" and "a=a+b" are both optimized. So this does not validate for a
use-case ^_^

> 
> So, there are two features of augmented assignment:
> 
> 1. It is a shortcut for spelling out the full assignment
> 2. Types that override augmented assignment methods may optimize
> in-place operations, *without the need for client code to change*.

Sure, I understood ... still I do not see any need for that, while I can
see a bunch of problems !

>> If you have a use-case for this "let the
>> object decide about in-place operation or not" I'd be interested as I
>> found none.
> 
> 
> The whole point of it is that I don't need to *care* whether a
> particular use is such or not.  I simply say what the code intends, and
> then if somebody needs to pass in something different, or the behavior
> of some other part of the system changes, then I get that for free. 
> Looking for a specific use case for that is like looking for a use case
> for duck typing.  That is, *everything* is a use case for it, because
> the point isn't the initial state of the system.  The point is what
> happens when you *change* the system.

My point here is: if the syntax causes a problem and does not solve any,
why would we keep it ?

As for duck-typing use cases are plenty ! A huge part of my code use
benefit of duck-typing and so does the Python library, so there *are*
use-cases !

Pierre

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
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