Daniel Stutzbach dan...@stutzbachenterprises.com added the comment:
Since this issue doesn't apply in Python 3 and (as I understand it) the 2.7
branch is only open to bug fixes, can we close this performance issue?
--
nosy: +stutzbach
___
Python
Changes by Brett Cannon br...@python.org:
--
resolution: - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5362
___
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Both msg98465 and msg98466 agree that this should not be a configuration
variable. I think a new patch is needed which follows the suggested solutions
from the two messages given.
--
nosy: +BreamoreBoy
Antoine Pitrou pit...@free.fr added the comment:
Given the very small benefits, I don't think there's any point in making this a
configuration variable. A hardcoded flag would be sufficient, and expert users
would be able to recompile their Python (as with the FAST_LOOPS flag).
--
Marc-Andre Lemburg m...@egenix.com added the comment:
I'm with Antoine on this one.
Also, instead of removing the flag completely which will cause problems with
extensions relying on it, I'd suggest to just disable the PyErr_WarnPy3k(msg,
stacklevel) macro and turn it into a no-op if a
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
priority: - normal
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5362
___
Collin Winter coll...@gmail.com added the comment:
Jeffrey: updated the patch to address your concerns.
Martin: I'm not sure I completely understand it either, though it seems
similar to issue4477. In the course of developing this patch, I tried
also #ifdef'ing out all usages of the
Changes by Collin Winter coll...@gmail.com:
Removed file: http://bugs.python.org/file13168/no_py3k_warning.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5362
___
Collin Winter coll...@gmail.com added the comment:
Bah, forgot to run autoreconf. Fixed.
Added file: http://bugs.python.org/file13184/no_py3k_warning.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5362
Changes by Collin Winter coll...@gmail.com:
Removed file: http://bugs.python.org/file13183/no_py3k_warning.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5362
___
New submission from Collin Winter coll...@gmail.com:
The attached patch adds a --with-py3k-warnings option to configure.
Passing --without-py3k-warnings disables all Py3k compatibility warnings
(the default is to keep the warnings). For production deployments where
performance is more important
Martin v. Löwis mar...@v.loewis.de added the comment:
I would like to understand the problem better first. I find it hard to
believe that mere access to a global (even if frequent) costs so much. I
think we should strive to make the warnings check faster if it indeed
produces significant runtime
Jeffrey Yasskin jyass...@gmail.com added the comment:
s/Leaving/Turning/ in configure.in.
It looks like the convention for other --with flags that default to
enabled is to document them as --with(out)-xxx. (except tsc...) I guess
it's probably even better just to say what the default is in the
13 matches
Mail list logo
