Lambda going out of fashion

S

Steve Holden

Aahz said:
For me, it works the other way around, but I can see how you perceive it
that way.




Okay, it wasn't clear in your original post that you're still stuck with
1.5.2. That makes a huge difference in the convenience of newer
features.
I haven't corresponded specifically with Fredrik about this, bit I get
the impression he *chooses* to continue to produce 1.5.2-compatible
products. I for one, having suffered at the hands of modules that
*claim* 1.5.2 compatibility (and then screw you by using dict()!),
appreciate the time he takes to do so.

A summary of how to maintain such compatibility might make Python apps
more accessible - how many of us can say that our code would run on a
Red Hat 7 system any more? The sad thing is that it's often fairly
trivial changes that remove backwards-compatibility.Well, I guess we have to accept that not every change to the language is
going to be well-thought-out and completely desirable.
While I'm in complete agreement about the "".join() construct on the
basis of looks, I have come to appreciate the fact that I *never* mess up
the order of arguments any more.

Personally that's one of the changes I managed to take in my stride, and
I've never really felt it was a biggie. Maybe my code is just so ugly
that a little extra ugliness isn't noticeable?

horses-for-courses-ly y'rs - steve
 
C

Cameron Laird

True! So, personally, I'd rather code, e.g.,

def bools(lst): return map(bool, lst)

rather than breal this one-liner into two lines at the colon, as per
standard Python style. However, uniformity has its advantages, too; I'm
ready for the one-liner style to be outlawed in Python 3.0, purely in
the advantage of uniformity.

Note that lambda is utterly useless here, be it for one-liners or not.
.
.
.
Please say that last sentence another way. I *think* you mean
that to define (def) a non-pathologic named function, lambda
provides no advantage; one sacrifices no expressivity by a
restriction to def-s. Is that right?
 
C

Cameron Laird

.
.
.
IMO the reference behaviour of functions in the C API could be
clearer. One often has to simply know, or refer to the docs, to tell
whether a particular call steals a reference or is reference neutral.
Take, for example, PyDict_SetItemString vs PyMapping_SetItemString . Is
it obvious that one of those steals a reference, and one is reference
neutral? Is there any obvious rationale behind this? I'm not overflowing
with useful suggestions about this, but I do think it'd be nice if there
was a way to more easily tell how functions behave in regard to
reference counts.
.
.
.
This is a sensitive area for me, too. I'd welcome insight
on how to think about this. If Pythonia were a better place
in this regard, how would it be? Reference documents that
more transparently define reference behavior? A convention
for API names that reveals reference characteristics? Is
there someone who's confident with Python use through C that
has a reliable process for getting reference counts right?
 
C

Craig Ringer

.
.
.
IMO the reference behaviour of functions in the C API could be
clearer. [snip] .
.
.
This is a sensitive area for me, too. I'd welcome insight
on how to think about this. If Pythonia were a better place
in this regard, how would it be? Reference documents that
more transparently define reference behavior?

I think the current documentation does a fairly good job of that when
describing how to treat the return values of the various functions, but
a much poorer one when covering their arguments.
A convention for API names that reveals reference characteristics?

That is what I'd lean towards personally... but of course there's
duplication and compatibility to be considered.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top