Re: [Python-Dev] CFFI released
Hi Greg, On Tue, Jun 19, 2012 at 8:30 AM, Greg Ewing wrote: > Is there any provision for keeping the compiled > C code and distributing it along with an application? > Requiring a C compiler to be present at all times > could be a difficulty for Windows. We are aware of it and doing that is work in progress. Armin. ___ 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] CFFI released
Hi Stefan, On Tue, Jun 19, 2012 at 8:28 AM, Stefan Behnel wrote: > Any reason you didn't write the C parts in Cython? '''As a general rule, when there is a design issue to resolve, we pick the solution that is the “most C-like”.''' (from the documentation). But you are welcome to write Cython bindings for/from/around cffi if you like. A bientôt, Armin. ___ 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/18/2012 07:35 PM, Yury Selivanov wrote: BTW, http://bugs.python.org/issue15008 has the latest implementation attached (if anybody wants to play with it) I've also posted the latest minor tweaks to the PEP, on behalf of Yury. The new version is already live: http://www.python.org/dev/peps/pep-0362 Cheers, //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] cpython: Fix #14772: Return the destination from some shutil functions.
On Tue, 19 Jun 2012 01:41:44 +0200 brian.curtin wrote: > http://hg.python.org/cpython/rev/8281233ec648 > changeset: 77514:8281233ec648 > user:Brian Curtin > date:Mon Jun 18 18:41:07 2012 -0500 > summary: > Fix #14772: Return the destination from some shutil functions. > > files: > Doc/library/shutil.rst | 14 ++--- > Lib/shutil.py | 13 +++-- > Lib/test/test_shutil.py | 41 + > Misc/NEWS | 2 + > 4 files changed, 62 insertions(+), 8 deletions(-) > > > diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst > --- a/Doc/library/shutil.rst > +++ b/Doc/library/shutil.rst You forgot to add some versionchanged tags for these changes. 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] Help to fix this bug http://bugs.python.org/issue15068
Hi, I'm working on this bug to fix it. http://bugs.python.org/issue15068 >>> from sys import stdin >>> str=stdin.read() hello hello world CTRL+D CTRL+D Can anyone tell me where is stdin.read() function defined? Or where is sys.stdin defined? Or which function is called for str=stdin.read() ? Thanks ___ 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] Help to fix this bug http://bugs.python.org/issue15068
It depends on the Python version. In 3.3, for example, look into Modules/_io/fileio.c Eli On Tue, Jun 19, 2012 at 2:39 PM, gmspro wrote: > Hi, > > I'm working on this bug to fix it. http://bugs.python.org/issue15068 > > >>> from sys import stdin > >>> str=stdin.read() > hello > hello world > CTRL+D > CTRL+D > > Can anyone tell me where is stdin.read() function defined? > Or where is sys.stdin defined? > Or which function is called for str=stdin.read() ? > > Thanks > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/eliben%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] Help to fix this bug http://bugs.python.org/issue15068
Hi, On Tue, 19 Jun 2012 04:39:30 -0700 (PDT) gmspro wrote: > Hi, > > I'm working on this bug to fix it. http://bugs.python.org/issue15068 I'm not sure why you think this is fixable, given the comments on the tracker. What is your plan? > >>> from sys import stdin > >>> str=stdin.read() > hello > hello world > CTRL+D > CTRL+D > > Can anyone tell me where is stdin.read() function defined? > Or where is sys.stdin defined? Can I suggest you try to investigate it a bit yourself: >>> sys.stdin <_io.TextIOWrapper name='' mode='r' encoding='UTF-8'> So it's a TextIOWrapper from the _io module (which is really the implementation of the io module). You'll find its source in Modules/_io. TextIOWrapper objects are defined in Modules/_io/textio.c. But as you know, they wrap buffered I/O objects, which are defined in Modules/_io/bufferedio.c. In sys.stdin's case, the buffered I/O object wraps a raw FileIO object, defined in Modules/_io/fileio.c: >>> sys.stdin.buffer <_io.BufferedReader name=''> >>> sys.stdin.buffer.raw <_io.FileIO name='' mode='rb'> 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] Help to fix this bug http://bugs.python.org/issue15068
On 19.06.12 15:13, Antoine Pitrou wrote: sys.stdin <_io.TextIOWrapper name='' mode='r' encoding='UTF-8'> So it's a TextIOWrapper from the _io module (which is really the implementation of the io module). You'll find its source in Modules/_io. TextIOWrapper objects are defined in Modules/_io/textio.c. But as you know, they wrap buffered I/O objects, which are defined in Modules/_io/bufferedio.c. In sys.stdin's case, the buffered I/O object wraps a raw FileIO object, defined in Modules/_io/fileio.c: sys.stdin.buffer <_io.BufferedReader name=''> sys.stdin.buffer.raw <_io.FileIO name='' mode='rb'> And don't forget about _pyio module. ___ 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 397 - Last Comments
On Tue, Jun 19, 2012 at 1:30 AM, "Martin v. Löwis" wrote: >> Agreed, I would expect the same. I would think taking out the word >> "only" and then flipping newer and older in the sentence would correct >> it. > > Will change. > >>> "On 64bit Windows with both 32bit and 64bit implementations of the same >>> (major.minor) Python version installed, the 64bit version will always be >>> preferred. This will be true for both 32bit and 64bit implementations of >>> the launcher - a 32bit launcher will prefer to execute a 64bit Python >>> installation of the specified version if available." >>> >>> This implies to me that the 32bit installation *will* install a 32bit >>> launcher and that there could be both versions of the launcher installed. > > No - this paragraph talks about the Python being launched, not the > bitness of the launcher. As (currently) the launcher creates a > subprocess always, this is quite feasible. > > The bitness of the launcher really doesn't matter, except that a 32-bit > launcher cannot access all directories, and a 64-bit launcher does not > work on a 32-bit system. > > Now that I think about it, it might be that it's best to always have the > launcher as a 32-bit binary. It could disable the filesystem and > registry redirection if it really wanted to, and would work on both > 32-bit and 64-bit systems. Always doing a 32-bit binary seems like a better move to me. >> I took that as covering an independently-installed launcher. >> >> You could always install your own 32-bit launcher, and it'd prefer to >> launch a binary matching the machine type. > > No, that's not the plan. The binary being launched is entirely > controlled by command line arguments, ini files, and shebang lines. > > I personally find it sad that it always creates a subprocess, and it > could avoid doing so if the launched Python has the same bitness, but > alas, the problems with doing so are mostly convincing. > >> So yes, there could be >> multiple launchers installed for different machine types, and I'm not >> sure why we'd want to (or how we could) prevent people from installing >> them. You could have a 64-bit launcher available system-wide in your >> Windows folder, then you could have a 32-bit launcher running out of >> C:\Users\Terry for some purposes. > > The PEP doesn't really consider launcher binaries not installed into > the standard location. It would work, but it's out of scope of the PEP. > > The PEP actually only talks about launcher binaries in c:\windows, and > essentially says that they must match the bitness of the system. True, got it. >> My only additional comment would be to have the "Configuration file" >> implementation details supplemented with a readable example of where >> the py.ini file should be placed. On my machine that is >> "C:\Users\brian\AppData\Local", rather than making people have to run >> that parameter through the listed function via pywin32. > > Will do. > > Martin ___ 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 - 5th edition
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.format()' was removed. I think we'll add something
to customize formatting later, in 3.4. Although, Signature still has
its __str__ method.
3. Built-in ('C') functions no longer have mutable '__signature__'
attribute, that patch was reverted. In the "Design Considerations"
section we stated clear that we don't support some callables.
4. Positions of keyword-only parameters now longer affect equality
testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
(Thanks to Jim Jewett for pointing that out)
The only question we have now is: when we do equality test between
Signatures, should we account for positional-only, var_positional
and var_keyword arguments names? So that: 'foo(*args)' will
be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
(Again, I think that's a Jim's idea)
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.
It's possible to test Signatures for equality. Two signatures are
equal when their parameters are equal, their positional and
positional-only parameters appear in the same order, and they
have equal return annotations.
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
Signature also implements ``__str__`` and ``__copy__`` methods.
The latter creates a shallow copy of Signature, with all Parameter
objects copied as well.
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.
* `
[Python-Dev] PEP 362 minor nits
I've limited this to minor issues, but kept python-dev in the loop because some are questions, rather than merely editorial. Based on: http://hg.python.org/peps/file/tip/pep-0362.txt view pep-0362.txt @ 4466:659639095ace Committing the latest changes to PEP 362 on behalf of Yury Selivanov. author Larry Hastings dateTue, 19 Jun 2012 02:38:15 -0700 (3 hours ago) parents c1f693b39292 == 44 * return_annotation : object 45 The annotation for the return type of the function if specified. 46 If the function has no annotation for its return type, this 47 attribute is not set. I don't think you need the "if specified", given the next line. Similar comments around line 89 (Parameter.default) and 93 (Parameter.annotation). 48 * parameters : OrderedDict 49 An ordered mapping of parameters' names to the corresponding 50 Parameter objects (keyword-only arguments are in the same order 51 as listed in ``code.co_varnames``). Are you really sure you want to promise the keyword-only order in the PEP? [BoundArguments] 139 * arguments : OrderedDict 140 An ordered, mutable mapping of parameters' names to arguments' values. 141 Does not contain arguments' default values. I think 141 should be reworded, but I'm not certain my wording doesn't have similar problems, so I merely offer it: arguments contains only explicitly bound parameters; parameters for which the binding relied on a default value do not appear in arguments. 142 * args : tuple 143 Tuple of positional arguments values. Dynamically computed from 144 the 'arguments' attribute. 145 * kwargs : dict 146 Dict of keyword arguments values. Dynamically computed from 147 the 'arguments' attribute. Do you want to specify which will contain the normal parameters, that could be called either way? My naive assumption would be that as much as possible gets shoved into args, but once a positional parameter is left to default, remaining parameters are stuck in kwargs. 172 - If the object is not callable - raise a TypeError 173 174 - If the object has a ``__signature__`` attribute and if it 175 is not ``None`` - return a shallow copy of it Should these two be reversed? 183 - If the object is a method or a classmethod, construct and return 184 a new ``Signature`` object, with its first parameter (usually 185 ``self`` or ``cls``) removed 187 - If the object is a staticmethod, construct and return 188 a new ``Signature`` object I would reverse these two, to make it clear that a staticmethod is not treated as a method. 194 - If the object is a class or metaclass: 195 196 - If the object's type has a ``__call__`` method defined in 197 its MRO, return a Signature for it 198 199 - If the object has a ``__new__`` method defined in its class, 200 return a Signature object for it 201 202 - If the object has a ``__init__`` method defined in its class, 203 return a Signature object for it What happens if it inherits a __new__ or __init__ from something more derived than object? 207 Note, that I would remove the comma. 235 Some functions may not be introspectable 236 237 238 Some functions may not be introspectable in certain implementations of 239 Python. For example, in CPython, builtin functions defined in C provide 240 no metadata about their arguments. Adding support for them is out of 241 scope for this PEP. Ideally, it would at least be possible to manually construct a signature, and register them in some central location. (Similar to what is done with pickle or copy.) Checking that location would then have to be an early step in the signature algorithm. -jJ ___ 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 minor nits
Jim Jewett wrote: 48 * parameters : OrderedDict 49 An ordered mapping of parameters' names to the corresponding 50 Parameter objects (keyword-only arguments are in the same order 51 as listed in ``code.co_varnames``). Are you really sure you want to promise the keyword-only order in the PEP? Is keyword order even important? We're already ignoring for equality tests. ~Ethan~ ___ 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 minor nits
Jim, On 2012-06-19, at 11:33 AM, Jim Jewett wrote: > I've limited this to minor issues, but kept python-dev in the loop > because some are questions, rather than merely editorial. > > > Based on: http://hg.python.org/peps/file/tip/pep-0362.txt > > view pep-0362.txt @ 4466:659639095ace > > > > Committing the latest changes to PEP 362 on behalf of Yury Selivanov. > authorLarry Hastings > date Tue, 19 Jun 2012 02:38:15 -0700 (3 hours ago) > parents c1f693b39292 > > > == > > >44 * return_annotation : object >45 The annotation for the return type of the function if specified. >46 If the function has no annotation for its return type, this >47 attribute is not set. > > I don't think you need the "if specified", given the next line. > Similar comments around line 89 (Parameter.default) and 93 > (Parameter.annotation). +1. >48 * parameters : OrderedDict >49 An ordered mapping of parameters' names to the corresponding >50 Parameter objects (keyword-only arguments are in the same order >51 as listed in ``code.co_varnames``). > > Are you really sure you want to promise the keyword-only order in the PEP? Well we can remove that sentence (it seems that at least for CPython we can guarantee so, as we work with '__code__.co_varnames', but again, even for CPython there may be some opcode optimizer, that can screw up the order in some way) > [BoundArguments] > 139 * arguments : OrderedDict > 140 An ordered, mutable mapping of parameters' names to > arguments' values. > 141 Does not contain arguments' default values. > > I think 141 should be reworded, but I'm not certain my wording doesn't > have similar problems, so I merely offer it: > > arguments contains only explicitly bound parameters; parameters for > which the binding relied on a default value do not appear in > arguments. +1. > 142 * args : tuple > 143 Tuple of positional arguments values. Dynamically computed from > 144 the 'arguments' attribute. > 145 * kwargs : dict > 146 Dict of keyword arguments values. Dynamically computed from > 147 the 'arguments' attribute. > > Do you want to specify which will contain the normal parameters, that > could be called either way? My naive assumption would be that as much > as possible gets shoved into args, but once a positional parameter is > left to default, remaining parameters are stuck in kwargs. Correct, we push as much as possible to 'args'. Only var_keyword and keyword_only args go to 'kwargs'. But the words "positional" and "keyword" more refer to what particularly *args and **kwargs do, disconnected from the Signature's parameters. > 172 - If the object is not callable - raise a TypeError > 173 > 174 - If the object has a ``__signature__`` attribute and if it > 175 is not ``None`` - return a shallow copy of it > > Should these two be reversed? Do you have a use-case? I think we should only support callable types, otherwise we may mask an error in the user code. > 183 - If the object is a method or a classmethod, construct and return > 184 a new ``Signature`` object, with its first parameter (usually > 185 ``self`` or ``cls``) removed > > 187 - If the object is a staticmethod, construct and return > 188 a new ``Signature`` object > > I would reverse these two, to make it clear that a staticmethod is not > treated as a method. It's actually not how it's implemented. https://bitbucket.org/1st1/cpython/src/bf009eb6e1b4/Lib/inspect.py#cl-1262 We first check for (types.MethodType, classmethod), because they relay all attributes from the underlying function (including __signature__) But that's an implementation detail, the algorithm in the PEP just shows the big picture (is it OK?). > 194 - If the object is a class or metaclass: > 195 > 196 - If the object's type has a ``__call__`` method defined in > 197 its MRO, return a Signature for it > 198 > 199 - If the object has a ``__new__`` method defined in its class, > 200 return a Signature object for it > 201 > 202 - If the object has a ``__init__`` method defined in its class, > 203 return a Signature object for it > > What happens if it inherits a __new__ or __init__ from something more > derived than object? What do you mean by "more derived than object"? > 207 Note, that > > I would remove the comma. > > > 235 Some functions may not be introspectable > 236 > 237 > 238 Some functions may not be introspectable in certain implementations of > 239 Python. For example, in CPython, builtin functions defined in C provide > 240 no metadata about their arguments. Adding support for them is out of > 241 scope for this PEP. > > Ideally, it would at least be possible to manually construct a > signature, and register
Re: [Python-Dev] PEP 362 minor nits
On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
wrote:
>> Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
>> view pep-0362.txt @ 4466:659639095ace
>> ==
>> 142 * args : tuple
>> 143 Tuple of positional arguments values. Dynamically computed from
>> 144 the 'arguments' attribute.
>> 145 * kwargs : dict
>> 146 Dict of keyword arguments values. Dynamically computed from
>> 147 the 'arguments' attribute.
>> Do you want to specify which will contain the normal parameters, that
>> could be called either way? My naive assumption would be that as much
>> as possible gets shoved into args, but once a positional parameter is
>> left to default, remaining parameters are stuck in kwargs.
> Correct, we push as much as possible to 'args'. Only var_keyword
> and keyword_only args go to 'kwargs'.
> But the words "positional" and "keyword" more refer to what particularly
> *args and **kwargs do, disconnected from the Signature's parameters.
Which is why there is some ambiguity, and I wondered if you were
intentionally leaving it open or not.
>>> def f(a): pass
>>> s=signature(f)
>>> ba1=s.bind(1)
Now which of the following are true?
>>> # Ambiguous parameters to args
>>> ba.args==(1,) and ba.kwargs=={}
>>> # or ambiguous parameters to kwargs
>>> ba.args=() and ba.kwargs={a:1}
Does it matter how the argument was bound? As in, would
>>> ba2=s.bind(a=2)
produce a different answer?
If as much as possible goes to args, then:
>>> def g(a=1, b=2, c=3): pass
>>> s=signature(g)
>>> ba=s.bind(a=10, c=13)
would imply
>>> ba.args == (10,) and ba.kwargs={c:13}
True
because a can be written positionally, but c can't unless b is, and b
shouldn't be because it relied on the default value.
>> 172 - If the object is not callable - raise a TypeError
>> 173
>> 174 - If the object has a ``__signature__`` attribute and if it
>> 175 is not ``None`` - return a shallow copy of it
>> Should these two be reversed?
> Do you have a use-case?
Not really; the only cases that come to mind are cases where it makes
sense to look at an explicit signature attribute, instead of calling
the factory.
>> 183 - If the object is a method or a classmethod, construct and return
>> 184 a new ``Signature`` object, with its first parameter (usually
>> 185 ``self`` or ``cls``) removed
>>
>> 187 - If the object is a staticmethod, construct and return
>> 188 a new ``Signature`` object
>> I would reverse these two, to make it clear that a staticmethod is not
>> treated as a method.
> It's actually not how it's implemented.
...
> But that's an implementation detail, the algorithm in the PEP just
> shows the big picture (is it OK?).
Right; implementing it in the other order is fine, so long as the
actual tests for methods exclude staticmethods. But for someone
trying to understand it, staticmethods sound like a kind of method,
and I would expect them to be included in something that handles
methods, unless they were already excluded by a prior clause.
>> 194 - If the object is a class or metaclass:
>> 195
>> 196 - If the object's type has a ``__call__`` method defined in
>> 197 its MRO, return a Signature for it
>> 198
>> 199 - If the object has a ``__new__`` method defined in its class,
>> 200 return a Signature object for it
>> 201
>> 202 - If the object has a ``__init__`` method defined in its class,
>> 203 return a Signature object for it
>>
>> What happens if it inherits a __new__ or __init__ from something more
>> derived than object?
> What do you mean by "more derived than object"?
>>> class A:
def __init__(self): pass
>>> class B(A): ...
Because of the distinction between "in its MRO" and "in its class", it
looks like the signature of A is based on its __init__, but the
signature of subclass B is not.
-jJ
___
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 - 5th edition
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.format()' was removed. I think we'll add something
to customize formatting later, in 3.4. Although, Signature still has
its __str__ method.
3. Built-in ('C') functions no longer have mutable '__signature__'
attribute, that patch was reverted. In the "Design Considerations"
section we stated clear that we don't support some callables.
4. Positions of keyword-only parameters now longer affect equality
testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
(Thanks to Jim Jewett for pointing that out)
The only question we have now is: when we do equality test between
Signatures, should we account for positional-only, var_positional
and var_keyword arguments names? So that: 'foo(*args)' will
be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
(Again, I think that's a Jim's idea)
There are obviously cases where the names should be considered (such as
foo(source, dest) and bar(dest, source) ) and cases where it should not
be (spam(text, count) and eggs(txt, cnt) )...
I think the default implementation should be strict (names are
considered) as it is safer to have a false negative than a false positive.
However, rather than force everyone who is willing to cope with the
possible false positives from rewriting a Signature equality routine
that ignores names, perhaps a method can be added to the class that does so?
class Signature:
. . .
def equivalent(self, other):
"compares two Signatures for equality (ignores parameter names)"
. . .
~Ethan~
___
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 - 5th edition
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> Hello,
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>> Summary:
>> 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
>> __copy__ creates a shallow copy of Signature, shallow copying its
>> Parameters as well.
>> 2. 'Signature.format()' was removed. I think we'll add something
>> to customize formatting later, in 3.4. Although, Signature still has
>> its __str__ method.
>> 3. Built-in ('C') functions no longer have mutable '__signature__'
>> attribute, that patch was reverted. In the "Design Considerations"
>> section we stated clear that we don't support some callables.
>> 4. Positions of keyword-only parameters now longer affect equality
>> testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
>> (Thanks to Jim Jewett for pointing that out)
>> The only question we have now is: when we do equality test between
>> Signatures, should we account for positional-only, var_positional
>> and var_keyword arguments names? So that: 'foo(*args)' will
>> be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
>> (Again, I think that's a Jim's idea)
>
> There are obviously cases where the names should be considered (such as
> foo(source, dest) and bar(dest, source) ) and cases where it should not be
> (spam(text, count) and eggs(txt, cnt) )...
>
> I think the default implementation should be strict (names are considered) as
> it is safer to have a false negative than a false positive.
+1
> However, rather than force everyone who is willing to cope with the possible
> false positives from rewriting a Signature equality routine that ignores
> names, perhaps a method can be added to the class that does so?
>
> class Signature:
> . . .
> def equivalent(self, other):
> "compares two Signatures for equality (ignores parameter names)"
> . . .
I don't think that comparing signatures will be a common operation,
so maybe we can postpone adding any additional methods for 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 - 5th edition
Yury Selivanov wrote:
On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.format()' was removed. I think we'll add something
to customize formatting later, in 3.4. Although, Signature still has
its __str__ method.
3. Built-in ('C') functions no longer have mutable '__signature__'
attribute, that patch was reverted. In the "Design Considerations"
section we stated clear that we don't support some callables.
4. Positions of keyword-only parameters now longer affect equality
testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
(Thanks to Jim Jewett for pointing that out)
The only question we have now is: when we do equality test between
Signatures, should we account for positional-only, var_positional
and var_keyword arguments names? So that: 'foo(*args)' will
be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
(Again, I think that's a Jim's idea)
There are obviously cases where the names should be considered (such as
foo(source, dest) and bar(dest, source) ) and cases where it should not be
(spam(text, count) and eggs(txt, cnt) )...
I think the default implementation should be strict (names are considered) as
it is safer to have a false negative than a false positive.
+1
However, rather than force everyone who is willing to cope with the possible
false positives from rewriting a Signature equality routine that ignores names,
perhaps a method can be added to the class that does so?
class Signature:
. . .
def equivalent(self, other):
"compares two Signatures for equality (ignores parameter names)"
. . .
I don't think that comparing signatures will be a common operation,
so maybe we can postpone adding any additional methods for that?
Sure, toss it in the list of possible adds for 3.4.
At some point it was suggested that Signature be put in provisionally so
we could modify the API if needed -- are we doing that?
~Ethan~
___
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 - 5th edition
On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
>>> Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Summary:
1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
__copy__ creates a shallow copy of Signature, shallow copying its
Parameters as well.
2. 'Signature.format()' was removed. I think we'll add something
to customize formatting later, in 3.4. Although, Signature still has
its __str__ method.
3. Built-in ('C') functions no longer have mutable '__signature__'
attribute, that patch was reverted. In the "Design Considerations"
section we stated clear that we don't support some callables.
4. Positions of keyword-only parameters now longer affect equality
testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
(Thanks to Jim Jewett for pointing that out)
The only question we have now is: when we do equality test between
Signatures, should we account for positional-only, var_positional
and var_keyword arguments names? So that: 'foo(*args)' will
be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
(Again, I think that's a Jim's idea)
>>> There are obviously cases where the names should be considered (such as
>>> foo(source, dest) and bar(dest, source) ) and cases where it should not be
>>> (spam(text, count) and eggs(txt, cnt) )...
>>>
>>> I think the default implementation should be strict (names are considered)
>>> as it is safer to have a false negative than a false positive.
>> +1
>>> However, rather than force everyone who is willing to cope with the
>>> possible false positives from rewriting a Signature equality routine that
>>> ignores names, perhaps a method can be added to the class that does so?
>>>
>>> class Signature:
>>> . . .
>>> def equivalent(self, other):
>>> "compares two Signatures for equality (ignores parameter names)"
>>> . . .
>> I don't think that comparing signatures will be a common operation,
>> so maybe we can postpone adding any additional methods for that?
>
> Sure, toss it in the list of possible adds for 3.4.
>
> At some point it was suggested that Signature be put in provisionally so we
> could modify the API if needed -- are we doing that?
Well, it doesn't have much of an API right now (just few methods)
-
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 minor nits
On 2012-06-19, at 12:33 PM, Jim Jewett wrote:
> On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
> wrote:
>
>>> Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
>>> view pep-0362.txt @ 4466:659639095ace
>>> ==
>
>>> 142 * args : tuple
>>> 143 Tuple of positional arguments values. Dynamically computed from
>>> 144 the 'arguments' attribute.
>>> 145 * kwargs : dict
>>> 146 Dict of keyword arguments values. Dynamically computed from
>>> 147 the 'arguments' attribute.
>
>>> Do you want to specify which will contain the normal parameters, that
>>> could be called either way? My naive assumption would be that as much
>>> as possible gets shoved into args, but once a positional parameter is
>>> left to default, remaining parameters are stuck in kwargs.
>
>> Correct, we push as much as possible to 'args'. Only var_keyword
>> and keyword_only args go to 'kwargs'.
>
>> But the words "positional" and "keyword" more refer to what particularly
>> *args and **kwargs do, disconnected from the Signature's parameters.
>
> Which is why there is some ambiguity, and I wondered if you were
> intentionally leaving it open or not.
>
def f(a): pass
s=signature(f)
>
ba1=s.bind(1)
>
> Now which of the following are true?
>
# Ambiguous parameters to args
ba.args==(1,) and ba.kwargs=={}
>
# or ambiguous parameters to kwargs
ba.args=() and ba.kwargs={a:1}
The first one (ba.args == (1,))
> Does it matter how the argument was bound? As in, would
>
ba2=s.bind(a=2)
>
> produce a different answer?
No.
> If as much as possible goes to args, then:
>
def g(a=1, b=2, c=3): pass
s=signature(g)
ba=s.bind(a=10, c=13)
>
> would imply
>
ba.args == (10,) and ba.kwargs={c:13}
>True
Right (there was a bug in BoundArguments.args & kwargs - fixed and
unit-tested now)
> because a can be written positionally, but c can't unless b is, and b
> shouldn't be because it relied on the default value.
OK, so do you want to elaborate on BoundArguments.args & kwargs?
(I think it's fine now)
...
>>> 183 - If the object is a method or a classmethod, construct and return
>>> 184 a new ``Signature`` object, with its first parameter (usually
>>> 185 ``self`` or ``cls``) removed
>>>
>>> 187 - If the object is a staticmethod, construct and return
>>> 188 a new ``Signature`` object
>
>>> I would reverse these two, to make it clear that a staticmethod is not
>>> treated as a method.
>
>> It's actually not how it's implemented.
> ...
>> But that's an implementation detail, the algorithm in the PEP just
>> shows the big picture (is it OK?).
>
> Right; implementing it in the other order is fine, so long as the
> actual tests for methods exclude staticmethods. But for someone
> trying to understand it, staticmethods sound like a kind of method,
> and I would expect them to be included in something that handles
> methods, unless they were already excluded by a prior clause.
I can tweak the PEP to make it more clear for those who don't know
that staticmethods are not exactly methods, but do we really need that?
(I don't want to change the implementation, because every 'isinstance'
call matters, and we need to check on 'types.FunctionType' as soon as
possible)
>>> 194 - If the object is a class or metaclass:
>>> 195
>>> 196 - If the object's type has a ``__call__`` method defined in
>>> 197 its MRO, return a Signature for it
>>> 198
>>> 199 - If the object has a ``__new__`` method defined in its class,
>>> 200 return a Signature object for it
>>> 201
>>> 202 - If the object has a ``__init__`` method defined in its
>>> class,
>>> 203 return a Signature object for it
>>>
>>> What happens if it inherits a __new__ or __init__ from something more
>>> derived than object?
>
>> What do you mean by "more derived than object"?
>
class A:
>def __init__(self): pass
class B(A): ...
>
> Because of the distinction between "in its MRO" and "in its class", it
> looks like the signature of A is based on its __init__, but the
> signature of subclass B is not.
Got it. I currently check the MRO in the implementation, so your
example will work as expected - B will have a signature of A.__init__
I'll update the PEP wording.
-
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 minor nits
On Tue, Jun 19, 2012 at 2:10 PM, Yury Selivanov wrote:
> On 2012-06-19, at 12:33 PM, Jim Jewett wrote:
>
>> On Tue, Jun 19, 2012 at 11:53 AM, Yury Selivanov
>> wrote:
>>
Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
view pep-0362.txt @ 4466:659639095ace
==
>>
142 * args : tuple
143 Tuple of positional arguments values. Dynamically computed from
144 the 'arguments' attribute.
145 * kwargs : dict
146 Dict of keyword arguments values. Dynamically computed from
147 the 'arguments' attribute.
>>> Correct, we push as much as possible to 'args'.
[examples to clarify]
OK, I would just add a sentence and commented example then, something like.
Arguments which could be passed as part of either *args or **kwargs
will be included only in the args attribute. In the following
example:
>>> def g(a=1, b=2, c=3): pass
>>> s=signature(g)
>>> ba=s.bind(a=10, c=13)
>>> ba.args
(10,)
>>> ba.kwargs
{'c': 13}
Parameter a is part of args, because it can be.
Parameter c must be passed as a keyword, because (earlier) parameter b
is not being passed an explicit value.
> I can tweak the PEP to make it more clear for those who don't know
> that staticmethods are not exactly methods, but do we really need that?
I would prefer it, if only because it surprised me. When do
distinguish between methods, staticmethod isn't usually the odd man
out.
And I also agree that the implementation doesn't need to change
(except to add a comment), only the PEP.
-jJ
___
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] Status of packaging in 3.3
Hi all, We need to make a decision about the packaging module in Python 3.3. Please read this message and breathe deeply before replying :) [Sorry this ends up being so long; Tarek, Georg, Guido, I hope you have the time to read it.] Let me first summarize the history of packaging in the standard library. (Please correct if I misremember something; this email expresses my opinion and I did not talk with Tarek or Alexis before writing it.) Two years ago the distutils2 (hereafter d2) project was started outside of the stdlib, to allow for fast-paced changes, releases and testing before merging it back. Changes in distutils were reverted to go back to misfeature-for-misfeature compatibility (but not bug-for-bug: bug fixes are allowed, unless we know for sure everyone is depending on them or working around them). Tarek’s first hope was to have something that could be included in 2.7 and 3.2, but these deadlines came too fast. At one point near the start of 2011 (didn’t find the email) there was a discussion with Martin about adding support for the stable ABI or parallel builds to distutils, in which Tarek and I opposed adding this new feature to distutils as per the freeze policy, and Martin declared he was not willing to work outside of the standard library. We (d2 developers and python-dev) then quickly agreed that distutils2 would be merged back after the release of 3.2, which was done. There was no PEP requested for this addition, maybe because this was not a fully new module but an improvement of an existing one with real-world-tested features, or maybe just because nobody thought about the process. In retrospect, a PEP would have really helped define the scope of the changes and the roadmap for packaging. Real life caused contributors to come and go, and the primary maintainer (Tarek at first, me since last December) to be at times very busy (like me these last three months), with the result that packaging is in my opinion just not ready. Many big and small things need more work: the three packaging PEPs implemented in d2 have small flaws or missing pieces (I’m not repeating the list here to avoid spawning subthreads) that need to be addressed, we’ve started to get feedback from users and developers only recently (pip and buildout devs since last PyCon for example) the public Python API of d2 is far from great, the implementation is of very unequal quality, important features have patches that are not fully ready (—and I do acknowledge that I am the blocker for reviews on many of them—), the compiler system has not been revised, tests are not all clear and robust, some of the bdist commands need to be removed, a new bdist format needs to be designed, etc. With beta coming, a way to deal with that unfortunate situation needs to be found. We could (a) grant an exception to packaging to allow changes after beta1; (b) keep packaging as it is now under a provisional status, with due warnings that many things are expected to change; (c) remove the unstable parts and deliver a subset that works (proposed by Tarek to the Pyramid author on distutils-sig); (d) not release packaging as part of Python 3.3 (I think that was also suggested on distutils-sig last month). I don’t think (a) would give us enough time; we really want a few months (and releases) to hash out the API (most notably with the pip and buildout developers) and clean the bdist situation. Likewise (c) would require developer (my) time that is currently in short supply. (b) also requires time and would make development harder, not to mention probable user pain. This leaves (d), after long reflection, as my preferred choice, even though I disliked the idea at first (and I fully expect Tarek to feel the same way). I’d like to stress that this is not as bad as it appears at first. We (I) will have to craft reassuring wording to explain why 3.3b1 does not include packaging any more, but I believe that it would be worse for our users (code-wise and PR-wise) to deliver a half-finished version in 3.3 rather than to retract it and wait for 3.4. And if we keep in mind that many people are still using a 2.x version, releasing in 3.3 or 3.4 makes no change for them: the standalone releases on PyPI will keep coming. Developer-wise, this would *not* mean that the considerable effort that went into porting and merging, and the really appreciated patches from developers such as Vinay, would have been in vain: even if packaging is removed from the main repo (or just from the release systems), there would be a clone to continue development, or the module would be added back right after the 3.3 release, or we would develop in the d2 repo and merge it back when it’s ready—this is really an implementation detail for the decision; my point is that the work will not be lost. Thanks for reading; please express your opinion (especially Tarek as d2 project l
Re: [Python-Dev] Status of packaging in 3.3
Reverting and writing a full packaging PEP for 3.4 sounds like a wise course of action to me. Regards, Nick. -- Sent from my phone, thus the relative brevity :) ___ 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] Status of packaging in 3.3
Éric Araujo wrote: This leaves (d), after long reflection, as my preferred choice, even though I disliked the idea at first (and I fully expect Tarek to feel the same way). Thanks for reading; please express your opinion (especially Tarek as d2 project lead, Georg as RM and Guido as BDFL). I would go with (d) -- it's still available on PyPI, and having a half-done product in the final release would not be good. ~Ethan~ (as ordinary user ;) ___ 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] Status of packaging in 3.3
On 19 June 2012 22:46, Éric Araujo wrote: [...] > This leaves (d), after long reflection, as my preferred choice, even though > I disliked the idea at first (and I fully expect Tarek to feel the same > way). I agree with Nick. It's regrettable, but this is probably the wisest course of action. Remove packaging from 3.3, create a PEP clearly defining what packaging should be, and aim to implement for 3.4. It seems to me that there's a lot of interest in the packaging module, but it's fragmented and people have very different goals and expectations. Developing a PEP will likely be a big task in itself, but I'd hope that a well-crafted PEP will provide something the various people with an interest could get behind and work together on, which might help ease the developer time issue. (Assuming, of course, that championing the PEP doesn't burn Éric out completely...) 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
Re: [Python-Dev] Status of packaging in 3.3
On 06/19/2012 05:46 PM, Éric Araujo wrote: Hi all, We need to make a decision about the packaging module in Python 3.3. Please read this message and breathe deeply before replying :) ... With beta coming, a way to deal with that unfortunate situation needs to be found. We could (a) grant an exception to packaging to allow changes after beta1; (b) keep packaging as it is now under a provisional status, with due warnings that many things are expected to change; (c) remove the unstable parts and deliver a subset that works (proposed by Tarek to the Pyramid author on distutils-sig); (d) not release packaging as part of Python 3.3 (I think that was also suggested on distutils-sig last month). I think it'd be very wise to choose (d) here. We've lived so long without a credible packaging story that waiting one (or even two) more major release cycles isn't going to make a huge difference in the long run but including a version of packaging now which gets fixed in a rush would probably end up muddying the already dark waters of Python software distribution. - C ___ 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 minor nits
On 2012-06-19, at 4:17 PM, Jim Jewett wrote: >> I can tweak the PEP to make it more clear for those who don't know >> that staticmethods are not exactly methods, but do we really need that? > > I would prefer it, if only because it surprised me. When do > distinguish between methods, staticmethod isn't usually the odd man > out. > > And I also agree that the implementation doesn't need to change > (except to add a comment), only the PEP. Actually, it appears we don't need those special checks (for classmethod and staticmethod) at all. class Foo: @staticmethod def bar(): pass >>> Foo.bar >>> Foo().bar >>> Foo.__dict__['bar'] So using the signature will be OK for 'Foo.bar' and 'Foo().bar', but not for 'Foo.__dict__['bar']' - which I think is fine (since staticmethod & classmethod instances are not callable) I'll just remove checks for static- and class-methods from the PEP signature() algorithm section. - 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 - 5th edition
On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov wrote:
> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>> At some point it was suggested that Signature be put in provisionally so we
>> could modify the API if needed -- are we doing that?
>
> Well, it doesn't have much of an API right now (just few methods)
Right, provisional API status is a fairly blunt instrument that we
should only use if we can't find any other way to allow the standard
library to progress.
In this particular case, we have a superior alternative: distill the
API down to the bare minimum that is needed to provide a more robust,
cross-implementation format for describing callable signatures. We can
then implement that bare minimum API for 3.3 as the foundation for
higher level layered APIs that offer more flexibility, and/or capture
more information about the callables.
Further comments on the PEP and implementation:
1. The PEP should specify the constructor signatures for Signature and
Parameter objects (I'd also prefer it if "kind" was permitted as a
positional argument)
2. The constructor for Parameter objects should require that names for
positional-only parameters start with "<" and end with ">" to ensure
they can always be distinguished from standard parameters in signature
string representations and in BoundArguments.parameters
3. The standard Signature constructor should accept an iterable of
Parameter objects directly (with the return annotation as an optional
keyword-only "annotation" argument) and enforce the following
constraints:
- permitted parameter binding order is strictly (POSITIONAL_ONLY,
POSITIONAL_OR_KEYWORD, VAR_POSITIONAL, KEYWORD_ONLY, VAR_KEYWORD)
- all parameter names must be distinct (otherwise bind() won't work properly)
- if a positional only parameter is not named (param.name is None), it
is given a name based on its position in the parameter list ("<0>",
"<1>", etc)
4. The current Signature constructor should become a "from_function"
class method
With these changes, the following would become straightforward:
>>> def f1(a): pass
>>> str(signature(f1))
(a)
>>> def f2(*args): a, = args
>>> f.__signature__ = Signature([Parameter("",
Parameter.POSITIONAL_ONLY])
>>> str(signature(f2))
()
>>> def f3(*args): a, = args
>>> f.__signature__ = Signature([Parameter(None, Parameter.POSITIONAL_ONLY])
>>> str(signature(f3))
(<0>)
5. Given the updated constructor signature, we can revisit the
question of immutable signature objects (even just using read-only
properties for public attributes and exposing a dict proxy for the
parameter list). Instead of mutating the parameter list, you would
instead write code like:
new_sig = Signature(old_sig.parameters[1:])
In my opinion, that's a *much* nicer approach than copying an existing
signature object and mutating it.
6. I think "return_annotation" can safely be abbreviated to just
"annotation". The fact it is on the Signature object rather than an
individual parameter is enough to identify it as the return
annotation.
7. The idea of immutable Signature objects does highlight an annoyance
with the "attribute may be missing" style APIs. To actually duplicate
a signature correctly, including its return annotation (and assuming
the attribute is renamed), you would have to do something like:
try:
note = {"annotation": old_sig.annotation}
except AttributeError:
note = {}
new_sig = Signature(old_sig.parameters[1:], **note)
There's an alternative approach to optional attributes that's often
easier to work with: expose them as containers. In this case, since we
want to make them easy to pass as keyword-only arguments, one way to
achieve that would be expose an "optional" attribute on both Signature
and Parameter objects. Then the above would be written as:
new_sig = Signature(old_sig.parameters[1:], **old_sig.optional)
And copying a Parameter would be:
new_param = Parameter("new name", old_param.kind, **old_param.optional)
If we even keep that at all for the initial version of the API, the
direct "default" and "annotation" attributes would just be read-only
properties that accessed the "optional" container (reporting
AttributeError if the corresponding attribute was missing)
8. Not essential, but I suggest moving most of the parameter
formatting details to a Parameter.__str__ method
9. The PEP should explicitly note that we're taking a deliberately
strict approach to the notion of signature and parameter equivalence
by assuming that all parameter names have semantic significance.
Looser checks that ignore the names of positional and variable keyword
parameters can be handled with Signature.bind() or by implementing
custom key or comparison functions.
10. Similar to the discussion of convenience properties on Signature
objects themselves, I now think we should drop the "args" and "kwargs"
properties from the initial version of BoundArguments. Instead, I
propose the following attribute
Re: [Python-Dev] pep 362 - 5th edition
On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 3:53 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 1:03 PM, Ethan Furman wrote:
>>> At some point it was suggested that Signature be put in provisionally so we
>>> could modify the API if needed -- are we doing that?
>>
>> Well, it doesn't have much of an API right now (just few methods)
>
> Right, provisional API status is a fairly blunt instrument that we
> should only use if we can't find any other way to allow the standard
> library to progress.
>
> In this particular case, we have a superior alternative: distill the
> API down to the bare minimum that is needed to provide a more robust,
> cross-implementation format for describing callable signatures. We can
> then implement that bare minimum API for 3.3 as the foundation for
> higher level layered APIs that offer more flexibility, and/or capture
> more information about the callables.
>
> Further comments on the PEP and implementation:
>
> 1. The PEP should specify the constructor signatures for Signature and
> Parameter objects (I'd also prefer it if "kind" was permitted as a
> positional argument)
+1
> 2. The constructor for Parameter objects should require that names for
> positional-only parameters start with "<" and end with ">" to ensure
> they can always be distinguished from standard parameters in signature
> string representations and in BoundArguments.parameters
+1
> 3. The standard Signature constructor should accept an iterable of
> Parameter objects directly (with the return annotation as an optional
> keyword-only "annotation" argument) and enforce the following
> constraints:
> - permitted parameter binding order is strictly (POSITIONAL_ONLY,
> POSITIONAL_OR_KEYWORD, VAR_POSITIONAL, KEYWORD_ONLY, VAR_KEYWORD)
> - all parameter names must be distinct (otherwise bind() won't work properly)
> - if a positional only parameter is not named (param.name is None), it
> is given a name based on its position in the parameter list ("<0>",
> "<1>", etc)
+1
> 4. The current Signature constructor should become a "from_function"
> class method
+1
> With these changes, the following would become straightforward:
>
def f1(a): pass
str(signature(f1))
>(a)
def f2(*args): a, = args
f.__signature__ = Signature([Parameter("",
> Parameter.POSITIONAL_ONLY])
str(signature(f2))
>()
def f3(*args): a, = args
f.__signature__ = Signature([Parameter(None, Parameter.POSITIONAL_ONLY])
str(signature(f3))
>(<0>)
>
> 5. Given the updated constructor signature, we can revisit the
> question of immutable signature objects (even just using read-only
> properties for public attributes and exposing a dict proxy for the
> parameter list). Instead of mutating the parameter list, you would
> instead write code like:
>new_sig = Signature(old_sig.parameters[1:])
I think that mocking immutability here is a better decision than
to implement a truly immutable object in C. Read-only properties
and a dict-proxy for Signature.parameters will work.
> In my opinion, that's a *much* nicer approach than copying an existing
> signature object and mutating it.
+1
> 6. I think "return_annotation" can safely be abbreviated to just
> "annotation". The fact it is on the Signature object rather than an
> individual parameter is enough to identify it as the return
> annotation.
I'm not sure about this one. 'return_annotation' is a very
self-descriptive and clear name.
> 7. The idea of immutable Signature objects does highlight an annoyance
> with the "attribute may be missing" style APIs. To actually duplicate
> a signature correctly, including its return annotation (and assuming
> the attribute is renamed), you would have to do something like:
>
>try:
>note = {"annotation": old_sig.annotation}
>except AttributeError:
>note = {}
>new_sig = Signature(old_sig.parameters[1:], **note)
>
> There's an alternative approach to optional attributes that's often
> easier to work with: expose them as containers. In this case, since we
> want to make them easy to pass as keyword-only arguments, one way to
> achieve that would be expose an "optional" attribute on both Signature
> and Parameter objects. Then the above would be written as:
>
>new_sig = Signature(old_sig.parameters[1:], **old_sig.optional)
>
> And copying a Parameter would be:
>new_param = Parameter("new name", old_param.kind, **old_param.optional)
>
> If we even keep that at all for the initial version of the API, the
> direct "default" and "annotation" attributes would just be read-only
> properties that accessed the "optional" container (reporting
> AttributeError if the corresponding attribute was missing)
+0. I think that 'optional' is a bit unusual attribute for the stdlib,
but it will work if we make Signature immutable.
> 8. Not essential, but I suggest moving most of the parameter
> formatting details to a Parameter.__str__ method
+1
>
Re: [Python-Dev] Status of packaging in 3.3
On Tue, 19 Jun 2012 17:46:30 -0400 Éric Araujo wrote: > >I don’t think (a) would give us enough time; we really want a few > months (and releases) to hash out the API (most notably with the pip and > buildout developers) and clean the bdist situation. Likewise (c) would > require developer (my) time that is currently in short supply. (b) also > requires time and would make development harder, not to mention probable > user pain. This leaves (d), after long reflection, as my preferred > choice, even though I disliked the idea at first (and I fully expect > Tarek to feel the same way). The question is what will happen after 3.3. There doesn't seem to be a lot of activity around the project, does 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 - 5th edition
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote: > On 2012-06-19, at 8:39 PM, Nick Coghlan wrote: > >> 2. The constructor for Parameter objects should require that names for >> positional-only parameters start with "<" and end with ">" to ensure >> they can always be distinguished from standard parameters in signature >> string representations and in BoundArguments.parameters > > +1 Actually, can we just make positional-only parameters to render brackets in their/Signature's __str__ methods? I think Parameter.kind should be enough, without adding additional obstacles. - 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 - 5th edition
On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote: > On 2012-06-19, at 9:22 PM, Yury Selivanov wrote: > >> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote: >> >>> 2. The constructor for Parameter objects should require that names for >>> positional-only parameters start with "<" and end with ">" to ensure >>> they can always be distinguished from standard parameters in signature >>> string representations and in BoundArguments.parameters >> >> +1 > > Actually, can we just make positional-only parameters to render brackets > in their/Signature's __str__ methods? I think Parameter.kind should be > enough, without adding additional obstacles. True, the check for name clashes in Signature (and the implied numeric "names") will cover the BoundArguments.parameters case 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 - 5th edition
On 2012-06-19, at 10:06 PM, Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 11:29 AM, Yury Selivanov wrote: >> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote: >> >>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote: >>> 2. The constructor for Parameter objects should require that names for positional-only parameters start with "<" and end with ">" to ensure they can always be distinguished from standard parameters in signature string representations and in BoundArguments.parameters >>> >>> +1 >> >> Actually, can we just make positional-only parameters to render brackets >> in their/Signature's __str__ methods? I think Parameter.kind should be >> enough, without adding additional obstacles. > > True, the check for name clashes in Signature (and the implied numeric > "names") will cover the BoundArguments.parameters case Nick, I also would like to keep Parameter.name being required. I understand that *currently* we have no parameter names specified for builtin methods, but we don't have any mechanisms to introspect them too. Now, in 3.3 (I hope) we introduce a brand new mechanism, and, probably, in 3.4 we have way to define Signatures for builtins. Why not do it right? This whole positional-only case is just a weird anachronism of CPython. - 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 - 5th edition
On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov wrote: > On 2012-06-19, at 8:39 PM, Nick Coghlan wrote: >> 6. I think "return_annotation" can safely be abbreviated to just >> "annotation". The fact it is on the Signature object rather than an >> individual parameter is enough to identify it as the return >> annotation. > > I'm not sure about this one. 'return_annotation' is a very > self-descriptive and clear name. I'm not too worried about that one. If you prefer the longer name, feel free to keep it. >> If we even keep that at all for the initial version of the API, the >> direct "default" and "annotation" attributes would just be read-only >> properties that accessed the "optional" container (reporting >> AttributeError if the corresponding attribute was missing) > > +0. I think that 'optional' is a bit unusual attribute for the stdlib, > but it will work if we make Signature immutable. The name isn't great, but the mapping is a lot more convenient when you need to handle the case of attributes potentially being missing. >> 10. Similar to the discussion of convenience properties on Signature >> objects themselves, I now think we should drop the "args" and "kwargs" > > Big -1 on this one. Look at the current implementation of those > properties - it's quite complex. One of the major points of new > API is to allow easy modifications of arguments. Without .args & > .kwargs it will be a PITA to call a function. > > Imagine, that the "check types" example from the PEP is modified > to coerce arguments to specified types. It won't be possible > to do without .args & .kwargs. I, for instance, use this API to bind, > validate, and coerce arguments for RPC calls. The whole point for me > to work on this PEP was to make these types of functionality easy to > implement. The one thing that slightly concerns me is that given: def f(a): pass s = signature(f) The following produce the same result: s.bind(1) s.bind(a=1) That said, I guess if a parameter is proclaiming itself to be KEYWORD_OR_POSITIONAL, then it really shouldn't care which way the arguments are passed, so a stated preference for binding those as positional parameters is fine. >> properties from the initial version of BoundArguments. Instead, I >> propose the following attributes: >> - arguments (mapping of parameter names to values supplied as arguments) >> - defaults (mapping of unbound parameter names with defaults to >> their default values) > > Why would you need 'defaults'? It's very easy to compile that list > manually (and I believe the use cases will be limited) > >> - unbound (set of unbound names, always empty for bind(), may have >> entries for bind_partial()) > > This may be practical. But again - those are easy to deduce from > 'BoundArguments.arguments' and 'Signature.parameters'. OK, leave them out for now. Perhaps add a simple example showing how to calculate them if you want them? (The most obvious use case I can see is calculating a new signature after using bind_partial) 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 - 5th edition
On Wed, Jun 20, 2012 at 12:15 PM, Yury Selivanov wrote:
> On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
>> True, the check for name clashes in Signature (and the implied numeric
>> "names") will cover the BoundArguments.parameters case
>
> Nick, I also would like to keep Parameter.name being required.
> I understand that *currently* we have no parameter names specified
> for builtin methods, but we don't have any mechanisms to introspect
> them too.
Sure, so long as the name requirement is enforced at construction time
- the current code will happily accept None as the first argument to
parameter.
> Now, in 3.3 (I hope) we introduce a brand new mechanism, and, probably, in
> 3.4 we have way to define Signatures for builtins. Why not do it right?
> This whole positional-only case is just a weird anachronism of CPython.
No, it's a characteristic of any FFI - not all target languages will
support keyword arguments. CPython just happens to use such an FFI as
part of its implementation (due to the nature of the PyArg_Parse*
APIs).
There have been serious (albeit failed so far) attempts at coming up
with an acceptable language level syntax for positional only arguments
on python-ideas, since they're a useful concept when you want to avoid
name clashes with arbitrary keyword arguments and you *can*
effectively implement them in Python using a nested function call to
get the correct kind of error:
def _positional_only(a, b, c):
return a, b, c
def f(*args, **kwds): # "a", "b", "c" are supported as values in "kwds"
a, b, c = _positional_only(*args)
With PEP 362, we can at least *represent* the above API cleanly, even
though there's still no dedicated syntax:
>>> def _param(name): return Parameter(name, Parameter.POSITIONAL_ONLY)
>>> s = Signature([_param("a"), _param("b"), _param("c"),
Parameter("kwds", Parameter.VAR_KEYWORD])
>>> str(s)
(, , , **kwds)
If a syntax for positional only parameters is ever defined in the
future, then the Signature __str__ implementation can be updated to
use it at the time.
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 - 5th edition
On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>> 7. The idea of immutable Signature objects does highlight an annoyance
>> with the "attribute may be missing" style APIs. To actually duplicate
>> a signature correctly, including its return annotation (and assuming
>> the attribute is renamed), you would have to do something like:
>>
>> try:
>> note = {"annotation": old_sig.annotation}
>> except AttributeError:
>> note = {}
>> new_sig = Signature(old_sig.parameters[1:], **note)
BTW, we don't have slices for OrderedDict. Since the slice object is
not hashable, we can implement it safely. I can create an issue (and draft
implementation), as I think it'd be quite a useful feature.
-
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 - 5th edition
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov > wrote: >>> 10. Similar to the discussion of convenience properties on Signature >>> objects themselves, I now think we should drop the "args" and "kwargs" >> >> Big -1 on this one. Look at the current implementation of those >> properties - it's quite complex. One of the major points of new >> API is to allow easy modifications of arguments. Without .args & >> .kwargs it will be a PITA to call a function. >> >> Imagine, that the "check types" example from the PEP is modified >> to coerce arguments to specified types. It won't be possible >> to do without .args & .kwargs. I, for instance, use this API to bind, >> validate, and coerce arguments for RPC calls. The whole point for me >> to work on this PEP was to make these types of functionality easy to >> implement. > > The one thing that slightly concerns me is that given: > >def f(a): pass >s = signature(f) > > The following produce the same result: >s.bind(1) >s.bind(a=1) > > That said, I guess if a parameter is proclaiming itself to be > KEYWORD_OR_POSITIONAL, then it really shouldn't care which way the > arguments are passed, so a stated preference for binding those as > positional parameters is fine. Right. >>> properties from the initial version of BoundArguments. Instead, I >>> propose the following attributes: >>> - arguments (mapping of parameter names to values supplied as arguments) >>> - defaults (mapping of unbound parameter names with defaults to >>> their default values) >> >> Why would you need 'defaults'? It's very easy to compile that list >> manually (and I believe the use cases will be limited) >> >>> - unbound (set of unbound names, always empty for bind(), may have >>> entries for bind_partial()) >> >> This may be practical. But again - those are easy to deduce from >> 'BoundArguments.arguments' and 'Signature.parameters'. > > OK, leave them out for now. Perhaps add a simple example showing how > to calculate them if you want them? (The most obvious use case I can > see is calculating a new signature after using bind_partial) OK, will add an example to the PEP - 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 - 5th edition
Nick, I started a new branch to experiment with immutable Signatures. So far, almost everything works (except a couple unit-tests, that are modifying now immutable Parameters & Signatures) https://bitbucket.org/1st1/cpython/changesets/tip/branch(%22pep362-2%22) I hope tomorrow we get some feedback on this, and if it's positive - I'll finish off the implementation and update the PEP. I hope we still can make it to 3.3. - 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 - 5th edition
On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
wrote:
> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> 7. The idea of immutable Signature objects does highlight an annoyance
>>> with the "attribute may be missing" style APIs. To actually duplicate
>>> a signature correctly, including its return annotation (and assuming
>>> the attribute is renamed), you would have to do something like:
>>>
>>> try:
>>> note = {"annotation": old_sig.annotation}
>>> except AttributeError:
>>> note = {}
>>> new_sig = Signature(old_sig.parameters[1:], **note)
>
> BTW, we don't have slices for OrderedDict. Since the slice object is
> not hashable, we can implement it safely. I can create an issue (and draft
> implementation), as I think it'd be quite a useful feature.
No need, my example was just wrong, it should be:
new_sig = Signature(old_sig.parameters.values()[1:])
The constructor accepts an iterable of Parameter objects rather than a mapping.
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 - 5th edition
On 2012-06-19, at 11:24 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 12:36 PM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 9:22 PM, Yury Selivanov wrote:
>>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
7. The idea of immutable Signature objects does highlight an annoyance
with the "attribute may be missing" style APIs. To actually duplicate
a signature correctly, including its return annotation (and assuming
the attribute is renamed), you would have to do something like:
try:
note = {"annotation": old_sig.annotation}
except AttributeError:
note = {}
new_sig = Signature(old_sig.parameters[1:], **note)
>>
>> BTW, we don't have slices for OrderedDict. Since the slice object is
>> not hashable, we can implement it safely. I can create an issue (and draft
>> implementation), as I think it'd be quite a useful feature.
>
> No need, my example was just wrong, it should be:
>
> new_sig = Signature(old_sig.parameters.values()[1:])
>
> The constructor accepts an iterable of Parameter objects rather than a
> mapping.
That's the code I've ended up with:
sig = signature(obj.__func__)
return Signature(OrderedDict(tuple(sig.parameters.items())[1:]),
**sig.optional)
Still looks better than creating implicit & explicit copies ;)
As for slices support in OrderedDict -- it would return values, so
it won't solve the problem anyways.
-
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 - 5th edition
On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> wrote:
>> On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:
>>> If we even keep that at all for the initial version of the API, the
>>> direct "default" and "annotation" attributes would just be read-only
>>> properties that accessed the "optional" container (reporting
>>> AttributeError if the corresponding attribute was missing)
>>
>> +0. I think that 'optional' is a bit unusual attribute for the stdlib,
>> but it will work if we make Signature immutable.
>
> The name isn't great, but the mapping is a lot more convenient when
> you need to handle the case of attributes potentially being missing.
What if instead of 'optional', we have 'base_signature'
(or 'from_signature')?
sig = signature(func)
params = OrderedDict(tuple(sig.parameters.items())[1:])
new_sig = Signature(params, base_signature=sig)
And for Paramater:
param = sig.parameters['foo']
param1 = Parameter('bar', base_parameter=param)
param2 = Parameter('spam', annotation=int, base_parameter=param)
param3 = Parameter(base_parameter=param)
param4 = Parameter(default=42, base_parameter=param)
So 'base_parameter' will be a template from which Parameter's constructor
will copy the missing arguments.
-
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 397 - Last Comments
Sorry, but I missed the announcement of an updated PEP. It looks good to me! Also, I see no reason not to always use a 32bit version of the launcher other than (a) the 64bit code already exists and works and (b) it might mean it is no longer possible to do a complete build of a 64bit Python without the 32bit compilers installed. But (b) is really only a theoretical problem so I think in practice it would be fine either way. Thanks to Martin for updating it - I agree it is vastly improved! Cheers, Mark On 19/06/2012 2:31 PM, Brian Curtin wrote: Martin approached me earlier and requested that I act as PEP czar for 397. I haven't been involved in the writing of the PEP and have been mostly observing from the outside, so I accepted and hope to get this wrapped up quickly and implemented in time for the beta. The PEP is pretty complete, but there are a few outstanding issues. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy wrote: "Independent installations will always only overwrite newer versions of the launcher with older versions." 'always only' is a bit awkward and the sentence looks backwards to me. I would expect only overwriting older versions with newer versions. Agreed, I would expect the same. I would think taking out the word "only" and then flipping newer and older in the sentence would correct it. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy wrote: These seem contradictory: "The 32-bit distribution of Python will not install a 32-bit version of the launcher on a 64-bit system." I presume this mean that it will install the 64-bit version and that there will always be only one version of the launcher on the system. "On 64bit Windows with both 32bit and 64bit implementations of the same (major.minor) Python version installed, the 64bit version will always be preferred. This will be true for both 32bit and 64bit implementations of the launcher - a 32bit launcher will prefer to execute a 64bit Python installation of the specified version if available." This implies to me that the 32bit installation *will* install a 32bit launcher and that there could be both versions of the launcher installed. I took that as covering an independently-installed launcher. You could always install your own 32-bit launcher, and it'd prefer to launch a binary matching the machine type. So yes, there could be multiple launchers installed for different machine types, and I'm not sure why we'd want to (or how we could) prevent people from installing them. You could have a 64-bit launcher available system-wide in your Windows folder, then you could have a 32-bit launcher running out of C:\Users\Terry for some purposes. Martin - is that correct? === Outside of Terry's concerns, I find the updated PEP almost ready to go as-is. Many of the updates were in line with what Martin and I briefly talked about at PyCon, and I believe some of them came out of previous PEP discussions on here, so I see nothing unexpected at this point. My only additional comment would be to have the "Configuration file" implementation details supplemented with a readable example of where the py.ini file should be placed. On my machine that is "C:\Users\brian\AppData\Local", rather than making people have to run that parameter through the listed function via pywin32. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/skippy.hammond%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] Status of packaging in 3.3
Nick nailed it (again). On Tue, Jun 19, 2012 at 3:14 PM, Nick Coghlan wrote: > Reverting and writing a full packaging PEP for 3.4 sounds like a wise > course of action to me. > > Regards, > Nick. > -- > Sent from my phone, thus the relative brevity :) > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ 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 - 5th edition
On Wed, Jun 20, 2012 at 1:28 PM, Yury Selivanov wrote: > On 2012-06-19, at 11:24 PM, Nick Coghlan wrote: >> The constructor accepts an iterable of Parameter objects rather than a >> mapping. > > That's the code I've ended up with: > > sig = signature(obj.__func__) > return Signature(OrderedDict(tuple(sig.parameters.items())[1:]), > **sig.optional) Why require a mapping as the argument? A simple iterable of Parameter objects seems like a more convenient constructor API to me. The constructor can take care of building the mapping from that internally via: param_map = OrderedDict((param.name, param for param in parameters)) > Still looks better than creating implicit & explicit copies ;) Indeed :) > > As for slices support in OrderedDict -- it would return values, so > it won't solve the problem anyways. You wouldn't want to do it anyway - while slices happen to not be hashable *now*, there's no strong reason behind that. 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 - 5th edition
On Wed, Jun 20, 2012 at 1:51 PM, Yury Selivanov wrote:
> What if instead of 'optional', we have 'base_signature'
> (or 'from_signature')?
>
> sig = signature(func)
> params = OrderedDict(tuple(sig.parameters.items())[1:])
> new_sig = Signature(params, base_signature=sig)
>
> And for Paramater:
>
> param = sig.parameters['foo']
>
> param1 = Parameter('bar', base_parameter=param)
> param2 = Parameter('spam', annotation=int, base_parameter=param)
> param3 = Parameter(base_parameter=param)
> param4 = Parameter(default=42, base_parameter=param)
>
> So 'base_parameter' will be a template from which Parameter's constructor
> will copy the missing arguments.
Good thought (and better than my initial idea), but I'd follow the
model of namedtuple._replace and make it a separate instance method:
sig = signature(f)
new_sig = sig.replace(parameters=sig.parameters.values()[1:])
param = sig.parameters['foo']
param1 = param.replace(name='bar')
param2 = param.replace(name='spam', annotation=int)
param3 = param.replace() # namedtuple._replace also allows this edge case
param4 = param.replace(default=42)
Such a copy-and-override method should be the last piece needed to
make immutable Signature objects a viable approach.
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] Status of packaging in 3.3
On Wed, Jun 20, 2012 at 11:23 AM, Antoine Pitrou wrote: > The question is what will happen after 3.3. There doesn't seem to be a > lot of activity around the project, does it? I think the desire is there, but there are enough "good enough" approaches around that people find other more immediately satisfying things to do with their time (hammering out consensus on packaging issues takes quite a bit of lead time to fully resolve). This will make a good guinea pig for my "release alphas early" proposal, though :) 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 397 - Last Comments
> It looks good to me! Also, I see no reason not to always use a 32bit > version of the launcher other than I'll change it, then - the strong reason *for* always using a 32-bit launcher is packaging, as the 32-bit installer would otherwise have to include both a 32-bit launcher and a 64-bit launcher, and install the right one depending on what the target system is. > Thanks to Martin for updating it - I agree it is vastly improved! Thanks! Martin ___ 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] Status of packaging in 3.3
What is the status of the third party module on PyPI (distutils2)? Does it contain all fixes done in the packaging module? Does it have exactly the same API? Does it support Python 2.5 to 3.3, or maybe also 2.4? How is the distutils2 module installed? Installed manually? Using pip or setuptools? Is distutils2 included in some Linux distributions? If it's simple to install distutils2, it's not a big deal to not have it in the stdlib. -- It is sometimes a pain to have a buggy module in Python. For example, I got a lot of issues with the subprocess module of Python 2.5. I started to include a copy of the subprocess module from Python 2.7 in my projects to workaround these issues. In my previous work we did also backport various modules to get the last version of the xmlrpc client on Python 2.5 (especially for HTTP/1.1, to not open a new TCP socket at each request). I don't want to reopen the discussion "the stdlib should be an external project". I just want to confirm that it is better to wait until important users of the packaging API have finished their work (on porting their project to distutils2, especially pip), before we can declare the module (and its API) as stable. By the way, what is the status of "pip using distutils2"? 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
