Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103564 > unrolled thread

Re: Bug in Python?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bug in Python? Terry Reedy <tjreedy@udel.edu> - 2016-02-27 03:55 -0500
    Re: Bug in Python? Steven D'Aprano <steve@pearwood.info> - 2016-02-27 20:44 +1100
      Re: Bug in Python? Terry Reedy <tjreedy@udel.edu> - 2016-02-27 06:48 -0500
      Re: Bug in Python? "Sven R. Kunze" <srkunze@mail.de> - 2016-02-28 11:24 +0100

#103564 — Re: Bug in Python?

On 2/26/2016 6:07 PM, eryk sun wrote:
>   On Fri, Feb 26, 2016 at 4:08 PM, Sven R. Kunze <srkunze@mail.de> wrote:
>> Python sometimes seems not to hop back and forth between C and Python code.
>> Can somebody explain this?
>
> Normally a C extension would call PySequence_SetItem, which would call
> the type's sq_ass_item, which for MyList is slot_sq_ass_item. The
> latter function bridges the CPython and Python sides by binding and
> calling the overridden __setitem__ method.  However, the _heapq
> extension module uses `PyList_SET_ITEM(heap, 0, lastelt)`. This macro
> expands to `((PyListObject *)(heap))->ob_item[0] = lastelt`. This
> directly modifies the internal ob_item array of the list, so the
> overridden __setitem__ method is never called. I presume it was
> implemented like this with performance in mind, but I don't know
> whether or not that justifies the loss of generality.

In other words, when that doc says *list*, it means a *list*.

"To create a heap, use a list initialized to [], or you can transform a 
populated list into a heap via function heapify()."

Note: when the doc says 'dict' rather than 'dictionary' or 'mapping', it 
is pretty obvious it means builtin dict.  It may sometimes say 'dict or 
dict subclass'.  Ditto for 'str' versus 'string' or 'text'.  However, 
'list' (Python builtin) and generic 'list are easy to confuse.  In this 
case, 'initialized to []' is a hint.  However, the doc could be made 
clearer. How about

"A heap must be an instance of *list* (and not a subclass thereof).  To 
create a heap, start with [] or transform an existing list into a heap 
via function heapify()."

*list* means to display it blue, linked to the list class.


-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#103571

On Sat, 27 Feb 2016 07:55 pm, Terry Reedy wrote:

> In other words, when that doc says *list*, it means a *list*.
> 
> "To create a heap, use a list initialized to [], or you can transform a
> populated list into a heap via function heapify()."
[...]
> "A heap must be an instance of *list* (and not a subclass thereof).  To
> create a heap, start with [] or transform an existing list into a heap
> via function heapify()."

I think that's a sad decision. heapq ought to be able to handle any list
subclass, not just actual lists. Preferably it ought to handle duck-typed
lists too, anything with a list-like interface. It is okay if the optimized
C version only works with actual lists, and falls back to a slower Python
version for anything else.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103579

On 2/27/2016 4:44 AM, Steven D'Aprano wrote:
> On Sat, 27 Feb 2016 07:55 pm, Terry Reedy wrote:
>
>> In other words, when that doc says *list*, it means a *list*.
>>
>> "To create a heap, use a list initialized to [], or you can transform a
>> populated list into a heap via function heapify()."
> [...]
>> "A heap must be an instance of *list* (and not a subclass thereof).  To
>> create a heap, start with [] or transform an existing list into a heap
>> via function heapify()."
>
> I think that's a sad decision. heapq ought to be able to handle any list
> subclass, not just actual lists. Preferably it ought to handle duck-typed
> lists too, anything with a list-like interface. It is okay if the optimized
> C version only works with actual lists, and falls back to a slower Python
> version for anything else.

Propose that on the tracker, after checking previous issues.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#103621

On 27.02.2016 12:48, Terry Reedy wrote:
> On 2/27/2016 4:44 AM, Steven D'Aprano wrote:
>> On Sat, 27 Feb 2016 07:55 pm, Terry Reedy wrote:
>>
>>> In other words, when that doc says *list*, it means a *list*.
>>>
>>> "To create a heap, use a list initialized to [], or you can transform a
>>> populated list into a heap via function heapify()."
>> [...]
>>> "A heap must be an instance of *list* (and not a subclass thereof).  To
>>> create a heap, start with [] or transform an existing list into a heap
>>> via function heapify()."
>>
>> I think that's a sad decision. heapq ought to be able to handle any list
>> subclass, not just actual lists. Preferably it ought to handle 
>> duck-typed
>> lists too, anything with a list-like interface. It is okay if the 
>> optimized
>> C version only works with actual lists, and falls back to a slower 
>> Python
>> version for anything else.
>

I agree that it would increase comprehensibility. I took me a fair 
amount of time to see why things are not working as intended (and as you 
see I wasn't even close to the real explanation).

However, heapq might work well the way it is as long as you have the 
chance to get your hands on one of the other heap implementations out there.

> Propose that on the tracker, after checking previous issues.

:)

Best,
Sven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web