Re: [Python-Dev] [Python-checkins] cpython: Review of signature docs.

2012-08-14 Thread Andrew Svetlov 
Thank you for review.

On Tue, Aug 14, 2012 at 10:45 AM, georg.brandl
 wrote:
> http://hg.python.org/cpython/rev/e1e7d628c0b9
> changeset:   78560:e1e7d628c0b9
> user:Georg Brandl 
> date:Tue Aug 14 09:45:28 2012 +0200
> summary:
>   Review of signature docs.
>
> files:
>   Doc/library/inspect.rst |  127 +--
>   1 files changed, 62 insertions(+), 65 deletions(-)
>
>
> diff --git a/Doc/library/inspect.rst b/Doc/library/inspect.rst
> --- a/Doc/library/inspect.rst
> +++ b/Doc/library/inspect.rst
> @@ -397,25 +397,18 @@
>
>  .. _inspect-signature-object:
>
> -Introspecting callables with Signature Object
> --
> -
> -Signature object represents the call signature of a callable object and its
> -return annotation.  To get a Signature object use the :func:`signature`
> -function.
> -
> +Introspecting callables with the Signature object
> +-
>
>  .. versionadded:: 3.3
>
> -.. seealso::
> -
> -   :pep:`362` - Function Signature Object.
> -  The detailed specification, implementation details and examples.
> -
> +The Signature object represents the call signature of a callable object and 
> its
> +return annotation.  To retrieve a Signature object, use the :func:`signature`
> +function.
>
>  .. function:: signature(callable)
>
> -   Returns a :class:`Signature` object for the given ``callable``::
> +   Return a :class:`Signature` object for the given ``callable``::
>
>>>> from inspect import signature
>>>> def foo(a, *, b:int, **kwargs):
> @@ -432,24 +425,24 @@
>>>> sig.parameters['b'].annotation
>
>
> -   Accepts a wide range of python callables, from plain functions and classes
> -   to :func:`functools.partial` objects.
> +   Accepts a wide range of python callables, from plain functions and 
> classes to
> +   :func:`functools.partial` objects.
>
> .. note::
>
> -  Some callables may not be introspectable in certain implementations
> -  of Python. For example, in CPython, built-in functions defined in C
> -  provide no metadata about their arguments.
> +  Some callables may not be introspectable in certain implementations of
> +  Python.  For example, in CPython, built-in functions defined in C 
> provide
> +  no metadata about their arguments.
>
>
>  .. class:: Signature
>
> -   A Signature object represents the call signature of a function and its
> -   return annotation. For each parameter accepted by the function it
> -   stores a :class:`Parameter` object in its :attr:`parameters` collection.
> +   A Signature object represents the call signature of a function and its 
> return
> +   annotation.  For each parameter accepted by the function it stores a
> +   :class:`Parameter` object in its :attr:`parameters` collection.
>
> -   Signature objects are *immutable*. Use :meth:`Signature.replace` to make
> -   a modified copy.
> +   Signature objects are *immutable*.  Use :meth:`Signature.replace` to make 
> a
> +   modified copy.
>
> .. attribute:: Signature.empty
>
> @@ -462,30 +455,29 @@
>
> .. attribute:: Signature.return_annotation
>
> -  The "return" annotation for the callable. If the callable has
> -  no "return" annotation, this attribute is set to
> -  :attr:`Signature.empty`.
> +  The "return" annotation for the callable.  If the callable has no 
> "return"
> +  annotation, this attribute is set to :attr:`Signature.empty`.
>
> .. method:: Signature.bind(*args, **kwargs)
>
> -  Creates a mapping from positional and keyword arguments to parameters.
> -  Returns :class:`BoundArguments` if ``*args`` and ``**kwargs`` match
> -  the signature, or raises a :exc:`TypeError`.
> +  Create a mapping from positional and keyword arguments to parameters.
> +  Returns :class:`BoundArguments` if ``*args`` and ``**kwargs`` match the
> +  signature, or raises a :exc:`TypeError`.
>
> .. method:: Signature.bind_partial(*args, **kwargs)
>
> -  Works the same way as :meth:`Signature.bind`, but allows the
> -  omission of some required arguments (mimics :func:`functools.partial`
> -  behavior.) Returns :class:`BoundArguments`, or raises a 
> :exc:`TypeError`
> -  if the passed arguments do not match the signature.
> +  Works the same way as :meth:`Signature.bind`, but allows the omission 
> of
> +  some required arguments (mimics :func:`functools.partial` behavior.)
> +  Returns :class:`BoundArguments`, or raises a :exc:`TypeError` if the
> +  passed arguments do not match the signature.
>
> .. method:: Signature.replace([parameters], *, [return_annotation])
>
> -  Creates a new Signature instance based on the instance replace was
> -  invoked on. It is possible to pass different ``parameters`` and/or
> -  ``return_annotation`` to override the corresponding properties of
> -  the base signature. To remove return_annotation

