Hello Raymond
Am 10.12.2012 02:44, schrieb Raymond Hettinger:
> Another benefit is that resizing is faster and
> touches fewer pieces of memory. Currently, every
> hash/key/value entry is moved or copied during a
> resize. In the new layout, only the indices are
> updated. For the most part, t
On Sun, Dec 9, 2012 at 5:44 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> The current memory layout for dictionaries is
> unnecessarily inefficient. It has a sparse table of
> 24-byte entries containing the hash value, key pointer,
> and value pointer.
>
> Instead, the 24-byte ent
On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote:
> If the packages have files in conflict, they won't be both installed.
> If they don't have files in conflict, there's nothing important to be
> informed of. If one is installing pexpect-u, then one does not need
> to discover that it is a s
On Dec 9, 2012, at 10:03 PM, MRAB wrote:
> What happens when a key is deleted? Will that leave an empty slot in
> the entry array?
Yes. See the __delitem__() method in the pure python implemention
at http://code.activestate.com/recipes/578375
> If so, will the array be compacted if the propor
On 2012-12-10 01:44, Raymond Hettinger wrote:
The current memory layout for dictionaries is
unnecessarily inefficient. It has a sparse table of
24-byte entries containing the hash value, key pointer,
and value pointer.
Instead, the 24-byte entries should be stored in a
dense table referenced by
On Sun, Dec 9, 2012 at 8:48 PM, Stephen J. Turnbull wrote:
> PJ Eby writes:
> > This is a good example of what I meant about clear thinking on
> > concrete use cases, vs. simply copying fields from distro tools. In
> > the distro world, these kinds of fields reflect the *results* of
> > resea
PJ Eby writes:
> That being said, I don't object to having the ability for either of
> them to do so: the utility of the field is *much* enhanced once its
> connection to installation tools is gone, since a wider variety of
> issues can be described without inconveniencing users.
+1 to "descr
The current memory layout for dictionaries is
unnecessarily inefficient. It has a sparse table of
24-byte entries containing the hash value, key pointer,
and value pointer.
Instead, the 24-byte entries should be stored in a
dense table referenced by a sparse table of indices.
For example, the di
On Sun, Dec 9, 2012 at 3:30 PM, anatoly techtonik wrote:
> Just to let you know that annotate in hgweb is broken for Python sources.
>
> http://hg.python.org/cpython/annotate/692be1f9fa1d/Lib/distutils/tests/test_register.py
Maybe I'm missing something, but what's broken about it? Also, in my
ex
Just to let you know that annotate in hgweb is broken for Python sources.
http://hg.python.org/cpython/annotate/692be1f9fa1d/Lib/distutils/tests/test_register.py
--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
On 2012-12-09 22:22, Mark Shannon wrote:
Hi all,
The current CPython bytecode interpreter is rather more complex than it
needs to be. A number of bytecodes could be eliminated and a few more
simplified by moving the work involved in handling compound statements
(loops, try-blocks, etc) from the
Interesting idea, main challenge is to keep stepping through the code with
pdb sane, and being clear on what differences in behaviour will be visible
to the runtime execution hooks.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev maili
Sounds good to me. No PEP needed, just a tracker item, tests, review etc...
--Guido van Rossum (sent from Android phone)
On Dec 9, 2012 2:24 PM, "Mark Shannon" wrote:
> Hi all,
>
> The current CPython bytecode interpreter is rather more complex than it
> needs to be. A number of bytecodes could
Hi all,
The current CPython bytecode interpreter is rather more complex than it
needs to be. A number of bytecodes could be eliminated and a few more
simplified by moving the work involved in handling compound statements
(loops, try-blocks, etc) from the interpreter to the compiler.
This sim
On Sun, Dec 9, 2012 at 12:54 AM, Nick Coghlan wrote:
> On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby wrote:
>>
>> On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan wrote:
>> > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby wrote:
>> >>
>> >> So if package A includes a "Conflicts: B" declaration, I recommend the
>>
Am 04.12.2012 20:35, schrieb Antoine Pitrou:
> On Tue, 04 Dec 2012 11:04:09 -0800
> Larry Hastings wrote:
>>
>> Along these lines, I've been contemplating proposing that Clinic
>> specifically understand "path" arguments, distinctly from other string
>> arguments, as they are both common and ra
Am 08.12.2012 22:51, schrieb Barry Warsaw:
> Hark fellow Emacsers. All you unenlightened heathens can stop reading now.
>
> A few years ago, my colleague Jono Lange wrote probably the best little chunk
> of Emacs lisp ever. `M-x bzr-tools-grep` lets you easily search a Bazaar
> repository for a
17 matches
Mail list logo
