[issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__
Changes by Bruno Dupuis : Removed file: http://bugs.python.org/file28239/16049.patch ___ Python tracker <http://bugs.python.org/issue16049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__
Changes by Bruno Dupuis : Added file: http://bugs.python.org/file28240/16049.patch ___ Python tracker <http://bugs.python.org/issue16049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__
Bruno Dupuis added the comment: Éric, here is a full patch. I hope the doc isn't too confuse. I think we lack a word meaning 'has XXX as metaclass', we should imagine a term for that. -- keywords: +patch Added file: http://bugs.python.org/file28239/16049.patch ___ Python tracker <http://bugs.python.org/issue16049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue1294232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15045] Make textwrap.dedent() consistent with str.splitlines(True) and str.strip()
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue15045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11299] Allow deepcopying and pickling paused generators
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue11299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue887237] Machine integers
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue887237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16619] LOAD_GLOBAL used to load `None` under certain circumstances
Bruno Dupuis added the comment: We definitely need to put the code that loads constants with LOAD_CONST out of the optimization code. It's not optim, it's a language feature: None *is* a 'singleton' constant. I'm trying to figure out how to change compile.c to achieve this, as it's my first dive into the compiler code, it's not that easy. Another approch is to strip unreachable nodes in AST, but a) it's quite complex, as Terry said b) it solves only this particular bug, not the general assertion "None, True and False are reserved words bound to constants. It can not ever be loaded with LOAD_NAME or LOAD_GLOBAL" -- ___ Python tracker <http://bugs.python.org/issue16619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16619] LOAD_GLOBAL used to load `None` under certain circumstances
Bruno Dupuis added the comment: This first patch spots the issue, but doesn't solve it if the bytecode of the function is > 32700 (see PyCode_Optimize comment). However with this patch, we get the LOAD_CONST anytime for None, True and False. There is two questions : 1- is it safe to strip all the code after RETURN_VALUE as the patch does? 2- to correct this bug, we will need a deep refactoring of PyCode_Optimize (so that it accepts any code length). The other way, is not to rely on PyCode_Optimize to compile return None/True/False, but do modifictations in the compiler itself. This must be the right way to do this, but it's far beyond my C skills and python core knowledge. -- keywords: +patch Added file: http://bugs.python.org/file28217/16619-1.patch ___ Python tracker <http://bugs.python.org/issue16619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16619] LOAD_GLOBAL used to load `None` under certain circumstances
Bruno Dupuis added the comment: line 426 in peehole.c : if (codestr[codelen-1] != RETURN_VALUE) goto exitUnchanged; before the optim. I'm quite sure it's here. i patch and see... -- ___ Python tracker <http://bugs.python.org/issue16619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16619] LOAD_GLOBAL used to load `None` under certain circumstances
Bruno Dupuis added the comment: To me, the whole issue is at line ~ 480 in peehole.c in the LOAD_NAME/LOAD_GLOBAL switch case. This explains the difference between `return` and `return None` as the former is actually compiled to LOAD_CONST. OTOH, `return None` has to pass the optim pass to be changed in LOAD_CONST. The real bug is sometime it doesn't. -- ___ Python tracker <http://bugs.python.org/issue16619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16619] LOAD_GLOBAL used to load `None` under certain circumstances
New submission from Bruno Dupuis:
We found some strange behaviour of the compiler in this discussion on
python-list:
http://mail.python.org/pipermail/python-list/2012-December/636104.html
The fact is, `return` and `return None` result in inconsistent bytecode
depending on the context.
Consider :
>>> import dis
>>> def f(x):
... return None
...
>>> dis.dis(f)
2 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
>>> def g(x):
... return None
... print(x)
...
>>> dis.dis(g)
2 0 LOAD_GLOBAL 0 (None)
3 RETURN_VALUE
3 4 LOAD_GLOBAL 1 (print)
7 LOAD_FAST0 (x)
10 CALL_FUNCTION1 (1 positional, 0 keyword pair)
13 POP_TOP
`return None` statement results in LOAD_GLOBAL 0 if there is some unreachable
code after it. I first saw that as an optimization issue, but Ian Kelly's
message http://mail.python.org/pipermail/python-list/2012-December/636117.html
gives an extensive analysis and some examples:
"""
I think this should even be considered a bug, not just a missing
optimization. Consider:
>>> globals()['None'] = 42
>>> def f(x):
... return None
... print(x)
...
>>> f('test')
42
The use of the LOAD_GLOBAL allows None to effectively be reassigned.
"""
Ian also points out in this message that `return` and `return None` don't
result in the same bytecode when followed by trash code.
--
components: Interpreter Core
messages: 176999
nosy: Horpner, bruno.dupuis, ikelly, python-dev, stevenjd
priority: normal
severity: normal
status: open
title: LOAD_GLOBAL used to load `None` under certain circumstances
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue16619>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16588] gcc 4.7 unused-but-set warnings on Python/thread_pthread.h
Bruno Dupuis added the comment: I don't agree. Trash build logs are bad, trash code (I mean, in terms of utility, not quality :-) ) is far worst IMHO. The purpose of this bug, to me, is to try to find a neat way to suppress the warnings without touching the code, and if we can't, wich is probable, we just tell the world : "Yeah, we know this bug, it's not ours and it has no inpact". Anyway, I do not know the official policy for this kind of problem, but I really think we should avoid adding dead code as a workaround for every bug of every supported version of each supported compiler. -- versions: -Python 2.7, Python 3.2, Python 3.4 ___ Python tracker <http://bugs.python.org/issue16588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16588] gcc 4.7 ilegitimate unused-but-set warnings on Python/thread_pthread.h
New submission from Bruno Dupuis:
Looks like #10951, but for another version of gcc.
I get these warnings:
In file included from Python/thread.c:86:0:
Python/thread_pthread.h: In function ‘PyThread_free_lock’:
Python/thread_pthread.h:304:17: attention : variable ‘error’ set but not used
[-Wunused-but-set-variable]
Python/thread_pthread.h: In function ‘PyThread_acquire_lock_timed’:
Python/thread_pthread.h:335:17: attention : variable ‘error’ set but not used
[-Wunused-but-set-variable]
Python/thread_pthread.h: In function ‘PyThread_release_lock’:
Python/thread_pthread.h:386:17: attention : variable ‘error’ set but not used
[-Wunused-but-set-variable]
I tried to remove the variables, but the build crash as they are used in
#define CHECK_STATUS(name) if (status != 0) { perror(name); error = 1; }
looks like a gcc 4.7.2 bug.
--
components: Build
messages: 176737
nosy: bruno.dupuis
priority: normal
severity: normal
status: open
title: gcc 4.7 ilegitimate unused-but-set warnings on Python/thread_pthread.h
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue16588>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Changes by Bruno Dupuis : Added file: http://bugs.python.org/file28175/warnings_opt_parse_API-7.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: corrected, I changed the name of the function to parse_option, and I kept WarningsOptionParsingError as a name for the exception. These two sound good together. -- Added file: http://bugs.python.org/file28174/warnings_opt_parse_API-6.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1075356] exceeding obscure weakproxy bug
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue1075356> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: Changes made. I added the exception doc and some cosmetics -- Added file: http://bugs.python.org/file28173/warnings_opt_parse_API-5.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2921] enable embedding: declare/#define only py* symbols in #includes
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue2921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6036] Clean up test_posixpath.py
Bruno Dupuis added the comment: Mark, correct, this test doesn't exist in 3.X branches. I updated the patch for 2.7. It is trivial, so if someone may merge it, we could close this bug (please, before next SCM switch :-) ) -- nosy: +loewis Added file: http://bugs.python.org/file28170/6036_test_posixpath_cleanup_2.7.patch ___ Python tracker <http://bugs.python.org/issue6036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set
Bruno Dupuis added the comment: Thank you for the review, Guilherme. -- ___ Python tracker <http://bugs.python.org/issue10259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12891] Clean up traces of manifest template in packaging
Bruno Dupuis added the comment: Ok, thanks, Èric. -- ___ Python tracker <http://bugs.python.org/issue12891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6036] Clean up test_posixpath.py
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue6036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10259] Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set
Bruno Dupuis added the comment: I updated the script to 3k. Now the behaviour is very odd : Python 2.7: works only if `justify="right"` is commented out. Python 3.3: Shroedinger-like behaviour (sometimes dead, sometimes alive, nobody knows before we check) whith `justify="right"` Looks like some kind of race-condition or something, so this results may only be relevant on my hardware (2 yo low-end PC). I'm not a tkinter expert, so even if the app code looks good I need someone that knows tk to double-check if there is some oddities in the script before we go further. -- nosy: +bruno.dupuis, gpolo versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 2.6 Added file: http://bugs.python.org/file28163/Project5_3k.py ___ Python tracker <http://bugs.python.org/issue10259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12891] Clean up traces of manifest template in packaging
Bruno Dupuis added the comment: Sounds easy even though there's quite a bit of lines to impact. I may do it, I just need a go. Tarek? Éric? anyone? -- nosy: +bruno.dupuis versions: -3rd party ___ Python tracker <http://bugs.python.org/issue12891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6835] doctest problem with decorated function when decorator is defined in separate file
Bruno Dupuis added the comment: it's a duplicate of #1108 -- ___ Python tracker <http://bugs.python.org/issue6835> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6835] doctest problem with decorated function when decorator is defined in separate file
Bruno Dupuis added the comment:
updated the test to 3k (requires sh and Python2.{6,7} as python2). It works.
Anyone to close?
--
nosy: +ezio.melotti, michael.foord
Added file: http://bugs.python.org/file28162/mytest3k.sh
___
Python tracker
<http://bugs.python.org/issue6835>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6835] doctest problem with decorated function when decorator is defined in separate file
Changes by Bruno Dupuis : -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue6835> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16049] Create abstract base classes by inheritance rather than a direct invocation of __metaclass__
Bruno Dupuis added the comment: This solution hides the risk of metaclass conflicts, as the user did not explicitly set the metaclass. IMO, this risk should be clearly told in the Doc. -- nosy: +bruno.dupuis ___ Python tracker <http://bugs.python.org/issue16049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Changes by Bruno Dupuis : -- hgrepos: +161 Added file: http://bugs.python.org/file28160/warnings_opt_parse_API-4.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: Ok, changes made. I also updated the tests -- Added file: http://bugs.python.org/file28158/warnings_opt_parse_API-3.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: Éric, I saw the `review` link just after I submited the second patch, and I read your comments. I'll do the changes. Sorry, I still have to learn the tools and processes. -- ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: I added the documentation with a recipe. -- Added file: http://bugs.python.org/file28154/warnings_opt_parse_API-2.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: Thanks, I'll write the doc. Now, I'm not sure that keeping _OptionError as WarningsOptParsingError base class is a good idea. I can't see any use case to catch this exception outside the module and I'm quite sure nobody ever has. However, I tend to be over-conservative when it comes to backward-compatibility, even for underscore names. -- ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Bruno Dupuis added the comment: Patch attached. I just exposed _setoption() as process_option() so that the user can manage execptions as she wants but she has to make his own loop. `_OptionError` is exposed as `WarningsOptParsingError`. I'm not satisfied with this name as it is quite long and it contains "Warning" which is bad for something that raise and is not actually a warning. If someone has a better idea... Anyway, I wrote a test case, and I'll write a short reciepe in the doc when the patch is good. It's my very first patch for Python. Be rude, please :) -- keywords: +patch nosy: +lisael Added file: http://bugs.python.org/file28153/warnings_opt_parse_API.patch ___ Python tracker <http://bugs.python.org/issue7976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
