replace() method in unicode objects

[e7cf8a40-bd85-43dc-b2db-ec50fd01aa3f]

BPO	680863
Files	unicode-replace.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['interpreter-core'] title = 'replace() method in unicode objects' updated_at = user = 'https://bugs.python.org/faeltir' ``` bugs.python.org fields: ```python activity = actor = 'nnorwitz' assignee = 'none' closed = True closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'faeltir' dependencies = [] files = ['4995'] hgrepos = [] issue_num = 680863 keywords = ['patch'] message_count = 8.0 messages = ['42676', '42677', '42678', '42679', '42680', '42681', '42682', '42683'] nosy_count = 3.0 nosy_names = ['nnorwitz', 'jvr', 'faeltir'] pr_nums = [] priority = 'normal' resolution = 'rejected' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue680863' versions = ['Python 2.2'] ```

[e7cf8a40-bd85-43dc-b2db-ec50fd01aa3f]

Hi,

I found that unlike the string object, the replace() method in the unicode object doesn't throw an exception when you supply an empty pattern string. Instead it slaps on the replace string a few times at the end.

I'm supplying a patch to make the unicode object behave like the string object.

I realize that in 2.3, doing replace() with an empty pattern string will work differently so maybe you don't consider throwing an exception the Right Way(TM), but I'm presenting it to you in case you (like me) thinks it's just better if unicode and string objects behave in the same way while not changing the way that string objects currently work in 2.2.

Best regards, Fredrik Juhlin

[0aa1c2b5-8e64-4988-b25b-7db15cdc7c29]

Logged In: YES user_id=92689

What I'm not sure of is whether the fact that this: "x".replace("", "a") raises an exception in 2.2 and "works" in 2.3 is intentional. It returns this in 2.3: 'axa'.

[d21744ff-f396-4c71-955e-7dbd2e886779]

Logged In: YES user_id=33168

The change for 2.3 was on purpose. See Objects/stringobject.c 2.184 which fixed SF bug 595350.

Hmmm, unicode doesn't even do it right in 2.2.2+

>>> u"x".replace("", "a")
u'xaa'

Not sure what to do to fix for 2.2.3. :-(

[e7cf8a40-bd85-43dc-b2db-ec50fd01aa3f]

Logged In: YES user_id=386805

I checked the CVS and saw that it had not been touched, which is why I supplied the patch to make it act in the same manner as strings :)

The two options seems to be to either solve it in the manner that my patch does or make both behave like in 2.3.

While I realize that my opinion weighs light, not being part of the coding team in any way, it seems to me like the road of least surprise is the better way to go for a minor release and that would be to not change the obviously deliberate behaviour of the string object.

Well, that's my two cents :)

[0aa1c2b5-8e64-4988-b25b-7db15cdc7c29]

Logged In: YES user_id=92689

I'm not following you, in 2.3 CVS, "a".replace("", "x") yields "xax", yet with your patch the same thing with a unicode string raises an exception...

[e7cf8a40-bd85-43dc-b2db-ec50fd01aa3f]

Logged In: YES user_id=386805

Hello again,

I'm sorry for being unclear, I meant in the release22-maint branch of the CVS, which I (perhaps mistakenly?) assumed is the branch that all 2.2.* releases are made from.

Since I thought (apparently correctly) that the change in 2.3 was deliberate, I didn't think it was an issue for the trunk.

Again, I'm sorry for not being clear on that.

[0aa1c2b5-8e64-4988-b25b-7db15cdc7c29]

Logged In: YES user_id=92689

Sorry, it was me who was sleeping. I thought there was both an issue with 2.2.2 as well as with 2.3... It seems 2.3 is fine. Sorry for the added confusion!

[d21744ff-f396-4c71-955e-7dbd2e886779]

Logged In: YES user_id=33168

This patch appears to only be useful for 2.2.x which isn't maintained any longer. Since it would also change behaviour, I'm rejecting it.