Steven D'Aprano wrote:

[..]
>
> The 't__' prefix clearly marks the tuple argument as different from the
> others. The use of a double underscore is unusual in naming conventions,
> and thus less likely to clash with other conventions. Python users are
> already trained to distinguish single and double underscores. And while
> it's three characters longer than the current 2to3 behaviour, the length
> compares favorably with the original tuple form:
>
> t__result_flag
> (result, flag)

Let's see what the conversion tool does:

$ cat tmp.py
g = lambda (a, b): a*b + a_b
$ 2to3 tmp.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- tmp.py (original)
+++ tmp.py (refactored)
@@ -1,1 +1,1 @@
-g = lambda (a, b): a*b + a_b
+g = lambda a_b1: a_b1[0]*a_b1[1] + a_b
RefactoringTool: Files that need to be modified:
RefactoringTool: tmp.py

So the current strategy is to add a numerical suffix if a name clash occurs.
The fixer clearly isn't in final state as for functions instead of lambdas
it uses xxx_todo_changeme.

> What do people think? Is it worth taking this to the python-dev list?

I suppose that actual clashes will be rare. If there is no clash a_b is the
best name and I prefer trying it before anything else.
I don't particularly care about what the fallback should be except that I
think it should stand out a bit more than the current numerical prefix.
xxx1_a_b, xxx2_a_b,... maybe?

Peter

Steven D'Aprano wrote:

[..]
>
> The 't__' prefix clearly marks the tuple argument as different from the
> others. The use of a double underscore is unusual in naming conventions,
> and thus less likely to clash with other conventions. Python users are
> already trained to distinguish single and double underscores. And while
> it's three characters longer than the current 2to3 behaviour, the length
> compares favorably with the original tuple form:
>
> t__result_flag
> (result, flag)

Let's see what the conversion tool does:

$ cat tmp.py
g = lambda (a, b): a*b + a_b
$ 2to3 tmp.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- tmp.py (original)
+++ tmp.py (refactored)
@@ -1,1 +1,1 @@
-g = lambda (a, b): a*b + a_b
+g = lambda a_b1: a_b1[0]*a_b1[1] + a_b
RefactoringTool: Files that need to be modified:
RefactoringTool: tmp.py

So the current strategy is to add a numerical suffix if a name clash occurs.
The fixer clearly isn't in final state as for functions instead of lambdas
it uses xxx_todo_changeme.

> What do people think? Is it worth taking this to the python-dev list?

I suppose that actual clashes will be rare. If there is no clash a_b is the
best name and I prefer trying it before anything else.
I don't particularly care about what the fallback should be except that I
think it should stand out a bit more than the current numerical suffix.
xxx1_a_b, xxx2_a_b,... maybe?

Peter

Martin Geisler wrote:
> Steven D'Aprano <steve> writes:

>>> From reading the PEP-3113 I got the impression that the author
>>> thought that this feature was unused and didn't matter.

And that there were good alternatives, and that there were technical
reasons why maintaining the feature in the face of other arguments
options would be a nuisance.

>>> With this I wish to say that it matters to me.
>> Alas, I think it's too late. I feel your pain.
>
> Thanks! And I know it's too late, I should have found out about this
> earlier :-(

For future reference, the time to have said something would have been
during the 3 month alpha phase, which is for testing feature and api
changes. I suspect, from reading the pydev discussion, that the answer
still would have been to either use a def statement and add the unpack
line or to subscript the tuple arg to stick with lambda expressions.
But who knows?

tjr

On Sun, 05 Oct 2008 "Aaron \"Castironpi\" Brady" wrote:

[..]
> pass
>
>To be thorough, there's also a trailing double underscore option.
>
>def function(vocab_list, result_flag__, max_value):
> result, flag = result_flag__
> pass
>
>Which I don't recognize from any other usages, but I defer. If there
>aren't any, conditionally, I think this is my favorite.

t__result_flag and result_flag__t have the advantage that you can
search for t__ or __t as start or end of a name if you want to
find and change all these places in the source. You can compare
it with the decision to use reinterpret_cast<long>(...) as a cast
operator in C++. It is ugly but much easier to find than (long)...
A search for __ alone would have too many hits in Python.

Harald

On Oct 5, 9:13 am, Terry Reedy <tjre> wrote:
> Martin Geisler wrote:
> > Steven D'Aprano <st> writes:
> >>> From reading the PEP-3113 I got the impression that the author
> >>> thought that this feature was unused and didn't matter.
>
> And that there were good alternatives, and that there were technical
> reasons why maintaining the feature in the face of other arguments
> options would be a nuisance.
>

As the author of PEP 3113, I should probably say something (kudos to
Python-URL bringing this thread to my attention).

There are two things to realize about the tuple unpacking that acted
as motivation. One is supporting them in the compiler is a pain.
Granted that is a weak argument that only the core developers like
myself care about.

Second, tuple unpacking in parameters breaks introspection horribly.
All one has to do is look at the hoops 'inspect' has to jump through
in order to figure out what the heck is going on to see how messy this
is. And I realize some people will say, "but if 'inspect' can handle
it, then who cares about the complexity", but that doesn't work if
'inspect' is viewed purely as a simple wrapper so you don't have to
remember some attribute names and not having to actually perform some
major hoops. I personally prefer being able to introspect from the
interpreter prompt without having to reverse-engineer how the heck
code objects deal with tuple unpacking.

>  >>> With this I wish to say that it matters to me.
>

Well, every feature matters to someone. Question is whether it matters
to enough people to warrant having a feature. I brought this up at
PyCon 2006 through a partially botched lightning talk and on python-
dev through the PEP, so this was not some snap decision on my part
that I rammed through python-dev; there was some arguing for keeping
it from some python-dev members, but Guido agreed with me in the end.

If you still hate me you can find me at PyCon 2009 and tar & feather
me *after* my talk. =)

