[Python-Dev] Some RFE for review

[Raymond Hettinger]

> 1193128:
> str.translate(None, delchars) should be allowed and only delete
delchars
> from the string.

I had agreed to this one and it's on my todo list to implement.


> 1214675:
> warnings should get a removefilter() method. An alternative would be
to
> fully document the "filters" attribute to allow direct tinkering with
it.

I'm concerned that removefilter() may not work well in the presence of
multiple modules that use the warnings module.  It may be difficult to
make sure the one removed wasn't subsequently added another module.
Also, the issue is compounded because the order of filter application is
important.


> 1205239:
> 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.

The OP is asking why it is different for negative sequence indicies (why
the added convenience was thought to outweigh the loss of error
detection).



> 1152248:
> 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.

Okay, call it a record then.  The OPs request is not a non-starter.
There is a proven precedent in AWK which allows programmer specifiable
record separators.



> The latter is further complicating the file interface, so I would
follow
> the
> principle that not every 3-line function should be builtin.

This is not a design principle.  UserDict.Mixin shows that most of the
mapping API is easily expressible in terms of a few lines and a few
primitives; however, the mapping API has long been proven as valuable
for its expressiveness.  Likewise, Guido's any() and all() builtins can
be expressed in a single line but were accepted anyway.

A more nuanced version of the "principle" is:  if a proposal can be
easily expressed with a small grouping of existing constructs, then must
meet much higher standards of use frequency and expressiveness in order
to be accepted.



> 1110010:
> 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.

While potentially useful, the function is entirely unintuitive (it has
to be studied a bit before being able to see what it is for).  Also, the
OP is short on use cases (none were presented).  IMO, this belongs as a
cookbook recipe.


Raymond Hettinger