Re: [Python-Dev] __signature__ for PySide ready

2017-08-19 Thread Nick Coghlan 
On 19 August 2017 at 02:55, Jelle Zijlstra  wrote:
> 2017-08-18 18:20 GMT+02:00 Yury Selivanov :
>> There's a backport of signature API to Python 2.  Although last time I
>> checked it was fairly outdated.
>>
> I wrote a backport earlier this year: https://pypi.python.org/pypi/inspect2.

Nice.

Yury was probably referring to https://funcsigs.readthedocs.io/, which
is a partial backport specifically of inspect.Signature and friends.

Either way, the answer to Christian's original question is that "Yes,
supporting __signature__ is also useful in Python 2.x", as even though
the native inspect module doesn't support it, 3rd party backports do.

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

Re: [Python-Dev] PEP 550 v3

2017-08-19 Thread Nick Coghlan 
On 19 August 2017 at 06:33, Yury Selivanov  wrote:
> Hi,
>
> This is a third iteration of the PEP.
>
> There was some really good feedback on python-ideas and
> the discussion thread became hard to follow again, so I decided to
> update the PEP only three days after I published the previous
> version.
>
> Summary of the changes can be found in the "Version History"
> section: https://www.python.org/dev/peps/pep-0550/#version-history
>
> There are a few open questions left, namely the terminology
> and design of ContextKey API.  On the former topic, I'm quite
> happy with the latest version: Execution Context, Logical
> Context, and Context Key.

Nice, I quite like this version of the naming scheme and the core
design in general.

While Guido has a point using the same noun for two different things
being somewhat confusing, I think the parallel here is the one between
the local scope and the lexical (nonlocal) scope for variable names -
just as your lexical scope is a nested stack of local scopes in outer
functions, your execution context is your current logical context plus
a nested stack of outer logical contexts.

> Generator Object Modifications
> ^^
>
> To achieve this, we make a small set of modifications to the
> generator object:
>
> * New ``__logical_context__`` attribute.  This attribute is readable
>   and writable for Python code.
>
> * When a generator object is instantiated its ``__logical_context__``
>   is initialized with an empty ``LogicalContext``.
>
> * Generator's ``.send()`` and ``.throw()`` methods are modified as
>   follows (in pseudo-C)::
>
> if gen.__logical_context__ is not NULL:
> tstate = PyThreadState_Get()
>
> tstate.execution_context.push(gen.__logical_context__)
>
> try:
> # Perform the actual `Generator.send()` or
> # `Generator.throw()` call.
> return gen.send(...)
> finally:
> gen.__logical_context__ = tstate.execution_context.pop()
> else:
> # Perform the actual `Generator.send()` or
> # `Generator.throw()` call.
> return gen.send(...)

I think this pseudo-code expansion includes a few holdovers from the
original visibly-immutable API design.

Given the changes since then, I think this would be clearer if the
first branch used sys.run_with_logical_context(), since the logical
context references at the Python layer now behave like shared mutable
objects, and the apparent immutability of
sys.run_with_execution_context() comes from injecting a fresh logical
context every time.

Also +1 to the new design considerations questions that explicitly
postpones consideration of any of my "What about..."" questions from
python-ideas to future PEPs.

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

Re: [Python-Dev] __signature__ for PySide ready

2017-08-19 Thread Christian Tismer 
Hi Nick,

On 19.08.17 09:37, Nick Coghlan wrote:
> On 19 August 2017 at 02:55, Jelle Zijlstra  wrote:
>> 2017-08-18 18:20 GMT+02:00 Yury Selivanov :
>>> There's a backport of signature API to Python 2.  Although last time I
>>> checked it was fairly outdated.
>>>
>> I wrote a backport earlier this year: https://pypi.python.org/pypi/inspect2.
> 
> Nice.
> 
> Yury was probably referring to https://funcsigs.readthedocs.io/, which
> is a partial backport specifically of inspect.Signature and friends.
> 
> Either way, the answer to Christian's original question is that "Yes,
> supporting __signature__ is also useful in Python 2.x", as even though
> the native inspect module doesn't support it, 3rd party backports do.

I did not use a backport, but simply hacked it together, myself:

- Take the signature part of Python 3.6 out,
- Adjust the syntax to Python 2.7.

The hairy part was my way to create the PySide PyCFunction objects in
a compatible way like Python 3 does it: the handling of PyCFunction's
"self" parameter is different (holds type info, Python 2 does not).
That needed much more internal knowledge as intended...