> >> Alas, I think it's too late. I feel your pain.
>
> > Thanks! And I know it's too late, I should have found out about this
> > earlier :-(
>
> For future reference, the time to have said something would have been
> during the 3 month alpha phase, which is for testing feature and api
> changes.  I suspect, from reading the pydev discussion, that the answer
> still would have been to either use a def statement and add the unpack
> line or to subscript the tuple arg to stick with lambda expressions.
> But who knows?

I have not read this whole thread thoroughly, but it sounds like using
iterator unpacking at the call site (e.g., ``fxn(*args)`` when calling
your lambda) is out of the question because it is from a callback?

As Terry said, the alpha is one way you can give feedback if you don't
want to follow python-dev or python-3000 but still have your opinion
be heard. The other way is to subscribe to the PEP news feed (found
off of http://www.python.org/dev/peps/) to keep on top of PEPs as
practically all language changes have to result in a PEP at some
point. And of course the last option is to follow python-dev. =)

-Brett

Brett C.:
> There are two things to realize about the tuple unpacking that acted
> as motivation. One is supporting them in the compiler is a pain.
> ...
> Second, tuple unpacking in parameters breaks introspection horribly.

Are there ways to re-implement from scratch similar native pattern-
matching features in CPython, like ones of Closure:
http://items.sjbach.com/16/some-notes-about-clojure
Or better ones of Scala, (or even OcaML, but those are static), etc,
that avoid that pain and introspection troubles?

Bye,
bearophile

On Sun, 05 Oct 2008 17:15:27 +0200, Peter Otten wrote:

[..]
> So the current strategy is to add a numerical suffix if a name clash
> occurs. The fixer clearly isn't in final state as for functions instead
> of lambdas it uses xxx_todo_changeme.
>> I suppose that actual clashes will be rare. If there is no clash a_b is
> the best name and I prefer trying it before anything else. I don't
> particularly care about what the fallback should be except that I think
> it should stand out a bit more than the current numerical suffix.
> xxx1_a_b, xxx2_a_b,... maybe?


Possibly you have misunderstood me. I'm not concerned with a clash
between names, as in the following:

lambda a_b, (a, b):
maps to -> lambda a_b, a_b:

as I too expect they will be rare, and best handled by whatever mechanism
the fixer users to fix any other naming clash.

I am talking about a clash between *conventions*, where there could be
many argument names of the form a_b which are not intended to be two item
tuples.

In Python 2.x, when you see the function signature

def spam(x, (a, b))

it is clear and obvious that you have to pass a two-item tuple as the
second argument. But after rewriting it to spam(x, a_b) there is no such
help. There is no convention in Python that says "when you see a function
argument of the form a_b, you need to pass two items" (nor should there
be).

But given the deafening silence on this question, clearly other people
don't care much about misleading argument names.

*wink*

On Oct 11, 8:23 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
[..]
> second argument. But after rewriting it to spam(x, a_b) there is no such
> help. There is no convention in Python that says "when you see a function
> argument of the form a_b, you need to pass two items" (nor should there
> be).
>
> But given the deafening silence on this question, clearly other people
> don't care much about misleading argument names.
>
> *wink*
>
Could it be a double underscore instead, eg a__b,
first_item__second_item?

On Oct 11, 2:23 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
snip
> I am talking about a clash between *conventions*, where there could be
> many argument names of the form a_b which are not intended to be two item
> tuples.
>
> In Python 2.x, when you see the function signature
>
> def spam(x, (a, b))
>
> it is clear and obvious that you have to pass a two-item tuple as the
> second argument. But after rewriting it to spam(x, a_b) there is no such
> help. There is no convention in Python that says "when you see a function
> argument of the form a_b, you need to pass two items" (nor should there
> be).
>
> But given the deafening silence on this question, clearly other people
> don't care much about misleading argument names.

No, we just document them. (ducks) And ambiguous is different from
misleading anyway. If the docs say pass a 2-tuple as the 2nd
parameter...?