Le 29/02/2012 00:25, Nick Coghlan a écrit :
> Also, I think there may be some confusion about Armin's plan to handle
> 3.2 - he aims to write an *import hook* that accepts the u/U prefixes
> during tokenisation, not a source-to-source transform like 2to3.
>
this needs to be emphasized. Read fro
>
> FWIW, I agree that much of the rhetoric in the current version of PEP
> 414 is excessive.
>
> Armin has given me permission to create an updated version of PEP 414
> and toning down the hyperbole (or removing it entirely in cases where
> it's irrelevant to the final decision) is one of the t
Armin,
I see you've (or somebody) changed:
"""As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3."""
to:
"""As it stands, when chosing between 2.7
Armin,
I see you've (or somebody) changed:
"""As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3."""
to:
"""As it stands, when chosing between 2.7
On Feb 29, 2012, at 07:30 AM, Yury Selivanov wrote:
>"""As it stands, Python 3 is currently a bad choice for long-term
>investments, since the ecosystem is not yet properly developed, and
>libraries are still fighting with their API decisions for Python 3."""
>
>to:
>
>"""As it stands, when chos
As requested, I create a PEP and a related issue:
http://www.python.org/dev/peps/pep-0416/
http://bugs.python.org/issue14162
The PEP 416 is different from my previous propositions: frozendict
values can be mutable and dict doesn't inherit from frozendict
anymore. But it is still possible to use t
On Wed, 2012-02-29 at 19:21 +0100, Victor Stinner wrote:
> As requested, I create a PEP and a related issue:
>
> http://www.python.org/dev/peps/pep-0416/
[...snip...]
>
> Rationale
> =
>
> A frozendict mapping cannot be changed, but its values can be mutable
> (not hashable). A frozend
> > Rationale
> > =
> >
> > A frozendict mapping cannot be changed, but its values can be mutable
> > (not hashable). A frozendict is hashable and so immutable if all
> > values are hashable (immutable).
> The wording of the above seems very unclear to me.
>
> Do you mean "A frozendict has
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
>
>
> 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
Antoine Pitrou wrote:
> Stefan Krah wrote:
> > In Python 3.3 most issues with the memoryview object have been fixed
> > in a recent commit (3f9b3b6f7ff0).
>
> Oh and congrats for doing this, of course.
Thanks!
Stefan Krah
___
Python-Dev mailing li
Greg Ewing wrote:
>> Options 2) and 3) would ideally entail one backwards incompatible
>> bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
>> rejects integers but accepts byte objects, but according to the
>> struct syntax mandated by the PEP it should be the other way round.
>
>
I have updated PEP 411, following the input from this discussion. The
updated PEP is at: http://hg.python.org/peps/file/default/pep-0411.txt
Changes:
- Specified that a package may remain provisional for longer than a single
minor release
- Shortened the suggested documentation notice, linking to
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
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 Feb 28, 2012 7:14 PM, wrote:
>>
>> Why is readding u'' a feature and not a bug?
>
>
> There is a really simple litmus test for whether something is a bug:
> does it deviate from the specification?
>
> In this case, the specification is the grammar, and the implementation
> certainly doesn't dev
On Wed, 29 Feb 2012 17:06:21 -0500, Calvin Spealman
wrote:
> On Feb 28, 2012 7:14 PM, wrote:
> >>
> >> Why is readding u'' a feature and not a bug?
> >
> >
> > There is a really simple litmus test for whether something is a bug:
> > does it deviate from the specification?
> >
> > In this case, t
>> There is a really simple litmus test for whether something is a bug:
>> does it deviate from the specification?
>>
>> In this case, the specification is the grammar, and the implementation
>> certainly doesn't deviate from it. So it can't be a bug.
>
> I don't think anyone can assert that the s
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 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
> 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 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
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
>> 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
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
On 2/29/2012 2:34 PM, Stefan Krah wrote:
Greg Ewing wrote:
Options 2) and 3) would ideally entail one backwards incompatible
bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
rejects integers but accepts byte objects, but according to the
struct syntax mandated by the PEP it sho
Armin filed and argued for the addition in a PEP, a Python *Enhancement*
Proposal. He did not file a bugfix behavior issue on the tracker. Let us
leave it as that.
x.y is a specified language. We continuously improve the x.y docs that
describe and explain the specification. We also improve the
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
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
[erroneouly hit send button before instead of edit menu above it]
On 2/29/2012 2:34 PM, Stefan Krah wrote:
Greg Ewing wrote:
Options 2) and 3) would ideally entail one backwards
incompatible bugfix: In 2.7 and 3.2 assignment to a memoryview
with format 'B' rejects integers but accepts byte obj
On Thu, Mar 1, 2012 at 11:48 AM, Terry Reedy wrote:
> * As for porting, my impression is that the PEP directly affects only C code
> and Python code using ctypes and only some fraction of those. If the
> bugfix-only patch is significantly different from complete patch, porting to
> 3.2 would be si
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
In http://mail.python.org/pipermail/python-dev/2012-February/117113.html
Victor Stinner posted:
> An immutable mapping can be implemented using frozendict::
> class immutabledict(frozendict):
> def __new__(cls, *args, **kw):
> # ensure that all values are immutable
>
Just checking in:
On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
> At the very least:
> - the IP Interface API needs to move to a point where it more clearly
> *is* an IP Address and *has* an associated IP Network (rather than
> being the other way around)
This is done [1]. There's cleanup
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 Thu, Mar 1, 2012 at 3:13 PM, Peter Moody wrote:
> Just checking in:
>
> On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
>> At the very least:
>> - the IP Interface API needs to move to a point where it more clearly
>> *is* an IP Address and *has* an associated IP Network (rather than
>> b
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
37 matches
Mail list logo
