[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 function always succeeds. -- assignee: georg.brandl components: Documentation messages: 78429 nosy: garcia, georg.brandl severity: normal status: open title: PyErr_GivenExceptionMatches documentation out of date versions: Python 2.5, Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue4763> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the documentation rather than vice-versa. -- components: None messages: 79472 nosy: garcia severity: normal status: open title: PyIter_Next documentation inconsistent with implementation type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue4897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 flag bit is set". Should the latter refer to Py_TPFLAGS_HAVE_ITER? -- assignee: georg.brandl components: Documentation messages: 79487 nosy: garcia, georg.brandl severity: normal status: open title: inconsistent API docs for tp_iter versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue4901> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker <http://bugs.python.org/issue4897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_passwd(pw_name='demo_user', pw_passwd='', pw_uid=1001,
pw_gid=100, pw_gecos='demo_user', pw_dir='/Users/demo_user',
pw_shell='/bin/bash')
Current pypy output
('demo_user', '', 1001, 100, 'demo_user', '/Users/demo_user',
'/bin/bash')
--
messages: 139090
nosy: fgarciar
priority: normal
severity: normal
status: open
title: non defined representation for pwd.struct_passwd
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12412>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 extensions. >>> string.letters 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83\x8a\x8c\x8e\x9a\x9c\x9e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' But still, unless the user customizes the installation, sys.getdefaultencoding() returns ascii. The consequence is that after instating a COM object, pywin32 211 issues this exception: File "C:\Python25\Lib\site-packages\win32com\client\build.py", line 297, in MakeFuncMethod return self.MakeDispatchFuncMethod(entry, name, bMakeClass) File "C:\Python25\Lib\site-packages\win32com\client\build.py", line 318, in MakeDispatchFuncMethod s = linePrefix + 'def ' + name + '(self' + BuildCallList(fdesc, names, defNamedOptArg, defNamedNotOptArg, defUnnamedArg, defOutArg) + '):' File "C:\Python25\Lib\site-packages\win32com\client\build.py", line 604, in BuildCallList argName = MakePublicAttributeName(argName) File "C:\Python25\Lib\site-packages\win32com\client\build.py", line 542, in MakePublicAttributeName return filter( lambda char: char in valid_identifier_chars, className) File "C:\Python25\Lib\site-packages\win32com\client\build.py", line 542, in return filter( lambda char: char in valid_identifier_chars, className) UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 52: ordinal not in range(128) The line that causes this exception is from win32com.client.build. This fragment is enough to reproduce the bug (from build.py in win32com/client): valid_identifier_chars = string.letters + string.digits + "_" ... return filter( lambda char: char in valid_identifier_chars, className) Try to print the expression in the return statement and set className to anything you wish in Unicode. It will crash It is contradictory that the default codec does not allow translation of characters 0x83, and that string.letters includes it. If one regards this character as printable, then it should be encoded successfully. -- components: Windows messages: 70725 nosy: ramong severity: normal status: open title: Inconsistency between string.letters and default encoding. versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is the default encoding as sys.getdefaultencoding()
If in site.py "I enable Enable the support locale" then de defaultencoding
become cp1252 and the function works.
Expand user should use the encoding used by the system (may be
locale.getdefaultlocale()) to decode path given by the system instead of the
default encoding the should be the target encoding.
I do beleave some other functions may be concerned by this problem.
I detect the problem on Windows (WP and 7), but I do beleave the problem may
happen on Linux also.
--
components: Library (Lib)
messages: 190850
nosy: plgarcia
priority: normal
severity: normal
status: open
title: os.path.expanduser does not use the system encoding
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue18171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 encoding then the function works, but, after having called expanduser, I need to make an explicit decode(locale.getdefaultlocale()), or else the string can not be used to build path to files. ==> with ASCII C:\Users\pépé>D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py Traceback (most recent call last): File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py", line 329, in run() File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py", line 206, in run globaldef.initDefs(wd, force) File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\globaldef.py", line 80, in initDefs wrkdir= os.path.expanduser(u"~"+os.sep) File "C:\Python27\lib\ntpath.py", line 301, in expanduser return userhome + path[i:] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 10: ordinal not in range(128) WITH UTF8 : C:\Users\pépé>D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py Traceback (most recent call last): File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py", line 329, in run() File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\scolasync.py", line 206, in run globaldef.initDefs(wd, force) File "D:\DevelopmentWorkspaces\SCOLASYNC\ScolaSyncNG\scolasync-ng\src\globaldef.py", line 80, in initDefs wrkdir= os.path.expanduser(u"~"+os.sep) File "C:\Python27\lib\ntpath.py", line 301, in expanduser return userhome + path[i:] File "C:\Python27\lib\encodings\utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 10: invalid continuation byte -- ___ Python tracker <http://bugs.python.org/issue18171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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]
wrkdir= wrkdir.decode(encoding)
I need to explicitally decode the string if I want to use it and have the next
sentence working a bit further.
os.path.join(wrkdir, u"Tango\\")
Encodding is a very good motivation to go to python3, and if i didn't have
other constraints it would be done for ages.
For this special case I think that function should return strings with the
default encoding, and the programmer should not have to know about the
underground to make the right decode.
But it works, thanks again.
Pascal
--
resolution: invalid ->
status: closed -> open
type: behavior ->
___
Python tracker
<http://bugs.python.org/issue18171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/ I've checked that python tarfile doesn't validate the filenames so python tarfile is vulnerable to this attack. -- components: Library (Lib) files: prevent-tar-traversal-attack.diff keywords: patch messages: 215222 nosy: Daniel.Garcia priority: normal severity: normal status: open title: tarfile: Traversal attack vulnerability type: security versions: Python 3.5 Added file: http://bugs.python.org/file34676/prevent-tar-traversal-attack.diff ___ Python tracker <http://bugs.python.org/issue21109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue21109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 datetime.datetime.now().microseconds The interpreter returns AttributeError: 'datetime.datetime' object has no attribute 'microseconds' The correct way to access the number of microseconds is by: datetime.datetime.now().microsecond # Note the final 's' which is not consistent with the documentation. Many thanks Miquel -- assignee: docs@python components: Documentation messages: 219366 nosy: Miquel.Garcia, docs@python priority: normal severity: normal status: open title: Documentation for datetime.datetime uses microseconds instead of microsecond versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue21609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
with open('allCountries.txt', 'r') as fd:
reader = csv.reader(fd, delimiter='\t')
for i, row in enumerate(reader):
pass
print(i + 1) # prints 10381963
print(reader.line_num) # prints 11157064
For some reason, there are around 7% of the rows in the files, that are
skipped. The rows doesn't have anything special (most of them are all ascii
characters, even if the file is in utf-8).
If I create a new file with all the skipped files, and I read it again in the
same way, around 30% of the rows are skipped. So many of them weren't returned
by the iterator when being a part of a bigger file, but now they are.
Note that the attribute line_num has the right number. Also note that if I
remove the delimiter parameter (tab) from the reader, and it uses the default
comma, the iteration on the reader doesn't skip any row.
I checked what I think it's the relevant part of the code [2], but I couldn't
see anything that could cause this bug.
1. http://download.geonames.org/export/dump/allCountries.zip
2. https://hg.python.org/cpython/file/tip/Modules/_csv.c#l787
--
components: Library (Lib)
messages: 280323
nosy: datapythonista
priority: normal
severity: normal
status: open
title: csv reader loosing rows with big files and tab delimiter
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28642>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 chunks of the file I tested, had always an even number of quotes. Also, I don't understand why using the default delimiter worked well, and with tab delimiter the problem happened. I'll take a look in more detail, but I'm closing this issue. Thank you all a lot for the help! -- resolution: -> not a bug status: open -> closed title: csv reader loosing rows with big files and tab delimiter -> csv reader losing rows with big files and tab delimiter ___ Python tracker <http://bugs.python.org/issue28642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, delimiter='\t')
for i, row in enumerate(reader):
pass
print(reader.line_num) # 2
print(i + 1)# 1
The reason to return the right number of rows with the default delimiter, is
because the quote needs to be immediately after the delimiter to be considered
the opening of a quoted text.
If the file contains an opening quote, and the EOF is reached without its
closing quote, the reader considers all the text until EOF to be that field.
This would work as expected in a line like:
1,"well quoted text","this one has a missing quote
But it'd fail silently with unexpected results in all other cases. I'd expect
csv to raise an exception, more than the current behavior.
Do you agree? Should I create another issue to address this?
--
___
Python tracker
<http://bugs.python.org/issue28642>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 raise an exception, than to ignore the error and assume there is just a missing quote at the end. >From the Zen of Python: "Errors should never pass silently", and I think it's >clear that there is an error in the file. -- ___ Python tracker <http://bugs.python.org/issue28642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 need to be added to MyPy.
>>> class C(Protocol):
... def __init__(self) -> None:
... print('init!')
...
>>> c = C() # Pyright error, MyPy says it's okay
I came across this while trying to create a class that requires concrete
subclasses to define a specific field, and it seems like Protocol is the only
thing that can pull this off because of how type checkers special case it:
https://gist.github.com/adriangb/6c1a001ee7035bad5bd56df70e0cf5e6
I don't particularly like this use of Protocol, but it works (aside from the
overriding issue).
I don't know if this usage of implementing `__init__` on a protocol class
should be valid or not, but I do think it's interesting that `__init__` is
never called on the protocol class itself, even if the protocol class is the
one defining it. It is only called on `MyAPIKey`, which is a concrete class
that happens to inherit the implementation from a protocol class. So maybe that
should be valid? I'm not sure.
But I do know that making type checkers enforce this instead runtime would
allow this use case to work while still prohibiting the (in my opinion invalid)
use case of calling `__init__` on the protocol class itself.
--
nosy: +adriangb
status: pending -> open
___
Python tracker
<https://bugs.python.org/issue44807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (trying to instantiate a Protocol class with no __init__): https://github.com/python/cpython/pull/31628/files#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887 -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 fixing the issue of `__init__` getting silently overridden (which is the crux / title of this issue). I'm not sure which approach is right. -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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__ -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 with how coroutines work under the
hood, if so I'd appreciate some help in understanding why this is the expected
behavior.
```python
import asyncio
import contextvars
ctxvar = contextvars.ContextVar("ctxvar", default="spam")
def func():
assert ctxvar.get() == "spam"
async def coro():
func()
async def main():
ctx = contextvars.copy_context()
ctxvar.set("ham")
ctx.run(func) # works
await ctx.run(coro) # breaks
asyncio.run(main())
```
Thanks!
--
components: Library (Lib)
messages: 398924
nosy: adriangb
priority: normal
severity: normal
status: open
title: contextvars.Context.run w/ coroutines gives inconsistent behavior
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44834>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ended up being exactly the API I needed to most efficiently execute dependencies. So, kudos on the design! I actually ended up re-writing it in Rust, partly because I wanted a good project to learn Rust, partly because I wanted to be able to modify the API a bit. Namely: 1. I needed the ability to re-execute the same DAG multiple times without re-checking for cycles and re-adding all nodes (so basically copying `npredecessors` before executing). 2. I needed the ability to remove nodes from the graph. The real-world application is removing pruning subgraphs corresponding to cached dependencies. Again, I wanted to do this without rebuilding the entire thing (removing nodes can never lead to a cycle, and it is possible to keep track of new leaf nodes as you remove them instead of iterating over the entire graph again to find leaf nodes). Here's the implementation in case anyone is interested: https://github.com/adriangb/graphlib2 The algorithm is the same, but I had to change the data structures somewhat to cope w/ Rusts' borrowing rules (namely I can't hold a mutable reference to two values in `node2nodeinfo` at the same time, which the current implementation does here https://github.com/python/cpython/blob/32f1491a9770b7f2989507ecf8f13ef35dd95b0b/Lib/graphlib.py#L190, so I split them out into two separate mappings). -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue17005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue30212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
