[issue43094] sqlite3.create_function takes parameter named narg, not num_params
New submission from Nicholas Chammas : The doc for sqlite3.create_function shows the signature as follows: https://docs.python.org/3.9/library/sqlite3.html#sqlite3.Connection.create_function ``` create_function(name, num_params, func, *, deterministic=False) ``` But it appears that the parameter name is `narg`, not `num_params`. Trying `num_params` yields: ``` TypeError: function missing required argument 'narg' (pos 2) ``` -- assignee: docs@python components: Documentation messages: 386100 nosy: docs@python, nchammas priority: normal severity: normal status: open title: sqlite3.create_function takes parameter named narg, not num_params versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20039] Missing documentation for argparse.ArgumentTypeError
Nicholas Chammas added the comment: Just a note that I also went looking for the docs for argparse.ArgumentTypeError after coming across it in this (highly viewed) post: https://stackoverflow.com/a/14117511/877069 -- nosy: +nchammas ___ Python tracker <https://bugs.python.org/issue20039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34713] csvwriter.writerow()'s return type is undocumented
Nicholas Chammas added the comment: Nope, go ahead. -- ___ Python tracker <https://bugs.python.org/issue34713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34713] csvwriter.writerow()'s return type is undocumented
Nicholas Chammas added the comment:
Looks like it's bytes written, not characters:
```
>>> import csv
>>> with open('test.csv', 'w', newline='') as csv_file:
... csv_writer = csv.writer(
... csv_file,
... dialect='unix',
... )
... csv_writer.writerow('야 너') # 3 characters
...
12
```
--
___
Python tracker
<https://bugs.python.org/issue34713>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34713] csvwriter.writerow()'s return type is undocumented
New submission from Nicholas Chammas : It _looks_ like csvwriter.writerow() returns the number of bytes (or is it characters?) written. However, there is no documentation of this: https://docs.python.org/3.7/library/csv.html#csv.csvwriter.writerow Is this behavior part of the method's "contract"? And if so, shouldn't we document it? The same goes for csvwriter.writerows(). -- assignee: docs@python components: Documentation, Library (Lib) messages: 325557 nosy: docs@python, nchammas priority: normal severity: normal status: open title: csvwriter.writerow()'s return type is undocumented type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22269] Resolve distutils option conflicts with priorities
Change by Nicholas Chammas <nicholas.cham...@gmail.com>: -- nosy: +nchammas ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26463] asyncio-related (?) segmentation fault
Nicholas Chammas added the comment: Thanks for the tip. Enabling the fault handler reveals that the crash is happening from the Cryptography library. I'll move this issue there. Thank you. -- resolution: -> not a bug status: open -> closed Added file: http://bugs.python.org/file42055/faulthandler-stacktrace.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26463] asyncio-related (?) segmentation fault
Changes by Nicholas Chammas <nicholas.cham...@gmail.com>: Added file: http://bugs.python.org/file42052/stacktrace.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26463] asyncio-related (?) segmentation fault
New submission from Nicholas Chammas: Python 3.5.1, OS X 10.11.3. I have an application that uses asyncio and Cryptography (via the AsyncSSH library). Cryptography has some parts written in C, I believe. I'm testing my application by sending a keyboard interrupt while 2 tasks are working. My application doesn't clean up after itself correctly, so I get these warnings about pending tasks being destroyed, but I don't think I should ever be getting segfaults. I am able to consistently get this segfault by interrupting my application at roughly the same point. I'm frankly intimidated by the segfault (it's been many years since I dug into one), but the most likely culprits are either Python or Cryptography since they're the only components of my application that have parts written in C, as far as I know. I'm willing to help boil this down to something more minimal with some help. Right now I just have the repro at this branch of my application (which isn't too helpful for people other than myself): https://github.com/nchammas/flintrock/pull/77 Basically, launch a cluster on EC2, and as soon as one task reports that SSH is online, interrupt Flintrock with Control + C. You'll get this segfault. -- components: Macintosh, asyncio files: segfault.txt messages: 261036 nosy: Nicholas Chammas, gvanrossum, haypo, ned.deily, ronaldoussoren, yselivanov priority: normal severity: normal status: open title: asyncio-related (?) segmentation fault type: crash versions: Python 3.5 Added file: http://bugs.python.org/file42051/segfault.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8706] accept keyword arguments on most base type methods and builtins
Changes by Nicholas Chammas <nicholas.cham...@gmail.com>: -- nosy: +Nicholas Chammas ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26334] bytes.translate() doesn't take keyword arguments; docs suggests it does
Nicholas Chammas added the comment: Yep, you're right. I'm just understanding now that we have lots of methods defined in C which have signatures like this. Is there an umbrella issue, perhaps, that covers adding support for keyword-based arguments to functions defined in C, like `translate()`? -- resolution: -> duplicate status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26334] bytes.translate() doesn't take keyword arguments; docs suggests it does
Nicholas Chammas added the comment: So you're saying if `bytes.translate()` accepted keyword arguments, its signature would look something like this? ``` bytes.translate(table, delete=None) ``` I guess I was under the mistaken assumption that argument names in the docs always matched keyword arguments in the signature. But you're right, a strictly positional argument (I guess specified via something like `args*`?) doesn't have a name. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26334] bytes.translate() doesn't take keyword arguments; docs suggests it does
New submission from Nicholas Chammas: The docs for `bytes.translate()` [0] show the following signature: ``` bytes.translate(table[, delete]) ``` However, calling this method with keyword arguments yields: ``` >>> b''.translate(table='la table', delete=b'delete') Traceback (most recent call last): File "", line 1, in TypeError: translate() takes no keyword arguments ``` I'm guessing other methods have this same issue. (e.g. `str.translate()`) Do the docs need to be updated, or should these methods be updated to accept keyword arguments, or something else? [0] https://docs.python.org/3/library/stdtypes.html#bytes.translate -- assignee: docs@python components: Documentation, Library (Lib) messages: 260034 nosy: Nicholas Chammas, docs@python priority: normal severity: normal status: open title: bytes.translate() doesn't take keyword arguments; docs suggests it does versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26188] Provide more helpful error message when `await` is called inside non-`async` method
Nicholas Chammas added the comment: Related discussions about providing more helpful syntax error messages: * http://bugs.python.org/issue1634034 * http://bugs.python.org/issue400734 * http://bugs.python.org/issue20608 >From the discussion on issue1634034, it looks like providing better messages >in the general case of a syntax error is quite difficult. But perhaps in >limited cases like this one we can do better. Parsers are a bit over my head. Martin, is it difficult to distinguish between `await` as a regular name and `await` as a special token? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX
Nicholas Chammas added the comment: As of Python 3.5.1 [0], it looks like 1) the `aliased` and `terse` parameters of `platform.platform()` are documented to take integers instead of booleans (contrary to what Marc-Andre requested), and 2) calling `platform.platform()` with `aliased` set to 1 or True still returns "Darwin" on OS X. Is this by design? [0] https://docs.python.org/3.5/library/platform.html#platform.platform -- nosy: +Nicholas Chammas ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26188] Provide more helpful error message when `await` is called inside non-`async` method
New submission from Nicholas Chammas: Here is the user interaction: ```python $ python3 Python 3.5.1 (default, Dec 7 2015, 21:59:10) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def oh_hai(): ... await something() File "", line 2 await something() ^ SyntaxError: invalid syntax ``` It would be helpful if Python could tell the user something more specific about _why_ the syntax is invalid. Is that possible? For example, in the case above, an error message along the following lines would be much more helpful: ``` SyntaxError: Cannot call `await` inside non-`async` method. ``` Without a hint like this, it's too easy to miss the obvious and waste time eye-balling the code, like I did. :-) -- components: Interpreter Core messages: 258879 nosy: Nicholas Chammas priority: normal severity: normal status: open title: Provide more helpful error message when `await` is called inside non-`async` method versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument
New submission from Nicholas Chammas: Here is traceback.print_tb()'s signature [0]: ``` def print_tb(tb, limit=None, file=None): ``` However, its documentation reads [1]: ``` .. function:: print_tb(traceback, limit=None, file=None) ``` Did the keyword argument change recently, or was this particular doc always wrong? [0] https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Lib/traceback.py#L43 [1] https://raw.githubusercontent.com/python/cpython/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Doc/library/traceback.rst -- assignee: docs@python components: Documentation messages: 257670 nosy: Nicholas Chammas, docs@python priority: normal severity: normal status: open title: traceback.print_tb() takes `tb`, not `traceback` as a keyword argument versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document or test return values
Nicholas Chammas added the comment: Alright, sounds good to me. Thank you for guiding me through the process! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document or test return values
Nicholas Chammas added the comment: Ah, I see. The setup/teardown stuff runs for each test. So this is what I did: * Added a method to add a "bad" source file to the source directory. It gets cleaned up with the existing teardown method. * Used test_importlib to temporarily mutate sys.path as you recommended. I think this is much closer to what we want. Let me know what you think. By the way, are there any docs on test_importlib? I couldn't find any. -- Added file: http://bugs.python.org/file41364/compileall.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document or test return values
Nicholas Chammas added the comment: I've added the tests as we discussed. A couple of comments: * I found it difficult to reuse the existing setUp() code so had to essentially repeat a bunch of very similar code to create "bad" files. Let me know if you think there is a better way to do this. * I'm having trouble with the test for compile_path(). Specifically, it doesn't seem to actually use the value for skip_curdir. Do you understand why? -- Added file: http://bugs.python.org/file41277/compileall.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24931] _asdict breaks when inheriting from a namedtuple
Nicholas Chammas added the comment: I know. I came across this issue after upgrading to the 3.5.1 release and seeing that vars(namedtuple) didn't work anymore. I looked through the changelog [0] for an explanation of why that might be and couldn't find one, so I posted that question on Stack Overflow. I'm guessing others will go through the same flow after they upgrade to 3.5.1 and wonder why their vars(namedtuple) code broke, so I posted here asking if we should amend the changelog to call this change out. But I gather from your comment that the changelog cannot be updated after the release, so I guess there is nothing to do here. (Sorry about the distraction. I'm new to the Python dev community.) [0] https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-1-final -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24931] _asdict breaks when inheriting from a namedtuple
Nicholas Chammas added the comment: Should this change be called out in the 3.5.1 release docs? It makes some code that works on 3.5.0 break in 3.5.1. See: http://stackoverflow.com/q/34166469/877069 -- nosy: +Nicholas Chammas ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document or test return values
Nicholas Chammas added the comment: Absolutely. I'll add a "bad source file" to `setUp()` [0] and check return values as part of the existing checks in `test_compile_files()` [1]. Does that sound like a good plan to you? Also, I noticed that `compile_path()` has no tests. Should I test it as part of `test_compile_files()` or as part of a different test function? [0] https://hg.python.org/cpython/file/tip/Lib/test/test_compileall.py#l14 [1] https://hg.python.org/cpython/file/tip/Lib/test/test_compileall.py#l57 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: OK, here's a patch. I reviewed the doc style guide [0] but I'm not 100% sure if I'm using the appropriate tense. There are also a couple of lines that go a bit over 80 characters, but the file already had a few of those. Am happy to make any adjustments, if necessary. [0] https://docs.python.org/devguide/documenting.html#style-guide -- keywords: +patch Added file: http://bugs.python.org/file41201/compileall-doc.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: And I just signed the contributor agreement. (Some banner showed up when I attached the patch to this issue asking me to do so.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: :thumbsup: Take your time. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25775] Bug tracker emails go to spam
New submission from Nicholas Chammas: Not sure where to report this. Is there a component for the bug tracker itself? Anyway, Gmail sends emails from this bug tracker to spam and flags each one with the following message: > Why is this message in Spam? It is in violation of Google's recommended email > sender guidelines. Learn more > https://support.google.com/mail/answer/81126?hl=en#authentication Is this actionable? Is this a known issue? -- messages: 255676 nosy: Nicholas Chammas priority: normal severity: normal status: open title: Bug tracker emails go to spam type: behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: Oh derp. It appears this is dup of issue24386. Apologies. -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: Whoops, wrong issue. Reopening. -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25775] Bug tracker emails go to spam
Nicholas Chammas added the comment: Oh derp. It appears this is dup of issue24386. Apologies. -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
Nicholas Chammas added the comment: Exciting! I'm on it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25768] compileall functions do not document return values
New submission from Nicholas Chammas: I'm using the public functions of Python's built-in compileall module. https://docs.python.org/3/library/compileall.html#public-functions There doesn't appear to be documentation of what each of these functions returns. I figured out, for example, that compileall.compile_file() returns 1 when the file compiles successfully, and 0 if not. If this is "official" behavior, it would be good to see it documented so that we can rely on it. I'd be happy to submit a patch to fix this if a committer is willing to shepherd a new contributor (me) through the process. Otherwise, this is probably a quick fix for experienced contributors. -- assignee: docs@python components: Documentation messages: 255600 nosy: Nicholas Chammas, docs@python priority: normal severity: normal status: open title: compileall functions do not document return values type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25768> ___ ___ 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 Nicholas Chammas <nicholas.cham...@gmail.com>: -- nosy: +Nicholas Chammas ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Did the 3.4.4 docs get published early?
Sorry, somehow the formatting in my previous email didn't come through correctly. This part was supposed to be in a quote block: Also, just replacing the version number in the URL works for the python 3 series (use 3.X even for python 3.0), even farther back than the drop down menu allows. Nick On Wed, Jun 10, 2015 at 2:25 PM Nicholas Chammas nicholas.cham...@gmail.com wrote: Also, just replacing the version number in the URL works for the python 3 series (use 3.X even for python 3.0), even farther back than the drop down menu allows. This does not help in this case: https://docs.python.org/3.4/library/asyncio-task.html#asyncio.ensure_future Also, you cannot select the docs for a maintenance release, like 3.4.3. Anyway, it’s not a big deal as long as significant changes are tagged appropriately with notes like “New in version NNN”, which they are. Ideally, the docs would only show the latest changes for released versions of Python, but since some changes (like the one I linked to) are introduced in maintenance versions, it’s probably hard to separate them out into separate branches. Nick On Wed, Jun 10, 2015 at 10:11 AM Nicholas Chammas nicholas.cham...@gmail.com wrote: For example, here is a New in version 3.4.4 method: https://docs.python.org/3/library/asyncio-task.html#asyncio.ensure_future However, the latest release appears to be 3.4.3: https://www.python.org/downloads/ Is this normal, or did the 3.4.4 docs somehow get published early by mistake? Nick -- https://mail.python.org/mailman/listinfo/python-list
Did the 3.4.4 docs get published early?
For example, here is a New in version 3.4.4 method: https://docs.python.org/3/library/asyncio-task.html#asyncio.ensure_future However, the latest release appears to be 3.4.3: https://www.python.org/downloads/ Is this normal, or did the 3.4.4 docs somehow get published early by mistake? Nick -- https://mail.python.org/mailman/listinfo/python-list
Re: Did the 3.4.4 docs get published early?
Also, just replacing the version number in the URL works for the python 3 series (use 3.X even for python 3.0), even farther back than the drop down menu allows. This does not help in this case: https://docs.python.org/3.4/library/asyncio-task.html#asyncio.ensure_future Also, you cannot select the docs for a maintenance release, like 3.4.3. Anyway, it’s not a big deal as long as significant changes are tagged appropriately with notes like “New in version NNN”, which they are. Ideally, the docs would only show the latest changes for released versions of Python, but since some changes (like the one I linked to) are introduced in maintenance versions, it’s probably hard to separate them out into separate branches. Nick On Wed, Jun 10, 2015 at 10:11 AM Nicholas Chammas nicholas.cham...@gmail.com wrote: For example, here is a New in version 3.4.4 method: https://docs.python.org/3/library/asyncio-task.html#asyncio.ensure_future However, the latest release appears to be 3.4.3: https://www.python.org/downloads/ Is this normal, or did the 3.4.4 docs somehow get published early by mistake? Nick -- https://mail.python.org/mailman/listinfo/python-list
[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument
Changes by Nicholas Chammas nicholas.cham...@gmail.com: -- nosy: +Nicholas Chammas ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
