On Jan 31, 4:30 pm, Terran Melconian
<[EMAIL PROTECTED]> wrote:
> * Why are there no real mutable strings available?
>
> I found MutableString in UserString, but further research indicates
> that it is horribly inefficient and actually just wraps immutable
> strings for the implementation.
>
> I want to be able to accumulate a string with +=, not by going
> through an intermediate list and then doing ''.join(), because I
> think the latter is ugly.
If it's just the weird spelling, you can always write
str.join("",acc)
> There are also times when I'd like to use
> the string as a modifiable buffer.
array module has already been mentioned.
You can also use an mmap (pass it a file handle of -1 I believe to get
an anonymous buffer), or even a numpy array of type character if
you're feeling frisky.
Python 3.0 is scheduled to have a mutable buffer type. (BTW,
originally there was going to be a mutable bytes type, but this proved
to cause many inconveniences so bytes is now an immutable, and buffer
is a now a lessened version of what bytes would have been.)
> Is the python idiom that this is actually the Right Thing for
> reasons I'm not seeing? Is there a fundamental reason it would be
> hard to implement a mutable string in cpython?
It might seem a little weird for someone coming from Perl, but Python
isn't the sort of language that implements every possible feature that
isn't "fundamentally hard". Python carefully considers the benefits
and drawbacks of adding something, and if there is too much drawback
it won't be added, no matter how obvious or basic it seems.
In practice, very few string operations really need the benefit of
mutability. (How large are most strings, really?) OTOH, the
drawbacks of mutability are severe: once you allow string buffer data
to change, then the language has to take defensive steps in case
string values are mutated. Strings could no longer be keys for dicts,
for instance, which would be unfortunate since that's how Python looks
up global variables and attributes.
Python wisely made the built-in string type immutable--saving all
kinds of grief for the most typical usages--while providing modules
such as cStringIO, array, and mmap to handle the special cases where
you really need a mutable type.
> * What's the best way to initialize a list of lists?
>
> I keep wanting to do this:
>
> l=[[None]*5]*5
>
> as do many other Python novices, but of course it quickly becomes
> apparent why this is a bad idea as soon as one modifies a value.
> The best I've found is:
>
> l=[[None]*5 for i in range(5)]
>
> I don't particularly like it, though. It bothers me to have to
> explain list comprehensions, which are a moderately advanced feature
> conceptually, just to initialize an array. We could get around this
> if we had a defaultlist, but we don't. Is there a more elegant
> solution here?
No. Since 2D arrays aren't commonplace, since listcomps work passably
here, and since there's a popular thrid-party library (numpy) that
handles multidimensional arrays, it's unlikely that Python would add
any means to do this more elegantly.
You can put it in a function and forget about how it's implemented if
you don't like the listcomps.
def create_empty_2d_list(rows,cols):
return [[None]*cols for i in xrange(rows)]
> * Is there a way to get headings in docstrings?
>
> I want to create my own sections, like "OVERVIEW", "EXAMPLES",
> "AUTHORS", "BUGS", etc. I can't figure out any way to do this. In
> perldoc, I can easily use =head1, but I can't figure out the Python
> equivalent. At first I thought I could use (re)structuredtext, but
> then it became apparent that pydoc(1) does not parse any of this
> markup. Am I missing something, or is it just not possible to
> achieve this effect other than by writing separate, independent
> manpages?
Not a big expert on docstrings (they seem so superfluous...) but
perhaps there are third-party packages that let you specify meta-
documentation with function decorators. For example:
@overview("Blah blah blah")
@authors("So and so")
def some_function():
pass
Try looking on PyPI (cheeseshop.python.org). Python's in-code
documentation is pretty basic; I think Python is happy to outsource
more elaborate schemes to third party packages.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
