Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I won't have time to work on this. It would also be an option to do
these checks in test_capi.
--
resolution: -> later
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Since this is 2.7 and an exotic system, I'm removing myself from the nosy list.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue18777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
The HP-UX issue is fixed. Are we leaving this open for IRIX?
--
___
Python tracker
<http://bugs.python.org/issue16442>
___
___
Pytho
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue3539>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
The original problem is fixed, but a similar one exists with
testembed (see msg113305 for instructions):
gcc -pthread -Xlinker -export-dynamic -o Modules/_testembed
Modules/_testembed.o libpython3.5dm.a -lpthread -ldl -lutil -lm
gcc: error: Modules
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue12619>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16124>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
This is actually a lot of work, I don't think I'll have time for it.
Please just reopen if you think there's a chance that someone will take the
task.
--
resolution: -> wont fix
stage: -> resolved
s
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
memoryobject.c is converted with a minimal patch (I would like to keep
100% code coverage for the file).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue20
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16442>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue18061>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue19463>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue15989>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20015>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue19533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue19531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
This might be out of date: _decimal has never implemented alternate
formatting and so far there have been no reported issues.
Another data point: Go apparently implements alternate formatting
only for octal, hex and strings:
http://golang.org/pkg/fmt/
So I
Stefan Krah added the comment:
OverflowError vs. ValueError is a debatable issue (msg215873). In my
view ValueError should be raised in most of the cases.
I do not see anything wrong with the docs though, since the link
you posted talks about "arithmetic operations".
--
no
Stefan Krah added the comment:
While NumPy is of course not normative, this is what they do:
>>> numpy.random.triangular(left=1, right=2, mode=0)
Traceback (most recent call last):
File "", line 1, in
File "mtrand.pyx", line 3218, in mtrand.RandomState.tri
Stefan Krah added the comment:
Hi Andrew. Did you by any chance sign the contributor agreement?
[It's perfectly okay if you don't want to, but then we cannot use
the patch from #20230.]
--
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
Sunny, is there a definition of "visible positional fields"? Currently,
it seems to me that in os.stat_result we have the opposite problem, namely
"visible non-positional" fields:
For example, st_atime_ns is visible but not indexable:
os.stat_
Stefan Behnel added the comment:
I tried the same with a Cython compiled version of select.py in the latest
CPython 3.5 build. It pretty clearly shows that select2 is pretty much always
faster than sorting, by a factor of 2-5x or so. I'll also attach the annotated
source file that C
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file35427/select.html
___
Python tracker
<http://bugs.python.org/issue21592>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
Here's also the pathological "average of three calls" case. As Steven suggests,
it shows that select() suffers quite heavily (algorithmically), but select2()
also suffers enough to jump up to about 2/3 of the runtime of sorting (so it's
s
Stefan Behnel added the comment:
Updating the type declaration file to remove the dependency on the list builtin
and allow arbitrary containers. The test code has this dependency (calls
a.sort()), but the current statistics module in the stdlib does not (calls
sorted()). Timings do not change
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file35430/select.html
___
Python tracker
<http://bugs.python.org/issue21592>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Let's open a new issue for system load detection. This one is not asyncio
specific.
--
resolution: -> not a bug
stage: needs patch ->
status: open -> closed
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
"I ran a quick test with profile-guided optimization (PGO, pronounced "pogo"),
which has supposedly been improved since VC9, and
+saw a very unscientific 20% speed improvement on pybench.py and 10% size
reduction in python35.dll. I'm not sure
Stefan Krah added the comment:
Isn't PyLong_FromUnsignedLongLong() still involved through spec_add_field()?
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
The flags from mb_getbuf() have to be passed to PyBuffer_FillInfo():
return PyBuffer_FillInfo(view, (PyObject *)self,
internal, 5,
/*readonly=*/0, flags);
The flags contain the actual request that the
Stefan Krah added the comment:
Yes, PyBuffer_FillInfo() is a bit confusing: The canonical usage *looks* as
if "flags" were somehow used in the Py_buffer struct to mark a buffer as having
certain capabilities:
Modules/_io/bufferedio.c:
-
if (PyBuffer_Fil
Stefan Krah added the comment:
I think it's worth adding a note to the docs about passing the flags unmodified
inside a getbufferproc.
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
resolution: not a bug ->
stage: -> needs patch
version
Stefan Krah added the comment:
I guess the tests --without-doc-strings are broken:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6900/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
Added file: http://bugs.python.org/file35681/ull_vctest.diff
___
Python tracker
<http://bugs.python.org/issue15993>
___
___
Python-bugs-list m
Stefan Krah added the comment:
> The two issues were unrelated - the 'invalid filter ID'
> (4611686018427387905 == 0x4000_0001) is the correct
> value but the wrong branch in the switch was taken, leading
> to the error message.
Unfortunately I don't have a Vi
Stefan Krah added the comment:
Ramchandra Apte wrote:
> > I'm not quite sure why you're quoting the docs at me. What's the point
> > you want to make?
>
> Does decimal use the dummy_threading module where
> deadlock might occur from a thread being creat
Stefan Krah added the comment:
Isn't IDLE supposed to be a Python shell? As I understand this issue,
you'd have the same "exploit" by adding this to your .bashrc:
echo "EXPLOIT" > /root/exploit
Then, as a normal user, run:
sudo bash
It would be nice to get
Stefan Krah added the comment:
I also don't find the scenario where an attacker has write privileges
to a user's home directory so disturbing -- there are juicier targets
(like .bashrc).
This constructed example using /tmp is a little more troubling:
$ cd /tmp
$ echo '
Stefan Krah added the comment:
Ramchandra Apte wrote:
> Almost nobody knows that when using tkinter, code in .Tk.py is executed.
> (readprofile is not even documented!)
> While in your example, it is quite easy to see that it will run .bashrc
The point of the example is that it
New submission from Stefan Krah:
test_cmd_line_script is failing on multiple buildbots:
==
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest
Stefan Krah added the comment:
Andrew and Serhiy, thanks for the reviews. Should be fixed now.
--
assignee: -> skrah
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://
Stefan Krah added the comment:
Some of the buildbots are failing with the new test:
==
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest)
--
Traceback
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> Python launcher does not support non ascii characters
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
One of 13ebaa36d87d, 9f696742dbda or 6903f5214e99 causes test failures in
test_pep277:
==
FAIL: test_failures (test.test_pep277.UnicodeFileTests
Stefan Krah added the comment:
Additionally, some of the changes cause a failure in test_subprocess:
==
ERROR: test_no_leaking (test.test_subprocess.ProcessTestCase
Changes by Stefan Krah :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Serhiy, your original example from msg173373 still fails on
FreeBSD:
$ name=$(printf "\xff")
$ echo "print('Hello, world')" >$name
$ ./python $name
UnicodeEncodeError: 'ascii' codec can't encode character '\
Stefan Krah added the comment:
This is it:
>>>
>>> sys.getdefaultencoding()
'utf-8'
>>> sys.getfilesystemencoding()
'ascii'
>>> locale.getpreferredencoding(True)
'US-ASCII'
>>> locale.getpreferredencoding(False)
'U
Stefan Krah added the comment:
On FreeBSD both Serhiy's original test case as well as the unit test work
if the locale is ISO8859-15:
>>> sys.getdefaultencoding()
'utf-8'
>>> sys.getfilesystemencoding()
'iso8859-15'
>&g
Stefan Krah added the comment:
That sounds good for Unix.
For Windows I'm getting a more informative error message than from the
buildbot output if I run the test via an ssh c
Stefan Krah added the comment:
Serhiy Storchaka wrote:
> Try with my last patch (pythonrun_filename_decoding_test.patch). It
> fixes also fail on Linux with 8-bit locale.
Unfortunately your last patch does not work on Windows. -- I'm too lazy
to step through the domain specific
Stefan Krah added the comment:
I think this is what went wrong on Windows in the previous test (see
Lib/test/test_cmd_line_script.py:43):
>>> s = '\udcf1\udcea\udcf0\udce8\udcef\udcf2'
>>> f = open(s, "w")
>>> f.write("print('%s\\n
New submission from Stefan Behnel:
After compiling the stdlib with Cython with the attached script, modules that
use circular imports fail to initialise. That includes os and posixpath, as
well as shutil and tarfile. Example:
$ ./python -c 'import shutil'
Traceback (most recent
New submission from Stefan Behnel:
My guess is that line 454 in pkgutil.py should pass "pkg_name" into the
import_module() function, not "pkg". I get the following error when compiling
it with Cython:
Error c
Stefan Behnel added the comment:
Well, it's not like the setup was all that difficult. 1) Install the latest
github master of Cython (they provide one-click archives that pip can install
for you), 2) change into the CPython stdlib directory and run the script I
attached, 3) execute "
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file27865/cystdlibbug.py
___
Python tracker
<http://bugs.python.org/issue16392>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Since it's quite possible that this has nothing to do with the frozen part of
the importlib specifically, I'm removing that bit from the ticket title.
--
title: frozen importlib crashes on circular imports in ext modules -> import
crashe
Stefan Behnel added the comment:
Hmm, we already do that for packages (i.e. when compiling __init__.py). Looks
like this just needs to be done for all modules in Py3. And unless there is a
compelling reason for Py_InitModule4() not to do it, I think it should be
reverted to its Py2 behaviour
Stefan Behnel added the comment:
Now that you mention it - wouldn't that suffer from not actually knowing the
FQMN? There's that hack in the dynlib loader that stores the package context in
a global variable so that the module creation function can figure it out. That
might be a rea
Stefan Behnel added the comment:
The problem is a) that the module does not necessarily know to which place it
eventually gets installed (Cython relies on the distutils Extension not lying
to it, for example, which people do from time to time), and b) that the call to
Py_InitModule() only
Stefan Krah added the comment:
"Would that result in displaying both author and maintainer info on the PyPI
page? For what cases is it useful?"
It gives due credit to the original author if another person maintains
the package. I think it's a matter of common courtesy not to
Stefan Krah added the comment:
Pickling changed in 3.3 to make the C and Python versions compatible. So pickled
contexts in 3.3 are actually interchangeable.
Pickling a list of rounding modes is not compatible.
--
___
Python tracker
<h
Stefan Krah added the comment:
So what data structure are you trying to serialize interchangeably?
--
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
I see that you mentioned the use case in your first mail. Yes, that isn't
possible right now.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
It would be possible to translate strings to integers; the infrastructure
is already there for pickling. The decision not to do that was actually
deliberate: Up to now no one has requested string constants for rounding
modes and I *suspect* that there
Stefan Krah added the comment:
Well, I suppose one could use a cascaded switch statement, starting with the
7th letter and then (in the case of HALF*) proceed with the 12th letter:
"ROUND_CEILING"
"ROUND_FLOOR"
"ROUND_UP"
"ROUND_DOWN"
"ROUND
Stefan Behnel added the comment:
Agreed. Since it doesn't really fit into any specific function documentation, I
would place it right at the top. Something like this:
"""
The following functions can be used by C code to call into Python's import
machinery.
No
Stefan Behnel added the comment:
I'm increasing the target version as this didn't change anything for 3.3.
However, for 3.4, it might be possible to work around this by splitting the
module init function into two parts, one that gets executed in order to create
the module object (a
Stefan Krah added the comment:
Thanks, Amaury. Should be fixed now.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Behnel added the comment:
Triggered discussion on python-dev:
http://thread.gmane.org/gmane.comp.python.devel/135764
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Stuhr added the comment:
I think this is a case of faulty over-engineering in the ttk module. The
following works just fine (imports converted to Python3):
import tkinter as tk
import tkinter.ttk as ttk
root = tk.Tk()
tree = ttk.Treeview(root, columns="1 2 3")
tree.tk
Stefan Krah added the comment:
FWIW, on x86/x64 gcc often generates identical code for x = y and
memcpy(x, y, 8). See e.g. the PACK_SINGLE and UNPACK_SINGLE macros in
Objects/memoryobject.c.
I didn't look at the patch yet, just an
Stefan Krah added the comment:
> The code can be identical, but the time will differ significantly for
> aligned and non-aligned data.
Of course, but in most cases the data *is* aligned, so only code that does
something quite special pays the performance p
Stefan Krah added the comment:
The "Mountain Lion" bots still fail. :)
--
___
Python tracker
<http://bugs.python.org/issue16218>
___
___
Python-bugs-l
Stefan Krah added the comment:
Any programming language that uses binary floats behaves like that
and it is actually what people expect.
If you want behavior that is closer to pencil and paper calculations,
you need to use decimal:
>>> Decimal(1) // Decimal("0.1")
Decimal(
Stefan Krah added the comment:
#15835 has a patch specifically for HP-UX. Also see the link in
msg171068 for evidence that PATH_MAX is quite a mess on HP-UX.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
Thanks for reviewing!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Stefan Neufeind :
--
nosy: +neufeind
___
Python tracker
<http://bugs.python.org/issue11362>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Well, there was a test_circular_imports() failure on (I think) the
Windows-amd64 bot last week, but I can't access it any more.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
I'm not so sure. If dicts or classes are used for configuration
or informational purposes, I prefer them to be locked down.
An example of the first is the decimal context, where it was possible
to write context.emax = 9 instead of context.Emax = 9 without ge
Changes by Stefan Krah :
--
title: re.grupindex available for modification and continues to work, having
incorrect data inside it -> re.groupindex available for modification and
continues to work, having incorrect data inside it
___
Python trac
Stefan Krah added the comment:
Should we go ahead with this? If so, then I think it only makes sense
to change *all* undocumented cases of None default args. Here's a
case that used rounding=None in quantize():
https://bitbucket.org/simplecodes/wtforms/issue/117/test-failure-with-pyth
Stefan Krah added the comment:
By "all cases" I mean the ones listed in msg169144, not the Number methods.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
OK, here's a patch. Specifics:
o Except for the number methods, decimal.py and _decimal should behave
identically now.
o _decimal actually requires an additional context arg in same_quantum(),
compare_total(), compare_total_mag() and copy_sign().
Stefan Krah added the comment:
New patch with docs. I've eliminated the unused context arg from canonical(). I
can't possibly imagine that anyone uses it (or
that anyone uses canonical() at all for that matter).
--
Added file: http://bugs.python.org/file28009/issue15783-
Stefan Krah added the comment:
I don't particularly like OverflowError in any situation where the
potential overflow is detected *before* it actually happens. This is
another example:
>>> x = [1]*
Traceback (most recent call last):
File "", l
Stefan Krah added the comment:
Mark, there's a small typo in the patch: "preseve the usual identity"
--
nosy: +skrah
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
Is PY_UINT32_T a big problem? I hope that one day we can use the
C99 types directly. Visual Studio finally supports stdint.h, and
I'm not aware of any compiler that does not.
Consider cdecimal as a trial balloon: It compiles on all obscure
snakebite platforms
Stefan Krah added the comment:
The deeper issue is that globals in unicodeobject.c are used before
they are initialized. So I thought that should be cleared up before
the next release.
Basically, strings are used as keys during type initializations
*before* _PyUnicode_Init() is called
Stefan Krah added the comment:
Fixed in 2.7, 3.3 and 3.4.
--
keywords: +buildbot
nosy: +skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Not that it helps much, but here are recent failures on
Windows and FreeBSD:
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5938/steps/test/logs/stdio
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5936/steps/test/logs
Stefan Krah added the comment:
I think I fixed this yesterday in #6308. Please try with a current 2.7,
3.3 or 3.4 clone.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue14
Stefan Krah added the comment:
Closing, since this is fixed on the buildslave.
--
components: +Extension Modules -Build
keywords: +buildbot
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> termios fix for QNX break
New submission from Stefan Krah:
There's an error on the HPUX-IA64 buildbot that might be due to
some kernel limits. Trent, could you check if the following helps
(requires root)?
http://zensonic.dk/?p=326
test_forkinthread (test.test_thread.TestForkInThread) ... Fatal Python error:
In
3001 - 3100 of 4952 matches
Mail list logo