Re: [Python-Dev] Some RFE for review
Reinhold Birkenfeld wrote:
> Hi,
>
> 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):
Aren't there opinions to the RFE other than the "path module" one?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
Oren Tirosh wrote: > An infrastructure that could be leveraged is the readahead buffer used > by the file object's line iterator. That's the infrastructure I meant. I was just being sloppy with my terminology ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
On 6/27/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Reinhold Birkenfeld wrote: > > 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. > > The latter is further complicating the file interface, so I would follow the > > principle that not every 3-line function should be builtin. > > As Douglas Alan's sample implementation (and his second attempt [1]) > show, getting this right (and reasonably efficient) is actually a > non-trivial exercise. Leveraging the existing xreadlines > infrastructure is an idea worth considering. Do you mean the existing xreadlines infrustructure that no longer exists since 2.4 ? :-) An infrastructure that could be leveraged is the readahead buffer used by the file object's line iterator. Oren ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
[Paul Moore on readline getting a record separator argument] > As a more general approach, would it be worth considering an addition > to itertools which took an iterator which generated "blocks" of items, > and split them on a subsequence? Nope. Assign responsibility to the class that has all of the relevant knowledge (API for retrieving blocks, type of the retrieved data, how EOF is detected, etc). > It's a generalisation of the basic > pattern here, and would be able to encapsulate the fiddly "what if a > separator overlaps a block split" logic without locking it down to > string manipulation... How do you build, scan, and extract the buffer in a type independent manner? Are there any use cases for non-string data buffers, a stream of integers or somesuch? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
On 6/27/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > As Douglas Alan's sample implementation (and his second attempt [1]) > show, getting this right (and reasonably efficient) is actually a > non-trivial exercise. Leveraging the existing xreadlines > infrastructure is an idea worth considering. > > I think it's worth leaving this one open, and see if someone comes up > with a patch (obviously, this was my opinion from the start, or I > wouldn't have raised the RFE in response to Douglas's query!) As a more general approach, would it be worth considering an addition to itertools which took an iterator which generated "blocks" of items, and split them on a subsequence? It's a generalisation of the basic pattern here, and would be able to encapsulate the fiddly "what if a separator overlaps a block split" logic without locking it down to string manipulation... Or does that count as overgeneralisation? Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
Reinhold Birkenfeld wrote: > 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. > The latter is further complicating the file interface, so I would follow the > principle that not every 3-line function should be builtin. As Douglas Alan's sample implementation (and his second attempt [1]) show, getting this right (and reasonably efficient) is actually a non-trivial exercise. Leveraging the existing xreadlines infrastructure is an idea worth considering. I think it's worth leaving this one open, and see if someone comes up with a patch (obviously, this was my opinion from the start, or I wouldn't have raised the RFE in response to Douglas's query!) Cheers, Nick. [1] http://mail.python.org/pipermail/python-list/2005-February/268547.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some RFE for review
> 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Some RFE for review
Hi,
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):
1193128:
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.
1226256:
The "path" module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.
1216944:
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.
1214675:
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.
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.
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.
The latter is further complicating the file interface, so I would follow the
principle that not every 3-line function should be builtin.
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.
1052098:
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.
985094:
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 ;)
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
