Re: [Python-Dev] [Python-checkins] cpython (3.3): PythonCAD is now on PyQt, use Wing as a prominent PyGtk example.
On Mon, Oct 07, 2013 at 12:13:18AM +0100, Michael Foord wrote: > Wing is only a good example of PyGtk until Wing 5 is out of beta. They too > have switched to PyQt... Perhaps Gramps is a good example: http://www.gramps-project.org/ I just glanced at their code and it's still using PyGtk. --amk ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451: ModuleSpec
On Sat, Oct 5, 2013 at 1:25 AM, Stefan Behnel wrote: > As a quick remark, reading the word "name" made me think a couple of times > whether it's the simple name of the module or the fully qualified name. I > think it's the FQMN in pretty much all cases, but it would be good to make > that clear, maybe by stating it somewhere near the beginning of the PEP > (and then doing a quick search+reread to make sure it's really the case > throughout the document). It's definitely always meant to be FQMN. I'll make this clear. Thanks for mentioning it. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): PythonCAD is now on PyQt, use Wing as a prominent PyGtk example.
07.10.13 16:54, A.M. Kuchling написав(ла): On Mon, Oct 07, 2013 at 12:13:18AM +0100, Michael Foord wrote: Wing is only a good example of PyGtk until Wing 5 is out of beta. They too have switched to PyQt... Perhaps Gramps is a good example: http://www.gramps-project.org/ I just glanced at their code and it's still using PyGtk. http://en.wikipedia.org/wiki/Pygtk#Notable_applications_that_use_PyGTK However "PyGTK will be phased out with the transition to GTK+ version 3 and be replaced with PyGObject, which uses GObject introspection to generate bindings for Python and other languages on the fly." ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
In article , Raymond Hettinger wrote: > On Sep 22, 2013, at 6:16 PM, Ethan Furman wrote: > > > Are we close to asking for pronouncement? > > When you're ready, let me know. > > In the meantime, I conducting usability tests on students in Python classes > and researching how well it substitutes for existing solutions for > case insensitive dictionaries (the primary use case) and for other > existing cases such as dictionaries with unicode normalized keys. > > If you want to participate in the research, I could also use help looking > at what other languages do. Python is not the first language with > mappings or to encounter use cases for transforming keys prior > to insertion and lookup. I would like to find out what work has > already been done on this problem. > > Another consideration is whether the problem is more general > that just dictionaries. Would you want similar functionality in > all mapping-like objects (i.e. a persistent dictionaries, os.environ, etc)? > Would you want similar functionality for other services > (i.e. case-insensitive filenames or other homomorphisms). > > You can also add to the discussion by trying out your own usability > tests on people who haven't been exposed to this thread or the pep. > > My early results indicate that the API still needs work. > >... > * Another issue is that we're accumulating too many dictionary > variants and that is making it difficult to differentiate and choose > between them. I haven't found anyone (even in advanced classes > with very experienced pythonistas) would knew about > all the variations: dict, defaultdict, Mapping, MutableMapping, > mapping views, OrderedDict, Counter, ChainMap, andTransformDict. I agree. I personally think being able to transform keys would be much more useful as a property of existing dictionaries. I often use case-insensitive keys. But I use them with dict and OrderedDict (and probably ought to use defaultdict, as well). TransformDict is neat, but I'd personally be happier seeing this as a 3rd party library for now. -- Russell ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
100% disagreement. Err, well, 50%. A property of existing dictionaries is useless. A separate object in, say, collections is more organized. 3rd party libraries can be hard to find, even the great ones. On Mon, Oct 7, 2013 at 3:01 PM, Russell E. Owen wrote: > In article , > Raymond Hettinger wrote: > > > On Sep 22, 2013, at 6:16 PM, Ethan Furman wrote: > > > > > Are we close to asking for pronouncement? > > > > When you're ready, let me know. > > > > In the meantime, I conducting usability tests on students in Python > classes > > and researching how well it substitutes for existing solutions for > > case insensitive dictionaries (the primary use case) and for other > > existing cases such as dictionaries with unicode normalized keys. > > > > If you want to participate in the research, I could also use help looking > > at what other languages do. Python is not the first language with > > mappings or to encounter use cases for transforming keys prior > > to insertion and lookup. I would like to find out what work has > > already been done on this problem. > > > > Another consideration is whether the problem is more general > > that just dictionaries. Would you want similar functionality in > > all mapping-like objects (i.e. a persistent dictionaries, os.environ, > etc)? > > Would you want similar functionality for other services > > (i.e. case-insensitive filenames or other homomorphisms). > > > > You can also add to the discussion by trying out your own usability > > tests on people who haven't been exposed to this thread or the pep. > > > > My early results indicate that the API still needs work. > > > >... > > * Another issue is that we're accumulating too many dictionary > > variants and that is making it difficult to differentiate and choose > > between them. I haven't found anyone (even in advanced classes > > with very experienced pythonistas) would knew about > > all the variations: dict, defaultdict, Mapping, MutableMapping, > > mapping views, OrderedDict, Counter, ChainMap, andTransformDict. > > I agree. > > I personally think being able to transform keys would be much more > useful as a property of existing dictionaries. I often use > case-insensitive keys. But I use them with dict and OrderedDict (and > probably ought to use defaultdict, as well). > > TransformDict is neat, but I'd personally be happier seeing this as a > 3rd party library for now. > > -- Russell > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > -- Ryan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: > (If we cannot find a better name, we may add more specialized classes: > KeyInsensitiveDict and IdentiyDict. But I like the idea of using my > own "transform" function.) -1 on a plethora of specialised dicts. I do think that a TransformDict seems useful, and might even *be* useful, but would not like to see a whole pile of specialised dicts added to the std lib. I wonder though, are we going about this the wrong way? Since there is apparently disagreement about TransformDict, that suggests that perhaps we need more concrete experience with the basic idea before graduating to a concrete class in the std lib. Perhaps we should follow the example of dict, __missing__ and defaultdict. The dict class could do something like this on key access: if type(self) is not dict: # This only applies to subclasses, not dict itself. try: transform = type(self).__transform__ except AttributeError: pass else: key = transform(key) # now use the key as usual Am I barking up the wrong tree? Would this slow down dict access too much? -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 8 Oct 2013 07:26, "Steven D'Aprano" wrote: > > On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: > > > (If we cannot find a better name, we may add more specialized classes: > > KeyInsensitiveDict and IdentiyDict. But I like the idea of using my > > own "transform" function.) > > -1 on a plethora of specialised dicts. > > I do think that a TransformDict seems useful, and might even *be* > useful, but would not like to see a whole pile of specialised dicts > added to the std lib. > > I wonder though, are we going about this the wrong way? Since there is > apparently disagreement about TransformDict, that suggests that perhaps > we need more concrete experience with the basic idea before graduating > to a concrete class in the std lib. Perhaps we should follow the example > of dict, __missing__ and defaultdict. The dict class could do something > like this on key access: > > if type(self) is not dict: > # This only applies to subclasses, not dict itself. > try: > transform = type(self).__transform__ > except AttributeError: > pass > else: > key = transform(key) > # now use the key as usual > > > Am I barking up the wrong tree? Would this slow down dict access too > much? The problem is doing this in a way that keeps a strong reference to the original key (and produces that when iterating) while doing the lookup based on the transformed keys. That said, with the current plan to lower the barrier to entry for PyPI dependencies (I should have the 3.4 only ensurepip proposal written up some time this week), I think it makes sense to let this one bake on PyPI for a while. I think there *is* a potentially worthwhile generalisation here, but I'm far from sure "is-a-dict" is the right data model - for composability reasons, it feels like a "has-a" relationship with an underlying data store may make more sense. (If performance is critical, you're going to write a dedicated type anyway, so composability and simplicity strike me as more important criteria at this point). Cheers, Nick. > > > -- > Steven > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 10/07/2013 02:24 PM, Steven D'Aprano wrote: On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: if type(self) is not dict: # This only applies to subclasses, not dict itself. try: transform = type(self).__transform__ except AttributeError: pass else: key = transform(key) # now use the key as usual Am I barking up the wrong tree? Would this slow down dict access too much? Considering that __transform__ would usually not exist, and triggered exceptions are costly, I think it would. From the docs[1]: (10) If a subclass of dict defines a method __missing__, if the key k is not present, the a[k] operation calls that method with the key k as argument. The a[k] operation then returns or raises whatever is returned or raised by the __missing__(k) call if the key is not present. No other operations or methods invoke __missing__(). If __missing__ is not defined, KeyError is raised. __missing__ must be a method; it cannot be an instance variable. For an example, see collections.defaultdict. New in version 2.5. So something more like: transform = getattr(self, '__transform__', None) if transform is not None: key = transform(key) ... A key difference (pun unavoidable ;) between __missing__ and __transform__ is that __missing__ is only called when a key is not found, while __transform__ needs to be called /every/ time a key is looked up: d[k] d.get(k) d.has_key(k) d.fromkeys(...) d.setdefault(...) k in d -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Mon, Oct 07, 2013 at 02:55:44PM -0700, Ethan Furman wrote: > On 10/07/2013 02:24 PM, Steven D'Aprano wrote: > >On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: > > > >if type(self) is not dict: > > # This only applies to subclasses, not dict itself. > > try: > > transform = type(self).__transform__ > > except AttributeError: > > pass > > else: > > key = transform(key) > ># now use the key as usual > > > > > >Am I barking up the wrong tree? Would this slow down dict access too > >much? > > Considering that __transform__ would usually not exist, and triggered > exceptions are costly, I think it would. I fear you are right, particularly for subclasses. dict itself would only have the cost of testing whether the instance is an actual dict, which I presume is cheap. Still, given enough "cheap" tests, the overall performance hit could be significant. [...] > So something more like: > > transform = getattr(self, '__transform__', None) > if transform is not None: > key = transform(key) > ... One minor point, being a dunder method, it should be grabbed from the class itself, not the instance: getattr(type(self), ...) > A key difference (pun unavoidable ;) between __missing__ and __transform__ > is that __missing__ is only called when a key is not found, while > __transform__ needs to be called /every/ time a key is looked up: Yes. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 10/07/2013 02:55 PM, Ethan Furman wrote: A key difference (pun unavoidable ;) between __missing__ and __transform__ is that __missing__ is only called when a key is not found, while __transform__ needs to be called /every/ time a key is looked up: d[k] d.get(k) d.has_key(k) d.fromkeys(...) d.setdefault(...) k in d Oh, and d.pop(k) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
Sorry I missed the original discussion, but isn't this a simple case of putting a decorator around the getitem method (to transform the input key) and a single line in the body of the setitem method, making this very easy adaptation of the existing dict class? Mark ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Mon, Oct 07, 2013 at 06:17:09PM -0700, Mark Janssen wrote:
> Sorry I missed the original discussion, but isn't this a simple case
> of putting a decorator around the getitem method (to transform the
> input key) and a single line in the body of the setitem method, making
> this very easy adaptation of the existing dict class?
Not really. We can try what you suggest to implement a case insensitive
dict (decorator is not needed):
py> class CaseInsensitiveDict(dict):
... def __getitem__(self, key):
... key = key.casefold() # use .lower() before Python 3.3
... return super().__getitem__(key)
... def __setitem__(self, key, value):
... key = key.casefold()
... super().__setitem__(key, value)
...
py> d = CaseInsensitiveDict()
py> d['X'] = 42
py> d
{'x': 42}
Well, that's not exactly what I was hoping for... I was hoping that the
dict would preserve case, rather than just convert it. But that's only
the start of the problem:
py> d['X'] # this works
42
py> d.pop('X') # expecting 42
Traceback (most recent call last):
File "", line 1, in
KeyError: 'X'
So no, it isn't just a matter of a trivial wrapper around __getitem__,
__setitem__ and __delitem__.
Check the bug tracker for more detail:
http://bugs.python.org/issue18986
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Tue, 8 Oct 2013 08:31:46 +1000 Nick Coghlan wrote: > > That said, with the current plan to lower the barrier to entry for PyPI > dependencies (I should have the 3.4 only ensurepip proposal written up some > time this week), I think it makes sense to let this one bake on PyPI for a > while. "the current plan to lower the barrier to entry for PyPI" sounds a lot like the obsession du jour to me :-) It's not like "ensurepip" makes it cheaper / more attractive to add dependencies. It just provides a better experience for those who *want* to use pip (and would otherwise have installed it using an explicit download). > I think there *is* a potentially worthwhile generalisation here, but I'm > far from sure "is-a-dict" is the right data model - for composability > reasons, it feels like a "has-a" relationship with an underlying data store > may make more sense. It doesn't work. Your "underlying mapping" can show too much variation for the wrapper/proxy to have sane semantics. For example, how do you combine with a defaultdict or a WeakKeyDictionary, knowing that the wrapper/proxy has to have its own internal mapping as well? > (If performance is critical, you're going to write a > dedicated type anyway, so composability and simplicity strike me as more > important criteria at this point). A dedicated CaseInsensitiveDict won't be much faster than TransformDict(str.casefold). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
