Abend with cls.__repr__ = cls.__str__ on Windows.
J Peyret
stopped working", rather than a regular exception stack error. I've
fixed it, after I figured out the cause, which took a while, but maybe
someone will benefit from this.
Python 2.6.5 on Windows 7.
class Foo(object):
pass
#def __str__(self): #if you have this defined, no abend
# return "a Foo"
Foo.__repr__ = Foo.__str__ # this will cause an abend.
#Foo.__str__ = Foo.__repr__ #do this instead, no abend
foo = Foo()
print str(foo)
I suspect that object.__str__ is really object.__repr__ by default, as
they both print out the same string, so that this doesn't make any
sense.
What was I trying to achieve? Leveraging __str__ to debug instances
in lists and containers. In that case, __repr__ is called and I
usually do:
class Foo(object):
def __str__(self):
return "a foo"
def __repr__(self): #was trying to avoid this.
return str(self)
Terry Reedy
> This gives a particularly nasty abend in Windows - "Python.exe has
> stopped working", rather than a regular exception stack error. I've
> fixed it, after I figured out the cause, which took a while, but maybe
> someone will benefit from this.
>
> Python 2.6.5 on Windows 7.
>
> class Foo(object):
> pass
>
2.7.1 and 3.2.0 on winxp, no problem, interactive intepreter or IDLE
shell. Upgrade?
--
Terry Jan Reedy
Steven D'Aprano
> This gives a particularly nasty abend in Windows - "Python.exe has
> stopped working", rather than a regular exception stack error. I've
> fixed it, after I figured out the cause, which took a while, but maybe
> someone will benefit from this.
>
> Python 2.6.5 on Windows 7.
I get the same behaviour on Python 2.6, 2.7 and 3.1 under Linux: the
Python process hangs until killed manually.
--
Steven
Terry Reedy
> On 3/17/2011 8:24 PM, J Peyret wrote:
>> stopped working", rather than a regular exception stack error. I've
>> fixed it, after I figured out the cause, which took a while, but maybe
>> someone will benefit from this.
>>
>> Python 2.6.5 on Windows 7.
>>
>> class Foo(object):
>> pass
>>
>
> shell. Upgrade?
To be clear, the above, with added indent, but with extra fluff (fixes)
removed, is exactly what I ran. If you got error with anything else,
please say so. Described behavior for legal code is a bug. However,
unless a security issue, it would not be fixed for 2.6.
--
Terry Jan Reedy
J Peyret
Nope, that is it. No need to upgrade, nor is there any urgency. I
was just surprised to see it fail so brutally, is all. I've only
encountered 2 or 3 core Python bugs at that level in about 13 yrs of
coding in it, so thought I'd post it, especially as it is so easy to
replicate.
Txs for your help
I actually have another really weird behavior in this program, but
haven't figured out yet what causes it so it is hard to tell if it's
an error on my part or another system bug. I'll post it if I can
isolate a system error.
FWIW, what I am doing is using Configparser to assemble a bunch of
classes together to provide a reporting/diffing engine for database
comparisons. The object compositions are all defined in an .ini file.
I've found Python + ini files are a great match for creating truly
flexible programs. SQL queries, template strings and regular
expression patterns can be stored in the ini file and are easy to
modify without touching the core python code. Pass a different ini
file => different behavior. Xml is overkill for this and plays really
badly with relational <,> operators.
This is the next step for me, defining mostly separate classes and
assembling and initializing them based on ini file configuration info.
Duncan Booth
On Windows, I can replicate this with Python 2.7, Python 3.1.2, and
Python 3.2. Here's the exact script (I had to change the print to be
compatible with Python 3.2):
-------------------- bug.py --------------
class Foo(object):
pass
#def __str__(self): #if you have this defined, no abend
# return "a Foo"
Foo.__repr__ = Foo.__str__ # this will cause an abend.
#Foo.__str__ = Foo.__repr__ #do this instead, no abend
foo = Foo()
print(str(foo))
------------------------------------------
for Python 3.2 the command:
C:\Temp>c:\python32\python bug.py
generates a popup:
python.exe - Application Error
The exception unknown software exception (0xc0000fd) occurred in the
application at location 0x1e08a325.
Click on OK to terminate the program
Click on CANCEL to debug the program
So it looks to me to be a current bug.
--
Duncan Booth http://kupuguy.blogspot.com
eryksun ()
>
> I suspect that object.__str__ is really object.__repr__ by default, as
> they both print out the same string, so that this doesn't make any
> sense.
They're not the same object, and they don't have all of the same methods.
In [1]: object.__repr__ is object.__str__
Out[1]: False
In [2]: object.__repr__.__name__
Out[2]: '__repr__'
In [3]: object.__str__.__name__
Out[3]: '__str__'
In [4]: object.__repr__.__hash__()
Out[4]: 28910896
In [5]: object.__str__.__hash__()
Out[5]: 28910976
In [6]: object.__repr__.__call__(100)
Out[6]: '<int object at 0x01BE5234>'
In [7]: object.__str__.__call__(100)
Out[7]: '100'
Carl Banks
Multiple people reproduce a Python hang/crash yet it looks like no one
bothered to submit a bug report....
I observed the same behavior (2.6 and 3.2 on Linux, hangs) and went
ahead and submitted a bug report.
Carl Banks
J Peyret
> Multiple people reproduce a Python hang/crash yet it looks like no one
> bothered to submit a bug report....
>
> I observed the same behavior (2.6 and 3.2 on Linux, hangs) and went
> ahead and submitted a bug report.
>
> Carl Banks
Speaking for myself, I've only put in one bug report on an OSS
project. Won't do it again.
Firefox, some kinda "attribute works with html, but blows up on xhtml"
issue. Nothing that was really xhtml related, but their Bugzilla
folks pulled out some unconvincing RFC crap claiming that it was out
of scope for xhtml as opposed to html so they wouldn't fix it.
Their choice. 4 yrs ago.
Still getting occasional emails from Bugzilla about that "we won't fix
it for you" bug. At least 2 dozen over the years. Nothing about
fixing it, just status churn.
If I ever specifically work on an OSS project's codeline, I'll post
bug reports, but frankly that FF example is a complete turn-off to
contributing by reporting bugs.
Terry Reedy
> Multiple people reproduce a Python hang/crash yet it looks like no one
> bothered to submit a bug report....
I did not because I did not initially see a problem...
>
> I observed the same behavior (2.6 and 3.2 on Linux, hangs) and went
> ahead and submitted a bug report.
http://bugs.python.org/issue11603
where I added additional comments.
--
Terry Jan Reedy
Carl Banks
> If I ever specifically work on an OSS project's codeline, I'll post
> bug reports, but frankly that FF example is a complete turn-off to
> contributing by reporting bugs.
You probably shouldn't take it so personally if they don't agree with
you. But it's ok, it's not unreasonable to call attention to (actual)
bugs here.
I was surprised, though, when several people confirmed but no one
reported it, especially since it was a crash, which is quite a rare
thing to find. (You should feel proud.)
Carl Banks
J Peyret
> On Mar 18, 5:31 pm, J Peyret <jpey...@gmail.com> wrote:
>
> > If I ever specifically work on an OSS project's codeline, I'll post
> > bug reports, but frankly that FF example is a complete turn-off to
> > contributing by reporting bugs.
>
> You probably shouldn't take it so personally if they don't agree with
> you. But it's ok, it's not unreasonable to call attention to (actual)
> bugs here.
>
No, I didn't take the refusal personally at all, though it seemed
kinda glib to xhtml-not-hmtl out of a bug. Such is life.
What I object to is getting auto-spammed for years after that because
I was silly enough to enter my email on their database and then being
notified about every single event on that bug.
> I was surprised, though, when several people confirmed but no one
> reported it, especially since it was a crash, which is quite a rare
> thing to find. (You should feel proud.)
>
> Carl Banks
Yes, that's why I reported it. Python is extremely stable so it
seemed worthwhile. And I figured someone on the list would know its
bug quotient.
Impressed that there is already a bit of a proposed approach on the
entry to fix it, you guys are great.
But... I rather thought __repr__ was going to disappear in 3.x, with
just __str__ sticking around.
Steven D'Aprano
> I observed the same behavior (2.6 and 3.2 on Linux, hangs) and went
> ahead and submitted a bug report.
Thank you.
--
Steven