Re: [Python-Dev] Add more SyntaxWarnings?
Chris Barker - NOAA Federal writes: > > > But as a rule, > > > there are a LOT of errors that can be pretty mysterious to newbies. > > > > Isn't that the very definition of "newbie"? That's half a joke, but I > > really don't think that programmers new to Python should be the > > standard. > > Python is broadly advocated (and used) as a first language to learn. > Because it is. > > So I think anything we can do to help newbies, *that doesn’t make the > language less powerful, or even more annoying for experienced > developers* is a good thing. > > That is: prioritizing newbie-friendliness is good. Prioritizing it > over other important things is not. I don't disagree. I disagree with the conclusion that it's worth the effort to try to improve all error messages that confuse new users, because new users (by definition) don't know enough to respond usefully in many cases. In those cases, they need to be told what's going on and why, where more experienced users can figure it out from their background knowledge of Python semantics. Embedding a "theory of operations" note in every error message would be possible, but I don't think it's a good idea -- it would certainly make the language more annoying for experienced developers. That's why I proposed the criterion > > The problematic cases are those where even a relatively > > experienced Python programmer needs to be told why an error is > > raised, because it's too hard to figure out from background > > knowledge of the language, you need to know about implementation > > internals. Maybe that's too strict. The pleasant hacks of giving ``quit`` and ``help`` "values" as variables are certainly useful. On the contrary, getting rid of the print statement was perhaps a better idea. :-) Steve ___ 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] Add more SyntaxWarnings?
> But as a rule, >> there are a LOT of errors that can be pretty mysterious to newbies. > > Isn't that the very definition of "newbie"? That's half a joke, but I > really don't think that programmers new to Python should be the > standard. Python is broadly advocated (and used) as a first language to learn. Because it is. So I think anything we can do to help newbies, *that doesn’t make the language less powerful, or even more annoying for experienced developers* is a good thing. That is: prioritizing newbie-friendliness is good. Prioritizing it over other important things is not. -CHB > The problematic cases are those where even a relatively > experienced Python programmer needs to be told why an error is raised, > because it's too hard to figure out from background knowledge of the > language, you need to know about implementation internals. > >> I would love to see Python become generally more informative with >> errors. > > I would love to see all automated systems become more informative with > errors! One thing I like about Python the development community is > that people are doing something about it. Slowly but surely > >> I don’t think so — what we need are helpful error messages. If it >> will be raised at compile time, then it won’t generally be >> catchable in s try-except— so the actual exception type isn’t very >> important. > > +1 > > In general depending much on exception type is a hit-or-miss affair. ___ 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] Sub-interpreters: importing numpy causes hang
On Mon, 28 Jan 2019 at 19:36, Stephan Reiter wrote:
>
> Reading through that post, I think I have everything covered but this here:
> - The third and final scenario, and the one where the extended GIL
> state functions for Ensure is still required, is where code doesn't
> have the GIL as yet and wants to make a call into sub interpreter
> rather than the main interpreter, where it already has a pointer to
> the sub interpreter and nothing more. In this case the new
> PyGILState_EnsureEx() function is used, with the sub interpreter being
> passed as argument.
>
> If I understand it correctly, it means the following in practice:
> Whenever I or a third-party library start a new thread, we need to
> query what interpreter we are running at the moment (in the thread
> that is starting the new thread) and pass that information on to the
> new thread so that it can initialize the GIL for itself.
>
> Pseudo code ahead:
> void do_in_thread(func_t *what) {
> PyThreadState* state = PyThreadState_Get(); /// or new
> PyInterpreterState_Current();
> PyInterpreterState *interpreter = state->interp;
> std::thread t([what, interpreter] {
> auto s = PyGILState_EnsureEx(interpreter);
> what();
> PyGILState_Release(s); // could also release before what() because
> TLS was updated and next PyGILState_Ensure() will work
> });
> }
>
> Did I get that right?
Yeah, I think that's the essence of it, although the other case that
can come up is when the parent thread just created a new
subinterpreter (that only changes how it acquires the pointer though -
the challenge of getting a child thread to make proper use of that
pointer remains the same).
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] Anyone else seeing a lack of caching in local docs builds?
On Mon, 28 Jan 2019 18:02:16 +1000 Nick Coghlan wrote: > On Mon, 28 Jan 2019 at 05:44, Terry Reedy wrote: > > On 1/27/2019 9:01 AM, Nick Coghlan wrote: > > > For now, I'm assuming I've messed something up with my local docs > > > build setup, but figured I'd ask if anyone else was seeing this, in > > > case it was actually broken at the build level (CI wouldn't pick this > > > up, since it always builds from scratch anyway). > > > > I think something is broken. Caching used to work better. > > In my case, I had an older version of blurb installed, which was > keeping NEWS from rendering properly, and I suspect that was > preventing Sphinx from marking the cache as valid. > > I'm not sure about that theory though, as I would have expected an > invalid NEWS file to only keep the NEWS file from being cached. I've often noticed oddities in Sphinx caching on other projects. I'm not sure the algorithm is extremely precise. Regards Antoine. ___ 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] Sub-interpreters: importing numpy causes hang
Reading through that post, I think I have everything covered but this here:
- The third and final scenario, and the one where the extended GIL
state functions for Ensure is still required, is where code doesn't
have the GIL as yet and wants to make a call into sub interpreter
rather than the main interpreter, where it already has a pointer to
the sub interpreter and nothing more. In this case the new
PyGILState_EnsureEx() function is used, with the sub interpreter being
passed as argument.
If I understand it correctly, it means the following in practice:
Whenever I or a third-party library start a new thread, we need to
query what interpreter we are running at the moment (in the thread
that is starting the new thread) and pass that information on to the
new thread so that it can initialize the GIL for itself.
Pseudo code ahead:
void do_in_thread(func_t *what) {
PyThreadState* state = PyThreadState_Get(); /// or new
PyInterpreterState_Current();
PyInterpreterState *interpreter = state->interp;
std::thread t([what, interpreter] {
auto s = PyGILState_EnsureEx(interpreter);
what();
PyGILState_Release(s); // could also release before what() because
TLS was updated and next PyGILState_Ensure() will work
});
}
Did I get that right?
Stephan
Am Mo., 28. Jan. 2019 um 09:27 Uhr schrieb Nick Coghlan :
>
> On Mon, 28 Jan 2019 at 00:32, Stephan Reiter wrote:
> >
> > Cool. Thanks, Nick!
> >
> > I did experiments based on this idea
> > (https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622)
> > and haven't rejected it yet. :-)
>
> After talking to Graham about this, I unfortunately realised that the
> reason the callback approach is appearing to work for you is because
> your application is single-threaded, so you can readily map any
> invocation of the callback to the desired interpreter. Multi-threaded
> applications won't have that luxury - they need to be able to set the
> callback target on a per-thread basis.
>
> Graham actually described a plausible approach for doing that several
> years back: https://bugs.python.org/issue10915#msg126387
>
> We have much better subinterpreter testing support now, so if this is
> any area that you're interested in, one potential place to start would
> be to get Antoine's patch back to a point where it applies and
> compiles again.
>
> 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] Sub-interpreters: importing numpy causes hang
On Mon, 28 Jan 2019 at 00:32, Stephan Reiter wrote: > > Cool. Thanks, Nick! > > I did experiments based on this idea > (https://github.com/stephanreiter/cpython/commit/3bca91c26ac81e517b4aa22302be1741b3315622) > and haven't rejected it yet. :-) After talking to Graham about this, I unfortunately realised that the reason the callback approach is appearing to work for you is because your application is single-threaded, so you can readily map any invocation of the callback to the desired interpreter. Multi-threaded applications won't have that luxury - they need to be able to set the callback target on a per-thread basis. Graham actually described a plausible approach for doing that several years back: https://bugs.python.org/issue10915#msg126387 We have much better subinterpreter testing support now, so if this is any area that you're interested in, one potential place to start would be to get Antoine's patch back to a point where it applies and compiles again. 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] Anyone else seeing a lack of caching in local docs builds?
On Mon, 28 Jan 2019 at 05:44, Terry Reedy wrote: > On 1/27/2019 9:01 AM, Nick Coghlan wrote: > > For now, I'm assuming I've messed something up with my local docs > > build setup, but figured I'd ask if anyone else was seeing this, in > > case it was actually broken at the build level (CI wouldn't pick this > > up, since it always builds from scratch anyway). > > I think something is broken. Caching used to work better. In my case, I had an older version of blurb installed, which was keeping NEWS from rendering properly, and I suspect that was preventing Sphinx from marking the cache as valid. I'm not sure about that theory though, as I would have expected an invalid NEWS file to only keep the NEWS file from being cached. 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
