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
Python-Dev@python.org
http://mail.python.org
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
> indi
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 ins
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
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
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 acc
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://m
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
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 var
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 thin
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, posit
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 verbos
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
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-D
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
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.
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
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 ex
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
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
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 mean
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):
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:
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,
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,
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
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 assu
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
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" (excepti
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
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 som
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 "posi
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. Hopef
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
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
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()
36 matches
Mail list logo
