> I think you should provide stronger arguments in each case why the
> data needs to be truly immutable or read-only, rather than just using
> a convention or an "advisory" API (like __private can be circumvented
> but clearly indicates intent to the reader).
I only know one use case for "truly im
Mark Janssen writes:
> Since there's no way (even theoretical way) to completely secure anything
> (remember the DVD protection wars?), there's no way there should be any
> liability if reasonable diligence is performed to provide security where
> expected (which is probably calculable to some
On 2012-03-01, at 9:31 PM, Guido van Rossum wrote:
> That sounds *very* far-fetched. You're pretty much designing a new
> language variant. It's not an argument for burdening the original
Yeah, that's what we do ;)
> You should be able to prototype what you want using an advisory
> subclass (if y
On Thu, Mar 1, 2012 at 6:13 PM, Yury Selivanov wrote:
> On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
>> I think you should provide stronger arguments in each case why the
>> data needs to be truly immutable or read-only, rather than just using
>> a convention or an "advisory" API (like __pri
On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
> I think you should provide stronger arguments in each case why the
> data needs to be truly immutable or read-only, rather than just using
> a convention or an "advisory" API (like __private can be circumvented
> but clearly indicates intent to t
On Fri, Mar 2, 2012 at 11:50 AM, R. David Murray wrote:
> +1. Except in very limited circumstances (such as a security sandbox)
> I would *much* rather have the code I'm interacting with use advisory
> means rather than preventing me from being a consenting adult. (Having to
> name mangle by han
On Thu, 01 Mar 2012 16:50:06 -0800, Guido van Rossum wrote:
> On Thu, Mar 1, 2012 at 4:39 PM, Victor Stinner
> wrote:
> > frozendict could be used to implement "read-only" types: it is not possible
> > to add or remove an attribute or set an attribute value, but attribute value
> > can be a muta
On Thu, Mar 1, 2012 at 4:39 PM, Victor Stinner wrote:
> Le 01/03/2012 19:07, Guido van Rossum a écrit :
>
>> What other use cases are there?
>
>
> frozendict could be used to implement "read-only" types: it is not possible
> to add or remove an attribute or set an attribute value, but attribute va
Le 01/03/2012 19:07, Guido van Rossum a écrit :
What other use cases are there?
frozendict could be used to implement "read-only" types: it is not
possible to add or remove an attribute or set an attribute value, but
attribute value can be a mutable object. Example of an enum with my
type_fi
On Thu, Mar 1, 2012 at 10:00 AM, Guido van Rossum wrote:
>
> I do know that I don't feel comfortable having a sandbox in the Python
> standard library or even recommending a 3rd party sandboxing solution
> -- if someone uses the sandbox to protect a critical resource, and a
> hacker breaks out of
On Thu, Mar 1, 2012 at 12:35 PM, André Malo wrote:
> * Guido van Rossum wrote:
>
>> On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner
> wrote:
>> > frozendict would help pysandbox but also any security Python module,
>> > not security, but also (many) other use cases ;-)
>>
>> Well, let's focus on t
* Guido van Rossum wrote:
> On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner
wrote:
> > frozendict would help pysandbox but also any security Python module,
> > not security, but also (many) other use cases ;-)
>
> Well, let's focus on the other use cases, because to me the sandbox
> use case is t
* Serhiy Storchaka wrote:
> 01.03.12 16:47, André Malo написав(ла):
> > On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
> >> This is the first rational use of frozendict that I see. However, a
> >> deep copy is still necessary to create the frozendict. For this case,
> >> I believe, wou
>> I challenge anyone to try to break pysandbox!
>
> Can you explain precisely how a frozendict will help pysandbox? Then
> I'll be able to beat this challenge :-)
See this email:
http://mail.python.org/pipermail/python-dev/2012-February/117011.html
The issue #14162 has also two patches: one to m
On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner wrote:
> frozendict would help pysandbox but also any security Python module,
> not security, but also (many) other use cases ;-)
Well, let's focus on the other use cases, because to me the sandbox
use case is too controversial (never mind how confid
On 1 March 2012 17:44, Victor Stinner wrote:
> I challenge anyone to try to break pysandbox!
Can you explain precisely how a frozendict will help pysandbox? Then
I'll be able to beat this challenge :-)
Paul.
___
Python-Dev mailing list
Python-Dev@pyth
01.03.12 16:47, André Malo написав(ла):
> On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
>> This is the first rational use of frozendict that I see. However, a deep
>> copy is still necessary to create the frozendict. For this case, I
>> believe, would be better to "freeze" dict inplace
> In App Engine's case, an attacker who broke out of the sandbox would have
> access to the inside of Google's datacenter, which would obviously be
> bad -- that's why Google has developed its own sandboxing
> technologies.
This is not specific to Google: if an attacker breaks a sandbox,
he/she ha
On Thu, Mar 1, 2012 at 2:01 AM, Victor Stinner
wrote:
>>> The main idea of pysandbox is to reuse most of CPython but hide
>>> "dangerous" functions and run untrusted code in a separated namespace.
>>> The problem is to create the sandbox and ensure that it is not
>>> possible to escape from this s
On Thursday 01 March 2012 15:54:01 Victor Stinner wrote:
> > I'm not sure about your final types. I'm using __slots__ = () for such
> > things
>
> You can still replace an attribute value if a class defines __slots__:
> >>> class A:
>
> ... __slots__=('x',)
> ... x = 1
> ...
>
> >>> A.x=2
> >>
>> > Here are my real-world use cases. Not for security, but for safety and
>> > performance reasons (I've built by own RODict and ROList modeled after
>> > dictproxy):
>> >
>> > - Global, but immutable containers, e.g. as class members
>>
>> I attached type_final.patch to the issue #14162 to demon
> But I will try to suggest another approach. `frozendict` inherits from
> `dict`, but data is not stored in the parent, but in the internal
> dictionary. And even if dict.__setitem__ is used, it will have no visible
> effect.
>
> class frozendict(dict):
> def __init__(self, values={}):
>
On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
> 01.03.12 11:29, André Malo написав(ла):
> > - Caching. My data container objects (say, resultsets from a db or
> > something) usually inherit from list or dict (sometimes also set) and are
> > cached heavily. In order to ensure that they
01.03.12 11:29, André Malo написав(ла):
- Caching. My data container objects (say, resultsets from a db or something)
usually inherit from list or dict (sometimes also set) and are cached
heavily. In order to ensure that they are not modified (accidentially), I
have to choices: deepcopy
On 1 March 2012 12:37, Yury Selivanov wrote:
> Actually I find fronzendict concept quite useful. We also have an
> implementation in our framework, and we use it, for instance, in
> http request object, for parsed arguments and parsed forms, which
> values shouldn't be ever modified once parsed.
01.03.12 11:11, Victor Stinner написав(ла):
You can redefine dict.__setitem__.
Ah? It doesn't work here.
dict.__setitem__=lambda key, value: None
Traceback (most recent call last):
File "", line 1, in
TypeError: can't set attributes of built-in/extension type 'dict'
Hmm, yes, it's true.
On Thu, Mar 1, 2012 at 7:29 PM, André Malo wrote:
> - Caching. My data container objects (say, resultsets from a db or something)
> usually inherit from list or dict (sometimes also set) and are cached
> heavily. In order to ensure that they are not modified (accidentially), I
> have to choices
On Thursday 01 March 2012 14:07:10 Victor Stinner wrote:
> > Here are my real-world use cases. Not for security, but for safety and
> > performance reasons (I've built by own RODict and ROList modeled after
> > dictproxy):
> >
> > - Global, but immutable containers, e.g. as class members
>
> I atta
> Here are my real-world use cases. Not for security, but for safety and
> performance reasons (I've built by own RODict and ROList modeled after
> dictproxy):
>
> - Global, but immutable containers, e.g. as class members
I attached type_final.patch to the issue #14162 to demonstrate how
frozendic
> A builtin frozendict type "compatible" with the PyDict C API is very
> convinient for pysandbox because using this type for core features
> like builtins requires very few modification. For example, use
> frozendict for __builtins__ only requires to modify 3 lines in
> frameobject.c.
See the fro
Actually I find fronzendict concept quite useful. We also have an
implementation in our framework, and we use it, for instance, in
http request object, for parsed arguments and parsed forms, which
values shouldn't be ever modified once parsed.
Of course everybody can live without it, but given th
>> The main idea of pysandbox is to reuse most of CPython but hide
>> "dangerous" functions and run untrusted code in a separated namespace.
>> The problem is to create the sandbox and ensure that it is not
>> possible to escape from this sandbox. pysandbox is still a
>> proof-of-concept, even if i
On Wednesday 29 February 2012 20:17:05 Raymond Hettinger wrote:
> On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
> > A frozendict type is a common request from users and there are various
> > implementations.
>
> ISTM, this request is never from someone who has a use case.
> Instead, it almost
Il 01 marzo 2012 02:45, Raymond Hettinger
ha scritto:
>
> On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
>
> One of my colleagues implemented recently its own frozendict class
> (which the "frozendict" name ;-)
>
>
> I write new collection classes all the time.
> That doesn't mean they warrant
>> Problem: if you implement a frozendict type inheriting from dict in
>> Python, it is still possible to call dict methods (e.g.
>> dict.__setitem__()). To fix this issue, pysandbox removes all dict
>> methods modifying the dict: __setitem__, __delitem__, pop, etc. This
>> is a problem because unt
01.03.12 01:52, Victor Stinner написав(ла):
Problem: if you implement a frozendict type inheriting from dict in
Python, it is still possible to call dict methods (e.g.
dict.__setitem__()). To fix this issue, pysandbox removes all dict
methods modifying the dict: __setitem__, __delitem__, pop, etc
On 01.03.2012 02:45, Raymond Hettinger wrote:
>
> On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
>
>> One of my colleagues implemented recently its own frozendict class
>> (which the "frozendict" name ;-)
>
> I write new collection classes all the time.
> That doesn't mean they warrant inclu
On Wed, Feb 29, 2012 at 3:52 PM, Victor Stinner
wrote:
>> It would (apparently) help Victor to fix issues in his pysandbox
>> project. I don't know if a secure Python sandbox is an important
>> enough concept to warrant core changes to make it possible.
>
> Ok, let's talk about sandboxing and secu
On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
> One of my colleagues implemented recently its own frozendict class
> (which the "frozendict" name ;-)
I write new collection classes all the time.
That doesn't mean they warrant inclusion in the library or builtins.
There is a use case for Lis
Raymond Hettinger wrote:
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always comes from "completers", people
who see
Raymond Hettinger wrote:
On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote:
I don't know if hardening Python is a compelling argument to add a new
builtin type.
It isn't.
Builtins are for general purpose use.
It is not something most people should use;
however, if it is a builtin, people
>> A frozendict type is a common request from users and there are various
>> implementations.
>
> ISTM, this request is never from someone who has a use case.
One of my colleagues implemented recently its own frozendict class
(which the "frozendict" name ;-)). He tries to implement something
like
On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote:
> I don't know if hardening Python is a compelling argument to add a new
> builtin type.
It isn't.
Builtins are for general purpose use.
It is not something most people should use;
however, if it is a builtin, people will be drawn
to frozend
On Thu, 01 Mar 2012 10:13:01 +1100, Chris Angelico wrote:
> On Thu, Mar 1, 2012 at 8:08 AM, Paul Moore wrote:
> > It would (apparently) help Victor to fix issues in his pysandbox
> > project. I don't know if a secure Python sandbox is an important
> > enough concept to warrant core changes to mak
> It would (apparently) help Victor to fix issues in his pysandbox
> project. I don't know if a secure Python sandbox is an important
> enough concept to warrant core changes to make it possible.
Ok, let's talk about sandboxing and security.
The main idea of pysandbox is to reuse most of CPython
On Feb 29, 2012, at 1:08 PM, Paul Moore wrote:
> As it stands, I don't find the PEP compelling. The hardening use case
> might be significant but Victor needs to spell it out if it's to make
> a difference.
If his sandboxing project needs it, the type need not be public.
It can join dictproxy an
On Thu, Mar 1, 2012 at 8:08 AM, Paul Moore wrote:
> It would (apparently) help Victor to fix issues in his pysandbox
> project. I don't know if a secure Python sandbox is an important
> enough concept to warrant core changes to make it possible.
If a secure Python sandbox had been available last
On Thu, Mar 1, 2012 at 7:08 AM, Paul Moore wrote:
> As it stands, I don't find the PEP compelling. The hardening use case
> might be significant but Victor needs to spell it out if it's to make
> a difference.
+1
Avoiding-usenet-nod-syndrome'ly,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 29 February 2012 19:17, Raymond Hettinger
wrote:
> From this experience, I conclude that adding a frozendict type
> would be a total waste (except that it would inspire more people
> to request frozen variante of other containers).
It would (apparently) help Victor to fix issues in his pysandb
>
>
> The frozenset type covers a niche case that is nice-to-have but
> *rarely* used. Many experienced Python users simply forget
> that we have a frozenset type. We don't get bug reports or
> feature requests about the type. When I do Python consulting
> work, I never see it in a client's code
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
> A frozendict type is a common request from users and there are various
> implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always comes from "completers", people
who see that we have a frozenset
Steven D'Aprano wrote:
> M.-A. Lemburg wrote:
>> Victor Stinner wrote:
See also the PEP 351.
>>> I read the PEP and the email explaining why it was rejected.
>>>
>>> Just to be clear: the PEP 351 tries to freeze an object, try to
>>> convert a mutable or immutable object to an immutable object
Victor Stinner wrote:
* frozendict values must be immutable, as dict keys
Why? That may be useful, but an immutable dict whose values
might mutate is also useful; by forcing that choice, it starts
to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a fr
>> * frozendict values must be immutable, as dict keys
>
> Why? That may be useful, but an immutable dict whose values
> might mutate is also useful; by forcing that choice, it starts
> to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a frozendict
instan
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't
Victor Stinner wrote:
>> See also the PEP 351.
>
> I read the PEP and the email explaining why it was rejected.
>
> Just to be clear: the PEP 351 tries to freeze an object, try to
> convert a mutable or immutable object to an immutable object. Whereas
> my frozendict proposition doesn't convert a
On Tue, 28 Feb 2012 13:14:15 +0100
Victor Stinner wrote:
>
> > See also the PEP 351.
>
> I read the PEP and the email explaining why it was rejected.
I think you should write a separate PEP and explain the use cases
clearly.
cheers
Antoine.
___
Py
Hi,
I don't know if an implementation of the frozendict actually exists,
but if anyone is planning on writing one then can I suggest that they
take a look at my new dict implementation:
http://bugs.python.org/issue13903
https://bitbucket.org/markshannon/cpython_new_dict/
Making dicts immutable (
On Tue, 28 Feb 2012 12:07:32 +
Mark Shannon wrote:
> Antoine Pitrou wrote:
> > On Tue, 28 Feb 2012 12:45:54 +0100
> > Victor Stinner wrote:
> >>> I think you need to elaborate on your use cases further, ...
> >> A frozendict can be used as a member of a set or as a key in a dictionary.
> >>
>
Updated patch and more justifications.
New patch:
- dict doesn't inherit from frozendict anymore
- frozendict is a subclass of collections.abc.Mutable
- more tests
> * frozendict.__hash__ computes hash(frozenset(self.items())) and
> caches the result is its private hash attribute
hash(frozen
>> A frozendict can be used as a member of a set or as a key in a dictionary.
>>
>> For example, frozendict is indirectly needed when you want to use an
>> object as a key of a dict, whereas one attribute of this object is a
>> dict.
>
> It isn't. You just have to define __hash__ correctly.
Define
On 28 February 2012 12:07, Mark Shannon wrote:
>>> frozendict helps also in threading and multiprocessing.
>>
>> How so?
>
> Inter process/task communication requires copying. Inter/intra thread
> communication uses reference semantics. To ensure these are the same,
> the objects used in communica
Antoine Pitrou wrote:
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner wrote:
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner wrote:
> > I think you need to elaborate on your use cases further, ...
>
> A frozendict can be used as a member of a set or as a key in a dictionary.
>
> For example, frozendict is indirectly needed when you want to use an
> object as a key of a
> I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as a key of a dict, whereas one attribute of this object is a
dict. Use a frozendic
> A frozendict type is a common request from users and there are various
>> implementations. There are two main Python implementations:
>
> Perhaps this should also detail why namedtuple is not a viable alternative.
It doesn't have the same API. Example: frozendict[key] vs
namedtuple.attr (namedtu
Victor Stinner wrote:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and violate even more invariants.
For most purposes, this falls under "consenting adult
On Mon, Feb 27, 2012 at 19:53, Victor Stinner
wrote:
> A frozendict type is a common request from users and there are various
> implementations. There are two main Python implementations:
Perhaps this should also detail why namedtuple is not a viable alternative.
Cheers,
Dirkjan
___
Nick Coghlan gmail.com> writes:
> I'm pretty sure the PyPy jit can already pick up and optimise cases
> where a dict goes "read-only" (i.e. stops being modified).
No, it doesn't. We handle cases like a type's dict, or a module's dict,
by having them use a different internal implementation (while
On Tue, Feb 28, 2012 at 9:34 AM, Victor Stinner
wrote:
>>> The blacklist implementation has a major issue: it is still possible
>>> to call write methods of the dict class (e.g. dict.set(my_frozendict,
>>> key, value)).
>>
>> It is also possible to use ctypes and violate even more invariants.
>> F
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 PM, Victor Stinner wrote:
> tuple and frozenset can only contain immutables values.
Tuples can contain mutables::
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "cred
>> The blacklist implementation has a major issue: it is still possible
>> to call write methods of the dict class (e.g. dict.set(my_frozendict,
>> key, value)).
>
> It is also possible to use ctypes and violate even more invariants.
> For most purposes, this falls under "consenting adults".
My pr
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html
Victor Stinner proposed:
> The blacklist implementation has a major issue: it is still possible
> to call write methods of the dict class (e.g. dict.set(my_frozendict,
> key, value)).
It is also possible to use ctypes and
> This may be an issue at the C level (I'm not sure), but since this would
> be a Python 3-only collection, "user" code (in Python) should/would
> generally be using abstract base classes, so type-checking would not
> be an issue (as in Python code performing `isinstance(a, dict)` checks
> naturall
On 2012-02-27, at 19:53 , Victor Stinner wrote:
> Rationale
> =
>
> A frozendict type is a common request from users and there are various
> implementations. There are two main Python implementations:
>
> * "blacklist": frozendict inheriting from dict and overriding methods
> to raise a
Rationale
=
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
* "blacklist": frozendict inheriting from dict and overriding methods
to raise an exception when trying to modify the frozendict
* "whitelist":
76 matches
Mail list logo