Re: [Python-Dev] AST optimizer implemented in Python

2012-08-14 Thread Kristján Valur Jónsson 


> -Original Message-
> I moved the script to a new dedicated project on Bitbucket:
> https://bitbucket.org/haypo/astoptimizer
> 
> Join the project if you want to help me to build a better optimizer!
> 
> It now works on Python 2.5-3.3.

I had the idea (perhaps not an original one) that peephole optimization would 
be much better
done in python than in C.  The C code is clunky and unwieldly, wheras python 
would be much
better suited, being able to use nifty regexes and the like.

The problem is, there exists only bytecode disassembler, no corresponding 
assembler.

Then I stumbled upon this project:
http://code.google.com/p/byteplay/
Sounds like just the ticket, disassemble the code, do transformations on it, 
then reassemble.
Haven't gotten further than that though :)

K


___
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] AST optimizer implemented in Python

2012-08-14 Thread Victor Stinner 
2012/8/14 Kristján Valur Jónsson :
>> I moved the script to a new dedicated project on Bitbucket:
>> https://bitbucket.org/haypo/astoptimizer
>>
>> Join the project if you want to help me to build a better optimizer!
>>
>> It now works on Python 2.5-3.3.
>
> I had the idea (perhaps not an original one) that peephole optimization would 
> be much better
> done in python than in C.  The C code is clunky and unwieldly, wheras python 
> would be much
> better suited, being able to use nifty regexes and the like.
>
> The problem is, there exists only bytecode disassembler, no corresponding 
> assembler.

Why would you like to work on bytecode instead of AST? The AST
contains much more information, you can implement better optimizations
in AST. AST is also more convinient than bytecode.

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] AST optimizer implemented in Python

2012-08-14 Thread Kristján Valur Jónsson 


> -Original Message-
> From: Victor Stinner [mailto:[email protected]]
> Sent: 14. ágúst 2012 13:32
> To: Kristján Valur Jónsson
> Cc: Python Dev
> Subject: Re: [Python-Dev] AST optimizer implemented in Python
> > The problem is, there exists only bytecode disassembler, no corresponding
> assembler.
> 
> Why would you like to work on bytecode instead of AST? The AST contains
> much more information, you can implement better optimizations in AST. AST
> is also more convinient than bytecode.
> 

We already optimize bytecode.  But it seems much more could be done there.
It also seems like a simpler goal.  Also, AST will need to be changed to 
bytecode at some point, and that bytecode could still be optimized in ways not 
available to the AST, I imagine.
Also, I understand bytecode, more or less :)

K
___
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] AST optimizer implemented in Python

2012-08-14 Thread Hrvoje Niksic 

On 08/14/2012 03:32 PM, Victor Stinner wrote:

 I had the idea (perhaps not an original one) that peephole optimization would 
be much better
 done in python than in C.  The C code is clunky and unwieldly, wheras python 
would be much
 better suited, being able to use nifty regexes and the like.

 The problem is, there exists only bytecode disassembler, no corresponding 
assembler.


Why would you like to work on bytecode instead of AST? The AST
contains much more information, you can implement better optimizations


AST allows for better high-level optimizations, but a real peephole 
optimization pass is actually designed to optimize generated code.  This 
allows eliminating some inefficiencies which would be fairly hard to 
prevent at higher levels - wikipedia provides some examples.

___
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] PEPs build system

2012-08-14 Thread Yury Selivanov 
Hi,

There seems to be a problem with PEPs build process again.
As far as I see - PEP 362 and PEP 398 are out of sync with 
what is in the repo.

Thanks,
-
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

[Python-Dev] Installation on Macs

2012-08-14 Thread Raymond Hettinger 
On Mountain Lion, the default security settings only allow installation of 
applications downloaded from the Mac App Stored and "identified developers".

We need to either become an "identified developer" or include some instructions 
on how to change the security settings (System Preference -- General -- Unlock 
--Select the "Anywhere" radio button -- Install Python -- Restore the original 
settings -- and Relock).  Changing the security settings isn't appealing 
because 1) it weakens the user's security 2) it involves multiple steps and 3) 
the user will see an unsettling warnings along the way. 

Another unrelated issue is that the instructions for updating Tcl/Tk are 
problematic.  In the past few months, I've witnessed hundreds of people 
unsuccessfully trying follow the instructions and having an immediate 
unpleasant out-of-the-box experience when IDLE crashes.  I suggest that we stop 
being so indirect about the chain of footnotes and links leading to a Tcl/Tk 
download.  I would like to see a direct Tcl/Tk updater link side-by-side with 
our Python installer link at http://www.python.org/download/releases/2.7.3/

