Re: [Python-Dev] The devguide is now hosted on GitHub

2016-08-04 Thread Sven R. Kunze 

Thanks a lot. :)


On 22.07.2016 22:04, Brett Cannon wrote:

https://github.com/python/devguide

I have also moved all issues over as well and hooked up Read The Docs 
so that there's a mirror which is always up-to-date (vs. 
docs.python.org/devguide  which is on 
a cronjob).



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] stuck issue 26826

2016-08-04 Thread Nick Coghlan 
On 4 August 2016 at 06:32, Marcos Dione  wrote:
> Maybe you're right. Maybe, to keep Python's own code simple, we could
> skip these optimizations, and leave them in a 3rd party module.

Having the scandir package on PyPI made it possible for folks to
quantify the benefits of the new os.scandir() call for different
workloads before we committed to adding it to the standard library. It
also had the benefit of allowing folks to achieve the speedups by
installing the library and changing their code if that was easier for
them than waiting for a new release of CPython and upgrading to it
(e.g. that's common for library authors that focus on Linux can often
require an extra C dependency without too much hassle, but also
frequently target the older versions of Python shipped by long term
support distros).

It seems to me that a dedicated "os_linux" addon module on PyPI could
serve a dual purpose in making updated os module APIs available on
older versions of Python, as well as in providing a venue for folks to
experiment with the performance of new syscalls before proposing them
for stdlib inclusion.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Alexander Belopolsky 
What is the current status of the Argument Clinic DSL?  The clinic
preprocessor was released [1] with Python 3.4 with a promise [2] "that
signature metadata for programmatic introspection will be added to
additional callables implemented in C as part of Python 3.4
maintenance releases."  We are now close to 3.6 beta and clinic
coverage in stdlib is sparse at best.  For example, the math module
makes no use of the clinic (but interestingly a few methods in cmath
do).  The documentation is very sparse as well.  While one would
expect PEP 436 to serve as *the* documentation while clinic is being
developed, but the PEP has the "Draft" status and has not been updated
since 2013.  Furthermore, the 3.4 release notes contain a warning
saying "The Argument Clinic PEP is not fully up to date with the state
of the implementation."  It does not look like this situation has
improved since.

The practical question is: does it make sense to invest time in
learning the clinic DSL and converting more modules (e.g. datetime) to
it or it is likely that the whole approach will be revised in the
future?

[1] http://bugs.python.org/issue16612
[2] 
https://docs.python.org/3.6/whatsnew/3.4.html?highlight=clinic#pep-436-argument-clinic
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Method signatures in the datetime module documentation

2016-08-04 Thread Alexander Belopolsky 
On Wed, Aug 3, 2016 at 10:41 PM, Martin Panter  wrote:
> If replace() actually supported these keywords all along, then I am happy
> with this proposal.
>

With the obvious exception of "fold", it did at least since Python 3.0
(and likely since 2.x where x is 5 ± 1.)

> There are a few bug reports that may be relevant:
>
> https://bugs.python.org/issue13386: notation where there is no simple
> default value
> https://bugs.python.org/issue23738: notation for defaults for
> positional-only parameters

Thanks.  These are helpful, but they don't address the case in hand
where the member function defaults are taken from the other
attributes.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Brett Cannon 
On Thu, 4 Aug 2016 at 09:14 Alexander Belopolsky <
[email protected]> wrote:

> What is the current status of the Argument Clinic DSL?  The clinic
> preprocessor was released [1] with Python 3.4 with a promise [2] "that
> signature metadata for programmatic introspection will be added to
> additional callables implemented in C as part of Python 3.4
> maintenance releases."  We are now close to 3.6 beta and clinic
> coverage in stdlib is sparse at best.  For example, the math module
> makes no use of the clinic (but interestingly a few methods in cmath
> do).  The documentation is very sparse as well.  While one would
> expect PEP 436 to serve as *the* documentation while clinic is being
> developed, but the PEP has the "Draft" status and has not been updated
> since 2013.  Furthermore, the 3.4 release notes contain a warning
> saying "The Argument Clinic PEP is not fully up to date with the state
> of the implementation."  It does not look like this situation has
> improved since.
>

I always read https://docs.python.org/3/howto/clinic.html as the
documentation and not the PEP.


>
> The practical question is: does it make sense to invest time in
> learning the clinic DSL and converting more modules (e.g. datetime) to
> it


Yes. Part of the issue is there was a big push to convert modules for the
3.4 release and some of us helped convert however many we can, but then
people stopped putting the time in to convert code a module at a time once
3.4 was released. Serhiy has actually been working on a patch to speed up
keyword parsing which will automatically be applied to code using Argument
Clinic: http://bugs.python.org/issue27574 .


> or it is likely that the whole approach will be revised in the
> future?
>
>
I don't see it being revised, but maybe Larry has something to say on the
matter.


> [1] http://bugs.python.org/issue16612
> [2]
> https://docs.python.org/3.6/whatsnew/3.4.html?highlight=clinic#pep-436-argument-clinic
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Larry Hastings 



On 08/04/2016 09:11 AM, Alexander Belopolsky wrote:

Furthermore, the 3.4 release notes contain a warning
saying "The Argument Clinic PEP is not fully up to date with the state
of the implementation."  It does not look like this situation has
improved since.


It hasn't.  The PEP lags behind the implementation.  The HOWTO is 
up-to-date though.




The practical question is: does it make sense to invest time in
learning the clinic DSL and converting more modules (e.g. datetime) to
it or it is likely that the whole approach will be revised in the
future?


AFAIK the Clinic DSL can handle all of Python's C extensions.  I have no 
plans to "revise the whole approach"; if someone else does I haven't 
heard about it.



//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Alexander Belopolsky 
On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings  wrote:

