[issue11443] Zip password issue
New submission from Yaroslav :
There's issue while setting password.
I brute-force different passwords for that arhive-file, and it pass with
different, not correct password. For that arhive password is: "pass", but that
arhive is correct in python and even extract files from that with not correct
passwords:
('Password is:', 'aafy')
('Password is:', 'aakv')
('Password is:', 'aavu')
('Password is:', 'aazs')
('Password is:', 'abgj')
('Password is:', 'abmr')
('Password is:', 'abzo')
('Password is:', 'acds')
('Password is:', 'acdu')
('Password is:', 'ace')
('Password is:', 'achc')
('Password is:', 'acue')
('Password is:', 'acxi')
('Password is:', 'adcj')
('Password is:', 'adcl')
('Password is:', 'adde')
('Password is:', 'advx')
('Password is:', 'aenu')
('Password is:', 'afbl')
('Password is:', 'afqg')
('Password is:', 'afyl')
('Password is:', 'agef')
('Password is:', 'agtv')
('Password is:', 'aimo')
('Password is:', 'aizr')
('Password is:', 'ajjt')
('Password is:', 'ajlj')
('Password is:', 'akqr')
...
Of course content of file is not correct ("Q1E85�ڳM��ژo��H*] 5Q���
�� ��X">_+x�������I�k�~L>��
").
z = zipfile.ZipFile("data.zip", 'r')
z.setpassword("aafy")
print(z.read("secretfile.txt"))
--
messages: 130361
nosy: sbojchuk
priority: normal
severity: normal
status: open
title: Zip password issue
versions: Python 2.5, Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue11443>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11443] Zip password issue
Yaroslav added the comment: I forgot zip file -- Added file: http://bugs.python.org/file21052/data.zip ___ Python tracker <http://bugs.python.org/issue11443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11443] Zip password issue
Yaroslav added the comment: Ok, i try that example in new versions 3+, and it works there. Thanks -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue11443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41455] Python Devguide differs from python docs
Yaroslav added the comment: As I can see here https://github.com/python/devguide/blob/master/garbage_collector.rst#collecting-the-oldest-generation > the GC only triggers a full collection of the oldest generation if the ratio > long_lived_pending / long_lived_total is above a given value (hardwired to > 25%) But in the python docs here https://docs.python.org/3.10/library/gc.html#gc.set_threshold > When the number of allocations minus the number of deallocations exceeds > threshold0, collection starts. Initially only generation 0 is examined. If > generation 0 has been examined more than threshold1 times since generation 1 > has been examined, then generation 1 is examined as well. Similarly, > threshold2 controls the number of collections of generation 1 before > collecting generation 2. As I can see here: https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L1456 the first one is correct. We should probably fix python docs accordingly. -- ___ Python tracker <https://bugs.python.org/issue41455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41455] Python Devguide differs from python docs
Yaroslav added the comment: Here's opened PR. https://github.com/python/cpython/pull/21703 -- nosy: -python-dev ___ Python tracker <https://bugs.python.org/issue41455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41511] Pathlib parents doesn't support slicing with negative indexes
New submission from Yaroslav :
As I can see, pathlib path parents don't support slicing with negative indexes:
>>> import pathlib
>>> path = pathlib.PosixPath("some/very/long/path/here")
>>> path.parents[-1]
...
raise IndexError(idx)
IndexError: -1
That's kinda weird for python. I mean, in regular list/etc if I need the last
element, I'd normally do list[-1], but here to get the last parent, I need to
actually know how many parents do I have.
So now, I can do something like this:
>>> parents_count = len(path.parents) - 1
>>> path.parents[parents_count]
PosixPath('.')
So that's how I can get the last parent. But is it pythonic? No.
So, I decided to fix this, and now we can do negative slicing:
>>> path.parents[-1] == path.parents[parents_count]
True
>>> path.parents[-2] == path.parents[parents_count - 1]
True
So what do you guys think about this?
--
components: Library (Lib)
messages: 375076
nosy: ypank
priority: normal
severity: normal
status: open
title: Pathlib parents doesn't support slicing with negative indexes
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue41511>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41511] Pathlib parents doesn't support slicing with negative indexes
Yaroslav added the comment: Here's opened PR: https://github.com/python/cpython/pull/21799 -- ___ Python tracker <https://bugs.python.org/issue41511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
Changes by Yaroslav Bulatov : -- nosy: +yaroslavvb ___ Python tracker <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
Yaroslav Bulatov added the comment: This causes problem for Freetype Python bindings on Linux -- ___ Python tracker <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
Yaroslav Bulatov added the comment: Sorry for confusion, I meant the original problem causes problems. I haven't tested the patch because my target machines don't have gcc -- ___ Python tracker <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10006] non-Pythonic fate of __abstractmethods__
New submission from Yaroslav Halchenko :
We ran into this while generating documentation for our project (PyMVPA) with
recent sphinx and python2.6 (fine with 2.5, failed for 2.6, 2.7, 3.1), which
relies on traversing all attributes given by "dir(obj)", BUT apparently
__abstractmethods__ becomes very special -- it is given by "dir(obj)" since it
is present in obj.__class__, but getattr(obj, "__abstractmethods__") fails for
classes derived from type. E.g. following sample demonstrates it:
print("in type's dir" , '__abstractmethods__' in dir(type))
print(type.__abstractmethods__)
class type3(type):
pass
print("in type3's dir" , '__abstractmethods__' in dir(type3))
print(type3.__abstractmethods__)
results in output:
$> python2.6 trash/type_subclass.py
("in type's dir", True)
("in type3's dir", True)
Traceback (most recent call last):
File "trash/type_subclass.py", line 9, in
print(type3.__abstractmethods__)
AttributeError: __abstractmethods__
$> python3.1 trash/type_subclass.py
in type's dir True
in type3's dir True
Traceback (most recent call last):
File "trash/type_subclass.py", line 9, in
print(type3.__abstractmethods__)
AttributeError: __abstractmethods__
And that seems to be the only attribute behaving like that (others are fine and
accessible). Some people even seems to provide workarounds already, e.g.:
http://bitbucket.org/DasIch/bpython-colorful/src/19bb4cb0a65d/bpython/repl.py
when __abstractmethods__ is accessed only for the subclasses of ABCmeta ...
so, is it a bug or a feature (so we have to take care about it in all
traversals of attributes given by dir())? ;)
--
messages: 117798
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: non-Pythonic fate of __abstractmethods__
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue10006>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10006] non-Pythonic fate of __abstractmethods__
Yaroslav Halchenko added the comment: yikes... surprising resolution -- I expected that fix would either makes __abstractmethods__ accessible in derived "type"s or becomes absent from output of dir() -- but none of those has happened. Now we ended up with a consistent non-Pythonic fate of __abstractmethods__ listed in output of dir() but not accessible. is that a feature? -- ___ Python tracker <http://bugs.python.org/issue10006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Yaroslav Halchenko added the comment: In PyMVPA we have our little decorator as an alternative to Fernando's generators, and which is closer, I think, to what Michael was wishing for: @sweepargs http://github.com/yarikoptic/PyMVPA/blob/master/mvpa/testing/sweepargs.py NB it has some minor PyMVPA specificity which could be easily wiped out, and since it was at most 4 eyes looking at it and it bears "evolutionary" changes, it is far from being the cleanest/best piece of code, BUT: * it is very easy to use, just decorate a test method/function and give an argument which to vary within the function call, e.g smth like @sweepargs(arg=range(5)) def test_sweepargs_demo(arg): ok_(arg < 5) ok_(arg < 3) ok_(arg < 2) For nose/unittest it would still look like a single test * if failures occur, sweepargs groups failures by the type/location of the failures and spits out a backtrace for one of failures + summary (instead of detailed backtraces for each failure) specifying which arguments lead to what error... here is the output for example above: $> nosetests -s test_sweepargs_demo.py F == FAIL: mvpa.tests.test_sweepargs_demo.test_sweepargs_demo -- Traceback (most recent call last): File "/usr/lib/pymodules/python2.5/nose/case.py", line 183, in runTest self.test(*self.arg) File "/usr/lib/pymodules/python2.5/nose/util.py", line 630, in newfunc return func(*arg, **kw) File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 11, in test_sweepargs_demo ok_(arg < 2) File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_ assert expr, msg AssertionError: Different scenarios lead to failures of unittest test_sweepargs_demo (specific tracebacks are below): File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 10, in test_sweepargs_demo ok_(arg < 3) File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_ assert expr, msg on arg=3 arg=4 File "/home/yoh/proj/pymvpa/pymvpa/mvpa/tests/test_sweepargs_demo.py", line 11, in test_sweepargs_demo ok_(arg < 2) File "/usr/lib/pymodules/python2.5/nose/tools.py", line 25, in ok_ assert expr, msg on arg=2 -- Ran 1 test in 0.003s FAILED (failures=1) * obviousely multiple decorators could be attached to the same test, to test on all combinations of more than 1 argument but output atm is a bit cryptic ;-) -- nosy: +Yaroslav.Halchenko ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Yaroslav Halchenko added the comment: Fernando, I agree... somewhat ;-) At some point (whenever everything works fine and no unittests fail) I wanted to merry sweepargs to nose and make it spit out a dot (or animate a spinning wheel ;)) for every passed unittest, so instead of 300 dots I got a picturesque field of thousands dots and Ss and also saw how many were skipped for some parametrizations. But I became "Not sure" of such feature since field became quite large and hard to "grasp" visually although it gave me better idea indeed of what was the total number of "testings" were done and skipped. So may be it would be helpful to separate notions of tests and testings and provide user ability to control the level of verbosity (1 -- tests, 2 -- testings, 3 -- verbose listing of testings (test(parametrization))) But I blessed sweepargs every time whenever something goes nuts and a test starts failing for (nearly) all parametrization at the same point. And that is where I really enjoy the concise summary. Also I observe that often an ERROR bug reveals itself through multiple tests. So, may be it would be worth developing a generic 'summary' output which would collect all tracebacks and then groups them by the location of the actual failure and tests/testings which hit it? -- ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Yaroslav Halchenko added the comment: Hi Nick, Am I reading your right, Are you suggesting to implement this manual looping/collecting/reporting separately in every unittest which needs that? On Tue, 11 May 2010, Nick Coghlan wrote: > Nick Coghlan added the comment: > I agree with Michael - one test that covers multiple settings can easily be > done by collecting results within the test itself and then checking at the > end that no failures were detected (e.g. I've done this myself with a test > that needed to be run against multiple input files - the test knew the > expected results and maintained lists of filenames where the result was > incorrect. At the end of the test, if any of those lists contained entries, > the test was failed, with the error message giving details of which files had > failed and why). -- ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38449] regression - mimetypes guess_type is confused by ; in the filename
New submission from Yaroslav Halchenko :
Our tests in DataLad started to fail while building on Debian with Python
3.7.5rc1 whenever they passed just fine previously with 3.7.3rc1. Analysis
boiled down to mimetypes
$> ./python3.9 -c 'import mimetypes; mimedb =
mimetypes.MimeTypes(strict=False); print(mimedb.guess_type(";1.tar.gz"))'
(None, None)
$> ./python3.9 -c 'import mimetypes; mimedb =
mimetypes.MimeTypes(strict=False); print(mimedb.guess_type("1.tar.gz"))'
('application/x-tar', 'gzip')
$> git describe
v3.8.0b1-1174-g2b7dc40b2af
Ref:
- original issue in DataLad: https://github.com/datalad/datalad/issues/3769
--
components: Library (Lib)
messages: 354455
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: regression - mimetypes guess_type is confused by ; in the filename
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38449>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38449] regression - mimetypes guess_type is confused by ; in the filename
Yaroslav Halchenko added the comment: FWIW, our more complete test filename is # python3 -c 'import patoolib.util as ut; print(ut.guess_mime(r" \"\`;b&b&c |.tar.gz"))' (None, None) which works fine with older versions -- ___ Python tracker <https://bugs.python.org/issue38449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33040] Make itertools.islice supports negative values for start and stop arguments for sized iterable object
Yaroslav Nikitenko added the comment: I hope it's fine to add to closed topics here. I agree with the decision that islice should not handle a special case of sized containers vs iterables. However, I think that the support of negative indices in islice would be nice. A simple use case would be to get the last element of an iterable. I had to write my own code for that (you may read and/or use it if needed), because I needed this algorithm in my analysis. Here is the link to my function ISlice._run_negative_islice in my architectural framework for data analysis: https://github.com/ynikitenko/lena/blob/master/lena/flow/iterators.py#L150 or on https://lena.readthedocs.io/en/latest/flow.html#lena.flow.iterators.ISlice (I'm afraid the correct link might change later). I also agree that to support negative indices would require more work. Indeed, it seems that for each combination of positive/negative start/stop it required a new algorithm! I didn't implement negative steps. However, I think that because it's not easy to implement, it would be even better to include that in the standard library (because it would save other people from writing that). If we care about code reuse: I think that negative indices make the algorithm more useful, while non-trivial steps are redundant, because they can be implemented by a composition of a slice with step=1 with a simple slice with start, stop=None, None with step!=1. Negative slice fundamentally changes the algorithm: if one wants to have the flow inverted, fflow[0, None, -1], one would have to store it all in memory! Anyway it's easy to make this in a separate function. So I think it's more functional to implement negative indices and discard negative steps (or non-trivial steps at all). About drop_first, drop_last suggested above: I also think that they are redundant and would be better incorporated into islice. -- nosy: +ynikitenko ___ Python tracker <https://bugs.python.org/issue33040> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33040] Make itertools.islice supports negative values for start and stop arguments for sized iterable object
Yaroslav Nikitenko added the comment: Sorry for a typo. The paragraph before the last should read Negative *step* fundamentally changes the algorithm:... flow[-1:None:-1]. -- ___ Python tracker <https://bugs.python.org/issue33040> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38801] Scientific notation doesn't work with itertools.islice
New submission from Yaroslav Nikitenko : Numbers written in scientific notation don't work with itertools.islice. Check this script: # a usual function works ## def works as well f = lambda x : x f(1e+6) # 100.0 import itertools # islice without scientific notation works itertools.islice([], 100) # itertools.islice([], 1e+6) # Traceback (most recent call last): # File "", line 1, in # ValueError: Stop argument for islice() must be None or an integer: 0 <= x <= sys.maxsize. All this works well in Python 2.7.17, but scientific notation fails in Python 3.7.5. I use Fedora Core 29. -- components: Library (Lib) messages: 356618 nosy: ynikitenko priority: normal severity: normal status: open title: Scientific notation doesn't work with itertools.islice type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38801] Scientific notation doesn't work with itertools.islice
Yaroslav Nikitenko added the comment: Hello Raymond. Many thanks for your explanation. In this case I suggest any of the following: 1) distinguish between integer and floating numbers in scientific notation. Definitely, 1e+6 is an integer. I can't see where else numbers in scientific notation are defined as only floats. 2) to write explicitly in the documentation that scientific notation is always float. I searched documentation of 'scientific notation', but didn't found that (https://docs.python.org/3/search.html?q=scientific+notation&check_keywords=yes&area=default) 3) to provide a better exception message in islice if this is a known issue. Should I change parameters of my report or create a new one? I'm afraid this message may get lost if closed. -- ___ Python tracker <https://bugs.python.org/issue38801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40634] Ignored "BlockingIOError: [Errno 11] Resource temporarily unavailable" are still haunting us
New submission from Yaroslav Halchenko : This is a reincarnation of previous issues such as - older https://bugs.python.org/issue21595 which partially (with ack on that) addressed the issue awhile back - more recent https://bugs.python.org/issue38104 which was closed as "wont fix" since "the provided example finishes without any warning" on 3.8 (verified -- true for me with 3.8.3rc1); and with the explanation that "You spawn too many subprocesses that finish virtually at the same time. It leads to wakeup_fd overrun." - additional similar reports could be found online, e.g. https://stackoverflow.com/a/52391791/1265472 . In our project we are slowly introducing use of asyncio and have a mix of execution with asyncio and regular subprocess.Popen. We do run lots of short lived processes serially, and I think it should be Ok, i.e. it should not cause underlying libraries to spit out some output to ignore unless we indeed just using them incorrectly somehow. If we recreate the SelectorEventLoop for every separate execution via asyncio -- no ignored exception messages are displayed. But if we start to reuse the same loop -- they eventually emerge. If I enable asyncio debug and log it along with our own debug messages, the strange thing that they come around the points where we run using regular subprocess.Popen, not asyncio. See https://github.com/datalad/datalad/pull/4527#issuecomment-629289819 for more information. Unfortunately I do not have (yet) any short script to reproduce it, but I would appreciate possible hints on how to figure out what is actually causing them in our particular case. May be additional logging within asyncio could assist? -- components: asyncio messages: 368953 nosy: Yaroslav.Halchenko, asvetlov, yselivanov priority: normal severity: normal status: open title: Ignored "BlockingIOError: [Errno 11] Resource temporarily unavailable" are still haunting us versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue40634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40634] Ignored "BlockingIOError: [Errno 11] Resource temporarily unavailable" are still haunting us
Yaroslav Halchenko added the comment: any feedback/ideas/fixes would still be highly appreciated. Thank you! -- ___ Python tracker <https://bugs.python.org/issue40634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment: Here's possible fix: https://github.com/python/cpython/pull/21799 -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment:
That's kinda weird for python. I mean, in regular list/etc if I need the last
element, I'd normally do list[-1], but here to get the last parent, I need to
actually know how many parents do I have.
So now, I can do something like this:
>>> parents_count = len(path.parents) - 1
>>> path.parents[parents_count]
PosixPath('.')
--
message_count: 16.0 -> 17.0
nosy: +ypank
nosy_count: 10.0 -> 11.0
pull_requests: +20938
stage: -> patch review
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.9
pull_request: https://github.com/python/cpython/pull/21799
___
Python tracker
<https://bugs.python.org/issue21041>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment: Any thoughts about that folks? It's a pretty old bug, let's decide smth for it. -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41594] Intermittent failures of loop.subprocess_exec() to capture output
Yaroslav Halchenko added the comment: Might (although unlikely) be related to https://bugs.python.org/issue40634 which is about BlockingIOError being raised (and ignored) if SelectorEventLoop is reused (not the case here) also in the case of short lived processes. -- nosy: +Yaroslav.Halchenko ___ Python tracker <https://bugs.python.org/issue41594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment: That makes sense, but should we have this behaviour only for negative indices? We'll end up with something lie: path.parents[len(path.parents) - 1] != path.parents[-1] I think that is should be consistent regardless of negative/positive indices. -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment: And it looks like a special case, so "Special cases aren't special enough to break the rules." -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Yaroslav Pankovych added the comment: Agree with that, it currently supports this behavior. -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories
New submission from Yaroslav Halchenko: If tarfile contains a file under a directory which has no write permission, extractall would fail since chmod'ing of the directory is done right when it is "extracted". Please find attached a quick&dummy script to demonstrate the problem using Python code. The issue is not just of an academic interest -- git-annex uses read-only permission to safe-guard against manual deletion of content. So tarball of any of git-annex repository carrying content for at least a single file, would not be extractable using Python's tarfile module (works fine with pure tar, verified that it is still failing to extract with Python v3.6.1-228-g1398b1bc7d from http://github.com/python/cpython). -- components: IO files: tarfilero.py messages: 294217 nosy: Yaroslav.Halchenko priority: normal severity: normal status: open title: tarfile would fail to extract tarballs with files under R/O directories versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46888/tarfilero.py ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories
Yaroslav Halchenko added the comment:
Dear Catherine,
Thank you very much for looking into it!! And sorry that I have missed the fact
of recursive addition when pointing to a directory. Indeed though, tar handles
that case a bit more gracefully.
BUT I feel somewhat dumb since I am afraid that may be the actual original
issue I have observed was simply because I already had that archive extracted
and tried to extract it twice, overriding existing files. That leads to the
failure I think I was trying to chase down (example with a sample tiny real
annex repo):
$> wget -q http://onerussian.com/tmp/sample.tar ; python -c 'import tarfile;
tarfile.open("sample.tar").extractall()'
$> python -c 'import tarfile; tarfile.open("sample.tar").extractall()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/tarfile.py", line 2081, in extractall
self.extract(tarinfo, path)
File "/usr/lib/python2.7/tarfile.py", line 2118, in extract
self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
File "/usr/lib/python2.7/tarfile.py", line 2194, in _extract_member
self.makefile(tarinfo, targetpath)
File "/usr/lib/python2.7/tarfile.py", line 2234, in makefile
with bltn_open(targetpath, "wb") as target:
IOError: [Errno 13] Permission denied:
'./sample/.git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b'
$> tar -xf sample.tar && echo "extracted ok"
extracted ok
But I wouldn't even consider it a failure but would take it as a feature in my
case (stuff is read-only for a reason!)
Altogether, I do not have the earth-shaking problem now, thus if you feel that
issue needs retitle or closing, feel free to do so
--
___
Python tracker
<http://bugs.python.org/issue30438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories (twice)
Changes by Yaroslav Halchenko : -- title: tarfile would fail to extract tarballs with files under R/O directories -> tarfile would fail to extract tarballs with files under R/O directories (twice) ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31651] io.FileIO cannot write more than 2GB (-4096) bytes??? must be documented (if not fixed)
New submission from Yaroslav Halchenko :
originally detected on python 2.7, but replicated with python 3.5.3 --
apparently io.FileIO, if given a bytestring of 2GB or more, cannot write it all
at once -- saves (and returns that size) only 2GB - 4096.
I found no indication for such behavior anywhere in the documentation. And it
is surprising to me especially since regular file.write does it just fine!
attached is the code snippet which I list below and which demonstrates it
$> python3 --version; python3 longwrite.py
Python 3.5.3
Written 2147479552 out of 2147483648
4096 bytes were not written
Traceback (most recent call last):
File "longwrite.py", line 28, in
assert in_digest == out_digest, "Digests do not match"
AssertionError: Digests do not match
python3 longwrite.py 7.03s user 5.80s system 99% cpu 12.848 total
1 11365 ->1.:Sat 30 Sep 2017 04:56:26 PM
EDT:.
smaug:/mnt/btrfs/scrap/tmp
$> cat longwrite.py
# -*- coding: utf-8 -*-
import io
import os
import hashlib
s = u' '*(256**4//2) #+ u"перфекто"
s=s.encode('utf-8')
#s=' '*(10)
in_digest = hashlib.md5(s).hexdigest()
fname = 'outlong.dat'
if os.path.exists(fname):
os.unlink(fname)
with io.FileIO(fname, 'wb') as f:
#with open(fname, 'wb') as f:
n = f.write(s)
#n = os.stat(fname).st_size
print("Written %d out of %d" % (n, len(s)))
if n != len(s):
print("%d bytes were not written" % (len(s) - n))
# checksum
with open(fname, 'rb') as f:
out_digest = hashlib.md5(f.read()).hexdigest()
assert in_digest == out_digest, "Digests do not match"
print("all ok")
--
components: IO
files: longwrite.py
messages: 303429
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: io.FileIO cannot write more than 2GB (-4096) bytes??? must be documented
(if not fixed)
type: behavior
versions: Python 2.7, Python 3.5
Added file: https://bugs.python.org/file47182/longwrite.py
___
Python tracker
<https://bugs.python.org/issue31651>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31651] io.FileIO cannot write more than 2GB (-4096) bytes??? must be documented (if not fixed)
Yaroslav Halchenko added the comment: Thank you for the follow-ups! Wouldn't it be better if Python documentation said exactly that On Linux, write() (and similar system calls) will transfer at most 0x7000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.) Also, it might be nice to add a note on top, that this module is for 'low level' IO interface, and that it is recommended to use regular file type for typical file operations (not io.FileIO) to avoid necessity of dealing limitations such as the one mentioned. -- ___ Python tracker <https://bugs.python.org/issue31651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG)
New submission from Yaroslav Halchenko : It is quite often desired to reproduce the same failure identically. In many cases sufficient to seed the shared random._inst (via random.seed). tempfile creates new instance(s) for its own operation and does not provide API to seed it. I do not think it would be easy (unless I miss some pattern) to make it deterministic/reproducible for multi-process apps, but I wondered why initially (for the main process) tempfile module doesn't just reuse the random._inst while only creating a new _Random in children processes? Another alternative solution would be to allow to specify seed for all those mkstemp/mkdtemp/... and pass it all way to _RandomNameSequence which would initialize _Random with it. This way, developers who need to seed it, could do so -- messages: 308043 nosy: Yaroslav.Halchenko priority: normal severity: normal status: open title: there is no way to make tempfile reproducible (i.e. seed the used RNG) ___ Python tracker <https://bugs.python.org/issue32276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG)
Yaroslav Halchenko added the comment: I have spent too much time in Python to be able to compare to other languages ;) but anywhere I saw RNG being used, there was a way to seed it or to provide a state. tempfile provides no such API my usecase -- comparison of logs from two runs where I need to troubleshoot the point of divergence in execution . Logs in our case (datalad) contain temporary directory filenames, so they always "diff" and I need to sift through them or to come up with some obscure sed regex to unify them. I found in other projects of ours a really handy to be able to seed RNG globally so two runs result in identical execution path -- allows for easier reproducibility/comparison. But when it got to those temporary filenames -- apparently I could not make it happen and would need to resort to some heavy monkey patching. -- ___ Python tracker <https://bugs.python.org/issue32276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
Changes by Yaroslav Halchenko : -- nosy: -Yaroslav.Halchenko ___ Python tracker <http://bugs.python.org/issue16997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9235] missing "import sys" in Tools/gdb/libpython.py
New submission from Yaroslav Halchenko :
as you can see from below, sys. is used, but never imported (besides a
docstring)
$> git describe
upstream/0.5.0.dev-875-gf06319e
$> grep -5 'sys' /home/yoh/proj/misc/python/Tools/gdb/libpython.py
"""
During development, I've been manually invoking the code in this way:
(gdb) python
import sys
sys.path.append('/home/david/coding/python-gdb')
import libpython
end
then reloading it after each edit like this:
(gdb) python reload(libpython)
--
def print_summary(self):
if self.is_evalframeex():
pyop = self.get_pyop()
if pyop:
sys.stdout.write('#%i %s\n' % (self.get_index(),
pyop.get_truncated_repr(MAX_OUTPUT_LEN)))
sys.stdout.write(pyop.current_line())
else:
sys.stdout.write('#%i (unable to read python frame
information)\n' % self.get_index())
else:
sys.stdout.write('#%i\n' % self.get_index())
class PyList(gdb.Command):
'''List the current Python source code, if any
Use
--
for i, line in enumerate(all_lines[start-1:end]):
linestr = str(i+start)
# Highlight current line:
if i + start == lineno:
linestr = '>' + linestr
sys.stdout.write('%4s%s' % (linestr, line))
# ...and register the command:
PyList()
--
components: Demos and Tools
messages: 110134
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: missing "import sys" in Tools/gdb/libpython.py
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue9235>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9235] missing "import sys" in Tools/gdb/libpython.py
Yaroslav Halchenko added the comment: sorry -- git describe was by mistake in there... report is based on SVN revision 82502 -- ___ Python tracker <http://bugs.python.org/issue9235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ???
Yaroslav Halchenko added the comment: the function getargspec was removed but references to it within docstrings remained: $> git grep getargspec Doc/library/inspect.rst: The first four items in the tuple correspond to :func:`getargspec`. Doc/library/inspect.rst: :func:`getargspec` or :func:`getfullargspec`. Doc/whatsnew/3.4.rst::func:`~inspect.getfullargspec` and :func:`~inspect.getargspec` Doc/whatsnew/3.5.rst:* :func:`inspect.getargspec` is deprecated and scheduled to be removed in Doc/whatsnew/3.6.rst:* ``inspect.getargspec()`` was removed (was deprecated since CPython 3.0). Lib/inspect.py:getargspec(), getargvalues(), getcallargs() - get info about function arguments Lib/inspect.py:The first four items in the tuple correspond to getargspec(). Lib/inspect.py:"""Format an argument spec from the values returned by getargspec Lib/test/test_inspect.py:# getclasstree, getargspec, getargvalues, formatargspec, formatargvalues, Misc/NEWS:- Issue #13248: Remove deprecated inspect.getargspec and inspect.getmoduleinfo -- nosy: +Yaroslav.Halchenko ___ Python tracker <http://bugs.python.org/issue13248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25284] Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation
New submission from Yaroslav Admin: Parameter for BaseEventLoop.run_in_executor(executor, callback, *args) was renamed from callback to func in 3.5.0 release, but it's not reflected in the docs. Commit with change: https://github.com/python/cpython/commit/111610562141a46f1eaac64d497d79fe13290847#diff-08afa52ab2b1511bee8527814ad44d80L468 Documentation: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.run_in_executor -- components: asyncio messages: 251961 nosy: Yaroslav Admin, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25284] Spec for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation
Changes by Yaroslav Admin : -- title: Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation -> Spec for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation ___ Python tracker <http://bugs.python.org/issue25284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
