Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Michael Urman 
On 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> On and off, I've been looking for an elegant way to handle properties using
> decorators.

Why use decorators when a metaclass will already do the trick, and
save you a line? This doesn't necessarily get around Antoine's
complaint that it looks like self refers to the wrong type, but I'm
not convinced anyone would be confused.

class MetaProperty(type):
def __new__(cls, name, bases, dct):
if bases[0] is object: # allow us to create class Property
return type.__new__(cls, name, bases, dct)
return property(dct.get('get'), dct.get('set'),
dct.get('delete'), dct.get('__doc__'))

def __init__(cls, name, bases, dct):
if bases[0] is object:
return type.__init__(cls, name, bases, dct)

class Property(object):
__metaclass__ = MetaProperty


class Test(object):
class foo(Property):
"""The foo property"""
def get(self): return self._foo
def set(self, val): self._foo = val
def delete(self): del self._foo

test = Test()
test.foo = 'Yay!'
assert test._foo == 'Yay!'
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] problem with genexp

2005-10-17 Thread Jiwon Seo 
On 10/16/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > There's a problem with genexp's that I think really needs to get
> > fixed.  See http://python.org/sf/1167751 the details are below.  This
> > code:
> >
> > >>> foo(a = i for i in range(10))
> >
> > I agree with the bug report that the code should either raise a
> > SyntaxError or do the right thing.
>
> The change to Grammar/Grammar below seems to fix the problem and all
> the tests pass.  Can anyone comment on whether this fix is
> correct/appropriate?  Is there a better way to fix the problem?
>
> -argument: [test '='] test [gen_for] # Really [keyword '='] test
> +argument: test [gen_for] | test '=' test ['(' gen_for ')'] # Really
> [keyword '='] test

The other option would be changes in the Python/compile.c (somewhat)
like following

diff -r2.352 compile.c
6356c6356,6362
-   if (TYPE(n) == argument && NCH(n) == 3) {
---
+   if (TYPE(n) == argument && NCH(n) == 4) {
+   PyErr_SetString(PyExc_SyntaxError,
+   "invalid syntax");
+   symtable_error(st, n->n_lineno);
+   return;
+   }
+   else if (TYPE(n) == argument && NCH(n) == 3) {

but IMO, changing the Grammar looks more obvious.

>
> n
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/seojiwon%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Nick Coghlan 
Michael Urman wrote:
> class Test(object):
> class foo(Property):
> """The foo property"""
> def get(self): return self._foo
> def set(self, val): self._foo = val
> def delete(self): del self._foo
> 
> test = Test()
> test.foo = 'Yay!'
> assert test._foo == 'Yay!'

Thus proving once again, that metaclasses are the one true way to monkey with 
classes ;)

Cheers,
Nick.

P.S. I think I need an email program that disables the send button after 11 
pm. . .

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 343 updated

2005-10-17 Thread Nick Coghlan 
Guido van Rossum wrote:
> On 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I hope you reverted the status to "Proposed"...

I hadn't, but I've now fixed that in CVS (both in the PEP and the PEP index), 
and added some text into the PEP saying why it was reverted to Draft.

> On the latter: I think it shouldn't; I don't like this kind of magic.
> I'll have to read it before I can comment on the rest.

I don't particularly like treating __with__ specially either, but I'm not sure 
I like the alternative.

The alternative is that we'd never be able to safely define a __with__ method 
directly on generators - the reason is that we would want a "def __with__" 
where the @context decorator has been forgotten to trigger a TypeError when it 
is used. If generator-iterators were to provide a context manager to 
automatically invoke close(), then leaving out "@context" would result in a 
very obscure bug (as g.close() would be used to finish the context, instead of 
g.next() or g.throw()).

On the other hand, if the context decorator is invoked automatically when a 
generator function is supplied to populate the __with__ slot, then using a 
generator to define a __with__ method will "just work", instead of "only works 
if you also apply the context decorator"

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 343 updated

2005-10-17 Thread Nick Coghlan 
Andrew Koenig wrote:
>> PEP 343 has been updated on python.org.
> 
>> Highlights of the changes:
> 
>>- changed the name of the PEP to be simply "The 'with' Statement"
> 
> Do you mean PEP 346, perchance?  PEP 343 is something else entirely.

No, I mean PEP 343 - it describes Guido's proposal for a "with" statement. The 
old name made perfect sense if you'd been part of the PEP 340 discussion, but 
was rather obscure otherwise.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)

