[issue32797] Tracebacks from Cython modules no longer work

[Stefan Behnel]

Stefan Behnel  added the comment:

FWIW, I can see that Cython is a special case because it can control the source 
line mapping and reporting through the C-API. Other code generators might not 
be able to do that, e.g. for a DSL or template language that gets translated to 
Python code, for which an explicit source mapping would be required.

But, I definitely see the analogy between .py files and .pyx files. In fact, 
.pyx files often originate from renaming .py files. And keep in mind that 
Cython can also compile .py files, which leads to .so files in the same package 
directory.

Installing the .pyx files alongside with the .so files is currently easy for 
our users because distutils does it automatically. Changing the place where 
they get installed would require tooling support and most likely also changes 
on user side in all Cython projects out there (unless it's configured through 
the distutils Extension object, which Cython can control).

The recommended way to structure Cython packages is to have the .pyx files 
where the resulting extension modules go, in their package, so that both end up 
next to each other with "setup.py build_ext --inplace", but also to make 
relative imports and inclusions work through the normal path lookup mechanism 
in Cython. Keeping two identical package structures in different places, one 
for .py files and generated .so files, and one for Cython source files (.pyx, 
.pxd, .pxi), is not desirable from a user perspective, and would require 
namespace packages for the lookup, where otherwise a simple single Python 
package structure would suffice. That would complicate Cython's internal 
compile time import lookup system quite a bit.

If we keep that single package structure (and from a user's perspective, I'm 
all for it), but change the way source files are looked up, we would have to 
additionally come up with a way to support the debugging case in a source 
checkout, where .pyx files and .so file are necessarily in the same package 
directory, together with the .py files.

This whole idea looks backwards and complicated. As Brett noted, .pyc files 
were moved out of the source tree, because they are build time artifacts and 
not sources. With that analogy, it's the .so files that would have to move, not 
the .pyx or .py source files, which are sources for the compiled .so files.

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34330] The decode_header function does not always work correctly.

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Nick Coghlan]

Nick Coghlan  added the comment:

Regarding PEP 302 compliance: until Python 3.3, the builtin import system 
wasn't present on sys.metapath - it was its own implicit legacy thing. The 
change in Python 3.3 was to fix that, and make it work based on a handful of 
default sys.metapath entries. Not coincidentally, 3.3 was also the first 
release where the import system was finally added to the language reference 
rather than being wholly implementation dependent: 
https://docs.python.org/3/reference/import.html

I think that also points the way forward for providing a useful import spec 
compliant fallback for sourceless files in linecache in a way that could be 
backported to earlier Python 3 versions: it's possible to create a FileFinder 
[1] instance that only looks for source files, and ignores files that don't 
provide source code.

Given that, the changes needed to make SageMath tracebacks "just work" the way 
they currently do in Python 2 would be:

1. Enhance PathFinder [2] to allow specification of which path importer cache 
and path_hooks entries to use
2. Set up a source-only metapath in linecache with a single default entry: a 
PathFinder configured with a source-only FileFinder instance as a path hook
3. Fall back to the source-only metapath if the main import system indicates 
the module is being loaded from a sourceless format.

[1] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
[2] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder

--
versions:  -Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

[Nick Coghlan]

Nick Coghlan  added the comment:

Agreed, but it's still a definition time bug, as the types are only nulling out 
tp_new after creating the singleton instance, and not preventing __new__ from 
resolving.

If they *don't* null out tp_new, but instead set tp_new to a common helper 
function that raises "TypeError: Cannot create  instances", that 
will both prevent __new__ from working, and also ensure that `type(obj)()` and 
`type(obj).__new__()` give the same error.

(Changing the applicable version, as this issues combines a relatively obscure 
error reporting issue with a relatively intrusive fix, so the risk/reward ratio 
pushes it towards being a Python 3.8 only change).

--
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6952] deprecated conversion from string constant to char *

[Berker Peksag]

Berker Peksag  added the comment:

All changes (except PyUnicode_EncodeDecimal() which was deprecated in Python 
3.3) have already been implemented in the following commits:

