[issue46922] tarfile.TarFile.next() crashes on empty tar files
New submission from progval : Hi, I found two related bugs when calling tarfile.TarFile.next() on an empty tar file, both when trying to seek when it should not: import io import tarfile # Create a tarball with no member: fd = io.BytesIO() with tarfile.open(fileobj=fd, mode="w") as tf: pass # read in stream mode: fd.seek(0) with tarfile.open(fileobj=fd, mode="r|") as tf: print(tf.next()) # tarfile.StreamError: seeking backwards is not allowed # read in normal mode: fd.seek(0) with tarfile.open(fileobj=fd, mode="r") as tf: print(tf.next()) # ValueError: negative seek value -1 -- components: Library (Lib) messages: 414536 nosy: progval priority: normal severity: normal status: open title: tarfile.TarFile.next() crashes on empty tar files versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30268] Make mimetypes.guess_type accept path-like objects
ProgVal added the comment: @r.david.murray I don't think it's a bug either, but a possible enhancement. @serhiy.storchaka We could simply do this: if isinstance(url, bytes): url = os.fsdecode(url) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30268] Make mimetypes.guess_type accept path-like objects
New submission from ProgVal:
The documentation for mimetypes.guess_type says that it “guesses the type of a
file based on its filename or URL”.
However, this function only accepts a string object, and not a bytes object:
>>> import os
>>> import mimetypes
>>> mimetypes.guess_type(os.listdir(os.fsencode('./'))[0])
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.7/mimetypes.py", line 291, in guess_type
return _db.guess_type(url, strict)
File "/usr/lib/python3.7/mimetypes.py", line 116, in guess_type
scheme, url = urllib.parse.splittype(url)
File "/usr/lib/python3.7/urllib/parse.py", line 924, in splittype
match = _typeprog.match(url)
TypeError: cannot use a string pattern on a bytes-like object
--
components: Library (Lib)
messages: 292995
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: Make mimetypes.guess_type accept path-like objects
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30268>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30267] Deprecate os.path.commonprefix
New submission from ProgVal: The function os.path.commonprefix computes the longest prefix of strings (any iterable, actually), regardless of their meaning as paths. I do not see any reason to use this function for paths, and keeping it in the os.path module makes it prone to be confused with os.path.commonpath (which was introduced in Python 3.5). I believe making this function raise a DeprecationWarning would help avoid having this kind of bugs. -- components: Library (Lib) messages: 292993 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: Deprecate os.path.commonprefix ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29646] ast.parse parses string literals as docstrings
ProgVal added the comment: Indeed, thanks. I should have done that when I migrated from compiler.parse. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29646] ast.parse parses string literals as docstrings
ProgVal added the comment: (Oops, submitted too soon.) I understand the rational of this change, so I am not sure if this is actually a bug. However, if someone wants to parse a simple expression that may be a string, they need to add a special handling in case it's a string interpreted as a module docstring. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29646] ast.parse parses string literals as docstrings
New submission from ProgVal:
Since commit cb41b2766de646435743b6af7dd152751b54e73f (Python 3.7a0), string
literals are not parsed the same way.
ast.parse("'test'").body used to be a list with one item containing 'test'; but
now it is an empty list:
Python 3.5.2+ (default, Dec 13 2016, 14:16:35)
[GCC 6.2.1 20161124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> print(ast.parse("'test'"))
<_ast.Module object at 0x7fa37ae4c630>
>>> print(ast.parse("'test'").body)
[<_ast.Expr object at 0x7fa37ae4c630>]
>>> print(ast.parse("'test'").docstring)
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Module' object has no attribute 'docstring'
Python 3.7.0a0 (default, Feb 24 2017, 21:38:30)
[GCC 6.3.0 20170205] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> print(ast.parse("'test'"))
<_ast.Module object at 0x7fe2aa415eb8>
>>> print(ast.parse("'test'").body)
[]
>>> print(ast.parse("'test'").docstring)
test
--
components: Interpreter Core
messages: 288553
nosy: Valentin.Lorentz, inada.naoki
priority: normal
severity: normal
status: open
title: ast.parse parses string literals as docstrings
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29646>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
ProgVal added the comment: > On Linux 3.16? 4.7? What is difference between 3.16 and 4.7? On 4.8 (which has the same issue as 4.7). The difference is that on 4.7, the rlimit has to be set incredibly high for the child process not to hit the limit. > Again, I doubt Python's memory consumption increased by Linux version. > Isn't rlimit more strict for now? That's what I think too, because I would have noticed if the interpreter actually started using 20MB for such a simple operation. > Even if memory usage is really grow, I don't think it's a Python's issue. > Maybe, environment issue or kernel issue. I agree. But I don't know how to reproduce this issue without multiprocessing.Queue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
ProgVal added the comment: first command: (0, 0) 0.14user 0.01system 0:00.94elapsed 16%CPU (0avgtext+0avgdata 18484maxresident)k 560inputs+0outputs (0major+2702minor)pagefaults 0swaps second command: (6663744, 6732519) 0.18user 0.01system 0:00.96elapsed 20%CPU (0avgtext+0avgdata 22572maxresident)k 480inputs+0outputs (2major+4081minor)pagefaults 0swaps -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28922] Add fixer for "import exceptions"
New submission from ProgVal: Hi, Here is a fixer to remove "import exceptions" from Python 2 code and replace "exceptions.X" with "X". Valentin -- components: 2to3 (2.x to 3.x conversion tool) files: fix_import_exceptions.py messages: 282787 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: Add fixer for "import exceptions" type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45817/fix_import_exceptions.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
ProgVal added the comment: Sorry. That's the result of |||get_traced_memory|on Python 3.5 and Linux 4.7. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
ProgVal added the comment: (4350362, 4376669) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
Changes by ProgVal <prog...@gmail.com>: -- versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28663] Higher virtual memory usage on recent Linux versions
New submission from ProgVal: Hi, I use `resource.setrlimit(resource.RLIMIT_DATA, ...)` to limit the memory usage of a child process. I noticed that on recent Linux versions, my processes are much more likely to raise MemoryError or behave inconsistently (which I believe is caused by a MemoryError being silently ignored somewhere). With Linux 4.7 under Python 3.4 (tested on a Debian 8.0 chroot) and 3.5 (tested on Debian Testing and Unstable), the attached script crashes on the `assert False`, which it should not encounter since all execution paths go through a `q.put`. With Linux 3.16 under Python 3.4 (tested on a Debian 8.0 virtual machine), the attached script terminates without an error. Even when restricting the memory to 1MB instead of 10MB, it still works. It may look like I just have to increase the limit to a larger value, eg. 20MB. However, when there is more imported modules in the parent process, the required value gets incredibly high (eg. 1GB). -- components: Interpreter Core files: rlimit_difference_linux_versions.py messages: 280566 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: Higher virtual memory usage on recent Linux versions versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45438/rlimit_difference_linux_versions.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28326] multiprocessing.Process depends on sys.stdout being open
New submission from ProgVal: Hello, The following code: import sys import multiprocessing sys.stdout.close() def foo(): pass p = multiprocessing.Process(target=foo) p.start() Crashes with: Traceback (most recent call last): File "foo.py", line 10, in p.start() File "/usr/lib/python3.5/multiprocessing/process.py", line 105, in start self._popen = self._Popen(self) File "/usr/lib/python3.5/multiprocessing/context.py", line 212, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/context.py", line 267, in _Popen return Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 17, in __init__ sys.stdout.flush() ValueError: I/O operation on closed file. This bug has been reported to me on a daemonized program (written prior to PEP 3143). -- components: Library (Lib) messages: 277807 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: multiprocessing.Process depends on sys.stdout being open versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27023] Documentation of tempfile.gettempdir() does not mention it only supports existing directories
ProgVal added the comment: I know, that's why I did not ask to change the code. Only the doc to make that behavior more explicit. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27023] Documentation of tempfile.gettempdir() does not mention it only supports existing directories
ProgVal added the comment: The directory could be created -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27023] Documentation of tempfile.gettempdir() does not mention it only supports existing directories
New submission from ProgVal: Documentation of tempfile.gettempdir() <https://docs.python.org/3/library/tempfile.html#tempfile.gettempdir> does not mention it only supports existing directories. This led to this question on Stackoverflow: http://stackoverflow.com/q/37229398/539465 -- assignee: docs@python components: Documentation, Library (Lib) messages: 265539 nosy: Valentin.Lorentz, docs@python priority: normal severity: normal status: open title: Documentation of tempfile.gettempdir() does not mention it only supports existing directories versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26845] Misleading variable name in exception handling
New submission from ProgVal:
In Python/errors.c, PyErr_Restore is defined this way:
void
PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback)
In Python/ceval.c, in the END_FINALLY case, it is called like this:
PyErr_Restore(status, exc, tb);
I believe “exc” should be renamed to “val”.
Indeed, END_FINALLY pops values from the stack like this:
PyObject *status = POP();
// ...
else if (PyExceptionClass_Check(status)) {
PyObject *exc = POP();
PyObject *tb = POP();
PyErr_Restore(status, exc, tb);
And, they are pushed like this, in fast_block_end:
PUSH(tb);
PUSH(val);
PUSH(exc);
--
components: Interpreter Core
messages: 264198
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: Misleading variable name in exception handling
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26845>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26640] xmlrpc.server imports xmlrpc.client
ProgVal added the comment: Even if xmlrpc.client imported them in its namespace? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26640] xmlrpc.server imports xmlrpc.client
New submission from ProgVal: from xmlrpc.client import Fault, dumps, loads, gzip_encode, gzip_decode Shouldn't these class/functions be moved to a new module, with a name like xmlrpc.common? -- components: Library (Lib) messages: 262428 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: xmlrpc.server imports xmlrpc.client type: enhancement versions: Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26442] Doc refers to xmlrpc.client but means xmlrpc.server
New submission from ProgVal: The doc of xmlrpc.server and xmlrpc.client both warn about XML vulnerabilities. However, both say “The xmlrpc.client module is not secure”, whereas the page for xml.server should say xmlrpc.server. -- assignee: docs@python components: Documentation messages: 260892 nosy: Valentin.Lorentz, docs@python priority: normal severity: normal status: open title: Doc refers to xmlrpc.client but means xmlrpc.server versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25951] SSLSocket.sendall() does not return None on success like socket.sendall()
New submission from ProgVal: socket.sendall() returns None if it succeeded <https://docs.python.org/3/library/socket.html#socket.socket.sendall> SSLSocket.sendall() is said to have the same behavior as socket.sendall(), besides not allowing flags <https://docs.python.org/3/library/ssl.html#ssl.SSLSocket> However, SSLSocket.sendall() returns the amount of bytes written on success. -- components: Library (Lib) messages: 256992 nosy: ProgVal priority: normal severity: normal status: open title: SSLSocket.sendall() does not return None on success like socket.sendall() versions: Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21429] Input.output error with multiprocessing
ProgVal added the comment: The relevant piece of code: https://github.com/ProgVal/Limnoria/blob/master/plugins/Web/plugin.py#L85 commands.process is defined here: https://github.com/ProgVal/Limnoria/blob/master/src/commands.py#L76 callbacks.CommandProcess is defined at https://github.com/ProgVal/Limnoria/blob/master/src/callbacks.py#L1037 (SupyThread is a small subclass of threading.Thread, which increments a count on initialization) -- nosy: +Valentin.Lorentz status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18477] fix_import (2to3 fixer) is not case-sensitive
New submission from ProgVal: In a project, I have a package with a module named Socket.py, and the __init__.py imports the socket module (from the standard Python lib). However, when fix_import went over it _on Windows_, it converted import socket to from . import Socket. I also had this issue from a package containing a subpackage named Math, and a __init__.py importing math (from the standard Python lib). This issue is caused by using os.path.exists(), which is case-insensitive on Windows. However, PEP 235 says imports are case-sensitive. I'm including a patch I have wrote for this. -- components: 2to3 (2.x to 3.x conversion tool), Windows files: fix_case-sensitivity_of_fix-import.patch keywords: patch messages: 193193 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: fix_import (2to3 fixer) is not case-sensitive type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30942/fix_case-sensitivity_of_fix-import.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17953] sys.modules cannot be reassigned
New submission from ProgVal:
In Python 3.3 (I did not test with 3.4), sys.modules cannot be reassigned
without breaking the import mechanism; while it works with Python = 3.2.
Here is how to reproduce the bug:
progval@Andromede:/tmp$ mkdir test_imports
progval@Andromede:/tmp$ echo from . import module test_imports/__init__.py
progval@Andromede:/tmp$ echo print('foo') test_imports/module.py
progval@Andromede:/tmp$ python3.3
Python 3.3.1 (default, Apr 6 2013, 13:58:40)
[GCC 4.7.2] on linux
Type help, copyright, credits or license for more information.
import sys
sys.modules = dict(sys.modules)
import test_imports
Traceback (most recent call last):
File stdin, line 1, in module
File ./test_imports/__init__.py, line 1, in module
from . import module
SystemError: Parent module 'test_imports' not loaded, cannot perform relative
import
progval@Andromede:/tmp$ python3.2
Python 3.2.3 (default, May 6 2013, 01:46:35)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
import sys
sys.modules = dict(sys.modules)
import test_imports
foo
--
components: Interpreter Core
messages: 188901
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: sys.modules cannot be reassigned
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17953
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17856] multiprocessing.Process.join does not block if timeout is lower than 1
New submission from ProgVal: In Python 3.3, multiprocessing.Process.join() is not blocking with floats lower than 1.0 (not included). It works as expected (ie. blocking for the specified timeout) in Python 2.6-3.2 As you can see in this example, calling join() with 0.99 returns immediately. $ python3.3 Python 3.3.1 (default, Apr 6 2013, 13:58:40) [GCC 4.7.2] on linux Type help, copyright, credits or license for more information. import time import multiprocessing def foo(): ... time.sleep(1000) ... p = multiprocessing.Process(target=foo) p.start() bar = time.time(); p.join(0.99); print(time.time()-bar) 0.015963315963745117 p.is_alive() True bar = time.time(); p.join(1.0); print(time.time()-bar) 1.0011239051818848 p.is_alive() True -- components: Library (Lib) messages: 187916 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: multiprocessing.Process.join does not block if timeout is lower than 1 type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11130] SocketServer: server_address is... a socket
New submission from ProgVal prog...@gmail.com:
Hello,
I have issues with a script I'm programming (TypeError at every client
connection), so I edited BaseServer's __init__():
def __init__(self, server_address, RequestHandlerClass):
Constructor. May be extended, do not override.
if isinstance(server_address, socket._socketobject):
raise Exception()
self.server_address = server_address
self.RequestHandlerClass = RequestHandlerClass
self.__is_shut_down = threading.Event()
self.__shutdown_request = False
And it raises sometimes this traceback:
Exception happened during processing of request from ('127.0.0.1', 32810)
Traceback (most recent call last):
File /usr/lib/python2.6/SocketServer.py, line 285, in
_handle_request_noblock
self.process_request(request, client_address)
File /usr/lib/python2.6/SocketServer.py, line 311, in process_request
self.finish_request(request, client_address)
File /usr/lib/python2.6/SocketServer.py, line 324, in finish_request
self.RequestHandlerClass(request, client_address, self)
File /usr/lib/python2.6/SocketServer.py, line 400, in __init__
BaseServer.__init__(self, server_address, RequestHandlerClass)
File /usr/lib/python2.6/SocketServer.py, line 198, in __init__
raise Exception()
Best regards,
ProgVal
--
components: Library (Lib)
messages: 127999
nosy: ProgVal
priority: normal
severity: normal
status: open
title: SocketServer: server_address is... a socket
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11130] SocketServer: server_address is... a socket
ProgVal prog...@gmail.com added the comment:
The problem happens on Python 2.7 too.
Additionaly, here is the traceback, if I don't edit the library:
Exception happened during processing of request from ('127.0.0.1', 50378)
Traceback (most recent call last):
File /usr/lib/python2.7/SocketServer.py, line 284, in
_handle_request_noblock
self.process_request(request, client_address)
File /usr/lib/python2.7/SocketServer.py, line 310, in process_request
self.finish_request(request, client_address)
File /usr/lib/python2.7/SocketServer.py, line 323, in finish_request
self.RequestHandlerClass(request, client_address, self)
File /usr/lib/python2.7/SocketServer.py, line 408, in __init__
self.server_bind()
File /usr/lib/python2.7/SocketServer.py, line 419, in server_bind
self.socket.bind(self.server_address)
File /usr/lib/python2.7/socket.py, line 224, in meth
return getattr(self._sock,name)(*args)
TypeError: getsockaddrarg: AF_INET address must be tuple, not _socketobject
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11130] SocketServer: server_address is... a socket
ProgVal prog...@gmail.com added the comment: This seems odd to me: this line: self.RequestHandlerClass(request, client_address, self) calls TCPServer's constructor: def __init__(self, server_address, RequestHandlerClass, bind_and_activate=True): -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11130] SocketServer: server_address is... a socket
ProgVal prog...@gmail.com added the comment: Oh, excuse me, it's because of my code! class MyRequestHandler(SocketServer.TCPServer): -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
ProgVal prog...@gmail.com added the comment:
Same result on all tested versions (2.5 - 2.7) :
--
import urllib2
import tarfile
tarfile.open(fileobj=open('/home/progval/Downloads/GoodFrench.tar'), mode='r:')
# Works
tarfile.open(fileobj=urllib2.urlopen(urllib2.Request('http://plugins.supybot-fr.tk/GoodFrench.tar')),
mode='r:') # Fails
--
I don't understand, because /home/progval/Downloads/GoodFrench.tar is the same
file...
I don't know if I have the skills to do the patch, I use Python for less than 9
months...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10362
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
ProgVal prog...@gmail.com added the comment:
This code :
import urllib2
print urllib2.urlopen('http://plugins.supybot-fr.tk/GoodFrench.tar').read(500)
Prints :
data/75500017517511466030066011677 5ustar progvalprogval
If the problem comes from networking libraries, I really don't have the skills
:s
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10362
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
ProgVal prog...@gmail.com added the comment: I also have the bug with Python 2.7.1rc1 (from Debian 'Experimental' repo) -- nosy: +ProgVal versions: +Python 2.6 -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
New submission from ProgVal prog...@gmail.com: Hello, I had this traceback: Traceback (most recent call last): ... File /home/progval/workspace/Supybot/Supybot-plugins/Packages/plugin.py, line 123, in extractData file = tarfile.open(fileobj=file_) File /usr/lib/python2.6/tarfile.py, line 1651, in open saved_pos = fileobj.tell() AttributeError: addinfourl instance has no attribute 'tell' The repr(file_) is : addinfourl at 47496224 whose fp = socket._fileobject object at 0x2c933d0 (the file has been downloaded with urllib). I use Python 2.6.6 (from Debian Sid repo) Best regards, ProgVal -- messages: 120781 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: AttributeError: addinfourl instance has no attribute 'tell' ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
ProgVal prog...@gmail.com added the comment: Thanks for your answer. Sorry, no change... -- components: +Library (Lib) versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10362] AttributeError: addinfourl instance has no attribute 'tell'
ProgVal prog...@gmail.com added the comment: Here is the new traceback: Traceback (most recent call last): ... File /home/progval/workspace/Supybot/Supybot-plugins/Packages/plugin.py, line 123, in extractData file = tarfile.open(fileobj=file_, mode='r:') File /usr/lib/python2.6/tarfile.py, line 1671, in open return func(name, filemode, fileobj, **kwargs) File /usr/lib/python2.6/tarfile.py, line 1698, in taropen return cls(name, mode, fileobj, **kwargs) File /usr/lib/python2.6/tarfile.py, line 1563, in __init__ self.offset = self.fileobj.tell() AttributeError: addinfourl instance has no attribute 'tell' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