> AFAIK the Clinic DSL can handle all of Python's C extensions.  I have no
> plans to "revise the whole approach"; if someone else does I haven't heard
> about it.


I was just wondering that with so much effort to bring typing to the
mainstream, a more "pythonic" DSL may emerge for describing the signatures
of functions in C modules.

BTW, is there any document describing the syntax of "text signatures" such
as:

>>> os.rename.__text_signature__
'($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)'

?

What does the "$module, /," part mean?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Alexander Belopolsky 
On Thu, Aug 4, 2016 at 7:00 PM, Brett Cannon  wrote:
>> >>> os.rename.__text_signature__
>> '($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)'
>>
>> ?
>>
>> What does the "$module, /," part mean?
>
>
> Don't remember what the $module means but the / means positional-only
> arguments.

Not in this case.  Apparently the / applies to the $module thingy
because src and dst are not positional only (and the / would be after
them if they were, I think.)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Brett Cannon 
On Thu, 4 Aug 2016 at 15:47 Alexander Belopolsky <
[email protected]> wrote:

>
> On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings  wrote:
>
>> AFAIK the Clinic DSL can handle all of Python's C extensions.  I have no
>> plans to "revise the whole approach"; if someone else does I haven't heard
>> about it.
>
>
> I was just wondering that with so much effort to bring typing to the
> mainstream, a more "pythonic" DSL may emerge for describing the signatures
> of functions in C modules.
>
> BTW, is there any document describing the syntax of "text signatures" such
> as:
>
> >>> os.rename.__text_signature__
> '($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)'
>
> ?
>
> What does the "$module, /," part mean?
>

Don't remember what the $module means but the / means positional-only
arguments.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Larry Hastings 

On 08/04/2016 03:45 PM, Alexander Belopolsky wrote:


On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings > wrote:


AFAIK the Clinic DSL can handle all of Python's C extensions.  I
have no plans to "revise the whole approach"; if someone else does
I haven't heard about it.


I was just wondering that with so much effort to bring typing to the 
mainstream, a more "pythonic" DSL may emerge for describing the 
signatures of functions in C modules.


BTW, is there any document describing the syntax of "text signatures" 
such as:


>>> os.rename.__text_signature__
'($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)'

?

What does the "$module, /," part mean?



/ is the delimiter between positional-only parameters and 
positional-or-keyword arguments.  It's not actual Python syntax, but 
Guido said (somewhere) that *if* Python ever sprouted a syntax for 
positional-only parameters, that was as good a delimiter as any.  I 
think he picked it because / is the inverse of *.


The "$" in "$module" means it's what we called a "bound parameter", a 
parameter which gets bound to a value before Python ever sees it.  C 
extension functions get the module passed in automatically, but this is 
done internally and from the Python level you can't see it.  So it's 
accurate to present it there, but we suppress it before we compute the 
inspect.signature.  For example, os_chdir_impl in Modules/posixmodule.c 
takes two arguments, the first being the module, the second being the 
path; inspect.signature(os.chdir) only shows one parameter, the path.


__text_signature__, although user-visible, is not considered information 
for users.  It's an internal implementation detail like co_code.  
However, with the exception of things like "$module" and "/" it's just a 
Python function declaration. Literally we remove the funny bits like 
"$module" and "/", prepend that string with "def foo", append that 
string with ": pass", and parse the result with ast.parse.


If you have more questions about __text_signature__, I recommend reading 
the implementation of inspect.signature, since that's the one and only 
consumer of it.



//arry/

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread Alexander Belopolsky 
On Thu, Aug 4, 2016 at 7:12 PM, Larry Hastings  wrote:

> C extension functions get the module passed in automatically, but this is
> done internally and from the Python level you can't see it.


Always something new to learn!  This was not so in Python 2.x - self was
passed as NULL to the C module functions.  When did this change?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the Argument Clinic DSL

2016-08-04 Thread eryk sun 
On Thu, Aug 4, 2016 at 11:33 PM, Alexander Belopolsky
 wrote:
>
> On Thu, Aug 4, 2016 at 7:12 PM, Larry Hastings  wrote:
>>
>> C extension functions get the module passed in automatically, but this is
>> done internally and from the Python level you can't see it.
>
> Always something new to learn!  This was not so in Python 2.x - self was
> passed as NULL to the C module functions.  When did this change?

In 2.x this is the `self` parameter (actually named "passthrough" in
the source) of Py_InitModule4 [1, 2]. You probably use the
Py_InitModule or Py_InitModule3 macros, which pass NULL for this
parameter:

#define Py_InitModule(name, methods) \
Py_InitModule4(name, methods, (char *)NULL, (PyObject *)NULL, \
   PYTHON_API_VERSION)

#define Py_InitModule3(name, methods, doc) \
Py_InitModule4(name, methods, doc, (PyObject *)NULL, \
   PYTHON_API_VERSION)

Python 3's PyModule_Create2 [3-5] API makes this a reference to the
module. It's currently implemented in
PyModule_AddFunctions [6, 7].

[1]: https://docs.python.org/2/c-api/allocation.html#c.Py_InitModule4
[2]: https://hg.python.org/cpython/file/v2.7.12/Python/modsupport.c#l31
[3]: https://docs.python.org/3/c-api/module.html#c.PyModule_Create2
[4]: https://hg.python.org/cpython/file/v3.5.2/Objects/moduleobject.c#l133
[5]: https://hg.python.org/cpython/file/v3.0b1/Objects/moduleobject.c#l63
[6]: https://docs.python.org/3/c-api/module.html#c.PyModule_AddFunctions
[7]: https://hg.python.org/cpython/file/v3.5.2/Objects/moduleobject.c#l387
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com