[issue9417] Declaring a class creates circular references
Kay Hayen added the comment: What I also meant to say, is that debug Python is not affected, and this had me deeply confused. Any ideas how that could happen? -- ___ Python tracker <https://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Kay Hayen added the comment: Today I changed my reference count tests to not use debug Python and came across this issue. >From my testing, Python3.4 is the first affected version, Python3.3 was still >fine, so were 2.7 and 2.6. This leaks: def simpleFunction39(): class Parent(str): pass This does not: def simpleFunction39(): class Parent(object): pass When comparing (or attempted to) gc.get_objects() before and after, I was unable to point to any count that would be different, that was confusing. I can rule out a mistake in my changes to how the counts are achieved, because every other reference count test works. -- nosy: +kayhayen ___ Python tracker <https://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`
Kay Hayen added the comment: Thanks a lot, Batuhan, this will feel a lot more correct, from my point of view, this could be closed unless there would be a backport. -- ___ Python tracker <https://bugs.python.org/issue35143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36725] Reference leak regression with Python3.8a3
New submission from Kay Hayen : Much like #9366 the same file can be used. This reference leaks according to Nuitka comparative testing: simpleFunction59: FAILED 129511 129512 leaked 1 def simpleFunction59(): a = 3 b = 5 try: a = a * 2 return a finally: return a / b I would be guessing, that you are leaking the return value when returning again. -- messages: 340861 nosy: kayhayen priority: normal severity: normal status: open title: Reference leak regression with Python3.8a3 type: resource usage versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11566] hypot define in pyconfig.h clashes with g++'s cmath
Change by Kay Hayen : -- nosy: -Kay.Hayen __ Python tracker <https://bugs.python.org/issue11566> __ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35143] Annotations future requires unparse, but not accessible from Pythpn
New submission from Kay Hayen :
Hello,
in trying to know what to put into "__annotations__" at run time, the "from
__future__ import annotations" pose a new problem. It is now necessary to
"unparse" to ast code that is still there.
Code to do so, is in C API "_PyAST_ExprAsUnicode", but won't work with the
Python level ast objects.
I have a kludge, using "compile" and "exec", to get past that. It's pretty ugly
to do it like this, and Nuitka cannot be alone in trying to predict the value
of "__annotations__".
This code is my "ast.unparse" replacement:
def unparse(node):
_host_node = ast.parse("x:1")
_host_node.body[0].annotation = node
r = compile(_host_node, "", "exec", 1048576, dont_inherit
= True)
# Using exec here, to compile the ast node tree back to string,
# there is no accessible "ast.unparse", and this works as a hack
# to convert our node to a string annotation, pylint: disable=exec-used
m = {}
exec(r, m)
return m["__annotations__"]['x']
I am caching "_host_node" in the real code.
Having a real "ast.unparse" would be better however. It seems that the building
blocks are all there, just not in that form.
Yours,
Kay
--
messages: 329114
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Annotations future requires unparse, but not accessible from Pythpn
type: enhancement
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35143>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34615] subprocess.call wrong exit code
Kay Hayen added the comment: So I was confused indeed. Actually I am observing in other tests at least, that apparently Nuitka compiled execution in my tests can import _testcapi module, which normal execution of the test does not manage. Then there is the possibility that the exit code is indeed "0" and different. The failure to import that module is old, and something I consider to raise as a separate issue. Closing this one as it's not worthy. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34615] subprocess.call wrong exit code
Kay Hayen added the comment: I think that the whole reason I was doing this, is because with "os.execl" on Windows, the exit code was always lost, but of course it is very important and "subprocess.call" promises to return it. I just tried if 3.7 has any better exit code handling right there for "os.execl", but apparently it's not the case. -- ___ Python tracker <https://bugs.python.org/issue34615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34615] subprocess.call wrong exit code
New submission from Kay Hayen : Hello there, I am probably confusing myself. I am using this kind of code in Nuitka to emulate "os.execl" on Windows, and so far it never let me down: r = subprocess.call( args, shell = False ) print (r, args) sys.exit(r) When i execute my tests with Nuitka and Python 3.6 and everything before, this gives: 1 ['test_call.exe'] 1 ['C:\\Python36_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py'] And with python 3.7 it gives: 0 ['test_call.exe'] 0 ['C:\\Python37_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py'] So I am in Nuitka re-executing itself without the site module, and then immediately the created binary. For 3.7 it doesn't give me an error. I manually confirmed that "test_call.exe" indeed gives error code 1 as well, in both bash and cmd.exe, but it is not seen in the return value. Checking existing issues, I didn't find any hint at all, how this can be. I added "shell = False" to make it clear that no "cmd.exe" should be used, for which there had been issues. I also confirmed, by adding a exit(27), that if I simulate that "test_call.exe" gave 27, rather then 0, then that one is detected by the exec, so what could be going on here. But I am also sure I don't confuse binaries or so, plus it's working as expected in other Python versions than 3.7.0 here. This happens with 64 bits too, I am only citing 32 bits. And it is happening with just about every compiled unit test that gives an error exit, where otherwise e.g. tests that check for error exits to be the case work nicely. Thanks for any help or direction you can give me there. I am at loss. Yours, Kay -- components: Windows messages: 324897 nosy: kayhayen, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: subprocess.call wrong exit code type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34265] Dataclasses test doesn't run independently
Kay Hayen added the comment: Totally is. Closing, sorry for not seeing that one myself. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34265] Dataclasses test doesn't run independently
New submission from Kay Hayen : When I run: python3.7 test/test_dataclasses.py == ERROR: test_classvar_module_level_import (__main__.TestStringAnnotations) -- Traceback (most recent call last): File "/home/hayen/repos/Py2C/tests/CPython37/test/test_dataclasses.py", line 2716, in test_classvar_module_level_import from . import dataclass_module_1 ImportError: cannot import name 'dataclass_module_1' from '__main__' (/home/hayen/repos/Py2C/tests/CPython37/test/test_dataclasses.py) == FAIL: test_no_repr (__main__.TestRepr) -- Traceback (most recent call last): File "/home/hayen/repos/Py2C/tests/CPython37/test/test_dataclasses.py", line 1970, in test_no_repr repr(C(3))) AssertionError: 'test_dataclasses.TestRepr.test_no_repr..C object at' not found in '<__main__.TestRepr.test_no_repr..C object at 0x7f6a2d4ffd68>' The relative imports cannot work, as the main program is not in the test package. Also it has the name __main__ not the module name in repr. As Guido said in another bug report, tests are expected to pass. Can you please adapt them? I hope "Library" is proper component, as tests are below it. Thanks, Kay -- components: Library (Lib) messages: 322570 nosy: kayhayen priority: normal severity: normal status: open title: Dataclasses test doesn't run independently versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34251] MSI build fails
New submission from Kay Hayen : Hello there, building an MSI for my project fails. I am calling it like this: assert subprocess.call( ( sys.executable, "setup.py", "bdist_msi", "--target-version=" + sys.version[:3] ) ) == 0 Giving the target version is probably non-sense and from a time, where one script was building multiple MSIs, I no longer do that. and it gives: File "C:\Python37_64\lib\site-packages\setuptools\__init__.py", line 129, in setup return distutils.core.setup(**attrs) File "C:\Python37_64\lib\distutils\core.py", line 148, in setup dist.run_commands() File "C:\Python37_64\lib\distutils\dist.py", line 966, in run_commands self.run_command(cmd) File "C:\Python37_64\lib\distutils\dist.py", line 985, in run_command cmd_obj.run() File "C:\Python37_64\lib\distutils\command\bdist_msi.py", line 256, in run self.add_find_python() File "C:\Python37_64\lib\distutils\command\bdist_msi.py", line 346, in add_find_python if msilib.Win64: AttributeError: module 'msilib' has no attribute 'Win64' This happens for 32 and 64 bit CPython 3.7.0 installations. The same code works for all of 2.7, 3.3 through to 3.6, so this is a regression. Any idea? Thanks, Kay -- components: Distutils messages: 322510 nosy: dstufft, eric.araujo, kayhayen priority: normal severity: normal status: open title: MSI build fails type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34136] Del on class __annotations__ regressed, failing test
Kay Hayen added the comment: As somebody whose opinion is even less important: Did you consider my suggestion to make it a "SyntaxError" for "del __annotations__" on a class level or even module level or at all? Or does this go too far? Yours, Kay -- ___ Python tracker <https://bugs.python.org/issue34136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34136] Del on class __annotations__ regressed, failing test
Kay Hayen added the comment: Thanks for pointing out, where it comes from, Serhiy. So, should the test case be removed then. I still am not so sure about the bug nature. Because using the standard mechanism will do this: x : int class C: del __annotations__ x : float y : int print(__annotations__) This will give float for x, and int for y, both of which are wrong for the module. I do agree that "del" on "__annotations__" might not have a use case, or does it? I think it's optimized away if not used for classes anyway, isn't it? Maybe you want make "del" on __annotations__ a syntax error then? Yours, Kay -- ___ Python tracker <https://bugs.python.org/issue34136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34136] Del on class __annotations__ regressed, failing test
New submission from Kay Hayen : I am getting this: PYTHONPATH=`pwd` /c/Python37_32/python test/test_opcodes.py .F.. == FAIL: test_do_not_recreate_annotations (__main__.OpcodeTest) -- Traceback (most recent call last): File "test/test_opcodes.py", line 45, in test_do_not_recreate_annotations class C: File "test/test_opcodes.py", line 48, in C x: int AssertionError: NameError not raised I have seen this on Linux as well. I first notices that as a regression of Nuitka in the CPython36 test suite. It actually took me a while to implement support for "del __annotations__" to make later references not fall back to the module "__annotation__", for 3.6 compatibility. However, now with 3.7 behavior is back to what 3.5 I think would have done, while the test is not updated to match. I am confused now, which is the intended way for this to work? Should I follow this change, or will it be fixed, or am I doing something wrong in running something wrong here? Yours, Kay -- components: Interpreter Core messages: 321807 nosy: kayhayen priority: normal severity: normal status: open title: Del on class __annotations__ regressed, failing test type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34042] Reference loss for local classes
Kay Hayen added the comment: Hello, so it's harmless and it explains the other reference counting issue, where a change in call convention could make a reference counting bug show or go away: codecs.open(TESTFN, encoding='cp949') This was showing it, where as codecs.open(TESTFN, "rb", 'cp949') was not. With all the difference being a dictionary passed into a function call or not. I am now assuming that getting your fix this will also go away. Caused me a bit of head scratching already. If you could do what you often you, and make this what distributions like Debian pull from, it would be good enough in terms of release for me, as it blocks Nuitka tests from passing on them. Yours, Kay -- ___ Python tracker <https://bugs.python.org/issue34042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34042] Reference loss for local classes
Kay Hayen added the comment: Just to confirm, this is also happening on Windows as well, with both 32 and 64 bits. -- ___ Python tracker <https://bugs.python.org/issue34042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34042] Reference loss for local classes
New submission from Kay Hayen : I have a test in Nuitka, designed to detect reference counting problems with Python code. It basically takes a snapshot of the refcount, runs a function until it stabilizes, then says PASS, or else reports the last diff. Obviously for CPython it's supposed to pass. Testing with self compiled 3.7.0 and 3.7.0-1 as in Debian testing (buster) currently, this happens for me: This is a cutout, there are more than 100 functions, I am listing the ones that report: simpleFunction16: FAILED 118414 118412 leaked -2 simpleFunction17: FAILED 118395 118393 leaked -2 simpleFunction18: FAILED 118375 118373 leaked -2 ... simpleFunction21: FAILED 118337 118333 leaked -4 ... simpleFunction25: FAILED 118315 118313 leaked -2 simpleFunction26: FAILED 118295 118293 leaked -2 ... simpleFunction38: FAILED 118257 118253 leaked -4 simpleFunction39: FAILED 118235 118233 leaked -2 ... simpleFunction43: FAILED 118215 118213 leaked -2 simpleFunction48: FAILED 118195 118193 leaked -2 ... simpleFunction76: FAILED 118422 118418 leaked -4 ... simpleFunction88: FAILED 118400 118398 leaked -2 This is really bad, because normally values are positive, merely preventing a release. A negative value indicates that references have been lost. This will normally result in corruption of the memory allocator for Python, although I have not yet seen that. I have a few remaining cases, where compiled code causes negative leaks too, there is happens. But I didn't force the issue yet. Notice that this is of course with the debug Python version and let me express, pure CPython is used to run the test code. When compiling with Nuitka and 3.7, my private code gives the same ref counts for there, but it also pretty much does the same things, these are some of the functions: def simpleFunction16(): class EmptyClass: pass return EmptyClass def simpleFunction39(): class Parent(object): pass All the other cases also use locally defined classes and only test cases using local classes are failing for me here. To reproduce is easy: git clone --branch develop http://git.nuitka.net/Nuitka.git python3.7-dbg Nuitka/tests/basics/Referencing.py Thanks, Kay Hayen -- messages: 321037 nosy: kayhayen priority: normal severity: normal status: open title: Reference loss for local classes versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34024] Builtin types take no keyword arguments anymore
Kay Hayen added the comment: Hello Ned, sorry for noise. I checked that, but oversaw it. Maybe I also wasn't expecting this. There has been such a huge trend towards * and ** support for like everything, e.g. class definitions in 3.6, that this felt like a move in the opposite direction. But I got the information I need for Nuitka to follow this. I agree with your close and my apology. Yours, Kay -- ___ Python tracker <https://bugs.python.org/issue34024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34024] Builtin types take no keyword arguments anymore
New submission from Kay Hayen : Hello, things like list(sequence = something) ought to work in Python 3.6 back to the oldest Python2 I know. However, in 3.7 this raises an exception about not accepting keyword arguments. I noticed the same for tuple, int, float(x=9.0), and probably a lot others. It is not described in the release notes either. I think it's a bug and might affect existing code. Or is this how thing will be from now on? Yours, Kay -- components: Interpreter Core messages: 320888 nosy: kayhayen priority: normal severity: normal status: open title: Builtin types take no keyword arguments anymore type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31745] Overloading "Py_GetPath" does not work
New submission from Kay Hayen <kay.ha...@gmail.com>: Hello, for my Python compiler Nuitka, I want to make sure that compiled binaries in standalone mode do not access the original installation, but solely the distribution folder created. I am using the new API Py_SetPath on Python3 and it works fine. The Python2.7 documentation of the C-API however says: The embedding application can steer the search by calling Py_SetProgramName(file) before calling Py_Initialize(). Note that PYTHONHOME still overrides this and PYTHONPATH is still inserted in front of the standard path. An application that requires total control has to provide its own implementation of Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix(), and Py_GetProgramFullPath() (all defined in Modules/getpath.c). My attempts at overloading this have badly failed, because of conflicting "declspec" (dllimport vs dllexport). And when defining Py_GetPath away before making the include, so the conflict is not seen by the MSVC compiler, the result is that the function is not called. Is this known to work? Can you point me to a working example, because my searches didn't reveal anything. Not normal web search, nor global code search for Py_GetPath code. I did not try on Linux yet. I am assuming it might work, I just wanted to tap on knowledge on your side. Is it feasible. For Linux? For Windows? Thanks, Kay Hayen -- components: Build messages: 304045 nosy: kayhayen priority: normal severity: normal status: open title: Overloading "Py_GetPath" does not work type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30878] The staticmethod doesn't properly reject keyword arguments
New submission from Kay Hayen: Check out this: python3.6 -c "staticmethod(function=1)" Traceback (most recent call last): File "", line 1, in TypeError: staticmethod expected 1 arguments, got 0 python3.6 -c "staticmethod()" Traceback (most recent call last): File "", line 1, in TypeError: staticmethod expected 1 arguments, got 0 python3.6 -c "staticmethod(f=1)" Traceback (most recent call last): File "", line 1, in TypeError: staticmethod expected 1 arguments, got 0 I believe Python 2.7 behaves the same. What should happen is more like this: python3.6 -c "range(f=1)" Traceback (most recent call last): File "", line 1, in TypeError: range() does not take keyword arguments While statically optimizing, I came across this as a first. At least "classmethod" behaves the same. I suppose it is because these are not intended for manual use anymore. I would recommend to fix up the argument parsing to either indicate its rejection of keyword arguments, or to accept "function = " for input (preferred). Thanks, Kay Hayen -- components: Interpreter Core messages: 297946 nosy: kayhayen priority: normal severity: normal status: open title: The staticmethod doesn't properly reject keyword arguments versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27942] Default value identity regression
Kay Hayen added the comment: Same with 3.6b1, still present. -- nosy: +kayhayen ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28257] Regression for star argument parameter error messages
New submission from Kay Hayen:
Hello,
there is a regression in the beta (alpha 4 was ok) for this kind of code:
print("Complex call with both invalid star list and star arguments:")
try:
a = 1
b = 2.0
functionWithDefaults(1,c = 3,*a,**b)
except TypeError as e:
print(repr(e))
try:
a = 1
b = 2.0
functionWithDefaults(1,*a,**b)
except TypeError as e:
print(repr(e))
try:
a = 1
b = 2.0
functionWithDefaults(c = 1, *a,**b)
except TypeError as e:
print(repr(e))
try:
a = 1
b = 2.0
functionWithDefaults(*a,**b)
except TypeError as e:
print(repr(e))
This prints with beta1 3.6
Complex call with both invalid star list and star arguments:
TypeError("'int' object is not iterable",)
TypeError("'int' object is not iterable",)
TypeError("'float' object is not iterable",)
TypeError('functionWithDefaults() argument after ** must be a mapping, not
float',)
The later message is what they all probably should be like. This is 3.5 output:
Complex call with both invalid star list and star arguments:
TypeError('functionWithDefaults() argument after ** must be a mapping, not
float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not
float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not
float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not
float',)
The function itself doesn't matter obviously, it's never called. Please restore
the old behavior, thanks.
Yours,
Kay
--
messages: 277270
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Regression for star argument parameter error messages
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28257>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27942] Default value identity regression
New submission from Kay Hayen: Consider this: def defaultKeepsIdentity(arg = "str_value"): print(arg is "str_value") defaultKeepsIdentity() This has been outputing "True" on every Python release I have seen so far, but not so on 3.6.0a4. Normally string values come from a "co_const" and will be "is" identical if used as literals in a module, but no longer in this case. This seems wasteful at best, needlessly increasing the number of strings in usage. Yours, Kay -- components: Interpreter Core messages: 274257 nosy: Kay.Hayen priority: normal severity: normal status: open title: Default value identity regression type: resource usage versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11566] hypot define in pyconfig.h clashes with g++'s cmath
Kay Hayen added the comment: This also affects Python2.7.12 on Windows with latest MinGW. I think something similar needs to be added for GCC version check: /* VS 2010 and above already defines hypot as _hypot */ #if _MSC_VER < 1600 #define hypot _hypot #endif Not sure which gcc version first had that, but 6.1 definitely does. Yours, Kay -- nosy: +Kay.Hayen ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16967] Keyword only argument default values are evaluated before other defaults
Kay Hayen added the comment: I can confirm that Python3.4 is not affected. Python 3.3 and 3.2 still are. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
Kay Hayen added the comment: Are you still tracking this as a feature request. If so, please note that I don't need it anymore. The meta path based import mechanism is fully sufficient to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16967] Keyword keyword only default parameters are evaluated before po
New submission from Kay Hayen: Suprisingly, keyword only arguments become evaluated first: def f(a=undefined1,*,b=undefined2):pass ... Traceback (most recent call last): File stdin, line 1, in module NameError: name 'undefined2' is not defined It should be undefined1. I am sure, this is going to surprise developers and breaks assumptions, people tend to make. So far (to my knowledge) nothing that was separated by a , could be evaluated in a mixed order. Please consider to change this around. -- components: Interpreter Core messages: 179970 nosy: Kay.Hayen priority: normal severity: normal status: open title: Keyword keyword only default parameters are evaluated before po versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13792] The os.execl call doesn't give programs exit code
Kay Hayen kayha...@gmx.de added the comment: Does the Python standard library not offer anything that does replace with current process code with another? I checked with subprocess, and admittedly it's not that. Does Win32 API offer nothing for that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13792] The os.execl call doesn't give programs exit code
New submission from Kay Hayen kayha...@gmx.de: Hello, I am the author of the Python compiler Nuitka. It has the ability to immediately execute the created executable file. For that I am using os.execl to immediately replace the compiler and run the freshly created binary instead. This worked well so far, but as of late, I am also checking the exit codes, and it turns out that even for failing programs, the exit code is 0 on Windows, even though the compiled binary is exiting with 1. Investigating further, I made a simple program: --- import os os.execl( FailingProgram.exe, lala ) --- And it turns out, it's giving me 0, whereas when executed directly FailingProgram.exe gives 1. Checking %errorlevel% manually that is, my test framework uses subprocess module and gets 0. The same code works fine (preserves exit code) under Linux. I didn't find the windows specific code responsible for implementing os.execv under Win32. I am suspecting that somehow cmd.exe may not be propagating the error code, but for that to confirm I would need pointers. Thanks in advance, Kay -- components: Library (Lib) messages: 151304 nosy: kayhayen priority: normal severity: normal status: open title: The os.execl call doesn't give programs exit code type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13792] The os.execl call doesn't give programs exit code
Kay Hayen kayha...@gmx.de added the comment:
Well, I saw that code, but expected that there must be more to it. But I found
out, the bug is actually caused by at least MinGW. See below how I build a
program with it, that does execl on an error exiting program and then the
errorlevel variable is 0, whereas direct execution gives 1.
I don't have MSVC installed, so I cannot tell if it is affected as well. I will
report this as a bug to MinGW then.
c:\Users\hayen\Nuitkagcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/lib/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Ziel: mingw32
Konfiguriert mit: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,ob
jc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libg
omp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-
runtime-libs --build=mingw32 --prefix=/mingw
Thread-Modell: win32
gcc-Version 4.6.2 (GCC)
c:\Users\hayen\Nuitkagcc exec_sample.cpp
c:\Users\hayen\Nuitkatype exec_sample.cpp
#include unistd.h
#include stdio.h
int main()
{
puts( Hello bad world! );
execl( badprogram.exe, badprogram, what );
puts( Look, this is not happening! );
return 2;
}
c:\Users\hayen\Nuitka.\a.exe
Hello bad world!
c:\Users\hayen\NuitkaTraceback (most recent call last):
File tests\syntax\RelativeNonPackageImport.py, line 20, in module
from . import whatever
ValueError: Attempted relative import in non-package
c:\Users\hayen\Nuitkaecho %errorlevel%
0
c:\Users\hayen\Nuitka.\badprogram.exe
Traceback (most recent call last):
File tests\syntax\RelativeNonPackageImport.py, line 20, in module
from . import whatever
ValueError: Attempted relative import in non-package
c:\Users\hayen\Nuitkaecho %errorlevel%
1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13792
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13735] The protocol 0 of cPickle does not given stable dictionary values
Kay Hayen kayha...@gmx.de added the comment: It seems that there is an extra BINPUT 2, whatever it does. I am attaching a variant that does pickletools.dis on the 3 dumps. Protocol 2 : Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.' 0: \x80 PROTO 2 2: }EMPTY_DICT 3: qBINPUT 1 5: USHORT_BINSTRING 'modules' 14: qBINPUT 2 16: NNONE 17: sSETITEM 18: .STOP highest protocol among opcodes = 2 Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' 0: \x80 PROTO 2 2: }EMPTY_DICT 3: qBINPUT 1 5: USHORT_BINSTRING 'modules' 14: NNONE 15: sSETITEM 16: .STOP highest protocol among opcodes = 2 Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' 0: \x80 PROTO 2 2: }EMPTY_DICT 3: qBINPUT 1 5: USHORT_BINSTRING 'modules' 14: NNONE 15: sSETITEM 16: .STOP highest protocol among opcodes = 2 -- Added file: http://bugs.python.org/file24180/stream.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13735] The protocol 0 of cPickle does not given stable dictionary values
Kay Hayen kayha...@gmx.de added the comment: Sending my attached file stream.py through 2to3.py it shows that CPython 3.2 doesn't exihibit the issue for either protocol, which may be because it's now unicode key, but as it's the only value I tried, I can't tell. Hope this helps. Regarding the marshal, I presume, that somehow the dictionary when created via marshal (or compile, if no .pyc is involved?) first time is somehow less efficient to determine/stream that the one cPickle created. My assumption is that somehow, when creating the dictionary from cPickle, it is different (has to be), and that's interesting. And of course the easier to stream dictionary may be the nicer one at runtime as well. But that is just my speculation. Yours, Kay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13735] The protocol 0 of cPickle does not given stable dictionary values
Kay Hayen kayha...@gmx.de added the comment: I see, if it's refcount dependent, that explains why it changes from interpreter provided dictionary and self-created one. So, I take, I should always call pickletools.optimize( cPickle.dumps( value )) then. Thanks, Kay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13735] The protocol 0 of cPickle does not given stable dictionary values
New submission from Kay Hayen kayha...@gmx.de: Hello, I am implementing a Python compiler (Nuitka) that is testing if when it compiles itself, it gives the same output. I have been using protocol = 0 ever since with pickle module for historic reasons (gcc bug with raw strings lead me to believe it's better) and lately, I have changed to protocol = 2 and cPickle. But then I noticed that my compile itself test now fail to give same code from pickling of dictionary constants. Imanaged and isolated the issue, and it's a Python2.7 regression, Python2.6 is fine: Observe this output from cPickle.dumps for a constant dictionary with one element: Protocol 0 : Dumping read const const stream (dp1\nS'modules'\np2\nNs. Dumping load const const stream (dp1\nS'modules'\np2\nNs. Dumping load const const stream (dp1\nS'modules'\np2\nNs. Protocol 1 : Dumping read const const stream '}q\x01U\x07modulesq\x02Ns.' Dumping load const const stream '}q\x01U\x07modulesNs.' Dumping load const const stream '}q\x01U\x07modulesNs.' Protocol 2 : Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.' Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' It seems that cPickle as of CPython2.7 does give a better stream for dictionaries it itself emitted. With CPython2.6 I observe no difference. My work-around is to re-stream, dumps - loads - dumps with CPython2.7 for the time being. Can you either: Fix cPickle to treat the dictionaries the same, or enhance to core to produce the same dict as cPickle does? It appears at least some kind of efficiency might be missed out for marshall as well. -- components: Interpreter Core, Library (Lib) files: stream.py messages: 150841 nosy: kayhayen priority: normal severity: normal status: open title: The protocol 0 of cPickle does not given stable dictionary values type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file24170/stream.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
Kay Hayen kayha...@gmx.de added the comment: Why did you remove Python2.7 from the versions list? Isn't this supposed to track the affected versions? (This is not the first time I encountered that.) I understand that you may not fix all bugs in 2.x, but is it already unsupported in the sense that its bugs are not tracked, then remove it from the tracker. In the alternative, please add 2.7 (and 2.6) back. Thanks, Kay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
New submission from Kay Hayen kayha...@gmx.de: Hello, I try to include modules with PyImport_AppendInittab or PyImport_ExtendInittab and that works fine. But if these modules are part of a package, i.e. I provide package_name.module_name as the name, they never get considered. Is there any way to add a package with modules below it from C/API? So that an import package_name.module_name from other modules will find it? Yours, Kay Hayen -- messages: 115235 nosy: kayhayen priority: normal severity: normal status: open title: The inittab modules cannot be packages type: feature request versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9690] Cannot distinguish bstr from str in ast module.
Kay Hayen kayha...@gmx.de added the comment: This is to inform you that I worked around the bug by reading the source file in question and checking the indicated position. This is currently the only way to decide if a literal should be unicode or str with unicode_literals from future imported. It goes like this: kind = _sources[ filename ][ node.lineno - 1][ node.col_offset ] if kind != 'b': value = unicode( node.s ) else: value = node.s I don't see how removing the ambgious representation of what I presume is a wanted language construct can be considered a new feature. But that is your decision to make. Best regards, Kay Hayen -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9690] Cannot distinguish bstr from str in ast module.
Kay Hayen kayha...@gmx.de added the comment: You didn't understand. Please tell me, how to decide if this is a unicode literal or a str (2.x) literal: value=Str(s='d') It's just not possible. When I found a from __future__ import unicode_literals in the code before, it means I should convert value.s to unicode fine. But the syntax allows with bd to make an exception for some strings. Your test test_compile.py contains it. May I ask you to not close this bug therefore, as your proposal is not feasible? I really need ast.parse() to return different nodes for the string literals d and bd or else I cannot detect the non-unicode literals with unicode literals as default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9690] Cannot distinguish bstr from str in ast module.
Kay Hayen kayha...@gmx.de added the comment: Hello Benjamin, thank you for the response. What do you mean with there is nothing we can do about it. Is it not possible to add another field indicating the prefix given to a literal? BTW: I believe raw strings are also no longer recognizable. Fortunately I do not need to do that, but look here: ast.dump( ast.parse( ra = r'\n' ) ) Module(body=[Assign(targets=[Name(id='a', ctx=Store())], value=Str(s='n'))]) Currently the only work around to not being able to tell if there was a b in the source code, is to open the file and check myself. And getting the actual raw string is not feasible at all. So why not at least have an ast module that allows to decide without ambiguity what the user said. I agree that raw strings can be solved before the AST and it doesn't matter much. But I don't think it's acceptable that CPython can execute the code correctly, but using the AST nodes, there is no way to tell. I thought they share code? Yours, Kay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9690] Cannot distinguish bstr from str in ast module.
New submission from Kay Hayen kayha...@gmx.de: There is no way to decide if a string literal should be non-unicode when the default has been set to unicode_literals. Please see: import ast ast.dump( ast.parse( c = d ) ) Module(body=[Assign(targets=[Name(id='c', ctx=Store())], value=Str(s='d'))]) from __future__ import unicode_literals ast.dump( ast.parse( c = d ) ) Module(body=[Assign(targets=[Name(id='c', ctx=Store())], value=Str(s='d'))]) ast.dump( ast.parse( c = bd ) ) Module(body=[Assign(targets=[Name(id='c', ctx=Store())], value=Str(s='d'))]) ast.dump( ast.parse( c = ud ) ) Module(body=[Assign(targets=[Name(id='c', ctx=Store())], value=Str(s=u'd'))]) I have checked fields, but didn't find anything either. Without an indication of the Str literal type, its type cannot be detected. In either case it is str and may or not have to be converted to a unicode value. -- components: Library (Lib) messages: 114950 nosy: kayhayen priority: normal severity: normal status: open title: Cannot distinguish bstr from str in ast module. type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9656] compiler module provides wrong AST for extended slice of length 1
New submission from Kay Hayen kayha...@gmx.de:
Please check the following:
[GCC 4.4.5 20100728 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import compiler
compiler.parse( d[1,] = None )
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1)])],
Name('None'))]))
compiler.parse( d[1] = None )
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1)])],
Name('None'))]))
d = {}
d[1,] = None
d[1] = None
d
{1: None, (1,): None}
As you can see d[1] = None and d[1,] = None do different things, but do they
lead to the same abstract syntax tree. It's the same on Python 2.7:
Python 2.7.0+ (r27:82500, Aug 7 2010, 19:41:51)
[GCC 4.4.5 20100728 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import compiler
compiler.parse( d[1,] = None )
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1)])],
Name('None'))]))
compiler.parse( d[1] = None )
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1)])],
Name('None'))]))
--
components: Library (Lib)
messages: 114507
nosy: kayhayen
priority: normal
severity: normal
status: open
title: compiler module provides wrong AST for extended slice of length 1
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9656
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9366] Reference leak for local new style class
New submission from Kay Hayen kayha...@gmx.de: Hello, I have created tests that check the reference counting and found that the following simple function leaks references in CPython: def simpleFunction39(): class Parent( object ): pass I have attached a test that needs to be run with python-dbg and checks the total reference count for many language constructs. Sometimes a warmup can be useful, if CPython caches something, but it doesn't help in this case. Removing object or replacing it with an old style class helps. I think I saw that 3 references of object leak, and a total of ca. 20 for each call to the function. I suspect a memory leak too. Use the attached file for reproduction of the problem. -- components: Interpreter Core files: Referencing.py messages: 111433 nosy: kayhayen priority: normal severity: normal status: open title: Reference leak for local new style class type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file18173/Referencing.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
