New submission from Eric Fahlgren :
Windows 10 Pro 64
Python 3.8.3 64
wxPython 4.1.0
It appears that there are synthetic classes in the mro, which don't appear in
the type's namespace, raising KeyError when encountered. From reading the
function's doc and source, it looks like it should
New submission from Eric Fahlgren :
Python 3.8's new math.hypot function also appears to suffer from the same issue
as math.log:
>>> import math, inspect
>>> inspect.signature(math.hypot)
Traceback (most recent call last):
File "", line 1, in
File &q
Eric Fahlgren added the comment:
Thanks, I installed 3.7.2 on one of our non-production machines and it appears
that gettext has been fixed, so I'm closing this.
> python -V
Python 3.7.2
> python bpo35785.py --foo
usage: bpo35785.py [-h] [--foo FOO]
bpo35785.py: error: argument
Eric Fahlgren added the comment:
After a bit more digging, it's a side effect of having the locale set with
'Plural-Forms'. I've attached the resulting .mo file, but since it's a binary,
I'm not sure it will work cross-platform, so here's how to recreate it.
> cat en_US/LC_MESSAGES/foo
New submission from Eric Fahlgren :
When argparse is configured with an option that takes arguments, then the
script is invoked with the switch but no arguments, a nonsensical exception is
raised during gettext processing.
In the 3.7.1 source, the error is at line 2077 of argparse.py, where
Change by Eric Fahlgren :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue35785>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Fahlgren added the comment:
I believe that the CL command line switch is /FC, not /FP:
https://msdn.microsoft.com/en-us/library/027c4t2s.aspx
--
nosy: +eric.fahlgren
___
Python tracker
<https://bugs.python.org/issue34
Eric Fahlgren added the comment:
So maybe add the dpiAware and dpiAwareness settings to the manifest for just
Windows' pythonw.exe and leave the python.exe console interpreter alone? I'm
going to guess that the pythonw.exe manifest already has some settings related
to its unique status
Eric Fahlgren added the comment:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt748620(v=vs.85).aspx
gives the syntax for adding dpiAwareness to the Windows manifest.
--
nosy: +eric.fahlgren
___
Python tracker
<https://bugs.python.
Eric Fahlgren added the comment:
I used the default Application setting.
--
___
Python tracker
<https://bugs.python.org/issue26698>
___
___
Python-bugs-list m
Eric Fahlgren added the comment:
Still blurry with 3.6.5 on Win 10 with a 2560x1600 monitor at 125% scaling (I
compared it to 2.7.15, they looked identical). If I go to the Windows
properties for pythonw.exe and turn on "Override high DPI scaling behavior"
it's nice
Eric Fahlgren added the comment:
Would it be appropriate to make a comment about this Windows bug in both
os.stat and os.path.exists documentation? I just stumbled upon it
independently (both Win7 and 10, both Py 2.7 and 3.6) with nearly the same
incantation that Kenneth reported over 10
Changes by Eric Fahlgren <ericfahlg...@gmail.com>:
--
nosy: +eric.fahlgren
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29282>
___
Eric Fahlgren added the comment:
> # Junctions are not recognized as links.
> self.assertFalse(os.path.islink(self.junction))
If the above comment is intended as a statement of fact, then it's inconsistent
with the implementation of Py_DeleteFileW (
https://hg.python.org/cpytho
Eric Fahlgren added the comment:
Thanks, Serhiy. I sort of figured that it would get fixed with the
wordcode rework, and was going to verify that it was when 3.6 settled down.
On Sun, Jun 5, 2016 at 8:30 AM, Serhiy Storchaka <rep...@bugs.python.org>
wrote:
>
> Serhiy Sto
Changes by Eric Fahlgren <ericfahlg...@gmail.com>:
--
nosy: +eric.fahlgren
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27129>
___
Changes by Eric Fahlgren <ericfahlg...@gmail.com>:
--
nosy: +eric.fahlgren
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22893>
___
Eric Fahlgren added the comment:
Barun, take a look at the latest version of the testfindlabels.py, see what you
think. If it works for you, maybe move the test function into
Lib/test/test_dis.py as part of the standard dis module tests. Still need to
look at the code that's being tested
Eric Fahlgren added the comment:
Oops, wrong/bad patch, delete line 310 "arg = None" in _get_instruction_bytes...
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric Fahlgren added the comment:
Two things:
1) Verified this has always been a problem and still is in the development
branch, so I added 2.7 and 3.6 to the versions list.
2) Couldn't tolerate the duplicate code handling the extended args operator, so
in the interests of DRY, I moved
Eric Fahlgren added the comment:
I just remembered that code can have more than one (up to three?) EXTENDED_ARG
operators before the real opcode, so I added that generalization to build code
around the args list...
--
Added file: http://bugs.python.org/file42046/testfindlabels.py
Eric Fahlgren added the comment:
Oh, don't worry about time between responses, we all have lives (well, some of
us anyhow :) ).
After looking at Lib/test/test_dis.py, I think it's just an oversight that
there is no specific findlabels test (it's tested implicitly by ``dis.dis``
after all
Eric Fahlgren added the comment:
Lookin' good so far. How about we try it on all the opcodes that have
arguments?
See attached example for which I can see two obvious improvements:
1) It could be improved by taking apart that "args" list and using it to
synthesize "sample_co
Eric Fahlgren added the comment:
The findlabels function takes a bytecode array of type bytes, usually the
actual code from a function. My original test case uses the full Python
compiler from source code to a CodeType object to create the bytecodes
(plus all that other stuff that makes up
Eric Fahlgren added the comment:
Well, now that I'm thinking about it, you could synthesize a bytecode stream
trivially and have a much better test. This is completely off the top of my
head, so take it is guaranteed to (probably) not work as written, but it should
get you started:
from
Eric Fahlgren added the comment:
Our paths crossed, I don't know exactly how you'd add a test case for this,
maybe construct the monster function in a string, eval the string, the use the
synthesized function in dis.findlabels?
--
___
Python
Eric Fahlgren added the comment:
My test case:
def long():
z = a = b = c = d = e = f = g = h = 1
while x:
x = x if x and x or not x else x
above line repeated 2999 more times
import dis
print(dis.findlabels(long.__code__.co_code)[:10])
Buggy output:
[35510, 35509, 62
New submission from Eric Fahlgren:
When trying out dis.dis on some synthetically long functions, I noted that
spurious branch targets were being generated in the output. First one is at
address 8:
157 0 LOAD_CONST 1 (1)
3 DUP_TOP
4
Changes by Eric Fahlgren <ericfahlg...@gmail.com>:
--
nosy: +eric.fahlgren
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26110>
___
Changes by Eric Fahlgren <ericfahlg...@gmail.com>:
--
nosy: +eric.fahlgren
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26252>
___
30 matches
Mail list logo