2005-10-17 Thread Nick Coghlan 
Steven Bethard wrote:
> Nick Coghlan wrote:
>> Having module attribute access obey the descriptor protocol (__get__, 
>> __set__,
>> __delete__) sounds like a pretty good option to me.
>>
>> It would even be pretty backwards compatible, as I'd be hardpressed to think
>> why anyone would have a descriptor *instance* as a top-level object in a
>> module (descriptor definition, yes, but not an instance).
> 
> Aren't all functions descriptors?

So Josh pointed out.

> py> def baz():
> ... print "Evaluating baz!"
> ... return "Module attribute"
> ...
> py> baz()
> Evaluating baz!
> 'Module attribute'
> py> baz.__get__(__import__(__name__), None)
> >
> py> baz.__get__(__import__(__name__), None)()
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: baz() takes no arguments (1 given)
> 
> How would your proposal change the invocation of module-level functions?

It would, alas, break it. And now that I think about it, functions have to 
work the way they do, otherwise binding an arbitrary function to a class 
variable wouldn't work properly.

So the class descriptor protocol can't be used as is at the module level, 
because functions are descriptor instances.

Ah well, another idea runs aground on the harsh rocks of reality.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Steve Holden 
Neal Norwitz wrote:
> We all know Guido likes Python.  But the real question is do pythons like 
> Guido?
> 
>   http://python.org/neal/
> 
Neal:

Getting a 404 on this one right now.

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

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Oleg Broytmann 
On Mon, Oct 17, 2005 at 12:55:00PM +0100, Steve Holden wrote:
> >   http://python.org/neal/
> > 
> Getting a 404 on this one right now.

   No problems here, very nice fotos! :)

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 3000 and exec

2005-10-17 Thread Jim Jewett 
Guido van Rossum wrote:

> Another idea might be to change the exec() spec so that you are
> required to pass in a namespace (and you can't use locals() either!).
> Then the whole point becomes moot.

I think of exec as having two major uses:

(1)  A run-time compiler
(2)  A way to change the local namespace, based on run-time
information (such as a config file).

By turning exec into a function with its own namespace (and
enforcing a readonly locals()), the second use is eliminated.

Is this intentional for security/style/efficiency/predictability?

If so, could exec/eval at least

(1)  Be treatable as nested functions, so that they can *read* the
current namespace.
(2)  Grow a return value, so that they can more easily pass
information back to at least a (tuple of) known variable name(s).

-jJ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)

2005-10-17 Thread Guido van Rossum 
On 10/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ah well, another idea runs aground on the harsh rocks of reality.

I should point out that it's intentional that there are very few
similarities between modules and classes. Many attempts have been made
to unify the two, but these never work right, because the module can't
decide whether it behaves like a class or like an instance. Also the
direct access to global variables prevents you to put any kind of code
in the get-attribute path.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3000 and exec