* 
https://github.com/python/cpython/commit/c679227e31245b0e8dec74a1f7cc77710541d985
* 
https://github.com/python/cpython/commit/f308132cc29eea9b7fe899deb575d29d607a48f4
* 
https://github.com/python/cpython/commit/f0b463ad845c7433a0c561ef2c71d350f4b508c5

Closing this as 'out of date'.

--
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24937] Multiple problems in getters & setters in capsulethunk.h

[Berker Peksag]

Berker Peksag  added the comment:

It would be nice to remove PyCObject_* entries from Doc/data/refcounts.dat.

+.. _documentation: http://py3c.readthedocs.org/en/latest/capsulethunk.html

Nit: We could the HTTPS link.

--
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.2, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Brett Cannon]

Brett Cannon  added the comment:

On Sat, Aug 4, 2018, 16:07 Jeroen Demeyer,  wrote:

>
> Jeroen Demeyer  added the comment:
>
> To everybody who mentioned that Cython sources don't belong on sys.path:
> where *do* they belong then?
>

In a subdirectory similar to __pycache__.

> One issue which hasn't been mentioned before is packaging. By installing
> Cython sources along with the generated .so files, we can re-use all the
> existing tooling from distutils/setuptools/wheel to install those source
> files.

Technically this doesn't fall under our purview but that of distutils-sig.
Plus how distutils or setuptools do anything is an implementation detail
and it's more important how a wheel would handle this (if any special
support is even necessary). Remember, PEP 517 us our future and is there to
break the monopoly of setuptools.

If we want to install them in a different way, ideally it should be done in
> a way sanctioned by the PyPA and the tools should support it. We should
> then also change linecache to search for source files in that directory.
>

Yep.

> Unless somebody can come up with a simple suggestion, this seems to
> require basically a PEP.

Or at least a new API.

I don't plan to write that PEP and fight for it, since this can easily be
> fixed with essentially a 1-line patch to linecache, as I proposed in
> https://github.com/python/cpython/pull/6653
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22852] urllib.parse wrongly strips empty #fragment, ?query, //netloc

[Martin Panter]

Martin Panter  added the comment:

I like this option. I suppose choosing which option to take is a compromise 
between compatiblity and simplicity. In the short term, the “allows_none” 
option requires user code to be updated. In the long term it may break 
compatibility. But the “has_netloc” etc option is more complex.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

To everybody who mentioned that Cython sources don't belong on sys.path: where 
*do* they belong then?

One issue which hasn't been mentioned before is packaging. By installing Cython 
sources along with the generated .so files, we can re-use all the existing 
tooling from distutils/setuptools/wheel to install those source files. If we 
want to install them in a different way, ideally it should be done in a way 
sanctioned by the PyPA and the tools should support it. We should then also 
change linecache to search for source files in that directory.

Unless somebody can come up with a simple suggestion, this seems to require 
basically a PEP. I don't plan to write that PEP and fight for it, since this 
can easily be fixed with essentially a 1-line patch to linecache, as I proposed 
in https://github.com/python/cpython/pull/6653

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)

[Mikhail Terekhov]

Change by Mikhail Terekhov :


--
keywords: +patch
pull_requests: +8167
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32258] Rewrite asyncio docs to use async/await syntax

[Mikhail Terekhov]

Change by Mikhail Terekhov :


--
pull_requests: +8168

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)

[Mikhail Terekhov]

New submission from Mikhail Terekhov :

Couple of examples in in asyncio documentation mix @asyncio.coroutine decorator 
and await.

--
components: asyncio
messages: 323121
nosy: asvetlov, termim, yselivanov
priority: normal
severity: normal
status: open
title: Fix examples in asyncio docs (suppliment to bpo-32258)
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34311] locale.format() and locale.format_string() cast Decimals to float

[James Emerton]

James Emerton  added the comment:

It looks like a bot got a bit excited when I mentioned this issue in the PR for 
bpo-33731. I unlinked the PR but this issue still got flagged for review.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34311] locale.format() and locale.format_string() cast Decimals to float

