[Python-Dev] TypeError: f() missing 1 required positional argument: 'x'
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 stdin, line 1, in module 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 9:56 PM, Mark Dickinson dicki...@gmail.com 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan ncogh...@gmail.com 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 stdin, line 1, in module 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 10:59 PM, Mark Dickinson dicki...@gmail.com 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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/9/20 Mark Dickinson dicki...@gmail.com: 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson benja...@python.org 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 Python-Dev@python.org 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'
On Thu, 20 Sep 2012 10:12:04 -0400 Benjamin Peterson benja...@python.org wrote: 2012/9/20 Mark Dickinson dicki...@gmail.com: 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 3:12 PM, Benjamin Peterson benja...@python.org 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 Python-Dev@python.org 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/9/20 Mark Dickinson dicki...@gmail.com: 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 stdin, line 1, in module TypeError: f() missing 2 required positional arguments: 'a' and 'b' f(1, 2, 3, 4) Traceback (most recent call last): File stdin, line 1, in module TypeError: f() takes from 2 to 3 positional arguments but 4 were given -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 4:14 PM, Benjamin Peterson benja...@python.org wrote: 2012/9/20 Mark Dickinson dicki...@gmail.com: 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 Python-Dev@python.org 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
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: cedric.kr...@b2ck.com Website: http://www.b2ck.com/ ___ Python-Dev mailing list Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson benja...@python.org wrote: 2012/9/20 Mark Dickinson dicki...@gmail.com: 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 Python-Dev@python.org 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'
On 20 September 2012 16:14, Benjamin Peterson benja...@python.org wrote: 2012/9/20 Mark Dickinson dicki...@gmail.com: 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 stdin, line 1, in module TypeError: f() missing 2 required positional arguments: 'a' and 'b' f(1, 2, 3, 4) Traceback (most recent call last): File stdin, line 1, in module 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 stdin, line 1, in module 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 Python-Dev@python.org 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'
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 stdin, line 1, in module 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 Python-Dev@python.org 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'
On 9/20/2012 10:12 AM, Benjamin Peterson wrote: 2012/9/20 Mark Dickinson dicki...@gmail.com: 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 Python-Dev@python.org 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
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 Python-Dev@python.org 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/9/20 David Beazley d...@dabeaz.com: 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 Python-Dev@python.org 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
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 d...@dabeaz.com: 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 8:52 AM, Guido van Rossum gu...@python.org wrote: On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson benja...@python.org 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 Python-Dev@python.org 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'
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 Python-Dev@python.org 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
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 Python-Dev@python.org 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
David Beazley d...@dabeaz.com 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 Python-Dev@python.org 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/9/20 David Beazley d...@dabeaz.com: 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 Python-Dev@python.org 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
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 d...@dabeaz.com: 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 Python-Dev@python.org 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'
On 20/09/12 22:59, Mark Dickinson wrote: On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlanncogh...@gmail.com 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 stdin, line 1, inmodule 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 Python-Dev@python.org 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'
On 21/09/12 00:49, Antoine Pitrou wrote: On Thu, 20 Sep 2012 10:12:04 -0400 Benjamin Petersonbenja...@python.org wrote: 2012/9/20 Mark Dickinsondicki...@gmail.com: 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 Python-Dev@python.org 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'
On 21/09/12 01:53, Oscar Benjamin wrote: Mark Dickinson wrote: def f(x): pass ... f() Traceback (most recent call last): File stdin, line 1, inmodule 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 Python-Dev@python.org 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'
On Thu, Sep 20, 2012 at 10:18 AM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Sep 20, 2012 at 8:52 AM, Guido van Rossum gu...@python.org wrote: On Thu, Sep 20, 2012 at 7:12 AM, Benjamin Peterson benja...@python.org 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 Python-Dev@python.org 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'
Steven D'Aprano wrote: On 20/09/12 22:59, Mark Dickinson wrote: On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlanncogh...@gmail.com 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 stdin, line 1, inmodule 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 stdin, line 1, inmodule 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 Python-Dev@python.org 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'
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 Python-Dev@python.org 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'
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 Python-Dev@python.org 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'
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 Python-Dev@python.org 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
Le Sep 20, 2012 à 11:35 AM, David Beazley d...@dabeaz.com 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 http://en.wikipedia.org/wiki/64_bit#64-bit_data_models 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 Python-Dev@python.org 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
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 gl...@twistedmatrix.com wrote: Le Sep 20, 2012 à 11:35 AM, David Beazley d...@dabeaz.com 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 http://en.wikipedia.org/wiki/64_bit#64-bit_data_models 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 Python-Dev@python.org 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
On Fri, Sep 21, 2012 at 9:37 AM, David Beazley d...@dabeaz.com 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
