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.
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
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
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
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
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 to
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
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
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
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 doing a
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
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
13 matches
Mail list logo
