[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
[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
[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
[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
[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
[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
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: $ 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 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: 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
[issue1031] Datetime enhancements
New submission from Fred Flinstone: Copy of issue 1665292 -- components: Library (Lib) messages: 51803 nosy: FredFlinstone, tiran severity: normal status: open title: Datetime enhancements type: rfe versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8033] sqlite: broken long integer handling for arguments to user-defined functions
New submission from Fred Fettinger : Handling of long integers is broken for arguments to sqlite functions created with the create_function api. Integers passed to a sqlite function are always converted to int instead of long, which produces an incorrect value for integers outside the range of a int32 on a 32 bit machine. These failures cannot be reproduced on a 64 bit machine, since sizeof(long) == sizeof(long long). I attached a program that demonstrates the failure. This program reports failures on a 32 bit machine, and all tests pass on a 64 bit machine. -- components: Library (Lib) files: sqlite_long_test.py messages: 100235 nosy: BinaryMan32 severity: normal status: open title: sqlite: broken long integer handling for arguments to user-defined functions type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file16404/sqlite_long_test.py ___ Python tracker <http://bugs.python.org/issue8033> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8033] sqlite: broken long integer handling for arguments to user-defined functions
Fred Fettinger added the comment:
I've never really looked at the python source before, but this is my best guess
at the problem:
For the standard SELECT query:
In Modules/_sqlite/cursor.c, _pysqlite_fetch_one_row() has this code:
PY_LONG_LONG intval;
...
} else if (coltype == SQLITE_INTEGER) {
intval = sqlite3_column_int64(self->statement->st, i);
if (intval < INT32_MIN || intval > INT32_MAX) {
converted = PyLong_FromLongLong(intval);
} else {
converted = PyInt_FromLong((long)intval);
}
}
For user-defined function arguments:
In Modules/_sqlite/connection.c, _pysqlite_build_py_params() has this code:
PY_LONG_LONG val_int;
...
case SQLITE_INTEGER:
val_int = sqlite3_value_int64(cur_value);
cur_py_value = PyInt_FromLong((long)val_int);
break;
A select query can return long integers from C to python but a user-defined
function argument cannot.
--
___
Python tracker
<http://bugs.python.org/issue8033>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://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
[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
[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: 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
[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
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
[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
[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
[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: 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: 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 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: 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
[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
[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
[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
[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
[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
[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
[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
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
[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
[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
[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
[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
[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] 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
[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
[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
[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
[issue7980] time.strptime not thread safe
Fred Wheeler added the comment: This issue should be noted in the documentation of strptime in the time and datetime modules and/or the thread module. As it stands there is no good way for a user of these modules to learn of this problem until one day the right race conditions exist to expose the problem. Perhaps the following notes will do? https://docs.python.org/2/library/time.html#time.strptime Thread safety: The use of strptime is thread safe, but with one important caveat. The first use of strptime is not thread safe because the first use will import _strptime. That import is not thread safe and may throw AttributeError or ImportError. To avoid this issue, import _strptime explicitly before starting threads, or call strptime once before starting threads. https://docs.python.org/2/library/datetime.html (under strptime()) See time.strptime() for important thread safety information. Having just encountered this unusual and undocumented thread safety problem using 2.7.6, I'm wondering if there are other similar lurking thread safety issues that I might only find when the race conditions are just right and my program stops working. -- nosy: +fredwheeler ___ Python tracker <http://bugs.python.org/issue7980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20121] quopri_codec newline handling
New submission from Fred Stober:
While trying to encode some binary data, I encountered this behaviour of the
quopri_codec:
>>> '\r\n\n'.encode('quopri_codec').decode('quopri_codec')
'\r\n\r\n'
>>> '\n\r\n'.encode('quopri_codec').decode('quopri_codec')
'\n\n'
If this behaviour is really intended, it should be mentioned in the
documentation that this coded is not bijective.
--
components: Library (Lib)
messages: 207281
nosy: fredstober
priority: normal
severity: normal
status: open
title: quopri_codec newline handling
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue20121>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6043] HTMLParseError derivation
New submission from Fred Bayer :
Acoording to documentation, only a few exceptions should inherit
directly from Exception, most should inherit from StandardError.
However, HTMLParser.HTMLParseError doesn't conform:
isinstance(HTMLParser.HTMLParseError("foo"),StandardError) --> False
--
components: Library (Lib)
messages: 87944
nosy: bayerf
severity: normal
status: open
title: HTMLParseError derivation
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue6043>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25474] Weird behavior when setting f_trace in a context manager
New submission from Fred Gansevles: I'm playing with the idea of making a DSL based on anonynous code blocks I discovered that the behaviour of the context manager is different in some cases if there are line-continuations in the 'with' command I've attached a script that reproduces this behaviour. With both Python 2.7.6 and Python 3.4.3 I get the same results. Fred. -- files: as_context.py messages: 253426 nosy: Fred Gansevles priority: normal severity: normal status: open title: Weird behavior when setting f_trace in a context manager type: behavior Added file: http://bugs.python.org/file40858/as_context.py ___ Python tracker <http://bugs.python.org/issue25474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25474] Weird behavior when setting f_trace in a context manager
Fred Gansevles added the comment: Xavier, thanks for looking at my post. But, since all six invocations of the context manager are the same - I did an 'ast.parse' and 'ast.dump' and the the six calls were *exactly* the same (save lineno and col_offset) - why does 'zero', 'one', 'four' and 'five' get assigned but 'two' and 'three' not ? -- ___ Python tracker <http://bugs.python.org/issue25474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25474] Weird behavior when setting f_trace in a context manager
Fred Gansevles added the comment: Xavier, thanks! you found it. If I look the code again, I see that with zero, one, four and five the context-manager (i.e. Context()) and the target (one .. five) are on the same code-line In the case of two and three they are on a different line. Now, with the dependency of the trace function on the *physical line* it all make sense. Fred. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue25474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26329] os.path.normpath("//") returns //
New submission from Fred Rolland:
Hi,
os.path.normpath("//") returns '//'
I would expect to be '/'
>>> os.path.normpath("//")
'//'
>>> os.path.normpath("///")
'/'
>>> os.path.normpath("")
'/'
--
components: Library (Lib)
messages: 260016
nosy: Fred Rolland
priority: normal
severity: normal
status: open
title: os.path.normpath("//") returns //
versions: Python 2.7, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26329>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue469773] Write 'Using Python on Platform X' documents
Changes by Fred L. Drake, Jr.: -- assignee: fdrake -> Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue469773> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue870479] Scripts need platform-dependent handling
Fred L. Drake, Jr. added the comment: Removing the assignment to me, since I'm not going to resolve the fundamental disagreements about what "the right thing" is. Someone else can argue with the wrong-headed. -- assignee: fdrake -> Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue870479> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1209562] add single html files
Fred L. Drake, Jr. added the comment: Might be nice, but it's obvious I've not gotten to this, so removing myself from the issue. -- assignee: fdrake -> _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1209562> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1126] file.fileno and file.isatty() should be implementable by any file like object
Fred L. Drake, Jr. added the comment: The documentation does not say what's implied by msg55724; they methods can (and arguably should) be implmented by types for which they apply (for which there is a corresponding file descriptor, for example). There is an API issue here as well: what about a wrapper type that is sometimes associated with a real file, and sometimes not? I suppose in that case the factory (constructor) needs to detect the situation and return an instance of an appropriate type. The documentation is clear, so far as it goes, but is arguably incomplete. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1126> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Fred L. Drake, Jr. added the comment: Looks good to me too. This should be committed. -- assignee: fdrake -> jafo resolution: -> accepted versions: +Python 2.5, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1053] bogus attributes reported in asyncore doc
Fred L. Drake, Jr. added the comment: Fixed for the 2.5.2 (revision 58328) and 2.6 (revision 58327) releases. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1053> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1317] smtplib.SMTP docs
New submission from Fred L. Drake, Jr.: The docstring for the smtplib.SMTP class includes descriptions of some instance attributes that are not covered by the documentation: does_esmtp ehlo_resp esmtp_features helo_resp If these are intended as part of the public interface, they should be documented in the .tex/.rst documentation, otherwise their descriptions should be in a comment instead of a docstring. (helo_resp is mentioned in Misc/HISTORY, if that actually means anything.) -- components: Documentation messages: 56688 nosy: fdrake severity: normal status: open title: smtplib.SMTP docs type: rfe versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1317> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Changes by Fred L. Drake, Jr. : -- nosy: -fdrake ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11379] Remove "lightweight" from minidom description
Fred L. Drake, Jr. added the comment: Removing "Lightweight" and changing the first paragraph to (something like) :mod:`xml.dom.minidom` is an implementation of the Document Object Model interface. The API is slightly simpler than the full W3C DOM, but the implementation has a significantly higher memory footprint than :mod:`xml.dom.etree`. would be entirely reasonable. (I don't think it's wrong to discuss relative memory footprints in comparison to other modules in the standard library.) -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue11379> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use secured channel for uploading packages to pypi
Fred L. Drake, Jr. added the comment: On Wed, Jun 1, 2011 at 11:14 AM, anatoly techtonik wrote: > Adding catalog-sig to CC. I can guarantee this for Windows. I'll be > near Linux box tomorrow and will try upload to PyPI from there. It > still will be more authoritative if more than one person can test > upload to PyPI with this patch on different systems. The interesting case will be for a build that doesn't include SSL support. -Fred -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use secured channel for uploading packages to pypi
Fred L. Drake, Jr. added the comment: On Mon, Jun 6, 2011 at 11:50 AM, Éric Araujo wrote: > If you make an HTTPS connection without checking the certificate, what > security does it add? I'm in favor of cert checking, myself. -- ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Fred L. Drake, Jr. added the comment: People working on this should probably also look at how zc.buildout's zc.recipe.egg handles script generation. It's similar to setuptools in that "console_script" entry points are used, but it binds in the desired Python executable as well. (If you ran the build with an unversioned Python executable name, that's what you get, but if you use a versioned path, it's retained.) -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12409] Moving "Documenting Python" to Devguide
Fred L. Drake, Jr. added the comment: -1 > Hi! We have the devguide now, and it should be the place where to look > for references and docs about contributing to Python, that means also > for the documentation. For information specific to the Python documentation itself, but not relevant to users documenting their own projects, yes. > In the official Python doc we have a section "Documenting Python" > (http://docs.python.org/py3k/documenting/index.html) and I think it > should be merged into the devguide - what's your opinion on that? The scope of this document is much larger than Python's documentation, but extends to all projects written in Python that use Sphinx as their documentation tool. With that, it makes sense to keep it as part of the documentation for users of Python. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10149] Data truncation in expat parser
Fred L. Drake, Jr. added the comment: Chunking of the data is expected with Expat. There are no promises about *where* chunks are broken; the underlying behavior will break at line endings, but is not limited to that. Setting buffer_text informs the Python wrapper that it's allowed to combine the chunks reported by the Expat library; this was made optional since it could affect working applications (changing the default with the move to Python 3 may have been acceptable, though). -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly braces in fnmatch
Fred L. Drake, Jr. added the comment:
It's worth noting that the sh-like shells are far more widely used than the
csh-like shells, so csh-like behavior may surprise more people.
>From the sh-like shell perspective, the {...,...} syntax just isn't part of
>the globbing handling.
--
nosy: +fdrake
___
Python tracker
<http://bugs.python.org/issue9584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1055864] HTMLParser not compliant to XHTML spec
Fred L. Drake, Jr. added the comment: Indeed it is. Closing, won't fix. HTMLParser tries to deal with XHTML constructs only so much as HTML ends up with that stuff, not because it's trying to handle everything. (The claimed example appears not to have been attached, anyway.) -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue1055864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2830] Copy cgi.escape() to html
Fred L. Drake, Jr. added the comment: Encoding the forward slash should not cause problems, but the quote “forward slash is included as it helps end an HTML entity” is confused; there's no need or additional value in escaping the forward slash. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue2830> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Re-opening for investigation. (The previous message really should have been a new issue.) -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Changes by Fred L. Drake, Jr. : -- nosy: +lukasz.langa ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: I've attached a diagnostic script that I ran with Python 2.4..3.2 (current py3k HEAD); there are two output variants: "old style": [section] option = None "new style": [section] option This is the output I get when running this script for each of those Python versions: 2.4.6 RawConfigParser: old-style output 2.4.6 SafeConfigParser: raised TypeError on set 2.4.6 ConfigParser: old-style output 2.5.5 RawConfigParser: old-style output 2.5.5 SafeConfigParser: raised TypeError on set 2.5.5 ConfigParser: old-style output 2.6.5 RawConfigParser: old-style output 2.6.5 SafeConfigParser: raised TypeError on set 2.6.5 ConfigParser: old-style output 2.7 RawConfigParser: new-style output 2.7 SafeConfigParser: raised TypeError on set 2.7 ConfigParser: new-style output 3.1.1 RawConfigParser: old-style output 3.1.1 SafeConfigParser: raised TypeError on set 3.1.1 ConfigParser: old-style output 3.2a1+ RawConfigParser: new-style output 3.2a1+ SafeConfigParser: raised TypeError on set 3.2a1+ ConfigParser: new-style output Essentially: For the RawConfigParser and ConfigParser classes, the output changes in 2.7 and 3.2, and in a way that should be considered incorrect because it conflicts with the allow_no_values setting. This is a bug and should be fixed in both 2.7 and 3.2. The TypeError-on-set is consistently raised only for SafeConfigParser, and should remain unchanged. (Why this was handled differently for SafeConfigParser I don't recall offhand.) -- Added file: http://bugs.python.org/file18717/cpsample.py ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Attached fix & test for Python 2; adjusting to Python 3 is trivial. The test could be added to 2.6 as well to protect against regressions there, though that's unlikely to be a significant issue. -- Added file: http://bugs.python.org/file18718/issue-7005.patch ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Commited as r84443 (release27-maint), r8 (py3k) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: My question in IRC wasn't intended to mean "why are we passing settings to the constructor" so my much as "why are these configuration settings"; sorry I wasn't clear. Have we encountered actual use cases that are not covered by the existing code? I don't recall ever seeing a request for more flexibility in that regard. -- ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: Regardless, my concerns about including delimiters and comment_prefixes as settings is irrelevant to this issue. The changes to them probably shouldn't have been part of this issue to begin with, but I'll try not to lose sleep over it at this point. -- ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: The patch has been commited largely as-is (r84486). I'm not happy with the documentation yet: - Markup like this: .. method:: ConfigParser.getint(section, option, raw=False, [vars, default]) doesn't sit well with me. I'm going to dig around current practice a bit and discuss with Georg sometime over the next few days, and see how best to adjust that. - Inclusion of references to internal names in the API docs, like this in the signatures: comment_prefixes=_COMPATIBLE is just bad form. Again, we need a better way. I suspect there is little if any considered precedent, so we'll come up with something. Neither of these are blockers; we can adjust this independently of the code and doocumentation content. (It's not part of the feature.) Leaving this issue open for the completion of these changes. -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue976869] Stripping script extensions with distutils
Fred L. Drake, Jr. added the comment: At this point, I'm more in favor of adopting something closer to the setuptools scripts based on "console_scripts" entry points, and dropping old-style scripts entirely (most *because* of the issues I mentioned at the start). -- ___ Python tracker <http://bugs.python.org/issue976869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue870479] Scripts need platform-dependent handling
Fred L. Drake, Jr. added the comment: As noted in issue 976869, I'm very much in the camp of entry-point based generated scripts, which should clearly use the right line endings for the host platform. Hacking around with the file copy just doesn't make sense moving forward. -- ___ Python tracker <http://bugs.python.org/issue870479> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: This is related to this issue from simplejson: http://code.google.com/p/simplejson/issues/detail?id=28 This problem is why I still use simplejson 1.x; moving forward to simplejson 2.x or Python's json is unlikely. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: As I understand it, the decision to return str instead of unicode values for the "simplejson" module was simply inherited by the standard library. As such, it still needs to be evaluated in the context of the standard library, because of the incompatibility it introduces. I still maintain that it's a bug, and should be treated as such. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Causing perfectly good Python 2 applications to degrade in performance is bad, even if something else is available. This should be fixed as a regression. -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Ok, reading more carefully, it's not a regression. But it's certainly a bug, and should be fixed. -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Assigning to myself for review. -- assignee: -> fdrake keywords: +needs review ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Committed with minor changes in r85366 (release27-maint branch). -- keywords: -needs review resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10108] ExpatError not property wrapped
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: I'll note that it seems relevant that this package is not considered "externally maintained" by the terms of PEP 360: http://www.python.org/dev/peps/pep-0360/ Given the level of attention this has received from the originator of the code, we should not hesitate to commit technically acceptable changes to the Python repository, -- title: json.loads() on str should return unicode, not str -> Returntype of json.loads() on strings ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Changes by Fred L. Drake, Jr. : -- title: Returntype of json.loads() on strings -> json.loads() on str should return unicode, not str ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Fred L. Drake, Jr. added the comment: Alternately, the Python implementation may be thought of as definitive and the optimizations are broken. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Fred L. Drake, Jr. added the comment: The incomplete testing and C/Python implementation mismatch are covered by issue 5723 and issue 9233. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10299] Add index with links section for built-in functions
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5412] extend configparser to support mapping access(__*item__)
Fred L. Drake, Jr. added the comment:
Code
- The __name__-aversion in the mapping interface is a little
heavy-handed, but given the implementation of __name__ elsewhere, I
think this can be revisited separately if anyone cares enough.
In particular, it should be allowed to give an __name__ value
explicitly and have it exposed:
>>> import configparser
>>> import io
>>> cp = configparser.RawConfigParser()
>>> cp.read_file(io.StringIO('[sect]\n__name__ = FooBar\n'))
>>> cp.get('sect', '__name__')
'FooBar'
>>> cp['sect']['__name__']
Traceback (most recent call last):
File "", line 1, in
File ".../py3k/Lib/configparser.py", line 1132, in __getitem__
raise ValueError(self._noname)
ValueError: __name__ special key access and modification not supported
through the mapping interface.
In this example, the __name__ key isn't special, it's just a key.
Documentation
=
- I dislike the 'fallback'/'default' terminology problem; everywhere
else, the fallback is called 'default'. This really points to
configparser (ne ConfigParser) not having been fully thought out
before it was released as part of Python. There's probably nothing
to be done about it at this point.
Has anyone attempted to determine how widely used the "defaults"
(mis-)feature is? I've not seen a good user for it as implemented
outside the original application ConfigParser was written for
(though others probably exist that have a similar need).
- There's no value in saying
`None` can be provided as a `fallback` value.
(regardless of the terminology). None is a value like any other, and
the docs already indicate it is used if provided. If anything need be
said, identify the exception raised if the default isn't provided and
no value is present.
Identifying None as a possible value isn't needed or done in any of
the mapping descriptions, so let's not add it here, even for the
methods that don't correlate to mapping methods.
- I dislike the documentation style where we indicate arguments are
keyword-only using a bare * in the signature, and then repeat that in
prose (this is not the only place this happens). It's redundant
(more work to maintain) and more verbose than helpful.
I still need to give the new docs a thorough read.
--
___
Python tracker
<http://bugs.python.org/issue5412>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10358] Doc styles for print should only use dark colors
New submission from Fred L. Drake, Jr. : The HTML version of the documentation should include style settings for printing that use fairly dark colors, so that printed copies of pages are more readable. Using a printer that reduces colors to grays causes the light colors in code examples (or inlined references to classes and the like) to nearly drop out, making the result very painful to read. -- assignee: d...@python components: Documentation keywords: easy messages: 120741 nosy: d...@python, fdrake priority: normal severity: normal stage: needs patch status: open title: Doc styles for print should only use dark colors type: feature request ___ Python tracker <http://bugs.python.org/issue10358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10386] token module should define __all__
Fred L. Drake, Jr. added the comment: Normally, I'd recommend leaving the "main" name alone, but in the case of modules that use it as an tool for module maintenance (symbol, token), I don't think it matters either way. Ok to commit. -- assignee: -> belopolsky nosy: +fdrake resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue10386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10373] Setup Script example incorrect
Fred L. Drake, Jr. added the comment: > perhaps the web page should be checked for an incorrect link. The link from the Python documentation to the Python bug tracker is fine. If you were using distutils directly, it would be an issue for the Python tracker. You're not. setuptools is a separate project; you should refer to it's documentation and it's tracker. -- nosy: +fdrake resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue10373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
New submission from Fred L. Drake, Jr. : Some portions of the documentation are using the term "member" to mean "data attribute". This appears to be an aberration at this time, but occurrences should be identified and corrected, and "Documenting Python" updated to note correct usage. Example use: http://docs.python.org/dev/py3k/library/xmlrpc.client.html#fault-objects http://docs.python.org/dev/py3k/library/urllib.request.html#basehandler-objects (paragraph starting "The following members and methods should") "Members and methods" should just be "attributes". -- assignee: d...@python components: Documentation messages: 121110 nosy: d...@python, fdrake priority: normal severity: normal status: open title: Use "member" consistently ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Changes by Fred L. Drake, Jr. : -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11372] Remove xrange from argparse docs
Fred L. Drake, Jr. added the comment: Committed for Python 3.3.0: r88717 Committed for Python 3.2.1: r88718 -- assignee: docs@python -> fdrake nosy: +fdrake resolution: -> accepted stage: -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue11372> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9101] reference json format in file formats chapter
Fred L. Drake, Jr. added the comment: And what are these people looking for? "json"? If so, there's already an entry in the module index. That seems sufficient. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue9101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12043] Update shutil documentation
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