2005-10-17 Thread Guido van Rossum 
On 10/17/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Another idea might be to change the exec() spec so that you are
> > required to pass in a namespace (and you can't use locals() either!).
> > Then the whole point becomes moot.
>
> I think of exec as having two major uses:
>
> (1)  A run-time compiler
> (2)  A way to change the local namespace, based on run-time
> information (such as a config file).
>
> By turning exec into a function with its own namespace (and
> enforcing a readonly locals()), the second use is eliminated.
>
> Is this intentional for security/style/efficiency/predictability?

Yes, there are lots of problems with (2); both the human reader and
the compiler often don't quite know what the intended effect is.

> If so, could exec/eval at least
>
> (1)  Be treatable as nested functions, so that they can *read* the
> current namespace.

There will be a way to get the current namespace (similar to locals()
but without its bugs). But it's probably better to create an empty
namespace and explicitly copy into it only those things that you are
willing to expose to the exec'ed code (or the things it needs).

> (2)  Grow a return value, so that they can more easily pass
> information back to at least a (tuple of) known variable name(s).

You can easily build that functionality yourself; after running
exec(), you just pick certain things out of the namespace that you
expect it to create.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread skip 

Neal> We all know Guido likes Python.  But the real question is do
Neal> pythons like Guido? 

Neal>   http://python.org/neal/

Like Steve (and unlike Oleg), I get 404s for this page.  I also tried
"www.python.org" and "~neal".

Skip

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Steve Holden 
[EMAIL PROTECTED] wrote:
> Neal> We all know Guido likes Python.  But the real question is do
> Neal> pythons like Guido? 
> 
> Neal>   http://python.org/neal/
> 
> Like Steve (and unlike Oleg), I get 404s for this page.  I also tried
> "www.python.org" and "~neal".
> 
This appears to be a DNS issue: the stuff is on creosote, 
213.84.134.214, not www or dinsdale.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Tim Peters 
[Skip]
> Like Steve (and unlike Oleg), I get 404s for this page.  I also tried
> "www.python.org" and "~neal".

The original

http://python.org/neal/

 worked fine for me, and still does.  OTOH,

 http://www.python.org/neal/

gets a 404, and (the original without the trailing backslash)

http://python.org/neal

"changes itself"  to the 404 on .
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] AST branch update

2005-10-17 Thread Armin Rigo 
Hi Jeremy,

On Thu, Oct 13, 2005 at 04:52:14PM -0400, Jeremy Hylton wrote:
> I don't think the current test suite covers all of the possible syntax
> errors that can be raised.  I'd like to add a new test suite that
> covers all of the remaining cases, perhaps moving some existing tests
> into this module as well.

You might be interested in PyPy's test suite here.  In particular,
http://codespeak.net/svn/pypy/dist/pypy/interpreter/test/test_syntax.py
contains a list of syntactically valid and invalid corner cases.

If you are willing to check out the whole of PyPy (i.e.
http://codespeak.net/svn/pypy/dist) you should also be able to run the
whole test suite, or at least the following tests:

   python test_all.py pypy/interpreter/test/test_compiler.py
   python test_all.py pypy/interpreter/pyparser/

which compare CPython's builtin compiler with our own compilers; as of
PyPy revision 18722 these tests pass on all CPython versions (2.3.5,
2.4.2, HEAD).


A bientot,

Armin.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 3000 and exec

2005-10-17 Thread Jim Jewett 
For communicating with an exec/eval child, once exec
cannot run in the current namespace, I asked that it be
possible to pass a read-only "current view" and to see
a return value.

(Guido):
>... it's probably better to create an empty namespace and
> explicitly copy into it ...

> ... just pick certain things out of the namespace [afterwards]

Yes and no.

If the exec'ed code is well defined (and it needs to be if
security is a concern), then that works well.

For more exploratory code, it can be hard to know what
in advance what the code will need, or to agree on the
names of return variables.

The simplest general API that I can come up with is

"You're allowed to see anything I can" (even if it is
in a nested scope or base class, and I realize that
you *probably* won't need it).

"Return value is whatever you explicitly choose to
return"  (Lisp's "last result" might be even simpler,
but would probably lead to confusion other places.)

-jJ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Neal Norwitz 
On 10/17/05, Tim Peters <[EMAIL PROTECTED]> wrote:
[Skip]> Like Steve (and unlike Oleg), I get 404s for this page.  I also tried> "www.python.org" and "~neal".The original
http://python.org/neal/ worked fine for me, and still does.  OTOH, http://www.python.org/neal/gets a 404, and (the original without the trailing backslash)

Yup, as most people already pointed out, I only put this up on creosote
and should have added that to the URL.  I don't have an account on
dinsdale and can't copy stuff up there AFAIK.  This URL should
work for a while longer.

  http://creosote.python.org/neal/

