[Python-Dev] Some RFE for review

Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Sun Jun 26 18:57:39 CEST 2005


while bugs and patches are sometimes tricky to close, RFE can be very easy
to decide whether to implement in the first place. So what about working a
bit on this front? Here are several RFE reviewed, perhaps some can be
closed ("should" is always from submitter's point of view):

str.translate(None, delchars) should be allowed and only delete delchars
from the string.
Review: may be a good feature, although string._idmap can be passed as the
first parameter too.

The "path" module by Jason Orendorff should be in the standard library.
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.

urllib(2) should gain a dict mapping HTTP status codes to the correspondig
status/error text.
Review: I can't see anything speaking against it.

warnings should get a removefilter() method. An alternative would be to
fully document the "filters" attribute to allow direct tinkering with it.
Review: As mwh said in a comment, this isn't Java, so the latter may be
the way to go.

Shift operands should be allowed to be negative integers, so e.g.
a << -2  is the same as  a >> 2.
Review: Allowing this would open a source of bugs previously well identifiable.

In order to read "records" separated by something other than newline, file objects
should either support an additional parameter (the separator) to (x)readlines(),
or gain an additional method which does this.
Review: The former is a no-go, I think, because what is read won't be lines.
The latter is further complicating the file interface, so I would follow the
principle that not every 3-line function should be builtin.

A function "attrmap" should be introduced which is used as follows:
attrmap(x)['att'] == getattr(x, 'att')
The submitter mentions the use case of new-style classes without a __dict__ used
at the right of %-style string interpolation.
Review: I don't know whether this is worth it.

An environment variable should be supported to set the default encoding.
Review: If one wants this for a single application, he can still implement it himself.

getattr should support a callable as the second argument, used as follows:
getattr(obj, func) == func(obj)
Review: Highly unintuitive to me.

That's all for today; sorry if it was too much ;)


Mail address is perfectly valid!

More information about the Python-Dev mailing list