[issue46404] 3.11a4: a small attrs regression
Change by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <https://bugs.python.org/issue46404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46382] dataclass(slots=True) does not account for slots in base classes
Hynek Schlawack added the comment:
>>> @attrs.define
... class C(Base):
... a: int
... b: int
...
>>> C.__slots__
('b', '__weakref__')
We've got a test specifically for this use case:
https://github.com/python-attrs/attrs/blob/5f36ba9b89d4d196f80147d4f2961fb2f97ae2e5/tests/test_slots.py#L309-L334
--
___
Python tracker
<https://bugs.python.org/issue46382>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Hynek Schlawack added the comment: Thanks for the feedback Antoine! I updated the patch to latest default tip and added the requested tags to the docs. -- hgrepos: +97 ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24062/8a9e14cda106.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Changes by Hynek Schlawack : Removed file: http://bugs.python.org/file22860/mp-starmap-w-docs.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Hynek Schlawack added the comment: You're right. I've updated the docs accordingly, thanks! -- ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24063/c02fbcda56f3.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Changes by Hynek Schlawack : Removed file: http://bugs.python.org/file24062/8a9e14cda106.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24067/c92c4d936255.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: I have updated the patch to latest default/tip and would appreciate a review. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24069/4832bf7aa028.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: Thanks to Antoine & Charles-François for their reviews! I think I've incorporated all desired changes. Please let me know if I have missed something, meanwhile I'll tackle the docs. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24070/d9212bb67f64.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: The patch contains also the necessary changes for the docs now. Please let me know, if I can do anything else. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24099/23e6204efe20.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: Added another patch fixing the issues pointed out by Antoine and Charles-François. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24102/8330f2045f4d.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: Added new patch with protection for the remaining UF_NODUMPs in the test case. All raised issues should be fixed now. :) -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9993] shutil.move fails on symlink source
Hynek Schlawack added the comment: I took the liberty to fix the tests. Basically I've adapted them to the new mock based cross file system approach (that doesn't depend on luck anymore :)). I also had to add one more `os.path.realpath` because on some OS (like OS X) the tmp directory path already consists of symlinks. I didn't touch the actual code. Tested on OS X and Ubuntu Linux (Oneiric). -- Added file: http://bugs.python.org/file24146/shutil_move_symlinks.patch ___ Python tracker <http://bugs.python.org/issue9993> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9993] shutil.move fails on symlink source
Hynek Schlawack added the comment: Oh sorry, I didn't look into the doc patch. I unified both into one patch and added the versionchanged tag and also updated the docstring of shutil.move. -- Added file: http://bugs.python.org/file24149/shutil_move_symlinks.patch ___ Python tracker <http://bugs.python.org/issue9993> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Hynek Schlawack added the comment: What's the current state here? Anyone working on a solution or are we waiting how http://hg.python.org/features/pathlib/ will work out? If the consensus is to add a generic walker method, wouldn't be appropriate to open a new bug and add it as dependency? Or is there one I've missed? -- ___ Python tracker <http://bugs.python.org/issue4489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Hynek Schlawack added the comment: > > What's the current state here? Anyone working on a solution or are we > > waiting how http://hg.python.org/features/pathlib/ will work out? > > Well, I am not working on that one, so waiting for it to work out might > be optimistic :) > I don't know what to do with it (the pathlib): is such a feature > desireable enough? Independently from this bug, I'd say it would be a good thing. Proof: http://twistedmatrix.com/documents/current/api/twisted.python.filepath.html – Twisted already implemented something similar for themselves. > > If the consensus is to add a generic walker method, wouldn't be > > appropriate to open a new bug and add it as dependency? > > Agreed. See #13734 -- ___ Python tracker <http://bugs.python.org/issue4489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13734] Add a generic directory walker method to avoid symlink attacks
New submission from Hynek Schlawack : This is an offspring of #4489 (which is a security bug). The method is AFAIU intended to be private. As shown in the discussion of the mentioned #4489, there is a whole family of attacks that exploit the time window between gathering path names and executing a function on them. A general description of this problem can be found in: https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link While the consequences in rmtree() are probably most dramatic, other recursive functions could benefit too (chmodtree() and chowntree() were mentioned) so Charles-François suggested to write a "generic walker method that would take as argument the methods to call on a directory and on a file (or link)". Some (probably) necessary helper functions has been already implemented in #4761 (*at()) and #10755 (fdlistdir()). Has there already been done any work? Ross mentioned he wanted to take a stab? -- components: Library (Lib) messages: 150833 nosy: hynek.schlawack, neologix, pitrou, rosslagerwall, tarek priority: normal severity: normal status: open title: Add a generic directory walker method to avoid symlink attacks type: security versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
New submission from Hynek Schlawack : After I've seen a co-worker to unpack tuples while using multiprocessing.Pool.map(), I realized that the module is missing a starmap() method like itertools has. I took it as a opportunity to contribute some code and implemented both starmap() and starmap_async(). The patch including tests is attached, please let me know, what you think. Please don't call me names, it's my first patch for such a high profile project like Python. ;) -- components: Library (Lib) files: mp-starmap.diff keywords: patch messages: 141761 nosy: hynek, jnoller priority: normal severity: normal status: open title: multiprocessing.Pool is missing a starmap[_async]() method. type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file22859/mp-starmap.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12709] In multiprocessing, error_callback isn't documented for map_async
New submission from Hynek Schlawack : While working on #12708 , I noticed that the error_callback argument of multiprocessing.Pool.map_async() isn't documented (callback is). -- assignee: docs@python components: Documentation messages: 141763 nosy: docs@python, hynek priority: normal severity: normal status: open title: In multiprocessing, error_callback isn't documented for map_async type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue12709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Hynek Schlawack added the comment: In all my excitement, I somehow presumed that the docstring automagically lands in the docs. Added doc entries to patch (I hope they aren't too crude, I'm not a native speaker). Same as first patch otherwise. -- Added file: http://bugs.python.org/file22860/mp-starmap-w-docs.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12709] In multiprocessing, error_callback isn't documented for map_async
Hynek Schlawack added the comment: Yeah, if my 3G hadn't failed on me, it would have been already here. :) As a matter of fact, the argument is discussed in the body of the doc, it just has been omitted in the method definition, so the patch is trivial. -- keywords: +patch Added file: http://bugs.python.org/file22861/map_async-doc-fix.diff ___ Python tracker <http://bugs.python.org/issue12709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Changes by Hynek Schlawack : Removed file: http://bugs.python.org/file22859/mp-starmap.diff ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: Additionally copyfile() might be fixed to understand symlinks=True too. Currently working on a patch for all 5 of them. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files
New submission from Hynek Schlawack : While working on #12715 I noticed that the tests of shutil aren't exactly consistent concerning reading and writing files. There were no less than two function to read files (one of them not being used at all) and two methods to write them. Additionally lots of code simply reads/writes by hand. I've unified the functionality in module functions read_file and write_file which can be told to open the file as binaries. -- components: Tests files: cleanup-test_shutil.diff keywords: patch messages: 141856 nosy: hynek priority: normal severity: normal status: open title: Chaotic use of helper functions in test_shutil for reading and writing files type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22871/cleanup-test_shutil.diff ___ Python tracker <http://bugs.python.org/issue12721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: JFTR, my implementation is ready, but I can't/don't want to start writing tests, as long as #12721 is open. -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files
Hynek Schlawack added the comment: I tend to agree on public APIs, however in this case of a helper function the use case with a join is really really common so this extra function comes in very handy. I also kept it using lists, so it's more obvious than tuples. JFTR it wasn't my idea, so I'm not defensive about my own idea here. :) I just re-implemented it for read_file b/c it's really handy and saves a lot of typing. -- ___ Python tracker <http://bugs.python.org/issue12721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.
Hynek Schlawack added the comment: No, that's just a helper function like the `mapstar` directly above. args[1] is the iterable with tuples that get unpacked as arguments. -- ___ Python tracker <http://bugs.python.org/issue12708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files
Hynek Schlawack added the comment: Eric, just to be clear: Are you making this list->tuple change or should I fix the patch? -- ___ Python tracker <http://bugs.python.org/issue12721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12461] it's not clear how the shutil.copystat() should work on symlinks
Hynek Schlawack added the comment: This is a sub-issue of #12715. ATM the consent is to add just one symlinks parameter and use the l* functions iff src _and_ dst are symlinks. -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue12461> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9993] shutil.move fails on symlink source
Hynek Schlawack added the comment: I work on the superficially related #12715 (symlinks for shutil). As we try to mimic the POSIX tools and `mv` indeed doesn't follow links, I agree with the approach of this patch. -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue9993> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: We have an edge case when the caller calls copymode with symlinks=True on an OS that doesn't have lchmod (ie any other than FreeBSD). Should it be a nop (as in copystat), use chmod or raise an Exception? I Personally (and some people on #python-dev) believe it should raise an Exception as the caller made the effort to say that (s)he wants the link _not_ to be followed and it's just one operation (contrary to copystat that does several things). -- ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue4489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files
Hynek Schlawack added the comment: While writing my tests I realized, it would be really useful to make write_file() return the path it wrote to. I need the concatenated filenames most of the time, so I'm getting blocks of: fn = os.path.join(x,y) write_file(fn, 'contents') I'd prefer: fn = write_file((x,y), 'contents') Any thoughts? IMHO a write_file that concats path but doesn't return it is only useful in the tree-functions. -- ___ Python tracker <http://bugs.python.org/issue12721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12824] Make the write_file() helper function in test_shutil return the file name it wrote to
New submission from Hynek Schlawack : test_shutil contains a handy helper function called write_file(filename. contents). If *filename* is a tuple, os.path.join() is used to concatenate it to a path. To be really useful, the resulting file name should be returned, so the user can work with it. So instead of: fn = os.path.join(x,y) write_file(fn, 'contents') I'd prefer: fn = write_file((x,y), 'contents') I have attached a simple patch that achieves this and also applied the resulting simplification to some of the tests. -- components: Tests files: write_file_returns_filename.diff keywords: patch messages: 142795 nosy: eric.araujo, hynek priority: normal severity: normal status: open title: Make the write_file() helper function in test_shutil return the file name it wrote to type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23014/write_file_returns_filename.diff ___ Python tracker <http://bugs.python.org/issue12824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files
Hynek Schlawack added the comment: Done in Issue12824. -- ___ Python tracker <http://bugs.python.org/issue12721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12824] Make the write_file() helper function in test_shutil return the file name it wrote to
Hynek Schlawack added the comment: ok. it would have saved some LOC for me, but it's nothing essential of course. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Hynek Schlawack added the comment: What started as a 2 lines fix, grew to a patch of ~400 lines. :) It's mostly tests though: Lib/shutil.py | 102 +-- Lib/test/test_shutil.py | 220 ++ Misc/ACKS |1 + 3 files changed, 297 insertions(+), 26 deletions(-) I've AFAIS implemented the desired behavior and hope for feedback/bug reports. It's tested on Linux & FreeBSD 8.2 and applies cleanly against default/tip. Please let me know if I've done something stupid. -- hgrepos: +63 ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12715] Add symlink support to shutil functions
Changes by Hynek Schlawack : -- keywords: +patch Added file: http://bugs.python.org/file23028/e126ceae5ba9.diff ___ Python tracker <http://bugs.python.org/issue12715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45792] contextvars.Token has wrong module name in Sphinx's objects.inv
New submission from Hynek Schlawack : Doc/library/contextvars.rst defines a module using `.. module:: contextvars` which means that all defined symbols are automatically part of the contextvars module. The docs added in https://github.com/python/cpython/pull/5685 however explicitly use `.. class:: contextvars.Token` instead of just `.. class:: Token` which means that the recorded intersphinx symbol is `contextvars.contextvars.Token`. I have noticed this because sphinx couldn't find `contextvars.Token` in structlog's docs. AFAICT, this only affects contextvars.Token. -- assignee: hynek components: Documentation messages: 406192 nosy: hynek, yselivanov priority: low severity: normal stage: needs patch status: open title: contextvars.Token has wrong module name in Sphinx's objects.inv type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45792] contextvars.Token has wrong module name in Sphinx's objects.inv
Change by Hynek Schlawack : -- keywords: +patch pull_requests: +27783 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/29533 ___ Python tracker <https://bugs.python.org/issue45792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42600] Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError: Lock is not acquired.
New submission from Hynek Schlawack :
This is something I've been procrastinating on for almost a year and working
around it using my own version of asyncio.Condition because I wasn't sure how
to describe it. So here's my best take:
Consider the following code:
```
import asyncio
async def tf(con):
async with con:
await asyncio.wait_for(con.wait(), 60)
async def f(loop):
con = asyncio.Condition()
t = loop.create_task(tf(con))
await asyncio.sleep(1)
t.cancel()
async with con:
con.notify_all()
await t
loop = asyncio.get_event_loop()
loop.run_until_complete(f(loop))
```
(I'm using old-school APIs because I wanted to verify whether it was a
regression. I ran into the bug with new-style APIs:
https://gist.github.com/hynek/387f44672722171c901b8422320e8f9b)
`await t` will crash with:
```
Traceback (most recent call last):
File "/Users/hynek/t.py", line 6, in tf
await asyncio.wait_for(con.wait(), 60)
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/tasks.py", line
466, in wait_for
await waiter
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/hynek/t.py", line 24, in
loop.run_until_complete(f(loop))
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/base_events.py",
line 642, in run_until_complete
return future.result()
File "/Users/hynek/t.py", line 20, in f
await t
File "/Users/hynek/t.py", line 6, in tf
await asyncio.wait_for(con.wait(), 60)
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line
20, in __aexit__
self.release()
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line
146, in release
raise RuntimeError('Lock is not acquired.')
RuntimeError: Lock is not acquired.
```
If you replace wait_for with a simple await, it works and raises an
asyncio.exceptions.CancelledError:
```
Traceback (most recent call last):
File "/Users/hynek/t.py", line 6, in tf
await con.wait()
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line
290, in wait
await fut
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/hynek/t.py", line 20, in f
await t
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/hynek/t.py", line 24, in
loop.run_until_complete(f(loop))
File
"/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/base_events.py",
line 642, in run_until_complete
return future.result()
asyncio.exceptions.CancelledError
```
I have verified, that this has been broken at least since 3.5.10. The current
3.10.0a3 is affected too.
--
components: asyncio
messages: 382732
nosy: asvetlov, hynek, lukasz.langa, yselivanov
priority: normal
severity: normal
status: open
title: Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError:
Lock is not acquired.
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42600>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42014] shutil.rmtree calls onerror with different function than failed
Change by Hynek Schlawack : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13520] Patch to make pickle aware of __qualname__
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue13520> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13848] io.open() doesn't check for embedded NUL characters
Hynek Schlawack added the comment: I took a deep dive into parts of CPython that were unknown to me :) and dug up the following: Methods like os.stat or even os.open convert the file name using "et" in PyArg_ParseTuple[AndKeywords]. OTOH, open() and io.open() just hand through the object as "O" to the respective low-level io module. The result in 2.7 is that file() tries to convert it for it's own usage eventually – which fails as seen. While a more explicit error message wouldn't hurt, this seems safe to me insofar. In 3.3, file() aka Modules/_io/fileio.c , io_open does no such thing because it seems to handle fds as "nameobj" as well and does a wide range of checks on the argument. After io_open is certain that nameobj is a file name, it uses PyObject_AsCharBuffer()on bytes and PyUnicode_FromObject() + encoding magic on unicode to get an encoded string as a file name. Neither does a check for NUL bytes so the (w)open(er) that follows reacts as demonstrated by Antoine. I presume fixing/breaking PyObject_AsCharBuffer()/PyUnicode_FromObject() is out of question so the most obvious part to fix would be the conversion block inside io_open. Should I have a stab at it or do you disagree with my approach? -- ___ Python tracker <http://bugs.python.org/issue13848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13849] Add tests for NUL checking in certain strs
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue13849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13848] io.open() doesn't check for embedded NUL characters
Hynek Schlawack added the comment: JFTR, file()'s C equivalent is fileio_init and not io_open, I lost track of all the opens. ;) -- ___ Python tracker <http://bugs.python.org/issue13848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13848] io.open() doesn't check for embedded NUL characters
Hynek Schlawack added the comment:
So I have good news and bad news. The good is: I fixed it for non-Win platforms
and the patch is truly beautiful:
Lib/test/test_builtin.py | 6 ++
Modules/_io/fileio.c | 25 -
2 files changed, 10 insertions(+), 21 deletions(-)
;)
Two problems:
1. I'm not sure if it's okay for me to put the test where I put it?
2. I'm not sure how to fix it for Win32 (and I also can't test it :().
It's just about the case when it's called with a Unicode path name. The current
code looks like as following:
if (PyUnicode_Check(nameobj)) {
widename = PyUnicode_AsUnicode(nameobj);
if (widename == NULL)
return -1;
}
We can't use the nifty PyUnicode_FSConverter because we want to keep Unicode.
So I assume the way to go would be the C equivalent of somthing like:
if '\0' in widename:
raise TypeError()
Right?
I hope someone would be so kind to implement it, otherwise the patch attached
passes all test on Linux and Mac (except for test_recursion_limit but that
fails currently for me on the Mac even without my patch).
--
keywords: +patch
Added file: http://bugs.python.org/file24316/open-nul.patch
___
Python tracker
<http://bugs.python.org/issue13848>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13848] io.open() doesn't check for embedded NUL characters
Hynek Schlawack added the comment: I have fixed the refleak, added a _PyUnicode_HasNULChars and integrated it into the Win32-unicode-if-branch. Couldn't test it due to lack of win32 – the function itself is tested though. -- Added file: http://bugs.python.org/file24355/open-nul.patch ___ Python tracker <http://bugs.python.org/issue13848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13848] io.open() doesn't check for embedded NUL characters
Hynek Schlawack added the comment: With Georg's kind help I added some improvements: - I've been reluctant to waste heap for caching the nul string but he convinced me that I was being ridiculous ;) - For some reason there was a stray character inside, that should be fixed too. In related news, I'm also adding tests for fileio since the last patch. -- Added file: http://bugs.python.org/file24356/open-nul.patch ___ Python tracker <http://bugs.python.org/issue13848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10284] NNTP should accept bytestrings for username and password
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue10284> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: I think I've fixed it to do as described. Alas, I have no Easynews account to test it (I mailed their support about that so maybe that'll change). Would someone with an account mind to test, if it works? Nathan? -- Added file: http://bugs.python.org/file24466/nntp-retry-capas-after-login.diff ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: Sure, I wanted to add tests as soon as I know that the flow is correct (which it isn't :)). So essentially we want always CAPABILITIES LOGIN CAPABILITIES ? That's rather simple to achieve. The tests are going to be the harder part. ;) Re the patch: I tried to generate it using SourceTree but probably did something wrong – will use hg next time again. -- ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: I've added general tests of AUTH USER/PASS as there weren't any present yet. As I haven't alas heard back from Easynews, I can only presume they allow CAPABILITIES after a login – I've added a test case that models this behavior. Otherwise I did as it was asked: getcapabilities() is tolerant to temporary errors and we get them again after a login now. (I'm also using the remote repo tool now to avoid further patch fuckups – sorry for the extra mails.) -- hgrepos: +113 ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24499/0cf0b06e1d31.diff ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24500/e986dd8bb47d.diff ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: Thanks! I think I've addressed everything in the latest patch. -- ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: There's one more issue Julien has raised: nntplib attempts to authenticate when "AUTHINFO" is sent w/o USER. (haven't tested it but I presume it's still valid) It's trivial to catch that but I'd say that it's fine to let the server handle it if the user has specifically told us to authenticate by giving credentials – no? Maybe if dealing with not-entirely-rfc-compliant servers? I will look into the READER/MODE-READER part. -- ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24502/b33bcf179df4.diff ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10287] NNTP authentication should check capabilities
Hynek Schlawack added the comment: So my take on the whole issue and Antoine "tends to agree". ;) 1. If the user tells us (s)he _wants_ us to authenticate or send MODE READER, we do it even if capabilities don't advertise it. There's a lot of rfc-non-conformant servers out there. Permanent errors (i.e. not supported) will be gracefully swallowed. That's already status quo. 2. If the server tells us it already _is_ in READER mode, we don't send it because in that case we can assume the server knows what it's doing. The next patch checks whether we're in READER mode before trying to switch the mode. I've also added a test for the basic case where a connection is made to a MODE-READER advertising server. I also added a handler to the nntp2 tests that raises an exception if "mode reader" is called although the server advertises itself as "reader". If there's a consensus of not sending "MODE READER" if not advertised, it's a matter of two lines to fix that. Personally, I like this middle ground best. -- ___ Python tracker <http://bugs.python.org/issue10287> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7644] bug in nntplib.body() method with possible fix
Hynek Schlawack added the comment: Looking into the source code of nntplib, I'd claim this bug isn't valid anymore? At least the file is opened in binary mode now – see Lib/nntplib.py:462 In any case, we have a test suite now. -- nosy: +hynek versions: +Python 3.3 -Python 3.1 ___ Python tracker <http://bugs.python.org/issue7644> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8739] Update to smtpd.py to RFC 5321
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue8739> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7644] bug in nntplib.body() method with possible fix
Hynek Schlawack added the comment: I have also added a test for NTTP.head(), enjoy. -- keywords: +patch Added file: http://bugs.python.org/file24524/nntp-file-test.diff ___ Python tracker <http://bugs.python.org/issue7644> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14082] shutil doesn't copy extended attributes
Hynek Schlawack added the comment: I'd tend to always copy xattrs – it seems that's what the user would expect to happen. A new parameter to _forbid_ it might make sense. However, I feel that there are already enough parameters in place. :-/ -- ___ Python tracker <http://bugs.python.org/issue14082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14082] shutil doesn't copy extended attributes
Hynek Schlawack added the comment: If nobody objects, I'd cook up a patch. -- ___ Python tracker <http://bugs.python.org/issue14082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14082] shutil doesn't copy extended attributes
Hynek Schlawack added the comment: This ticket has a small catch: There are several namespaces. According to http://en.wikipedia.org/wiki/Xattr#Linux : - user: can be set by anyone - trusted: root only - security: root only - system: even root can’t do that, at least not in my vm I’m writing a shutil.copyxattr() first which could simple get another argument for the namespaces that should be copied. However what to do inside copy2()? I’m tending to either: 1. copy only user.* 2. ignore errors in any namespace != user Personally, I find the second approach rather non-deterministic. So I’d suggest: - copyxattr has an extra argument called namespaces with default being ['user'], so that in theory someone who wants to do something more sophisticated can do it. - copy2 copies only user.* though because that’s what you usually want. Please let me know what you think about it. -- ___ Python tracker <http://bugs.python.org/issue14082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12978] Figure out extended attributes on BSDs
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue12978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14082] shutil doesn't copy extended attributes
Hynek Schlawack added the comment: Ok, so I’ve added a function `copyxattr()` and `copy2()` tries to copy all possible namespaces. Tests pass on Linux and Mac OS X. -- keywords: +patch Added file: http://bugs.python.org/file25194/xattr.diff ___ Python tracker <http://bugs.python.org/issue14082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14157] time.strptime without a year fails on Feb 29
Hynek Schlawack added the comment: The point isn’t that time.strptime validates dates but that it uses datetime internally: julian = datetime_date(year, month, day).toordinal() - \ datetime_date(year, 1, 1).toordinal() + 1 Is it worth to reimplement this functionality? It strikes easier to me to just use a different year if year is undefined and date == Feb 29. -- ___ Python tracker <http://bugs.python.org/issue14157> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad
Change by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <https://bugs.python.org/issue29587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31997] SSL lib does not handle trailing dot (period) in hostname or certificate
Change by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <https://bugs.python.org/issue31997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33734] asyncio/ssl: Fix AttributeError, increase default handshake timeout
Hynek Schlawack added the comment: For some context: 10s seems to be more common than I liked to believe (seems like Go's http client uses it by default too). Nevertheless I ran into the 10s after updating uvloop and stopped being able to connect to a server in India. Therefore I'd consider 10s at least a regression that should be fixed. What was the effective timeout before? Depending on the old value, 60s could be excessive for clients and might lead to self-DoS on the client side… P.S. I tried to reply on my phone and now I fully support Mariatta’s proposal of moving to GitHub issues. -- ___ Python tracker <https://bugs.python.org/issue33734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33734] asyncio/ssl: Fix AttributeError, increase default handshake timeout
Hynek Schlawack added the comment: > Previous timeout was effectively infinite. Oi, well then 60s are an improvement indeed. :) -- ___ Python tracker <https://bugs.python.org/issue33734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18108] shutil.chown should support dir_fd and follow_symlinks keyword arguments
Changes by Hynek Schlawack : -- nosy: +hynek versions: +Python 3.4 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue18108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add a “first” function to the stdlib
New submission from Hynek Schlawack:
Let met try to get you sold on adding the “first” function I released on PyPI
roughly a year ago:
https://github.com/hynek/first
It’s a very nice complement to functions like `any()` or itertools. I consists
effectively of 9 lines of code but it proved extremely handy in production.
***
It returns the first true value from an iterable or a default:
>>> first([0, None, False, [], (), 42])
42
>>> first([0, None, False, [], ()], default=42)
42
Additionally it also allows for a key function:
>>> first([1, 1, 3, 4, 5], key=lambda x: x % 2 == 0)
4
***
First happens to be especially useful together with the re module:
import re
from first import first
re1 = re.compile('b(.*)')
re2 = re.compile('a(.*)')
m = first(regexp.match('abc') for regexp in [re1, re2])
if not m:
print('no match!')
elif m.re is re1:
print('re1', m.group(1))
elif m.re is re2:
print('re2', m.group(1))
All the knee-jerk alternatives to it have some shortcomings:
next(itertools.ifilter(None, (regexp.match('abc') for regexp in [re1, re2])),
None)
next((regexp.match('abc') for regexp in [re1, re2] if regexp.match('abc')),
None)
None of them is Pythonic and the second one even has to call match() twice,
which is *not* a cheap method to call.
Here the first version for comparison again:
first(regexp.match('abc') for regexp in [re1, re2])
It doesn’t even exhaust the iterator if not necessary.
***
I don’t cling to neither the name or the exact function signature (although it
got polished with the help of several people, two of them core developers). I
also don’t really care whether it gets added along of any() or put into
itertools. I just know that I and several other people would appreciate to
have such a handy function in the stdlib – I even got an e-mail from OpenStack
folks asking when it will be added because they would like to use it and
there’s even a debian package by now:
http://packages.debian.org/unstable/python-first
There’s also this question on StackOverflow:
http://stackoverflow.com/questions/1077307/why-is-there-no-firstiterable-built-in-function-in-python
which is nice but doesn’t fix the subtleties like when there is no true value
etc which makes it useless for production code and one has to write boilerplate
code every single time.
It was even one of five Python packages Lukasz Langa deemed worthy to be
highlighted in his PyCon 2013 lightning talk:
http://youtu.be/1vui-LupKJI?t=20m40s
FWIW, SQL has a similar function called COALESCE (
https://en.wikipedia.org/wiki/Null_(SQL)#COALESCE ) which only handles NULL
though.
***
I’ll happily respond to any questions or concerns that may arise and supply a
patch as soon as we agree on a place to add it.
--
assignee: hynek
components: Library (Lib)
messages: 194338
nosy: hynek, lukasz.langa, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Add a “first” function to the stdlib
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue18652>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add a “first” function to the stdlib
Hynek Schlawack added the comment: `filter()` exhausts the full iterator which is potentially very expensive – like in conduction with regular expressions. -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add a “first” function to the stdlib
Hynek Schlawack added the comment: Ah ok sorry. Anyhow, it’s just a very common idiom that should be easy and readable. As said, I’m not married to any names at all and would happily add a compatibility package to PyPI with the new names/parameters. -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add a “first”-like function to the stdlib
Hynek Schlawack added the comment: Martin, I don’t find the loop easier to read because you have to *remember* the `break` otherwise “weird stuff happens”. Coalesce seems common enough, I would +1 on that too. -- title: Add a “first” function to the stdlib -> Add a “first”-like function to the stdlib ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.coalesce
Hynek Schlawack added the comment: > def coalesce(iterable, default=None, pred=None): >return next(filter(pred, iterable), default) > > Are you sure you want add this one-line function to the itertools module > rather then to recipes? Well, for many – including me – it would mean to have this one-line function in every other project or a PyPI dependency. I’m certain there are other short but useful functions in the stdlib. -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.coalesce
Hynek Schlawack added the comment: > But why you want to have a separate function instead of just use two builtins? This question has been answered twice now, once from Nick – please refer above. It's a clunky and error-prone solution to a common problem. Maybe you can't emphasize because it's not a common problem to you but that doesn't make it less useful. -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
Hynek Schlawack added the comment: > +1 on the name 'first_true'. Does exactly what it says on the tin. I fully agree. *** I assume what's missing now is a permission from Raymond to mess with his turf? -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
Hynek Schlawack added the comment: So I wanted to provide a first patch to move the discussion on and realized that itertools appears currently to be completely inside of `Modules/itertoolsmodule.c`. :-/ Any volunteers? :) -- assignee: hynek -> stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
Hynek Schlawack added the comment: Well that's the point: it's extremely handy but simple. I wish Raymond would pronounce on this. I can keep using the PyPI version for all I care, so I'm not going fight for it. But with one exception there seems to be an agreement that it would be a very fine thing to have. -- ___ Python tracker <http://bugs.python.org/issue18652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18959] Create a "Superseded modules" section in standard library ToC
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue18959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14157] time.strptime without a year fails on Feb 29
Hynek Schlawack added the comment: I gave it a shot, doesn’t look like a hack to me, what do you think? -- keywords: +patch Added file: http://bugs.python.org/file25301/strptime-on-leap-years.diff ___ Python tracker <http://bugs.python.org/issue14157> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: I guess a “best effort” approach would be best here. I presume Python 3.2+ have the same behavior? -- nosy: +hynek ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: Now that’s odd. I just looked into the code at http://hg.python.org/cpython/file/2.7/Lib/shutil.py#l103 and there is a guard against EOPNOTSUPP: try: os.chflags(dst, st.st_flags) except OSError, why: if (not hasattr(errno, 'EOPNOTSUPP') or why.errno != errno.EOPNOTSUPP): raise Does your /Library/Gentoo/usr/lib/python2.7/shutil.py look the same? Would you mind adding a `print why.errno` just before the raise? I have tried move'ing files to NTFS and FAT32 and it works just fine here. -- ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: I had this text ready before ned chimed in, I’ll post it anyway because it was a lot of work ;): You're right, 2.7’s errnos are incomplete compared to 3.2. Antoine added ENOTSUP in c370866f30a7 and it runs as “Solaris-specific”. So it’s currently in 3.2 and later. Shouldn’t hurt to back port it? EOPNOTSUP is obviously wrong in your case and it doesn’t really sound right at all by the description. However, maybe on some other architecture (FreeBSD?) it’s the way to go? The commit (2e0d58adadbe) states it’s because of ZFS on OS X. As the code is unchanged in 3.2+, this bug also applies to them. Suggestion: For 3.2+3.3: I’d extend the catch to also catch ENOTSUP For 2.7: I’d also backport the err code. NB I’m fine if Fabian wants to do it himself, it’s his issue. -- ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14682] Backport missing errnos to 2.7
New submission from Hynek Schlawack : In order to fix issue14662, we need to back port at least ENOTSUP to 2.7 (presuming we don’t want to check for magic numbers). The question is, whether we should back port all/most of them when we’re at it? There doesn’t seem to be much harm to it. -- assignee: ronaldoussoren components: IO, Library (Lib), Macintosh messages: 159458 nosy: benjamin.peterson, eric.araujo, hynek, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Backport missing errnos to 2.7 type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Hynek Schlawack added the comment: Anybody working on this one? I’d give it a shot otherwise. -- ___ Python tracker <http://bugs.python.org/issue4489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14682] Backport missing errnos to 2.7
Hynek Schlawack added the comment: So what does that mean for issue14662? Backport only ENOTSUP, check against “45” or “won't fix”? -- ___ Python tracker <http://bugs.python.org/issue14682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: This is a fix for 2.7. As Benjamin said in http://bugs.python.org/issue14682#msg159477 it’s okay to back port ENOTSUP, I did it as part of the patch here. I wasn’t sure whether we should document it? I’m porting the patch to tip right now, reviews/opinions welcome. -- keywords: +patch nosy: +pitrou Added file: http://bugs.python.org/file25382/expand-chflags-catch-2.7.diff ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: This one is against tip. -- Added file: http://bugs.python.org/file25383/expand-chflags-catch-tip.diff ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Hynek Schlawack added the comment: And finally against 3.2 -- Added file: http://bugs.python.org/file25384/expand-chflags-catch-3.2.diff ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