[James Emerton]

Change by James Emerton :


--
pull_requests:  -8166

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34311] locale.format() and locale.format_string() cast Decimals to float

[James Emerton]

Change by James Emerton :


--
keywords: +patch
pull_requests: +8166
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33731] string formatting that produces floats with preset precision while respecting locale

[Stefan Krah]

Change by Stefan Krah :


--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26171] heap overflow in zipimporter module

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Brett Cannon]

Brett Cannon  added the comment:

On Sat, Aug 4, 2018, 11:52 Jeroen Demeyer,  wrote:

>
> Jeroen Demeyer  added the comment:
>
> > In my view (and that of the documentation for sys.path), sys.path is
> where you put things that the Python interpreter can load - .so files, .pyc
> files and .py files.
>
> It's quite typical for packages to install stuff in site-packages which
> the interpreter cannot load. In fact, that's the exactly the point of the
> package_data argument to setup(), see
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data
>
> Just as an example, Numpy installs tons of stuff inside
> site-packages/numpy/ (header files, configuration files, data files for the
> testsuite)
>

I think the key point no one is saying is that .pyc files are no longer on
sys.path because they are in __pycache__ and those aren't importable unless
you access them as namespace packages. So we have been moving to keeping
artifacts like .pyc files off of sys.path.

As Nick said, we have no generalized concept of source maps and I think
coming up with that is what will be required to solve this as i personally
don't view Loader.get_source() is not meant to be a generalized concept of
some form of source code but Python source code.

> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33187] Document ElementInclude (XInclude) support in ElementTree

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Hello Anjali,

As far as I remember, you started this in a PyDelhi Dev Sprint. So, just wanted 
to check around, if you're looking for any help :)

--
nosy: +CuriousLearner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34273] %f is confusingly associated with fixed point format

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +8165
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> In my view (and that of the documentation for sys.path), sys.path is where 
> you put things that the Python interpreter can load - .so files, .pyc files 
> and .py files.

It's quite typical for packages to install stuff in site-packages which the 
interpreter cannot load. In fact, that's the exactly the point of the 
package_data argument to setup(), see 
https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data

Just as an example, Numpy installs tons of stuff inside site-packages/numpy/ 
(header files, configuration files, data files for the testsuite)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Paul Moore]

Paul Moore  added the comment:

> What's wrong with that? Installing the .pyx sources together with the .so 
> compiled modules makes a lot of sense to me: it is very analogous to 
> installing the .py sources together with the .pyc byte-compiled files. In 
> https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that 
> analogy, but I don't quite understand why.

Because if someone deletes the .pyc file, the interpreter can (and will) 
regenerate it using the .py file. If someone deletes the .so file, you're 
stuck. Having the .pyx file present won't help you.

In my view (and that of the documentation for sys.path), sys.path is where you 
put things that the Python interpreter can load - .so files, .pyc files and .py 
files.

Looking for source to report as part of a traceback is a separate process, and 
there's no immediate reason why it should involve sys.path. The fact that 
historically it did (because that worked for pure Python modules that shipped 
with source) doesn't mean it's the right solution. I'd rather see a 
well-designed protocol for "find me the source for this module" that tools like 
Cython can support, than trying to patch up the loader protocol and sys.path to 
do something they weren't ever designed for.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23876] Fix mkdir() call for Watcom compilers on UNIX-like platforms

[Jeffrey Armstrong]

Change by Jeffrey Armstrong :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Then instead of adding the source directory to sys.path

What's wrong with that? Installing the .pyx sources together with the .so 
compiled modules makes a lot of sense to me: it is very analogous to installing 
the .py sources together with the .pyc byte-compiled files. In 
https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that 
analogy, but I don't quite understand why.

And if ${prefix}/lib/pythonX.Y/site-packages/PKGNAME is not a good place to 
store the installed sources, where would you want to install them otherwise?

> (which was only working because the legacy import system never implemented 
> PEP 302 properly)

