[issue25652] collections.UserString.__rmod__() raises NameError

Change by Irit Katriel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue25652] collections.UserString.__rmod__() raises NameError

miss-islington added the comment: New changeset 7abf8c60819d5749e6225b371df51a9c5f1ea8e9 by Miss Islington (bot) (Batuhan Taşkaya) in branch 'master': bpo-25652: Fix __rmod__ of UserString (GH-13326) https://github.com/python/cpython/commit/7abf8c60819d5749e6225b371df51a9c5f1ea8e9 --

[issue25652] collections.UserString.__rmod__() raises NameError

Change by Batuhan : -- keywords: +patch pull_requests: +13238 stage: needs patch -> patch review ___ Python tracker ___ ___ Python-b

[issue25652] collections.UserString.__rmod__() raises NameError

Jonathan Goble added the comment: I would prefer to keep __rmod__ and fix the bug, given that the use case I described above would otherwise create an inconsistency in subclasses, which would be able to easily extend __mod__ by calling super(), but would be forced to fully implement __rmod__ t

[issue25652] collections.UserString.__rmod__() raises NameError

Serhiy Storchaka added the comment: I think any solution is better than keeping a bug in the current code. -- ___ Python tracker ___ _

[issue25652] collections.UserString.__rmod__() raises NameError

Raymond Hettinger added the comment: Unless there are objections, I think the wisest course is to remove __rmod__ entirely (refuse the temptation to guess at what the user would expect the semantics to be). -- ___ Python tracker

[issue25652] collections.UserString.__rmod__() raises NameError

Jonathan Goble added the comment: Any decision on this? I recently played around and found a reasonable use case where UserString.__rmod__ does get called; run the attached userstringerror.py to see it in action. Basically, it seems the idea of UserString is to subclass it, tweak as desired,

[issue25652] collections.UserString.__rmod__() raises NameError

Serhiy Storchaka added the comment: Issue28598 may be related. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue25652] collections.UserString.__rmod__() raises NameError

Jonathan Goble added the comment: Code analysis, if it can even be called that. I was simply looking through the source of the collections module one day out of curiosity (mainly to see how various things in it were implemented) and this bug jumped out at me as I was reading the code. I do not

[issue25652] collections.UserString.__rmod__() raises NameError

Martin Panter added the comment: Jonathon: Do you have a use case for __rmod__(), or did you find this bug by code analysis? UserString.__rmod__() was added as part of Issue 22189. The main reason seems to be so that UserString has all the methods listed by dir(str). The result was that UserS

[issue25652] collections.UserString.__rmod__() raises NameError

R. David Murray added the comment: This was set to commit review when Raymond was ready to commit it, but subsequent discussion indicates the patch isn't yet ready for commit. In particular, there ought to be some tests, even if the decision is to remove __rmod__. The fact that UserString pa

[issue25652] collections.UserString.__rmod__() raises NameError

Changes by Serhiy Storchaka : -- assignee: serhiy.storchaka -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25652] collections.UserString.__rmod__() raises NameError

Serhiy Storchaka added the comment: What about such example? >>> class F: ... def __init__(self, value): ... self.value = value ... def __mod__(self, other): ... if isinstance(other, str): ... return self.value % other ... return NotImplemented ... >>

[issue25652] collections.UserString.__rmod__() raises NameError

Antoine Pitrou added the comment: I admit I don't understand what __rmod__ is meant to achieve here, and following str's behaviour sounds like a reasonable decision. -- ___ Python tracker _

[issue25652] collections.UserString.__rmod__() raises NameError

Raymond Hettinger added the comment: Antoine, do you have any thoughts on this one? I'm inclined to remove __rmod__ entirely. That would match what str does and it avoids having to guess what the user meant when writing "A(s) % UserString(t)" when A does not have a __mod__ formatting method

[issue25652] collections.UserString.__rmod__() raises NameError

Serhiy Storchaka added the comment: In normal case there is no infinite recursion in collections.UserString1, since UserString.__rmod__(S) falls back to S.__mod__(str) or str.__rmod__(S). >>> S('say %s') % UserString('hello') Traceback (most recent call last): File "", line 1, in File "/ho

[issue25652] collections.UserString.__rmod__() raises NameError

Raymond Hettinger added the comment: The UserString1 patch is incorrect as it leads to infinite recursion because the __rmod__ operation only gets called when the other argument doesn't have __mod__. One possible fix is to coerce the template to a regular str: def __rmod__(self, template

[issue25652] collections.UserString.__rmod__() raises NameError

Serhiy Storchaka added the comment: Would be nice to add some tests. For example: 0 % collections.UserString(''). -- nosy: +serhiy.storchaka ___ Python tracker ___ __

[issue25652] collections.UserString.__rmod__() raises NameError

Raymond Hettinger added the comment: I'll apply this shortly. -- stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list

[issue25652] collections.UserString.__rmod__() raises NameError

Jonathan Goble added the comment: *ping* Can this be reviewed? It's a simple fix to a problem that happens consistently, and it would be nice to get it into the next bugfix release. -- versions: +Python 3.6 ___ Python tracker

[issue25652] collections.UserString.__rmod__() raises NameError

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue25652] collections.UserString.__rmod__() raises NameError

Xiang Zhang added the comment: Quite sorry for making some mistakes. unicodeobject does get a __radd__ method. It is added by addoperators though I cannot see it in PyNumberMethods. Now I think just fixing the typo is enough. -- Added file: http://bugs.python.org/file41066/collections.

[issue25652] collections.UserString.__rmod__() raises NameError

Xiang Zhang added the comment: It seems this is a typo. The args should be self.data. And since unicodeobject doesn't support __rmod__, at least I think we should str(format) or remove __rmod__ totally. I attach a patch. -- nosy: +xiang.zhang Added file: http://bugs.python.org/file4106

[issue25652] collections.UserString.__rmod__() raises NameError

Jonathan Goble added the comment: c06b2480766d appears to be the offending changeset. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue25652] collections.UserString.__rmod__() raises NameError

New submission from Jonathan Goble: In an instance of collections.UserString, any call to the __rmod__() method will raise NameError, due to the undefined "args" name in the method. -- components: Library (Lib) messages: 254830 nosy: Jonathan Goble, rhettinger priority: normal severity: