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
Changes by Bruno Dupuis bdup...@lisael.org:
Added file: http://bugs.python.org/file28240/16049.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16049
Changes by Bruno Dupuis bdup...@lisael.org:
Removed file: http://bugs.python.org/file28239/16049.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16049
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
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
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 rep...@bugs.python.org
http://bugs.python.org/issue7976
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 rep...@bugs.python.org
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 rep...@bugs.python.org
http://bugs.python.org/issue7976
Changes by Bruno Dupuis bdup...@lisael.org:
--
hgrepos: +161
Added file: http://bugs.python.org/file28160/warnings_opt_parse_API-4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7976
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 rep...@bugs.python.org
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6835
___
___
Python-bugs-list
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 rep
Bruno Dupuis added the comment:
it's a duplicate of #1108
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6835
___
___
Python-bugs-list mailing
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 rep...@bugs.python.org
http
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
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6036
___
___
Python-bugs-list
Bruno Dupuis added the comment:
Ok, thanks, Èric.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12891
___
___
Python-bugs-list mailing list
Bruno Dupuis added the comment:
Thank you for the review, Guilherme.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10259
___
___
Python-bugs
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
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2921
___
___
Python-bugs-list
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 rep...@bugs.python.org
http://bugs.python.org/issue7976
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1075356
___
___
Python-bugs-list
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
Changes by Bruno Dupuis bdup...@lisael.org:
Added file: http://bugs.python.org/file28175/warnings_opt_parse_API-7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7976
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
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
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
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
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 rep...@bugs.python.org
http
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
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
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue887237
___
___
Python-bugs-list
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11299
___
___
Python-bugs-list
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15045
___
___
Python-bugs-list
Changes by Bruno Dupuis bdup...@lisael.org:
--
nosy: +bruno.dupuis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294232
___
___
Python-bugs-list
35 matches
Mail list logo
