[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows
New submission from Rob : Hi, In the docs for the asyncio event loop, it has a note on page: https://docs.python.org/3/library/asyncio-eventloop.html#running-subprocesses "Note The default asyncio event loop on Windows does not support subprocesses. See Subprocess Support on Windows for details." Then following the link in that note to: https://docs.python.org/3/library/asyncio-platforms.html#subprocess-support-on-windows Says: "On Windows, the default event loop ProactorEventLoop supports subprocesses, whereas SelectorEventLoop does not." So the issue is, there are conflicting statements about default support for asyncio subprocesses on Windows. It seems the first statement listed above, is wrong or outdated since the default event loop on Windows is the ProactorEventLoop which does support subprocesses. Thank you! -- assignee: docs@python components: Documentation messages: 406967 nosy: Rob4226, docs@python priority: normal severity: normal status: open title: Conflicting statements in docs about default support for asyncio subprocesses on Windows versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows
Rob added the comment: Ok will do. Thanks for confirming. -- ___ Python tracker <https://bugs.python.org/issue45896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows
Change by Rob : -- keywords: +patch pull_requests: +28085 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29857 ___ Python tracker <https://bugs.python.org/issue45896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper
Changes by Rob : -- nosy: +raymondr ___ Python tracker <http://bugs.python.org/issue17849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
New submission from Rob Bairos :
When adding hooks to sys.meta_path, to correctly deal with arbitrarily named
non-disk module definitions, module names with slashes should still be
processed.
As it stands when executing statements such as:
import my_module_123#/123
or
even
__import__('my_module_123#/123')
the following exception is raised:
ImportError: Import by filename is not supported.
This stops sys.meta_path from handling arbitrarily named modules.
Shouldn't the ImportError be raised *after* the meta_path processing, at which
point, its safe to assume the name is a disk name, in which case slashes are
relevant?
--
components: Interpreter Core
messages: 146799
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: ImportError ImportError: Import by filename, should be deferred until
sys.meta_path hooks are processed
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13314>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Changes by Rob Bairos : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Rob Bairos added the comment: Why is a module name syntactically improper simply because it contains a slash? That seems an arbitrary definition, that serves no purpose, except to discourage accidentally specifying a filename. Module with unusual characters all reach the meta_path stage, eg: my,mo*d1?2my##m;o#d13 But as soon as a slash is introduced, a warning that filenames not being supported is thrown. 1) If the issue is that its not syntactically correct, it should state so. 2) If the issue is that its not syntactically correct, the syntax of a module name should be documented to include *,?# or throw the same exception. 3) Whats the purpose of the 'Import my filename' exception anyhow? Will it not fail soon thereafter at any rate? This behaviour is definitely inconsistent and arbitrary. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Rob Bairos added the comment: Yah, thinking about this further, the real error is that sys.meta_path allows processing of names with #,?* etc. I can see why this would cause problems, as python names must only be _ and alphanumeric characters. I'll re-implement this. Thanks. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12912] xmlrpclib.__version__ not bumped with updates
New submission from Rob Crittenden : xmlrpclib.__version__ reports 1.0.1 from Python 2.7 in Fedora 14 and Python 2.6 in Fedora 12. I discovered this while trying to find a way to identify the version of xmlrpclib. The 2.7 xmlrpclib is not completely backward compatible with that in 2.6 Version-Release number of selected component (if applicable): python-2.7-7.fc14.x86_64 Steps to Reproduce: $ rpm -q python python-2.6.2-8.fc12.x86_64 $ python Python 2.6.2 (r262:71600, Jun 4 2010, 18:28:58) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' $ rpm -q python python-2.7-7.fc14.x86_64 $ python Python 2.7 (r27:82500, Jul 26 2010, 18:19:48) [GCC 4.5.0 20100716 (Red Hat 4.5.0-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' -- components: Library (Lib) messages: 143604 nosy: rcritten priority: normal severity: normal status: open title: xmlrpclib.__version__ not bumped with updates versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12912] xmlrpclib.__version__ not bumped with updates
Rob Crittenden added the comment: Yes, this is the solution I ended up using as a workaround. I figured that since xmlrpclib has its own version it should be meaningful. -- ___ Python tracker <http://bugs.python.org/issue12912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12912] xmlrpclib.__version__ not bumped with updates
Rob Crittenden added the comment: Python 2.7 changed the internal class used in xmlrpclib from HTTP to HTTPConnection. I have code that subclasses httplib.HTTP to use the python-nss package to create a connection over SSL (similiar to httplib.HTTPS). My code currently looks something like this as a workaround: class NSSConnection(httplib.HTTPConnection) ... class NSSHTTPS(httplib.HTTP): _connection_class = NSSConnection def __init__ ... def connect(): (major, minor, micro, releaselevel, serial) = sys.version_info if major == 2 and minor < 7: conn = NSSHTTPS(host, 443, dbdir="/etc/pki/nssdb") else: conn = NSSConnection(host, 443, dbdir="/etc/pki/nssdb") Full code is at https://fedorahosted.org/freeipa/browser/ipalib/rpc.py and https://fedorahosted.org/freeipa/browser/ipapython/nsslib.py At least one other person has run into this, https://techknowhow.library.emory.edu/blogs/branker/2011/07/01/python-27-xmlrpclibtransport-backward-compatibility -- ___ Python tracker <http://bugs.python.org/issue12912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
New submission from Rob Watson :
Is the below a bug or a misuse of the api ? This was compiled with visual
studio 2008 and python26 64bit
void testfunction()
{
for (int x = 1;x <= 10;x++)
{
PyGILState_STATE gstate = PyGILState_Ensure();
PyRun_SimpleString("2 + 1");
PyGILState_Release(gstate);
}
}
int main()
{
Py_Initialize();
PyEval_InitThreads();
PyEval_ReleaseLock();
boost::thread(boost::bind(testfunction));
// if this Sleep(100) is commented out, I will get "Python Fatal Error
: This thread state must be current when releasing"
Sleep(100);
testfunction();
Sleep(100);
}
--
components: None
messages: 116891
nosy: Rob.Watson
priority: normal
severity: normal
status: open
title: Threading Bug or misuse of the api ?
type: crash
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue9900>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
Changes by Rob Watson : -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue9900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
Changes by Rob Watson : -- resolution: invalid -> ___ Python tracker <http://bugs.python.org/issue9900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
Changes by Rob Watson : -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue9900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
Changes by Rob Watson : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue9900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9900] Threading Bug or misuse of the api ?
Rob Watson added the comment: it seemed changing PyEval_ReleaseLock() to PyThreadState_DeleteCurrent() has fixed my problem. Thanks -- resolution: invalid -> ___ Python tracker <http://bugs.python.org/issue9900> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
Rob Cliffe added the comment: Thanks for your work. Glad if I have made a contribution to Python, however small. Rob Cliffe On 22/11/2010 00:26, Éric Araujo wrote: > Éric Araujo added the comment: > > Thank you. I uploaded your patch to Rietveld and reviewed it: > http://codereview.appspot.com/3169042/ > > -- > > ___ > Python tracker > <http://bugs.python.org/issue8525> > ___ > -- ___ Python tracker <http://bugs.python.org/issue8525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
Rob Cliffe added the comment:
I would not be at all surprised if my patch could be simplified (in fact
I'd be surprised if it couldn't).
However, I did try out your version on Python 2.5 specifically, and it
did not work for me.
Trying it out on help(Exception), the relevant members of
object.__subclasses__() viz.
, etc.
had a __module__attribute which equalled 'exceptions', not 'builtins'.
Best wishes
Rob Cliffe
On 22/11/2010 01:33, Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>
> The following passes tests in elp_8525.patch, but is much simpler:
>
> ===
> --- Lib/pydoc.py (revision 86600)
> +++ Lib/pydoc.py (working copy)
> @@ -1139,6 +1139,15 @@
> push('' + makename(base))
> push('')
>
> +# List the built-in subclasses, if any:
> +subclasses = [cls.__name__ for cls in object.__subclasses__()
> + if cls.__module__ == 'builtins']
> +if subclasses:
> +push("Built-in subclasses:")
> +for subclassname in sorted(subclasses):
> +push('' + subclassname)
> +push('')
> +
> # Cute little class to pump out a horizontal rule between sections.
> class HorizontalRule:
> def __init__(self):
>
> --
> nosy: +belopolsky
>
> ___
> Python tracker
> <http://bugs.python.org/issue8525>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue8525>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Display exception's subclasses in help()
Rob Cliffe added the comment: Originally I only had built-in classes in mind (with Exceptions being IMO the most obvious example of a built-in class hierarchy that it is useful to find your way around). But if the idea can be extended to other classes, well, great. Rob Cliffe -- ___ Python tracker <http://bugs.python.org/issue8525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6294] Improve shutdown exception ignored message
Rob Lourens added the comment: I agree with R. David Murray's suggestions, and have implemented it in the attached patch. -- keywords: +patch nosy: +rob.lourens Added file: http://bugs.python.org/file20707/errors.patch ___ Python tracker <http://bugs.python.org/issue6294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3484] Sphinx tests fail because of missing dir
New submission from Rob Cakebread <[EMAIL PROTECTED]>: When I try to run the unit tests with tests/run.py they fail because this directory is missing: tests/root/_build If I simply create the directory and run the tests, they pass. Running Sphinx test suite... EEE... == ERROR: test_config.test_core_config -- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest self.test(*self.arg) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py", line 20, in test_core_config cfg = TestApp(confoverrides=overrides).config File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py", line 106, in __init__ freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py", line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py", line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' == ERROR: test_config.test_extension_values -- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest self.test(*self.arg) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py", line 65, in test_extension_values app = TestApp() File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py", line 106, in __init__ freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py", line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py", line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' == ERROR: Failure: OSError ([Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees') -- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_markup.py", line 21, in app = TestApp() File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py", line 106, in __init__ freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py", line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File "/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py", line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' -- Ran 6 tests in 3.785s FAILED (errors=3) -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70567 nosy: cakebread, georg.brandl severity: normal status: open title: Sphinx tests fail because of missing dir versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Small enhancement to help()
New submission from Rob Cliffe : help() on an exception class lists the method resolution order, which is in effect the class inheritance hierarchy. E.g. help(ArithmeticError) lists ArithmeticError, StandardError, Exception, BaseException, __builtin__.object. It struck me it would help to find my way around if it also listed the builtin SUBclasses (if any). Something like: Built-in subclasses: FloatingPointError OverflowError ZeroDivisionError In fact why not do it for any class, not just exceptions? I attach a patched version of pydoc.py - tested but only on my PC which is running Python 2.5 under Windows XP. I have added lines 1129-1148 to the docclass method of the TextDoc class (and flagged them # [RAC] ). (I don't pretend to understand the magic where __builtins__ is a dictionary when pydoc.py is run but becomes a module later on. Never mind - the patch works (I believe).) For consistency, a similar patch would also have to be made to the docclass nethod of the HTMLDoc class (which outputs HTML rather than plain text). I have not attempted this as I don't know how it is called and hence how to test any patch, but it should be straightforward for anyone with the know-how. -- files: pydoc.py messages: 104134 nosy: robcliffe severity: normal status: open title: Small enhancement to help() type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file17075/pydoc.py ___ Python tracker <http://bugs.python.org/issue8525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4535] Build / Test Py3K failed on Ubuntu 8.10
Changes by Rob Wiers <[EMAIL PROTECTED]>: -- components: Build files: py3k.out nosy: lbhudda severity: normal status: open title: Build / Test Py3K failed on Ubuntu 8.10 type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12225/py3k.out ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4535> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4535] Build / Test Py3K failed on Ubuntu 8.10
New submission from Rob Wiers <[EMAIL PROTECTED]>: After reading about the Py3K release, I downloaded the source distribution and did a build and test. The test failed, and I thought it might be useful to share it here. I realise there is probably a person (or group) dedicated to porting Python 3.0 to Ubuntu, but I thought this might be helpful. If not, please let me know. Regards, Rob Wiers ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4535> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue918368] urllib doesn't correct server returned urls
Rob Probin added the comment: I agree - this appears to be the same as issue 1153027 ? ___ Python tracker <http://bugs.python.org/issue918368> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Rob Probin added the comment: Appears to be the same as issue 918368 -- nosy: +robzed ___ Python tracker <http://bugs.python.org/issue1153027> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38523] ignore_dangling_symlinks in shutil.copytree does not apply recursively
New submission from Rob nelson : The ignore_dangling_symlinks attribute in shutil.copytree is not passed down recursively, resulting in dangling symlinks located anywhere other than the root of the source tree to raise an error. The line causing the error for 3.9: https://github.com/python/cpython/blob/v3.8.0/Lib/shutil.py#L486 Trivial patches and an improved test case for: 3.7: https://github.com/veaviticus/cpython/commit/a662ae8a3f85380ec76ed3dfbc778aad8c5ac37a 3.8: https://github.com/veaviticus/cpython/commit/64f72c7196243bd3e2cf4136ebbb9f9ffe206750 3.9: https://github.com/veaviticus/cpython/commit/e55dd12e558443c350d241d87bf17dfc322dbfcf -- components: Library (Lib) messages: 354924 nosy: veaviticus priority: normal severity: normal status: open title: ignore_dangling_symlinks in shutil.copytree does not apply recursively versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue38523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22239] asyncio: nested event loop
Change by Rob Moore : -- nosy: +rob.moore ___ Python tracker <https://bugs.python.org/issue22239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44495] wrong FNAME in tarfile if tgz extension is used
Rob Nelson added the comment:
The code referenced in the previous comment only hits for tarfiles built from
Streams.
The same (incorrect) code exists in the gzip.py library as well, and hits the
more common usecase of building a tar.gz from a set of files on disk.
def _write_gzip_header(self, compresslevel):
self.fileobj.write(b'\037\213') # magic header
self.fileobj.write(b'\010') # compression method
try:
# RFC 1952 requires the FNAME field to be Latin-1. Do not
# include filenames that cannot be represented that way.
fname = os.path.basename(self.name)
if not isinstance(fname, bytes):
fname = fname.encode('latin-1')
if fname.endswith(b'.gz'):
fname = fname[:-3]
This effects decompressing the file with 7zip, who respects the FNAME value,
and thus attempts to create a new file with the same name as the file its
currently decompressing. Or if you extract to another directory, it creates a
tar file that is named "foo.tgz", which is confusing to users who are expecting
a tar.
You can very easily reproduce this:
import tarfile
f = tarfile.open("test.tgz", mode="w:gz")
f.close()
and then "extract" the file with 7zip
--
nosy: +veaviticus
___
Python tracker
<https://bugs.python.org/issue44495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45888] Revisit: start_tls() difficult when using asyncio.start_server()
New submission from Rob Blackbourn : The issue 34975 "start_tls() difficult when using asyncio.start_server()" was closed because streams was being re-written, but it's still a useful enhancement, and a fairly simple change. Could this be revisited? I've done a proof of concept here: https://github.com/rob-blackbourn/asyncio-upgradeable-streams -- assignee: christian.heimes components: Library (Lib), SSL messages: 406906 nosy: christian.heimes, rob-blackbourn priority: normal severity: normal status: open title: Revisit: start_tls() difficult when using asyncio.start_server() type: enhancement versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39121] gzip header write OS field
New submission from Rob Man : Files written with gzip module write a value of 255 (unknown) at the 10th position in the header which defined what OS was used when gzip file was written. Files written with gzip linux command correctly set that field to the value of 3 (Unix). This ehancement does that. -- components: Library (Lib) messages: 358801 nosy: wungad priority: normal severity: normal status: open title: gzip header write OS field type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39121] gzip header write OS field
Change by Rob Man : -- keywords: +patch pull_requests: +17138 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17682 ___ Python tracker <https://bugs.python.org/issue39121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39121] gzip header write OS field
Change by Rob Man : -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue39121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39121] gzip header write OS field
Rob Man added the comment: I do not need it for personaly, but since RFC exists and since linux command line equivalent writes OS information, why should python gzip implementation not include that. The same goes for the FCOMMENT field for wich I also have a patch ready and I they're both nice enhancements. On Mon, 23 Dec 2019 at 09:04, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > The OS field is used in determining end-of-line convention for text files. > But since we do not set the FTEXT flag, all files are binary. RFC 1952 > > Why do you need to set this field? > > -- > nosy: +serhiy.storchaka > > ___ > Python tracker > <https://bugs.python.org/issue39121> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40416] Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded file causes UnicodeDecodeError
New submission from Rob Malouf :
Calling TextIOWrapper.tell() while reading the attached gb2312-encoded file
like this:
with open('udhr-gb2312.txt', encoding='GB2312') as f:
while True:
line = f.readline()
t = f.tell()
if not line:
break
gives this result:
Traceback (most recent call last):
File "test.py", line 4, in
t = f.tell()
UnicodeDecodeError: 'gb2312' codec can't decode byte 0xb5 in position 0:
illegal multibyte sequence
The file seems to be well-formed and can be read without any problem. It's
only the call to tell() that raises an issue.
--
components: IO, Unicode
files: udhr-gb2312.txt
messages: 367494
nosy: ezio.melotti, rmalouf, vstinner
priority: normal
severity: normal
status: open
title: Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded
file causes UnicodeDecodeError
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49096/udhr-gb2312.txt
___
Python tracker
<https://bugs.python.org/issue40416>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40416] Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded file causes UnicodeDecodeError
Rob Malouf added the comment: Same results on MacOS 10.15.4 (both the system python and the intel/anaconda version) and on CentOS 7.8 Here's the output with print(...): 13 71 72 392 393 399 536 537 761 762 879 880 933 934 1146 1147 1254 1255 1359 1360 1760 1761 1772 1895 1897 1906 2105 2107 2338 2339 2348 2398 2399 2408 2509 2510 2519 2612 2614 2622 2682 2684 2693 2898 2900 2909 3050 3052 3061 3113 3115 3124 3295 3297 3309 3445 3632 3644 3814 3816 3828 3882 3967 3979 4048 4184 4196 4226 4308 4320 4492 4559 4641 4653 4728 4770 4782 4999 5001 5013 5202 5204 5216 5270 5318 5333 5411 5465 5672 5687 5953 5954 5969 6082 6137 6307 6373 6388 6494 6496 6511 6786 6913 6928 7148 7371 7447 7462 7569 7704 7719 7847 7848 7863 7972 8238 8342 Traceback (most recent call last): File "test.py", line 4, in print(f.tell()) UnicodeDecodeError: 'gb2312' codec can't decode byte 0xb5 in position 0: illegal multibyte sequence -- ___ Python tracker <https://bugs.python.org/issue40416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42984] Python 3.7 and qt Libraries
New submission from Rob Simsiman : Hello, I am trying to run an application on CentOS-8 that is unable to find qt4 libraries, namely libQtCore.so.4. My PC has qt5 libraries, namely libQt5Core.so.5. How can I configure my Python 3.7 to look for the qt5 libraries instead of the qt4 libraries. Or, do I simply need to grab a newer version of Python? Thank you, Rob Simsiman -- components: ctypes messages: 385367 nosy: rsimsiman priority: normal severity: normal status: open title: Python 3.7 and qt Libraries type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue42984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40805] Can no longer patch flask.g
New submission from Rob Taft :
Whenever I try to patch flask.g, it appears to do nothing. This happened when
I upgraded mock from 3.x to 4.x. I reported it on the mock github page
https://github.com/testing-cabal/mock/issues/490 and was asked to report it
here. The folllowing code run with pytest works fine in mock 3.0.5, but fails
to patch in 4.0.0 and up.
from mock import patch
import flask
def some_function():
flask.g.somevariable = True
return flask.g.somevariable
@patch('flask.g')
def test_some_function(mock_flask_global):
assert some_function()
--
components: Tests
messages: 370197
nosy: Rob Taft
priority: normal
severity: normal
status: open
title: Can no longer patch flask.g
type: behavior
versions: Python 3.6, Python 3.8
___
Python tracker
<https://bugs.python.org/issue40805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40805] Can no longer patch flask.g
Rob Taft added the comment: The test was supposed to patch the flask component during the unit test, the error indicates the patch did not work. The actual error message is not relevant to the actual issue. I don't know why I was directed to here. When I replace it with unittest.mock, it appears to work fine, so my solution might end up being to dump the 3rd party mock library. On Fri, May 29, 2020 at 11:02 PM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > Sorry, but I believe you were misdirected*. mock, as opposed to > unittest.mock, pytest, flask, and werkzeug are 3rd party modules. The > error report seems to be missing part of the stacktrace at both ends. What > line is your file resulted in the error? (This time we can guess == > @patch. @What called _lookup_app_object in flask? (I have no idea.) > > However, once contextlib._GeneratorContextManager calls next(self.gen), > the rest of the trace is outside the stdlib. At the end, the RuntimeError > is raised by flask, not by python, because the flask _app_ctx_stack.top > does not exist. If you do not understand their error message, ask flask > people. > > * I assume that cjw296 *glanced* at your report, saw 'RuntimeError', and > too quickly assumed 'cpython error'. flask could have defined, for > instance, FlaskRuntimeError for its error reporting. > > -- > nosy: +terry.reedy > resolution: -> third party > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue40805> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40805] Can no longer patch flask.g
Rob Taft added the comment: I have confirmed that using unittest.mock instead of the 3rd party mock library in python 3.8.3 and 3.9-dev fails to patch flask.g. 3.7.7 works correctly. -- ___ Python tracker <https://bugs.python.org/issue40805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40805] Can no longer patch flask.g
Change by Rob Taft : -- versions: +Python 3.9 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue40805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40805] Can no longer patch flask.g
Rob Taft added the comment:
I updated the test with 2 cases and the traceback is different for each when I
expected them to be the same if this was purely a mock issue, the line throwing
the error is the same. I can post this over with flask and see what they think.
from unittest.mock import patch
import flask
def some_function():
flask.g.somevariable = True
return flask.g.somevariable
@patch('flask.g')
def test_patch(mock_flask_global):
assert some_function()
def test_no_patch():
assert some_function()
$ pytest -vv temp_test.py
test session starts
=
platform linux -- Python 3.8.3, pytest-5.4.3, py-1.8.1, pluggy-0.13.1 --
collected 2 items
temp_test.py::test_patch FAILED
[ 50%]
temp_test.py::test_no_patch FAILED
[100%]
==
FAILURES
==
_
test_patch
_
args = (), keywargs = {}
@wraps(func)
def patched(*args, **keywargs):
> with self.decoration_helper(patched,
args,
keywargs) as (newargs, newkeywargs):
../../../.pyenv/versions/3.8.3/lib/python3.8/unittest/mock.py:1322:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../../../.pyenv/versions/3.8.3/lib/python3.8/contextlib.py:113: in __enter__
return next(self.gen)
../../../.pyenv/versions/3.8.3/lib/python3.8/unittest/mock.py:1304: in
decoration_helper
arg = exit_stack.enter_context(patching)
../../../.pyenv/versions/3.8.3/lib/python3.8/contextlib.py:425: in enter_context
result = _cm_type.__enter__(cm)
../../../.pyenv/versions/3.8.3/lib/python3.8/unittest/mock.py:1416: in __enter__
if spec is None and _is_async_obj(original):
../../../.pyenv/versions/3.8.3/lib/python3.8/unittest/mock.py:51: in
_is_async_obj
if hasattr(obj, '__func__'):
pyvenv/lib/python3.8/site-packages/werkzeug/local.py:347: in __getattr__
return getattr(self._get_current_object(), name)
pyvenv/lib/python3.8/site-packages/werkzeug/local.py:306: in _get_current_object
return self.__local()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
name = 'g'
def _lookup_app_object(name):
top = _app_ctx_stack.top
if top is None:
> raise RuntimeError(_app_ctx_err_msg)
E RuntimeError: Working outside of application context.
E
E This typically means that you attempted to use functionality that
needed
E to interface with the current application object in some way. To
solve
E this, set up an application context with app.app_context(). See the
E documentation for more information.
pyvenv/lib/python3.8/site-packages/flask/globals.py:45: RuntimeError
___
test_no_patch
def test_no_patch():
> assert some_function()
temp_test.py:14:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
temp_test.py:6: in some_function
flask.g.somevariable = True
pyvenv/lib/python3.8/
[issue40805] Can no longer patch flask.g
Rob Taft added the comment: https://github.com/pallets/flask/issues/3637 I've worked around the issue and accept that this will not work in the future. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue40805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28340] [py2] TextIOWrapper.tell extremely slow
Changes by Rob Malouf : -- pull_requests: +1832 ___ Python tracker <http://bugs.python.org/issue28340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Display exceptions' subclasses in help()
Rob Cliffe added the comment:
On 14/07/2018 13:44, Nick Coghlan wrote:
> Nick Coghlan added the comment:
>
> Reviewing the builtins in 3.7, I get the following results for builtin
> objects that have defined subclasses immediately after interpreter startup:
>
> =
>>>> for name, obj in vars(builtins).items():
> .. if isinstance(obj, type) and name in str(obj):
> .. subclasses = type(obj).__subclasses__(obj)
> .. if subclasses:
> .. print(f"{obj}: {len(subclasses)}")
> ..
> : 1
> : 1
> : 1
> : 1
> : 132
> : 1
> : 16
> : 1
> : 4
> : 19
> : 2
> : 13
> : 3
> : 1
> : 1
> : 1
> : 3
> : 2
> : 3
> : 3
> : 1
> : 10
> : 4
> =
>
> So rather than special-casing exceptions or builtins in general, my
> inclination would be to include a section that lists up to 4 subclasses
> inline, and then adds a "... and NNN additional subclasses" trailing when
> there are more than 4 (or when there are less than 4 subclasses with public
> names, but additional private subclasses).
>
>
My 2 cents:
To use Exceptions optimally (e.g. to make the errors you trap
neither too specific nor too general), you often need to know (and
understand) the relevant part of the Exception hierarchy. In particular
you may know the name of an Exception that covers a particular use case,
but not the names of its subclasses, one of which might be more
appropriate. Exceptions are exceptional* in that the "issubclass"
relationship is vital to the way that they work. So it is USEFUL to
know ALL subclasses of a given Exception class (not just 4; in practice
there won't be more than a dozen or two). I have found myself in just
this position; in fact it impelled me to adding a "show subclasses"
feature to help() in my then current version of
Python 2. (An alternative might be a handy way of showing the complete
built-in Exception hierarchy.)
I question whether it is really useful to know all subclasses of ANY
class, or whether YAGNI. I think that, for non-Exception classes,
typically when you look at a class you may want to know its inheritance
(to understand its functionality better), but it is rare that you will
want to know what subclasses it has, if any. No doubt there are
exceptions* (perhaps you monkey-patch a class and want to know what
subclasses might be affected).
Regards
Rob Cliffe
* Pun not intended
--
___
Python tracker
<https://bugs.python.org/issue8525>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34865] Incorrect assignment of optional argument when partial match with different argument found.
New submission from Rob Dalton : Parsing an unknown optional argument whose leading characters (e.g. '--user') match those of another, known optional argument (e.g. '--userdata') causes the unknown argument to be parsed as the known one. For example - passing the unknown argument '--user' to a parser with the known argument '--userdata' assigns the passed '--user' value to '--userdata'. Here's my setup info: Python: Python 3.6.3 :: Anaconda custom (64-bit) OS: MacOS High Sierra 10.13.6 Wrote up some example cases here: https://gist.github.com/rob-dalton/9ec06b8d5e2e9083713ddc7884d16072 -- components: Library (Lib) messages: 326824 nosy: rob-dalton priority: normal severity: normal status: open title: Incorrect assignment of optional argument when partial match with different argument found. type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34865] Incorrect assignment of optional argument when partial match with different argument found.
Rob Dalton added the comment: It does. Thanks! I feel dumb for not finding that. Guess I'd just suggest making the default `false`, seems more intuitive to me. On Mon, Oct 1, 2018 at 2:00 PM Robert Dalton wrote: > It does. Thanks! I feel dumb for not finding that. > > Guess I'd just suggest making the default `false`, seems more intuitive to > me. > > On Mon, Oct 1, 2018 at 1:48 PM Zachary Ware > wrote: > >> >> Zachary Ware added the comment: >> >> Would using `allow_abbrev=False` fix this for you? >> >> https://docs.python.org/3/library/argparse.html#allow-abbrev >> >> -- >> nosy: +zach.ware >> >> ___ >> Python tracker >> <https://bugs.python.org/issue34865> >> _______ >> > > > -- > Best, > Rob Dalton > > > (814) 571-0462 | robdalton.me | robcdal...@gmail.com > -- Best, Rob Dalton (814) 571-0462 | robdalton.me | robcdal...@gmail.com -- ___ Python tracker <https://bugs.python.org/issue34865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
New submission from Rob Bairos: Why does PyImport_Import (import.c) call __import__ then immediately discard the result, and then look for the module again in the module dictionary? It will return the same value in both cases no? Ive included the relevant portion of the code below. Its breaking an embedded application we've built where a hierarchy of modules are maintained outside the sys.modules dictionary. /* Call the __import__ function with the proper argument list Always use absolute import here. Calling for side-effect of import. */ r = PyObject_CallFunction(import, "i", module_name, globals, globals, silly_list, 0, NULL); if (r == NULL) goto err; //-- WHY IS THIS SECTION NEEDED? Py_DECREF(r); modules = PyImport_GetModuleDict(); r = PyDict_GetItem(modules, module_name); if (r != NULL) //--- Py_INCREF(r); -- components: Interpreter Core messages: 195915 nosy: Rob.Bairos priority: normal severity: normal status: open title: PyImport_Import redundant calls to find module versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Changes by Rob Bairos : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Rob Bairos added the comment: However, if it fails __import()__ it doesn't get to the sys.modules[] call anyways. The only case affected by this are: PASS the __import()__ call, then FAIL the sys.modules[] lookup afterwards. Why will that effect anything currently out there? As it stands now, it suppresses development of some types of dynamic hierarchies of modules such as we've implemented, that don't register themselves in sys.modules[] -- ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Rob Bairos added the comment: Okay, thanks for looking into it. Cheers -- ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15593] urlparse.parse_qs documentation wrong re: urlencode
New submission from Rob Kinyon: This may appear to be a duplicate of http://bugs.python.org/issue12390 and http://bugs.python.org/issue833405, but it's not. The documentation of urlparse.parse_qs() should state that in order for urllib.urlencode to properly reverse its output, the doseq parameter must be set to True. Please amend the documentation to make this very clear. Ideally, the documentation of urlencode() would also make it clear that doseq=True is required if the output is from parse_qs(). -- assignee: docs@python components: Documentation messages: 167707 nosy: Rob.Kinyon, docs@python priority: normal severity: normal status: open title: urlparse.parse_qs documentation wrong re: urlencode versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15593> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20402] List comprehensions should be noted in for loop documentation
Rob Lanphier added the comment: > Moving it earlier in the tutorial is likely to do more harm than help. > In teaching Python, you need some gap between learning for-loops and > learning list comprehensions (the former is a prerequisite for the > latter). The problem here is that many people get list comprehensions foisted on them by reading code that has them in it. Since list comprehensions aren't called "list comprehensions" in the code, but rather, they look like funny for loops, many people will turn to the for loop documentation, and as of this writing, they won't find anything. There doesn't necessarily need to be the full example as in Alex's patch (though Alex's version seems fine to me), I think there should at least be some link to the list comprehension documentation, e.g. "It is also possible to prepend a function onto a 'for' loop. This is a :ref:`list comprehensions `, and is explained further in the next chapter." -- ___ Python tracker <http://bugs.python.org/issue20402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14285] Traceback wrong on ImportError while executing a package
Changes by Rob Agar : -- nosy: +robagar ___ Python tracker <http://bugs.python.org/issue14285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14285] Traceback wrong on ImportError while executing a package
Rob Agar added the comment: The message also needs to include the file and line number of the ImportError. -- ___ Python tracker <http://bugs.python.org/issue14285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20296] PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc.
New submission from Rob Browning: Here (http://docs.python.org/2/c-api/arg.html), the documentation for "t#" says: t# (read-only character buffer) [char *, int]... while the documentation for "w#" says: w# (read-write character buffer) [char *, Py_ssize_t]... However, from getargs.c, it looks like they're handled the same with respect to the size type. At a minimum, it seems like it might make sense to change these docs to match, and if "w#" and "t#" are actually handled similarly to "s#", it would be even better to just change their docs to match (or refer to) "s#"'s which are more detailed, i.e. they mention the PY_SSIZE_T_CLEAN issues, etc. Thanks -- assignee: docs@python components: Documentation messages: 208410 nosy: docs@python, rlb priority: normal severity: normal status: open title: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc. versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20402] List comprehensions should be noted in for loop documentation
New submission from Rob Lanphier:
The current list comprehension documentation is difficult to find for someone
who doesn't know what a list comprehension is. Example of this problem:
http://www.reddit.com/r/learnprogramming/comments/1w6slm/different_kind_of_for_loop_python/
Since list comprehensions are a riff off of "for" loop syntax, they should at
least be noted and linked to from section 4.2 ("for statements" section) and
quite possibly 5.6 ("Looping constructs")
--
assignee: docs@python
components: Documentation
messages: 209380
nosy: docs@python, robla
priority: normal
severity: normal
status: open
title: List comprehensions should be noted in for loop documentation
type: enhancement
___
Python tracker
<http://bugs.python.org/issue20402>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux
Rob Gaddi added the comment:
I was just working on similar things, and found the same problem. I can
confirm failure on both Python 2.7.4 and Python 3.3.1 running on 64-bit Linux,
and that the Windows builds do not have this problem.
My code:
from __future__ import print_function
from ctypes import *
from itertools import product
bases = (BigEndianStructure, LittleEndianStructure)
packs = (True, False)
basetypes = ( (c_uint,16), (c_ushort,16), (c_uint,32) )
print("Base Basetype pack high low size bytes")
for basetype, base, pack in product(basetypes, bases, packs):
fields = [
('high', basetype[0], basetype[1]),
('low', basetype[0], basetype[1]),
]
cls = type('', (base,), {'_pack_' : pack, '_fields_' : fields})
x = cls(high = 0x1234, low = 0x5678)
bacls = c_uint8 * sizeof(x)
ba = bacls.from_buffer(x)
s = ''.join('{0:02X}'.format(b) for b in ba)
k = '*' if (x.high != 0x1234 or x.low != 0x5678) else ''
report = "{name:25s}{basetype:10s}{pack:4d} {high:04X} {low:04X}
{size:4d} {s}{k}".format(
name = base.__name__,
high = x.high,
low = x.low,
size = sizeof(x),
pack = pack,
basetype = basetype[0].__name__,
s = s,
k = k
)
print(report)
My results:
Base Basetype pack high low size bytes
BigEndianStructure c_uint 1 5678 4 5678*
BigEndianStructure c_uint 0 5678 4 5678*
Structurec_uint 1 1234 5678 4 34127856
Structurec_uint 0 1234 5678 4 34127856
BigEndianStructure c_ushort 1 1234 5678 4 12345678
BigEndianStructure c_ushort 0 1234 5678 4 12345678
Structurec_ushort 1 1234 5678 4 34127856
Structurec_ushort 0 1234 5678 4 34127856
BigEndianStructure c_uint 1 1234 5678 8 12345678
BigEndianStructure c_uint 0 1234 5678 8 12345678
Structurec_uint 1 1234 5678 8 34127856
Structurec_uint 0 1234 5678 8 34127856
On python3, the BigEndianStructure seemingly at random will set the high or low
fields from one execution to the next, but always misses one or the other. I
have always seen high = 0, low = 0x5678 on python2.
--
nosy: +rgaddi
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue20629>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7627] mailbox.MH.remove() lock handling is broken
New submission from Rob Austein : .remove() method of MH class in the mailbox module of the standard library references a file object after closing it. This throws a ValueError exception (I/O operation on closed file). The f.close() call just before the os.remove() call in the innermost try: block should just be removed, the finally: clause of the outer try: block will clean things up correctly. As far as I know it is completely legal (if slightly unusual) to delete an open file on any unix-like operating system, and the locking semantics won't work correctly otherwise in any case. -- components: Library (Lib) messages: 97185 nosy: sraustein severity: normal status: open title: mailbox.MH.remove() lock handling is broken type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Rob Renaud added the comment:
I am totally new to Python dev. I reinvented a NamedTupleReader
tonight, only to find out that it was created a year ago. My primary
motivation is that DictReader reads headers nicely, but DictWriter
totally sucks at handling them.
Consider doing some filtering on a csv file, like so.
sample_data = [
'title,latitude,longitude',
'OHO Ofner & Hammecke Reinigungsgesellschaft mbH,48.128265,11.610848',
'Kitchen Kaboodle,45.544241,-122.715728',
'Walgreens,28.339727,-81.596367',
'Gurnigel Pass,46.731944,7.447778'
]
def filter_with_dict_reader_writer():
accepted_rows = []
for row in csv.DictReader(sample_data):
if float(row['latitude']) > 0.0 and float(row['longitude']) > 0.0:
accepted_rows.append(row)
field_names = csv.reader(sample_data).next()
output_writer = csv.DictWriter(open('accepted_by_dict.csv', 'w'),
field_names)
output_writer.writerow(dict(zip(field_names, field_names)))
output_writer.writerows(accepted_rows)
You have to work so hard to maintain the headers when you write the file
with DictWriter. I understand this is a limitation of dicts throwing
away the order information. But namedtuples don't have that problem.
NamedTupleReader and NamedTupleWriter should be inverses. This means
that NamedTupleWriter needs to write headers. This should produce
identical output as the dict writer example, but it's much cleaner.
def filter_with_named_tuple_reader_writer():
accepted_rows = []
for row in csv.NamedTupleReader(sample_data):
if float(row.latitude) > 0.0 and float(row.longitude) > 0.0:
accepted_rows.append(row)
output_writer = csv.NamedTupleWriter(
open('accepted_by_named_tuple.csv', 'w'))
output_writer.writerows(accepted_rows)
I patched on top of the existing NamedTupleWriter patch adding support
for writing headers. I don't know if that's bad style/etiquette, etc.
--
nosy: +rrenaud
Added file: http://bugs.python.org/file13187/named_tuple_write_header.patch
___
Python tracker
<http://bugs.python.org/issue1818>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Rob Renaud added the comment: My previous patch could write the header twice. But I am not sure about about how the writer should handle the fieldnames parameter on one hand, and the namedtuple._fields on the other. Added file: http://bugs.python.org/file13188/named_tuple_write_header2.patch ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Changes by Rob Renaud : Removed file: http://bugs.python.org/file13187/named_tuple_write_header.patch ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Rob Renaud added the comment: I want to make sure I understand. Am I correct in believing that Skip thinks writing headers should be optional, while Jervis believes we should leave the burden to the NamedTupleWriter client? I agree that we should not unconditionally write headers, but I think that we should write headers by default, much like we read them by default. I believe the implicit header writing is very elegant, and the only reason that the DictWriter object doesn't write headers is the impedance mismatch between dicts and CSV. namedtuples has the field order information, the impedance mismatch is gone, we should no longer be hindered. Implicitly reading but not explicitly writing headers just seems wrong. It also seems wrong to require the construction of "header" namedtuple objects. It's much less natural than dicts holding identity mappings. >>> Point._make(Point._fields) Point(x='x', y='y') To me, that just looks weird and non-obvious to me. That Point instance doesn't really fit in my mind as something that should be a Point. ___ Python tracker <http://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Rob Renaud added the comment:
I did a search on Google code for the DictReader constructor. I
analyzed the first 3 pages, the fieldnames parameter was used in 14 of
27 cases (discounting unittest code built into Python) and was not
used in 13 of 27 cases. I suppose that means headered csv files are
sufficiently rare that they shouldn't be created implicitly by
default. I still don't like the lack of symmetry of supporting
implicit header reads, but not implicit header writes.
On Thu, Feb 26, 2009 at 8:00 PM, Skip Montanaro wrote:
>
> Skip Montanaro added the comment:
>
> More concretely, I don't think this is so onerous:
>
>names = ["col1", "col2", "color"]
>writer = csv.DictWriter(open("f.csv", "wb"), fieldnames=names, ...)
>writer.writerow(dict(zip(names, names)))
>...
>
> or
>
>f = open("f.csv", "rb")
>names = csv.reader(f).next()
>reader = csv.DictReader(f, fieldnames=names, ...)
>...
>
> Skip
>
> ___
> Python tracker
> <http://bugs.python.org/issue1818>
> ___
>
___
Python tracker
<http://bugs.python.org/issue1818>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1551113] random.choice(setinstance) fails
Rob Renaud added the comment: I found this via google search when disappointed that random.choice raised an exception rather than returned a random item in the set. It's quite easy to implement random.choice for sets/dicts in O(1) expected time from the C implementation as long as the set/dict implementation guarantees minimal constant density. Simply generate random indices in the set object until one with an object is found . This has will work in expected O(1/density) probes. I suppose making random.choice work for sets/dicts isn't worth a C implementation (as happy as it would have made me a few hours ago...)? -- nosy: +rrenaud ___ Python tracker <http://bugs.python.org/issue1551113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19500] Add client-side SSL session resumption
Rob Reilink added the comment: With this code in place, ftplib should / could also be updated to support session resumption. This would fix bugs with connections to FTP servers that require session resumption [1], [2] In ftplib.FTP_TLS.ntransfercmd, just add a reference to the current session in the wrap_socket call (maybe make this an option to do session resumption or not; I don't know if it could break something) Proposed patch is attached. [1] http://stackoverflow.com/questions/14659154/ftpes-session-reuse-required [2] https://forum.filezilla-project.org/viewtopic.php?t=36903 -- nosy: +robr Added file: http://bugs.python.org/file46409/ftplib_session.patch ___ Python tracker <http://bugs.python.org/issue19500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
New submission from Rob Bairos: python 3.5: wininst-14.0.exe Is triggering Microsoft Security Essentials virus detection: Recommended action: Remove this software immediately. Items: file:D:\PythonBuilds\202ee57ca3\py\Lib\distutils\command\wininst-14.0.exe I've tried on two separate machines so far, with same quarantine. Microsoft Security Essentials (running on Windows 7) Antimalware Client Version: 4.9.218.0 Engine Version: 1.1.12805.0 Antivirus definition: 1.223.2544.0 Antispyware definition: 1.223.2544.0 Network Inspection System Engine Version: 2.1.12706.0 Network Inspection System Definition Version: 116.10.0.0 -- components: Distutils messages: 269186 nosy: Rob Bairos, dstufft, eric.araujo priority: normal severity: normal status: open title: executuable in distutils triggering microsoft anti virus type: security versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
Rob Bairos added the comment: thanks for the quick action! -- ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
Rob Bairos added the comment: Great. Thanks for the update On Tue, Jun 28, 2016 at 2:37 PM, Steve Dower wrote: > > Steve Dower added the comment: > > FYI the definitions have been updated and I'm no longer seeing the false > positive. > > Definition version: 1.223.2858.0 > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27383> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27144] concurrent.futures.as_completed() memory inefficiency
Changes by Rob Nester : -- nosy: +rnester ___ Python tracker <http://bugs.python.org/issue27144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25464] Tix HList header_exists should be "exist"
New submission from Rob Williscroft: The method header_exists of Tix HList raises: File "...\python3\lib\tkinter\tix.py", line 926, in header_exists return self.tk.call(self._w, 'header', 'exists', col) _tkinter.TclError: unknown option "exists". Must be cget, configure, create, delete, exist or size IOW the option should be "exist" not "exists". I've seen this on Windows with python 2.7 and 3.4 and Linux-Mint with 2.7.6. The current method "header_exists" doesn't seem to be referenced or documented anywhere. -- components: Tkinter files: Lib-tkinter-tix-header_exist.patch keywords: patch messages: 253357 nosy: rtw priority: normal severity: normal status: open title: Tix HList header_exists should be "exist" type: crash versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file40842/Lib-tkinter-tix-header_exist.patch ___ Python tracker <http://bugs.python.org/issue25464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25535] collections.Counter methods return Counter objects
New submission from Rob Malouf: Several collections.Counter methods return Counter objects, which is leads to wrong or at least confusing behavior when Counter is subclassed. For example, nltk.FreqDist is a subclass of Counter: >>> x = nltk.FreqDist(['a','a','b','b','b']) >>> y = nltk.FreqDist(['b','b','b','b','b']) >>> z = x + y >>> z.__class__ This applies to __add__(), __sub__(), __or__(), __and__(), __pos__(), and __neg__(). In contrast, the copy() method does (what I think is) the right thing: >>> x.copy().__class__ -- components: Library (Lib) messages: 253930 nosy: rmalouf priority: normal severity: normal status: open title: collections.Counter methods return Counter objects type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16251] pickle special methods are looked up on the instance rather than the type
Changes by Rob Agar : -- nosy: +robagar ___ Python tracker <http://bugs.python.org/issue16251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26572] urlparse does not handle passwords with ? in them.
New submission from Rob Church:
>>> urlparse('http://user:pass?w...@example.com/path?query')
ParseResult(scheme='http', netloc='user:pass', path='', params='',
query='w...@example.com/path?query', fragment='')
Expected output is:
ParseResult(scheme='http', netloc='user:pass?w...@example.com', path='/path',
params='', query='query', fragment='')
--
components: Library (Lib)
messages: 261860
nosy: Rob Church
priority: normal
severity: normal
status: open
title: urlparse does not handle passwords with ? in them.
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue26572>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23950] Odd behavior with "file" and "filename" attributes in cgi.FieldStorage
New submission from Rob King: Hello, everyone. I've noticed an issue that could be just a documentation inaccuracy or a genuine, minor bug in cgi.FieldStorage. The documentation for the module states: "You can test for an uploaded file by testing either the filename attribute or the file attribute." However, I've noticed that on a form submission that includes both a file field and a normal form field, *all* of the members of the form have a non-None "file" attribute, while only the actual uploaded file has a non-None "filename" attribute. This would appear to be caused by the cgi module's use of MiniFieldStorage for in some situations, and FieldStorage in others. The FieldStorage class (if I'm reading the code correctly) would appear to always have a non-None "file" attribute but may have a None "filename" attribute. This makes the documentation for the module unclear, as testing for a non-None "file" attribute will always return True in cases of FieldStorage, even if the particular field is not actually a file. I would suggest modifying the documentation to say something like: "You can test for an uploaded file by testing the filename attribute." Please let me know if I'm missing something, that's always also a possibility. :) -- messages: 240942 nosy: deadpixi priority: normal severity: normal status: open title: Odd behavior with "file" and "filename" attributes in cgi.FieldStorage versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23952] Document the 'maxlen' member of the cgi module
Changes by Rob King : -- versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue23952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23952] Document the 'maxlen' member of the cgi module
New submission from Rob King: The cgi module has a global variable, 'maxlen', that specifies the maximum length of a POST request. By default, this limit is 0, meaning an unlimited POST request size. Having an unlimited default opens up CGI scripts to resource-exhaustion attacks. Setting the maxlen variable to a nonzero integer solves this problem, but this fix is not in the official documentation - neither the reference manual nor the module's docstring. I would recommend augmenting the module's docstring with the following statement: "The maxlen variable can be set to an integer indicating the maximum size of a POST request. POST requests larger than this size will result in a ValueError being raised during parsing. The default value of this variable is 0, meaning the request size is unlimited." -- messages: 240965 nosy: deadpixi priority: normal severity: normal status: open title: Document the 'maxlen' member of the cgi module versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28340] TextIOWrapper.tell extremely slow
New submission from Rob Malouf: io.TextIOWrapper.tell() is unusably slow in Python 2.7. This same problem was introduced in Python 3 and fixed in Python 3.3 (see Issue # 4). Any chance of getting the fix backported into the Python 2.7 library? It would make it much easier to modernize Unicode handling in libraries that have to support both 2 and 3 using the same codebase. -- components: IO messages: 277898 nosy: rmalouf priority: normal severity: normal status: open title: TextIOWrapper.tell extremely slow type: performance versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue28340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Changes by Rob la Lau : -- nosy: +ohreally ___ Python tracker <http://bugs.python.org/issue11245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
