Edvard Majakari wrote:
> Simon Brunning <[EMAIL PROTECTED]> writes:
>
>>http://wiki.python.org/moin/PythonDecoratorLibrary?#head-de01988728ccdec415708f10928cc6feb022e7bb
>
> Neat.
>
> I guess about 75% about programming-related things classified as neat-o or
> "convenient!" are already implement
Mike Meyer wrote:
> "Shai" <[EMAIL PROTECTED]> writes:
>
> > They're called "Special vars", and you need to define them (unlike
> > local LISP variables, which behave essentially like Python vars), but
> > then you use them just like other vars (that is, you usually bind them
> > with LET). This is
Simon Brunning <[EMAIL PROTECTED]> writes:
> http://wiki.python.org/moin/PythonDecoratorLibrary?#head-de01988728ccdec415708f10928cc6feb022e7bb
Neat.
I guess about 75% about programming-related things classified as neat-o or
"convenient!" are already implemented by some Pythonista(s). Spoils all
"Shai" <[EMAIL PROTECTED]> writes:
> They're called "Special vars", and you need to define them (unlike
> local LISP variables, which behave essentially like Python vars), but
> then you use them just like other vars (that is, you usually bind them
> with LET). This is the first I hear about them
I only saw this today... sorry about the late response. Anyway,
replying to your two messages at once:
Mike Meyer wrote:
> Last time I checked, dynamic binding variables were frowned on in LISP
> systems as well. Scheme doesn't have them. Common LISP requires
> special forms to use them.
They'r
On 7/6/05, Edvard Majakari <[EMAIL PROTECTED]> wrote:
> Ability to tag some methods 'deprecated' as in Java (from 1.5
> onwards?). However, Python interpreter doesn't have to do it: pydoc and
> similar tools could detect, say, '@deprecated' in method comment string and
> warn user about it.
http:/
Thomas Heller <[EMAIL PROTECTED]> writes:
> I don't see what's wrong with this code, and if one wanted, one could
> also implement a decorator which calls warnings.warn when the function
> is called:
>
> def c_buffer(init, size=None):
> "deprecated, use create_string_buffer instead"
> impo
Edvard Majakari <[EMAIL PROTECTED]> writes:
> (sorry, my NUA had lost the original article)
>>
>>> I'm curious -- what is everyone's favorite trick from a non-python
>>> language? And -- why isn't it in Python?
>
> Ability to tag some methods 'deprecated' as in Java (from 1.5
> onwards?). However,
(sorry, my NUA had lost the original article)
>
>> I'm curious -- what is everyone's favorite trick from a non-python
>> language? And -- why isn't it in Python?
Ability to tag some methods 'deprecated' as in Java (from 1.5
onwards?). However, Python interpreter doesn't have to do it: pydoc and
s
Okay, maybe that was too restrictive, reduce can *usually* be replaced
with sum. Sorry about that.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 03 Jul 2005 15:40:38 -0500, Rocco Moretti <[EMAIL PROTECTED]> wrote:
>Jp Calderone wrote:
>> On Fri, 01 Jul 2005 15:02:10 -0500, Rocco Moretti
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I'm not aware of a language that allows it, but recently I've found
>>> myself wanting the ability to trans
Jp Calderone wrote:
> On Fri, 01 Jul 2005 15:02:10 -0500, Rocco Moretti
> <[EMAIL PROTECTED]> wrote:
>
>>
>> I'm not aware of a language that allows it, but recently I've found
>> myself wanting the ability to transparently replace objects.
>
>
> Smalltalk supports this with the "become" messa
Steven D'Aprano wrote:
> On Sun, 03 Jul 2005 00:39:19 -0400, Christopher Subich wrote:
>>Personally, I think demanding that it be writable as a sum (or product,
>>or any, or all) is a false standard -- nobody's claimed that these would
>>replace all cases of reduce, just the most common ones.
>
Steven D'Aprano wrote:
> How do you replace:
>
> reduce(lambda x,y: x*y-1/y, sequence)
>
> with sum?
missing = object()
def my_reduce(f, items, first=missing):
class adder:
def __init__(self, value):
self.value = value
def __add__(self, other):
retu
On Sun, 03 Jul 2005 00:39:19 -0400, Christopher Subich wrote:
> Devan L wrote:
>> sum(sequence[0] + [1/element for element in sequence[1:]])
>>
>> I think that should work.
>
> That won't work, because it misses the x*y part of the expression
> (x[n]*x[n+1] + 1/x[n+1], for people who haven't im
Steven D'Aprano wrote:
> On Fri, 24 Jun 2005 14:29:37 -0700, James wrote:
>
> > Interesting thread ...
> >
> > 1.) Language support for ranges as in Ada/Pascal/Ruby
> > 1..10 rather than range(1, 10)
>
> What advantages do Pascal-like for loops give over Python for loops?
>
> The only two I can thi
Devan L wrote:
> sum(sequence[0] + [1/element for element in sequence[1:]])
>
> I think that should work.
That won't work, because it misses the x*y part of the expression
(x[n]*x[n+1] + 1/x[n+1], for people who haven't immediately read the
grandparent).
Personally, I think demanding that it b
sum(sequence[0] + [1/element for element in sequence[1:]])
I think that should work.
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
> On Fri, 01 Jul 2005 12:24:44 -0700, Devan L wrote:
>
>
>>With the exception of reduce(lambda x,y:x*y, sequence), reduce can be
>>replaced with sum, and Guido wants to add a product function.
>
>
> How do you replace:
>
> reduce(lambda x,y: x*y-1/y, sequence)
>
> with
On Fri, 01 Jul 2005 12:24:44 -0700, Devan L wrote:
> With the exception of reduce(lambda x,y:x*y, sequence), reduce can be
> replaced with sum, and Guido wants to add a product function.
How do you replace:
reduce(lambda x,y: x*y-1/y, sequence)
with sum?
Inquiring minds want to know.
--
S
Scott David Daniels <[EMAIL PROTECTED]> writes:
> Rocco Moretti wrote:
>> Joseph Garvin wrote:
>>
>> I'm not aware of a language that allows it, but recently I've found
>> myself wanting the ability to transparently replace objects
>> I mainly look for it in the "object replaces self" form, bu
"Devan L" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> With the exception of reduce(lambda x,y:x*y, sequence), reduce can be
> replaced with sum, and Guido wants to add a product function.
The update function is not at all limited to sums and products, but can be
any callable w
I like C++ templates so that you can ensure that a list only contain
items of one type. I also like the JMP instruction in x86 assembler,
you could do some nasty tricks with that.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
[Lots of quoted text left in...]
I started thinking about this, and realized that there was a way to do
what you wanted, with no execution time overhead, and without
providing ways to radically change the program behavior behind the
scenes.
Mike Meyer <[EMAIL PROTECTED]> writes:
> "Shai" <[EMAIL
My personal favorite would be ruby's iterators and blocks.
Instead of writing a bunch of repetitive list comprehensions or
defining a bunch of utility functions, you just use the iterators
supported by container objects.
For instance,
[f(x) for x in y]
could be written in Ruby as
y.collect |x| d
"Shai" <[EMAIL PROTECTED]> writes:
> Joseph Garvin wrote:
>>
>> I'm curious -- what is everyone's favorite trick from a non-python
>> language? And -- why isn't it in Python?
>
> 1. Lisp's "dynamically scoped" variables (Perl has them, and calls them
> "local", but as far as I've seen their use th
Rocco Moretti wrote:
> Joseph Garvin wrote:
>
> I'm not aware of a language that allows it, but recently I've found
> myself wanting the ability to transparently replace objects
> I mainly look for it in the "object replaces self" form, but I guess you
> could also have it for arbitrary objec
On Fri, 01 Jul 2005 15:02:10 -0500, Rocco Moretti <[EMAIL PROTECTED]> wrote:
>Joseph Garvin wrote:
>
>> I'm curious -- what is everyone's favorite trick from a non-python
>> language? And -- why isn't it in Python?
>
>I'm not aware of a language that allows it, but recently I've found
>myself wanti
Joseph Garvin wrote:
>
> I'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
>
1. Lisp's "dynamically scoped" variables (Perl has them, and calls them
"local", but as far as I've seen their use their is discouraged). These
are global variab
Joseph Garvin wrote:
> I'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
I'm not aware of a language that allows it, but recently I've found
myself wanting the ability to transparently replace objects. For
example, if you have a trans
On Fri, 24 Jun 2005 21:17:09 GMT, rumours say that Ron Adam
<[EMAIL PROTECTED]> might have written:
>I think some sort of inline or deferred local statement would be useful
>also. It would serve as a limited lambda (after it's removed), eval
>alternative, and as a inlined function in some situa
With the exception of reduce(lambda x,y:x*y, sequence), reduce can be
replaced with sum, and Guido wants to add a product function.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>, Joseph Garvin wrote:
>I'm curious -- what is everyone's favorite trick from a non-python
>language? And -- why isn't it in Python?
>
Being able to use my native language without a hitch when naming my
variables &c. Java allows that because it supports almost any
Sorry, I realized that shortly after my post =X
--
http://mail.python.org/mailman/listinfo/python-list
ncf wrote:
> Eh, just figured it'd be worth noting...map, filter, and reduce should
> be possible with the extended list syntaxes. Well, filter I know is,
> but hte others /should/ be possible.
>
> filter(lambda: <>, <>)
> [some_var for some_var in <> if <>]
reduce isn't.
--
Erik Max Francis &
Hmm...I think it's time I do better justice to what I previously wrote.
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
The above article was linked by Python's PEP...
--
http://mail.python.org/mailman/listinfo/python-list
Eh, just figured it'd be worth noting...map, filter, and reduce should
be possible with the extended list syntaxes. Well, filter I know is,
but hte others /should/ be possible.
filter(lambda: <>, <>)
[some_var for some_var in <> if <>]
Honestly, though, I hope they don't drop the map functions a
On Thursday 30 June 2005 10:21 am, [EMAIL PROTECTED] wrote:
> If I had to choose one feature, I would like to see better support for
> nested lexical scopes. However, I imagine this is no easy "trick" to
> add to the language.
Doesn't that already happen in versions 2.2+?
What exactly do you mea
"Paddy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Sadly, its not a solution that I'm after, but a particular toolkit that
> can be used for solving that type of problem.
Presuming this is an anwer to my comment about generators... I was pointing
you more to the method used t
If I had to choose one feature, I would like to see better support for
nested lexical scopes. However, I imagine this is no easy "trick" to
add to the language.
> I'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
--
http://mail.python.
Terry Hancock wrote:
> http://www.logilab.org/projects/python-logic/
> This is something pretty new to me, so I can't comment on how well
> it would meet your expectations, but I see now that the site does mention
> OZ/Mozart as comparables.
I've used both, the logilab stuff is cool, but no where
Steven D'Aprano wrote:
> with colour do begin
> red := 0; blue := 255; green := 0;
> end;
>
> instead of:
>
> colour.red := 0; colour.blue := 255; colour.green := 0;
c = colour
c.red = 0; c.blue = 255; c.green = 0
del c # Not strictly needed, but limits the scope of c
When everything's a referenc
On Wednesday 29 June 2005 10:51 pm, Paddy wrote:
> Joseph Garvin wrote:
> 'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
>
> I use constraints programming at work, Check out "System Verilog" or
> OZ/Mozart.
>
> It would be great i
Joseph Garvin <[EMAIL PROTECTED]> writes:
> I'm curious -- what is everyone's favorite trick from a non-python
> language?
Metapost solution of linear equations:
x1+9=x2-8=2;
> And -- why isn't it in Python?
I'd like to know too.
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu
Sadly, its not a solution that I'm after, but a particular toolkit that
can be used for solving that type of problem.
- Pad.
--
http://mail.python.org/mailman/listinfo/python-list
"Paddy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The OZ homepage has an example for solving the eight queens problem:
Buried in the generator test module (something like
lib/test/test_generators.py) are solutions for both 8Queens and Knight's
Tour. You might find these of
Joseph Garvin wrote:
'm curious -- what is everyone's favorite trick from a non-python
language? And -- why isn't it in Python?
I use constraints programming at work, Check out "System Verilog" or
OZ/Mozart.
It would be great if this style of programming could be added to
Python.
It is a de
Sun, 26 Jun 2005 08:35:58 +0200 skrev Peter Otten:
> Steven D'Aprano wrote:
>
>> On Sat, 25 Jun 2005 21:30:26 +0200, Peter Otten wrote:
>>
>>> Mandus wrote:
>>>
By using the builtin reduce, I
move the for-loop into the c-code which performs better.
>>>
>>> No. There is no hope of ever
Hi All--
Mike Meyer wrote:
>
> Since the user is the one bound with B&D languages, they are clearly
> tops. Which makes Python a bottom.
>
Well, we certainly hope Python has a safe word.
Metta,
Ivan
--
Ivan Van Laningham
God N Locomotive Works
http:/
Tom Anderson <[EMAIL PROTECTED]> writes:
> On Fri, 24 Jun 2005, Roy Smith wrote:
>> Tom Anderson <[EMAIL PROTECTED]> wrote:
>>> The one thing i really do miss is method overloading by parameter
>>> type. I used this all the time in java
>> You do things like that in type-bondage languages
> I love
> if a.value == True:
> return a
> if not database.connect == error:
> database.query(q)
Yeah, yeah, I know that :-)
What I mean is that most of the time I find the code more "readable" (I
know that more readable code ain't better code, but it helps when you
work with other people...).
>
On 24 Jun 2005 19:09:05 +0400, Sergei Organov <[EMAIL PROTECTED]> wrote:
>Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
>> On Fri, 24 Jun 2005 00:55:38 -0600, Joseph Garvin wrote:
>>
>> > I'm curious -- what is everyone's favorite trick from a non-python
>> > language? And -- why isn't it in Pyt
[Terry Hancock]
> Probably the most pointless Python wart, I would think. The =/==
> distinction makes sense in C, but since Python doesn't allow assignments
> in expressions, I don't think there is any situation in which the distinction
> is needed. Python could easily figure out whether you mean
Steven D'Aprano wrote:
> On Sun, 26 Jun 2005 23:22:00 -0500, Terry Hancock wrote:
>
>>>You need to differentiate
>>> a = b = 1
>>>from
>>> a = b == 1
>>
>>Okay, I see what you mean. I can't ever recall having needed the
>>second form, though.
>>
>>Of course, you could still do assignment like
On Sun, 26 Jun 2005 23:22:00 -0500, Terry Hancock wrote:
>> You need to differentiate
>>a = b = 1
>> from
>>a = b == 1
>
> Okay, I see what you mean. I can't ever recall having needed the
> second form, though.
>
> Of course, you could still do assignment like this:
>
> a, b = (1,)*2
>
Terry Hancock wrote:
> On Sunday 26 June 2005 06:11 am, Robert Kern wrote:
>
>>Terry Hancock wrote:
>>
>>>On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:
>>>
However, then you must forbid a=b=1 for assigning to two variables
at the same time.
>>
>>You need to differentiate
>> a =
On Sunday 26 June 2005 06:11 am, Robert Kern wrote:
> Terry Hancock wrote:
> > On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:
> >>However, then you must forbid a=b=1 for assigning to two variables
> >>at the same time.
>
> You need to differentiate
>a = b = 1
> from
>a = b == 1
O
On Sun, 26 Jun 2005 14:36:42 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 25 Jun 2005 23:08:10 +, Bengt Richter wrote:
>
>>>Using := and = for assignment and equality is precisely as stupid as using
>>>= and == for assignment and equality. Perhaps less stupid: why do we use
>>>==
On Sun, 26 Jun 2005 14:30:15 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 25 Jun 2005 23:08:10 +, Bengt Richter wrote:
>
[...]
>>
>> The single line replacing
>> """
>> with colour do begin
>> red := 0; blue := 255; green := 0;
>> end;
>> """
>> follows:
< "return a if a.value == true"
< "database.query(q) unless database.connect == error
(etc)
if a.value == True:
return a
if not database.connect == error:
database.query(q)
Trading two words for one word doesn't necessarily make the code
better.
< unless false then print 1 # this prints
> I'm curious -- what is everyone's favorite trick from a non-python
> language? And -- why isn't it in Python?
Hmm... I used to be quite the fan of Python, yet not long ago I met
Ruby and fell in love almost instantly. Some of the features I like the
most:
- statement modifiers:
< "return a if
"Konstantin Veretennicov" <[EMAIL PROTECTED]> wrote:
> > On 25 Jun 2005 12:17:20 -0700, George Sakkis <[EMAIL PROTECTED]> wrote:
> > If they go to itertools, they can simply be:
> >
> > def map(f, *iterables):
> > return list(imap(f,*iterables))
> >
> > def filter(f, seq):
> > return list(
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Using := and = for assignment and equality is precisely as stupid as using
> = and == for assignment and equality.
On the other hand, == is easier to type than := (two taps on the same key
vs two different keys, and at least on a US/English keyboard, n
Terry Hancock wrote:
> On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:
>
>>Hallöchen!
>>However, then you must forbid a=b=1 for assigning to two variables
>>at the same time.
>
> Why? It's already handled as an exception in the syntax.
>
> In C, what you say makes sense, because "b=1" i
On Sunday 26 June 2005 05:39 am, Torsten Bronger wrote:
> Hallöchen!
> However, then you must forbid a=b=1 for assigning to two variables
> at the same time.
Why? It's already handled as an exception in the syntax.
In C, what you say makes sense, because "b=1" is an expression as
well as an assi
Hallöchen!
Terry Hancock <[EMAIL PROTECTED]> writes:
> [...]
>
> BASIC did it that way, IIRC.
Right.
> [...]
>
> I don't think Python's use of "==" has *ever* helped me find a
> bug, it just creates them. I really think "=" ought to be
> accepted as well, and "==" deprecated.
However, then yo
On Saturday 25 June 2005 01:08 pm, Steven D'Aprano wrote:
> Using := and = for assignment and equality is precisely as stupid as using
> = and == for assignment and equality. Perhaps less stupid: why do we use
> == for equals, but not ++ for plus and -- for minus?
Probably the most pointless Pytho
On 25 Jun 2005 12:17:20 -0700, George Sakkis <[EMAIL PROTECTED]> wrote:
> If they go to itertools, they can simply be:
>
> def map(f, *iterables):
> return list(imap(f,*iterables))
>
> def filter(f, seq):
> return list(ifilter(f,seq))
>>> from itertools import ifilter
>>> def filter(f, s
Steven D'Aprano wrote:
> On Sat, 25 Jun 2005 21:30:26 +0200, Peter Otten wrote:
>
>> Mandus wrote:
>>
>>> By using the builtin reduce, I
>>> move the for-loop into the c-code which performs better.
>>
>> No. There is no hope of ever writing fast code when you do not actually
>> measure its perf
On Sat, 25 Jun 2005 23:08:10 +, Bengt Richter wrote:
>>Using := and = for assignment and equality is precisely as stupid as using
>>= and == for assignment and equality. Perhaps less stupid: why do we use
>>== for equals, but not ++ for plus and -- for minus?
>>
> I agree, but I think := would
On Sat, 25 Jun 2005 23:08:10 +, Bengt Richter wrote:
> On Sun, 26 Jun 2005 04:08:31 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>>On Fri, 24 Jun 2005 15:47:45 -0700, James Stroud wrote:
>>
>>> On Friday 24 June 2005 05:58 am, Steven D'Aprano wrote:
with colour do begin
red :
On Sat, 25 Jun 2005 18:44:12 -0700, James Stroud wrote:
> On Saturday 25 June 2005 11:08 am, Steven D'Aprano wrote:
>> The problem is, you have made colour (returning to English spelling
>> instead of foreign) into a class. If you need two colour variables, you
>> have to duplicate the code for th
On Saturday 25 June 2005 06:44 pm, James Stroud wrote:
> I thought they were
> pointless 18 years ago when I learned pascal in highschool and after 20
> years, I still think they are still pointless.
I think that fails "==".
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 9515
On Sat, 25 Jun 2005 23:19:48 +0200, Peter Otten wrote:
> Python is more about readability than raw speed, and I prefer a for-loop
> over reduce() in that respect, too.
Fascinating. I prefer reduce for readability. "Reduce this list to one
value, using this known behaviour" seems to work for me b
On Sat, 25 Jun 2005 13:31:19 -0700, Robert Kern wrote:
> Of course, in a Python 3000 world, nothing stops anyone from using their
> own extension module implementing map, filter, and reduce if they really
> want to. TSBOOOWTDI in the language/stdlib, but it shouldn't stop anyone
> from using ot
On Sat, 25 Jun 2005 21:30:26 +0200, Peter Otten wrote:
> Mandus wrote:
>
>> By using the builtin reduce, I
>> move the for-loop into the c-code which performs better.
>
> No. There is no hope of ever writing fast code when you do not actually
> measure its performance.
Good grief! You've been
On Saturday 25 June 2005 11:08 am, Steven D'Aprano wrote:
> The problem is, you have made colour (returning to English spelling
> instead of foreign) into a class. If you need two colour variables, you
> have to duplicate the code for the class (perhaps only changing the
> numeric constants. You
On Sat, 25 Jun 2005 15:44:14 -0400, Nicolas Fleury wrote:
> Steven D'Aprano wrote:
>> One of the things I liked in Pascal was the "with" keyword. You could
>> write something like this:
>>
>> with colour do begin
>> red := 0; blue := 255; green := 0;
>> end;
>>
>> instead of:
>>
>> colour.red :
"Mandus" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fri, 24 Jun 2005 16:31:08 +0100 skrev Tom Anderson:
>> On Fri, 24 Jun 2005, Joseph Garvin wrote:
>> Higher-order functions like map, filter and reduce. As of Python 3000,
>> they're non-python tricks. Sigh - i guess it's time
On Sat, 25 Jun 2005 19:23:18 +, Mandus wrote:
> Sat, 25 Jun 2005 16:06:57 GMT skrev Lee Harr:
Higher-order functions like map, filter and reduce. As of Python 3000,
they're non-python tricks. Sigh - i guess it's time for me to get to know
list comprehensions a bit better.
On Sun, 26 Jun 2005 04:08:31 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Fri, 24 Jun 2005 15:47:45 -0700, James Stroud wrote:
>
>> On Friday 24 June 2005 05:58 am, Steven D'Aprano wrote:
>>> with colour do begin
>>> red := 0; blue := 255; green := 0;
>>> end;
>>>
>>> instead of:
>>>
>>>
Mandus wrote:
> 25 Jun 2005 13:15:16 -0700 skrev Devan L:
>> But by using the builtin reduce, you need to specify a function, which
>> probably slows it down more than any speed-up from the loop in C.
>
> Sounds reasonable, but not always the case, especially when dealing with
> numpy arrays. At
Devan L wrote:
> But by using the builtin reduce, you need to specify a function, which
> probably slows it down more than any speed-up from the loop in C.
Not if the function is from an extension module. For some applications,
this can be quite common.
Of course, in a Python 3000 world, nothing
25 Jun 2005 13:15:16 -0700 skrev Devan L:
> But by using the builtin reduce, you need to specify a function, which
> probably slows it down more than any speed-up from the loop in C.
Sounds reasonable, but not always the case, especially when dealing with
numpy arrays. At least that what some of m
But by using the builtin reduce, you need to specify a function, which
probably slows it down more than any speed-up from the loop in C.
--
http://mail.python.org/mailman/listinfo/python-list
Sat, 25 Jun 2005 21:30:26 +0200 skrev Peter Otten:
> Mandus wrote:
>
>> By using the builtin reduce, I
>> move the for-loop into the c-code which performs better.
>
> No. There is no hope of ever writing fast code when you do not actually
> measure its performance.
I do.
--
Mandus - the only man
Steven D'Aprano wrote:
> One of the things I liked in Pascal was the "with" keyword. You could
> write something like this:
>
> with colour do begin
> red := 0; blue := 255; green := 0;
> end;
>
> instead of:
>
> colour.red := 0; colour.blue := 255; colour.green := 0;
>
> Okay, so maybe it is m
Mandus wrote:
> By using the builtin reduce, I
> move the for-loop into the c-code which performs better.
No. There is no hope of ever writing fast code when you do not actually
measure its performance.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Why overload when you can use class methods?
--
http://mail.python.org/mailman/listinfo/python-list
Sat, 25 Jun 2005 16:06:57 GMT skrev Lee Harr:
>>> Higher-order functions like map, filter and reduce. As of Python 3000,
>>> they're non-python tricks. Sigh - i guess it's time for me to get to know
>>> list comprehensions a bit better.
>>>
>
>
> Couldnt there just be a "functional" module ?...
>
Sun, 26 Jun 2005 04:36:51 +1000 skrev Steven D'Aprano:
> On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:
>
>> On 6/25/05, Mandus <[EMAIL PROTECTED]> wrote:
>>> It is really a consensus on this; that
>>> removing map, filter, reduce is a good thing? It will render a whole lot
>>>
"Konstantin Veretennicov" <[EMAIL PROTECTED]> wrote:
> On 6/25/05, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:
> >
> > > On 6/25/05, Mandus <[EMAIL PROTECTED]> wrote:
> > >> It is really a consensus on this; that
> > >> removing
On Sat, 25 Jun 2005, Konstantin Veretennicov wrote:
> On 6/25/05, Mandus <[EMAIL PROTECTED]> wrote:
>
>> It is really a consensus on this; that removing map, filter, reduce is
>> a good thing? It will render a whole lot of my software unusable :(
>
> I think you'll be able to use "from __past__ i
On Fri, 24 Jun 2005, Roy Smith wrote:
> Tom Anderson <[EMAIL PROTECTED]> wrote:
>
>> The one thing i really do miss is method overloading by parameter type.
>> I used this all the time in java
>
> You do things like that in type-bondage languages
I love that expression. I think it started out a
On 6/25/05, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:
>
> > On 6/25/05, Mandus <[EMAIL PROTECTED]> wrote:
> >> It is really a consensus on this; that
> >> removing map, filter, reduce is a good thing? It will render a whole lot
On Sat, 25 Jun 2005 17:41:58 +0200, Konstantin Veretennicov wrote:
> On 6/25/05, Mandus <[EMAIL PROTECTED]> wrote:
>> It is really a consensus on this; that
>> removing map, filter, reduce is a good thing? It will render a whole lot
>> of my software unusable :(
>
> I think you'll be able to use
On 6/25/05, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Fri, 24 Jun 2005 14:29:37 -0700, James wrote:
> > 2.) Contracts
>
> Explain please.
James probably meant Eiffel's Design by Contract. My favourite Python
implementation is Terence Way's http://www.wayforward.net/pycontract/
;-)
- kv
--
On Fri, 24 Jun 2005 15:47:45 -0700, James Stroud wrote:
> On Friday 24 June 2005 05:58 am, Steven D'Aprano wrote:
>> with colour do begin
>> red := 0; blue := 255; green := 0;
>> end;
>>
>> instead of:
>>
>> colour.red := 0; colour.blue := 255; colour.green := 0;
>>
>> Okay, so maybe it is more of
On Fri, 24 Jun 2005 14:29:37 -0700, James wrote:
> Interesting thread ...
>
> 1.) Language support for ranges as in Ada/Pascal/Ruby
> 1..10 rather than range(1, 10)
What advantages do Pascal-like for loops give over Python for loops?
The only two I can think of are trivial:
(1) the Pascal-like
>> Higher-order functions like map, filter and reduce. As of Python 3000,
>> they're non-python tricks. Sigh - i guess it's time for me to get to know
>> list comprehensions a bit better.
>>
Couldnt there just be a "functional" module ?...
from functional import map, filter, reduce
--
http://
1 - 100 of 143 matches
Mail list logo
