Larry Hastings, 19.03.2013 05:45:
> The original impetus for Argument Clinic was adding introspection
> information for builtins [...]
> On to the representation. Consider the function
>
>def foo(arg, b=3, *, kwonly='a'):
> pass
> [...]
> 4. Store a string that looks like the Python d
The original impetus for Argument Clinic was adding introspection
information for builtins--it seemed like any manual approach I came up
with would push the builtins maintenance burden beyond the pale.
Assuming that we have Argument Clinic or something like it, we don't
need to optimize for
On Mon, Mar 18, 2013 at 05:27:33PM -0700, Christian Tismer wrote:
> Hi Trent,
Hi Christian! Thanks for taking the time to read my walls of text
;-)
> > So, the remaining challenge is preventing the use case alluded to
> > earlier where someone tries to modify an object that hasn't been "
Hi Trent,
I just started to try to understand the idea and the implications.
Removing almost all of your message since that is already too long
to work with:
The reference is
http://mail.python.org/pipermail/python-dev/2013-March/124690.html
On 3/14/13 11:45 AM, Trent Nelson wrote:
On Wed, Mar
Hi python dev.
I have two languishing defects regarding 2.7 and how buffer support isn't
complete there.
http://bugs.python.org/issue10211
http://bugs.python.org/issue10212
In both cases, the new style buffer support is incomplete, and the patches
close usability holes having to do with memoryvi
On 18.03.13 22:26, Jeff Allen wrote:
The puzzle is that it requires t.read() to succeed.
When I insert a check for bytes type in all the places it seems
necessary in my code, I pass the first two conditions, but since
t.read() also raises TypeError, the overall test fails. Is reading the
stream
On Mon, Mar 18, 2013 at 11:02 AM, Guido van Rossum wrote:
> On Mon, Mar 18, 2013 at 3:36 AM, Stefan Krah wrote:
>> Larry Hastings wrote:
>>> * The DSL currently makes no provision for specifying per-parameter
>>> type annotations. This is something explicitly supported in Python;
>>> it sho
On 18 Mar, 2013, at 23:43, Larry Hastings wrote:
> On 03/18/2013 02:29 AM, Ronald Oussoren wrote:
>> On 18 Mar, 2013, at 8:16, Larry Hastings wrote:
>>> This has some consequences. For example, inspect.getfullargspec,
>>> inspect.Signature, and indeed types.FunctionObject and types.CodeObject
On 03/18/2013 02:29 AM, Ronald Oussoren wrote:
On 18 Mar, 2013, at 8:16, Larry Hastings wrote:
This has some consequences. For example, inspect.getfullargspec,
inspect.Signature, and indeed types.FunctionObject and types.CodeObject have no
currently defined mechanism for communicating that a
Hrvoje Niksic wrote:
I am not the best person to answer because I go on to argue that this
syntax is not needed in Python at all (anything it can do can be
implemented with __setitem__ at no loss of clarity).
I would even argue that the proxy solution is even *better*
for that particular use c
I'm pulling recent changes in the io module across to Jython. I am
looking for help understanding the changes in
http://hg.python.org/cpython/rev/19a33ef3821d
That change set is about what should happen if the underlying buffer
does not return bytes when read, but instead, for example, unicode
On Mon, Mar 18, 2013 at 8:57 AM, Nick Coghlan wrote:
> On Mon, Mar 18, 2013 at 1:47 AM, larry.hastings
> wrote:
>> Notes / TBD
>> ===
>>
>> +* The DSL currently makes no provision for specifying per-parameter
>> + type annotations. This is something explicitly supported in Python;
>>
Move. This. Thread. Out. Of. Python-Dev. Now. (python-ideas is the right place.)
On Mon, Mar 18, 2013 at 10:25 AM, Serhiy Storchaka wrote:
> On 18.03.13 17:40, Steven D'Aprano wrote:
>>
>> On 19/03/13 02:01, Hrvoje Niksic wrote:
>>>
>>> Assigning to function calls is orthogonal to reference types
On Mon, Mar 18, 2013 at 3:36 AM, Stefan Krah wrote:
> Larry Hastings wrote:
>> * The DSL currently makes no provision for specifying per-parameter
>> type annotations. This is something explicitly supported in Python;
>> it should be supported for builtins too, once we have reflection suppor
On 18.03.13 17:40, Steven D'Aprano wrote:
On 19/03/13 02:01, Hrvoje Niksic wrote:
Assigning to function calls is orthogonal to reference types. For
example, Python manages assignment to subscripts without having
references just fine:
val = obj[index] # val = obj.__getitem__(index)
obj[ind
On 03/18/2013 04:40 PM, Steven D'Aprano wrote:
In analogy with that, Python could implement what looks like assignment to
function call like this:
val = f(arg) # val = f.__call__(arg)
f(arg) = val # f.__setcall__(arg, val)
That's all very well, but what would it do? It's not
On Sun, Mar 17, 2013 at 12:14 AM, Larry Hastings wrote:
> On 03/16/2013 02:17 AM, Stefan Krah wrote:
>
> Both PEPs were discussed at PyCon. The state of affairs is that a
> compromise is being worked upon and will be published by Larry in
> a revised PEP.
>
>
> I've pushed an update to PEP 436, t
On Mon, Mar 18, 2013 at 1:47 AM, larry.hastings
wrote:
> Notes / TBD
> ===
>
> +* The DSL currently makes no provision for specifying per-parameter
> + type annotations. This is something explicitly supported in Python;
> + it should be supported for builtins too, once we have reflect
On Mon, Mar 18, 2013 at 8:50 AM, Neal Becker wrote:
> def F(x):
> return x
>
> x = 2
> F(x) = 3
>
> F(x) = 3
> SyntaxError: can't assign to function call
>
> Do we really need this restriction? There do exist other languages without
> it.
I think this belongs on python-ideas before laun
On Mon, Mar 18, 2013 at 3:13 AM, Stefan Krah wrote:
> Larry Hastings wrote:
>> So I hope that at least converters can be declared statically in a header
>> file, like I suggested in PEP 437.
>>
>>
>> The Argument Clinic prototype is written in Python; I don't know how
>> "declared
>> sta
On 19/03/13 02:01, Hrvoje Niksic wrote:
On 03/18/2013 03:23 PM, Chris Angelico wrote:
The languages that permit you to assign to a function call all have
some notion of a reference type.
Assigning to function calls is orthogonal to reference types. For example,
Python manages assignment to s
On 03/18/2013 03:23 PM, Chris Angelico wrote:
The languages that permit you to assign to a function call all have
some notion of a reference type.
Assigning to function calls is orthogonal to reference types. For
example, Python manages assignment to subscripts without having
references just
Am 17.03.2013 19:59, schrieb Antoine Pitrou:
>> Why keep the libraries vulnerable for another year (3.4 final is expected
>> for early 2014), if there is something we can do about them now?
>
> Well, Christian said that his stdlib patch wasn't ready yet.
The patch is > 90% finished. All the hard
Am 17.03.2013 19:25, schrieb Eli Bendersky:
> I'll gladly review the _elementtree changes and can help with the expat
> & pyexpat changes as well. Until now I had the impression that the
> patches aren't ready for review yet. If they are, that's great.
The modifications to expat, pyexpat and _elem
On 2013-03-18, at 15:23 , Chris Angelico wrote:
> On Tue, Mar 19, 2013 at 12:50 AM, Neal Becker wrote:
>> def F(x):
>>return x
>>
>> x = 2
>> F(x) = 3
>>
>>F(x) = 3
>> SyntaxError: can't assign to function call
>>
>> Do we really need this restriction? There do exist other languages w
On Tue, Mar 19, 2013 at 12:50 AM, Neal Becker wrote:
> def F(x):
> return x
>
> x = 2
> F(x) = 3
>
> F(x) = 3
> SyntaxError: can't assign to function call
>
> Do we really need this restriction? There do exist other languages without
> it.
The languages that permit you to assign to a fu
On 19/03/13 00:50, Neal Becker wrote:
def F(x):
return x
x = 2
F(x) = 3
F(x) = 3
SyntaxError: can't assign to function call
Do we really need this restriction? There do exist other languages without it.
What meaning would you give to "F(x) = 3", and why?
--
Steven
On 18 March 2013 10:50, Neal Becker wrote:
> def F(x):
> return x
>
> x = 2
> F(x) = 3
>
> F(x) = 3
> SyntaxError: can't assign to function call
>
> Do we really need this restriction? There do exist other languages without
> it.
What?
I mean...what are you even talking about?
Assignmen
def F(x):
return x
x = 2
F(x) = 3
F(x) = 3
SyntaxError: can't assign to function call
Do we really need this restriction? There do exist other languages without it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
larry.hastings wrote:
> +Establishes that all the *proceeding* arguments are
> +positional-only. For now, Argument Clinic does not
> +support functions with both positional-only and
> +non-positional-only arguments; therefore, if ``/``
> +is specified for a function, currently
Larry Hastings wrote:
> * The DSL currently makes no provision for specifying per-parameter
> type annotations. This is something explicitly supported in Python;
> it should be supported for builtins too, once we have reflection support.
>
> It seems to me that the syntax for parameter lin
Larry Hastings wrote:
> So I hope that at least converters can be declared statically in a header
> file, like I suggested in PEP 437.
>
>
> The Argument Clinic prototype is written in Python; I don't know how "declared
> static in a header file" applies to a Python implementation. Curr
On 18 Mar, 2013, at 8:16, Larry Hastings wrote:
>
> This has some consequences. For example, inspect.getfullargspec,
> inspect.Signature, and indeed types.FunctionObject and types.CodeObject have
> no currently defined mechanism for communicating that a parameter is
> positional-only. I st
On 03/18/2013 12:16 AM, Larry Hastings wrote:
I'll amend my PEP soonish to reflect this. Specifically the semantics
of the /, [, and ] lines in the parameter section.
I've just posted this revision.
I'd like to draw everyone's attention to the top entry in the Notes
section, reproduced bel
On 03/17/2013 03:26 PM, Stefan Krah wrote:
While I like the syntax better and appreciate the option to condense the
function declaration I still fear that the amount of implicitness will
distract from what is important: programming in C.
This applies especially if people start declaring conver
35 matches
Mail list logo
