[issue17396] modulefinder fails if module contains syntax error

New submission from Jan Gosmann: Running modulefinder.ModuleFinder.run_script on a script which has an import statement with a module containing a syntax error will raise a SyntaxError exception. I think, modulefinder should instead continue its analysis and add the module to badmodules

[issue17396] modulefinder fails if module contains syntax error

Jan Gosmann added the comment: Could you point me to some documentation on how to add a test? I have not been involved in Python development so far. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17396

[issue17396] modulefinder fails if module contains syntax error

Jan Gosmann added the comment: Here is an updated patch, also containing a test. -- Added file: http://bugs.python.org/file30237/fix-handling-of-syntax-errors.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17396

[issue17396] modulefinder fails if module contains syntax error

Jan Gosmann added the comment: It's based on the default branch becoming 3.4. -- versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17396

[issue21318] sdist fails with symbolic links do non-existing files

New submission from Jan Gosmann: If there is a symbolic link to a non-existing file anywhere in the source tree python setup.py sdist fails with an output like the following: running sdist running check warning: check: missing required meta-data: url error: abc: No such file

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

Changes by Jan Gosmann <jan+pythontrac...@hyper-world.de>: -- nosy: +jgosmann ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 28 Mar 2017, at 3:08, Peter Otten wrote: > Perhaps numpy's default integer type has changed (assuming you are using > integer arrays, I did look at, but not into your code)? > > You could compare > numpy.array([42]).itemsize > 8 > > for the two interpreters. Both report 8 for integer and

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 28 Mar 2017, at 6:11, INADA Naoki wrote: I managed to install pyopencl and run the script. It takes more than 2 hours, and uses only 7GB RAM. Maybe, some faster backend for OpenCL is required? I used Microsoft Azure Compute, Standard_A4m_v2 (4 cores, 32 GB memory) instance. I suppose

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

That's great news. I'm busy with other things right now, but will look into your findings in more detail later. On 03/30/2017 02:09 PM, INADA Naoki wrote: Filed an issue: https://bugs.python.org/issue29949 Thanks for your report, Jan. On Fri, Mar 31, 2017 at 3:04 AM, INADA Naoki

[issue29949] sizeof set after set_merge() is doubled from 3.5

Changes by Jan Gosmann <jan+pythontrac...@hyper-world.de>: -- nosy: +jgosmann ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 28 Mar 2017, at 14:21, INADA Naoki wrote: On Wed, Mar 29, 2017 at 12:29 AM, Jan Gosmann <j...@hyper-world.de> wrote: I suppose smaller and faster benchmark is better to others looking for it. I already stopped the azure instance. [...] There are no maxrss difference in "small

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 29 Mar 2017, at 20:12, Steve D'Aprano wrote: If you can demonstrate this effect using simple example code without the external dependencies (using nothing but the standard library) and people can replicate it, I think it should be reported as a bug. I probably won't be able to

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 27 Mar 2017, at 18:30, Peter Otten wrote: Are you perchance comparing 32-bit Python 3.5 with 64-bit Python 3.6? I don't think so. [sys.maxsize](https://docs.python.org/3/library/platform.html#cross-platform) indicates both to be 64-bit. --

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 27 Mar 2017, at 18:42, Chris Angelico wrote: Are you able to share the program? I could try it on my system and see if the same thing happens. Yes, it is on GitHub (use the fixes branch): https://github.com/ctn-archive/gosmann-frontiers2017/tree/fixes Installation instructions are in the

Program uses twice as much memory in Python 3.6 than in Python 3.5

Hi, I have a program which uses twice as much memory when I run it in Python 3.6 than when I run it in Python 3.5 (about 60GB instead of 30GB). I tried to find the reason for that, but the cumulated size (measured with sys.getsizeof) of all objects returned by gc.get_objects accumulates only

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 27 Mar 2017, at 20:00, Chris Angelico wrote: By the way, since you're aiming this at recent Python versions, you could skip the 'virtualenv' external dependency and use the built-in 'venv' package: $ python3 -m venv env Yeah, I know about venv. The last time I tried it, there was still

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 27 Mar 2017, at 20:12, Chris Angelico wrote: On Tue, Mar 28, 2017 at 11:00 AM, Chris Angelico wrote: In any case, I've installed nvidia-opencl-dev and it seems to be happy. How long should I expect this to run for? Now testing under CPython 3.7. It ran for about 14

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 03/29/2017 11:31 PM, Chris Angelico wrote: On Thu, Mar 30, 2017 at 2:19 PM, Rick Johnson wrote: [...] Really? How could your clients not notice 60 GB of memory usage unless they are running some kind of mad-dog insane top-of-the-line hardware? (Got

Re: Program uses twice as much memory in Python 3.6 than in Python 3.5

On 03/30/2017 02:19 PM, INADA Naoki wrote: FYI, this small patch may fix your issue: https://gist.github.com/methane/8faf12621cdb2166019bbcee65987e99 I can verify that the patch fixes the issue for me. Do you still need more information about the `transitive_closure` function and my usage of

cPickle fails on manually compiled and executed Python function

Hi, today I came across some weird behaviour (a bug?) in Python 2.7.13 (on Linux) with the cPickle module. The pickle module works and so does the pickle module in Python 3. I have a file fn.py with a minimal function definition: ``` def fn(): pass ``` The actual code that I run is in

Re: cPickle fails on manually compiled and executed Python function

On 07/18/2017 01:07 AM, dieter wrote: "Jan Gosmann" <j...@hyper-world.de> writes: [...] fn = load_pyfile('fn.py')['fn'] [...] "pickle" (and "cpickle") are serializing functions as so called "global"s, i.e. as a module reference together with a

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

Change by Jan Gosmann <jan+pythontrac...@hyper-world.de>: -- nosy: +jgosmann ___ Python tracker <rep...@bugs.python.org> <https://bugs.python