Carl Banks wrote:
> The shamelessness with which you inflated the verbosity of the latter
> is hilarious.
[snip]
> [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ]
>
> Now there's no longer much advantage in conciseness for the map version
> (seeing that you'd have
Erik Max Francis wrote:
> Ron Adam wrote:
>
>> Each item needs to stand on it's own. It's a much stronger argument
>> for removing something because something else fulfills it's need and
>> is easier or faster to use than just saying we need x because we have y.
>>
>> In this case sum and prod
Ron Adam wrote:
> Each item needs to stand on it's own. It's a much stronger argument for
> removing something because something else fulfills it's need and is
> easier or faster to use than just saying we need x because we have y.
>
> In this case sum and product fulfill 90% (estimate of cour
either using reduce or a
for-loop. I think the disagreements will be sorted out.
>>2. Reduce calls a function on every item in the list, so it's
>>performance isn't much better than the equivalent code using a for-loop.
>
> That is an optimization issue. Especially w
Mike Meyer wrote:
> I'd say that removing functions is a bad thing. On the other hand, I'd
> say moving them from builtins to the standard library when Python has
> functionality that covers most of the use cases for them is a good
> thing.
We all can pretty much guess
ng really wrong with
that, but it's unappealing.
I'd say that removing functions is a bad thing. On the other hand, I'd
say moving them from builtins to the standard library when Python has
functionality that covers most of the use cases for them is a good
thing.
The latter has occu
Christopher Subich wrote:
> Interesting; could you post an example of this? Whenever I try to think
> of that, I come up with unwieldly syntax for the functional case. In
> purely functional code the results of map/filter/etc would probably be
> directly used as arguments to oth
Christopher Subich wrote:
> One caevat that I just noticed, though -- with the for-solution, you do
> need to be careful about whether you're using a generator or list if you
> do not set an explicit initial value (and instead use the first value of
> 'sequence' as the start). The difference is
Carl Banks wrote:
>
> Christopher Subich wrote:
>>I've heard this said a couple times now -- how can listcomps not
>>completely replace map and filter?
> If you're doing heavy functional programming, listcomps are
> tremendously unwieldy compared to map et a
rformance isn't much better than the equivalent code using a for-loop.
That is an optimization issue. Especially when used with the operator
module, reduce and map can be significantly faster than for loops.
> *** (note, that list.sort() has the same problem. I would support
> replac
Jp Calderone wrote:
> Suggesting people can "like it or lump it" is a disservice to everyone.
However, when people start with "why is this so" and rather than listen
for information, try to argue that they are right, that behavior is a
disservice to the group. Preparing a cogent argument to convi
Christopher Subich wrote:
> Carl Banks wrote:
>
> > Listcomps et al. cannot do everything map, lambda, filter, and reduce
> > did. Listcomps are inferior for functional programming. But, you see,
> > functional is not the point. Streamlining procedural programs is th
Steven D'Aprano wrote:
> On Sun, 03 Jul 2005 08:14:28 -0700, Scott David Daniels wrote:
>
> > egbert wrote:
> >> On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote:
> >>
> >>>Also, map is easily replaced.
> >>>map(f1, sequence) ==
Erik Max Francis wrote:
> Ron Adam wrote:
>> I'm just estimating, but I think that is the gist of adding those two
>> in exchange for reduce. Not that they will replace all of reduce use
>> cases, but that sum and product cover most situations and can be
>> implemented more efficiently than u
ing them to use them. Python is being pushed into directions which
>> are *far* harder to understand than map and reduce (currying, decorators,
>> etc) and people don't complain about those.
>
>I find it surreal too, for a different reason.
>
>Python *works*, right n
Steven D'Aprano wrote:
> Frankly, I find this entire discussion very surreal. Reduce etc *work*,
> right now. They have worked for years. If people don't like them, nobody
> is forcing them to use them. Python is being pushed into directions which
> are *far* harder to u
Scott David Daniels wrote:
> egbert wrote:
>> How do you replace
>> map(f1,sequence1, sequence2)
>> especially if the sequences are of unequal length ?
>>
>> I didn't see it mentioned yet as a candidate for limbo,
>> but the same question goes for:
>&
Carl Banks wrote:
> Listcomps et al. cannot do everything map, lambda, filter, and reduce
> did. Listcomps are inferior for functional programming. But, you see,
> functional is not the point. Streamlining procedural programs is the
> point, and I'd say listcomps do tha
On Sun, 03 Jul 2005 08:14:28 -0700, Scott David Daniels wrote:
> egbert wrote:
>> On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote:
>>
>>>Also, map is easily replaced.
>>>map(f1, sequence) == [f1(element) for element in sequence]
>>
>> How
egbert wrote:
> On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote:
>
>>Also, map is easily replaced.
>>map(f1, sequence) == [f1(element) for element in sequence]
>
> How do you replace
> map(f1,sequence1, sequence2)
> especially if the sequences are of unequal
John Roth wrote:
> "Robert Kern" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> >
> > map and filter are being removed *because of* list comprehensions. Did you
> > even read Guido's articles about this issue? Your understanding o
On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote:
>
> Also, map is easily replaced.
> map(f1, sequence) == [f1(element) for element in sequence]
>
How do you replace
map(f1,sequence1, sequence2)
especially if the sequences are of unequal length ?
I didn't see it m
t in?
I'm not myself a huge functional programming guy, but I'm certainly not
in favor of the proposal to remove map, filter, reduce, and lambda. For
map and filter, I can at least see the argument, because they truly are
expressible with list comprehensions (which I do use myself, o
Steven D'Aprano wrote:
> On Sat, 02 Jul 2005 20:26:31 -0700, Devan L wrote:
>
>
>> Claiming that sum etc. do the same job is the whimper of
>>someone who doesn't want to openly disagree with Guido.
>>
>>Could you give an example where sum cannot do the job(besides the
>>previously mentioned prod
On Sun, 03 Jul 2005 01:01:18 -0400, Christopher Subich <[EMAIL PROTECTED]>
wrote:
>Steven D'Aprano wrote:
>> comps. But reduce can't be written as a list comp, only as a relatively
>> complex for loop at a HUGE loss of readability -- and I've never used
>> Lisp or Scheme in my life. I'm surely not
Steven D'Aprano wrote:
> comps. But reduce can't be written as a list comp, only as a relatively
> complex for loop at a HUGE loss of readability -- and I've never used
> Lisp or Scheme in my life. I'm surely not the only one.
See my reply to your other post for a more detailed explanation, but I
of reduce.
> Also, map is easily replaced.
> map(f1, sequence) == [f1(element) for element in sequence]
Three mental tokens ( map, f1, sequence ) versus seven ( [], f1, element,
for, element, in, sequence ).
Also, map can take any number of sequences:
map(f1, seq1, seq2, seq3, seq4, ...
Steven D'Aprano wrote:
> On Fri, 01 Jul 2005 13:42:10 -0400, Mike Meyer wrote:
>>No, he wants Python to be Pythonic. TMTOWTDI is not Pythonic.
>
> Too Many T--- Only Way To Do It?
>
> There Might Tangle One Way To Do It?
>
> T--- M--- Two Obvious Ways To Do It?
>
> Nope, sorry, still not gettin
Claiming that sum etc. do the same job is the whimper of
someone who doesn't want to openly disagree with Guido.
Could you give an example where sum cannot do the job(besides the
previously mentioned product situation?
Also, map is easily replaced.
map(f1, sequence) == [f1(element) for el
On Fri, 01 Jul 2005 19:15:46 -0700, Erik Max Francis wrote:
> Sean McIlroy wrote:
>
>> if that's the case then list
>> comprehensions and/or "first class functions" are likely to be the next
>> target.
>
> Slippery slope arguments are logical fallacies, you know.
Not if you are actually standin
ython bother introducing list comps when there is
nothing they can do that a for loop can't?
Functional programming using map etc does require a slightly different way
of thinking about programming than does procedural programming, just as
object-oriented needs a different way of thinking than spag
On Fri, 01 Jul 2005 09:13:58 -0700, mcherm wrote:
> Lambda serves a very specific purpose: declaring small, in-place
> functions which are no bigger than a single expression. I do this often
> enough that I DO want special syntax for it. But I'll admit that I
> wish "lambda" were about 5 or 6 cha
Jamey Cribbs <[EMAIL PROTECTED]> writes:
> Code blocks allow you to wrap up any Ruby code and pass it to a method
> and have it executed within that method. It is more powerful than
> lambda, because you can have multiple statements in the code block and
> you can do assignment within the code blo
Tom Anderson wrote:
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
I have no functional language background. Until recently, I had no use
for programming "expression to be evaluated later"
John Roth wrote:
> "Robert Kern" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>map and filter are being removed *because of* list comprehensions. Did you
>>even read Guido's articles about this issue? Your understanding of why
On Fri, 1 Jul 2005, Sion Arrowsmith wrote:
> Tom Anderson <[EMAIL PROTECTED]> wrote:
>> On Thu, 30 Jun 2005, Roy Smith wrote:
>>
>>> Even some of the relatively recent library enhancements have been kind
>>> of complicated. The logging module, for example, seems way over the
>>> top.
>>
>> Exa
On Fri, 1 Jul 2005, Ivan Van Laningham wrote:
> Personally, I find that Lisp & its derivatives put your head in a very
> weird place. Even weirder than PostScript/Forth/RPN, when you come
> right down to it.
+1 QOTW!
tom
--
REMOVE AND DESTROY
--
http://mail.python.org/mailman/listinfo/pyth
"Robert Kern" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> map and filter are being removed *because of* list comprehensions. Did you
> even read Guido's articles about this issue? Your understanding of why
> these changes are planne
Quoth Tom Anderson <[EMAIL PROTECTED]>:
...
| I disagree strongly with Guido's proposals, and i am not an ex-Lisp,
| -Scheme or -any-other-functional-language programmer; my only other real
| language is Java. I wonder if i'm an outlier.
|
| So, if you're a pythonista who
Terry Hancock wrote:
> On Friday 01 July 2005 03:36 pm, Ron Adam wrote:
>
>>I find map too limiting, so won't miss it. I'm +0 on removing lambda
>>only because I'm unsure that there's always a better alternative.
>
>
> Seems like some new
"Sean McIlroy" <[EMAIL PROTECTED]> writes:
> Peter Hansen wrote:
>
>> Sean, what gave you the impression this would change?
> if that's the case then list comprehensions and/or "first class
> functions" are likely to be the next target.
The existence of list comprehensions are the reason that th
ammers, baffled by
> recursion and the like, who don't want to be reproached with the fact
> of their mathematical illiteracy.) if that's the case then list
> comprehensions and/or "first class functions" are likely to be the next
> target.
map and filter are being re
syntaxes can still be managed?
> IOW, just ripping them out of the core and leaving everyone in the
> lurch doesn't seem too pythonic to me.
Python 3000 will be breaking more backwards compatibility than
map/reduce/filter. That legacy code won't work anyways.
I predict, though, that
Sean McIlroy wrote:
> if that's the case then list
> comprehensions and/or "first class functions" are likely to be the next
> target.
Slippery slope arguments are logical fallacies, you know.
--
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 1
>>>>> "Devan" == Devan L <[EMAIL PROTECTED]> writes:
Devan> None of them are really indispensible. Map and filter cab
Devan> be replaced with list comprehensions. reduce is redundant
Devan> except when multiplying a series; there's a sum f
Peter Hansen wrote:
> Sean, what gave you the impression this would change?
just inductive reasoning. i've been wrong before (like anyone who makes
that claim), and i'm a former python enthusiast, so my judgement must
be colored to some extent by bitterness. maybe they have solid reasons
for scr
I have never written a line of Lisp or Scheme, so it took me a while to
grok "lambda" as a synonym for "expression to be evaluated later". I
then thought it was similar to Smalltalk's functional closures, since
you can define local arguments at the beginning of the block, and then
write the body o
Sean McIlroy wrote:
> personally i don't know lisp (or scheme), but now i've
> decided to learn it, because eventually it will no longer be possible
> in python to pass functions as arguments or return them as values. the
> education sig will have to change its motto to "computer programming
> for
wpost.jsp?thread=98196
>
> He says he's going to dispose of map, filter, reduce and lambda. He's
> going to give us product, any and all, though, which is nice of him.
>
> What really struck me, though, is the last line of the abstract:
>
> "I expect tons of di
Tom Anderson wrote:
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
glad you asked. personally i don't know lisp (or scheme), but now i've
decided to learn it, because eventually it wil
On Friday 01 July 2005 03:36 pm, Ron Adam wrote:
> I find map too limiting, so won't miss it. I'm +0 on removing lambda
> only because I'm unsure that there's always a better alternative.
Seems like some new idioms would have to be coined, like:
def my_function(a1, a
On Fri, 01 Jul 2005 20:36:29 GMT, Ron Adam <[EMAIL PROTECTED]> wrote:
>Tom Anderson wrote:
>
>> So, if you're a pythonista who loves map and lambda, and disagrees with
>> Guido, what's your background? Functional or not?
>
>I find map too limiting, so w
Tom Anderson wrote:
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
I find map too limiting, so won't miss it. I'm +0 on removing lambda
only because I'm unsure that there's a
Tom Anderson wrote:
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
I'm familiar with several function languages but haven't used them
extensively; I was primarily a C++ programmer
Scott David Daniels <[EMAIL PROTECTED]> wrote:
>Roy Smith wrote:
>> Look at what happened to C when it mutated into C++. In isolation, most of
>> the features of C++ seem like good ideas. Taken together, it's a huge
>> hairy mess that most people only understand increasingly larger subsets of.
Roy Smith wrote:
> Look at what happened to C when it mutated into C++. In isolation, most of
> the features of C++ seem like good ideas. Taken together, it's a huge
> hairy mess that most people only understand increasingly larger subsets of.
> Fred Brooks called it the second system syndrom
Mandus wrote:
> jepp - faster, but still slower than the map.
>
> 100 iterations:
> zip+list-comprehension: 8.1s
> izip+list-comprehension: 7.5s
> map: 7.0s
>
Strange. On 2.4.1 izip is the fastest.
The thing is that if you put benchmark code in global the
results
"iK" <[EMAIL PROTECTED]> writes:
> Seems like he wants python programmers to solve their problems all in the
> same way. While that is great for corporate slaves it is terrible for the
> creative programmer.
No, he wants Python to be Pythonic. TMTOWTDI is not Pythonic.
> Python is quickly beco
[EMAIL PROTECTED] wrote:
> I avoid map sometimes, because I find its syntax less readable
> than list (and expression) comprehensions. But occasionally it
> is the most readable way to do something, and I wouldn't want to lose
> it.
I tend to avoid map as much as possible. Th
None of them are really indispensible. Map and filter cab be replaced
with list comprehensions. reduce is redundant except when multiplying a
series; there's a sum function for a reason. Lambda looks cleaner in
some cases, but you don't gain any functionality.
What really struck me,
Tom Anderson wrote:
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
I avoid map sometimes, because I find its syntax less readable
than list (and expression) comprehensions. But occasionally it
is the m
> Seems like he wants python programmers to solve their problems all in the
> same way. While that is great for corporate slaves it is terrible for the
> creative programmer.
> Python is quickly becoming the visual basic of the 21 century. If you want
> to have fun while getting some work done you
Seems like he wants python programmers to solve their problems all in the
same way. While that is great for corporate slaves it is terrible for the
creative programmer.
Python is quickly becoming the visual basic of the 21 century. If you want
to have fun while getting some work done you need to
er-functional-language programmer; my only other
> > real language is Java. I wonder if i'm an outlier.
> > So, if you're a pythonista who loves map and lambda, and disagrees
> > with Guido, what's your background? Functional or not?
> I'm a pythonista who doesn&
Tom Anderson <[EMAIL PROTECTED]> wrote:
>On Thu, 30 Jun 2005, Roy Smith wrote:
>> Even some of the relatively recent library enhancements have been kind
>> of complicated. The logging module, for example, seems way over the
>> top.
>Exactly the same thing happened with Java.
I was under the im
"Tom Anderson" wrote:
> On Fri, 1 Jul 2005, George Sakkis wrote:
>
> > Keeping the language small is a worthwhile goal, but it should be traded
> > off with conciseness and readability; otherwise we could well be content
> > with s-expressions.
>
> There's quite a number of satisfied LISP programm
ogrammer; my only other real
> language is Java. I wonder if i'm an outlier.
>
> So, if you're a pythonista who loves map and lambda, and disagrees with
> Guido, what's your background? Functional or not?
>
I'm a pythonista who doesn't love them. In fa
Comrades,
During our current discussion of the fate of functional constructs in
python, someone brought up Guido's bull on the matter:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
He says he's going to dispose of map, filter, reduce and lambda. He's
going to give
On Fri, 1 Jul 2005, George Sakkis wrote:
> "Terry Hancock" wrote:
>
> Keeping the language small is a worthwhile goal, but it should be traded
> off with conciseness and readability; otherwise we could well be content
> with s-expressions.
There's quite a number of satisfied LISP programmers ou
On Thu, 30 Jun 2005, Roy Smith wrote:
> Terry Hancock <[EMAIL PROTECTED]> wrote:
>
>> One of the strengths of Python has been that the language itself is
>> small (which it shares with C and (if I understand correctly, not being
>> a lisp programmer?) Lisp), but with all the syntax enhancements
"Terry Hancock" wrote:
> On Thursday 30 June 2005 09:49 am, Mike P. wrote:
>
> > IMHO I'm not particularly happy with the way Python is going language wise.
> > I mean, I don't think I'll ever use decorators, for example. Personally, in
> > terms of language features and capabilities I think the l
Robert Kern <[EMAIL PROTECTED]> wrote:
> Looks like the PSU got to yoNO CARRIER
No, the trackpad on my PowerBook seems to have gone a little haywire and
I'm getting the occasional random mouse click. In that case, it seemed to
have clicked the "Post" button.
--
http://mail.python.org/mailman/
Terry Hancock <[EMAIL PROTECTED]> wrote:
> One of the strengths of Python has been that the language itself is
> small (which it shares with C and (if I understand correctly, not being
> a lisp programmer?) Lisp), but with all the syntax enhancements going
> on, Python is getting pretty complica
Roy Smith wrote:
> Terry Hancock <[EMAIL PROTECTED]> wrote:
>
>>One of the strengths of Python has been that the language itself is
>>small (which it shares with C and (if I understand correctly, not being
>>a lisp programmer?) Lisp), but with all the syntax enhancements going
>>on, Python is g
Terry Hancock <[EMAIL PROTECTED]> wrote:
> One of the strengths of Python has been that the language itself is
> small (which it shares with C and (if I understand correctly, not being
> a lisp programmer?) Lisp), but with all the syntax enhancements going
> on, Python is getting pretty complica
On Thursday 30 June 2005 09:49 am, Mike P. wrote:
> That really sucks, I wasn't aware of these plans. Ok, I don't use reduce
> much, but I use lambda, map and filter all the time.
> [...]
> Also, I don't necessarily think list comprehensions are necessarily easier
>
uggested that. The ones that are planned to be removed are
lambda, reduce, filter and map. Here's GvR's blog posting that explains
the reasons:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
That really sucks, I wasn't aware of these plans. Ok, I don't use reduce
much,
as suggested that. The ones that are planned to be removed are
> lambda, reduce, filter and map. Here's GvR's blog posting that explains
> the reasons:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>
That really sucks, I wasn't aware of these plans. Ok, I
Wed, 29 Jun 2005 08:33:58 -0700 skrev Scott David Daniels:
> Mandus wrote:
>> 29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
>>
>>>Le Wed, 29 Jun 2005 09:46:15 + (UTC), Mandus a écrit :
>>>
>>>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
>>
>
"F. Petitjean" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
> Hoping that zip will not be deprecated.
Cease worrying. Zip was added to replace the zipping behavior of map and
the idiom map(None, a, b, ..
Mandus wrote:
> 29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
>
>>Le Wed, 29 Jun 2005 09:46:15 + (UTC), Mandus a écrit :
>>
>>res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
>
> seem to be a tad slower than the map, but nothing serious. Guess it's
> the ex
"Carl Banks" <[EMAIL PROTECTED]> wrote in message
> Fear not, people: just as the BDFL does not indiscriminately add
> features, also he does not indiscriminately remove them. zip, though
> it feels a little exotic, is very useful and serves a purpose that no
> language feature serves(*), so rest
F. Petitjean wrote:
> Le Wed, 29 Jun 2005 09:46:15 + (UTC), Mandus a écrit :
> > Hi there,
> >
> > inspired by a recent thread where the end of reduce/map/lambda in Python was
> > discussed, I looked over some of my maps, and tried to convert them to
> > list-c
29 Jun 2005 10:04:40 GMT skrev F. Petitjean:
> Le Wed, 29 Jun 2005 09:46:15 + (UTC), Mandus a écrit :
>> Hi there,
>>
>> inspired by a recent thread where the end of reduce/map/lambda in Python was
>> discussed, I looked over some of my maps, and tried to convert the
"F. Petitjean" <[EMAIL PROTECTED]> writes:
> res = [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
>
> Hoping that zip will not be deprecated.
Nobody has suggested that. The ones that are planned to be removed are
lambda, reduce, filter and map. Here's GvR's blog posti
Le Wed, 29 Jun 2005 09:46:15 + (UTC), Mandus a écrit :
> Hi there,
>
> inspired by a recent thread where the end of reduce/map/lambda in Python was
> discussed, I looked over some of my maps, and tried to convert them to
> list-comprehensions.
>
> This one I am n
Hi there,
inspired by a recent thread where the end of reduce/map/lambda in Python was
discussed, I looked over some of my maps, and tried to convert them to
list-comprehensions.
This one I am not sure how to conver:
Given three tuples of length n, b,i and d, I now do:
map(lambda bb,ii,dd: bb
I see! It's the
in-place aspect that led me to assume that the assignment to self inside
the method would do the trick. Next the explicit call reinforced the perception.
Anyway, thank you very much for the clarification.
Frederic
> Anthra Norell wrote:>
>> If I am missing a point here, wha
Anthra Norell wrote:
> If I am missing a point here, what could it be?
the documentation?
> class Vertex (list):
>def __init__ (self, *coordinates): self [:] = list (coordinates [0:2])
>def __add__ (self, V): return Vertex (self [X] + V [X], self [Y] + V [Y])
>def __iadd__ (self, V)
Hi!
If I am missing a point here, what could it
be? Watch the hot spots (***)
Frederic
#
# Python 2.4, Windows ME
X = 0, Y = 1
class Vertex (list):
def __init__ (self, *coordinates): self [:]
= l
my image file is only about 5 MB, so, it's not too large.
I've done some testing with PIL and it will meet my needs, I think. I
can see how I could slice and dice my image, or only present the
cropped section that I need.
thanks,
S
--
http://mail.python.org/mailman/listinfo/python-list
Robert Kern wrote:
I use PROJ.4 via pipes for cartographic projections.
http://proj.maptools.org/
There is an addon to the matplotlib plotting library that contains a
binding for the PROJ.4 library, but I haven't gotten it to work on my Mac.
http://matplotlib.sourceforge.net/toolkits.html
Jus
Stewart Midwinter wrote:
I would like to do some image / map manipulation with Python.
I've got a very large map file in .png format. My thought is to chop
it up into small tiles using some method. What Python module would be
helpful for this?
The PIL. I'm not sure how well it handle
I would like to do some image / map manipulation with Python.
I've got a very large map file in .png format. My thought is to chop
it up into small tiles using some method. What Python module would be
helpful for this?
Next, when I obtain the start and end co-ordinates of a user's
In article <[EMAIL PROTECTED]>,
runsun pan <[EMAIL PROTECTED]> wrote:
.
.
.
>Secondly, [x+y for x,y in itertools.izip(xs, ys)] did go much faster
>than map(lambda x,y: x+y, xs, ys). The latter is not only the
Thx, Robert. I did some tests:
>>> xs = range(1)
>>> ys = range(0,2,2)
>>> def m1(x, count=100):
... for c in range(count):
...y = map(float, x)
... return y
>>> def L1(x, count=100):
... for c in range(count):
...y = [f
runsun pan wrote:
I remember reading somewhere that the map, filter, reduce are much
faster than list comp.
It depends.
map(float, some_list_of_numbers)
is going to be faster than
[float(x) for x in some_list_of_numbers]
but
map(lambda x,y: x+y, xs, ys)
is going to be slower than
import
I remember reading somewhere that the map, filter, reduce are much
faster than list comp.
--
http://mail.python.org/mailman/listinfo/python-list
I very much take your point. And thanks: that answers my syntax
question (I think!) -- *and* tells me that I don't care.
Charles Hartman
On Mar 27, 2005, at 2:16 PM, [EMAIL PROTECTED] wrote:
...
>>> simpler == complexities
True
>>>
I've not the glimmer of a clue which would be faster, and don't c
tion(len(x)) for x in lines.split()]
[5, 5, 11, 11, 5, 11, 5, 11]
>>>
I could be missing some edge cases, but it seems to me that if you
have list comps you don't really need map, filter, and the like. The
map portion can be done by nested function applications in the list
comp itse
701 - 800 of 843 matches
Mail list logo
