可变字符串 [英] Mutable strings

问题描述

是否有人建议引入可变字符串类型（当然是）

并通过报价类型将它们与标准字符串区分开来 - 单个

还是双倍？据我所知''和'目前在所有

的情况下都是可以互换的（只要它们已配对）所以没有超载

这种语言很混乱。当然可能会有一些有趣的问题

当前代码没有区别，但它会死了

很容易通过搜索来解决 - 和 - 更换。对于返回字符串的函数，这将是默认的

返回类型...

看起来有很多方法可以通过挖掘
$来处理这个问题。 b $ b模块用于更基本的类型，但是在''用户级''可以获得更好的

。

解决方案

Gordon Airport写道：

是否有人建议引入可变字符串类型（当然是的）
并将它们与标准字符串区分开来按报价类型 - 单个
还是双倍？据我所知''和'目前在所有情况下都是可以互换的（只要它们是配对的）所以没有超载来使语言变得混乱。当然可能存在一些有趣的问题
目前的代码没有区别，
但是用搜索和替换修复它会很容易。

^^^^^^^^^^^^^^^^^^^^^^^^^

不，绝对不会。你还必须考虑

已经没有转义的嵌入式引号，而且我确定还有其他的并发症。

>
但是，如果只是为了让

的想法可以被杀死并埋葬好，那么你可能值得写一个PEP。 ;-)


-Peter

2003年9月20日星期六下午6:40，戈登机场写道：

有没有人建议引入一个可变的字符串类型（当然是的）
并通过引用类型将它们与标准字符串区分开来 - 单个
还是双倍？据我所知''和'目前在所有情况下都是可以互换的（只要它们是配对的）所以没有超载来使语言变得混乱。当然可能存在一些有趣的问题
目前的代码没有区别，但它很容易用搜索和替换来解决。对于返回字符串的函数，这将是默认的返回类型......
看起来有一些方法可以通过在
模块中挖掘更多基本类型来处理这个问题，但它会在''用户级'可以获得更好的
。

可变字符串是我错过的一件事，最初，当我第一次开始时

使用Python。过了一会儿，就像Pythonic一样。做事的方式沉没，

我意识到Python不需要*可变的字符串。


Python字符串（以及整数和浮点数）是所有不可变的非常好

理由：词典不能可靠地使用可变对象作为键。起初，

这看起来很像摇尾巴的尾巴......然而，一旦我完全理解了％（百分比）字符串运算符，并且能够有效地将字符串转换成列表并返回，我的焦虑消失了。这些内容涵盖了大部分

字符串的使用，可能会说服你需要可变性。


至于建议使用的引用类型应该确定是否或

不是字符串是可变的，我有点/一半/同意。一方面，制作（比如）

撇号意味着可变，双引号意味着不可变会破坏数千个现有应用程序 - 对于最终用户来说，一个简单的搜索并且

替换根本不可行！此外，以下

片段的含义将巧妙地（并且可能危险地）改变：


---- 8< -----

s1 ="这是一个''不可变的''字符串'

s2 =''这是一个可变的字符串" string''


s3 = s1.replace（"''"，''"''）+"和+ s2.replace（''''''''，'''''''）＃替换引号与

＃撇号和反之亦然


d1 = {s3：（s1，s2）}

---- 8< -----


Q1）s3的类型是？

Q2）s2会发生什么？由于它是可变的，不应该做替换

在线？

Q3）d1的分配是否会成功？如果它失败了，那不会是混乱的吗？


另一方面，Python已经有了这种类型的原始区分和

unicode字符串（分别为r" ..."和u" ..."）。如果它被采用，

我可以用m" ..."字符串的类型，可以被禁止使用字典键作为
。这样就可以打开其他不可变的

类型的蠕虫：我们最终会得到：


---- 8< - ---

a = 1234567m＃一个可变整数

b = 1234567.89m＃一个可变浮点数

c = 123456789012345678901234567890Lm＃一个可变长整数
d = 123 + 456jm＃一个可变的复数

e = m（1,2,3,4,5,6，a，b，c ;）＃一个可变的元组！ ：-p

---- 8< -----


这可能引发关于三元规模的火焰战争/激烈争论

运营商PEP！


也许有一个项目给你（以及对新的实用

申请的一个很好的介绍风格的Python类来启动）！


我相信人们过去曾写过这类东西 - 在一些

的情况下，它一定很有用，但我认为它应该作为一个单独的模块保存，所以你必须*向读者声明*你对这个/ strange /

行为的使用; 明确比隐含更好。


记住，穆罕默德不得不去*山上，而不是相反！


hth，

-andyj


blockquote>

Peter Hansen写道：


我认为可以用相当简单的方法处理优点

正则表达式

它可能是值得你写一个PEP，但是，如果只是为了这个想法可以被杀死并埋葬好。 ; - ）

