New submission from Marc Schlaich:
Platform: Windows 7 64 bit
Interpreter: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit
Intel)] on win32
Here are the steps to reproduce:
1. Create a big file (5 GB):
with open('big', 'wb') as fobj:
for _ in xrange(1024 * 1024 * 5
Marc Schlaich added the comment:
I get the same result from `getaddrinfo` if Python is compiled with
`--disable-ipv6`. Is this the correct behaviour? I would expect no IP v6
address at all.
Python 2.5.6 (r256:88840, Jan 22 2013, 08:41:04)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type
Marc Schlaich added the comment:
Ok, I found #16208, just ignore me :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8858
___
___
Python-bugs
Marc Schlaich added the comment:
I agree with schmir, this is really unexpected behavior. At least it should be
fixed in the documentation. The doc currently says you get a 4-tuple for IPv6,
which is just wrong in this case.
Prominent library stumbled about this issue is Tornado
(https
Marc Schlaich added the comment:
I'm +1 for a warning. The current behavior is really unexpectable:
In [6]: sorted([nan, 0, 1, -1])
Out[6]: [nan, -1, 0, 1]
In [7]: sorted([0, 1, -1, nan])
Out[7]: [-1, 0, 1, nan]
In [8]: sorted([0, nan, 1, -1])
Out[8]: [0, nan, -1, 1]
--
nosy
New submission from Marc Schlaich marc.schla...@googlemail.com:
Here is a short example to reproduce the error:
import socket, ssl
sock = socket.socket()
sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_REQUIRED, ca_certs=u'ä.crt')
sock.connect((None, None))
Traceback (most recent call last
Marc Schlaich marc.schla...@googlemail.com added the comment:
Well, the Unicode HOWTO states:
When opening a file for reading or writing, you can usually just provide the
Unicode string as the filename, and it will be automatically converted to the
right encoding for you
This is really
Marc Schlaich marc.schla...@googlemail.com added the comment:
For example it is broken in the well known requests library:
import requests
requests.get('x', cert=u'öäü.pem')
Traceback (most recent call last):
File stdin, line 1, in module
...
UnicodeEncodeError: 'ascii' codec can't encode
New submission from Marc Schlaich marc.schla...@googlemail.com:
It is very simple to reproduce this error.
There is an executable package:
package/
__init__.py
__main__.py
The __init__ imports a missing module:
import missing_module
And the __main__ imports from it:
from
New submission from Marc Schlaich:
I'm running unittests on a CentOS 6.4 Virtual Box slave via Jenkins on a
Windows host. Randomly I get core dumps for no obvious reason. I don't
use any C extension in my code and don't use ctypes. The (proprietary)
software is plain Python with a multi
Marc Schlaich added the comment:
Yes, I could reproduce segfaults on Python 2.7 (looks like it is even worse
than on 2.6 where it appeared only randomly).
I was not quite accurate in my initial comment. I don't use any custom C
extensions but I'm using pygtk/gobject so it might be a bug
Marc Schlaich added the comment:
The generator.patch from #14432 didn't help. The other couldn't be applied to
2.7.
I have a core dump, should I upload it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18683
New submission from Marc Schlaich:
My System:
$ python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import sqlite3
sqlite3.version
'2.6.0'
sqlite3.sqlite_version
'3.6.21'
Test Script
Marc Schlaich added the comment:
Ok, these issues were probably due to the shipped version of PyGTK (which is
used as event scheduler). Since I built my own Python and own PyGTK everything
looks fine.
--
resolution: - invalid
status: open - closed
Marc Schlaich added the comment:
Ah that's great. The issue is resolved with SQLite 3.8.1.
However, would be great if a newer SQLite version comes already bundled with
Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Marc Schlaich added the comment:
This issue is not fixed. Another workaround would be the `win32select` function
from twisted:
http://twistedmatrix.com/trac/browser/trunk/twisted/internet/selectreactor.py#L23
--
nosy: +schlamar
___
Python tracker
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: -schlamar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue777588
___
___
Python
New submission from Marc Schlaich:
Steps to reproduce:
- clone pytest-cov at
https://bitbucket.org/schlamar/pytest-cov/commits/ac14225a67d715b6649f8158e05d2389b78620d2
- remove `@pytest.mark.skipif` from `test_multiprocessing_subprocess` in
test_pytest_cov.py
- run: `tox --develop -e py27
Marc Schlaich added the comment:
Patch added.
--
keywords: +patch
Added file: http://bugs.python.org/file34453/Issue20954.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Marc Schlaich added the comment:
This comes from http://bugs.python.org/issue12098. Python 3.3 is affected, too.
Reproduction can be minimized by running the following script:
import multiprocessing
def main():
p = multiprocessing.Process(target=lambda: None)
p.start()
p.join
Marc Schlaich added the comment:
Added TestCase.
--
Added file: http://bugs.python.org/file34459/20954_test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Marc Schlaich added the comment:
BTW, patches are for 2.7 branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
___
___
Python-bugs-list
Marc Schlaich added the comment:
Merged test case and fix in a single commit/patch.
--
Added file: http://bugs.python.org/file34460/Issue20954.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: -schlamar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Python-bugs
Changes by Marc Schlaich marc.schla...@googlemail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20954
___
___
Python-bugs
Marc Schlaich added the comment:
This was fixed in #19284 for Python 3.4 (without having possible consequences
in mind). I have updated my patch accordingly.
Maybe it's worth to port my test case to Python 3.4.
Removed Python 3.3 as it isn't in bugfix maintenance anymore.
--
versions
Marc Schlaich added the comment:
I can reproduce this one. There are a few conditions which needs to be met:
- Linux line endings
- File needs to have at least x lines (empty lines are fine). I guess this is
the point why no one could reproduce it. The attached file has 19 lines but
probably
New submission from Marc Schlaich:
multiprocessing.util.register_after_fork does not behave consistently on
Windows because the `_afterfork_registry` is not transferred to the subprocess.
The following example fails on Windows while it works perfectly on Linux:
import multiprocessing.util
Marc Schlaich added the comment:
Your statement is not correct, it does work on Windows (where fork is not
available) if you register the hook on module level instead of in `__main__`.
--
___
Python tracker rep...@bugs.python.org
http
Marc Schlaich added the comment:
I've now run various and partially complex applications including SQLAlchemy
against SQLite 3.8.1 for months without having any issues. Right now I have run
extensive database test suites against the current SQLite release 3.8.6 without
any issues, too.
So I
Marc Schlaich added the comment:
Yes, but this is no practical solution. Telling *all* my clients to update the
sqlite3.dll after *every* Python update is just not feasible and will just not
work out in practice.
What would be the required steps to update the *.dll in the build? Just update
Marc Schlaich added the comment:
Well, OSX release ships with 3.8.3.1, too:
https://hg.python.org/cpython/file/2.7/Mac/BuildScript/build-installer.py#l290
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19450
Marc Schlaich added the comment:
AFAIS this would break all existing code for yield-based coroutine schedulers
(Tornado, Twisted, Trollius, monocle, ...) when a coroutine is exited with
`raise StopIteration` in client code.
And this seems like a lot, a quick GitHub code search gives various
Marc Schlaich added the comment:
Yes, all yield-based coroutines are generators. I know that there is a backward
compatible upgrade path, but this might have a huge impact on existing code.
Interestingly, I didn't know before researching this PEP that you can actually
use `return` without
Marc Schlaich added the comment:
This issue is not fully fixed, there are some occasions where you can still run
into it. One example is if you want to spawn a new multiprocessing.Process as
sub process in a multiprocessing.Process:
pythonservice.exe
- multiprocessing.Process
Marc Schlaich added the comment:
Please fix this. Scripts with multiprocessing bundled as wheels are broken with
Python 2.7 on Windows: https://github.com/pypa/pip/issues/1891
--
nosy: +schlamar
___
Python tracker rep...@bugs.python.org
http
Marc Schlaich added the comment:
I'm still +1 for an update in 2.7 as there are a lot of important bug fixes and
a new SQLite version is 100% backwards compatible for my medium to big size
(SQLAlchemy) SQLite applications.
--
___
Python tracker rep
Marc Schlaich added the comment:
I'm attaching those bad files.
--
Added file: http://bugs.python.org/file41378/PatternGrammar2.7.11.final.0.pickle
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Marc Schlaich <marc.schla...@googlemail.com>:
Added file: http://bugs.python.org/file41379/Grammar2.7.11.final.0.pickle
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Marc Schlaich added the comment:
The issue is in Grammar2.7.11.final.0.pickle or
PatternGrammar2.7.11.final.0.pickle. I have copied these files to my manually
built Python and getting the same issue in this case.
--
___
Python tracker <
Marc Schlaich added the comment:
After deleting them, they are getting recreated and everything works now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Marc Schlaich:
This simple test case results in a lib2to3 crash with an AssertionError in
2.7.11
source = '''
class Test(object):
tests = []
'''
from lib2to3.refactor import RefactoringTool
def main():
tool = RefactoringTool([])
tool.refactor_string
Marc Schlaich added the comment:
Not sure. Somehow I got these corrupted files just by upgrading to 2.7.11. It
might be that they are not getting updated when installing 2.7.11 over an
existing 2.7.10. So maybe it's worth to investigate further as others could be
affected, too
Marc Schlaich added the comment:
Please see my latest comments to https://github.com/pypa/pip/issues/1891.
tl;dr It is related to the -m switch as pip's wheel launcher does
PYTHONPATH=script.exe python -m __main__
--
___
Python tracker <
New submission from Marc Schlaich:
This is a follow up of #5162.
There are some occasions where you can still run into this issue. One example
is if you want to spawn a new multiprocessing.Process as a child of a
multiprocessing.Process:
pythonservice.exe
- multiprocessing.Process
Marc Schlaich added the comment:
This wasn't decided yet for 2.7 so I'm reopening it until a decision is made.
I'm still +1 for an update to 3.8.3.1 on Windows so that this is on par with
the version on OSX and the version in Python 3.
--
resolution: fixed ->
status: closed ->
Marc Schlaich added the comment:
We have some business privilege management solution running which might have
corrupted the installation. As no one else is reporting this issue, this is my
best guest for this phenomena and I'm going to close this issue.
--
status: open -> clo
Marc Schlaich added the comment:
Wrong bug...
--
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26434>
___
___
Marc Schlaich added the comment:
We have some business privilege management solution running which might have
corrupted the installation. As no one else is reporting this issue, this is my
best guest for this phenomena and I'm going to close this issue.
--
status: open -> clo
Marc Schlaich added the comment:
This could be even a security issue.
People might rely on a proxy as a privacy feature. In this case the proxy
should do forward/reverse DNS requests and not the client. Doing DNS lookups to
check for proxy bypass doesn't seem right. I don't think that major
Marc Schlaich added the comment:
BTW, you can workaround this issue by defining the `http_proxy` and `no_proxy`
environment variables.
In this case urllib isn't doing any DNS request.
--
___
Python tracker <rep...@bugs.python.org>
Marc Schlaich added the comment:
Well, you can read the proxy settings from registry and write them to
os.environ (no_proxy needs to be transformed as it has a different format).
This will only take effect for the current process.
--
___
Python
Marc Schlaich added the comment:
Julia, could you please add other major browsers/HTTP clients (Firefox, Chrome,
curl, ...) to your comparison (compare_ie_urllib.txt). I would expect that
Python/urllib is the only implementation doing DNS requests for proxy bypass
handling.
Please note
Marc Schlaich added the comment:
I opened a PR on GitHub, please review.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26434>
___
__
Marc Schlaich added the comment:
We are passing arguments
-latest(Return only the newest version and last installed.)
and
"-requires", "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
So this should handle the cases multiple installs and different product
Change by Marc Schlaich :
--
keywords: +patch
pull_requests: +11016
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35699>
___
___
Py
Change by Marc Schlaich :
--
keywords: +patch, patch
pull_requests: +11016, 11017
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Marc Schlaich :
--
keywords: +patch, patch, patch
pull_requests: +11016, 11017, 11018
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Marc Schlaich added the comment:
Davin, why isn't just one of the simple one-line patches applied. This would be
much more reasonable instead of closing this as won't fix.
This is a really ugly bug and it took me hours to find the cause...
--
nosy: +schlamar
Change by Marc Schlaich :
--
nosy: +schlamar
___
Python tracker
<https://bugs.python.org/issue35596>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Marc Schlaich :
vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools
2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft
Visual C++ 14.0 is required" error.
Please see https://github.com/Microsoft/vswhere/
New submission from Marc Schlaich :
After closing a StreamWriter the `StreamReaderProtocol.connection_lost` on the
other end is not getting called. In this case the StreamReader is at EOF but
calling write/drain does not raise any Exception (and sending data to Nirvana).
I would expect
Marc Schlaich added the comment:
After having a closer look I fear that there isn't a correct implementation for
half closed sockets and returning True from eof_received results in a
fundamentally broken state machine.
I'm not sure if a selector implementation can handle half closed sockets
Marc Schlaich added the comment:
No, I'm seeing the same issue on MacOS. Attached modified example.
--
Added file: https://bugs.python.org/file48160/tcp_test.py
___
Python tracker
<https://bugs.python.org/issue35
New submission from Marc Schlaich :
Creating a venv from the python.exe from another venv does not work since 3.7.2
on Windows. This is probably related to the change
bpo-34977: venv on Windows will now use a python.exe redirector rather than
copying the actual binaries from the base
New submission from Marc Schlaich :
Controlling a venv from the python.exe from another venv does not work since
3.7.2 on Windows. This is probably related to the change
bpo-34977: venv on Windows will now use a python.exe redirector rather than
copying the actual binaries from the base
66 matches
Mail list logo