Not sure what you mean here...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33649] asyncio docs overhaul

[Yury Selivanov]

Yury Selivanov  added the comment:

Status update: I'm working on a first rewrite. I expect to have something to 
review on a couple of weeks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33649] asyncio docs overhaul

[Martin Altmayer]

Change by Martin Altmayer :


--
nosy: +MartinAltmayer

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

[ppperry]

ppperry  added the comment:

The problem doesn't just happen with `sys.flags`, though. It happens with all 
types that can't be created directly by python. Ex: frame objects, generators, 
cells, etc. The bug is that in types whose c-level tp_new is null, the 
python-level __new__ is inherited from the superclass (and since object defines 
a `__new__`, such a function always exists), instead of being defined to always 
raise an error, like calling the type directly does.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34309] Trouble when reloading extension modules.

[Nick Coghlan]

Nick Coghlan  added the comment:

As others have noted, dynamically reloading CPython extension modules is akin 
to dynamically reloading any other C/C++ shared library, so it has enough 
opportunities for things to go wrong that we consider allowing the shared state 
to persist across initialize/finalize cycles the less problematic of two 
problematic options (at least for now).

Reliable hot reloading support is typically a property of pure Python modules 
(and even at that higher level, inter-module dependencies can still cause 
problems at runtime).

(FWIW, this problem is currently also the main reason we don't offer an in-REPL 
package installation command - while PEP 489 offers significant opportunities 
for improvement, it's likely to be years before we see widespread adoption of 
that, so we prefer to advise folks to run an installer outside the REPL, then 
restart and replay their interactive session)

If subinterpreters are an option though, then yeah, that has far more potential 
to be viable. It wouldn't be trivial, as we'd need to add dlmopen support 
(thanks Stack Overflow [1]) to give the subinterpreter a truly independent copy 
of the shared library (and also work out whatever the equivalent to dlmopen 
might be on other platforms), but going down that path could also potentially 
provide a way around the known problems with global state leaking between 
subinterpreters via extension modules.

[1] 
https://stackoverflow.com/questions/48864659/loading-shared-library-twice/4598#4598

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1230540] sys.excepthook doesn't work in threads

[Andrey Vlasovskikh]

Andrey Vlasovskikh  added the comment:

> Would it be possible to modify the default implementation of sys.excepthook 
> to have a different output when it's not called from the main thread? Mimick 
> the current traceback from threads.

I agree it's a good idea to mimic what `_thread` does in case of both handled 
and unhandled exceptions. Why would you want to do it in `sys.excepthook`? The 
code for handling unhandled exceptions in `_thread` threads is located in 
`_threadmodule.c` itself, so there is no dependency from `sys` to `_thread`. By 
following the same logic, the code for handling unhandled exceptions in 
`threading` should be located in `threading.py`, like it does now. So the only 
thing that's missing in the pull request compared to `_thread` is the output:

   Unhandled exception in thread started by  at 
0x7f6769ca8e18>


for all the exceptions: not caught by the sys.excepthook **and** caught by the 
sys.exceptook.

> An alternative would be to introduce a new hook to log exceptions in threads, 
> ex: sys.threadexcepthook. That hoook would take a 4th parameter. But Andrey 
> Vlasovskikh didn't like this idea.

I'm overall OK with this idea, but I would prefer to make the existing 
`sys.excepthook` API applicable to all the exceptions: for the main thread 
(works well), for `_thread` threads (works well) and for `threading` threads 
(doesn't work).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

[Nick Coghlan]

Nick Coghlan  added the comment:

Looking at the code in 
https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/sysmodule.c#L2360,
 I think the underlying problem here is that the code to make these 
PyStructSequence subclasses uninstantiable isn't really right - rather than 
clearing those fields in the subclass (which still allows dynamic method lookup 
to fall back to the parent class, even though fast C level dispatch fails), it 
would be more consistent and reliable to replace them with implementations that 
always raise a TypeError with a suitable message.

(An alternative may be to implement the same behaviour as the builtin singleton 
types used for None and Ellipsis: replace __new__ with an implementation that 
always returns the original singleton instance. However, there isn't a 
compelling use case, so raising a descriptive exception along the lines of what 
ppperry suggests seems most appropriate)

--
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33736] Improve the documentation of asyncio stream API

