Re: [Python-Dev] PEP 362 Third Revision
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 we can certainly address that. > > 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 operation and the parameter. Let's take the "buffering" parameter to the open() builtin. It has three interesting settings: - unbuffered - line buffered - fixed size buffering What counts as "implemented" in that case? Supporting all 3? At least 2? Any 1 of them? If there's a maximum (or minimum) buffer size, does that still count as implemented? To know what "is_implemented" means for any given parameter, it's going to have to be documented *for that parameter*. In that case, better to define an interface specific mechanism that lets people ask the questions they want to ask. It's not appropriate to lump it into a general purpose introspection facility (certainly not one that hasn't even been added yet). 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] PEP 362 Third Revision
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_symlinks" argument works on Windows for os.stat() but not for > >> os.chmod(). > > Then indeed it's more granular than a parameter being "implemented" or > > not. A parameter may have a more restricted or extended meaning on > > different operating systems. (sendfile() on files for example). > > If you can suggest a representation that can convey this sort of subtle > complexity without being miserable to use, I for one would be very > interested to see it. I suggest that "is_implemented" solves a > legitimate problem in a reasonable way; I wasn't attempting to be all > things to all use cases. I don't think it solves a legitimate problem. As Benjamin pointed out, people want to know whether a functionality is supported, not whether a specific parameter is "implemented". Also, the incantation to look up that information on a signature object is definitely too complicated to be helpful. Regards Antoine. ___ 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] PEP 362 Third Revision
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 used in both upper case and lower case, so the consortium could reasonably declare that it should return True for both isupper and islower :). If you're talking about the German double-s ß, technically it is a lowercase letter and should be written as SS or SZ in uppercase. Just to add complication, historically German used to have an uppercase ß, and in recent years some designers have started to reintroduce it. (Note: I am not a German speaker, and everything I say above is taken from Wikipedia.) -- 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] investigating bot failures for ElementTree
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, > since the problems are most likely due to the ugly monkey-patching the > test_xml_etree is based on. > > Eli > > That's it, the stable bots are fairly green now. Some Windows failures were there before my commits also (seems like there's instability in some tests, like Locks). One test in test_xml_etree remains disabled for the time being. I've opened http://bugs.python.org/issue15075 to track this and will continue to investigate. The problem most likely happens due to the monkey-patching done by the test to import the Python and not the C implementation of ET. Since it's the test that is problematic and not the implementation, I've only marked the issue priority as "normal". Anyone partial to debugging hairy import-related problems, feel free to chime in ;-) Eli ___ 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] PEP 362 Third Revision
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 operation and the parameter. I guess I really did do a poor job of explaining it then. Here's another pass. My working definition for "is_implemented" is "is this functionality available at all?" Pressed to produce a stricter definition, I *would* define "is_implemented" as: True if it is possible to produce any valid inputs for the parameter on the current platform, and False otherwise. However, I don't think parameters should be added and removed from a function's signature based on what functionality is available on the local platform--that way lies madness. Instead I think it best to define a no-op default value for every optional parameter, and always accept that even when the functionality behind it isn't locally available.Function signatures should be stable. Therefore I amend the definition to: True if it is possible to produce any valid non-default inputs for the parameter on the current platform, and False otherwise. 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. //arry/ ___ 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] PEP 362 Third Revision
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 lengthy and verbose, but the names >> are consistent. > > In this case, I'm willing to trade a bit of verbosity for accuracy. It > also suggests a possible, more explicit name for the attribute: > "binding". Can we keep it called 'kind'? While technically 'binding' is more precise description for this, it's not as intuitive as 'kind'. Thank you, - Yury ___ 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] PEP 362 Third Revision
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. Correct, but the more important point is that I don't think the question you're proposing to ask is worth answering. I *don't care* if there is some value that's supported on the current platform, I only care if the value *I am about to pass* is supported. 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. To go back to my simple buffering parameter example: 1. A hypothetical platform supports line buffered and fixed chunk buffered IO. Therefore, it sets the "is_implemented" flag for "buffering" to True (under your proposed definition) 2. My LBYL program checks the flag, sees that it is implemented and passes "buffering=0" 3. My program fails with NotImplementedError or UnsupportedOperationError, since my LBYL check wasn't strict enough A simple "is this parameter implemented?" does not provide enough useful information to be justify being part of the standard signature objects. 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. But what we definitely *shouldn't* be doing is supporting a niche use case directly on Parameter objects without allowing adequate time to explore alternative solutions that may be better in the long run. 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] PEP 362 Third Revision
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 KEYWORD_ONLY VAR_KEYWORD >>> >>> I like those. A bit too lengthy and verbose, but the names >>> are consistent. >> >> In this case, I'm willing to trade a bit of verbosity for accuracy. It >> also suggests a possible, more explicit name for the attribute: >> "binding". > > Can we keep it called 'kind'? > > While technically 'binding' is more precise description for this, it's > not as intuitive as 'kind'. Sure, I'm still OK with "kind". 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] PEP 362 Third Revision
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 worth mentioning this option in the PEP - it hadn't occurred to me that using subclasses of Signature would be something people could do... Having said that, I also find it hard to imagine a case where I'd check is_implemented (Larry's explanation notwithstanding). Paul ___ 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] Summary of Python tracker Issues
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 with patches: 1464 Issues opened (31) == #14599: Windows test_import failure thanks to ImportError.path http://bugs.python.org/issue14599 reopened by skrah #15037: test_curses fails with OverflowError http://bugs.python.org/issue15037 opened by jcbollinger #15038: Optimize python Locks on Windows http://bugs.python.org/issue15038 opened by kristjan.jonsson #15039: module/ found before module.py when both are in the CWD http://bugs.python.org/issue15039 opened by strombrg #15040: stdlib compatability with pypy: mailbox.py http://bugs.python.org/issue15040 opened by mattip #15041: tkinter documentation: update "see also" list http://bugs.python.org/issue15041 opened by weirdink13 #15042: Implemented PyState_AddModule, PyState_RemoveModule http://bugs.python.org/issue15042 opened by Robin.Schreiber #15043: test_gdb is disallowed by default security settings in Fedora http://bugs.python.org/issue15043 opened by ncoghlan #15044: _dbm not building on Fedora 17 http://bugs.python.org/issue15044 opened by ncoghlan #15045: Make textwrap.dedent() consistent with str.splitlines(True) an http://bugs.python.org/issue15045 opened by ncoghlan #15047: Cygwin install (regen) problem http://bugs.python.org/issue15047 opened by jlt63 #15049: line buffering isn't always http://bugs.python.org/issue15049 opened by r.david.murray #15050: Python 3.2.3 fail to make http://bugs.python.org/issue15050 opened by shojnhv #15052: Outdated comments in build_ssl.py http://bugs.python.org/issue15052 opened by jkloth #15053: imp.lock_held() "Changed in Python 3.3" mention accidentally o http://bugs.python.org/issue15053 opened by brett.cannon #15054: bytes literals erroneously tokenized http://bugs.python.org/issue15054 opened by flox #15055: dictnotes.txt is out of date http://bugs.python.org/issue15055 opened by Mark.Shannon #15056: Have imp.cache_from_source() raise NotImplementedError when ca http://bugs.python.org/issue15056 opened by brett.cannon #15061: hmac.secure_compare() leaks information about length of string http://bugs.python.org/issue15061 opened by christian.heimes #15062: argparse: option for a positional argument http://bugs.python.org/issue15062 opened by wrobell #15063: Source code links for JSON documentation http://bugs.python.org/issue15063 opened by louiscipher #15064: multiprocessing should use more context manager http://bugs.python.org/issue15064 opened by sbt #15066: make install error: ImportError: No module named _struct http://bugs.python.org/issue15066 opened by suzhengchun #15067: sqlite3 docs reference PEP 246, which was rejected http://bugs.python.org/issue15067 opened by zach.ware #15068: fileinput requires two EOF when reading stdin http://bugs.python.org/issue15068 opened by jason.coombs #15071: TLS get keys and randoms http://bugs.python.org/issue15071 opened by llaniscudani #15074: Strange behaviour of python cmd module. (Ignores slash) http://bugs.python.org/issue15074 opened by jsevilleja #15075: XincludeTest failure in test_xml_etree http://bugs.python.org/issue15075 opened by eli.bendersky #15076: Sometimes couldn't import os, shown 'import site' failed, use http://bugs.python.org/issue15076 opened by qtld614 #15077: Regexp match goes into infinite loop http://bugs.python.org/issue15077 opened by moriyoshi #15078: Change os.sendfile so its arguments are stable http://bugs.python.org/issue15078 opened by larry Most recent 15 issues with no replies (15) == #15076: Sometimes couldn't import os, shown 'import site' failed, use http://bugs.python.org/issue15076 #15064: multiprocessing should use more context manager http://bugs.python.org/issue15064 #15063: Source code links for JSON documentation http://bugs.python.org/issue15063 #15054: bytes literals erroneously tokenized http://bugs.python.org/issue15054 #15045: Make textwrap.dedent() consistent with str.splitlines(True) an http://bugs.python.org/issue15045 #15039: module/ found before module.py when both are in the CWD http://bugs.python.org/issue15039 #15037: test_curses fails with OverflowError http://bugs.python.org/issue15037 #15032: Provide a select.select implemented using select.poll http://bugs.python.org/issue15032 #15025: httplib and http.client are missing response messages for defi http://bugs.python.org/issue15025 #15018: Incomplete Python LDFLAGS and CPPFLAGS used for extension modu http://bugs.python.org/issue15018 #15010: unittest: _top_level_dir is incorrectly persisted between call http://bugs.python.org/issue15010 #14999: ctypes ArgumentError lists arguments from 1, not 0 http://bugs.python.org/issu
Re: [Python-Dev] PEP 362 Third Revision
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 sensitive to belong on a generic signature object. Without is_implemented, all the properties of the signature object should only change if you alter the parameter list. How a parameter is dealt with in the function should not affect the signature of a function. -- 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] PEP 362 Third Revision
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 way >> too context-specific. > > Exactly! It's too context sensitive to belong on a generic signature > object. Without is_implemented, all the properties of the signature > object should only change if you alter the parameter list. How a > parameter is dealt with in the function should not affect the > signature of a function. > I agree. It seems to me is_implemented solves too small a class of the problem it attacks to be worth including in the signature. > > -- > 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/alexandre.zani%40gmail.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] PEP 362 Third Revision
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.fwalk is effectively gated on hasattr(posix, "openat"). I expect to remove openat() in favor of adding a dir_fd parameter to open (see issue 14626). 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. What would the validate() function for os.close do? //arry/ ___ 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] PEP 362 Third Revision
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 cite a situation where it matters in practice: the implementation > of os.fwalk is effectively gated on hasattr(posix, "openat"). I expect > to remove openat() in favor of adding a dir_fd parameter to open (see > issue 14626). I don't think that justifies adding an attribute to __signature__, though. As someone pointed out, it isn't part of the function's signature, it is part of the function's function. 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. > > 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. > > What would the validate() function for os.close do? Why would you need one? --David ___ 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] PEP 362 Third Revision
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 way too context-specific. Exactly! It's too context sensitive to belong on a generic signature object. Without is_implemented, all the properties of the signature object should only change if you alter the parameter list. How a parameter is dealt with in the function should not affect the signature of a function. My opinion is that function introspection allows you to answer questions about that function, and the question "Can I use this parameter at all?" is relevant. On 06/15/2012 10:21 AM, Alexandre Zani wrote: I agree. It seems to me is_implemented solves too small a class of the problem it attacks to be worth including in the signature. I concede that I appear to be in an extremely small minority. (Has a single other person stepped forward in support of is_implemented? I don't recall one.) //arry/ ___ 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] PEP 362 Third Revision
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_config_var('HAVE_OPENAT'). But, assuming I land issue
14626, this leads us to:
Q: Can I use the dir_fd parameter to os.open?
A: Only if sysconfig.get_config_var('HAVE_OPENAT') is true.
Q: Can I use the fd parameter to os.utime?
A: Only if sysconfig.get_config_var('HAVE_FUTIMENS') or
sysconfig.get_config_var('HAVE_FUTIMES') is true.
I feel this interface lacks civility.
//arry/
___
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] PEP 362 Third Revision
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.have_openat"; it's spelled
> sysconfig.get_config_var('HAVE_OPENAT'). But, assuming I land issue 14626,
> this leads us to:
>
> Q: Can I use the dir_fd parameter to os.open?
> A: Only if sysconfig.get_config_var('HAVE_OPENAT') is true.
>
> Q: Can I use the fd parameter to os.utime?
> A: Only if sysconfig.get_config_var('HAVE_FUTIMENS') or
> sysconfig.get_config_var('HAVE_FUTIMES') is true.
>
> I feel this interface lacks civility.
There's no reason this couldn't be wrapped into some sort of os level
attribute or function.
--
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] PEP 362 Third Revision
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 information.
We already have "os.have_openat"; it's spelled
sysconfig.get_config_var('HAVE_OPENAT'). But, assuming I land issue 14626,
this leads us to:
Q: Can I use the dir_fd parameter to os.open?
A: Only if sysconfig.get_config_var('HAVE_OPENAT') is true.
Q: Can I use the fd parameter to os.utime?
A: Only if sysconfig.get_config_var('HAVE_FUTIMENS') or
sysconfig.get_config_var('HAVE_FUTIMES') is true.
I feel this interface lacks civility.
There's no reason this couldn't be wrapped into some sort of os level
attribute or function.
No, but how would you spell it in a graceful way? It really is specific
to a particular parameter on a particular function. And there are a
bunch of parameters that are available if any one of a couple C
functions is locally available--fd and follow_symlinks on utime,
follow_symlinks on chown. follow_symlinks for stat is available if you
have lstat *or* you're on Windows. ('HAS_LSTAT' isn't set on Windows,
we don't use configure there.) So certainly I don't like the idea of
just checking if the C function(s) is (are) available.
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.
I can't say I like any of these:
os.can_use(os.stat, "fd") # too generic
os.can_use_fd(os.stat) # too specific
Binding it to the function itself seems to be Just Right to me. But
since they're PyCFunctionObjects I can't add arbitrary attributes.
(Perhaps the right thing would be to take this discussion to issue 14626.)
//arry/
___
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] PEP 362 Third Revision
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 [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] PEP 362 Third Revision
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 use Signature ;-) //arry/ ___ 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] PEP 362: 4th edition
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. 'signature()' checks for the '__wrapped__' attribute on all callables. 3. 'POSITIONAL_ONLY' parameters should be fully supported by 'bind()' and other Signature class methods. Open questions: 1. Should we keep 'Parameter.implemented' or not. *Please vote* 2. Should 'Signature.format()' instead of 7 or so arguments accept just a SignatureFormatter class, that implements all the formatting logic, that is easy to override? All in all, I think that the PEP is almost ready for the acceptance. As 3.3 beta 1 is just a week away, I want to ask for BDFAP (Nick?) Please also do the patch review: http://bugs.python.org/issue15008 Thank you! PEP: 362 Title: Function Signature Object Version: $Revision$ Last-Modified: $Date$ Author: Brett Cannon , Jiwon Seo , Yury Selivanov , Larry Hastings Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Aug-2006 Python-Version: 3.3 Post-History: 04-Jun-2012 Abstract Python has always supported powerful introspection capabilities, including introspecting functions and methods (for the rest of this PEP, "function" refers to both functions and methods). By examining a function object you can fully reconstruct the function's signature. Unfortunately this information is stored in an inconvenient manner, and is spread across a half-dozen deeply nested attributes. This PEP proposes a new representation for function signatures. The new representation contains all necessary information about a function and its parameters, and makes introspection easy and straightforward. However, this object does not replace the existing function metadata, which is used by Python itself to execute those functions. The new metadata object is intended solely to make function introspection easier for Python programmers. Signature Object A Signature object represents the call signature of a function and its return annotation. For each parameter accepted by the function it stores a `Parameter object`_ in its ``parameters`` collection. A Signature object has the following public attributes and methods: * return_annotation : object The annotation for the return type of the function if specified. If the function has no annotation for its return type, this attribute is not set. * parameters : OrderedDict An ordered mapping of parameters' names to the corresponding Parameter objects (keyword-only arguments are in the same order as listed in ``code.co_varnames``). * bind(\*args, \*\*kwargs) -> BoundArguments Creates a mapping from positional and keyword arguments to parameters. Raises a ``TypeError`` if the passed arguments do not match the signature. * bind_partial(\*args, \*\*kwargs) -> BoundArguments Works the same way as ``bind()``, but allows the omission of some required arguments (mimics ``functools.partial`` behavior.) Raises a ``TypeError`` if the passed arguments do not match the signature. * format(...) -> str Formats the Signature object to a string. Optional arguments allow for custom render functions for parameter names, annotations and default values, along with custom separators. Signature implements the ``__str__`` method, which fallbacks to the ``Signature.format()`` call. It's possible to test Signatures for equality. Two signatures are equal when they have equal parameters and return annotations. Changes to the Signature object, or to any of its data members, do not affect the function itself. Parameter Object Python's expressive syntax means functions can accept many different kinds of parameters with many subtle semantic differences. We propose a rich Parameter object designed to represent any possible function parameter. The structure of the Parameter object is: * name : str The name of the parameter as a string. * default : object The default value for the parameter, if specified. If the parameter has no default value, this attribute is not set. * annotation : object The annotation for the parameter if specified. If the parameter has no annotation, this attribute is not set. * kind : str Describes how argument values are bound to the parameter. Possible values: * ``Parameter.POSITIONAL_ONLY`` - value must be supplied as a positional argument. Python has no explicit syntax for defining positional-only parameters, but many builtin and extension module functions (especially those that accept only one or two parameters) accept them. * ``Parameter.POSITIONAL_OR_KEYWORD`` - value may be supplied as either a keyword or positiona
Re: [Python-Dev] PEP 362: 4th edition
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 [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] PEP 362: 4th edition
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 [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] PEP 362: 4th edition
-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 small a sub-set of the problem that it attacks to be useful. Raising exceptions solves the problem. Furthermore, whether a parameter is implemented or not is not properly a part of the callable's signature. It's a part of the function's internals. On Fri, Jun 15, 2012 at 12:56 PM, Larry Hastings wrote: > 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.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] PEP 362: 4th edition
> 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.supports_unicode_filename, hasattr(os, 'fork'), or something else. And such attribute might only be useful if changes proposed in the issue #14626 are accepted, but the issue is still open and not everybody do agree on the idea... > - If the object has a ``__signature__`` attribute and if it > is not ``None`` - return a deepcopy of it I still disagree with the deepcopy. I read somewhere that Python developers are consenting adult. If someone really want to modify a Signature, it would be nice to provide a simple method to copy it. But I don't see why it should be copied *by default*. I expect that modifying a signature is more rare than just reading a signature. > - If it is ``None`` and the object is an instance of > ``BuiltinFunction``, raise a ``ValueError`` 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 right now. I don't want to create a signature at startup if it is not used, because it would waste memory (as docstrings? :-)). Or we might drop __signature__ if python -O is used? Victor ___ 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] PEP 362: 4th edition
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, it would be nice to provide a simple method to copy it. But > I don't see why it should be copied *by default*. I expect that > modifying a signature is more rare than just reading a signature. 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. --David ___ 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] PEP 362: 4th edition
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 right now. > > I don't want to create a signature at startup if it is not used, > because it would waste memory (as docstrings? :-)). I think when we have the working mechanism to generate them in place, we can make it lazy. > Or we might drop > __signature__ if python -O is used? No, that'd be unacceptable. - Yury ___ 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] PEP 362: 4th edition
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 builtin function. I don't know if it's > > important to decide this right now. > > > > I don't want to create a signature at startup if it is not used, > > because it would waste memory (as docstrings? :-)). > > I think when we have the working mechanism to generate them in place, > we can make it lazy. I'm not sure I understand. The PEP already says signatures are computed lazily. Is there an exception for built-in functions? Regards Antoine. ___ 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] PEP 362 implementation issue: C callables
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 wrinklier. The problem is, you often can't add arbitrary attributes to these objects: >>> import os >>> os.stat.random_new_attribute = 3 Traceback (most recent call last): File "", line 1, in AttributeError: 'builtin_function_or_method' object has no attribute 'random_new_attribute' If users are to attach precomputed signatures to callables implemented in C, those callables may need to *already* have a __signature__ attribute. I've already added __signature__ to PyCFunctionObject in the PEP 362 patch. This takes care of the vast bulk of such callables. But there are a bunch of obscure callable objects in CPython, and I suspect some of them may need a __signature__ attribute. Here's an almost- complete list, listed as their Python type: functools.KeyWrapper (result of functools.cmp_to_key) weakref.weakref method (bound method objects, aka "x = Class(); x.method") instancemethod (is this still even used? it's never used in trunk) operator.itemgetter operator.attrgetter operator.methodcaller _json.Scanner (result of _json.make_scanner) _json.Encoder (result of _json.make_encoder) _ctypes.DictRemover (I'm not even sure how you can get your hands on one of these) sqlite3.Connection I produced this by grepping for "/* tp_call */" and ignoring all of them that were set to "0", then creating one of those objects and trying (and failing) to set a __signature__ attribute. There are four more candidates I found with the grep but couldn't figure out how to instantiate and test. They have to do with the descriptor protocol, aka properties, but the types aren't directly exposed by Python. They're all defined in Object/descrobject.c. The internal class names are: method_descriptor classmethod_descriptor wrapper_descriptor method-wrapper (you get one of these out of a "wrapper_descriptor") 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? //arry/ ___ 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] PEP 362: 4th edition
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? I don't know how to >>> implement such behaviour on a builtin function. I don't know if it's >>> important to decide this right now. >>> >>> I don't want to create a signature at startup if it is not used, >>> because it would waste memory (as docstrings? :-)). >> >> I think when we have the working mechanism to generate them in place, >> we can make it lazy. > > I'm not sure I understand. The PEP already says signatures are computed > lazily. Is there an exception for built-in functions? Right now, if there is no '__signature__' attribute set on a builtin function - there is no way of generating it (PyCFunctionObject doesn't have __code__), so a ValueError will be raised. Maybe, if in the future we replace PyArg_ParseTuple and family with something, that can generate metadata for builtins (or generate Signature object, or generate some callable that generates it, or something else) we make 'signature()' use it. But again, that's not for 3.3. And yes, signature() is still lazy. - Yury ___ 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] PEP 362: 4th edition
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 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 right now. > >>> > >>> I don't want to create a signature at startup if it is not used, > >>> because it would waste memory (as docstrings? :-)). > >> > >> I think when we have the working mechanism to generate them in place, > >> we can make it lazy. > > > > I'm not sure I understand. The PEP already says signatures are computed > > lazily. Is there an exception for built-in functions? > > Right now, if there is no '__signature__' attribute set on a builtin > function - there is no way of generating it (PyCFunctionObject doesn't > have __code__), so a ValueError will be raised. Ok, but what does this mean for 3.3? Does the PEP propose that all builtins get a non-lazy __signature__, or simply that ValueError always be raised? Regards Antoine. ___ 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] PEP 362 implementation issue: C callables
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__ attribute
to 'classmethod', 'staticmethod', 'functools.partial' and
'method' ('types.MethodType').
-
Yury
___
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] PEP 362: 4th edition
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: [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 right now. > > I don't want to create a signature at startup if it is not used, > because it would waste memory (as docstrings? :-)). I think when we have the working mechanism to generate them in place, we can make it lazy. >>> >>> I'm not sure I understand. The PEP already says signatures are computed >>> lazily. Is there an exception for built-in functions? >> >> Right now, if there is no '__signature__' attribute set on a builtin >> function - there is no way of generating it (PyCFunctionObject doesn't >> have __code__), so a ValueError will be raised. > > Ok, but what does this mean for 3.3? Does the PEP propose that all > builtins get a non-lazy __signature__, or simply that ValueError always > be raised? Simply ValueError. - Yury ___ 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] PEP 362: 4th edition
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 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 right now. >> >> I don't want to create a signature at startup if it is not used, >> because it would waste memory (as docstrings? :-)). > > I think when we have the working mechanism to generate them in place, > we can make it lazy. I'm not sure I understand. The PEP already says signatures are computed lazily. Is there an exception for built-in functions? >>> >>> Right now, if there is no '__signature__' attribute set on a builtin >>> function - there is no way of generating it (PyCFunctionObject doesn't >>> have __code__), so a ValueError will be raised. >> >> Ok, but what does this mean for 3.3? Does the PEP propose that all >> builtins get a non-lazy __signature__, or simply that ValueError always >> be raised? > > Simply ValueError. 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. - Yury ___ 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] PEP 362: 4th edition
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 signatures would have to be built by hand. If we could somehow produce signature information in C, what then? Two possible approaches suggest themselves: 1. Pre-generate the signatures and cache them in the __signature__ attribute. 2. Add a callback, perhaps named __get_signature__(), which calculates the signature and returns it. Both approaches have downsides. The former means generation is not lazy and therefore consumes more memory. The latter adds a new attribute to builtin functions. Which is a better approach? Who knows? We don't even have the signature information in C yet. As we all learned from Star Trek VI, the future is an undiscovered country. So the PEP deliberately makes no ruling here. //arry/ ___ 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] PEP 362 Third Revision
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 ``TypeError``)
if the passed arguments do not match the signature.
Why a dedicated exception class? TypeError is good enough, and the
proliferation of exception classes is a nuisance.
Agree. Will fix this.
It's not broken. Within reason, more specific exceptions are better than less
specific.
I have always considered it a wart that there was no supported way to
programmatically distinguish between (say) len(42) and len("a", "b"). Both
raise TypeError. Why is the second case a type error? It has nothing to do
with the type of either len, "a" or "b".
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.
--
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] PEP 362 Third Revision
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 PEP is needed. Right now we are talking about using it only in the context of PEP 362, where it is not useful over a plain TypeError (bind() only binds, so there is no possible confusion between different "kinds" of TypeErrors). Regards Antoine. ___ 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] PEP 362: 4th edition
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 one way or the other. Otherwise you will break isolation of sub interpreters. Builtin objects, types and methods *must* be immutable because they are shared across subinterpreters. This topic has been addressed by the PEP. Proposal: You could store the signature objects for builtin methods in a dict in each PyInterpreterState and use the qualname to reference the signature object. This ensures full isolation. Christian ___ 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] PEP 362: 4th edition
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. Should 'Signature.format()' instead of 7 or so arguments accept just a SignatureFormatter class, that implements all the formatting logic, that is easy to override? -1 It is easier to pass different arguments to a function than it is to subclass and modify a class. -- 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] PEP 362: 4th edition
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 attribute to builtin functions and types. It breaks the isolation between subinterpreters. Christian ___ 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] PEP 362: 4th edition
> 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-generate the signatures and cache them in the __signature__ attribute. This solution has an impact on memory footpring. > Add a callback, perhaps named __get_signature__(), which calculates the > signature and returns it. This might be decided before the PEP is accepted, because this is a new attribute not listed in the PEP. Or would it be possible to call a function when the __signature__ attribute is read? Victor ___ 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] PEP 362 Third Revision
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 like "chown" in os.supports_at_variant -- 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] VS 11 Express is Metro only.
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 the VS 2010 tool chain, in which case you can just as well use VS 2010 Express in the first place). Microsoft is now claiming that it will be able to using something called "multi-targeting", "later this year. http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx //arry/ ___ 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] PEP 362: 4th edition
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, with "value" attributes added to the Parameters. Use subclasses to distinguish the parameter kind. (Replacing most of the is_ methods from the 3rd version.) [is_]implemented is important information, but the API isn't quite right; even with tweaks, maybe we should wait a version before freezing it on the base class. But I would be happy to have Larry create a Signature for the os.* functions, whether that means a subclass or just an extra instance attribute. I favor passing a class to Signature.format, because so many of the formatting arguments would normally change in parallel. But my tolerance for nested structures may be unusually high. I make some more specific suggestions below. In http://mail.python.org/pipermail/python-dev/2012-June/120305.html Yury Selivanov wrote: > A Signature object has the following public attributes and methods: > * return_annotation : object >The annotation for the return type of the function if specified. >If the function has no annotation for its return type, this >attribute is not set. This means users must already be prepared to use hasattr with the Signature as well as the Parameters -- in which case, I don't see any harm in a few extra optional properties. I would personally prefer to see the name (and qualname) and docstring, but it would make perfect sense to implement these by keeping a weakref to the original callable, and just delegating there unless/until the properties are explicitly changed. I suspect others will have a use for additional delegated attributes, such as the self of boundmethods. I do agree that __eq__ and __hash__ should depend at most on the parameters (including their order) and the annotation. > * parameters : OrderedDict > An ordered mapping of parameters' names to the corresponding > Parameter objects (keyword-only arguments are in the same order > as listed in ``code.co_varnames``). For a specification, that feels a little too tied to the specific implementation. How about: Parameters will be ordered as they are in the function declaration. or even just: Positional parameters will be ordered as they are in the function declaration. because: def f(*, a=4, b=5): pass and: def f(*, b=5, a=4): pass should probably have equal signatures. Wild thought: Instead of just *having* an OrderedDict of Parameters, should a Signature *be* that OrderedDict (with other attributes)? That is, should signature(testfn)["foo"] get the foo parameter? > * bind(\*args, \*\*kwargs) -> BoundArguments > Creates a mapping from positional and keyword arguments to > parameters. Raises a ``BindError`` (subclass of ``TypeError``) > if the passed arguments do not match the signature. > * bind_partial(\*args, \*\*kwargs) -> BoundArguments > Works the same way as ``bind()``, but allows the omission > of some required arguments (mimics ``functools.partial`` > behavior.) Are those descriptions actually correct? I would expect the mapping to be from parameters (or parameter names) to values extracted from *args and **kwargs. And I'm not sure the current patch does even that, since it seems to instead return a non-Mapping object (but with a mapping attribute) that could be used to re-create *args, **kwargs in canonical form. (Though that canonicalization is valuable for calls; it might even be worth an as_call method.) I think it should be explicit that this mapping does not include parameters which would be filled by default arguments. In fact, if you stick with this interface, I would like a 3rd method that does fill out everything. But I think it would be simpler to just add an optional attribute to each Parameter instance, and let bind fill that in on the copies, so that the return value is also a Signature. (No need for the BoundArguments class.) Then the user can decide whether or not to plug in the defaults for missing values. > * format(...) -> str > Formats the Signature object to a string. Optional arguments allow > for custom render functions for parameter names, > annotations and default values, along with custom separators. I think it should state explicitly that by default, the return value will be a string that could be used to declare an equivalent function, if "Signature" were replaced with "def funcname". There are enough customization parameters that would often be changed together (e.g., to produce HTML output) that it might make sense to use overridable class defaults -- or even to make format a class itself. I also think it would make sense to delegate formatting the individual paramet
