[issue35897] Support list as argument to .startswith()
Fred added the comment: > For subtle reasons, that would make us worse off. Tuple of constants get > precomputed but lists of constants have to be rebuilt. So if a list is 20 times slower than a tuple, I can still do billions of computations in a second on a Raspberry Pi, so does it matter? Being able to pass a list into .startswith() makes it more user-friendly and makes Python be more productive for the developer. -- ___ Python tracker <https://bugs.python.org/issue35897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46027] email.utils.parsedate_to_datetime() handling of -0000 offset
New submission from Fred Drake : A local time offset of '-' is not handled the same way as an offset of '+', but I'd expect it would be: >>> import email.utils >>> >>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 -') datetime.datetime(2021, 12, 9, 8, 52, 4) >>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 +') datetime.datetime(2021, 12, 9, 8, 52, 4, tzinfo=datetime.timezone.utc) I observe the same behavior on Python 3.9.9 and 3.10.1. -- components: email messages: 408149 nosy: barry, fdrake, r.david.murray priority: normal severity: normal status: open title: email.utils.parsedate_to_datetime() handling of - offset type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
Fred added the comment: Yeah, those other languages such as C# and JavaScript and others make async much more easier, approachable, reduces boilerplate code and lowers the bar for entry! -- ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
Fred added the comment: I don't care what async framework is used, nor do I care if its a x86 or ARM, or if its Windows or Linux. I don't want to have to setup an async runner because it is boilerplate code, and it brings concern into my application which is outside of the domain of my application. In JavaScript, I can just call await fetch() or any other asynchronous function without having to pick and configure a async runtime. On .NET it is also very easy, just await a function at the top-level without declare any runtime either. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/top-level-statements Python is suppose to be a high-level language. Programmers should focus on their domain, not underlying things such as which runtime to use, which garbage collector to use, etc. -- ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
Fred added the comment: $ python3 --async myscript.py unknown option --async Also I cannot go around telling other people how to run my script. My script must be able to run properly without any special setup. -- ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
Fred added the comment: I think it would fit with the design and commmunity of Python. I think people who use Python don't care about what async runtime it is, or how to configure it or set it up, they just want to call async functions. This is 2021, we live in a async-first world. I think users expect to be able to do async with minimal friction. Other languages like C# lets you do it easy, by changing: static void Main() {} to: static async Task Main() {} -- ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
Fred added the comment: No, I was not aware of that. After I started Python by running "python3 -m asyncio" then it behaved as I expected it should behave by default. But this seems to work only in the REPL. I would like to write Python scripts stored in files where I can easily await at the top level as in the example in my first post. -- ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45625] Add support for top-level await
New submission from Fred : I want top-level await without any boilerplate code or setup. Just write a "await" statement on line 1 without any indention. #!/usr/bin/env python3 import asyncio await asyncio.sleep(1) I don't want to have to call asyncio.run(main()), and I don't want to have to put the await inside an async function. -- components: Interpreter Core messages: 405088 nosy: Fred priority: normal severity: normal status: open title: Add support for top-level await type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40990] Make http.server support SSL
Fred added the comment: How is this going? Any progress? -- ___ Python tracker <https://bugs.python.org/issue40990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40990] Make http.server support SSL
Fred added the comment: It could look for a existing certificate in a well-known location, and could fallback to an self-signed certificate that could be shipped with Python. -- nosy: +Fred ___ Python tracker <https://bugs.python.org/issue40990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44169] Add HTTPS support to http.server
New submission from Fred : The http.server module only supports HTTP. https://docs.python.org/3/library/http.server.html I propose that it should also support HTTPS. This would allow it to serve files that depend on features that are restricted to secure contexts. https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts -- components: Library (Lib) messages: 393867 nosy: Fred priority: normal severity: normal status: open title: Add HTTPS support to http.server type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44169> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: PR applied and backported; closing this. Thanks, Jared! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: New changeset 455583b54aaec9a4266ff37dd438cbbd8ec6068a by Miss Islington (bot) in branch '3.8': bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025, GH-5030) https://github.com/python/cpython/commit/455583b54aaec9a4266ff37dd438cbbd8ec6068a -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: New changeset f311290f091957653bba5ebfda28ad981bb78363 by Miss Islington (bot) in branch '3.9': bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025) (#25027) https://github.com/python/cpython/commit/f311290f091957653bba5ebfda28ad981bb78363 -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: New changeset 21a2cabb3795f5170c746ab8f29e9d25c7442550 by Jared Sutton in branch 'master': bpo-43620: Remove reference to os.sep from os.path.join() doc (#25025) https://github.com/python/cpython/commit/21a2cabb3795f5170c746ab8f29e9d25c7442550 -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: Just reviewed the documentation for both os.sep and os.path.join(). The os.sep docs do not suggest it can be set, and the reference in the os.path.join() description is silent regarding that, so can be read as Jared did. I don't recall this coming up before, but... there's a lot I don't remember at this point. --sigh-- Removing the reference to os.sep from the os.path.join() description would not be confusing, IMO. Clearly, the ambiguity can bite. I'd be open to a patch to remove the reference to os.sep from the os.path.join() docs. Reopening, but removing 3.6 and 3.7 since they're in security-fix-only mode. -- keywords: +easy resolution: not a bug -> stage: resolved -> needs patch status: closed -> open versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Fred Drake added the comment: Perhaps Jared was expecting that modifying os.sep would affect the functions in os.path? os.sep was never intended to be updated. Using the specific *path modules to work with "foreign" paths has long been advocated as the way to do this. It isn't a work-around. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43353] Document that logging.getLevelName() can return a numeric value.
Fred Drake added the comment: New changeset 9bdb5802361016704fb3434369741cc6c5e08f02 by Mariusz Felisiak in branch '3.8': bpo-43353: Document that logging.getLevelName() accepts string representation of logging level. (GH-24693) (#24825) https://github.com/python/cpython/commit/9bdb5802361016704fb3434369741cc6c5e08f02 -- ___ Python tracker <https://bugs.python.org/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43353] Document that logging.getLevelName() can return a numeric value.
Fred Drake added the comment: Mariusz: Good point. IMO, an insane API behavior, but a legacy we must live with. No further objections from me. -- ___ Python tracker <https://bugs.python.org/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43353] Document that logging.getLevelName() can return a numeric value.
Fred Drake added the comment: Just noticed this fly by in the stream of emails... sorry for not commenting earlier. The patch seems to describe "Level #" as "numeric", which I would not be inclined to do. It includes the numeric value since there's no available name for it, but as a value, it's still textual. I'm referring specifically to the change here: https://github.com/python/cpython/commit/bbba28212ce0f58096a4043f32442c6e727b74fc#diff-1bf0ad6d121df3948853dafdd8e5406709fe0c3911b30e3cf2def41717455c98R121 Otherwise, I do believe this should be back-ported. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)
Change by Fred Drake : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39994] pprint handling of dict subclasses that override __repr__
Fred Drake added the comment: And that is why the original code was checking not only for the type, but the actual __repr__ method itself. I think the current behavior is broken. -- ___ Python tracker <https://bugs.python.org/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39994] Redundant code in pprint module.
Fred Drake added the comment: Ah, good find! It's been so long since the first version of that code, but the implementation was surprisingly nuanced. -- ___ Python tracker <https://bugs.python.org/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39994] Redundant code in pprint module.
Fred Drake added the comment: Adding serhiy.storchaka to nosy list since it looks like he introduced the isinstance check on purpose (see bpo-23741). Though bpo-23741 asserts that no behavior was changed with the patch applied then, reading through the change leads me to think this did change for cases like the MyDict example from iritkatriel. The intent of the original code was that MyDict.__repr__ would be used; only the small handful of "known" reprs would be handled specially. -- ___ Python tracker <https://bugs.python.org/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36207] robotsparser deny all with some rules
Fred AYERS added the comment: I tried this one http://gtxgamer.fr/robots.txt/";>http://gtxgamer.fr/robots.txt and it seems to work. -- nosy: +Fred AYERS ___ Python tracker <https://bugs.python.org/issue36207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40065] py39: remove deprecation note for xml.etree.cElementTree
Fred Drake added the comment: The Python 2.7 documentation was not clear that xml.etree.cElementTree was optional, so users who didn't dive into the implementation or build process could easily not have known unless someone with a more limited installation used their code. -- ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40065] py39: remove deprecation note for xml.etree.cElementTree
Fred Drake added the comment: Same core problem (module removed with insufficient document update), but a different action is needed for 3.8 and 3.9. When I started testing an application with 3.9 and found one of the dependencies broken because it was relying directly on xml.etree.cElementTree, I had to dig into the history to determine that it was removed intentionally. Updated documentation would have helped. I did file an issue on the dependency as well: https://github.com/boto/botocore/issues/2002 -- ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40065] py39: remove deprecation note for xml.etree.cElementTree
New submission from Fred Drake : Since xml.etree.cElementTree does not exist in Python 3.9, the statement that it's deprecated should be removed from the documentation. -- assignee: docs@python components: Documentation keywords: easy messages: 365016 nosy: docs@python, fdrake priority: normal severity: normal status: open title: py39: remove deprecation note for xml.etree.cElementTree versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40064] py38: document xml.etree.cElementTree will be removed in 3.9
Change by Fred Drake : -- keywords: +easy ___ Python tracker <https://bugs.python.org/issue40064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40064] py38: document xml.etree.cElementTree will be removed in 3.9
Change by Fred Drake : -- assignee: docs@python components: Documentation nosy: docs@python, fdrake priority: normal severity: normal status: open title: py38: document xml.etree.cElementTree will be removed in 3.9 versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39480] referendum reference is needlessly annoying
Change by Fred Drake : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue39480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Fred Drake added the comment: Thanks, Julien! Sounds good to me; no reason for a PR addressing this specific issue to be held up once one becomes available. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38621] Bad decoding of encoded-words in unstructured email headers
Change by Fred Drake : -- resolution: fixed -> rejected stage: resolved -> ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38621] Bad decoding of encoded-words in unstructured email headers
Fred Drake added the comment: It turns out this was a problem in 3.7.4; Python 3.7.5 seems to have fixed this. Sorry for the noise. Guess it's time to update my application to use 3.7.5! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38621] Bad decoding of encoded-words in unstructured email headers
Fred Drake added the comment: This problem does not exist in Python 3.6 or Python 3.8; it appears to only exist in Python 3.7. -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38619] [Doc] UUID.hex is lowercase
Fred Drake added the comment: While I don't know Felipe's use case, I would expect the documentation to be clear that the representation won't change in the future so users will know that this can be relied on to generate keys into some other persistent structure. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue38619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38621] Bad decoding of encoded-words in unstructured email headers
Fred Drake added the comment: It's worth noting that dealing with this header eventually causes the header parser to enter an infinite loop. -- ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38621] Bad decoding of encoded-words in unstructured email headers
New submission from Fred Drake : I've encountered a problem parsing an email with this Subject: header: Subject: Be sure to redeem your =?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year email._header_value_parser.get_unstructured defers to get_encoded_word, passing the argument '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year' get_encoded_word eventually calls email._encoded_words.decode with the argument '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year?=' This doesn't seem right, but I'm unsure of the syntactic priority of =XX and ?= in this case. The policy for this is email.policy.SMTP + email.policy.strict (not sure if that's ideal; I'm retrieving messages from mbox files and over IMAP). -- assignee: r.david.murray messages: 355564 nosy: barry, fdrake, r.david.murray priority: normal severity: normal status: open title: Bad decoding of encoded-words in unstructured email headers ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Fred L. Drake, Jr. added the comment: I'd like to see consistent usage by default, with specific examples using the older forms as appropriate. The use cases Raymond identified are worth discussing (and the tutorial may be a good place for this), and well as mentioned in the reference docs for the '%s' % x and ''.format() operations (and string.Template(), of course). I would not like to see different syntaxes randomly applied to different examples that happen to involve formatting, but where that's not the emphasis. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Fred L. Drake, Jr. added the comment: Definitely agree with Eric on this; code modernization is definitely on the risky side, so judicious updates are important. (Of course, not updating is also a risk, eventually. But not much of one in this case.) This issue is really about whether the docs should be updated to use the newer syntax. In general, I think we should update the docs, and we've delayed long enough for the general application of f-strings. There will be cases to be wary of, certainly. I'm thinking especially of calls to the logging methods, or anywhere else doing delayed formatting. (Not that I can think of others off the top of my head.) -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Fred L. Drake, Jr. added the comment: I agree that it's less invasive and easier to review. My question (and it's just that) is whether we've made a decision to prefer one formatting syntax over others (outside of examples discussing the formatting approaches themselves). If a decision is made to prefer one over others, it's worth making that decision separately, and then using separate PRs to deal with updates to different parts of the docs. Added Julien Palard to the issue; I'd value input on this. -- nosy: +JulienPalard ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Fred L. Drake, Jr. added the comment: Does it make sense to change just one example? I'm not sure what the long-term stance is on whether %-formatting should be replaced at this point, but shouldn't this be a matter of which string formatting approach we want overall, rather than adjusting only specific examples? -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38255] Replace "method" with "attribute" in the description of super()
Change by Fred L. Drake, Jr. : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue38255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38255] Replace "method" with "attribute" in the description of super()
Change by Fred L. Drake, Jr. : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue38255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37741] importlib.metadata docs not showing up in the module index
Fred L. Drake, Jr. added the comment: Provisional status should not cause a module or other API element to be omitted from the indexes. So long as it's marked provisional where it's described, it should be locatable. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue37741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34226] cgi.parse_multipart() requires undocumented CONTENT-LENGTH in Python 3.7
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue34226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14149] argparse: Document how to use argument names that are not Python identifiers
Change by Fred L. Drake, Jr. : -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.2, Python 3.3 ___ Python tracker <https://bugs.python.org/issue14149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36705] Unexpected Behaviour of pprint.pprint
Fred L. Drake, Jr. added the comment: Eric nailed it; pprint was not designed as a replacement for print, and was never intended to serve that purpose. Rejecting as out of scope. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36532] Example of logging.formatter with new str.format style
Fred L. Drake, Jr. added the comment: Good catch, Vinay! Thanks. -- ___ Python tracker <https://bugs.python.org/issue36532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36532] Example of logging.formatter with new str.format style
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
Fred L. Drake, Jr. added the comment: Updated target to Python 3.8, since this has aged a bit. -- versions: +Python 3.8 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue9883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36418] urllib.parse.*Result: support _replace for additional computed addresses
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31822] Document that urllib.parse.{Defrag, Split, Parse}Result are namedtuples
Fred L. Drake, Jr. added the comment: To clarify: I'm not suggesting that an API expansion should be considered as part of this issue. -- ___ Python tracker <https://bugs.python.org/issue31822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31822] Document that urllib.parse.{Defrag, Split, Parse}Result are namedtuples
Fred L. Drake, Jr. added the comment: Unfortunately, when the implementation was migrated to use collections.namedtuple (a benefit), the _replace method wasn't extended to support the additional computed addresses for these types. That would really be useful. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue31822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36138] Improve documentation about converting datetime.timedelta to scalars
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35897] Support list as argument to .startswith()
Fred .Flintstone added the comment: A programmer want to instruct the computer to do something, without having to care about how it works. Maybe the library could in the background convert the list to a tuple. Like: "foo".startswith(tuple(["food", "for", "fast"])) But the programmer shouldn't have to worry about this. I have a list, I want to use the list. I shouldn't have to care about interpreter internals that have nothing to do with the intent of my code. My code should clearly represent intent, not have boilerplate code or constructs to workaround interpreter internals. -- ___ Python tracker <https://bugs.python.org/issue35897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35897] Support list as argument to .startswith()
New submission from Fred .Flintstone : The "".startswith() method accepts a string or a tuple as a parameter. Consider adding support for list as parameter. Example: "foo".startswith(["food", "for", "fast"]) -- components: Interpreter Core messages: 334856 nosy: Fred .Flintstone priority: normal severity: normal status: open title: Support list as argument to .startswith() type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue35897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35831] Format Spec example says limited to 3.1+ but works in 2.7
Fred L. Drake, Jr. added the comment: The 3.X docs generally don't refer to the 2.X series. What that comment is pointing out is that leaving the field identifier out (the number inside the {...} placeholder syntax) was not in the 3.0, but added in 3.1. Unfortunately, I don't have a 3.0 interpreter available to show the exception that's raised. No change is required. -- nosy: +fdrake stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33381] Incorrect documentation for strftime()/strptime() format code %f
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue33381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11233] clarifying Availability: Unix
Fred L. Drake, Jr. added the comment: A PR for this would be good, and would certainly accelerate getting this accomplished. Thanks, Cheryl! -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue11233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
Fred L. Drake, Jr. added the comment: The existing PR can be re-targeted to merge to a maintenance branch (I'd be inclined to merge manually, myself, but will have to check the current devguide to make sure that's still allowed). A new PR can be made for the non-documentation fix for master. My thought is that a PR is more about the patch than about the workflow; a different patch can be handled in a separate PR, and review & discussion are used to determine which PR should be applied where. -- ___ Python tracker <https://bugs.python.org/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
Fred L. Drake, Jr. added the comment: It probably makes more sense to keep that PR for the maintenance branches, and create a new branch / PR to land on master. -- ___ Python tracker <https://bugs.python.org/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
Fred L. Drake, Jr. added the comment: I'm just going to presume this issue has been around a long time, but I think that's a pretty safe presumption. Accepting a general sequence instead of only a list would reasonable, and I'd support a fix that caused the code to accept a general sequence (or any iterable) by calling list() on the passed-in value, starting with 3.8. The patch provided looks good for versions in maintenance. (It would also be fine for 3.8 if there's no interest in generalizing the code to accept arbitrary iterables). -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15474] Differentiate decorator and decorator factory in docs
Fred L. Drake, Jr. added the comment: I like Éric's terminology; giving a concrete name to the concept makes it a lot easier to grasp, and this doesn't require inventing any new component terms. Andrés, if you'd like to tackle this, that's great! I'd be happy to for you to bounce drafts through me if you like. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue15474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33869] doc Add set, frozen set, and tuple entries to Glossary
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue33869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
Change by Fred L. Drake, Jr. : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
Fred L. Drake, Jr. added the comment: Indeed, I did not. Fixed now. I hope. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
Fred L. Drake, Jr. added the comment: A quick grep on the 3.7 branch indicates that the standard documentation includes each of the terms "magic method" and "special method" about the same number of times. (I didn't check for instances that wrapped lines.) Perhaps we should decide on just one of these terms and fix references that use the other. I agree this can be a source of confusion, but having two terms for the same concept is a bug. I don't think we need to change references to "the __something__ method", because those are specific. We only need to decide on and consistently use the categorical term for these methods when referring to the entire category. -- nosy: +fdrake -pablogsal, rhettinger ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
Fred L. Drake, Jr. added the comment: > I saw what looked to me like a bug that's been in the code for 18 years, > and I saw that it was a simple fix. And you're right: It is a bug, the fix is simple, and the risk is low. Ten years ago, I'd have probably just landed the fix on all applicable branches and moved on. But the longer something stays the same (like you said, for 18 years now), the more surprising a fix can be when something (however foolishly and unlikely it seems) relied on the old, broken behavior falls apart because of the change. Please don't think we don't appreciate your contribution; we do. I hope you'll continue to be observant and catch bugs (even little ones!), and provide fixes. Feel free to reach out if you'd like to discuss this further. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
Fred L. Drake, Jr. added the comment: New changeset 5bfa058e65897567889354d7eb34af2b93a20f18 by Fred Drake (arikrupnik) in branch 'master': bpo-33274: Compliance with DOM L1: return removed attribute (#7465) https://github.com/python/cpython/commit/5bfa058e65897567889354d7eb34af2b93a20f18 -- ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
Fred L. Drake, Jr. added the comment: I should stop relying on wetware memory; it's not working out. Sorry for the mis-information. -- ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
Fred L. Drake, Jr. added the comment: Python 2.7 is in security-fix-only mode, and this doesn't fit that. While I wouldn't object to a note in the documentation, see my comments in my patch review (there's just no place for it to go). -- ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
Fred L. Drake, Jr. added the comment: While I've no strong objection to updating to follow the specification, I also don't see any real value here. The current minidom implementation has been considered sufficient for many years now (if you consider the DOM desirable at all), so the lack of conformance with the W3C spec doesn't seem significant in practice. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1644818] Allow built-in packages and submodules as well as top-level modules
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue1644818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32706] test_check_hostname() of test_ftplib started to fail randomly
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue32706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Fred L. Drake, Jr. added the comment: This has landed on master and will be part of Python 3.7. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Fred L. Drake, Jr. added the comment: New changeset 96a5e50a5de3683b2afd6d680c7ecc4b525986f6 by Fred Drake (Giuseppe Scrivano) in branch 'master': bpo-32143: add f_fsid to os.statvfs() (#4571) https://github.com/python/cpython/commit/96a5e50a5de3683b2afd6d680c7ecc4b525986f6 -- ___ Python tracker <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Fred L. Drake, Jr. added the comment: I think Giuseppe's patch is good, but there's a Windows failure on AppVeyor, so I'm a little wary. It doesn't look related, but I haven't looked at Python on Windows since... 2001, maybe? -- ___ Python tracker <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31766] Python 3.5 missing from documentation
Fred L. Drake, Jr. added the comment: The 3.5 docs should really remain in the main docs UI via the pulldown as long as it's so widely used. The fact that it won't be changing much just means it can be served efficiently. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue31766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29400] Add instruction level tracing via sys.settrace
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue29400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
Fred L. Drake, Jr. added the comment: On Thu, Jul 27, 2017 at 3:01 PM, Fred L. Drake, Jr. wrote: > If the link went to an edit form with the version of the content the > user was reading, > and includes an explanation of the multiple-versions issue, it might > prove reasonable Egads, look at that formatting! Somedays I miss my VT-100 terminals and sane line handling. -Fred -- ___ Python tracker <http://bugs.python.org/issue31055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
Fred L. Drake, Jr. added the comment: On Thu, Jul 27, 2017 at 1:03 PM, Mariatta Wijaya wrote: > I don't think we should add this link. > > When we make edits to the docs, even simple typo fixes, it should first be > done > in the master branch, instead of the maintenance branches (e.g. 2.7, 3.5 or > 3.6). > > If "Edit This Page" link takes you to edit the documentation in branches other > than "master", that's not desirable workflow. > > If "Edit This Page" link takes you to edit the master branch, it can be > confusing > to the contributor since the content on "master" might be different. I wonder if a better solution lies somewhere between the original suggestion and just not including such a link. If the link went to an edit form with the version of the content the user was reading, and includes an explanation of the multiple-versions issue, it might prove reasonable to try applying the diff between the modified and original text to the HEADs of each maintenance branch. If the diff doesn't apply, the (possibly new) contributor can be offered a chance to deal with edits to each version (which might be a bit much). At any rate, the diff could be used to construct a temporary branch, b.p.o issue, and PR. This would allow us to provide the contributor with a way to see that their suggested changes are being considered, and we're less likely to lose them in a wall of email. There'd be a bit of work to make all this play out, though. -Fred -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue31055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
Fred L. Drake, Jr. added the comment: I agree that writexml should be available for document fragments. I doubt the additional level of indentation should be added, as you've included in point 2. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue9883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29996] Use terminal width by default in pprint
Fred L. Drake, Jr. added the comment: I wouldn't go so far as to say it's never come up; it's something I've thought about a number of times, and I've waffled on it a few times. It's not fundamentally unreasonable to want it to adapt to the current terminal window, though I think it would be in a minority among the Unix command line tools that I use. Raymond's point about potentially confusing students is an important one, though. If adaptive behavior is sufficiently desirable, the module should check the value of an environment variable, and default to the current behavior. PYTHONADAPTIVEPPRINT ? -- ___ Python tracker <http://bugs.python.org/issue29996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29996] Use terminal width by default in pprint
Fred L. Drake, Jr. added the comment: This is not a problem for doctests, since the output stream is not a terminal; the check for terminal-ness seems reasonable. (Though I don't have any idea if it works on Windows, but it seems properly factored.) -- ___ Python tracker <http://bugs.python.org/issue29996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29997] Suggested changes for https://docs.python.org/3.6/extending/extending.html
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue29997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27879] add os.syncfs()
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue27879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] Add a profile decorator to profile and cProfile
Changes by Fred L. Drake, Jr. : -- nosy: -fdrake ___ Python tracker <http://bugs.python.org/issue9285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29601] Need reST markup for enum types
Fred L. Drake, Jr. added the comment: Is there some special treatment you think should be given to specific enum values as well? -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue29601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
Fred L. Drake, Jr. added the comment: "in" and "not in" are not comparisons, regardless of implementation mechanics (which could change). They aren't really dependent on iteration, though they often correlate with iteration. I'd rather see them described as "containment tests" or something similar. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19795] Formatting of True/False/None in docs
Fred L. Drake, Jr. added the comment: Without the star would be right. ReST does not support nested markup, and in this case, I don't think it would make sense anyway. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue19795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28278] Make `weakref.WeakKeyDictionary.__repr__` meaningful
Fred L. Drake, Jr. added the comment: I don't recall that the issues discussed here were considered when these classes were added; functionality was the issue at the time. I'm not particularly opposed to adding a more data-ful repr for the weakref-oriented mappings, but I'm not really convinced they'd be all that valuable, either. Interesting mappings are often too well populated to deal with using repr. -- ___ Python tracker <http://bugs.python.org/issue28278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27495] Pretty printing sorting for set and frozenset instances
Fred L. Drake, Jr. added the comment: +1 It could reasonably be argued that not sorting is a bug for already-released 3.x versions. -- ___ Python tracker <http://bugs.python.org/issue27495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18085] Verifying refcounts.dat
Fred L. Drake, Jr. added the comment: I don't think this is a duplicate of issue 9755; this relates to verifying the data, and that revolves around possible process improvements. Whether this issue should be closed is tied to whether the file has been verified, as the issue title suggests. I don't know whether Serhiy verified everything when he made his changes or not; that's not explicit in the issue or commit comments. -- ___ Python tracker <http://bugs.python.org/issue18085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9755] Fix refcounting details in Py3k C API documentation
Fred L. Drake, Jr. added the comment: As mentioned in issue 18085, the original file was not generated, but crafted by hand (though I don't think that really matters). -- ___ Python tracker <http://bugs.python.org/issue9755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values
Fred L. Drake, Jr. added the comment: +1 for ValueError instead of OSError. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue23116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
Fred L. Drake, Jr. added the comment: I've read through this, but haven't applied the patch & run tests (that's what buildbots are for). No objections. -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
Fred L. Drake, Jr. added the comment: I see your message to python-dev, and apologize for taking so long to get to this. I do intend to read through your changes, and hope to be able to make time while I'm at PyCon this coming week. -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com