[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
[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
