On Sun, Jul 13, 2014 at 02:04:17PM +, Jason R. Coombs wrote:
> PEP-416 mentions a MappingProxyType, but that’s no help.
Well, it kindof is. By combining MappingProxyType and UserDict the
desired effect can be achieved concisely:
import collections
import types
class frozendict(c
On Sun, Jul 13, 2014 at 06:43:28PM +, dw+python-...@hmmz.org wrote:
> if d:
> d = d.copy()
To cope with iterables, "d = d.copy()" should have read "d = dict(d)".
David
___
Python-Dev mailing list
Python-Dev@python.org
h
On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote:
> It would be nice to be able to return a frozendict instead of having the
> overhead of building a new dict on each call.
There already is an in-between available both to Python and C:
PyDictProxy_New() / types.MappingProxyType. It
On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote:
> So making code 3.x compatible by ditching cStringIO can cause a serious
> performance/memory regressions. One can change the code to build the data
> using BytesIO (without creating bytes objects in the first place), but that is
>
It's worth note that a natural extension of this is to do something very
similar on the write side: instead of generating a temporary private
heap allocation, generate (and freely resize) a private PyBytes object
until it is exposed to the user, at which point, _getvalue() returns it,
and converts
Hi Serhiy,
At least conceptually, 15381 seems the better approach, but getting a
correct implementation may take more iterations than the (IMHO) simpler
change in 22003. For my tastes, the current 15381 implementation seems a
little too magical in relying on Py_REFCNT() as the sole indication that
On Mon, May 12, 2014 at 04:22:52PM -0700, Gregory Szorc wrote:
> Why can't Python start as quickly as Perl or Ruby?
On my heavily abused Core 2 Macbook with 9 .pth files, 2.7 drops from
81ms startup to 20ms by specifying -S, which disables site.py.
Oblitering the .pth files immediately knocks 10
On Wed, Jun 04, 2014 at 03:17:00PM +1000, Nick Coghlan wrote:
> There's a general expectation that indexing will be O(1) because all
> the builtin containers that support that syntax use it for O(1) lookup
> operations.
Depending on your definition of built in, there is at least one standard
libr
On Fri, Jun 06, 2014 at 03:41:22PM +, Steve Dower wrote:
> [snip]
Speaking as a third party who aims to provide binary distributions for
recent Python releases on Windows, every new compiler introduces a
licensing and configuration headache. So I guess the questions are:
* Does the ABI stabi
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
> None of the options are particularly good, but yes, I think that's an
> option we have to consider. We're supporting 2.7.x for 6 more years on
> a compiler that is already 6 years old.
Surely that is infinitely less desirable than si
On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:
> > Is it really any difference in maintenance if you just stop applying
> > updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
> > new compiler then there should be no functional difference between
> > doing that and
On Sun, Jun 08, 2014 at 07:37:46PM +, dw+python-...@hmmz.org wrote:
> cls = tuple(name, (_NamedTuple,), {
Ugh, this should of course have been type().
David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
> > The current implementation is also *really* easy to understand,
> > while writing out the dynamic type creation explicitly would likely
> > require much deeper knowledge of the type machinery to follow.
> As proof that it's harder
On Sun, Jun 08, 2014 at 05:27:41PM -0400, Eric V. Smith wrote:
> How would you write _Namedtuple.__new__?
Knew something must be missing :) Obviously it's possible, but not
nearly as efficiently as reusing the argument parsing machinery as in
the original implementation.
I guess especially the
14 matches
Mail list logo
