Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Martin Blais wrote: Yes. setdefaultencoding() is removed from sys by site.py. To get it again you must reload sys. Thanks. Actually, I should take the opportunity to advise people that setdefaultencoding doesn't really work. With the default default encoding, strings and Unicode objects hash equal when they are equal. If you change the default encoding, this property goes away (perhaps unless you change it to Latin-1). As a result, dictionaries where you mix string and Unicode keys won't work: you might not find a value for a string key when looking up with a Unicode object, and vice versa. 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] Definining properties - a use case for class decorators?
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
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] problem with genexp
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/seojiwon%40gmail.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] Definining properties - a use case for class decorators?
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 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 343 updated
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 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 343 updated
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 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] Autoloading? (Making Queue.Queue easier to use)
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) bound method ?.baz of module '__main__' (built-in) py baz.__get__(__import__(__name__), None)() Traceback (most recent call last): File interactive input, 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 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] Guido v. Python, Round 1
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 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] Guido v. Python, Round 1
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 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] PEP 3000 and exec
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 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] Autoloading? (Making Queue.Queue easier to use)
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 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 3000 and exec
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 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] Guido v. Python, Round 1
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 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] Guido v. Python, Round 1
[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 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] Guido v. Python, Round 1
[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 wink to the 404 on http://www.python.org/neal/. ___ 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] AST branch update
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 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] PEP 3000 and exec
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 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] Guido v. Python, Round 1
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 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] Unicode charmap decoders slow
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[character11];
if(level1==0xFF)raise unmapped;
int level2 = table-level1[16*level1 + ((character7) 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.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.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] Guido v. Python, Round 1
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 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] Guido v. Python, Round 1
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 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] Definining properties - a use case for class decorators?
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 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] Definining properties - a use case for class decorators?
[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
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] Definining properties - a use case for class decorators?
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 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] Definining properties - a use case for class decorators?
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
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] Definining properties - a use case for class decorators?
[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
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] Definining properties - a use case for class decorators?
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 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] Definining properties - a use case for class decorators?
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
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] Definining properties - a use case for class decorators?
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 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] Definining properties - a use case for class decorators?
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
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] Definining properties - a use case for class decorators?
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
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