[Berker Peksag]

Change by Berker Peksag :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13574] refresh example in doc for Extending and Embedding

[Berker Peksag]

Berker Peksag  added the comment:

The documentation has been modernized in 
https://github.com/python/cpython/commit/1d80a561734b9932961c546b0897405a3bfbf3e6
 and the "Weak Reference Support" section has been updated to show the modern 
way of adding weakref support:


https://github.com/python/cpython/commit/1d80a561734b9932961c546b0897405a3bfbf3e6#diff-1ace1cc14bb5b7f4ee77f22238ede084R556

--
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34194] test_ssl, AIX, and defaults for _ssl connections

[Michael Felt]

Michael Felt  added the comment:

I "guess" it is somewhere in this code. But I am getting lost in all the macros 
that call other macros.

Some help would really be appreciated!

Currently looking in _ssl.c at:

/*[clinic input]
_ssl.get_default_verify_paths

Return search paths and environment vars that are used by SSLContext's 
set_default_verify_paths() to load defa
ult CAs.

The values are 'cert_file_env', 'cert_file', 'cert_dir_env', 'cert_dir'.
[clinic start generated code]*/

static PyObject *
_ssl_get_default_verify_paths_impl(PyObject *module)
/*[clinic end generated code: output=e5b62a466271928b input=5210c953d98c3eb5]*/
{
PyObject *ofile_env = NULL;
PyObject *ofile = NULL;
PyObject *odir_env = NULL;
PyObject *odir = NULL;

#define CONVERT(info, target) { \
const char *tmp = (info); \
target = NULL; \
if (!tmp) { Py_INCREF(Py_None); target = Py_None; } \
else if ((target = PyUnicode_DecodeFSDefault(tmp)) == NULL) { \
target = PyBytes_FromString(tmp); } \
if (!target) goto error; \
}

CONVERT(X509_get_default_cert_file_env(), ofile_env);
CONVERT(X509_get_default_cert_file(), ofile);
CONVERT(X509_get_default_cert_dir_env(), odir_env);
CONVERT(X509_get_default_cert_dir(), odir);
#undef CONVERT

return Py_BuildValue("", ofile_env, ofile, odir_env, odir);

  error:
Py_XDECREF(ofile_env);
Py_XDECREF(ofile);
Py_XDECREF(odir_env);
Py_XDECREF(odir);
return NULL;
}

What I would like to know is what environment variable is being used. Not clear 
to me from the code here.

Thx.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Nick Coghlan]

Nick Coghlan  added the comment:

As a completely minimal strawman design that's the closest fit to what SafeMath 
is already doing: what if there was a "linecache.fallback_source_path" 
attribute that linecache searched with importlib whenever a loader returned 
None to indicate that the module existed, but not in a format that provided 
source code?

Then instead of adding the source directory to sys.path (which was only working 
because the legacy import system never implemented PEP 302 properly), SageMath 
could instead add the source directory to that new 
linecache.fallback_source_path list.

(Given a separate linecache.fallback_metapath, a suitably clever Finder 
implementation could then even provide the URL source lookup feature)

There'd be some API design issues to work out around ensuring that directories 
added to linecache.fallback_source_path are added in the same relative order as 
directories on sys.path, but the end result would likely be more reliable and 
resilient than relying on "additional directory installed later in sys.path" as 
the fallback strategy for handling sourceless modules.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32797] Tracebacks from Cython modules no longer work

[Nick Coghlan]

Nick Coghlan  added the comment:

This problem isn't unique to Cython extension modules - it exists for pyc-only 
distribution of pure Python files as well.