Well, I thought the existence of __signature__ might be a good reason
to switch to Python 3, but if I support Python 2, the advantage
is gone. But if it's ok with you, then I'll publish both versions.

Thanks a lot for the feedback.

Ciao - Chris

-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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] PEP 550 v3

2017-08-19 Thread Antoine Pitrou 
On Fri, 18 Aug 2017 16:33:27 -0400
Yury Selivanov  wrote:
> 
> There are a few open questions left, namely the terminology
> and design of ContextKey API.  On the former topic, I'm quite
> happy with the latest version: Execution Context, Logical
> Context, and Context Key.

I don't really like it.  "Logical Context" is vague (there are
lots of things called "context" in other libraries, so a bit of
specificity would help avoid confusion), and it's not clear what is
"logical" about it anyway.  "Local Context" actually seemed better to
me (as it reminded of threading.local() or the general notion of
thread-local storage).

Regards

Antoine.


___
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] __signature__ for PySide ready

2017-08-19 Thread Christian Tismer 
Hi Brett,

On 18.08.17 18:31, Brett Cannon wrote:
> 
> 
> On Fri, 18 Aug 2017 at 02:05 Christian Tismer  > wrote:
> 
...

> Is it a bad idea to support signatures in Python 2 as well?
> Do I introduce a feature that should not exist in Python 2?
> Or is it fine to do so?
> 
> Please let me know your opinion, I am happy with any result.
> 
> 
> If you're getting paid to do the port then I don't think it really hurts
> anything since it isn't going to magically open Python 2 to more usage.
> In fact, if you are filling in the annotation information so that type
> hints are being exposed then maybe there's a chance it might help
> someone port to Python 3?

Well, I took extra precautions to make sure that existing PyCFunctions
are not affected in any way. The new types are clones of the original
types, and only PySide sees the additional attribute for it's functions.

So, no, I don not create magically signatures for Python 2 functions.

But I really warned my customer that the feature might not be welcomed
for Python 2, and we might only enable it internally for testing.

As said, I'm happy with either answer.

Cheers -- Chris

-- 
Christian Tismer :^)   [email protected]
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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] __signature__ for PySide ready

2017-08-19 Thread Nick Coghlan 
On 19 August 2017 at 18:38, Christian Tismer  wrote:
> On 19.08.17 09:37, Nick Coghlan wrote:
>> Either way, the answer to Christian's original question is that "Yes,
>> supporting __signature__ is also useful in Python 2.x", as even though
>> the native inspect module doesn't support it, 3rd party backports do.
>
> I did not use a backport, but simply hacked it together, myself:
>
> - Take the signature part of Python 3.6 out,
> - Adjust the syntax to Python 2.7.

The backports we're talking about are the ones that can *read*
__signature__ attributes, as well as synthesise them from the
underlying attributes on Python level functions and code objects.

> The hairy part was my way to create the PySide PyCFunction objects in
> a compatible way like Python 3 does it: the handling of PyCFunction's
> "self" parameter is different (holds type info, Python 2 does not).
> That needed much more internal knowledge as intended...
>
> Well, I thought the existence of __signature__ might be a good reason
> to switch to Python 3, but if I support Python 2, the advantage
> is gone. But if it's ok with you, then I'll publish both versions.

The builtins and standard library extension modules in 2.7 will never
gain signature information (since there's no equivalent of Argument
Clinic to populate the __text_signature__ attributes).

However, aside from it being extra work that they may not want to do,
there's no particular reason for 3rd party modules to avoid providing
better signatures in Python 2.x.

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

Re: [Python-Dev] PEP 550 v3

2017-08-19 Thread Brett Cannon 
On Sat, Aug 19, 2017, 01:43 Antoine Pitrou  wrote:

> On Fri, 18 Aug 2017 16:33:27 -0400
> Yury Selivanov  wrote:
> >
> > There are a few open questions left, namely the terminology
> > and design of ContextKey API.  On the former topic, I'm quite
> > happy with the latest version: Execution Context, Logical
> > Context, and Context Key.
>
> I don't really like it.  "Logical Context" is vague (there are
> lots of things called "context" in other libraries, so a bit of
> specificity would help avoid confusion), and it's not clear what is
> "logical" about it anyway.  "Local Context" actually seemed better to
> me (as it reminded of threading.local() or the general notion of
> thread-local storage).
>
>
I have to admit that I didn't even pick up on that name change. I could go
either way.

