> > > Yes, just about any ‘map()’ operation has a corresponding list > > > comprehension. (Does anyone know of a counter-example, a ‘map()’ > > > operation that doesn't have a correspondingly simple list > > > comprehension?)
> -- > \ “The apparent lesson of the Inquisition is that insistence on | > `\ uniformity of belief is fatal to intellectual, moral, and | > _o__) spiritual health.” —_The Uses Of The Past_, Herbert J. Muller | > Ben Finney
Kee Nethery wrote: > I just noticed the tag line "a place for Python". Looked it up online > (http://pyfora.org/) and it will be interesting to see if it can fill > the void that I experience (no centralized place to post and view user > submitted sample code) in the existing Python community.
There already is a well-known site for exchanging code snippets:
> As for user community fragmentation, I would guess that someone would be > less likely to create such a site if the user community needs were being > met by the official sites. There is a place for the existing old school > interaction forums (the IRC channel, the Usenet groups and mailing > lists), but there is also a place for archived user submitted comments.
> My personal preference would be a link in each sub-paragraph in the > official documentation to a wiki page devoted to that specific aspect of > the Python language. A place were users could augment the documentation > by providing sample code and by expanding out the documentation for > those of us who don't live and breath Python in our sleep. Real Python > coders would not click on the user wiki links and all of us newbies > could communicate with each other. But until a place like that exists, > perhaps Pyfora will get us part way there.
I'm sure something like that could be added to the official documentation. Please file a feature request for on the Python tracker.
We could have a dedicated place on the python.org wiki to host such snippets and then use sub-pages for the various topics.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Nov 03 2009)
> Strange to say it's a solution, when it doesn't solve the stated > problem: to replace use of ‘map()’ with a list comprehension.
Granted I admit this later in my post. It's not a solution to the OPs request, but it is the best solution to such a case.
>> I understand the OP was asking for it, but list comprehensions aren't >> the best solution in this case... it would just be line noise.
> I disagree; a list comprehension is often clearer than use of ‘map()’ > with a lambda form, and I find it to be so in this case.
The use of map expresses a value and implies the procedure by which it is obtained.
The list comprehension expresses the procedure by which the value is obtained.
Both have uses and in some cases a list comprehension is definitely preferrable to a map operation.
However in this case the procedure by which we derive the value is not important or even interesting. It is much more succinct to think of the operation as a value and express it accordingly. There's no need to clutter the mind with extra name bindings and iteration keywords. They won't make our idea any more clear.
dot_product = map(mul, vec1, vec2)
vs
dot_product = [a * b for a, b in zip(vec1, vec2)]
It's very clear, at least to me, what a dot-product is in this case. Adding in the loop construct and name bindings doesn't enhance my understanding of what a dot-product is. I don't need to see the loop construct at all in this case. A dot product is simply the multiplication of each element in a vector sequence. It's more succinct to simply think of the value rather then expressing the procedure to construct that value.
This isn't a hammer issue. Not every problem is a nail.
On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote: > However in this case the procedure by which we derive the value is not > important or even interesting. It is much more succinct to think of the > operation as a value and express it accordingly. There's no need to > clutter the mind with extra name bindings and iteration keywords. They > won't make our idea any more clear.
> dot_product = map(mul, vec1, vec2)
> vs
> dot_product = [a * b for a, b in zip(vec1, vec2)]
> It's very clear, at least to me, what a dot-product is in this case.
> Adding in the loop construct and name bindings doesn't enhance my > understanding of what a dot-product is. I don't need to see the loop > construct at all in this case. A dot product is simply the > multiplication of each element in a vector sequence.
What you need is to define a function dot-product, and not hijack the name for a local value. Then the function's implementation is irrelevant to you: it could use a list comp, or could use map, it could use a for- loop, a while loop, recursion, or black magic:
Steven D'Aprano wrote: > On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote: >> Adding in the loop construct and name bindings doesn't enhance my >> understanding of what a dot-product is. I don't need to see the loop >> construct at all in this case. A dot product is simply the >> multiplication of each element in a vector sequence.
> What you need is to define a function dot-product, and not hijack the > name for a local value. Then the function's implementation is irrelevant > to you: it could use a list comp, or could use map, it could use a for- > loop, a while loop, recursion, or black magic:
> scalar = dot_product(vec1, vec2)
Or use the appropriate libraries:
from numpy import dot
scalar = dot(vec1, vec2)
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote: > Steven D'Aprano wrote: >> On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
>>> Adding in the loop construct and name bindings doesn't enhance my >>> understanding of what a dot-product is. I don't need to see the loop >>> construct at all in this case. A dot product is simply the >>> multiplication of each element in a vector sequence.
>> What you need is to define a function dot-product, and not hijack the >> name for a local value. Then the function's implementation is >> irrelevant to you: it could use a list comp, or could use map, it could >> use a for- loop, a while loop, recursion, or black magic:
>> scalar = dot_product(vec1, vec2)
> Or use the appropriate libraries:
> from numpy import dot
> scalar = dot(vec1, vec2)
Why would I want to use an already existing library that is fast, well- written and well-supported, when I can toss together a nasty kludge myself?
Steven D'Aprano wrote: > On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote: >> Or use the appropriate libraries:
>> from numpy import dot
>> scalar = dot(vec1, vec2)
> Why would I want to use an already existing library that is fast, well- > written and well-supported, when I can toss together a nasty kludge > myself?
because you want to perform a dot-product on strings?
Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: > On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote: > > from numpy import dot
> > scalar = dot(vec1, vec2)
> Why would I want to use an already existing library that is fast, > well- written and well-supported, when I can toss together a nasty > kludge myself?
Because using that library will ensure you can't migrate to Python 3 any time soon?
*rimshot*
-- \ “… a Microsoft Certified System Engineer is to information | `\ technology as a McDonalds Certified Food Specialist is to the | _o__) culinary arts.” —Michael Bacarella | Ben Finney
> My personal preference would be a link in each sub-paragraph in the official > documentation to a wiki page devoted to that specific aspect of the Python > language. A place were users could augment the documentation by providing > sample code and by expanding out the documentation for those of us who don't > live and breath Python in our sleep. Real Python coders would not click on > the user wiki links and all of us newbies could communicate with each other. > But until a place like that exists, perhaps Pyfora will get us part way > there.
The PHP documentation has this feature: user comments right on the same page (no link to a wiki, though). It's great, most of the best usage practices that I have learned in that language came from the user's comments, not from the official documentation itself.
Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: > On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
>> However in this case the procedure by which we derive the value is not >> important or even interesting. It is much more succinct to think of the >> operation as a value and express it accordingly. There's no need to >> clutter the mind with extra name bindings and iteration keywords. They >> won't make our idea any more clear.
>> dot_product = map(mul, vec1, vec2)
>> vs
>> dot_product = [a * b for a, b in zip(vec1, vec2)]
>> It's very clear, at least to me, what a dot-product is in this case.
>> Adding in the loop construct and name bindings doesn't enhance my >> understanding of what a dot-product is. I don't need to see the loop >> construct at all in this case. A dot product is simply the >> multiplication of each element in a vector sequence.
> What you need is to define a function dot-product, and not hijack the > name for a local value. Then the function's implementation is irrelevant > to you: it could use a list comp, or could use map, it could use a for- > loop, a while loop, recursion, or black magic:
> scalar = dot_product(vec1, vec2)
Even better.
But now I'm afraid the example is running away from the point.
So to summarize:
1. Extra name bindings and loop keywords aren't always easier to read.
2. Expressing what we want rather than how we get it is much more clear.
and (third dirty argument added)
3. List comprehensions leak their name bindings to the surrounding scope. :p
On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote: > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
>> On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote: >> > from numpy import dot
>> > scalar = dot(vec1, vec2)
>> Why would I want to use an already existing library that is fast, well- >> written and well-supported, when I can toss together a nasty kludge >> myself?
> Because using that library will ensure you can't migrate to Python 3 any > time soon?
Why would I want to migrate to Python 3 any time soon? 2.5 and 2.6 meet my needs (so far), and the new features in Python 3 aren't especially compelling to me. Particularly if migrating to 3 requires me to re-write all the libraries, where's the advantage?
Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: > On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
> > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: > >> Why would I want to use an already existing library that is fast, > >> well- written and well-supported, when I can toss together a nasty > >> kludge myself?
> > Because using that library will ensure you can't migrate to Python 3 > > any time soon?
> Why would I want to migrate to Python 3 any time soon?
Sounds like you've answered the questions posed, then. Good for you!
-- \ “The whole area of [treating source code as intellectual | `\ property] is almost assuring a customer that you are not going | _o__) to do any innovation in the future.” —Gary Barnett | Ben Finney
On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote: > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>> > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: >> >> Why would I want to use an already existing library that is fast, >> >> well- written and well-supported, when I can toss together a nasty >> >> kludge myself?
>> > Because using that library will ensure you can't migrate to Python 3 >> > any time soon?
>> Why would I want to migrate to Python 3 any time soon?
> Sounds like you've answered the questions posed, then. Good for you!
I was actually only being *half* tongue in cheek, which is why I left out the smiley.
On the python-dev list at the moment is a lot of discussion on why uptake of Python 3.1 has been slower than hoped. But one of the things that people haven't really discussed -- or at least that I haven't seen -- is why one would prefer 3.1 over 2.5 or 2.6.
I've played around with 3.0, and I've read the What's New for 3.1 (and am installing 3.1 now), and while the changes look nice, I'm not sure that they're nice enough to deal with the pain of 2to3 migration.
So how about that, 3.1 fans? What are the most compelling reasons for you that convinced you to change?
> On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote:
>> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
>>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>>>> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: >>>>> Why would I want to use an already existing library that is fast, >>>>> well- written and well-supported, when I can toss together a nasty >>>>> kludge myself? >>>> Because using that library will ensure you can't migrate to Python 3 >>>> any time soon? >>> Why would I want to migrate to Python 3 any time soon? >> Sounds like you've answered the questions posed, then. Good for you!
> I was actually only being *half* tongue in cheek, which is why I left out > the smiley.
> On the python-dev list at the moment is a lot of discussion on why uptake > of Python 3.1 has been slower than hoped. But one of the things that > people haven't really discussed -- or at least that I haven't seen -- is > why one would prefer 3.1 over 2.5 or 2.6.
> I've played around with 3.0, and I've read the What's New for 3.1 (and am > installing 3.1 now), and while the changes look nice, I'm not sure that > they're nice enough to deal with the pain of 2to3 migration.
> So how about that, 3.1 fans? What are the most compelling reasons for you > that convinced you to change?
Since I'm just learning Python and am an utter Python novice this might not amount to much, but it's in the nature of language evolution that the new more or less incompatible version *does* become the dominant one, and for new things it's then a good idea to adopt the coming in future generally used version of the language, instead of being left in a quagmire trying to catch up with new versions of tools and libs suddenly not so compatible with the old code.
This happened with e.g. C++ standardization in 1998. The whole standard library was revamped and put in a namespace, and old headers like [iostream.h] were removed. And as with the Python "/" operator core language functionality was changed: in C++98 'new' suddenly threw (Pythoneese raised) an exception instead of returning 0 on failure, and templates were suddenly "two phase" with quite different semantics, so that much old code didn't even compile, and when it did, didn't work correctly.
But those who chose to stay behind paid and still for some pay the price, having to use ages old tools and libs. One amusing or sad (depending one's point of view) variant was where firms chose to get along with the language evolution, tools etc., but still restrict themselves to not only pre-standard C++ but some early 1980's version, not much more than "C with classes" or "better C". For example, at Google they generally don't use C++ exceptions, presumably because they have a large code base of non-exception-safe code. Still, assuming that's the rationale, it would surprise me if they don't use exceptions in their new code.
This is perhaps an heretical view, that the new language version's advantages don't matter so much as the fact that the new language version is incompatible, viewing that incompatibility as a /reason/ to change.
But I think it's realistic; getting the advantages (such as with Python 3.x improved efficiency for range etc., and thus also more clear notation) is just an added bonus.
<ste...@REMOVE.THIS.cybersource.com.au> wrote: > On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote: > > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
> >> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
> >> > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: > >> >> Why would I want to use an already existing library that is fast, > >> >> well- written and well-supported, when I can toss together a nasty > >> >> kludge myself?
> >> > Because using that library will ensure you can't migrate to Python 3 > >> > any time soon?
> >> Why would I want to migrate to Python 3 any time soon?
> > Sounds like you've answered the questions posed, then. Good for you!
> I was actually only being *half* tongue in cheek, which is why I left out > the smiley.
> On the python-dev list at the moment is a lot of discussion on why uptake > of Python 3.1 has been slower than hoped. But one of the things that > people haven't really discussed -- or at least that I haven't seen -- is > why one would prefer 3.1 over 2.5 or 2.6.
> I've played around with 3.0, and I've read the What's New for 3.1 (and am > installing 3.1 now), and while the changes look nice, I'm not sure that > they're nice enough to deal with the pain of 2to3 migration.
> So how about that, 3.1 fans? What are the most compelling reasons for you > that convinced you to change?
Itertools is worth the price of admission. As far as the "pain of migration" is concerned, less annoying than a mosquito bite.
Steven D'Aprano wrote: > On the python-dev list at the moment is a lot of discussion on why uptake > of Python 3.1 has been slower than hoped. But one of the things that > people haven't really discussed -- or at least that I haven't seen -- is > why one would prefer 3.1 over 2.5 or 2.6. > So how about that, 3.1 fans? What are the most compelling reasons for you > that convinced you to change?
Why I am back on 2.5/2.6
Case 1 I need to use the library construct for parsing binary files http://construct.wikispaces.com/ I tried porting it to python 3 but was not successful. Dont pretend to have tried very hard but... 1. The library is quite well written but I dont know its internals 2. In fact I am just familiarisng myself with its usage 3. Intricacies of 2to3 changes their whys and wherefores are quite foreign to me -- specifically unicode matters have always frightened me.
Case 2 I prefer to use python-mode in emacs for development python 3 has broken python-mode by removing execfile I suggested a (1-line) fix https://bugs.launchpad.net/python-mode/+bug/450552 Its still pending.
Case 3 Python3 has a windows installer but no deb packages for ubuntu/debian I installed with the installer on windows and compiled the sources on linux (with some help of this list) However compilation takes time and converts my laptop into a toaster Given the above 2 cases I seem to have wasted the wearntear of my laptop.
Summary: The attraction of python is not primarily in the language. Its not even in the batteries that are *included* but the non-included ones that are available. If that set is significantly sparser for 3 than for 2.x I dont see how many people can adopt it even if they wish to
[Excludes the academics in ivory towers who discuss the subtle qualities of different languages. Been-there-done-that (was in a university for 20 years) and if I was in that context I would not use 2 or 3 but lisp, haskell or some other beautiful wonderment from arcanaland]
>>>>>Why would I want to use an already existing library that is fast, >>>>>well- written and well-supported, when I can toss together a nasty >>>>>kludge myself?
>>>>Because using that library will ensure you can't migrate to Python 3 >>>>any time soon?
>>>Why would I want to migrate to Python 3 any time soon?
>>Sounds like you've answered the questions posed, then. Good for you!
> I was actually only being *half* tongue in cheek, which is why I left out > the smiley.
> On the python-dev list at the moment is a lot of discussion on why uptake > of Python 3.1 has been slower than hoped. But one of the things that > people haven't really discussed -- or at least that I haven't seen -- is > why one would prefer 3.1 over 2.5 or 2.6.
> I've played around with 3.0, and I've read the What's New for 3.1 (and am > installing 3.1 now), and while the changes look nice, I'm not sure that > they're nice enough to deal with the pain of 2to3 migration.
> So how about that, 3.1 fans? What are the most compelling reasons for you > that convinced you to change?
Steven D'Aprano wrote: > I've played around with 3.0, and I've read the What's New for 3.1 (and am > installing 3.1 now), and while the changes look nice, I'm not sure that > they're nice enough to deal with the pain of 2to3 migration.
I am in a different position since I did not have current code that would need migrating.
> So how about that, 3.1 fans? What are the most compelling reasons for you > that convinced you to change?
I am writing a book on algorithms that uses a subset of 3.1 as the algorithm language. It it simply cleaner and easier to explain to people not already familiar with the quirks of 2.x. One small but important-to-me example. I do not need to put 'from __future__ import integerdivision' (or whatever the incantation is) as the top of files. Hence I do not need to waste energy (mime and readers) explaining furture imports and the specifics of the old versus new meaning of int/int.
While I initially resisted the text==unicode change, I now see it as essential to the future of Python as a world algorithm language.
I admit that I am more bothered about the leftover quirks (to me -- sludge) in 2.x than most.
Unless you are the author/maintainer of an essential library, I have no opinion as to what you do with old code, or even what you use for new code.
I do care about people trying to disparage or sabotage 3.x.
On Thu, Nov 5, 2009 at 5:31 PM, Terry Reedy <tjre...@udel.edu> wrote: > Steven D'Aprano wrote:
>> I've played around with 3.0, and I've read the What's New for 3.1 (and am >> installing 3.1 now), and while the changes look nice, I'm not sure that >> they're nice enough to deal with the pain of 2to3 migration.
> I am in a different position since I did not have current code that would > need migrating.
>> So how about that, 3.1 fans? What are the most compelling reasons for you >> that convinced you to change?
> I am writing a book on algorithms that uses a subset of 3.1 as the algorithm > language. It it simply cleaner and easier to explain to people not already > familiar with the quirks of 2.x. One small but important-to-me example. I do > not need to put 'from __future__ import integerdivision' (or whatever the > incantation is) as the top of files. Hence I do not need to waste energy > (mime and readers) explaining furture imports and the specifics of the old > versus new meaning of int/int.
I agree. Most of my code is primarily mathematical, and while I personally see the move away from functional programming techniques as a minor misstep, the cleanliness of it all more than makes up for that.
|
