[Python-Dev] Re: Patch review: [ 1094542 ] add Bunch type to collections module
Hi all, Steven Bethard wrote: > Alan Green <[EMAIL PROTECTED]> wrote: >> Steven Bethard is proposing a new collection class named Bunch. I had >> a few suggestions which I attached as comments to the patch - but what >> is really required is a bit more work on the draft PEP, and then >> discussion on the python-dev mailing list. >> >> http://sourceforge.net/tracker/?func=detail&aid=1100942&group_id=5470&atid=305470 > > I believe the correct tracker is: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470 A while back, when I started writing ipython, I had to write this same class (I called it Struct), and I ended up building a fairly powerful one for handling ipython's reucursive configuration system robustly. The design has some nasty problems which I'd change if I were doing this today (I was just learning the language at the time). But it also taught me a few things about what one ends up needing from such a beast in complex situations. I've posted the code here as plain text and syntax-highlighted html, in case anyone is interested: http://amath.colorado.edu/faculty/fperez/python/Struct.py http://amath.colorado.edu/faculty/fperez/python/Struct.py.html One glaring problem of my class is the blocking of dictionary method names as attributes, this would have to be addressed differently. But one thing which I really find necessary from a useful 'Bunch' class, is the ability to access attributes via foo[name] (which requires implementing __getitem__). Named access is convenient when you _know_ the name you need (foo.attr). However, if the name of the attribute is held in a variable, IMHO foo[name] beats getattr(foo,name) in clarity and feels much more 'pythonic'. Another useful feature of this Struct class is the 'merge' method. While mine is probably overly flexible and complex for the stdlib (though it is incredibly useful in many situations), I'd really like dicts/Structs to have another way of updating with a single method, which was non-destructive (update automatically overwrites with the new data). Currently this is best done with a loop, but a 'merge' method which would work like 'update', but without overwriting would be a great improvement, I think. Finally, my values() method allows an optional keys argument, which I also find very useful. If this keys sequence is given, values are returned only for those keys. I don't know if anyone else would find such a feature useful, but I do :). It allows a kind of 'slicing' of dicts which can be really convenient. I understand that my Struct is much more of a dict/Bunch hybrid than what you have in mind. But in heavy usage, I quickly realized that at least having __getitem__ implemented was an immediate need in many cases. Finally, the Bunch class should have a way of returning its values easily as a plain dictionary, for cases when you want to pass this data into a function which expects a true dict. Otherwise, it will 'lock' your information in. I really would like to see such a class in the stdlib, as it's something that pretty much everyone ends up rewriting. I certainly don't claim my implementation to be a good reference (it isn't). But perhaps it can be useful to the discussion as an example of a 'battle-tested' such class, flaws and all. I think the current pre-PEP version is a bit too limited to be generally useful in complex, real-world situtations. It would be a good starting point to subclass for more demanding situations, but IMHO it would be worth considering a more powerful default class. Regards, ___ 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 309 (Was: Patch review: [ 1094542 ] add Bunch type to collections module)
On Thu, 27 Jan 2005 01:07:06 -0700, Fernando Perez <[EMAIL PROTECTED]> wrote: > I really would like to see such a class in the stdlib, as it's something that > pretty much everyone ends up rewriting. I certainly don't claim my > implementation to be a good reference (it isn't). But perhaps it can be > useful to the discussion as an example of a 'battle-tested' such class, flaws > and all. On the subject of "things everyone ends up rewriting", what needs to be done to restart discussion on PEP 309 (Partial Function Application)? The PEP is marked "Accepted" and various patches exist: 941881 - C implementation 1006948 - Windows build changes 931010 - Unit Tests 931007 - Documentation 931005 - Reference implementation (in Python) I get the impression that there are some outstanding tweaks required to the Windows build, but I don't have VS.NET to check and/or update the patch. Does this just need a core developer to pick it up? I guess I'll go off and do some patch/bug reviews... Paul. ___ 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] Patch review: [ 1009811 ] Add missing types to__builtin__
On Thu, 27 Jan 2005 02:01:20 -0500, James Y Knight <[EMAIL PROTECTED]> wrote: > Basically, I'd like to see them be given a binding somewhere, and have > their claimed module agree with that, but am not particular as to > where. Option #2 seemed to be rejected last time, and option #1 was > given approval, so that's what I wrote a patch for. It sounds like it's > getting pretty strong "no" votes this time around, however. Therefore, > I would like to suggest option #3, with being, say, > 'internals'. +1 -- --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] Patch review: [ 1009811 ] Add missing typesto__builtin__
[James Y Knight] > > Basically, I'd like to see them be given a binding somewhere, and have > > their claimed module agree with that, but am not particular as to > > where. Option #2 seemed to be rejected last time, and option #1 was > > given approval, so that's what I wrote a patch for. It sounds like it's > > getting pretty strong "no" votes this time around, however. Therefore, > > I would like to suggest option #3, with being, say, > > 'internals'. [GvR] > +1 That gives them a place to live and doesn't clutter __builtin__. However, it should be named __internals__. The next question is how to document it. My preference is to be clear that it is implementation specific (Jython won't have cell, PyCFunction, and dictproxy types); that it is subject to change between versions (so as not to prematurely immortalize design/implementation accidents); and that they have only esoteric application (99.9% of programs won't need them and should avoid them like the plague). Calling it __internals__ will help emphasize that we are exposing parts of the implementation that were consciously left semi-private or undocumented. Raymond ___ 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] Re: Patch review: [ 1094542 ] add Bunch type to collections module
Fernando Perez <[EMAIL PROTECTED]> wrote:
> > Alan Green <[EMAIL PROTECTED]> wrote:
> >> Steven Bethard is proposing a new collection class named Bunch. I had
> >> a few suggestions which I attached as comments to the patch - but what
> >> is really required is a bit more work on the draft PEP, and then
> >> discussion on the python-dev mailing list.
>
> But one thing which I really find necessary from a useful 'Bunch' class, is
> the ability to access attributes via foo[name] (which requires implementing
> __getitem__). Named access is convenient when you _know_ the name you need
> (foo.attr). However, if the name of the attribute is held in a variable, IMHO
> foo[name] beats getattr(foo,name) in clarity and feels much more 'pythonic'.
My feeling about this is that if the name of the attribute is held in
a variable, you should be using a dict, not a Bunch/Struct. If you
have a Bunch/Struct and decide you want a dict instead, you can just
use vars:
py> b = Bunch(a=1, b=2, c=3)
py> vars(b)
{'a': 1, 'c': 3, 'b': 2}
> Another useful feature of this Struct class is the 'merge' method.
[snip]
> my values() method allows an optional keys argument, which I also
> find very useful.
Both of these features sound useful, but I don't see that they're
particularly more useful in the case of a Bunch/Struct than they are
for dict. If dict gets such methods, then I'd be happy to add them to
Bunch/Struct, but for consistency's sake, I think at the moment I'd
prefer that people who want this functionality subclass Bunch/Struct
and add the methods themselves.
> I think the current pre-PEP version is a bit too limited to be generally
> useful in complex, real-world situtations. It would be a good starting point
> to subclass for more demanding situations, but IMHO it would be worth
> considering a more powerful default class.
I'm probably not willing to budge much on adding dict-style methods --
if you want a dict, use a dict. But if people think they're
necessary, there are a few methods from Struct that I wouldn't be too
upset if I had to add, e.g. clear, copy, etc. But I'm going to need
more feedback before I make any changes like this.
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] Patch review: [ 1009811 ] Add missing types to__builtin__
James Y Knight wrote: Sooo should (for 'generator' in objects that claim to be in __builtins__ but aren't), 1) 'generator' be added to __builtins__ 2) 'generator' be added to types.py and its __module__ be set to 'types' 3) 'generator' be added to .py and its __module__ be set to '' (and a name for the module chosen) There are more alternatives: 4) the __module__ of these types could be absent (i.e. accessing __module__ could give an AttributeError) 5) the __module__ could be present and have a value of None 6) anything could be left as is. The __module__ value of these types might be somewhat confusing, but not enough so to justify changing it to any of the alternatives, which might also be confusing (each in their own way). Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where. I think I cannot agree with this as a goal regardless of the consequences. Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with being, say, 'internals'. -1. 'internals' is not any better than 'sys', 'new', or 'types'. It is worse, as new modules are confusing to users - one more thing they have to learn. Regards, Martin ___ 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] Patch review: [ 1009811 ] Add missing types to__builtin__
> > Basically, I'd like to see them be given a binding somewhere, and have > > their claimed module agree with that, but am not particular as to where. > > I think I cannot agree with this as a goal regardless of the consequences. Other than a vague feeling of completeness is there any reason this needs to be done? Is there anything useful that currently cannot be expressed without this new module? Raymond ___ 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] Patch review: [ 1009811 ] Add missing types to__builtin__
Raymond Hettinger wrote: Other than a vague feeling of completeness is there any reason this needs to be done? Is there anything useful that currently cannot be expressed without this new module? That I wonder myself, too. Regards, Martin ___ 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] Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module
Fernando Perez wrote: > Steven Bethard wrote: > > I'm probably not willing to budge much on adding dict-style methods -- > > if you want a dict, use a dict. But if people think they're > > necessary, there are a few methods from Struct that I wouldn't be too > > upset if I had to add, e.g. clear, copy, etc. But I'm going to need > > more feedback before I make any changes like this. > > You already have update(), which by the way precludes a bunch storing an > 'update' attribute. Well, actually, you can have an update attribute, but then you have to call update from the class instead of the instance: py> from bunch import Bunch py> b = Bunch(update=3) py> b.update 3 py> b.update(Bunch(hi=4)) Traceback (most recent call last): File "", line 1, in ? TypeError: 'int' object is not callable py> Bunch.update(b, Bunch(hi=4)) py> b.hi 4 > Bunch.update(mybunch, othermapping) -> modifies mybunch. Yup, that works currently. As is normal for new-style classes (AFAIK), the methods are stored in the class object, so assigning an 'update' attribute to an instance just hides the method in the class. You can still reach the method by invoking it from the class and passing it an instance as the first argument. 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
[Python-Dev] Re: Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module
Steven Bethard wrote: > Fernando Perez wrote: >> Steven Bethard wrote: >> > I'm probably not willing to budge much on adding dict-style methods -- >> > if you want a dict, use a dict. But if people think they're >> > necessary, there are a few methods from Struct that I wouldn't be too >> > upset if I had to add, e.g. clear, copy, etc. But I'm going to need >> > more feedback before I make any changes like this. >> >> You already have update(), which by the way precludes a bunch storing an >> 'update' attribute. > > Well, actually, you can have an update attribute, but then you have to > call update from the class instead of the instance: [...] Of course, you are right. However, I think it would perhaps be best to advertise any methods of Bunch as strictly classmethods from day 1. Otherwise, you can have: b = Bunch() b.update(otherdict) -> otherdict happens to have an 'update' key ... more code b.update(someotherdict) -> boom! update is not callable If all Bunch methods are officially presented always as classmethods, users can simply expect that all attributes of a bunch are meant to store data, without any instance methods at all. Regards, f ___ 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] Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module
Steven Bethard wrote:
> Fernando Perez <[EMAIL PROTECTED]> wrote:
> My feeling about this is that if the name of the attribute is held in
> a variable, you should be using a dict, not a Bunch/Struct. If you
> have a Bunch/Struct and decide you want a dict instead, you can just
> use vars:
>
> py> b = Bunch(a=1, b=2, c=3)
> py> vars(b)
> {'a': 1, 'c': 3, 'b': 2}
Well, the problem I see here is that often, you need to mix both kinds of
usage. It's reasonable to have code for which Bunch is exactly what you need
in most places, but where you have a number of accesses via variables whose
value is resolved at runtime. Granted, you can use getattr(bunch,varname), or
make an on-the-fly dict as you indicated above. But since Bunch is above all
a convenience class for common idioms, I think supporting a common need is a
reasonable idea. Again, just my opinion.
>> Another useful feature of this Struct class is the 'merge' method.
> [snip]
>> my values() method allows an optional keys argument, which I also
>> find very useful.
>
> Both of these features sound useful, but I don't see that they're
> particularly more useful in the case of a Bunch/Struct than they are
> for dict. If dict gets such methods, then I'd be happy to add them to
> Bunch/Struct, but for consistency's sake, I think at the moment I'd
> prefer that people who want this functionality subclass Bunch/Struct
> and add the methods themselves.
It's very true that these are almost a request for a dict extension. Frankly,
I'm too swamped to follow up with a pep/patch for it, though. Pity, because
they can be really useful... Takers?
> I'm probably not willing to budge much on adding dict-style methods --
> if you want a dict, use a dict. But if people think they're
> necessary, there are a few methods from Struct that I wouldn't be too
> upset if I had to add, e.g. clear, copy, etc. But I'm going to need
> more feedback before I make any changes like this.
You already have update(), which by the way precludes a bunch storing an
'update' attribute. My class suffers from the same problem, just with many
more names. I've thought about this, and my favorite solution so far would be
to provide whichever dict-like methods end up implemented (update, merge (?),
etc) with a leading single underscore. I simply don't see any other way to
cleanly distinguish between a bunch which holds an 'update' attribute and the
update method.
I guess making them classmethods (or is it staticmethods? I don't use those so
I may be confusing terminology) might be a clean way out:
Bunch.update(mybunch, othermapping) -> modifies mybunch.
Less traditional OO syntax for bunches, but this would sidestep the potential
name conflicts.
Anyway, these are just some thoughts. Feel free to take what you like.
Regards,
f
___
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] Re: Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module
On Thu, 27 Jan 2005 18:31:55 -0700, Fernando Perez <[EMAIL PROTECTED]> wrote: > However, I think it would perhaps be best to advertise any methods of Bunch as > strictly classmethods from day 1. Otherwise, you can have: > > b = Bunch() > b.update(otherdict) -> otherdict happens to have an 'update' key > > ... more code > > b.update(someotherdict) -> boom! update is not callable > > If all Bunch methods are officially presented always as classmethods, users > can > simply expect that all attributes of a bunch are meant to store data, without > any instance methods at all. That sounds reasonable to me. I'll fix update to be a staticmethod. If people want other methods, I'll make sure they're staticmethods too.[1] Steve [1] In all the cases I can think of, staticmethod is sufficient -- the methods don't need to access any attributes of the Bunch class. If anyone has a good reason to make them classmethods instead, let me know... -- 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
[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib EditorWindow.py, 1.65, 1.66 NEWS.txt, 1.53, 1.54 config-keys.def, 1.21, 1.22 configHandler.py, 1.37, 1.38
Thanks!!!
On Thu, 27 Jan 2005 16:16:19 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Update of /cvsroot/python/python/dist/src/Lib/idlelib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5316
>
> Modified Files:
> EditorWindow.py NEWS.txt config-keys.def configHandler.py
> Log Message:
> Add keybindings for del-word-left and del-word-right.
>
> M EditorWindow.py
> M NEWS.txt
> M config-keys.def
> M configHandler.py
>
> Index: EditorWindow.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/EditorWindow.py,v
> retrieving revision 1.65
> retrieving revision 1.66
> diff -u -d -r1.65 -r1.66
> --- EditorWindow.py 19 Jan 2005 00:22:54 - 1.65
> +++ EditorWindow.py 28 Jan 2005 00:16:15 - 1.66
> @@ -141,6 +141,8 @@
> text.bind("<>",self.change_indentwidth_event)
> text.bind("", self.move_at_edge_if_selection(0))
> text.bind("", self.move_at_edge_if_selection(1))
> +text.bind("<>", self.del_word_left)
> +text.bind("<>", self.del_word_right)
>
> if flist:
> flist.inversedict[self] = key
> @@ -386,6 +388,14 @@
> pass
> return move_at_edge
>
> +def del_word_left(self, event):
> +self.text.event_generate('')
> +return "break"
> +
> +def del_word_right(self, event):
> +self.text.event_generate('')
> +return "break"
> +
> def find_event(self, event):
> SearchDialog.find(self.text)
> return "break"
>
> Index: NEWS.txt
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v
> retrieving revision 1.53
> retrieving revision 1.54
> diff -u -d -r1.53 -r1.54
> --- NEWS.txt19 Jan 2005 00:22:57 - 1.53
> +++ NEWS.txt28 Jan 2005 00:16:16 - 1.54
> @@ -3,17 +3,24 @@
>
> *Release date: XX-XXX-2005*
>
> +- Add keybindings for del-word-left and del-word-right.
> +
> - Discourage using an indent width other than 8 when using tabs to indent
>Python code.
>
> - Restore use of EditorWindow.set_indentation_params(), was dead code since
> - Autoindent was merged into EditorWindow.
> + Autoindent was merged into EditorWindow. This allows IDLE to conform to
> the
> + indentation width of a loaded file. (But it still will not switch to tabs
> + even if the file uses tabs.) Any change in indent width is local to that
> + window.
>
> - Add Tabnanny check before Run/F5, not just when Checking module.
>
> - If an extension can't be loaded, print warning and skip it instead of
>erroring out.
>
> +- Improve error handling when .idlerc can't be created (warn and exit).
> +
> - The GUI was hanging if the shell window was closed while a raw_input()
>was pending. Restored the quit() of the readline() mainloop().
>http://mail.python.org/pipermail/idle-dev/2004-December/002307.html
>
> Index: config-keys.def
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/config-keys.def,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -u -d -r1.21 -r1.22
> --- config-keys.def 17 Aug 2004 08:01:19 - 1.21
> +++ config-keys.def 28 Jan 2005 00:16:16 - 1.22
> @@ -55,6 +55,8 @@
> untabify-region=
> toggle-tabs=
> change-indentwidth=
> +del-word-left=
> +del-word-right=
>
> [IDLE Classic Unix]
> copy=
> @@ -104,6 +106,8 @@
> untabify-region=
> toggle-tabs=
> change-indentwidth=
> +del-word-left=
> +del-word-right=
>
> [IDLE Classic Mac]
> copy=
> @@ -153,3 +157,5 @@
> untabify-region=
> toggle-tabs=
> change-indentwidth=
> +del-word-left=
> +del-word-right=
>
> Index: configHandler.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/configHandler.py,v
> retrieving revision 1.37
> retrieving revision 1.38
> diff -u -d -r1.37 -r1.38
> --- configHandler.py13 Jan 2005 17:37:38 - 1.37
> +++ configHandler.py28 Jan 2005 00:16:16 - 1.38
> @@ -579,7 +579,9 @@
> '<>': [''],
> '<>': [''],
> '<>': [''],
> -'<>': ['']
> +'<>': [''],
> +'<>': [''],
> +'<>': ['']
> }
> if keySetName:
> for event in keyBindings.keys():
>
> ___
> Python-checkins mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-checkins
>
--
--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] Patch review: [ 1009811 ] Add missing types to__builtin__
On Thu, 2005-01-27 at 17:24, "Martin v. Löwis" wrote: > Raymond Hettinger wrote: > > Other than a vague feeling of completeness is there any reason this > > needs to be done? Is there anything useful that currently cannot be > > expressed without this new module? > > That I wonder myself, too. One reason is correct documentation. If the code is rejected, there should be a patch proposed to remove the erroneous documentation references that indicates things are in __builtins_ when they are in fact not. If they are put into __builtins__, the documentation won't need updating. ;-) -Jeff Rush ___ 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
