Changes by R. David Murray rdmur...@bitdance.com:
--
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
___
poq p...@gmx.com added the comment:
It is exposed as types.DictProxyType in Python 2...
--
nosy: +poq
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
STINNER Victor victor.stin...@gmail.com added the comment:
It is exposed as types.DictProxyType in Python 2...
Yes, but the purpose of the issue is to enable its constructor. You cannot
instanciate a DictProxy in Python 2:
import types
types.DictProxyType
type 'dictproxy'
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
STINNER Victor victor.stin...@gmail.com added the comment:
Patch version 4, it is ready for a review. Summary of the patch:
- expose the internal dict_proxy() type (used for __dict__ of user classes) as
types.MappingViewType (it was exposed a types.DictProxyType in Python 2)
-
Guido van Rossum gu...@python.org added the comment:
I'd like to bikeshed a little on the name. I think it should be
MappingProxy. (We don't use view much but the place where we do use
it, for keys/values/items views, is very different I think. Also
collections.abc already defines MappingView as
STINNER Victor victor.stin...@gmail.com added the comment:
(We don't use view much but the place where we do use
it, for keys/values/items views, is very different I think.)
You are right, it's closer to a proxy because it has the same methods than a
mapping (except of some methods used to
STINNER Victor victor.stin...@gmail.com added the comment:
Oh, collections.abc contains also the mappingview type exposed with the name
dict_proxy:
dict_proxy = type(type.__dict__)
It was exposed as _abcoll.dict_proxy in Python 3.2.
It is not documented. Should we keep it for backward
Éric Araujo mer...@netwok.org added the comment:
MappingView is a strange ABC: it should probably declare __contains__ as an
abstract method.
I think that was not done because it would not be very useful: MappingView
seems to exist only as a base class for the other *View, which define
Georg Brandl ge...@python.org added the comment:
But it has nothing to do with weakrefs, so...
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
Guido van Rossum gu...@python.org added the comment:
Since it has to go *somewhere*, let's put it in the types module. It has a
variety of other types that are used in the implementation of classes and
functions and related things.
--
___
Python
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
[GvR]
Since it has to go *somewhere*, let's put it
in the types module. It has a variety of other
types that are used in the implementation of
classes and functions and related things.
+1
--
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
___
Antoine Pitrou pit...@free.fr added the comment:
There's already a weak proxy class in the weakref module. Not sure a separate
module for the other proxies is a good idea.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
Michael Foord mich...@voidspace.org.uk added the comment:
If we do create a proxy module I'd like to suggest adding all or part of
Phillip Eby's ProxyTypes:
http://pypi.python.org/pypi/ProxyTypes
I haven't used it directly, but did read through it a while ago and have ended
up
Éric Araujo mer...@netwok.org added the comment:
weakref.mappingview sounds nice to me.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
STINNER Victor victor.stin...@gmail.com added the comment:
New patch replacing dictproxy() builtin type with collections.mappingview()
type:
- dictproxy() type doesn't need to be a builtin type
- it is not specific to dict so replace dict prefix with mapping
- view is a better suffix than
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I would very much like this to go somewhere other than the collections module.
As the maintainer of that module, I've worked hard to keep it clutter free
(people frequently want to stick things in that module when they can't
Guido van Rossum gu...@python.org added the comment:
Raymond, that sounds like a very irrational way of deciding where it should go.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
Stefan Krah stefan-use...@bytereef.org added the comment:
I wonder about the name: There is already a collections.abc.MappingView.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
The weakref collections objects (sets, dicts, etc) were all put in a separate
module and that has worked out well. I suggest doing the same for proxy
objects.
In maintaining the itertools module, I learned long ago that adding
Guido van Rossum gu...@python.org added the comment:
I like the suggestion of a library module containing proxy classes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
STINNER Victor victor.stin...@gmail.com added the comment:
A sequence *does* meet the (immutable) Mapping interface
Ah? Let's try:
x=[1, 2, 3]
x.get(2)
AttributeError: 'list' object has no attribute 'get'
x.keys()
AttributeError: 'list' object has no attribute 'keys'
list doesn't
STINNER Victor victor.stin...@gmail.com added the comment:
The PyMapping_Check(dict) !PyMapping_Check(dict)
Oh, I mean PyMapping_Check(dict) !PySequence_Check(dict)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I'm -1 on exposing this API.
Victor's sandboxing project doesn't warrant cluttering the public toolset.
As a consultant who gets to see many large codebases in different companies and
I see zero need for this type to be exposed.
R. David Murray rdmur...@bitdance.com added the comment:
I believe it was actually Guido who suggested exposing dict_proxy, in response
to Victor (but independent of Victor's needs, if I understood the message
correctly).
It has always seemed odd to me (always referring my time working with
STINNER Victor victor.stin...@gmail.com added the comment:
Victor's use case is unique in that he needs the type
to be implemented in C.
mxProxy, zope.proxy and zope.security implement object proxies in C (for
security purpose). These proxies are not specific to dict, but are generic.
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
It's clutter and we should show some restraint before adding new types.
Enthought's Python Distribution isn't shy about adding tools when they have a
demonstrated need. Likewise, Django adds any reusable tools they need.
STINNER Victor victor.stin...@gmail.com added the comment:
It's clutter and we should show some restraint before adding new types.
dictproxy() doesn't need to be a public builtin type. We can just implement its
constructor without documenting the type. Or it may be exposed in a module like
Guido van Rossum gu...@python.org added the comment:
Given that dictproxy is needed to implement the proper interface for classes I
don't think it is an implementation detail, and so I think it ought to be
constructable. We have more esoteric types constructable (e.g. function).
I also happen
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
[haypo]
dictproxy() doesn't need to be a public builtin type.
+1
We can just implement its constructor without documenting the type.
+1
Or it may be exposed in a module like collections.
Please don't use collections as a
STINNER Victor victor.stin...@gmail.com added the comment:
Patch version 2:
- add tests and documentation
- dictproxy code moved to dictproxyobject.c
- dict_proxy replaced with dictproxy in repr(dictproxy)
- key in dictproxy now handles correctly dict subclasses
- dictproxy constructor
STINNER Victor victor.stin...@gmail.com added the comment:
The dictproxy is useful to implement a Python sandbox: see the related issue
#14385.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
Jim Jewett jimjjew...@gmail.com added the comment:
The problem is to reject sequence in dictproxy constructor.
Why? Just because you can't delegate in quite the same way? A sequence *does*
meet the (immutable) Mapping interface; it just won't happen to have any
non-integer keys.
Or are
New submission from STINNER Victor victor.stin...@gmail.com:
Attached patch makes the dictproxy type public. Example:
$ ./python
Python 3.3.0a1+ (default:059489cec7b9+, Mar 22 2012, 02:45:36)
d=dictproxy({1:2})
d
dict_proxy({1: 2})
d[1]
2
d[1]=3
TypeError: 'dictproxy' object does not
STINNER Victor victor.stin...@gmail.com added the comment:
dictproxy.patch: proxy_new() should check that dict is a dict (PyDict_Check).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
___
Python-bugs-list
37 matches
Mail list logo
