Re: [Python-Dev] Unicode charmap decoders slow
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.
struct encoding_map{
unsigned char level0[32];
unsigned char *level1;
unsigned char *level2;
};
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)];
if(mapped==0)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.
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.
It would be possible to remove one level of indirection (giving
some more speed) at the expense of additional memory: for
example, and 8-8 trie would use 256 bytes for level 0, and
then 256 bytes for each Unicode row where the encoding has
characters, likely resulting in 1kiB for a typical encoding.
Hye-Shik Chang version of the fast codec uses such an 8-8
trie, but conserves space by observing that most 256-char
rows are only sparsely used by encodings (e.g. if you have
only ASCII, you use only 128 characters from row 0). He
therefore strips unused cells from the row, by also recording
the first and last character per row. This brings some
space back, at the expense of slow-down again.
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
[Python-Dev] PEP 343 updated
PEP 343 has been updated on python.org. Highlights of the changes: - changed the name of the PEP to be simply "The 'with' Statement" - added __with__() method - added section on standard terminology (that is, contexts/context managers) - changed generator context decorator name to "context" - Updated "Resolved Issues" section - updated decimal.Context() example - updated closing() example so it works for objects without close methods I also added a new Open Issues section with the questions: - should the decorator be called "context" or something else, such as the old "contextmanager"? (The PEP currently says "context") - should the decorator be a builtin? (The PEP currently says yes) - should the decorator be applied automatically to generators used to write __with__ methods? (The PEP currently says yes) 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
[Python-Dev] Definining properties - a use case for class decorators?
On and off, I've been looking for an elegant way to handle properties using decorators. It hasn't really worked, because decorators are inherently single function, and properties span multiple functions. However, it occurred to me that Python already contains a construct for grouping multiple related functions together: classes. And that thought led me to this decorator: def def_property(cls_func): cls = cls_func() try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) Obviously, this decorator can only be used by decorating a function that returns the class of interest: class Demo(object): @def_property def test(): class prop: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" return prop Which gives the following behaviour: Py> Demo.test Py> Demo().test Getting attribute on instance Py> Demo().test = 1 Setting attribute on instance Py> del Demo().test Deleting attribute on instance Py> help(Demo.test) Help on property: This is a test property = get(self) = set(self, value) = delete(self) If we had class decorators, though, the decorator could be modified to skip the function invocation: def def_property(cls): try: fget = cls.get.im_func except AttributeError: fget = None try: fset = cls.set.im_func except AttributeError: fset = None try: fdel = cls.delete.im_func except AttributeError: fdel = None return property(fget, fset, fdel, cls.__doc__) And the usage would be much more direct: class Demo(object): @def_property class test: """This is a test property""" def get(self): print "Getting attribute on instance" def set(self, value): print "Setting attribute on instance" def delete(self): print "Deleting attribute on instance" Comments? Screams of horror? 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] Definining properties - a use case for class decorators?
>class Demo(object): > @def_property > class test: > """This is a test property""" > def get(self): > print "Getting attribute on instance" > def set(self, value): > print "Setting attribute on instance" > def delete(self): > print "Deleting attribute on instance" The code looks like "self" refers to a test instance, but it will actually refer to a Demo instance. This is quite misleading. ___ 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 Oct 16, 2005, at 9:56 AM, Nick Coghlan wrote: > On and off, I've been looking for an elegant way to handle > properties using > decorators. This isn't my idea, and it might have been brought up here in the past to the same sorts of screams of horror to which you refer later, but I use the 'apply' pattern without too many internal objections for this: class Foo(object): # just a simple example, practically pointless _my_property = None @apply def my_property(): def get(self): return self._my_property def set(self, value): self._my_property = value return property(get, set) IMHO, I find this easier to parse than either of your two examples. Apologies if this has already been screamed at. :-) Gary ___ 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
On 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> 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" >- added __with__() method >- added section on standard terminology (that is, contexts/context > managers) >- changed generator context decorator name to "context" >- Updated "Resolved Issues" section >- updated decimal.Context() example >- updated closing() example so it works for objects without close methods > > I also added a new Open Issues section with the questions: > >- should the decorator be called "context" or something else, such as the > old "contextmanager"? (The PEP currently says "context") >- should the decorator be a builtin? (The PEP currently says yes) >- should the decorator be applied automatically to generators used to write > __with__ methods? (The PEP currently says yes) I hope you reverted the status to "Proposed"... 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. -- --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 10/16/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > On and off, I've been looking for an elegant way to handle properties using > decorators. > > It hasn't really worked, because decorators are inherently single function, > and properties span multiple functions. > > However, it occurred to me that Python already contains a construct for > grouping multiple related functions together: classes. Nick, and everybody else trying to find a "solution" for this "problem", please don't. There's nothing wrong with having the three accessor methods explicitly in the namespace, it's clear, and probably less typing (and certainly less indenting!). Just write this: class C: def getFoo(self): ... def setFoo(self): ... foo = property(getFoo, setFoo) -- --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 343 updated
> 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. ___ 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, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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. > > > > It hasn't really worked, because decorators are inherently single function, > > and properties span multiple functions. > > > > However, it occurred to me that Python already contains a construct for > > grouping multiple related functions together: classes. > > Nick, and everybody else trying to find a "solution" for this > "problem", please don't. There's nothing wrong with having the three > accessor methods explicitly in the namespace, it's clear, and probably > less typing (and certainly less indenting!). Just write this: > > class C: > def getFoo(self): ... > def setFoo(self): ... > foo = property(getFoo, setFoo) Does this necessisarily mean a 'no' still for class decorators, or do you just not like this particular use case for them. Or, are you perhaps against this proposal due to its use of nested classes? ___ 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] Early PEP draft (For Python 3000?)
On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote: > > > locals()['x'] = 1 # Quietly fails! > > > Replaced by: > > > frame.x = 1 # Raises error > > > > What about the possibility of making this hypothetic frame object an > > indexable, such that frame[0] is the current scope, frame[1] is the > > calling scope, etc.? On the same lines, what about closure[0] for the > > current frame, while closure[1] resolves to the closure the function > > was defined in? These would ensure that you could reliably access any > > namespace you would need, without nasty stack tricks and such, and > > would make working around some of the limitation of the closures, when > > you have such a need. One might even consider a __resolve__ to be > > defined in any namespace, allowing all the namespace resolution rules > > to be overridden by code at any level. > > -1000 If you want a namespace, create one and pass it around. If the > writer of a function or method wanted you monkeying around with a > namespace, they would have given you one to work with. If they want you monkeying around with their namespace or not, you can do so with various tricks introspecting the frame stack and other internals. I was merely suggesting this as something more standardized, perhaps across the various Python implementations. It would also provide a single point of restriction when you want to disable such things. > As for closure monkeywork, you've got to be kidding. Closures in Python > are a clever and interesting way of keeping around certain things, but > are actually unnecessary with the existance of class and instance > namespaces. Every example of a closure can be re-done as a > class/instance, and many end up looking better. i mostly put that in there for completeness. ___ 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, Calvin Spealman <[EMAIL PROTECTED]> wrote: > On 10/16/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Nick, and everybody else trying to find a "solution" for this > > "problem", please don't. There's nothing wrong with having the three > > accessor methods explicitly in the namespace, it's clear, and probably > > less typing (and certainly less indenting!). Just write this: > > > > class C: > > def getFoo(self): ... > > def setFoo(self): ... > > foo = property(getFoo, setFoo) > > Does this necessisarily mean a 'no' still for class decorators, or do > you just not like this particular use case for them. Or, are you > perhaps against this proposal due to its use of nested classes? I'm still -0 on class decorators pending good use cases. I'm -1 on using a class decorator (if we were to introduce them) for get/set properties; it doesn't save writing and it doesn't save reading. -- --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] Unicode charmap decoders slow
Tony Nelson wrote: > 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. Yes. But only U+ should normally map to 0. It could be special-cased altogether. > 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. I'm not concerned with long hash chains, I dislike having collisions in the first place (even if they are only for two code points). Having to deal with collisions makes the code more complicated, and less predictable. It's primarily a matter of taste: avoid hashtables if you can :-) 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] Early PEP draft (For Python 3000?)
Calvin Spealman <[EMAIL PROTECTED]> wrote: > > On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > > > On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote: > > > > locals()['x'] = 1 # Quietly fails! > > > > Replaced by: > > > > frame.x = 1 # Raises error > > > > > > What about the possibility of making this hypothetic frame object an > > > indexable, such that frame[0] is the current scope, frame[1] is the > > > calling scope, etc.? On the same lines, what about closure[0] for the > > > current frame, while closure[1] resolves to the closure the function > > > was defined in? These would ensure that you could reliably access any > > > namespace you would need, without nasty stack tricks and such, and > > > would make working around some of the limitation of the closures, when > > > you have such a need. One might even consider a __resolve__ to be > > > defined in any namespace, allowing all the namespace resolution rules > > > to be overridden by code at any level. > > > > -1000 If you want a namespace, create one and pass it around. If the > > writer of a function or method wanted you monkeying around with a > > namespace, they would have given you one to work with. > > If they want you monkeying around with their namespace or not, you can > do so with various tricks introspecting the frame stack and other > internals. I was merely suggesting this as something more > standardized, perhaps across the various Python implementations. It > would also provide a single point of restriction when you want to > disable such things. What I'm saying is that whether or not you can modify the contents of stack frames via tricks, you shouldn't. Why? Because as I said, if the writer wanted you to be hacking around with a namespace, they should have passed you a shared namespace. >From what I understand, there are very few (good) reasons why a user should muck with stack frames, among them because it is quite convenient to write custom traceback printers (like web CGI, etc.), and if one is tricky, limit the callers of a function/method to those "allowable". There may be other good reasons, but until you offer a use-case that is compelling for reasons why it should be easier to access and/or modify the contents of stack frames, I'm going to remain at -1000. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Early PEP draft (For Python 3000?)
On 10/16/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > > > Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > > > > > On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> wrote: > > > > > locals()['x'] = 1 # Quietly fails! > > > > > Replaced by: > > > > > frame.x = 1 # Raises error > > > > > > > > What about the possibility of making this hypothetic frame object an > > > > indexable, such that frame[0] is the current scope, frame[1] is the > > > > calling scope, etc.? On the same lines, what about closure[0] for the > > > > current frame, while closure[1] resolves to the closure the function > > > > was defined in? These would ensure that you could reliably access any > > > > namespace you would need, without nasty stack tricks and such, and > > > > would make working around some of the limitation of the closures, when > > > > you have such a need. One might even consider a __resolve__ to be > > > > defined in any namespace, allowing all the namespace resolution rules > > > > to be overridden by code at any level. > > > > > > -1000 If you want a namespace, create one and pass it around. If the > > > writer of a function or method wanted you monkeying around with a > > > namespace, they would have given you one to work with. > > > > If they want you monkeying around with their namespace or not, you can > > do so with various tricks introspecting the frame stack and other > > internals. I was merely suggesting this as something more > > standardized, perhaps across the various Python implementations. It > > would also provide a single point of restriction when you want to > > disable such things. > > What I'm saying is that whether or not you can modify the contents of > stack frames via tricks, you shouldn't. Why? Because as I said, if the > writer wanted you to be hacking around with a namespace, they should > have passed you a shared namespace. > > From what I understand, there are very few (good) reasons why a user > should muck with stack frames, among them because it is quite convenient > to write custom traceback printers (like web CGI, etc.), and if one is > tricky, limit the callers of a function/method to those "allowable". > There may be other good reasons, but until you offer a use-case that is > compelling for reasons why it should be easier to access and/or modify > the contents of stack frames, I'm going to remain at -1000. I think I was wording this badly. I meant to suggest this as a way to define nested functions (or classes?) and probably access names from various levels of scope. In this way, a nested function would be able to say "bind the name 'a' in the namespace in which I am defined to this object", thus offering more fine grained approached than the current global keyword. I know there has been talk of this issue before, but I don't know if it works with or against anything said for this previously. ___ 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] Divorcing str and unicode (no more implicit conversions).
On 10/15/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> > On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> >> Martin Blais <[EMAIL PROTECTED]> writes:
> >>
> >> > How hard would that be to implement?
> >>
> >> import sys
> >> reload(sys)
> >> sys.setdefaultencoding('undefined')
> >
> > Hmmm any particular reason for the call to reload() here?
>
> Yes. setdefaultencoding() is removed from sys by site.py. To get it
> again you must reload sys.
Thanks.
cheers,
___
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:
> Nick, and everybody else trying to find a "solution" for this
> "problem", please don't.
Denying that there's a problem isn't going to make it
go away. Many people, including me, have the feeling that
the standard way of defining properties at the moment leaves
something to be desired, for all the same reasons that have
led to @-decorators.
However, I agree that trying to keep the accessor method
names out of the class namespace isn't necessary, and may
not even be desirable. The way I'm defining properties in
PyGUI at the moment looks like this:
class C:
foo = overridable_property('foo', "The foo property")
def get_foo(self):
...
def set_foo(self, x):
...
This has the advantage that the accessor methods can be
overridden in subclasses with the expected effect. This
is particularly important in PyGUI, where I have a generic
class definition which establishes the valid properties
and their docstrings, and implementation subclasses for
different platforms which supply the accessor methods.
The only wart is the necessity of mentioning the property
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
--
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?
Greg Ewing wrote:
>class C:
>
> foo = overridable_property('foo', "The foo property")
>
> def get_foo(self):
>...
>
> def set_foo(self, x):
>...
>
> This has the advantage that the accessor methods can be
> overridden in subclasses with the expected effect.
This is a point I was going to bring up.
> The only wart is the necessity of mentioning the property
> name twice, once on the lhs and once as an argument.
> I haven't thought of a good solution to that, yet.
Have a look at my comment to Steven Bethard's recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
Tim Delaney
___
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]
> > Nick, and everybody else trying to find a "solution" for this
> > "problem", please don't.
[Greg Ewing]
> Denying that there's a problem isn't going to make it
> go away. Many people, including me, have the feeling that
> the standard way of defining properties at the moment leaves
> something to be desired, for all the same reasons that have
> led to @-decorators.
My challenge to many people, including you, is to make that feeling
more concrete. Sometimes when you have such a feeling it just means
you haven't drunk the kool-aid yet. :)
With decorators there was a concrete issue: the modifier trailed after
the function body, in a real sense "hiding" from the reader. I don't
see such an issue with properties. Certainly the proposed solutions so
far are worse than the problem.
> However, I agree that trying to keep the accessor method
> names out of the class namespace isn't necessary, and may
> not even be desirable. The way I'm defining properties in
> PyGUI at the moment looks like this:
>
>class C:
>
> foo = overridable_property('foo', "The foo property")
>
> def get_foo(self):
>...
>
> def set_foo(self, x):
>...
>
> This has the advantage that the accessor methods can be
> overridden in subclasses with the expected effect. This
> is particularly important in PyGUI, where I have a generic
> class definition which establishes the valid properties
> and their docstrings, and implementation subclasses for
> different platforms which supply the accessor methods.
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?
> The only wart is the necessity of mentioning the property
> name twice, once on the lhs and once as an argument.
> I haven't thought of a good solution to that, yet.
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. Looking
at that version, I think it's obscuring the semantics; it (ab)uses the
fact that a function's name is accessible through its __name__
attribute. But (unlike Greg's version) it breaks down when one of the
arguments is not a plain function. This makes it brittle in the
context of renaming operations, e.g.:
getx = lambda self: 42
def sety(self, value): self._y = value
setx = sety
x = LateBindingProperty(getx, setx)
--
--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
[Python-Dev] Guido v. Python, Round 1
We all know Guido likes Python. But the real question is do pythons like Guido? http://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] AST branch merge status
Real life interfered with the planned merge tonight. I hope you'll all excuse and wait until tomorrow night. Jeremy On 10/16/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > I just merged the head back to the AST branch for what I hope is the > last time. I plan to merge the branch to the head on Sunday evening. > I'd appreciate it if folks could hold off on making changes on the > trunk until that merge happens. > > If this is a non-trivial inconvenience for anyone, go ahead with the > changes but send me mail to make sure that I don't lose the changes > when I do the merge. Regardless, the compiler and Grammar are off > limits. I'll blow away any changes you make there <0.1 wink>. > > Jeremy > > ___ 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)
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? 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? 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 classdecorators?
Guido van Rossum wrote: > 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 never said it was a *good* approach - just *an* approach ;) Tim Delaney ___ 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/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
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] 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