是的，我没有看到一个，但我有点期待这个回复。

仍然，它没有'不要把三元运营商的核心利益放在

问题上。

Has anyone suggested introducing a mutable string type (yes, of course)
and distinguishing them from standard strings by the quote type - single
or double? As far as I know '' and " are currently interchangeable in all
circumstances (as long as they''re paired) so there''s no overloading to
muddy the language. Of course there could be some interesting problems
with current code that doesn''t make a distinction, but it would be dead
easy to fix with a search-and-replace. And which would be the default
return type for functions returning strings...
It looks like there are ways of handling this by digging around in the
modules for more basic types, but it would be much nicer to have it
available at ''user level''.

解决方案

Gordon Airport wrote:

Has anyone suggested introducing a mutable string type (yes, of course)
and distinguishing them from standard strings by the quote type - single
or double? As far as I know '' and " are currently interchangeable in all
circumstances (as long as they''re paired) so there''s no overloading to
muddy the language. Of course there could be some interesting problems
with current code that doesn''t make a distinction, but it would be dead easy to fix with a search-and-replace.

^^^^^^^^^^^^^^^^^^^^^^^^^
No, it definitely would not. You would also have to account for
embedded quotation marks that are not escaped already, and I''m
certain there are other complications.

It might be worth your writing a PEP, however, if only so that the
idea could be killed and buried for good. ;-)

-Peter

On Saturday 20 Sep 2003 6:40 pm, Gordon Airport wrote:

Has anyone suggested introducing a mutable string type (yes, of course)
and distinguishing them from standard strings by the quote type - single
or double? As far as I know '' and " are currently interchangeable in all
circumstances (as long as they''re paired) so there''s no overloading to
muddy the language. Of course there could be some interesting problems
with current code that doesn''t make a distinction, but it would be dead
easy to fix with a search-and-replace. And which would be the default
return type for functions returning strings...
It looks like there are ways of handling this by digging around in the
modules for more basic types, but it would be much nicer to have it
available at ''user level''.

Mutable strings are one thing that I missed, initially, when I first started
using Python. After a while, as the "Pythonic" way of doing things sank in,
I realised that Python doesn''t *need* mutable strings.

Python strings (and integers and floats) are all immutable for a very good
reason: dictionaries can''t reliably use mutable objects as keys. At first,
this seemed rather like "the tail wagging the dog"... however, once I fully
understood the % (percent) string operator, and the ability to efficiently
convert strings into lists and back, my anxiety went away. These cover most
usage of strings that might convince you you need mutability.

As for the suggestion that the kind of quote used should determine whether or
not a string is mutable, I sort of /half/ agree. On one hand, making (say)
the apostrophe mean mutable and the double quote mean immutable would break
thousands of existing applications - for end users, "a simple search and
replace" is simply not feasable! Furthermore, the meaning of the following
snippet would be subtly (and possibly dangerously) changed:

----8<-----
s1="this is an ''immutable'' string"
s2=''this is a "mutable" string''

s3=s1.replace("''",''"'')+" and "+s2.replace(''"'',''"'') # replace quotes with
# apostrophes and vice-versa

d1={s3:(s1,s2)}
----8<-----

Q1) What type will s3 be?
Q2) What happens to s2? As it''s mutable, shouldn''t it do the replacement
"in-line"?
Q3) Will the assignment of d1 succeed? If it fails, wouldn''t that be
confusing?

On the other hand, Python already has this type distinction for raw and
unicode strings (r"..." and u"...", respectively). If it were to be adopted,
I would be ok with an m"..." type of string, which could be barred from being
a dictionary key. This would open up a can of worms wrt the other immutable
types, too: would we end up with:

----8<-----
a=1234567m # a mutable integer
b=1234567.89m # a mutable float
c=123456789012345678901234567890Lm # a mutable long integer
d=123+456jm # a mutable complex number
e=m(1,2,3,4,5,6,"a","b","c") # a mutable tuple !!! :-p
----8<-----

This could start a flame-war/heated debate on the scale of the ternary
operator PEP!

Maybe there''s a project for you (and a good introduction to a practical
application for new-style Python classes to boot)!

I''m sure people have written this type of thing in the past - and in some
situations, it''s bound to be useful, but I think it should be kept as a
separate module, so that you have to *declare* your usage of this /strange/
behaviour to the reader; "explicit is better than implicit".

Remember, Mohammed had to go *to* the mountain, not the other way round!

hth,
-andyj

Peter Hansen wrote:

snip good points that I suspect could be handled with a fairly simple
regex

It might be worth your writing a PEP, however, if only so that the
idea could be killed and buried for good. ;-)

Yeah, I didn''t see one already but I kind of expected this response.
Still, it didn''t put a stake in the heart of the ternary operator
issue.

这篇关于可变字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！