Re: [Python-Dev] limited_api and datetime

[Christian Tismer]

Hi Nick,

On 23.08.17 07:41, Nick Coghlan wrote:
> On 23 August 2017 at 00:09, stackless  wrote:
>> Hi again,
>>
>> I am trying to support the limited Api (PEP 384) for PySide. Fortunately,
>> everything worked out of the box, just the datetime module gives me
>> a problem. Inspection showed that datetime is completely removed
>> when the limitation is set.
>>
>> Can somebody enlighten me why that needs to be so?
> 
> The main problem is that "datetime.h" defines several C structs that
> we wouldn't want to add to the stable ABI, and nobody has previously
> worked through details of the interface to see which parts of it could
> still be used even if those structs were made opaque, and the macros
> relying on them were switched to being functions instead.
> 
> There are almost certainly pieces of it that *could* be usefully
> exposed, though.
> 
>> And how should I use datetime, instead: Fish the functions out of
>> the dynamically imported datetime module?
> 
> Yep, going via the Python level API rather than directly to the C API
> is the default answer, as that inherently hides any struct layout
> details behind PyObject*.

Thank you very much for the clarification.
I think we can live with the Python interface for now.
Now I'm sure that I'm going the way to go.

Cheers -- Chris

-- 
Christian Tismer :^)   tis...@stackless.com
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
Python-Dev@python.org
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 naming

[Nick Coghlan]

On 23 August 2017 at 13:51, Guido van Rossum  wrote:
> Regarding DynamicAnything, I certainly saw it and didn't like it -- the only
> place where I've ever seen dynamic scoping was in Emacs Lisp, and I believe
> was first shown to me as anti-pattern thirty years ago.

As the original proponent of a Dynamic* naming scheme, I'll note that
I eventually decided I didn't like it for the same reason I already
didn't like naming schemes using either the word "local" or the word
"frame": they all suggest a coupling to the synchronous call stack
that deliberately isn't part of the proposal.

That is (at least for me):

- "local" suggests the implicit context will change when locals() changes
- "frame" suggests the implicit context will change when the running
frame changes
- "dynamic" suggest dynamic scoping, which again suggests the implicit
context will change on every function call

None of those associations are true, since the essential point of the
proposal is to *share* implicit state between frames of execution. The
tricky part is defining exactly which frames should and shouldn't
share their implicit context - threading.locals() is our current best
attempt, and the PEP is mainly driven by the problems introduced by
relying solely on that in programs that implement concurrent execution
of Python code independently of the underlying operating system
threads.

My concern with "logical" context is different, which is that as a
term it feels too *broad* to me: I'd expect the lexical context
(nonlocals, module globals), the explicit context (function
parameters), and the runtime context (process globals,
threading.locals()) to also be considered part of the overall logical
context. It's also a very computer-sciencey term of art - if you ask
an arbitrary English speaker "What does 'logical' mean?", they're very
*un*likely to give you an answer that has anything to do with logical
threads of control in computer programs.

My latest suggestion (ImplicitContext) has some of the same issues as
"logical context" (since the runtime context is also implicit), but
seems more defensible on the grounds of it aiming to be a more robust
way of accessing and manipulating implicit state in concurrent
programs, rather than it being the only kind of implicit state that
exists in an application. As an English word, the sense of "capable of
being understood from something else though unexpressed" (the first
definition that Merriam-Webster give) also has the benefit of
describing *exactly* what the PEP is aiming to achieve.

Cheers,
Nick.

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

Re: [Python-Dev] limited_api and datetime

[Nick Coghlan]

On 23 August 2017 at 00:09, stackless  wrote:
> Hi again,
>
> I am trying to support the limited Api (PEP 384) for PySide. Fortunately,
> everything worked out of the box, just the datetime module gives me
> a problem. Inspection showed that datetime is completely removed
> when the limitation is set.
>
> Can somebody enlighten me why that needs to be so?

The main problem is that "datetime.h" defines several C structs that
we wouldn't want to add to the stable ABI, and nobody has previously
worked through details of the interface to see which parts of it could
still be used even if those structs were made opaque, and the macros
relying on them were switched to being functions instead.

There are almost certainly pieces of it that *could* be usefully
exposed, though.

> And how should I use datetime, instead: Fish the functions out of
> the dynamically imported datetime module?

Yep, going via the Python level API rather than directly to the C API
is the default answer, as that inherently hides any struct layout
details behind PyObject*.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[Nathaniel Smith]

On Tue, Aug 22, 2017 at 8:51 PM, Guido van Rossum  wrote:
> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith  wrote:
>>
>> We could do worse than just plain Context and ContextStack, for that
>> matter.
>
>
> I worry that that's going to lead more people astray thinking this has
> something to do with contextlib, which it really doesn't (it's much more
> closely related to threading.local()).

