[Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Mark Dickinson 
I suspect I've missed the boat on this one (certainly for 3.3.0), but
here goes.  The new TypeError reporting for bad function calls is a
huge improvement (thanks Benjamin!), but I have one small nitpick:
what *is* a positional argument?  For example:

>>> def f(x): pass
...
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() missing 1 required positional argument: 'x'

I think it's confusing to describe 'x' as a positional argument.  It's
a required formal parameter, certainly.  But a caller of 'f' could
pass 'x' either by position or by 'keyword'.


When running training (generally Python 2.6 or 2.7 based), I
frequently have to devote some time to unravelling student confusion
between 'arguments passed by keyword' on one hand and 'optional formal
parameters' on the other.  The outline of the explanation goes
something like:

(0) Preamble: be careful to separate out details of function calling
from those of function definition; distinguish formal parameters from
actual arguments.
(1) On the function *definition* side, formal parameters may be either
*required* or *optional*.
(2) On the function *calling* side, actual arguments may be passed
either positionally or by keyword.
(3) The notions in (1) and (2) are entirely orthogonal!
(3a) (Although in practice, callers tend to use pass-by-keyword for
optional formal parameters.)

That's all for Python 2;  Python 3, of course, requires a bit more
explanation related to the keyword-only arguments.

There already seems to be a fair amount of confusion in the Python
world about point (3);  I've seen professional Python training slides
that show how to define optional formal parameters under the heading
"keyword arguments".

I submit that the word 'positional' in the TypeError message
exacerbates this confusion, and that little would be lost by simply
dropping it from the exception message.

Thoughts?

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Nick Coghlan 
On Thu, Sep 20, 2012 at 9:56 PM, Mark Dickinson  wrote:
> I submit that the word 'positional' in the TypeError message
> exacerbates this confusion, and that little would be lost by simply
> dropping it from the exception message.

+1 for using the unqualified "argument" in these error messages to
mean "positional or keyword argument" (inspect.Parameter spells it out
as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
an error message).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Mark Dickinson 
On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan  wrote:
> +1 for using the unqualified "argument" in these error messages to
> mean "positional or keyword argument" (inspect.Parameter spells it out
> as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
> an error message).

Ah yes;  I see that 'positional or keyword' is a more accurate term
(but agree it's unwieldy for an error message).  I also see that I was
naive to think that the 'fix' is as simple as dropping the word
'positional':

>>> def f(a, *, b):
... pass
...
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() missing 1 required positional argument: 'a'

If the word 'positional' were dropped here, it would give the
incorrect impression that f only requires one argument.

Perhaps this simply isn't worth worrying about, especially since the
current error messages are all but certain to make it into the 3.3
release.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Nick Coghlan 
On Thu, Sep 20, 2012 at 10:59 PM, Mark Dickinson  wrote:
> Perhaps this simply isn't worth worrying about, especially since the
> current error messages are all but certain to make it into the 3.3
> release.

No "all but" about it at this point - the earliest they could change
again is 3.3.1. Hopefully the new signature inspection support will
help explain some of the intricacies of binding argument values to
parameter names :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Benjamin Peterson 
2012/9/20 Mark Dickinson :
> Thoughts?

I tried to define the error messages in terms of the callee's
signature. I call the formals that are not variadic, keyword variadic,
or keyword-only, positional. For example, in

def f(a, b, c, *args, d):
 pass

a, b, and c are positional. Hence the "positional" in error messages.

As you noted in your next message, keyword-only arguments need to be
distinguished from these "positional" arguments somehow. Maybe it
helps to think of "positional" to mean "the only formals you can pass
to with position" (excepting variadic ones).

I'm certainly open to suggestions.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Chris Jerdonek 
On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson  wrote:
> def f(a, b, c, *args, d):
>  pass
>
> a, b, and c are positional. Hence the "positional" in error messages.
>
> As you noted in your next message, keyword-only arguments need to be
> distinguished from these "positional" arguments somehow. Maybe it
> helps to think of "positional" to mean "the only formals you can pass
> to with position" (excepting variadic ones).

That is how I think of "positional".

However, the other wrinkle is that some arguments really are
"position-only," for example:

>>> len(s="abc")
Traceback (most recent call last):
 ...
TypeError: len() takes no keyword arguments

I think it is a defect of our documentation that we don't have a way
to distinguish between "positional" and "position-only" arguments in
the function signature notation we use in our documentation, leading
to issues like this one:

"accept keyword arguments on most base type methods and builtins":

http://bugs.python.org/issue8706

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Antoine Pitrou 
On Thu, 20 Sep 2012 10:12:04 -0400
Benjamin Peterson  wrote:
> 2012/9/20 Mark Dickinson :
> > Thoughts?
> 
> I tried to define the error messages in terms of the callee's
> signature. I call the formals that are not variadic, keyword variadic,
> or keyword-only, positional. For example, in
> 
> def f(a, b, c, *args, d):
>  pass
> 
> a, b, and c are positional. Hence the "positional" in error messages.

But since the error message gives the name of the parameter, there
doesn't seem to be a point to add that it's "positional": it can be
trivially deduced from the function signature.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Mark Dickinson 
On Thu, Sep 20, 2012 at 3:12 PM, Benjamin Peterson  wrote:

> As you noted in your next message, keyword-only arguments need to be
> distinguished from these "positional" arguments somehow. Maybe it
> helps to think of "positional" to mean "the only formals you can pass
> to with position" (excepting variadic ones).

And excepting optional ones, too, right?  E.g., the c in

def foo(a, b, c=1, *args, d):
pass

can be passed to by position, but isn't "positional".

> I'm certainly open to suggestions.

Yes, I don't have a good alternative suggestion.  If we could find a
suitable word and bless it in the documentation, it might make it
easier to make clear and accurate statements about Python's function
calling.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Benjamin Peterson 
2012/9/20 Mark Dickinson :
> And excepting optional ones, too, right?  E.g., the c in
>
> def foo(a, b, c=1, *args, d):
> pass
>
> can be passed to by position, but isn't "positional".

Why not?

>>> def f(a, b, c=3): pass
...
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() missing 2 required positional arguments: 'a' and 'b'
>>> f(1, 2, 3, 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() takes from 2 to 3 positional arguments but 4 were given



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Mark Dickinson 
On Thu, Sep 20, 2012 at 4:14 PM, Benjamin Peterson  wrote:
> 2012/9/20 Mark Dickinson :
>> And excepting optional ones, too, right?  E.g., the c in
>>
>> def foo(a, b, c=1, *args, d):
>> pass
>>
>> can be passed to by position, but isn't "positional".
>
> Why not?

Ah, okay;  I was assuming (wrongly) that your definition of
'positional' was intended to exclude these.  My bad.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Take a look at Issue15421

2012-09-20 Thread Cédric Krier 
Hi,

Could someone take a look at the Issue15421 [1]?
It is a small bug in calendar module but it generates noise on web
application like roundup [2].

Thanks,

[1] http://bugs.python.org/issue15421
[2] http://issues.roundup-tracker.org/issue2550765

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Guido van Rossum 
On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson  wrote:
> 2012/9/20 Mark Dickinson :
>> Thoughts?
>
> I tried to define the error messages in terms of the callee's
> signature. I call the formals that are not variadic, keyword variadic,
> or keyword-only, positional. For example, in
>
> def f(a, b, c, *args, d):
>  pass
>
> a, b, and c are positional. Hence the "positional" in error messages.

No -- Mark's point is that (even given this syntax) you *could* pass
them using keywords.

I think Brett's got it right and we should just refer to a and b as
'arguments'. For d, we should use keyword arguments (or, in full,
keyword-only arguments). That's enough of a distinction.

Of course, in a specific call, we can continue to refer to positional
and keyword arguments based on the actual syntax used in the call.

Maybe this is also a good time to start distinguishing between
arguments (what you pass, call syntax) and parameters (what the
function receives, function definition syntax)?

> As you noted in your next message, keyword-only arguments need to be
> distinguished from these "positional" arguments somehow. Maybe it
> helps to think of "positional" to mean "the only formals you can pass
> to with position" (excepting variadic ones).
>
> I'm certainly open to suggestions.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Oscar Benjamin 
On 20 September 2012 16:14, Benjamin Peterson  wrote:

> 2012/9/20 Mark Dickinson :
> > And excepting optional ones, too, right?  E.g., the c in
> >
> > def foo(a, b, c=1, *args, d):
> > pass
> >
> > can be passed to by position, but isn't "positional".
>
> Why not?
>
> >>> def f(a, b, c=3): pass
> ...
> >>> f()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: f() missing 2 required positional arguments: 'a' and 'b'
> >>> f(1, 2, 3, 4)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: f() takes from 2 to 3 positional arguments but 4 were given
>

The difference between c and a,b is that c is optional, whereas a and b are
required.

In Python 2.x there are named arguments and variadic arguments. There are
two types of named arguments: required and optional. There are also two
types of variadic arguments: positional and keyword. i.e.:

named
  required
  not-required
variadic
  positional
  keyword

In Python 2.x all named parameters can be passed by position or by keyword,
so it doesn't make sense to use those concepts to distinguish them. On the
other hand, for variadic parameters that distinction is crucial.

In Python 3.x there are two orthogonal properties for each named parameter.
The parameter can be required or optional as before, and then the parameter
can be keyword-only or positional. There are 4 combinations of these two
properties:

def f(a, b=1, *, c, d=3): pass

   | required | optional
positional | a  | b
kwonly   | c  | d

Since there are two orthogonal properties of a parameter (requiredness and
positionness) it makes perfect sense to use two adjectives to describe each
parameter as is the case for the error message shown at the start of this
thread:

Mark Dickinson wrote:
 def f(x): pass
>...
 f()
>Traceback (most recent call last):
>  File "", line 1, in 
>TypeError: f() missing 1 required positional argument: 'x'

I would say that the only problem with this terminology is that it would be
good to think of a word to replace "keyword-only" (positionless?).

Oscar
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Terry Reedy 

On 9/20/2012 7:56 AM, Mark Dickinson wrote:

I suspect I've missed the boat on this one (certainly for 3.3.0), but
here goes.  The new TypeError reporting for bad function calls is a
huge improvement (thanks Benjamin!), but I have one small nitpick:
what *is* a positional argument?  For example:

 >>> def f(x): pass
 ...
 >>> f()
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: f() missing 1 required positional argument: 'x'

I think it's confusing to describe 'x' as a positional argument.  It's
a required formal parameter, certainly.  But a caller of 'f' could
pass 'x' either by position or by 'keyword'.


When running training (generally Python 2.6 or 2.7 based), I
frequently have to devote some time to unravelling student confusion
between 'arguments passed by keyword' on one hand and 'optional formal
parameters' on the other.  The outline of the explanation goes
something like:

(0) Preamble: be careful to separate out details of function calling
from those of function definition; distinguish formal parameters from
actual arguments.
(1) On the function *definition* side, formal parameters may be either
*required* or *optional*.


and optional params may or may not have an overt default object


(2) On the function *calling* side, actual arguments may be passed
either positionally or by keyword.


Sometimes position is required, sometimes keyword is required, and 
usually both are allowed.



(3) The notions in (1) and (2) are entirely orthogonal!


Moreover, all six combinations of passing mode and requirement are 
possible, although for Python functions, some combinations require setup 
code in addition to the header. Built-in print accepts an indefinite 
number of optional no-default position-only args followed by up to three 
optional defaulted keyword-only args. print() emits the default end='\n'.



(3a) (Although in practice, callers tend to use pass-by-keyword for
optional formal parameters.)

That's all for Python 2;  Python 3, of course, requires a bit more
explanation related to the keyword-only arguments.

There already seems to be a fair amount of confusion in the Python
world about point (3);


I have strongly suggested that the docs not adds to the confusion in at 
least one tracker discussion.



 I've seen professional Python training slides
that show how to define optional formal parameters under the heading
"keyword arguments".

I submit that the word 'positional' in the TypeError message
exacerbates this confusion, and that little would be lost by simply
dropping it from the exception message.


For this example that would be sufficient, but your later message shows 
that we need a one-word abbreviations for positional-or-keyword: either 
something indicating that its default nature -- 'normal', 'standard', 
'flexible', 'usual', 'typical' -- or something indicating its dual 
nature (possibly coined or metaphorical -- 'pos-key', 'bi-mode', 
'dual-mode', 'Janus-like'.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Terry Reedy 

On 9/20/2012 10:12 AM, Benjamin Peterson wrote:

2012/9/20 Mark Dickinson :

Thoughts?


I tried to define the error messages in terms of the callee's
signature. I call the formals that are not variadic, keyword variadic,
or keyword-only, positional. For example, in

def f(a, b, c, *args, d):
  pass

a, b, and c are positional. Hence the "positional" in error messages.


They are positional-or-keyword without defaults.


As you noted in your next message, keyword-only arguments need to be
distinguished from these "positional" arguments somehow.


Positional-or-keyword and positional-only also need to be distinguished.
'Positional' is ambiguous. One problem for standardized error messages 
is the the header info does not always tell the complete story.



I'm certainly open to suggestions.


I gave several suggestions for 'positional-or-keyword' in my response to 
Mark.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread David Beazley 
I have recently been experimenting with the memoryview() built-in and have come 
to believe that it really needs to expose the 'buf' attribute of the underlying 
Py_buffer structure as an integer (see PEP 3118).  Let me explain.

The whole point of PEP 3118 (as I understand it) is to provide a means for 
exchanging or sharing array data across different libraries such as numpy, PIL, 
ctypes, Cython, etc.   If you're working with Py_buffer objects at the C level, 
this works fine.  However, if you're working purely in Python, you're only able 
to get partial information about memory views such as the shape and size.   You 
can't get the actual pointer to the underlying memory (unless I've missed 
something obvious).

This is unfortunate because it means that you can't  write Python code to link 
memoryviews to other kinds of compiled code that might want to operate on 
array-oriented data.  For example, you can't pass the raw pointer into a 
function that you've exposed via ctypes.  Similarly, you can't pass the pointer 
into functions you've dynamically compiled using libraries such as LLVM-py. 
There might be other kinds of applications, but just having that one bit of 
extra information available would be useful for various advanced programming 
techniques involving extensions and memory buffers.

Cheers,
Dave






___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Benjamin Peterson 
2012/9/20 David Beazley :
> I have recently been experimenting with the memoryview() built-in and have 
> come to believe that it really needs to expose the 'buf' attribute of the 
> underlying Py_buffer structure as an integer (see PEP 3118).  Let me explain.
>
> The whole point of PEP 3118 (as I understand it) is to provide a means for 
> exchanging or sharing array data across different libraries such as numpy, 
> PIL, ctypes, Cython, etc.   If you're working with Py_buffer objects at the C 
> level, this works fine.  However, if you're working purely in Python, you're 
> only able to get partial information about memory views such as the shape and 
> size.   You can't get the actual pointer to the underlying memory (unless 
> I've missed something obvious).
>
> This is unfortunate because it means that you can't  write Python code to 
> link memoryviews to other kinds of compiled code that might want to operate 
> on array-oriented data.  For example, you can't pass the raw pointer into a 
> function that you've exposed via ctypes.  Similarly, you can't pass the 
> pointer into functions you've dynamically compiled using libraries such as 
> LLVM-py. There might be other kinds of applications, but just having that 
> one bit of extra information available would be useful for various advanced 
> programming techniques involving extensions and memory buffers.

Presumably ctypes should be able to do this conversion for you.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread David Beazley 
How?  I must be missing something very obvious.

Cheers,
Dave

On Sep 20, 2012, at 11:48 AM, Benjamin Peterson wrote:

> 2012/9/20 David Beazley :
>> I have recently been experimenting with the memoryview() built-in and have 
>> come to believe that it really needs to expose the 'buf' attribute of the 
>> underlying Py_buffer structure as an integer (see PEP 3118).  Let me explain.
>> 
>> The whole point of PEP 3118 (as I understand it) is to provide a means for 
>> exchanging or sharing array data across different libraries such as numpy, 
>> PIL, ctypes, Cython, etc.   If you're working with Py_buffer objects at the 
>> C level, this works fine.  However, if you're working purely in Python, 
>> you're only able to get partial information about memory views such as the 
>> shape and size.   You can't get the actual pointer to the underlying memory 
>> (unless I've missed something obvious).
>> 
>> This is unfortunate because it means that you can't  write Python code to 
>> link memoryviews to other kinds of compiled code that might want to operate 
>> on array-oriented data.  For example, you can't pass the raw pointer into a 
>> function that you've exposed via ctypes.  Similarly, you can't pass the 
>> pointer into functions you've dynamically compiled using libraries such as 
>> LLVM-py. There might be other kinds of applications, but just having 
>> that one bit of extra information available would be useful for various 
>> advanced programming techniques involving extensions and memory buffers.
> 
> Presumably ctypes should be able to do this conversion for you.
> 
> 
> 
> -- 
> Regards,
> Benjamin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Chris Jerdonek 
On Thu, Sep 20, 2012 at 8:52 AM, Guido van Rossum  wrote:
> On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson  
> wrote:
>> I tried to define the error messages in terms of the callee's
>> signature. I call the formals that are not variadic, keyword variadic,
>> or keyword-only, positional. For example, in
>
> Maybe this is also a good time to start distinguishing between
> arguments (what you pass, call syntax) and parameters (what the
> function receives, function definition syntax)?

The glossary is one place to start making this distinction.  It
currently has entries for "argument," "positional argument," and
"keyword argument" that could perhaps use a review from this
discussion.  For example:

http://docs.python.org/dev/glossary.html#term-positional-argument

The entries currently blur the distinction between the calling and
definition perspectives.  Ideally, the glossary definitions of these
terms would match and be consistent with their usage in error
messages.

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Terry Reedy 

On 9/20/2012 11:52 AM, Guido van Rossum wrote:


Maybe this is also a good time to start distinguishing between
arguments (what you pass, call syntax) and parameters (what the
function receives, function definition syntax)?


One standard usage (and mine) is that parameters are the (local) names 
that arguments get bound to. I *believe* that Knuth used this also, but 
I cannot find a reference. Here is the CS part of

https://en.wikipedia.org/wiki/Parameters
See the last sentence.

"Computer science
Main article: Parameter (computer science)

When the terms formal parameter and actual parameter are used, they 
generally correspond with the definitions used in computer science. In 
the definition of a function such as


f(x) = x + 2,

x is a formal parameter. When the function is used as in

y = f(3) + 5 or just the value of f(3),

3 is the actual parameter value that is substituted for the formal 
parameter in the function definition. These concepts are discussed in a 
more precise way in functional programming and its foundational 
disciplines, lambda calculus and combinatory logic.


In computing, parameters are often called arguments, and the two words 
are used interchangeably. However, some computer languages such as C 
define argument to mean actual parameter (i.e., the value), and 
parameter to mean formal parameter."


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Richard Oudkerk 

On 20/09/2012 5:53pm, David Beazley wrote:

How?  I must be missing something very obvious.


I would not call it obvious, but you can do

>>> m = memoryview(bytearray(5))
>>> ctypes.addressof(ctypes.c_char.from_buffer(m))
149979304

However, this only works for writable memoryviews.  For
read-only memoryviews you could do

>>> obj = ctypes.py_object(m)
>>> address = ctypes.c_void_p()
>>> length = ctypes.c_ssize_t()
>>> ctypes.pythonapi.PyObject_AsReadBuffer(obj, 
ctypes.byref(address), ctypes.byref(length))

0
>>> address, length
(c_void_p(149979304), c_long(5))


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Stefan Krah 
David Beazley  wrote:
> I have recently been experimenting with the memoryview() built-in and have
> come to believe that it really needs to expose the 'buf' attribute of the
> underlying Py_buffer structure as an integer (see PEP 3118).  Let me explain.

That sounds quite harmless. People who use the pointer via ctypes etc.
should know the implications. I've opened #15986 for this.


Stefan Krah



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Benjamin Peterson 
2012/9/20 David Beazley :
> How?  I must be missing something very obvious.

If you have some ctypes function that requires a pointer and you pass
a memoryview, ctypes should pass the pointer to the raw memory, right?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread David Beazley 
Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.  I 
get a type error about it wanting a ctypes pointer object.Even if this 
worked, it still doesn't address the need to get the pointer value possibly for 
some other purpose such as handling it off to a bunch of code generated via 
LLVM. 

Cheers,
Dave

On Sep 20, 2012, at 1:20 PM, Benjamin Peterson wrote:

> 2012/9/20 David Beazley :
>> How?  I must be missing something very obvious.
> 
> If you have some ctypes function that requires a pointer and you pass
> a memoryview, ctypes should pass the pointer to the raw memory, right?
> 
> 
> 
> -- 
> Regards,
> Benjamin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Steven D'Aprano 

On 20/09/12 22:59, Mark Dickinson wrote:

On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan  wrote:

+1 for using the unqualified "argument" in these error messages to
mean "positional or keyword argument" (inspect.Parameter spells it out
as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
an error message).


Ah yes;  I see that 'positional or keyword' is a more accurate term
(but agree it's unwieldy for an error message).  I also see that I was
naive to think that the 'fix' is as simple as dropping the word
'positional':

 >>>  def f(a, *, b):
 ... pass
 ...
 >>>  f()
 Traceback (most recent call last):
   File "", line 1, in
 TypeError: f() missing 1 required positional argument: 'a'

If the word 'positional' were dropped here, it would give the
incorrect impression that f only requires one argument.



I don't expect error messages to give a complete catalog of every
problem with a specific function call. If f() reports that required
argument 'a' is missing, that does not imply that no other required
arguments are also missing. I think it is perfectly acceptable to
not report the missing 'b' until the missing 'a' is resolved.

But I do expect error messages to be accurate. +1 to remove the
word "positional" from the message.



--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Steven D'Aprano 

On 21/09/12 00:49, Antoine Pitrou wrote:

On Thu, 20 Sep 2012 10:12:04 -0400
Benjamin Peterson  wrote:

2012/9/20 Mark Dickinson:

Thoughts?


I tried to define the error messages in terms of the callee's
signature. I call the formals that are not variadic, keyword variadic,
or keyword-only, positional. For example, in

def f(a, b, c, *args, d):
  pass

a, b, and c are positional. Hence the "positional" in error messages.


But since the error message gives the name of the parameter, there
doesn't seem to be a point to add that it's "positional": it can be
trivially deduced from the function signature.


Furthermore, since the parameter has a name, it can be given as a
keyword argument. Describing positional-or-keyword as "positional"
is misleading, although I admit that I often do that too. I think that
"positional or keyword argument" is too wordy, and is ambiguous as to
whether the argument can be given as either positional or keyword, or
we're unsure which of the two it is.

"Named positional argument" is more accurate, but also too wordy, and
it relies on the reader knowing enough about Python's calling semantics
to infer that therefore it can be given as positional or keyword style.

Since this is way too complicated to encapsulate in a short error
message, I'm with Nick and Mark that "positional" should be dropped
unless the argument is positional-only.



--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Steven D'Aprano 

On 21/09/12 01:53, Oscar Benjamin wrote:


Mark Dickinson wrote:

def f(x): pass

...

f()

Traceback (most recent call last):
  File "", line 1, in
TypeError: f() missing 1 required positional argument: 'x'


I would say that the only problem with this terminology is that it would be
good to think of a word to replace "keyword-only" (positionless?).


I disagree completely. I think keyword-only is the right terminology to
use for arguments which can only be passed by keyword. It is *positional*
that is questionable, since named positional arguments can be given by
keyword.

I would like to see error messages reserve the terms:

1) "positional" for explicitly positional-only parameters;
2) "keyword" for explicitly keyword-only parameters;

(I don't mind whether or not they use "-only" as a suffix)

For normal, named-positional-or-keyword arguments, just use an unqualified
"argument".



--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Chris Jerdonek 
On Thu, Sep 20, 2012 at 10:18 AM, Chris Jerdonek
 wrote:
> On Thu, Sep 20, 2012 at 8:52 AM, Guido van Rossum  wrote:
>> On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson  
>> wrote:
>>> I tried to define the error messages in terms of the callee's
>>> signature. I call the formals that are not variadic, keyword variadic,
>>> or keyword-only, positional. For example, in
>>
>> Maybe this is also a good time to start distinguishing between
>> arguments (what you pass, call syntax) and parameters (what the
>> function receives, function definition syntax)?
>
> The glossary is one place to start making this distinction.  It
> currently has entries for "argument," "positional argument," and
> "keyword argument" that could perhaps use a review from this
> discussion.  For example:
>
> http://docs.python.org/dev/glossary.html#term-positional-argument
>
> The entries currently blur the distinction between the calling and
> definition perspectives.  Ideally, the glossary definitions of these
> terms would match and be consistent with their usage in error
> messages.

I took the liberty to create an issue in the tracker to settle on and
document preferred terminology in the area of positional/keyword
arguments/parameters, etc.  The issue is here:

http://bugs.python.org/issue15990

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Ethan Furman 

Steven D'Aprano wrote:

On 20/09/12 22:59, Mark Dickinson wrote:

On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan  wrote:

+1 for using the unqualified "argument" in these error messages to
mean "positional or keyword argument" (inspect.Parameter spells it out
as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
an error message).


Ah yes;  I see that 'positional or keyword' is a more accurate term
(but agree it's unwieldy for an error message).  I also see that I was
naive to think that the 'fix' is as simple as dropping the word
'positional':

 >>>  def f(a, *, b):
 ... pass
 ...
 >>>  f()
 Traceback (most recent call last):
   File "", line 1, in
 TypeError: f() missing 1 required positional argument: 'a'

If the word 'positional' were dropped here, it would give the
incorrect impression that f only requires one argument.


I don't expect error messages to give a complete catalog of every
problem with a specific function call. If f() reports that required
argument 'a' is missing, that does not imply that no other required
arguments are also missing. I think it is perfectly acceptable to
not report the missing 'b' until the missing 'a' is resolved.


I disagree.  There is no reason (that I'm aware of ;) that the missing 
'b' cannot be noticed and reported at the same time as the missing 'a'.




But I do expect error messages to be accurate. +1 to remove the
word "positional" from the message.


And then it's still not accurate as 'b' is also a required argument that 
is missing.  Unless and until all error messages adopt your proposed 
'positional argument', 'argument', 'keyword argument' *and* describe 
_all_ the problems with the call confusion will reign supreme.


So, ideally, the above example would be:

 >>>  def f(a, *, b):
 ... pass
 ...
 >>>  f()
 Traceback (most recent call last):
   File "", line 1, in
 TypeError: f() missing 2 required arguments: positional: 'a', 
keyword: 'b'


~Ethan~

P.S.
Also, a big thank-you -- the error messages *are* getting better all the 
time!

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Ethan Furman 

Steven D'Aprano wrote:

I would like to see error messages reserve the terms:

1) "positional" for explicitly positional-only parameters;
2) "keyword" for explicitly keyword-only parameters;


+1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Steven D'Aprano 

On 21/09/12 05:45, Ethan Furman wrote:


I don't expect error messages to give a complete catalog of every
problem with a specific function call. If f() reports that required
argument 'a' is missing, that does not imply that no other required
arguments are also missing. I think it is perfectly acceptable to
not report the missing 'b' until the missing 'a' is resolved.


I disagree. There is no reason (that I'm aware of ;) that the missing
'b' cannot be noticed and reported at the same time as the missing 'a'.


Listing every missing argument does not scale well as the number of
arguments increases.

def f(spam, ham, cheese, aardvark, halibut, *,  shrubbery, parrot, 
wafer_thin_mint):
pass

f()

I would be -0 on an error message like:

TypeError: f() needs arguments 'spam', 'ham', 'cheese', 'aardvark', 'halibut' 
and keyword-only arguments 'shrubbery', 'parrot', 'wafer_thin_mint'

but wouldn't strongly object. I think it is acceptable (although not
ideal) if calling f() only reported the first missing argument it
noticed.

But I do think that we should not make any language guarantees about
error messages being "complete" or not.


--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

2012-09-20 Thread Nick Coghlan 
We've already had this terminology discussion and documented the results in
PEP 362. The rest of the docs may require updates to be brought in line
with that.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Glyph 
Le Sep 20, 2012 à 11:35 AM, David Beazley  a écrit :

> Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.  
> I get a type error about it wanting a ctypes pointer object.Even if this 
> worked, it still doesn't address the need to get the pointer value possibly 
> for some other purpose such as handling it off to a bunch of code generated 
> via LLVM. 

It seems like there's no reason to need to get the pointer value out as a 
Python integer.  If you are trying to get a pointer from a memoryview into some 
C code, or into some LLVM generated code, you still need to do the Python int 
object → C integer-of-some-kind → C pointer type conversion.  Better to just go 
straight from Python memoryview object → C pointer in one supported API call.  
Isn't this what the y* w* s* format codes are for?

Every time I have something that's a big number and I need to turn it into a 
pointer, I have to stare at the table in 
 for like 30 seconds.  
I'd rather have some Python API do the staring for me.  David, I realize that 
table is probably permanently visible in the heads-up display that your 
cybernetic implants afford you, but some of us need to make our way through C 
code with humbler faculties ;-).

-g

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread David Beazley 
A memory address is a number.   I think an integer is fine--if you're working 
at this level, you're already on your own and expected to know what you're 
doing.  I'd prefer to just get the raw address without yet another level of 
indirection.

Other parts of the library already do this.   For instance array.buffer_info().

Cheers
Dave

Sent from cell 

On Sep 20, 2012, at 6:16 PM, Glyph  wrote:

> Le Sep 20, 2012 à 11:35 AM, David Beazley  a écrit :
> 
>> Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.  
>> I get a type error about it wanting a ctypes pointer object.Even if this 
>> worked, it still doesn't address the need to get the pointer value possibly 
>> for some other purpose such as handling it off to a bunch of code generated 
>> via LLVM. 
> 
> It seems like there's no reason to need to get the pointer value out as a 
> Python integer.  If you are trying to get a pointer from a memoryview into 
> some C code, or into some LLVM generated code, you still need to do the 
> Python int object → C integer-of-some-kind → C pointer type conversion.  
> Better to just go straight from Python memoryview object → C pointer in one 
> supported API call.  Isn't this what the y* w* s* format codes are for?
> 
> Every time I have something that's a big number and I need to turn it into a 
> pointer, I have to stare at the table in 
>  for like 30 seconds. 
>  I'd rather have some Python API do the staring for me.  David, I realize 
> that table is probably permanently visible in the heads-up display that your 
> cybernetic implants afford you, but some of us need to make our way through C 
> code with humbler faculties ;-).
> 
> -g
> 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Nick Coghlan 
On Fri, Sep 21, 2012 at 9:37 AM, David Beazley  wrote:
> A memory address is a number.   I think an integer is fine--if you're working 
> at this level, you're already on your own and expected to know what you're 
> doing.  I'd prefer to just get the raw address without yet another level of 
> indirection.
>
> Other parts of the library already do this.   For instance 
> array.buffer_info().

I'm fine with exposing a memoryview.buffer_address attribute in 3.4.
The idea had never come up before, as the idea of using *Python code*
(rather than C) to provide the shim between a PEP 3118 exporter and a
consumer that doesn't understand that API isn't a use case we had even
considered. memoryview has instead been more focused on *interpreting*
the contents of exported buffers as ordinary Python objects.

(We already know we still need to define an API to let classes defined
in Python implement the buffer API, though)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Memoryviews should expose the underlying memory address

2012-09-20 Thread Greg Ewing 

Nick Coghlan wrote:

I'm fine with exposing a memoryview.buffer_address attribute in 3.4.


What about objects whose buffer address can change
when the buffer isn't locked?

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com