n

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unicode charmap decoders slow

2005-10-17 Thread Tony Nelson 
At 11:56 AM +0200 10/16/05, Martin v. Löwis wrote:
>Tony Nelson wrote:
>> BTW, Martin, if you care to, would you explain to me how a Trie would be
>> used for charmap encoding?  I know a couple of approaches, but I don't know
>> how to do it fast.  (I've never actually had the occasion to use a Trie.)
>
>I currently envision a three-level trie, with 5, 4, and 7 bits. You take
>the Unicode character (only chacters below U+ supported), and take
>the uppermost 5 bits, as index in an array. There you find the base
>of a second array, to which you add the next 4 bits, which gives you an
>index into a third array, where you add the last 7 bits. This gives
>you the character, or 0 if it is unmappable.

Umm, 0 (NUL) is a valid output character in most of the 8-bit character
sets.  It could be handled by having a separate "exceptions" string of the
unicode code points that actually map to the exception char.  Usually
"exceptions" would be a string of length 1.  Suggested changes below.


>struct encoding_map{
>   unsigned char level0[32];
>   unsigned char *level1;
>   unsigned char *level2;

Py_UNICODE *exceptions;

>};
>
>struct encoding_map *table;
>Py_UNICODE character;
>int level1 = table->level0[character>>11];
>if(level1==0xFF)raise unmapped;
>int level2 = table->level1[16*level1 + ((character>>7) & 0xF)];
>if(level2==0xFF)raise unmapped;
>int mapped = table->level2[128*level2 + (character & 0x7F)];

change:

>if(mapped==0)raise unmapped;

to:

if(mapped==0) {
Py_UNICODE *ep;
for(ep=table->exceptions; *ep; ep++)
if(*ep==character)
break;
if(!*ep)raise unmapped;
}


>Over a hashtable, this has the advantage of not having to deal with
>collisions. Instead, it guarantees you a lookup in a constant time.

OK, I see the benefit.  Your code is about the same amount of work as the
hash table lookup in instructions, indirections, and branches, normally
uses less of the data cache, and has a fixed running time.  It may use one
more branch, but its branches are easily predicted.  Thank you for
explaining it.


>It is also quite space-efficient: all tables use bytes as indizes.
>As each level0 deals with 2048 characters, most character maps
>will only use 1 or two level1 blocks, meaning 16 or 32 bytes
>for level1. The number of level3 blocks required depends on
>the number of 127-character rows which the encoding spans;
>for most encodings, 3 or four such blocks will be sufficient
>(with ASCII spanning one such block typically), causing the
>entire memory consumption for many encodings to be less than
>600 bytes.
 ...

As you are concerned about pathological cases for hashing (that would make
the hash chains long), it is worth noting that in such cases this data
structure could take 64K bytes.  Of course, no such case occurs in standard
encodings, and 64K is affordable as long is it is rare.

TonyN.:'   
  '  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread skip 

Neal> This URL should work for a while longer.

Neal> http://creosote.python.org/neal/

Ah, the vagaries of URL redirection.  Thanks...

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Guido v. Python, Round 1

2005-10-17 Thread Greg Ewing 
Neal Norwitz wrote:
> We all know Guido likes Python.  But the real question is do pythons like 
> Guido?
> 
>   http://python.org/neal/

??? I get a 404 for this.

-- 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Greg Ewing 
Guido van Rossum wrote:

> With decorators there was a concrete issue: the modifier trailed after
> the function body, in a real sense "hiding" from the reader.

A similar thing happens with properties, the property
definition (which is the public interface) trailing
after the accessor methods (which are an implementation
detail).

 > Certainly the proposed solutions so far are worse than
 > the problem.

I agree with that (except for mine, of course :-).

I still feel that the ultimate solution lies in some form
of syntactic support, although I haven't decided what
yet.

> But since you define the API, are you sure that you need properties at
> all? Maybe the users would be happy to write widget.get_foo() and
> widget.set_foo(x) instead of widget.foo or widget.foo = x?

I'm one of my main users, and I wouldn't be happy with
it. I *have* thought about this quite carefully. An early
version of the PyGUI API (predating properties) did things
that way, and people complained. After re-doing it with
properties, and getting some experience using the result,
I'm convinced that properties are the way to go for this
particular application.

> To which Tim Delaney responded, "have a look at my response here:"
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
> 
> I looked at that, and now I believe it's actually *better* to mention
> the property name twice, at least compared to Tim' s approach.

I'm inclined to agree. Passing functions that you're not
going to use as functions but just use the name of doesn't
seem right.

And in my version, it's not *really* redundant, since the
name is only used to derive the names of the accessor methods.
It doesn't *have* to be the same as the property name, although
using anything else could justifiably be regarded as insane...

-- 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Guido van Rossum 
[Guido]
> > I looked at that, and now I believe it's actually *better* to mention
> > the property name twice, at least compared to Tim' s approach.

[Greg Ewing]
> I'm inclined to agree. Passing functions that you're not
> going to use as functions but just use the name of doesn't
> seem right.
>
> And in my version, it's not *really* redundant, since the
> name is only used to derive the names of the accessor methods.
> It doesn't *have* to be the same as the property name, although
> using anything else could justifiably be regarded as insane...

OK, so how's this for a radical proposal.

Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.

If an argument is a string, it should be a method name, and the method
is looked up by that name each time the property is used. Because this
is late binding, it can be put before the method definitions, and a
subclass can override the methods. Example:

class C:

foo = property('getFoo', 'setFoo', None, 'the foo property')

def getFoo(self):
return self._foo

def setFoo(self, foo):
self._foo = foo

What do you think?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Greg Ewing 
Guido van Rossum wrote:

> Let's change the property built-in so that its arguments can be either
> functions or strings (or None).
> 
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used.

That sounds reasonable.

-- 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Barry Warsaw 
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:

> Let's change the property built-in so that its arguments can be either
> functions or strings (or None). If they are functions or None, it
> behaves exactly like it always has.
> 
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used. Because this
> is late binding, it can be put before the method definitions, and a
> subclass can override the methods. Example:
> 
> class C:
> 
> foo = property('getFoo', 'setFoo', None, 'the foo property')
> 
> def getFoo(self):
> return self._foo
> 
> def setFoo(self, foo):
> self._foo = foo
> 
> What do you think?

Ick, for all the reasons that strings are less appealing than names. 
IMO, there's not enough advantage in having the property() call before
the functions than after.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Greg Ewing 
Barry Warsaw wrote:

> Ick, for all the reasons that strings are less appealing than names. 
> IMO, there's not enough advantage in having the property() call before
> the functions than after.

That's not the only benefit - you also get overridability
of the accessor methods.

-- 
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Guido van Rossum 
[Guido]
> > Let's change the property built-in so that its arguments can be either
> > functions or strings (or None). If they are functions or None, it
> > behaves exactly like it always has.
> >
> > If an argument is a string, it should be a method name, and the method
> > is looked up by that name each time the property is used. Because this
> > is late binding, it can be put before the method definitions, and a
> > subclass can override the methods. Example:
> >
> > class C:
> >
> > foo = property('getFoo', 'setFoo', None, 'the foo property')
> >
> > def getFoo(self):
> > return self._foo
> >
> > def setFoo(self, foo):
> > self._foo = foo
> >
> > What do you think?

[Barry]
> Ick, for all the reasons that strings are less appealing than names.

I usually wholeheartedly agree with that argument, but here I don't
see an alternative.

> IMO, there's not enough advantage in having the property() call before
> the functions than after.

Maybe you didn't see the use case that Greg had in mind? He wants to
be able to override the getter and/or setter in a subclass, without
changing the docstring or having to repeat the property() call. That
requires us to do a late binding lookup based on a string.

Tim Delaney had a different solution where you would pass in the
functions but all it did was use their __name__ attribute to look up
the real function at runtime. The problem with that is that the
__name__ attribute may not be what you expect, as it may not
correspond to the name of the object passed in. Example:

class C:
def getx(self): ...something...
gety = getx
y = property(gety)

class D(C):
def gety(self): ...something else...

Here, the intention is clearly to override the way the property's
value is computed, but it doesn't work right -- gety.__name__ is
'getx', and D doesn't override getx, so D().y calls C.getx() instead
of D.gety().

If you can think of a solution that looks better than mine, you're a genius.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Barry Warsaw 
On Mon, 2005-10-17 at 22:24, Guido van Rossum wrote:

> > IMO, there's not enough advantage in having the property() call before
> > the functions than after.
> 
> Maybe you didn't see the use case that Greg had in mind? He wants to
> be able to override the getter and/or setter in a subclass, without
> changing the docstring or having to repeat the property() call. That
> requires us to do a late binding lookup based on a string.

True, I missed that use case.  But can't you already support
override-ability just by refactoring the getter and setter into separate
methods?  IOW, the getter and setter isn't overridden, but they call
other methods that implement the core functionality and that /are/
overridden.  Okay, that means a few extra methods per property, but that
still doesn't seem too bad.

> If you can think of a solution that looks better than mine, you're a genius.

Oh, I know that's not the case, but it's such a tempting challenge, I'll
try anyway :).

