Mark Dickinson dicki...@gmail.com added the comment:
Fixed in revisions r82654 through r82657. Thanks everyone for the input.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
I don't quite understand the point of catching NameError here
So that the initialization of DefaultContext itself doesn't fail.
--
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Alexander, for me the ternary expressions have the advantage that they
take up less vertical space and you have to keep less state in mind.
Mark, I'm sidestepping the dict syntax question and reassign to you :)
--
assignee:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
+try:
+dc = DefaultContext
+except NameError:
+pass
+
+self.prec = dc.prec if prec is None else prec
I don't quite understand the point of catching NameError here, but it
Mark Dickinson dicki...@gmail.com added the comment:
2.5 compatibility is fine for the 2.x version of decimal.py.
For the 3.x version of decimal.py, I don't see what it buys us.
--
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
Removed file: http://bugs.python.org/file17831/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9136
___
Stefan Krah stefan-use...@bytereef.org added the comment:
In the new patches I reinstated the ternary construct. I think it
would be nice to use dict comprehensions in py3k. People read the
stdlib for guidance, and it would help if ultimately only the most
concise idioms remained in py3k.
If
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file17837/issue9136-trunk-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9136
___
Mark Dickinson dicki...@gmail.com added the comment:
I can't reproduce this on Linux. However, I've seen an informal report of
something like this happening before. It looks a lot like something threading
related, but I don't see any threads in what you're doing. (Though I don't
know the
Mark Dickinson dicki...@gmail.com added the comment:
BTW, is the behaviour consistent, or does it only occur on some runs?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9136
___
Mark Dickinson dicki...@gmail.com added the comment:
Okay, I can reproduce by adding a 'time.sleep(0.01)' delay into the body of the
'for name, val in locals().items():' loop. I then get (with py3k):
dicki...@alberti:~/Source/py3k ./python
Python 3.2a0 (py3k:82413M, Jul 1 2010, 10:21:02)
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
I can't reproduce this on Linux. However, I've seen an informal report of
something like this happening before. It looks a lot like something
threading related, but I don't see any
Mark Dickinson dicki...@gmail.com added the comment:
Removing the decimal module from the equation, the following is enough to
trigger this for me. Stefan's suggestion about the profile module writing to
locals sounds right on target.
import profile
class Context(object):
def
Mark Dickinson dicki...@gmail.com added the comment:
class Context(object):
def __init__(self):
for name, val in locals().items():
setattr(self, name, val)
Isn't this dodgy anyway, since 'name' and 'val' end up going into locals()? I
wonder why the RuntimeError
Stefan Krah stefan-use...@bytereef.org added the comment:
Still clueless about profile.py, but I think it creates a parallel stack,
and overwriting of locals legitimately occurs in that stack, producing
the Exception.
So it would appear that by design one simply cannot iterate over locals
when
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
class Context(object):
def __init__(self):
for name, val in locals().items():
setattr(self, name, val)
Stefan Krah stefan-use...@bytereef.org added the comment:
The tracker doesn't handle code when posted by mail. Here's the
code again:
for name, val in locals().items():
... print(locals())
...
{'name': '__builtins__', 'val': module 'builtins' (built-in), '__builtins__':
module 'builtins'
Mark Dickinson dicki...@gmail.com added the comment:
Ah, it looks like 'locals()' is somewhat magical. Its docstring says:
Update and return a dictionary containing the current scope's local variables.
So I think this explains your (Stefan's) results: in either case, you evaluate
locals()
Mark Dickinson dicki...@gmail.com added the comment:
it looks like 'locals()' is somewhat magical
... and Objects/frameobject.c is the place to go for a full understanding.
PyFrame_FastToLocals is the 'updating' function that updates the locals dict
from the 'fast locals' object.
Mark Dickinson dicki...@gmail.com added the comment:
Here's a patch. It's a little ugly, but I don't see a better way that avoids
locals(). Using **kwargs is an option, but would mean abandoning the current
nice feature that unexpected keyword arguments raise TypeError (or
alternatively,
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, the patch looks good. I don't find it ugly, but anyway, here's a
bike shed version. :)
The main point is that I'd like the flags and traps sections to be
set apart visually while compressing the boilerplate.
--
Added file:
Mark Dickinson dicki...@gmail.com added the comment:
Nice shade of blue! Just a couple of red spots that I'd prefer repainted,
namely: (1) please put bodies of 'try:' and 'except:' on separate lines, and
(2) please use 'except NameError' instead of a bare except.
And a couple of points that
Mark Dickinson dicki...@gmail.com added the comment:
Stefan, one other thought: please also bear in mind that we're restricted to
Python 2.3 syntax in the 2.x version of decimal, so any post-Python 2.3-isms
will have to be rewritten when the patch is backported. (E.g., use of
conditional
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, good point about 2.3 compatibility. The unit tests diverge quite a
bit though between 2.5, 2.6 and 2.7.
I like {s: 0 for s in _signals} slightly better here (but I like
dict/list comprehensions in general).
So, the new patch
Mark Dickinson dicki...@gmail.com added the comment:
Looks good to me. Please go ahead and apply it to the 3.2 and 3.1 branches, if
you want. (Or just assign back to me if you prefer.)
It should also be applied to 2.7 and 2.6, eventually, but we should probably
wait until after the 2.7
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Stylistically, it would be nice to eliminate the local variable reassignment
entirely:
self.Emin = DefaultContext.Emin if Emin is None else Emin
self.Emax = DefaultContext.Emax if Emax is None else Emax
self._ignored_flags =
Mark Dickinson dicki...@gmail.com added the comment:
[Raymond]
self.Emin = DefaultContext.Emin if Emin is None else Emin
I agree that looks better. But we can't spell it that way in 2.x (since
conditional expressions aren't 2.3 compatible), and I'd prefer to keep the 2.x
and 3.x versions
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I'm not sure that I care about 2.3 compatibility anymore (I was the one who
made the rule about 2.3 compatibility and made sure that it was just a
preference, not an absolute rule -- as time goes on, it is of less and less
Mark Dickinson dicki...@gmail.com added the comment:
ISTM, 2.5 compatible is probably good enough.
Okay; that's fine with me. Now we can finally turn that from_float =
classmethod(from_float) into a proper @classmethod decorator. :)
I also don't think that the 2.x-to-3.x maintenance issue
Yuv Gre ubershme...@gmail.com added the comment:
Now that we're on the subject of from_float, I just recalled this slight
issue:
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)]
on
win32
Type help, copyright, credits or license for more information.
import decimal
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I also don't think that the 2.x-to-3.x maintenance issue
is that big a deal any more; it would be surprising if
the 2.x version of Decimal sees anything more than minor
changes (doc fixes, etc.) from this point on. So
New submission from Yuv Gre ubershme...@gmail.com:
I'm using Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
(Intel)] on win32. Running the following code:
import profile
import math
import decimal
def show_bug():
x =
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti, mark.dickinson
stage: - unit test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9136
___
33 matches
Mail list logo