Someone did add a note the the IDLE startup screen to the effect of:  "WARNING: 
The version of Tcl/Tk (8.5.9) in use may be unstable.
Visit http://www.python.org/download/mac/tcltk/ for current information."   In 
some ways this is progress.  In others, it falls short.  If IDLE crashes, you 
can't see the message.  If you have installed the ActiveTCL 8.5.12 update, you 
still see the warning eventhough it isn't necessary.  Also, I don't link that 
the referenced page is so complex and that it is full unsettling warnings, 
important notices, do-not-use advice, mentions of instability,  etc.  

I would like to see our download page have something more simple, affirmative, 
positively worded and direct.  For example:

*  Mac OS X 64-bit/32-bit Installer (3.2.3) for Mac OS X 10.6 and 10.7 [2] 
(sig).  To run IDLE or Tkinter, you need to update Tcl/Tk to ActiveTcl 8.5.12 
 .

That saves you from having to click a links down to a footnote at the bottom of 
the page  that sends you 
to  which is  another page full of 
tables, warnings,etc that leads you to the Apple 8.5.9 section 
 which is a dead-end 
because there are still known issues with 8.5.9, leaving you with the ActiveTCL 
section  which has 
a paragraph of text obscuring the link you actually needed: 
http://www.activestate.com/activetcl/downloads .

I applaud that some effort was made to document a solution; however, in 
practice the daisy chain of footnotes, tables, and links has proven unworkable 
for most of the engineers I've been working with.


Raymond

___
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] Installation on Macs

2012-08-14 Thread Jesse Noller 
I think becoming an apple signed developer to get a cert is the best approach.

If anyone wanted to approach apple about open source/non profit gratis 
licenses, that would be appreciated. 

Otherwise I could do it / fund it from the PSF board side, which I am happy to 
do.

I also concur with Raymond that the download/install instructions could be 
simplified. Noting for users that rather than downloading Xcode, they can just 
download the OSX Command Line Tools installer and easy_install/pip/etc will 
just work would also be nice

Jesse 

On Aug 14, 2012, at 8:33 PM, Raymond Hettinger  
wrote:

> On Mountain Lion, the default security settings only allow installation of 
> applications downloaded from the Mac App Stored and "identified developers".
> 
> We need to either become an "identified developer" or include some 
> instructions on how to change the security settings (System Preference -- 
> General -- Unlock --Select the "Anywhere" radio button -- Install Python -- 
> Restore the original settings -- and Relock).  Changing the security settings 
> isn't appealing because 1) it weakens the user's security 2) it involves 
> multiple steps and 3) the user will see an unsettling warnings along the way. 
> 
> Another unrelated issue is that the instructions for updating Tcl/Tk are 
> problematic.  In the past few months, I've witnessed hundreds of people 
> unsuccessfully trying follow the instructions and having an immediate 
> unpleasant out-of-the-box experience when IDLE crashes.  I suggest that we 
> stop being so indirect about the chain of footnotes and links leading to a 
> Tcl/Tk download.  I would like to see a direct Tcl/Tk updater link 
> side-by-side with our Python installer link at 
> http://www.python.org/download/releases/2.7.3/
> 
> Someone did add a note the the IDLE startup screen to the effect of:  
> "WARNING: The version of Tcl/Tk (8.5.9) in use may be unstable.
> Visit http://www.python.org/download/mac/tcltk/ for current information."   
> In some ways this is progress.  In others, it falls short.  If IDLE crashes, 
> you can't see the message.  If you have installed the ActiveTCL 8.5.12 
> update, you still see the warning eventhough it isn't necessary.  Also, I 
> don't link that the referenced page is so complex and that it is full 
> unsettling warnings, important notices, do-not-use advice, mentions of 
> instability,  etc.  
> 
> I would like to see our download page have something more simple, 
> affirmative, positively worded and direct.  For example:
> 
> *  Mac OS X 64-bit/32-bit Installer (3.2.3) for Mac OS X 10.6 and 10.7 [2] 
> (sig).  To run IDLE or Tkinter, you need to update Tcl/Tk to ActiveTcl 8.5.12 
>  .
> 
> That saves you from having to click a links down to a footnote at the bottom 
> of the page  that sends 
> you to  which is  another page full 
> of tables, warnings,etc that leads you to the Apple 8.5.9 section 
>  which is a dead-end 
> because there are still known issues with 8.5.9, leaving you with the 
> ActiveTCL section 
>  which has a 
> paragraph of text obscuring the link you actually needed: 
> http://www.activestate.com/activetcl/downloads .
> 
> I applaud that some effort was made to document a solution; however, in 
> practice the daisy chain of footnotes, tables, and links has proven 
> unworkable for most of the engineers I've been working with.
> 
> 
> Raymond
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jnoller%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