class A(object):
def __init__(self):
self._x = 0

def set_x(self, x):
self._set_x(x)

def _set_x(self, x):
print 'A._set_x()'
self._x = x

def get_x(self):
return self._get_x()

def _get_x(self):
print 'A._get_x()'
return self._x

x = property(get_x, set_x)


class B(A):
def _set_x(self, x):
print 'B._set_x()'
super(B, self)._set_x(x)

def _get_x(self):
print 'B._get_x()'
return super(B, self)._get_x()


a = A()
b = B()
a.x = 7
b.x = 9
print a.x
print b.x

Basically A.get_x() and A.set_x() are just wrappers to make the property
machinery work the way you want.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Guido van Rossum 
[Barry]
> > > IMO, there's not enough advantage in having the property() call before
> > > the functions than after.

[Guido]
> > Maybe you didn't see the use case that Greg had in mind? He wants to
> > be able to override the getter and/or setter in a subclass, without
> > changing the docstring or having to repeat the property() call. That
> > requires us to do a late binding lookup based on a string.

[Barry]
> True, I missed that use case.  But can't you already support
> override-ability just by refactoring the getter and setter into separate
> methods?  IOW, the getter and setter isn't overridden, but they call
> other methods that implement the core functionality and that /are/
> overridden.  Okay, that means a few extra methods per property, but that
> still doesn't seem too bad.
>
> > If you can think of a solution that looks better than mine, you're a genius.
>
> Oh, I know that's not the case, but it's such a tempting challenge, I'll
> try anyway :).
[...]

