Hi Greg,
Thanks for the feedback.
On 22 July 2013 23:01, Gregory P. Smith wrote:
> On Mon, Jul 22, 2013 at 2:44 PM, Ben North wrote:
>> [... proposed change of behaviour such that a recursive
>> dictview gives a repr() with "..." rather than a RuntimeError ...]
>
&g
Hi,
A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out
to be the one noted in [http://bugs.python.org/issue18019], i.e.:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d
This issue has been fixed in hg; the behaviour now is that a
RuntimeError is produced for a recursive dictionary
>> The current documentation for tarfile.TarFile.extractfile() does not
>> mention that the returned 'file-like object' supports close() and also
>> iteration. The attached patch (against svn trunk) fixes this.
>
> Please post the patch to bugs.python.org
Done:
http://bugs.python.org/issue582
Hi,
The current documentation for tarfile.TarFile.extractfile() does not
mention that the returned 'file-like object' supports close() and also
iteration. The attached patch (against svn trunk) fixes this.
(Background: I was wondering whether I could write
def process_and_close_file(f_in):
Hi,
As suggested, I've created
http://bugs.python.org/issue5191
to hold the patches for this feature, and the relation to the
'partial.skip' feature request. Could somebody with appropriate
privileges close the issue as rejected, if indeed that is the decision?
Thanks,
Ben.
___
Hi,
My reading of the most recent set of emails on this topic is that the
balance of opinion is against adding a 'partial_right' or 'partial.skip'
feature. I still think such a feature would be of real use, although I
can see the arguments against adding it. Is the conclusion 'no thanks',
then?
Hi,
Thanks for the further responses. Again, I'll try to summarise:
Scott David Daniels pointed out an awkward interaction when chaining
partial applications, such that it could become very unclear what was
going to happen when the final function is called:
> If you have:
> def button(root,
Hi,
> [ Potential new "functools.partial_right", e.g.,
>
>split_comma = partial_right(str.split, '.')
> ]
Thanks for the feedback. Apologies if (as was suggested) this should
have gone to python-ideas; I thought as a fairly small extension to
existing functionality it would be OK here. I'l
Hi,
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
# Won't work when called:
split_comma = partial(str.split, sep = ',')
and to create a 'log to
I wrote:
> I've sent an updated version of PEP 363 to the editors, which
> includes the following summary of the discussion. I hope I've
> captured the important points, but please let me know if there's
> something important I've left out or misrepresented.
There were a couple of points made off
[EMAIL PROTECTED] wrote:
> > > I really, really wish that every feature proposal for Python had
to meet
> > > some burden of proof
Ben North wrote:
> > This is what I understood the initial posting to python-ideas to be
> > about.
[EMAIL PROTECTED] wro
I've sent an updated version of PEP 363 to the editors, which
includes the following summary of the discussion. I hope I've
captured the important points, but please let me know if there's
something important I've left out or misrepresented.
- - - - 8< - - - -
Mailing Lists Discussion
Initi
Guido van Rossum wrote:
> This seems to be the overwhelming feedback at this point, so I'm
> withdrawing my support for the proposal. I hope that Ben can write up
> a PEP and mark it rejected, to summarize the discussion; it's been a
> useful lesson.
The feedback is clear, yes. The "new syntax se
The support for the including the feature at all is still not unanimous.
Perhaps the way forward is to try to reach consensus on the favourite
(or least-unfavourite) syntax, and I'll revise the PEP and sample
implementation.
I think the "obj.[attr_name]" syntax has the most support. To stop this
Guido van Rossum wrote:
> - There's near-universal dislike for the two-arg form, so let's drop
> that part of the proposal.
This is a strong consensus, definitely, so we can conclude that this
point has been decided. I will remove it from the PEP.
Guido also wrote:
> - There's a lot of suppor
Apologies: I overlooked a couple of replies in my summary earlier. Tim
Delaney and Terry Reedy both responded in positive terms to the
one-argument form and its syntax, and in negative terms to the
two-argument form.
Also, I missed the fact that Neil Toronto had made the same point as me
when he
Thanks for the comments so far on this. First, on the general idea:
Neil Toronto:
> I like it.
> [...]
> > obj.(attr_name) += 1
> Even nicer; much, much better than the current spelling.
Brett Cannon:
> +0 on the one-item version.
Anthony Baxter:
> -1 from me.
Collin Winter:
> I like the gen
access using the new syntax over getattr etc. Is 1% "too much" for
this feature?
Ben.
- - - - 8< - - - -
PEP: 363 [PROVISIONAL NUMBER]
Title: Syntax For Dynamic Attribute Access
Version: $Revision$
Last-Modified: $Date$
Author: Ben North
Status: Draft
Type: Standards Track
C
18 matches
Mail list logo
