[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: I am not sure if that solves anything (other than the fact that __new__ is much less common to implement than __init__), but I may just be slow to pick up the implications of moving the check to __new__

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Guido, it looks like you replied while I was typing my reply out. Yurii can correct me here but I believe PR #27543 was an attempt to disallow defining `__init__` on a Protocol completely. What I proposed above is the opposite behavior, while still

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Agreed. What if we allow protocols that implement `__init__` but still disallow instantiating a protocol that does not? It's a 1 line change, all existing tests pass and it would still catch what I think was the original intention (tryi

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Change by Adrian Garcia Badaracco : -- pull_requests: +29750 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/31628 ___ Python tracker <https://bugs.python.org/issu

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: Apologies if that was noise, I filed an issue on the MyPy issue tracker: https://github.com/python/mypy/issues/12261 -- ___ Python tracker <https://bugs.python.org/issue44

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Adrian Garcia Badaracco added the comment: While this is figured out, would it be possible to remove the silent overriding? This seems like something type checkers should be doing, not silent runtime modification of classes. Pyright already (correctly) checks this, so I think it would just

[issue17005] Add a topological sort algorithm

Adrian Garcia Badaracco added the comment: As part of working on a tool that deals with dependencies, I was building my own topological sort. I iterated through various APIs (iterable of tasks, iterable of parallelizable groups of tasks, etc.) until I found the (now stdlib) version which

[issue26175] Fully implement IOBase abstract on SpooledTemporaryFile

Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue26175> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

Change by Adrian Garcia Badaracco : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue44834> ___ ___ Python-bugs-list mailing list Unsub

[issue42815] new thread doesn't copy context of the parent thread

Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue42815> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior

New submission from Adrian Garcia Badaracco : I recently tried to use `contextvars.Context.run` w/ coroutines, expecting the same behavior as with regular functions, but it seems that `contextvars.Context.run` does not work w/ coroutines. I'm sorry if this is something obvious to do wit

[issue42369] Reading ZipFile not thread-safe

Change by Jen Garcia : -- nosy: +cuibonobo ___ Python tracker <https://bugs.python.org/issue42369> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40108] Improve error message for -m option when .py is present

Change by Jay Cee Garcia : -- components: +XML type: -> behavior ___ Python tracker <https://bugs.python.org/issue40108> ___ ___ Python-bugs-list mai

[issue30212] test_ssl.py is broken in Centos7

David Antonio Garcia Campos added the comment: Hello Victor, I just saw your message. I will try to setup my enviorment and will come back to you. BR David Garcia -- nosy: +David Antonio Garcia Campos ___ Python tracker <https://bugs.python.

[issue28642] csv reader losing rows with big files and tab delimiter

Marc Garcia added the comment: I agree that for my case, I was using the wrong quoting parameter, and if I specify that my file has no quotes, it works as expected. But I still think that in a different case, when a file do have quotes, but they are not paired, it'd be better to rai

[issue28642] csv reader losing rows with big files and tab delimiter

Marc Garcia added the comment: I could research a bit more on the problem. This is a minimal code that reproduces what happened: from io import StringIO import csv csv_file = StringIO('''1\t"A 2\tB''') reader = csv.reader(csv_file

[issue28642] csv reader losing rows with big files and tab delimiter

Marc Garcia added the comment: Sorry, my fault. It looks like having quotes in the file was the problem. As mentioned, adding the quoting parameter fixes the problem. I'd assume that if quotes are not paired, csv should raise an exception. And I don't think that all the different

[issue28642] csv reader loosing rows with big files and tab delimiter

New submission from Marc Garcia: I'm using the csv module from Python standard library, to read a 1.4Gb file with 11,157,064 of rows. The file is the Geonames dataset for all countries, which can be freely downloaded [1]. I'm using this code to read it: import csv

[issue21609] Documentation for datetime.datetime uses microseconds instead of microsecond

Miquel Garcia added the comment: My mistake. Yes you are right, I was confused with the timedelta class. Sorry for the confusion. Many thanks! Miquel -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.p

[issue21609] Documentation for datetime.datetime uses microseconds instead of microsecond

New submission from Miquel Garcia: In browsing the documentation for datetime.datetime: https://docs.python.org/2/library/datetime.html It states that the datetime.datetime.microseconds returns the number of microseconds but in trying (Python 2.7.1 r271:86832): import datetime print

[issue21109] tarfile: Traversal attack vulnerability

Daniel Garcia added the comment: The solution in the patch is based on the gnutar solution to this, removing the prefix when extracting and adding. -- ___ Python tracker <http://bugs.python.org/issue21

[issue21109] tarfile: Traversal attack vulnerability

New submission from Daniel Garcia: The application does not validate the filenames inside the tar archive, allowing to extract files in arbitrary path. An attacker can craft a tar file to override files. I've view this vulnerability in libtar: http://lwn.net/Vulnerabilities/587141/

[issue18171] os.path.expanduser does not use the system encoding

Pascal Garcia added the comment: Sorry for this error. Thanks for the solution. Here is the code as I modify it. wrkdir= os.path.expanduser("~"+os.sep) loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1]

[issue18171] os.path.expanduser does not use the system encoding

Pascal Garcia added the comment: Here are 2 logs one with the default site.py forcing defaultencoding to ascii, and the other to utf8. You can see that the home dir includes accents : Pépé Not an insult to anybody but this stupid computer :) When I force using the locale.getdefaultlocale() as

[issue18171] os.path.expanduser does not use the system encoding

New submission from Pascal Garcia: The name of the user contains accents under windows. This error occurs when using the function. expaduser("~") UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 10: ordinal not in range(128) ascii i

[issue12412] non defined representation for pwd.struct_passwd

New submission from Francisco Garcia : pwd.struct_passwd has different representations in cpython 2.7.2 and pypy 1.5 A unit test from cpython might enforce the same representation across interpreters: >>> print pwd.getpwuid(os.getuid()) Current cpython output: pwd.struct_passw

[issue4897] PyIter_Next documentation inconsistent with implementation

garcia added the comment: Thanks for the quick response. I see that the discussion in 3720 implicitly involves the implementation of PyIter_Next, but the documentation for PyIter_Next (and its conflict with the implementation) is not mentioned

[issue4901] inconsistent API docs for tp_iter

New submission from garcia : Page 107 of api.pdf says that Py_TPFLAGS_HAVE_ITER is set if the type object has the tp_iter and tp_iternext fields, but on page 109, preceding the documentation of tp_iter and tp_iternext, it says "the next two fields only exist if the Py_TPFLAGS_HAVE_CLASS

[issue4897] PyIter_Next documentation inconsistent with implementation

New submission from garcia : The documentation for PyIter_Next says it will raise TypeError if the object passed to it is not an iterator. However, the implementation in abstract.c performs an assert rather than raising TypeError. I would prefer if the implementation were adjusted to match

[issue4763] PyErr_GivenExceptionMatches documentation out of date

New submission from garcia : The documentation for PyErr_GivenExceptionMatches states that "If given is NULL, a memory access violation will occur." However, looking at the code, this is not the case: the function returns 0 (read: false). It appears, rather, that this funct

[issue3502] Inconsistency between string.letters and default encoding.

New submission from Ramon Garcia <[EMAIL PROTECTED]>: In python on Windows, under Idle, the string.letters includes extended characters. But the default codec, used when translating from string to unicode, is still ascii. This behaviour causes crashes with python win32 exte