Nice try. I guess it's similar to this, which is a bit more concise
and doesn't require as many underscores:

class B:
def get_x(self): return self._x
def set_x(self, x): self._x = x
x = property(lambda self: self.get_x(), lambda self, x: self.set_x(x))

But I still like the version with strings better:

x = property('get_x', 'set_x')

This trades two lambdas for two pairs of string quotes; a good deal IMO!

Now, if I were to follow Paul Graham's recommendations strictly
(http://www.paulgraham.com/diff.html), point 7 saysthat Python should
have a symbol type. I've always maintained that this is unnecessary
and that we can just as well use regular strings. This makes it easy
to constructs names on the fly that you pass to getattr() and
setattr() using standard string operations. Suppose the symbol type
were written as \foo (meaning a quoted reference to the identifier
'foo'). Then the above could be written like this:

x = property(\get_x, \set_x)

But I'm not sure this buys us anything, so I still believe that using
'set_x' and 'get_x' is just fine here. Greg Ewing, whose taste in
language features is hard to beat, seems to agree.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Aahz 
On Mon, Oct 17, 2005, Guido van Rossum wrote:
>
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used. Because this
> is late binding, it can be put before the method definitions, and a
> subclass can override the methods. Example:
> 
> class C:
> foo = property('getFoo', 'setFoo', None, 'the foo property')

+1

The only other alternative is to introduce some kind of block.  This is
a good solution that is not particularly intrusive; it leaves the door
open to a well-designed block structure later on.  The one niggle I have
is that it's going to be a little unwieldy to explain, but people who
create properties really ought to understand Python well enough to deal
with it.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Phillip J. Eby 
At 08:46 PM 10/17/2005 -0700, Guido van Rossum wrote:
>Now, if I were to follow Paul Graham's recommendations strictly
>(http://www.paulgraham.com/diff.html), point 7 saysthat Python should
>have a symbol type. I've always maintained that this is unnecessary
>and that we can just as well use regular strings.

Well, unless you're going to also do #8 ("a notation for code"), I'd agree.  :)

But then again, Graham also lists #6 ("programs composed of expressions"), 
and even though I'm often tempted by the desire to write something as a big 
expression, the truth is that most people's brains (mine included) just 
don't have enough stack space for it.  The people that have that much 
mental stack space can already write lambda+listcomp atrocities for the 
rest of us to boggle at.  :)