I do appreciate dropping ContextItem, though, because "CI" makes me think
of continuous integration. And the overall shape of the API for public
consumption LGTM.

-brett


>
> Regards
>
> Antoine.
>
>
> ___
> 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] Buildbot report, August 2017

2017-08-19 Thread Brett Cannon 
Thanks for all of this, Victor!

On Fri, Aug 18, 2017, 09:38 Victor Stinner  wrote:

> Hi,
>
> Here is a quick report of what changed recently on buildbots.
>
>
> == pythoninfo ==
>
> I added a new "python3 -m test.pythoninfo" command which is now run on
> Travis CI, AppVeyor and buildbots.
>
> https://bugs.python.org/issue30871
>
> This command dumps various informations to help debugging test
> failures on our CIs. For example, you get the Tcl version, information
> about the threading implementation, etc.
>
> Currently, pythoninfo is only run on the master branch, but I plan to
> run it on Python 3.6 and 2.7 later.
>
> The pythoninfo idea comes from https://bugs.python.org/issue29854 when
> we didn't know the readline version of a buildbot, and I didn't want
> to put such information in regrtest header, since importing readline
> has side effects.
>
>
> == Removed buildbots ==
>
> A few buildbots were removed:
>
> * All Python 3.5 buildbots was removed, since the 3.5 branch entered
> the security only stage:
>   https://mail.python.org/pipermail/python-dev/2017-August/148794.html
>
> * FreeBSD 9-STABLE (koobs-freebsd9): FreeBSD 9 is no more supported
> upstream, use FreeBSD 10 and FreeBSD CURRENT buildbots
>
> * OpenIndiana: was offline since the beginning of June. Previous
> discussions on
>   this list:
>
>   * September 2016: OpenIndiana and Solaris support
>
> https://mail.python.org/pipermail/python-dev/2016-September/146538.html
>   * April 2015: MemoryError and other bugs on AMD64 OpenIndiana 3.x
> https://mail.python.org/pipermail/python-dev/2015-April/138967.html
>   * September 2014: Sad status of Python 3.x buildbots
>
> https://mail.python.org/pipermail/python-dev/2014-September/136175.html
>
> * intel-ubuntu-skylake: Florin Papa wrote me that the machine became
>   unavailable in December 2016.
>
> * Yosemite ICC buildbot (intel-yosemite-icc): it was maintained by Zachary
> Ware
>   and R. David Murray. Sadly, David lost the VM image to a disk crash :-(
> New
>   ICC buildbots may come back later, wait & see ;-)
>
> * macOS Snow Leopard (murray-snowleopard): this old machine was stuck
> at boot for an unknown reason. "It's an old machine, and it is
> probably time to get rid of it." wrote R. David Murray :-)
>
>
> == Reduced failure rate ==
>
> As usual, many race conditions were fixed in tests and in the code, to
> reduce the buildbot failure rate.
>
> I may list them in a blog post, later.
>
>
> == What's Next? ==
>
> * Buildbot should be upgrade to buildbot 0.9:
>https://github.com/python/buildmaster-config/pull/12
>
> * Zachary Ware plans to rewrite our buildbot configuration during the
> CPython sprint (Sept 4-9)
>
> * test_logging fails randomly on FreeBSD 10 with a warning related to
> threads (bpo-30830). I was trying to reproduce the bug since 2 months.
> I just identified to root bug! https://bugs.python.org/issue31233
> "socketserver.ThreadingMixIn leaks running threads after
> server_close()".
>
> * The "Docs" buildbot (currently offline) may be dropped as well,
> https://github.com/python/buildmaster-config/pull/21
>
>
> See also my previous buildbot report:
> https://haypo.github.io/python-buildbots-2017q2.html
>
> Victor
> ___
> 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] PEP 550 v3

2017-08-19 Thread Ethan Furman 

On 08/19/2017 01:40 AM, Antoine Pitrou wrote:

On Fri, 18 Aug 2017 16:33:27 -0400 Yury Selivanov wrote:



There are a few open questions left, namely the terminology
and design of ContextKey API.  On the former topic, I'm quite
happy with the latest version: Execution Context, Logical
Context, and Context Key.