I guess that could be an argument for LocalContext and
LocalContextStack, to go back full circle...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[Guido van Rossum]

On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith  wrote:

> We could do worse than just plain Context and ContextStack, for that
> matter.
>

I worry that that's going to lead more people astray thinking this has
something to do with contextlib, which it really doesn't (it's much more
closely related to threading.local()).

Regarding DynamicAnything, I certainly saw it and didn't like it -- the
only place where I've ever seen dynamic scoping was in Emacs Lisp, and I
believe was first shown to me as anti-pattern thirty years ago.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[Nathaniel Smith]

On Tue, Aug 22, 2017 at 8:22 AM, Guido van Rossum  wrote:
> As I understand the key APIs and constraints of the proposal better, I'm
> leaning towards FooContext (LC) and FooContextStack (EC), for some value of
> Foo that I haven't determined yet. Perhaps the latter can be shortened to
> just ContextStack (since the Foo part can probably be guessed from context.
> :-)

I guess I'll put in another vote for DynamicContext and
DynamicContextStack. Though my earlier suggestion of these [1] sank
like a stone, either because no-one saw it or because everyone hated
it :-).

We could do worse than just plain Context and ContextStack, for that matter.

-n

[1] https://mail.python.org/pipermail/python-ideas/2017-August/046840.html

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[MRAB]

On 2017-08-23 00:12, Greg Ewing wrote:

Guido van Rossum wrote:
Perhaps the latter can be 
shortened to just ContextStack (since the Foo part can probably be 
guessed from context. :-)


-0.9, if I saw something called ContextStack turn up in a traceback
I wouldn't necessarily jump to the conclusion that it was a stack
of FooContexts rather than some other kind of context. EIBTI here,
I think.

The PEP says """This PEP proposes a new mechanism to manage execution 
state""", so ExecutionState or ExecState?

___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[Greg Ewing]

Guido van Rossum wrote:
Perhaps the latter can be 
shortened to just ContextStack (since the Foo part can probably be 
guessed from context. :-)


-0.9, if I saw something called ContextStack turn up in a traceback
I wouldn't necessarily jump to the conclusion that it was a stack
of FooContexts rather than some other kind of context. EIBTI here,
I think.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
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

[Guido van Rossum]

On Mon, Aug 21, 2017 at 10:09 PM, Nick Coghlan  wrote:

> My latest suggestion to Yury was to see how the PEP reads with it
> called ImplicitContext, such that:
>
> * the active execution context is a stack of implicit contexts
> * ContextKey.set() updates the innermost implicit context
> * Contextkey.get() reads the whole stack of active implicit contexts
> * by default, generators (both sync and async) would have their own
> implicit context, but you could make them use the context of method
> callers by doing "gen.__implicit_context__ = None"
> * by default, coroutines would use their method caller's context, but
> async frameworks would make sure to give top-level tasks their own
> independent contexts
>
> That proposal came from an initial attempt at redrafting the Abstract
> and Rationale sections, where it turns out that one of the things the
> current version of the PEP is somewhat taking for granted is that the
> reader already has a particular understanding of the difference
> between explicit state management (i.e. passing things around as
> function arguments and instance attributes) and implicit state
> management (i.e. relying on process globals and thread locals).
>

I think I like ImplicitContext. Maybe we can go with this as a working
title at least.

I think we should also rethink the form the key framework-facing APIs will
take, and how they are presented in the PEP -- I am now leaning towards
explaining this from the start as an immutable linked list of immutable
mappings, where the OS-thread state gets updated to a new linked list when
it is changed (either by ContextKey.set or by the various stack
manipulations). I think this falls under several Zen-of-Python points:
EIBTI, and "If the implementation is easy to explain, it may be a good
idea."

-- 
--Guido van Rossum (python.org/~guido )
___
Python-Dev mailing list
Python-Dev@python.org
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 naming

[Guido van Rossum]

As I understand the key APIs and constraints of the proposal better, I'm
leaning towards FooContext (LC) and FooContextStack (EC), for some value of
Foo that I haven't determined yet. Perhaps the latter can be shortened to
just ContextStack (since the Foo part can probably be guessed from context.
:-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] limited_api and datetime

[stackless]

Hi again,

I am trying to support the limited Api (PEP 384) for PySide. Fortunately, 
everything worked out of the box, just the datetime module gives me
a problem. Inspection showed that datetime is completely removed
when the limitation is set. 

Can somebody enlighten me why that needs to be so?

And how should I use datetime, instead: Fish the functions out of
the dynamically imported datetime module?

Thanks in advance - Chris

Sent from my Ei4Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com