The underlying problem is that we don't currently have a mechanism comparable 
to JavaScript source maps, whereby a preprocessed runtime artifact can provide 
a reference back to a more debugging-friendly representation that's stored 
somewhere else (whether that's adjacent to the compiled form, in a different 
directory elsewhere on the same machine, or even on a remote web server).

So I think asking how ExtensionFileLoader.get_source() should behave is likely 
looking at the problem at the wrong level: a better question may be to ask what 
feature *linecache* is missing to allow it to correctly report source lines for 
modules that do *not* include their source code when installed, but do have 
that source code available in a shadow directory, where the only things that 
change are the root location (which could potentially even be a HTTP or HTTPS 
URL), and a fixed transformation on the module filename itself (e.g. replacing 
"*.so" with "*.c", or "*.pyc" with "*.py").

Given such a feature in Python 3.8, and support for it in Cython, the enhanced 
linecache module could then be published to PyPI as backports.linecache, 
providing access to this improved behaviour on all Python 3 versions that 
SageMath wants to support.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21914] Create unit tests for Turtle guionly

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Hey Rajalakshmi,

Are you still working on this issue? Is there anything we can help you with?

--
nosy: +CuriousLearner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks a lot tzickle, I'll take a look.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[tzickel]

tzickel  added the comment:

It actually makes tons of sense that while the thread is running, that the 
object representing it is alive. After the thread finishes its work, the object 
dies.

>>> import time, threading, weakref, gc
>>> t = threading.Thread(target=time.sleep, args=(10,))
>>> wr = weakref.ref(t)
>>> t.start()
>>> del t
>>> gc.collect()
>>> wr()

Wait 10 seconds...
>>> gc.collect()
>>> wr()

The thread is gone (which doesn't happen with the pool).

Anyhow, I've submitted a patch to fix the bug that was introduced 9 years ago 
on GH, feel free to check it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34273] %f is confusingly associated with fixed point format

[Michael Fischer]

Michael Fischer  added the comment:

Terry: I absolutely agree with you. Changing 'Fixed point' to 'Fixed point 
notation' is the optimal solution here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +8164

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33898] pathlib issues with Windows device paths

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +8163
stage: test needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20596] Support for alternate wcstok syntax for Windows compilers

[Erik Janssens]

Erik Janssens  added the comment:

Would anyone mind if I create a new issue to reflect the current situation and 
create a PR to handle it with a Py_WCSTOK ?

--
nosy: +erikjanss

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34334] QueueHandler logs exc_info twice

[Adrian Dries]

New submission from Adrian Dries :

Since Python 3.7 logging.handlers.QueueHandler logs tracebacks twice::


>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> try: 1/0
... except: logging.exception('Look out!')
... 
Look out!
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: division by zero


Patching QueueHandler.prepare() to set exc_text to None seems to fix this.

--
components: Library (Lib)
messages: 323100
nosy: avdd
priority: normal
severity: normal
status: open
title: QueueHandler logs exc_info twice
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34332] Suggestion for a new loop type

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

You can also use a context manager and the `with` statement.

--
nosy: +matrixise

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34331] Incorrectly pluralized abstract class error message

[Daniel Andrade Groppe]

Change by Daniel Andrade Groppe :


--
keywords: +patch
pull_requests: +8162
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34296] Speed up python startup by pre-warming the vm

[Nick Coghlan]

Nick Coghlan  added the comment:

It isn't currently feasible to do anything along these lines, as the CPython 
runtime is highly configurable, so it's far from clear what, if anything, could 
be shared from run to run, and nor is it clear how the interpreter could check 
whether or not the current configuration settings matched those of the 
pre-warmed one.

However, the work taking place for PEP 432 (issue dependency added) will 
potentially make it possible to revisit this, as there may be a way to cache 
preconfigured interpreters in a fashion that means calculating the cache key 
from the current configuration and then loading the cached interpreter state is 
faster that imperatively initialising a fresh interpreter.

Even if it isn't possible to cache an entire interpreter state, there may at 
least be opportunities to optimise particular configuration substeps.

--
dependencies: +PEP 432: Redesign the interpreter startup sequence

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com