Re: Another obscure error, this one regarding PDFPageLabel

Glenn Linderman <[email protected]>
Newsgroups gmane.comp.python.reportlab.user
Message-ID <[email protected]>
On 5/19/2015 3:58 AM, Robin Becker wrote:
> ...........
>>
>> Tim,
>>
>> What you call arrogance is a result of reading the code, adding debug
>> statements, learning how it worked, and analyzing, yes, only my, 
>> problem.
>> However, as you can see from the stack trace you left in the quote, 
>> the message
>> I suggested subsumes the original message, thus permitting the 
>> original message
>> to be considered in the unlikely event that there are no duplicate 
>> page numbers
>> in the page label list. But if there are no duplicate page numbers, 
>> there would
>> be no attempt to compare PDFPageLabel objects, which are the second 
>> item in the
>> tuple being sorted, page number being first.
>>
>> If you can come up with _any_ other scenario that could produce this 
>> stack
>> trace, I'd be extremely interested.  If not, I'll consider it a 
>> little arrogant
>> of you make accusations of arrogance.
>>
>> Glenn
>>
> ..........
>
> Glenn, not sure exactly what Tim is objecting to, but we have a 
> mechanism to annotate the original exception.
>
> I suppose this is a python3x issue since it wouldn't happen in python 
> 2.x; I guess the correct solution is to ignore the error to preserve 
> the previous behaviour.
>
> It obviously makes no sense to have different page numbering schemes 
> for the same page, but so far as I can tell Adobe don't care. The 
> question then is should we make this an error?

I suppose it mostly depends on what the spec says, and it is nice not to 
have a non-deteriministic mechanism of knowing what label will appear on 
what page.  I was rather happy there was a diagnostic, so I could fix my 
problem, but of course the message was misleading.

I was using Python 3.4, and I know Python 2 can compare any types (even 
if it doesn't make sense to do so).

>
> It's fairly trivial to add
>
>     def __lt__(self,oth):
>         return False
>
> to the PDFPageLabel class which makes all pagelabels with the same 
> pagenumber equal; that way the order in which they appear is fixed by 
> the order of addition (python sort is stable).

Just fixing the message would be my preference, unless there is some 
rule that says multiple labels for one page must be permitted. I'd 
rather have spec adherence than my preferences :)  Usually :)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.