Should'nt the key'ing behaviour be controlled by the type of the key
instead of the type of the container?
2013/9/10 MRAB
> On 10/09/2013 20:08, Paul Moore wrote:
>
>> On 10 September 2013 19:31, Antoine Pitrou wrote:
>>
>>> I think it would be a flaw to have this detail implementation-defined
Debugging a refcount bug? Good. Out of the door, line on the left, one
cross each.
2013/3/2 Stefan Bucur
> On Sat, Mar 2, 2013 at 4:31 PM, Antoine Pitrou
> wrote:
> > On Fri, 1 Mar 2013 16:24:42 +0100
> > Stefan Bucur wrote:
> >>
> >> However, after applying this modification, when running "m
Notice that {'x':1} and dict(x=1) are different beasts: The first one
compiles directly to BUILD_MAP. The second one loads a reference to 'dict'
from globals() and calls the constructor. The two are not the same.
2012/11/15 Steven D'Aprano
> On 15/11/12 05:54, Mark Adam wrote:
>
> Merging of
At least on some versions of Windows (e.g. XP) the
QueryPerformanceCounter()-API is more or less only a stub around a
call to RDTSC which in turn varies in frequency on (at least) Intel
Pentium 4, Pentium M and Xeon processors (bound to the current clock
frequencies).
__
rings with less fields expose too much
overhead of entering the C-code and staying there a little longer to
unpack all fields is actually faster.
Having fifteen or more fields in a format-string seems unlikely and
I'll therefor abandon the idea of providing this mechanism.
2011/6/14 Lukas Lu
> So I really can't see what harm it could do, except for
> maybe a tiny performance reduction in the case where you
> extract all the fields, or refer to extracted fields
> repeatedly.
Referring to the view-object multiple times should not be a problem
since the object can create and hold referen
> This is what people normally do (unpack just the values they need,
> when they need them).
Due to the fact that there hundreds of format-strings which
dynamically compiled from a more verbose language at runtime, we will
have significant complexity in the code in order to generate format
strings
Hi.
We extensively use the struct module to crunch large amounts of binary
data. There are basically two operations for us that only seem to the
naked eye as one: Filtering (see if certain fields have certain
values, throw everything away if not) and inspection (care about all
the fields' values).
Distutils2 is not really an option right now as it is not found on
major Linux distributions, FreeBSD or MacOS X
2011/4/12 Nick Coghlan :
> On Tue, Apr 12, 2011 at 7:41 AM, Lukas Lueg wrote:
>> Any other ideas on how to solve this in a better way?
>
> Have you tried with distutil
Hi,
I'm the maintainer of Pyrit (http://pyrit.googlecode.com) and recently
checked in some code that uses the AES-NI intrinsics found in GCC
4.4+. I'm looking for a way how to build the python-extension using
distutils in a sane way and could not get an answer from the
distutils-people about that.
Hi,
i've a storage engine that stores a lot of files (e.g. > 10.000) in
one path. Running the code under cProfile, I found that with a total
CPU-time of 1,118 seconds, 121 seconds are spent in 27.013 calls to
open(). The number of calls is not the problem; however I find it
*very* discomforting th
I very much like the fact that python has *very* little black magic
revealed to the user. Strong -1 on optimizing picked builtins in a
picked way.
2011/1/4 Steven D'Aprano :
> Guido van Rossum wrote:
>>
>> On Tue, Jan 4, 2011 at 2:49 AM, Michael Foord
>> wrote:
>>>
>>> I think someone else pointe
Doesnt this all boil down to being able to monitor PyDict for changes
to it's key-space?
The keys are immutable anyway so the instances of PyDict could manage
a opaque value (in fact, a counter) that changes every time a new
value is written to any key. Once we get a reference out of the dict,
we
Consider the following code:
def foobar(x):
for i in range(5):
x[i] = i
The bytecode in python 2.7 is the following:
2 0 SETUP_LOOP 30 (to 33)
3 LOAD_GLOBAL 0 (range)
6 LOAD_CONST 1 (5)
9 CA
14 matches
Mail list logo
