Summary:
*Every* Parameter attribute is optional, even name. (Think of
builtins, even if they aren't automatically supported yet.)
So go ahead and define some others that are sometimes useful.
Instead of defining a BoundArguments class, just return a copy
of the Signature, w
On 05/31/2012 09:47 AM, "Martin v. Löwis" wrote:
I hereby predict that Microsoft will revert this decision, and that
VS Express 11 will be able to build CPython.
But will it be able to target Windows XP?
I have now tried, and it seems that the chances are really low (unless
you use th
2012/6/15 Larry Hastings :
> Note that I'm genuinely interested in your answer--"is_implemented" appears
> to have a groundswell of anti-support and I rather suspect will be axed.
> Meantime I still need to solve this problem.
How about a list of functions that support it. Then you could do things
> Right now we have no way to automatically generate signatures for built-in
> functions. So, as of current trunk, any such signatures would have to be
> built by hand.
>
> If we could somehow produce signature information in C, what then? Two
> possible approaches suggest themselves:
>
> Pre-gen
Am 15.06.2012 23:38, schrieb Yury Selivanov:
> Although, Larry added __signature__ attribute to PyCFunctionObject
> (None by default_. So those, who want to manually create signatures
> for their 'C' functions would be able to do that.
As I explained in my other posting: You can't add a mutable
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
-0.5
It is easier to add it later if it is needed, then to take it away if not
needed.
2
Am 15.06.2012 23:03, schrieb R. David Murray:
> The issue isn't "consenting adults", the issue is consistency.
> Without the deepcopy, sometimes what you get back from the
> inspect function is freely modifiable and sometimes it is not.
> That inconsistency is a bad thing.
This must be addressed o
On Sat, 16 Jun 2012 07:48:19 +1000
Steven D'Aprano wrote:
>
> The introduction of BindError will allow functions to raise a more specific,
> and less misleading, exception when they are called with the wrong number of
> arguments, or invalid keywords, etc.
If that's what you want, a separate P
Yury Selivanov wrote:
On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote:
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov wrote:
* bind(\*args, \*\*kwargs) -> BoundArguments
Creates a mapping from positional and keyword arguments to
parameters. Raises a ``BindError`` (subclass of ``Type
On 06/15/2012 02:13 PM, Antoine Pitrou wrote:
I'm not sure I understand. The PEP already says signatures are computed
lazily. Is there an exception for built-in functions?
Right now we have no way to automatically generate signatures for
built-in functions. So, as of current trunk, any such
On 2012-06-15, at 5:35 PM, Yury Selivanov wrote:
> On 2012-06-15, at 5:30 PM, Antoine Pitrou wrote:
>
>> On Fri, 15 Jun 2012 17:26:25 -0400
>> Yury Selivanov wrote:
>>
>>> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>>>
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov wrote:
>
On 2012-06-15, at 5:30 PM, Antoine Pitrou wrote:
> On Fri, 15 Jun 2012 17:26:25 -0400
> Yury Selivanov wrote:
>
>> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>>
>>> On Fri, 15 Jun 2012 17:07:46 -0400
>>> Yury Selivanov wrote:
On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
[sn
On 2012-06-15, at 5:24 PM, Larry Hastings wrote:
[snip]
> I'm happy to do the work, but I don't have a good sense of which callables
> need a __signature__ attribute. Can someone here tell me which ones might
> need a __signature__ attribute?
I think may we need to be able to write __signature_
On Fri, 15 Jun 2012 17:26:25 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>
> > On Fri, 15 Jun 2012 17:07:46 -0400
> > Yury Selivanov wrote:
> >> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> >> [snip]
> >>> Would it be possible to only create a signature
On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
> On Fri, 15 Jun 2012 17:07:46 -0400
> Yury Selivanov wrote:
>> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
>> [snip]
>>> Would it be possible to only create a signature for builtin the first
>>> time that you read its __signature__ attribute?
One wrinkle of PEP 362 in CPython is callables implemented directly in
C. Right now there's no good way to generate such signatures
automatically. That's why we kept __signature__ in the spec, to allow
implementors to generate signatures by hand for these callables.
But the wrinkle gets w
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> [snip]
> > Would it be possible to only create a signature for builtin the first
> > time that you read its __signature__ attribute? I don't know how to
> > implement such behaviour on a b
On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
[snip]
> Would it be possible to only create a signature for builtin the first
> time that you read its __signature__ attribute? I don't know how to
> implement such behaviour on a builtin function. I don't know if it's
> important to decide this rig
On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner
wrote:
> > 1. Should we keep 'Parameter.implemented' or not. Â *Please vote*
-1 to implemented.
> I still disagree with the deepcopy. I read somewhere that Python
> developers are consenting adult. If someone really want to modify a
> Signature
> 1. Should we keep 'Parameter.implemented' or not. *Please vote*
It looks like only few functions of the os module will use it. Even
for the os module, I'm not convinced that it is the appropriate
solution to indicate if a feature is supported or not. I would prefer
something like os.path.suppor
-1 implemented
It appears to target the problem of platform-dependent parameters.
However as was discussed previously, much more common than a parameter
simply not being supported on a platform is a parameter supporting
different values on different platforms. As such, I think that it
solves too s
On Fri, 15 Jun 2012 15:50:25 -0400
Yury Selivanov wrote:
>
> Open questions:
>
> 1. Should we keep 'Parameter.implemented' or not. *Please vote*
-1 to keeping it.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On 06/15/2012 12:50 PM, Yury Selivanov wrote:
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
+1 to keeping Parameter.implemented.
Let's get this over with,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. Signature's 'is_args', 'is_kwargs', 'is_keyword_only' were all
replaced with a single 'kind' attribute (Nick, I borrowed your
description of 'kind' attribute and its possible values.)
2.
On 06/15/2012 12:34 PM, Yury Selivanov wrote:
On 2012-06-15, at 3:31 PM, Larry Hastings wrote:
(Perhaps the right thing would be to take this discussion to issue 14626.)
Let's keep it in this thread while it's related to Signature.
I can assure you, however Benjamin might spell it, it won't u
On 2012-06-15, at 3:31 PM, Larry Hastings wrote:
> (Perhaps the right thing would be to take this discussion to issue 14626.)
Let's keep it in this thread while it's related to Signature.
-
Yury
___
Python-Dev mailing list
Python-Dev@python.org
http://
On 06/15/2012 12:06 PM, Benjamin Peterson wrote:
2012/6/15 Larry Hastings:
On 06/15/2012 11:46 AM, R. David Murray wrote:
Adding a os.have_openat seems more reasonable than adding is_implemented
to every __signature__ object. And more useful, as well; it provides
a much more specific piece of
2012/6/15 Larry Hastings :
> On 06/15/2012 11:46 AM, R. David Murray wrote:
>
> Adding a os.have_openat seems more reasonable than adding is_implemented
> to every __signature__ object. And more useful, as well; it provides
> a much more specific piece of information.
>
>
> We already have "os.hav
On 06/15/2012 11:46 AM, R. David Murray wrote:
Adding a os.have_openat seems more reasonable than adding is_implemented
to every __signature__ object. And more useful, as well; it provides
a much more specific piece of information.
We already have "os.have_openat"; it's spelled
sysconfig.get_
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote:
2012/6/15 Larry Hastings:
If I understand you correctly, you seem to be trying to apply
"is_implemented" to the problem of predicting which specific inputs to a
parameter would be valid. I don't think that problem is tractable--it's w
On Fri, 15 Jun 2012 11:17:09 -0700, Larry Hastings wrote:
> On 06/15/2012 04:32 AM, Nick Coghlan wrote:
> > Since I don't believe your proposed flag will answer any question that
> > actually matters in practice, I consider it useless noise that should
> > be dropped from the proposal.
>
> I can
On 06/15/2012 04:32 AM, Nick Coghlan wrote:
Since I don't believe your proposed flag will answer any question that
actually matters in practice, I consider it useless noise that should
be dropped from the proposal.
I can cite a situation where it matters in practice: the implementation
of os.
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote:
> 2012/6/15 Larry Hastings :
>> If I understand you correctly, you seem to be trying to apply
>> "is_implemented" to the problem of predicting which specific inputs to a
>> parameter would be valid. I don't think that problem is tractable-
2012/6/15 Larry Hastings :
> If I understand you correctly, you seem to be trying to apply
> "is_implemented" to the problem of predicting which specific inputs to a
> parameter would be valid. I don't think that problem is tractable--it's way
> too context-specific.
Exactly! It's too context sen
ACTIVITY SUMMARY (2012-06-08 - 2012-06-15)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3472 (+12)
closed 23384 (+30)
total 26856 (+42)
Open issues wit
On 15 June 2012 12:32, Nick Coghlan wrote:
> Now, what a function *could* do is set __signature__ to a Signature
> subclass that provided an additional "validate()" method, or provided
> arbitrary additional information about supported features. That's a
> perfectly reasonable option.
It might be
On Fri, Jun 15, 2012 at 9:25 PM, Yury Selivanov wrote:
> On 2012-06-14, at 11:21 PM, Nick Coghlan wrote:
>> On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
>> wrote:
>>> On 2012-06-14, at 7:16 PM, Nick Coghlan wrote:
>>>
POSITIONAL_ONLY
POSITIONAL_OR_KEYWORD
VAR_POSITIONAL
KE
On Fri, Jun 15, 2012 at 8:51 PM, Larry Hastings wrote:
> If I understand you correctly, you seem to be trying to apply
> "is_implemented" to the problem of predicting which specific inputs to a
> parameter would be valid. I don't think that problem is tractable--it's way
> too context-specific.
On 2012-06-14, at 11:21 PM, Nick Coghlan wrote:
> On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
> wrote:
>> On 2012-06-14, at 7:16 PM, Nick Coghlan wrote:
>>
>>> POSITIONAL_ONLY
>>> POSITIONAL_OR_KEYWORD
>>> VAR_POSITIONAL
>>> KEYWORD_ONLY
>>> VAR_KEYWORD
>>
>> I like those. A bit too length
On 06/15/2012 12:18 AM, Nick Coghlan wrote:
Perhaps you meant "ill-concieved"?
No, I mean ill-defined. The criteria for when a particular platform
should flip that bit for an arbitrary parameter is highly unclear, as
whether or not a particular parameter is "implemented" or not depends
on the o
On Fri, Jun 15, 2012 at 8:43 AM, Eli Bendersky wrote:
> Hi,
>
> I committed a significant patch to _elementtree, which causes some bots to
> fail on test_xml_etree[_c]. I'm currently investigating the possible cause
> of this - and will be disabling a couple of tests in the suite temporarily,
> s
R. David Murray wrote:
We know that a string cannot be both all-upper and all-lower at the same
time;
We know that because it's common wisdom for everyone (although who knows
what oddities the unicode consortium may come up with in the future).
Indeed, there is at least one letter that is use
On Thu, 14 Jun 2012 21:43:34 -0700
Larry Hastings wrote:
> On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
> > 2012/6/14 Larry Hastings:
> >> Also, it's more granular than that. For example, Python now understands
> >> symbolic links on Windows--but only haphazardly at best. The
> >> "follow_s
On Fri, Jun 15, 2012 at 3:23 PM, Larry Hastings wrote:
> I disagree with the description "ill-defined". I would be very surprised
> indeed if either you or Benjamin genuinely didn't understand exactly what
> "is_implemented" represents. If you're suggesting that the documentation is
> inadequate
44 matches
Mail list logo
