Message148844
| Author |
pitrou |
| Recipients |
Arfrever, Trundle, barry, djc, eric.araujo, nadeem.vawda, ncoghlan, petri.lehtinen, pitrou, python-dev, rpointel, skrah |
| Date |
2011年12月04日.08:59:11 |
| SpamBayes Score |
3.1916045e-08 |
| Marked as misclassified |
No |
| Message-id |
<1322988839.3484.2.camel@localhost.localdomain> |
| In-reply-to |
<1322969609.46.0.476602870597.issue12555@psf.upfronthosting.co.za> |
| Content |
> Is the following change in behavior caused by the fix for this issue?
>
> $ python3.2 -c $'class A(IOError):\n def __init__(self, arg): pass\nA(arg=1)'
> $ python3.3 -c $'class A(IOError):\n def __init__(self, arg): pass\nA(arg=1)'
> Traceback (most recent call last):
> File "<string>", line 3, in <module>
> TypeError: A does not take keyword arguments
It must be because IOError now has a significant __new__ method.
I could change it to accept arbitrary arguments but I'm not sure that's
the right solution.
Another approach would be:
- if IOError is instantiated, initialize stuff in IOError.__new__
- otherwise, initialize stuff in IOError.__init__
What do you think? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年12月04日 09:08:13 | pitrou | set | recipients:
+ pitrou, barry, ncoghlan, nadeem.vawda, djc, eric.araujo, Arfrever, Trundle, skrah, python-dev, petri.lehtinen, rpointel |
| 2011年12月04日 08:59:11 | pitrou | link | issue12555 messages |
| 2011年12月04日 08:59:11 | pitrou | create |
|