Re: [Python-Dev] functools.compose to chain functions together
I am personally indifferent to this, even though I had in mind in PEP309, that compose would probably end up in there too. On the one hand, some people will keep on expecting it to be there. The ones that care about it will not be confused: they'll expect compose(f,g)(x) to be f(g(x)) as is proposed. It can't do any significant harm. On the other hand it's not likely to be used even as often as partial, which I always wanted mostly to make anonymous callables for Tkinter, not because of any ivory-tower functional programming bias. And the most common use case of compose() is covered by a one-liner that really doesn't need to be in the standard library. I'll say +0, with the + because if new Python programmers run across compose() in the docs, and aren't familiar with the idea, they can follow a link from there to Wikipedia, and maybe it will give them an idea we haven't thought of for something cool to do with it. Peter Harris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 99, Issue 7
> > Hello Python Developers, > > I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are tracking a issue with Python 3.2.2 on Windows Developer Preview when > using Internet Explorer. > [...] > I'd like to connect directly with a developer on the project so that we can > work closesly to resolve this issue. You know, without any specifics given about the issue, this smells like comment spam. If it wasn't from such a reputable source, I'd almost think someone is just contacting projects at random with vague reports of "issues" relating to IE10 to pump up some interest in the new browser, whether those projects are anything to do with web browsing or not. Only kidding, they aren't that reputable ;) I Googled the phrase "I am a Program Manager with the Ecosystem Engineering team at Microsoft", and it seems this scattershot approach is not new. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 104, Issue 79
> > On 03/21/2012 07:39 PM, Huan Do wrote: > > *Hi, > > > > I am a graduating Berkeley student that loves python and would like to > > propose an enhancement to python. My proposal introduces a concept of > > slicing generator. For instance, if one does x[:] it returns a list > > which is a copy of x. Sometimes programmers would want to iterate over a > > slice of x, but they do not like the overhead of constructing another > > list. Instead we can create a similar operator that returns a generator. > > My proposed syntax is x(:). The programmers are of course able to set > lower, upper, and step size like the following. -1 on the syntax And have you looked at itertools.islice ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 112, Issue 23
Chris Withers wrote:
> On 14/11/2012 09:58, Merlijn van Deen wrote:
> > On 14 November 2012 10:12, Chris Withers wrote:
> >> ...which made me a little sad
> >
> > Why did it make you sad? dict() takes 0.2?s, {} takes 0.04?s. In other
> > words: you can run dict() _five million_ times per second, and {}
> > twenty-five million times per second. That is 'a lot' and 'a lot'. It
> > also means you are unlikely to notice the difference in real-world
> > code. Just use the one you feel is clearer in the situation, and don't
> > worry about micro-optimalization.
>
> I'm inclined to agree, but it makes me sad for two reasons:
>
> - it's something that people get hung up on, for better or worse. (if it
> wasn't, Doug wouldn't have written his article)
>
> - it can make a difference, for example setting up a dict with many keys
> at the core of a type loop.
>
> Without looking at implementation, they should logically perform the
> same...
>
> Well, without looking at the implementation, you could form any opinion you
like about how they should perform. Still you could speculate that dict()
will
require a builtins name lookup, and that the process of passing keyword
arguments
might itself involve constructing a dictionary, so must inherently take at
least
a little longer than compiling a {} literal.
Peter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python Dev] PEP 309
Overall, I have no major objections to the PEP or the patch. Before it goes in on auto-pilot, it would be darned nice if the proponents said that they've found it helpful in real code and that they are satisfied with the timings. I guess "darned nice" is the best you can hope for. Not sure if Peter Harris is still around. Regards, Martin Yes, I'm still lurking, slightly aghast that my little PEP is getting such ferocious scrutiny. I would have like some of that in time for it to go into 2.4, but I suppose you should be careful what you wish for. I'll answer a few points from this thread, in no particular order: My original desire was a built-in, but it was suggested that the first step would be a Python implementation in the standard library to try it out. That was the basis for the PEP, and in fact a C implementation would have been beyond my expertise. However, I sympathise with anyone who feels unhappy about a new module just for what amounts to one function. I'd be happy to go back to the built-in, now someone cleverer than I am has written one. Sorry I can't rememeber your name, whoever you are. I'm having trouble with my e-mails. I was never too bothered about efficiency, and still am not. For me it was always primarily a way to save typing or build call-back functions on the fly. The discussion about using it to make instancemethods and classmethods -- way over my head! I would count that as something weird enough to be worth spelling out in "plain Python", in my code anyway. The PEP was scattered over a few patches because I wasn't too sure how to go about it, so there was my Python module, the C implementation, the unit tests and the docs all in separate patches. 3/4 of that was my fault - sorry! Once the PEP had been accepted, I didn't like to mess with it, which is why I went quiet for a while. It's gone past the point where I can personally contribute much, so I'd just like to say thanks and I look forward to the day when I can just use it. Peter Harris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