Logix (http://livelogix.net/logix/) basically adds everything on Graham's 
list to Python, and then compiles it to Python bytecode.  But the result is 
something that still doesn't seem very Pythonic to me.

Of course, with good restraint, it seems to me that Logix allows some very 
tasteful language extensions (John Landahl created a nice syntax sugar for 
generic functions with it), but making full-tilt use of Graham's 9 features 
seems to result in a very Lisp-like experience, even without the parentheses.

At the same time, I would note that Ruby does seem to have an edge on 
Python in terms of ability to create "little languages" of the sort that 
Logix also excels at.  Compare SCons (Python) with Rakefiles (Ruby), for 
example, or SQLObject (Python) to Rails' ActiveRecord.  In each case, the 
Python DSL syntax is okay, but Ruby's is better.  Even PEP 340 in its 
heydey wasn't going to improve on it much, because Ruby DSL's benefit 
mainly from being able to pass the blocks to functions which could then 
hold on to them for later use.  (Also, in an ironic twist, Ruby requires 
fewer parentheses than Python for such operations, so the invocation looks 
more like user-defined syntax.)

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Steven Bethard 
Barry Warsaw wrote:
> On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
>
> > Let's change the property built-in so that its arguments can be either
> > functions or strings (or None). If they are functions or None, it
> > behaves exactly like it always has.
> >
> > If an argument is a string, it should be a method name, and the method
> > is looked up by that name each time the property is used. Because this
> > is late binding, it can be put before the method definitions, and a
> > subclass can override the methods. Example:
> >
> > class C:
> >
> > foo = property('getFoo', 'setFoo', None, 'the foo property')
> >
> > def getFoo(self):
> > return self._foo
> >
> > def setFoo(self, foo):
> > self._foo = foo
> >
> > What do you think?
>
> Ick, for all the reasons that strings are less appealing than names.

I'm not sure if you'll like it any better, but I combined Michael
Urman's suggestion with my late-binding property recipe to get:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418
It solves the name-repetition problem and the late-binding problem (I
believe), at the cost of either adding an extra argument to the
functions forming the property or confusing the "self" argument a
little.

STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Definining properties - a use case for class decorators?

2005-10-17 Thread Guido van Rossum 
On 10/17/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I'm not sure if you'll like it any better, but I combined Michael
> Urman's suggestion with my late-binding property recipe to get:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418
> It solves the name-repetition problem and the late-binding problem (I
> believe), at the cost of either adding an extra argument to the
> functions forming the property or confusing the "self" argument a
> little.

That is probably as good as you can get it *if* you prefer the nested
class over a property call with string arguments. Personally, I find
the nested class inheriting from Property a lot more "magical" than
the call to property() with string arguments.

I wonder if at some point in the future Python will have to develop a
macro syntax so that you can write

Property foo:
def get(self): return self._foo
...etc...

which would somehow translate into code similar to your recipe.

But until then, I prefer the simplicity of

foo = property('get_foo', 'set_foo')

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com