I don't really like it.  "Logical Context" is vague (there are
lots of things called "context" in other libraries, so a bit of
specificity would help avoid confusion), and it's not clear what is
"logical" about it anyway.  "Local Context" actually seemed better to
me (as it reminded of threading.local() or the general notion of
thread-local storage).


I am also not seeing the link between "logical" and "this local layer of environmental changes that won't be seen by 
those who called me".


Maybe ContextLayer?  Or marry the two and call it LocalContextLayer.

--
~Ethan~

___
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] PEP 550 v3

2017-08-19 Thread Guido van Rossum 
The way we came to "logical context" was via "logical thread (of control)",
which is distinct from OS thread. But I think we might need to search for
another term...

On Aug 19, 2017 11:56 AM, "Ethan Furman"  wrote:

> On 08/19/2017 01:40 AM, Antoine Pitrou wrote:
>
>> On Fri, 18 Aug 2017 16:33:27 -0400 Yury Selivanov wrote:
>>
>
> There are a few open questions left, namely the terminology
>>> and design of ContextKey API.  On the former topic, I'm quite
>>> happy with the latest version: Execution Context, Logical
>>> Context, and Context Key.
>>>
>>
>> I don't really like it.  "Logical Context" is vague (there are
>> lots of things called "context" in other libraries, so a bit of
>> specificity would help avoid confusion), and it's not clear what is
>> "logical" about it anyway.  "Local Context" actually seemed better to
>> me (as it reminded of threading.local() or the general notion of
>> thread-local storage).
>>
>
> I am also not seeing the link between "logical" and "this local layer of
> environmental changes that won't be seen by those who called me".
>
> Maybe ContextLayer?  Or marry the two and call it LocalContextLayer.
>
> --
> ~Ethan~
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 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] PEP 550 v3

2017-08-19 Thread Nick Coghlan 
On 20 August 2017 at 10:21, Guido van Rossum  wrote:
> The way we came to "logical context" was via "logical thread (of control)",
> which is distinct from OS thread. But I think we might need to search for
> another term...

Right. Framing it in pragmatic terms, the two entities that we're
attempting to name are:

1. The mutable storage that ContextKey.set() writes to
2. The dynamic context that ContextKey.get() queries

Right now, we're using ExecutionContext for the latter, and
LogicalContext for the former, and I can definitely see Antoine's
point that those names don't inherently convey any information about
which is which.

Personally, I still like the idea of moving ExecutionContext into the
"mutable storage" role, and then finding some other name for the stack
of execution contexts that ck.get() queries.

For example, if we named the latter after what it's *for*, we could
call it the DynamicQueryContext, and end up with the following
invocation functions:

# Replacing ExecutionContext in the current PEP
DynamicQueryContext
sys.get_dynamic_query_context()
sys.new_dynamic_query_context()
sys.run_with_dynamic_query_context()
# Suggests immutability -> good!
# Suggests connection to ck.get() -> good!

# Replacing LogicalContext in the current PEP
ExecutionContext
sys.new_execution_context()
sys.run_with_execution_context()
__execution_context__ attribute on generators (et al)
# Neutral on mutability/immutability
# Neutral on ck.set()/ck.get()

An alternative would be to dispense with the ExecutionContext name
entirely, and instead use DynamicWriteContext and DynamicQueryContext.
If we did that, I'd suggest omitting "dynamic" from the function and
attribute names (while keeping it on the types), and end up with:

# Replacing ExecutionContext in the current PEP
DynamicQueryContext
sys.get_query_context()
sys.new_query_context()
sys.run_with_query_context()
# Suggests immutability -> good!
# Suggests connection to ck.get() -> good!

# Replacing LogicalContext in the current PEP
DynamicWriteContext
sys.new_write_context()
sys.run_with_write_context()
__write_context__ attribute on generators (et al)
# Suggests mutability -> good!
# Suggests connection to ck.set() -> good!

In this variant, the phrase "execution context" could become a general
term that covered *all* of the active state that a running piece of
code has access to (the dynamic context,  thread locals, closure
variables, module globals, process globals, etc), rather than
referring to any particular runtime entity.

Cheers,
Nick.

P.S. Since we have LookupError (rather than QueryError) as the shared
base exception type for KeyError and IndexError, it would also be
entirely reasonable to replace "Query" in the above suggestions with
"Lookup" (DynamicLookupContext, sys.get_lookup_context(), etc). That
would also have the benefit of being less jargony, and more like
conversational English.

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