[issue40791] hmac.compare_digest could try harder to be constant-time.
Change by Devin Jeanpierre : -- keywords: +patch pull_requests: +19700 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20444 ___ Python tracker <https://bugs.python.org/issue40791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40791] hmac.compare_digest could try harder to be constant-time.
New submission from Devin Jeanpierre :
`hmac.compare_digest` (via `_tscmp`) does not mark the accumulator variable
`result` as volatile, which means that the compiler is allowed to short-circuit
the comparison loop as long as it still reads from both strings.
In particular, when `result` is non-volatile, the compiler is allowed to change
the loop from this:
```c
for (i=0; i < length; i++) {
result |= *left++ ^ *right++;
}
return (result == 0);
```
into (the moral equivalent of) this:
```c
for (i=0; i < length; i++) {
result |= *left++ ^ *right++;
if (result) {
for (; ++i < length;) {
*left++; *right++;
}
return 1;
}
}
return (result == 0);
```
(Code not tested.)
This might not seem like much, but it cuts out almost all of the data
dependencies between `result`, `left`, and `right`, which in theory would free
the CPU to race ahead using out of order execution -- it could execute code
that depends on the result of `_tscmp`, even while `_tscmp` is still performing
the volatile reads. (I have not actually benchmarked this. :)) In other words,
this weird short circuiting could still actually improve performance. That, in
turn, means that it would break constant-time guarantees.
(This is different from saying that it _would_ increase performance, but
marking it volatile removes the worry.)
(Prior art/discussion:
https://github.com/google/tink/commit/335291c42eecf29fca3d85fed6179d11287d253e )
I propose two changes, one trivial, and one that's more invasive:
1) Make `result` a `volatile unsigned char` instead of `unsigned char`.
2) When SSL is available, instead use `CRYPTO_memcmp` from OpenSSL/BoringSSL.
We are, in effect, "rolling our own crypto". The SSL libraries are more
strictly audited for timing issues, down to actually checking the generated
machine code. As tools improve, those libraries will grow to use those tools.
If we use their functions, we get the benefit of those audits and improvements.
--
components: Library (Lib)
messages: 370053
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: hmac.compare_digest could try harder to be constant-time.
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue40791>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: Oops, so it is. I can't read apparently. I'll spend my time on making more fuzz tests in the meantime. -- ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: kcc strongly disagrees though. Copying latest comment: """ fwiw - I object to us running any of this internally at Google. We need to be part of the main oss-fuzz project pulling from upstream revisions. Doing this testing within our blackhole of internal stuff adds more work for us internally (read: which we're not going to do) and wouldn't provide results feedback to the upstream CPython project in a useful timely manner. We must figure out how to get this to build and run on the external oss-fuzz infrastructure """ -- ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: > i'd rather make this work in oss-fuzz on cpython. can you point me to how > oss-fuzz works and what it wants to do so i can better understand what it > needs? I don't have any details except for what's in the PR to oss-fuzz (https://github.com/google/oss-fuzz/pull/731) My understanding is matches what you've said so far: Python is built to one directory (/out/), but then needs to be run from another directory (/out/ is renamed to /foo/bar/baz/out/). We need python to still work. I have no idea how to do this. The only suggestion on #python-dev IRC was to statically link a libpython.a, but this doesn't avoid needing to import libraries like "encodings" dynamically, so they still need to be locatable on disk. Is there a way to build python so that it doesn't use absolute paths to everything, and so that the install can be moved at will? Or is there a way to tell it that it was moved at runtime? (I am unconvinced PYTHONPATH is a maintainable solution, if it works at all...) oss-fuzz is not going to change away from its model (I asked if they could, they said no), so we're stuck with making Python compatible with it one way or another. This is why I am so drawn to running the test internally on Google's infrastructure anyway: we already _did_ all this work already, via hermetic python. Doing it a second time, but worse, seems annoying. -- ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: So here's an interesting issue: oss-fuzz requires that the built location be movable. IOW, we build Python into $OUT, and then the $OUT directory gets moved somewhere else and the fuzz test gets run from there. This causes problems because Python can no longer find where the modules it needs are (encodings for example). First thought: wouldn't it be nice if we could make a prepackaged and hermetic executable that we can move around freely? Second thought: isn't that "Hermetic Python", as used within Google? Third thought: doesn't Google have an internal fuzz testing environment we can use, instead of oss-fuzz? So unless someone says this is a bad idea, I'd propose we not run these in oss-fuzz and instead run them in Google proper. The alternative is if there's a way to make it easy to move Python around -- is there a way to build it s.t. the import path is relative and so on? -- ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Changes by Devin Jeanpierre : -- keywords: +patch pull_requests: +3434 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Changes by Devin Jeanpierre : -- pull_requests: +3412 ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: Huh. I would not have predicted that. https://gcc.gnu.org/onlinedocs/cpp/Defined.html I'll send a fix. -- ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: I think they misspoke, it's normal with fuzzing to test against master. The current draft of the code runs this git pull before building/launching any tests: git clone --depth 1 https://github.com/python/cpython.git cpython Speaking of which, I forgot to update this bug thread with the followup PR to actually run CPython's fuzz tests (when they exist): https://github.com/google/oss-fuzz/pull/731. That's where I grabbed the git clone statement from. I think that will be merged after some version of PR 2878 lands in CPython (still in code review / broken). For Python 2 I guess it's different, and we will test against the 2.7 branch, right? -- ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Changes by Devin Jeanpierre : -- pull_requests: +2929 ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function
Devin Jeanpierre added the comment: Oh, to be clear on this last point: > Hum, who else needs such function except of you? Right now there is no way to convert an int that might be > 64 bits, into a python long, except really bizarre shenanigans, unless we want to rely on implementation-defined behavior. This would be fine if it were easy to implement, but it isn't -- as we've both agreed, there's no good way to do this, and it is significantly easier to add this to CPython than to implement this from outside of CPython. And I do think there is merit in writing code that doesn't rely on implementation-defined behavior. I also think it's simpler -- imagine if we just didn't care about all these int types! Phew. Ack that this isn't "strong rationale" per your standards, so do whatever is right for this bug. -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function
Devin Jeanpierre added the comment: > Making two C functions public is very different from supporting intmax_t. I > expect a change of a few lines, whereas my intmax_t patch modified a lot of > code. I requested either a way to create from intmax_t, or from bytes. We have two existing functions (that I didn't know about) to do the latter, so it would fix this bug report to just make those public, from my POV. -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function
Devin Jeanpierre added the comment: > Devin, I asked you for a strong rationale to add the feature. I don't see > such rationale, so this issue will be closed again. I guess we have different definitions of "strong rationale". Clearer criteria would help. >> It may be better to make _PyLong_FromByteArray() and _PyLong_AsByteArray() >> public. > That makes sense. I suggest to open a new issue for that. This request was part of the original bug report, so why open a new issue? > PyLong_FromIntMax_t(myinteger) would be great. Or maybe even better would be > PyLong_FromBytes(&myinteger, sizeof(myinteger)) ? -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function
Devin Jeanpierre added the comment: > Write your own C extension to do that. Sorry, I don't know what is the best > way to write such C extension. If everyone who wants to convert intptr_t to a python int has to write their own function, then why not just include it in the C-API? Having support for intmax_t means we never have to have this conversation ever again, because it should work for all int types. Reopening since this use-case doesn't sound solved yet. -- resolution: rejected -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function
Devin Jeanpierre added the comment: > I wrote my first patch in 2013, but I still fail to find a very good example > where intmax_t would be an obvious choice. So I have to agree and I will now > close the issue. Hold on, nobody ever answered the question in the OP. How would you convert an intptr_t (e.g. Rust's int type) to a Python int? You can't use FromVoidPtr because of signedness. You can use FromLongLong, but that's implementation-defined. If what we should be using is FromLongLong for all "really big ints", why not just rename FromLongLong to FromIntMax and call it a day? There is no standard relationship between long long and most other int types -- all we know is that it's at least 64 bits, but an int type can perfectly reasonably be e.g. 80 bits or 128 bits or similar. I think it *is* a worhtwhile goal to allow programmers to write C code that has as little implementation-defined or undefined behavior as possible. If that isn't considered a worthwhile goal, maybe we should reconsider using such a dangerous and pointy language as C. :) -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: https://github.com/google/oss-fuzz/pull/583 is the PR to oss-fuzz to add the project. I'm working on actual tests to be submitted here. -- ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Devin Jeanpierre added the comment: Aha, I found an existing issue! For adding to oss-fuzz, is there a contact email we can use that is connected to a google account? I am tempted to just put gregory.p.smith on there if not. :) I can volunteer to fuzz some interesting subset of the stdlib. The list I've come up with (by counting uses in my code) is: the XML parser (which seems to be written in C) struct (unpack) the various builtins that parse strings (like int()) hashlib binascii datetime's parsing json I'd also suggest the ast module, since people do use ast.literal_eval on untrusted strings, but I probably won't do that one myself. I wrote a fuzz test for json via upstream simplejson, but the bug on github is getting stale: https://github.com/simplejson/simplejson/issues/163 Should I add it to CPython instead? > We should investigate creating fuzz targets for the Python re module (_sre.c) > at a minimum. If we prioritize based on security risk, I'd argue that this is lower priority than things like json's speedup extension module, because people should generally not pass untrusted strings to the re module: it's very easy to DOS a service with regexes unless you're using RE2 or similar -- which is fuzzed. In contrast, json is supposed to accept untrusted input and people do that very often. (OTOH, I would be willing to bet that fuzzing re will yield more bugs than fuzzing json.) -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29986] Documentation recommends raising TypeError from tp_richcompare
Devin Jeanpierre added the comment:
Yeah, I agree there might be a use-case (can't find one offhand, but in
principle), but I think it's rare enough that you're more likely to be led
astray from reading this note -- almost always, NotImplemented does what you
want.
In a way this is a special case of being able to raise an exception at all,
which is mentioned earlier ("if another error occurred it must return NULL and
set an exception condition.")
--
___
Python tracker
<http://bugs.python.org/issue29986>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29986] Documentation recommends raising TypeError from tp_richcompare
Devin Jeanpierre added the comment: Sorry, forgot to link to docs because I was copy-pasting from the PR: https://docs.python.org/2/c-api/typeobj.html#c.PyTypeObject.tp_richcompare https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_richcompare > Note: If you want to implement a type for which only a limited set of > comparisons makes sense (e.g. == and !=, but not < and friends), directly > raise TypeError in the rich comparison function. -- ___ Python tracker <http://bugs.python.org/issue29986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29986] Documentation recommends raising TypeError from tp_richcompare
New submission from Devin Jeanpierre: am not sure when TypeError is the right choice. Definitely, most of the time I've seen it done, it causes trouble, and NotImplemented usually does something better. For example, see the work in https://bugs.python.org/issue8743 to get set to interoperate correctly with other set-like classes --- a problem caused by the use of TypeError instead of returning NotImplemented (e.g. https://hg.python.org/cpython/rev/3615cdb3b86d). This advice seems to conflict with the usual and expected behavior of objects from Python: e.g. object().__lt__(1) returns NotImplemented rather than raising TypeError, despite < not "making sense" for object. Similarly for file objects and other uncomparable classes. Even complex numbers only return NotImplemented! >>> 1j.__lt__(1j) NotImplemented If this note should be kept, this section could use a decent explanation of the difference between "undefined" (should return NotImplemented) and "nonsensical" (should apparently raise TypeError). Perhaps a reference to an example from the stdlib. -- assignee: docs@python components: Documentation messages: 291144 nosy: Devin Jeanpierre, docs@python priority: normal pull_requests: 1167 severity: normal status: open title: Documentation recommends raising TypeError from tp_richcompare ___ Python tracker <http://bugs.python.org/issue29986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15138] base64.urlsafe_b64**code are too slow
Devin Jeanpierre added the comment: Here's a backport of the patch to 2.7. It's pretty rad, and basically identical to how YouTube monkeypatches base64. Not sure what will happen to this patch. According to recent discussion on the list (e.g. https://mail.python.org/pipermail/python-dev/2015-May/140380.html ), performance improvements are open for inclusion in 2.7 if anyone wants to bother with merging this in and taking on the review / maintenance burden. I'm OK with just publishing it for others to merge in with their own private versions of Python. It is only relevant if you use base64 a lot. :) ------ nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file39568/base64_27.diff ___ Python tracker <http://bugs.python.org/issue15138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17094] sys._current_frames() reports too many/wrong stack frames
Devin Jeanpierre added the comment: The patch I'm providing with this comment has a ... really hokey test case, and a two line + whitespace diff for pystate.c . The objective of the patch is only to have _current_frames report the correct frame for any live thread. It continues to report dead threads' frames, up until they would conflict with a live thread. IMO it's the minimal possible fix for this aspect of the bug, and suitable for 2.7.x. Let me know what you think. -- Added file: http://bugs.python.org/file39564/_current_frames_27_setdefault.diff ___ Python tracker <http://bugs.python.org/issue17094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17094] sys._current_frames() reports too many/wrong stack frames
Devin Jeanpierre added the comment: This bug also affects 2.7. The main problem I'm dealing with is "sys._current_frames will then return wrong stack frames for existing threads". One fix to just this would be to change how the dict is created, to keep newer threads rather than tossing them. Alternatively, we could backport the 3.4 fix. Thoughts? ------ nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue17094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Devin Jeanpierre added the comment: [a, b] = (1, 2) is also fine. -- ___ Python tracker <http://bugs.python.org/issue23275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24283] Print not safe in signal handlers
Devin Jeanpierre added the comment: It doesn't do any of those things in Python 2, to my knowledge. Why aren't we willing to make this work? -- ___ Python tracker <http://bugs.python.org/issue24283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24283] Print not safe in signal handlers
New submission from Devin Jeanpierre:
The code attached runs a while loop that prints, and has a signal handler that
also prints. There is a thread that constantly fires off signals, but this is
just to ensure the condition for the bug happens -- this is a bug with signal
handling, not threads -- I can trigger a RuntimeError (... with a missing
message?) by commenting out the threading lines and instead running a separate
process "while true; do kill -s SIGUSR1 4687; done".
Traceback:
$ python3 threading_print_test.py
hello
world
Traceback (most recent call last):
File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line
36, in
main()
File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line
30, in main
print("world")
File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line
13, in print_hello
print("hello")
RuntimeError: reentrant call inside <_io.BufferedWriter name=''>
--
files: threading_print_test.py
messages: 244020
nosy: Devin Jeanpierre, haypo
priority: normal
severity: normal
status: open
title: Print not safe in signal handlers
Added file: http://bugs.python.org/file39491/threading_print_test.py
___
Python tracker
<http://bugs.python.org/issue24283>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5315] signal handler never gets called
Devin Jeanpierre added the comment: Adding haypo since apparently he's been touching signals stuff a lot lately, maybe has some useful thoughts / review? :) -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue5315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5315] signal handler never gets called
Devin Jeanpierre added the comment: Agree with Charles-François's second explanation. This makes it very hard to reliably handle signals -- basically everyone has to remember to use set_wakeup_fd, and most people don't. For example, gunicorn is likely vulnerable to this because it doesn't use set_wakeup_fd. I suspect most code using select + signals is wrong. I've attached a patch which fixes the issue for select(), but not any other functions. If it's considered a good patch, I can work on the rest of the functions in the select module. (Also, tests for the details of the behavior.) Also the patch is pretty hokey, so I'd appreciate feedback if it's going to go in. :) -- keywords: +patch nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file39489/select_select.diff ___ Python tracker <http://bugs.python.org/issue5315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24235] ABCs don't fail metaclass instantiation
New submission from Devin Jeanpierre:
If a subclass has abstract methods, it fails to instantiate... unless it's a
metaclass, and then it succeeds.
>>> import abc
>>> class A(metaclass=abc.ABCMeta):
... @abc.abstractmethod
... def foo(self): pass
...
>>> class B(A): pass
...
>>> B()
Traceback (most recent call last):
File "", line 1, in
TypeError: Can't instantiate abstract class B with abstract methods foo
>>> class C(A, type): pass
...
>>> class c(metaclass=C): pass
...
>>> C('', (), {})
>>>
--
components: Library (Lib)
messages: 243540
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: ABCs don't fail metaclass instantiation
versions: Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/issue24235>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24144] Docs discourage use of binascii.unhexlify etc.
New submission from Devin Jeanpierre: Maybe the functions should be split up into those you shouldn't need to call directly, and those you should? I find it unlikely that you're supposed to use codecs.encode(..., 'hex') and codecs.decode(..., 'hex') instead of binascii (the only other thing, AFAIK, that works in both 2 and 3). Relevant quote starts with: "Normally, you will not use these functions directly" https://docs.python.org/2/library/binascii https://docs.python.org/3/library/binascii -- assignee: docs@python components: Documentation messages: 242737 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: Docs discourage use of binascii.unhexlify etc. versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23322] parser module docs missing second example
New submission from Devin Jeanpierre: The port to reST missed the second example: https://docs.python.org/release/2.5/lib/node867.html This is still referred to in the docs, so it is not deliberate. For example, the token module docs say "The second example for the parser module shows how to use the symbol module": https://docs.python.org/3.5/library/token.html#module-token There is no second example, nor any use of the symbol module, in the docs: https://docs.python.org/3.5/library/parser.html -- assignee: docs@python components: Documentation messages: 234716 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: parser module docs missing second example versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
New submission from Devin Jeanpierre: >>> [] = () >>> () = [] File "", line 1 SyntaxError: can't assign to () This contradicts the assignment grammar, which would make both illegal: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements -- components: Interpreter Core messages: 234324 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Can assign [] = (), but not () = [] type: behavior ___ Python tracker <http://bugs.python.org/issue23275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: I inferred from Serhiy's comment that if you override __iter__ to be efficient and not use __getitem__, this overridden behavior used to pass on to index(), but wouldn't after this patch. -- ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0
Devin Jeanpierre added the comment: Does the spec have a handy list of differences to floats anywhere, or do you have to internalize the whole thing? -- ___ Python tracker <http://bugs.python.org/issue23201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: I take it back, I don't want to copy what the list type does, because it's wrong: http://bugs.python.org/issue23204 -- ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23204] list.index and rest of list methods disagree if a value is in the list if it's mutated during the call
New submission from Devin Jeanpierre: >>> class AppendOnUnequal(object): ... def __init__(self, append_to): ... self.append_to = append_to ... def __eq__(self, other): ... if self is other: ... return True ... self.append_to.append(self) ... return False ... >>> L = [1]; AppendOnUnequal(L) in L True >>> L = [1]; L.count(AppendOnUnequal(L)) 1 >>> L = [1]; L.remove(AppendOnUnequal(L)) >>> L = [1]; L.index(AppendOnUnequal(L)) Traceback (most recent call last): File "", line 1, in ValueError: <__main__.AppendOnUnequal object at 0x7f2562d071d0> is not in list .index() is the only odd one out here. Looks like a bug to me. ------ components: Interpreter Core messages: 233721 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: list.index and rest of list methods disagree if a value is in the list if it's mutated during the call type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0
Devin Jeanpierre added the comment:
Yes, also, it is documented:
https://docs.python.org/3/library/decimal.html#decimal.InvalidOperation
Still, the status quo is bad. At the very least there should be clear
documentation on how Decimal differs in behavior from floats and ints. (Other
than the obvious, like 1/5 taking on a different value -- although explicitly
mentioning that in the list might be a good idea.)
BTW, 0**0=1 is not mathematically impure. It at one point was fairly well
accepted as the right answer, since it's the one that tends to come out
naturally . e.g. http://arxiv.org/abs/math/9205211 page 6 ("ripples") . This
might explain why ints and floats so casually evaluate 0**0 to 1.
--
___
Python tracker
<http://bugs.python.org/issue23201>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0
Changes by Devin Jeanpierre : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue23201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0
New submission from Devin Jeanpierre: >>> import decimal >>> x = 0 >>> y = float(x) >>> z = decimal.Decimal(x) >>> x == y == z == x True >>> x ** x 1 >>> y**y 1.0 >>> z**z Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/decimal.py", line 2216, in __pow__ return context._raise_error(InvalidOperation, '0 ** 0') File "/usr/lib/python2.7/decimal.py", line 3872, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 ** 0 This is PHP-like and confusing, and maybe not justified just by standards compliance. If it is justified by standards compliance, this deserves to be spelled out in big red letters in the documentation for the decimal module, along with any other inconsistencies. -- components: Library (Lib) messages: 233711 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: I'm going to add a test case that changes the sequence length during .index(), and just do whatever list does in that case. -- ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: Are you sure? I noticed that __iter__ went out of its way to avoid calling len(). -- ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: Why is there no "review" link next to my second patch? -- ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: I modified your test case somewhat. Also, your tests uncovered an issue with negative indexes -- oops, hadn't thought of those. Fixed. Let me know what you think. -- Added file: http://bugs.python.org/file37631/issue23086.2.patch ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method
Devin Jeanpierre added the comment: A wild patch appears! Test is included, I'm unhappy with it, because it uses one test method to test all of Sequence, but that's what the test suite does for MutableSequence. -- keywords: +patch nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file37607/issue23086.patch ___ Python tracker <http://bugs.python.org/issue23086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23162] collections.abc sequences don't check identity before equality
Devin Jeanpierre added the comment: I think that such a thing is meaningless, as I don't own copyright to the patches, my employer (Google) does. But, it can't hurt, so, done. -- ___ Python tracker <http://bugs.python.org/issue23162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23162] collections.abc sequences don't check identity before equality
Devin Jeanpierre added the comment: Since both patches will clobber each other (same test method), complicating the review process, I've written the patch for issue23086 first. It's currently waiting on committee review from my employer. Will upload to other issue, and once it's submitted or rejected, I'll add a test patch to this issue too. -- ___ Python tracker <http://bugs.python.org/issue23162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23162] collections.abc sequences don't check identity before equality
Devin Jeanpierre added the comment: Thanks for the patch! I was secretly hoping to write it though. :P Not sure how the code review tool works. The patch looks good to me, except it needs tests IMO. I can write them if you think this is not worth the effort. -- ___ Python tracker <http://bugs.python.org/issue23162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23161] collections.abc.MutableSet missing methods
Devin Jeanpierre added the comment: copy() should not be implemented magically, no. I understand the argument in favor of not implementing redundant methods, but if the redundancy was this big a concern, they should not have been added to sets in the first place. The current ABCs are inconsistent and confusing. For example: MutableSequence implements += and .extend, but on MutableSet, the analogous methods |= and .update are only half there. (Moreover, it's the wrong half, in my experience.) Plus not all of the named methods have operator equivalents, so e.g. is_subset is not supported, but is_disjoint is. This also means every subclass, in order to actually implement the set API, needs to write this code itself. It is very common to call the named methods, especially ones like update, and compatibility with set is desirable -- otherwise, we wouldn't bother inheriting from the relevant ABC. -- ___ Python tracker <http://bugs.python.org/issue23161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23162] collections.abc sequences don't check identity before equality
Devin Jeanpierre added the comment: See Raymond Hettinger's comments in http://bugs.python.org/issue4296 for details on why the usual sequence behavior is deliberate. -- ___ Python tracker <http://bugs.python.org/issue23162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23162] collections.abc sequences don't check identity before equality
New submission from Devin Jeanpierre: For sequence __contains__ and other scenarios, identity is checked before equality, which I've heard is so that "for x in y: assert x in y" doesn't ever fail with an AssertionError (even with NaN and so on). This is not the case for collections.abc-based sequences, which is a jarring inconsistency. -- components: Library (Lib) messages: 233399 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: collections.abc sequences don't check identity before equality versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue23162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23161] collections.abc.MutableSet missing methods
Changes by Devin Jeanpierre : -- components: +Library (Lib) ___ Python tracker <http://bugs.python.org/issue23161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23161] collections.abc.MutableSet missing methods
New submission from Devin Jeanpierre:
>>> set(dir(set)) - set(dir(collections.abc.MutableSet))
{'copy', 'update', '__rsub__', 'union', 'issubset', 'intersection',
'issuperset', '__rxor__', 'difference', 'symmetric_difference',
'difference_update', '__rand__', 'intersection_update',
'symmetric_difference_update', '__ror__'}
Most of these should be implemented on MutableSet rather than subclasses.
--
messages: 233398
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: collections.abc.MutableSet missing methods
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue23161>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22785] range docstring is less useful than in python 2
Changes by Devin Jeanpierre : -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue22785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown
Devin Jeanpierre added the comment: Please don't take my word for it, but my understanding is that this issue doesn't apply to 3.4+ since module globals are no longer set to None during interpreter shutdown. (So all the checks against None could even be deleted.) -- ___ Python tracker <http://bugs.python.org/issue21149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown
Devin Jeanpierre added the comment: Are you sure? There should have been many previous contributions by Google, so the relevant copyright agreements _should_ have already been signed. I asked internally and was told that a corporate version of this agreement had been signed a long time ago. -- ___ Python tracker <http://bugs.python.org/issue21149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown
New submission from Devin Jeanpierre: If another thread is active during interpreter shutdown, it can hold the last reference to a handler; when it drops that reference, the weakref callback -- _removeHandlerRef -- will be executed in this other thread. So while this callback is running, the main thread is replacing module globals with None. This creates a data race for the globals in logging -- for example, _releaseLock can be replaced with None after the "_releaseLock is not None" check, but before it is used. In principle I suspect this could cause a deadlock, in practice all I've seen are exception messages mentioning how None is not callable. I have attached a patch that I think resolves this issue. The patch is written against 2.7, although I expect this issue affects all versions of Python prior to 3.4 BTW, the copyright for this patch belongs to my employer, Google; please let me know if there are any contributor agreements or such that my employer needs to look at. -- components: Library (Lib) files: patch.diff keywords: patch messages: 215466 nosy: Devin Jeanpierre, gregory.p.smith priority: normal severity: normal status: open title: logging._removeHandlerRef is not threadsafe during interpreter shutdown versions: Python 2.7 Added file: http://bugs.python.org/file34718/patch.diff ___ Python tracker <http://bugs.python.org/issue21149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20722] newline is (partially) independent of universal newlines; needs to be made more clear in docs
New submission from Devin Jeanpierre: http://docs.python.org/3.4/library/functions.html#open says "newline controls how universal newlines mode works (it only applies to text mode)." My reading of this when I saw it was that newline= doesn't do anything unless universal newlines mode is enabled. This is untrue, and you can infer it's untrue from the following lines, but then the docs appear to contradict themselves. Please fix to say something more along the lines of "newline controls how newlines are read and written. It only applies to text mode." The interactions with universal newlines mode are explained in the following text, so they don't need to be called out upfront. newline does more than just that. -- assignee: docs@python components: Documentation messages: 211854 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: newline is (partially) independent of universal newlines; needs to be made more clear in docs versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue20722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19411] binascii.hexlify docs say it returns a string (it returns bytes)
New submission from Devin Jeanpierre: http://docs.python.org/3.4/library/binascii.html#binascii.hexlify -- assignee: docs@python components: Documentation messages: 201376 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: binascii.hexlify docs say it returns a string (it returns bytes) versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue19411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17884] Try to reuse stdint.h types like int32_t
Devin Jeanpierre added the comment:
I don't know what context these types are being used in, but would
int_least64_t suffice? C99 does require the existence of the [u]int_leastN_t
types (for N in {8,16,32,64}), unlike [u]intN_t.
--
___
Python tracker
<http://bugs.python.org/issue17884>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide a PyLong_FromIntptr_t() function
Devin Jeanpierre added the comment: Isn't it possible for a >64-bit architecture to have intptr_t be wider than long long? As for my use-case, I am wrapping the C-API for Rust. Rust can call and be called by C (and therefore Python), but a Rust "int" is a C "intptr_t", and a Rust "uint" is a C "uintptr_t". -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Python does not provide a PyLong_FromIntptr_t() function
Devin Jeanpierre added the comment: With regards to the title change, I would prefer a FromIntMax_t (and FromUintMax_t) to a FromIntPtr_t. The former covers every use case of the latter, and more. -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Hard to create python longs from arbitrary C integers
Devin Jeanpierre added the comment: PyLong_FromVoidPtr works for uintptr_t, but not intptr_t. -- ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17870] Hard to create python longs from arbitrary C integers
New submission from Devin Jeanpierre: As far as I can tell, the only safe and correct way to convert a (for example) intptr_t to a python long is something akin to the following: size_t repsize = sizeof(intmax_t)*8 + 2; char i_buf[repsize]; // enough to fit base 2 with sign, let alone base 1 snprintf(i_buf, repsize, "%ij", (intmax_t) myinteger); return PyLong_FromString(i_buf, NULL, 10); Does this not seem absurd? PyLong_FromIntMax_t(myinteger) would be great. Or maybe even better would be PyLong_FromBytes(&myinteger, sizeof(myinteger)) ? This is problematic because many things that can interact with the Python C-API do not use the C types like "long long" or "int". Instead they might use the equivalents of intptr_t and int32_t, which are more reliably sized. -- messages: 188103 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Hard to create python longs from arbitrary C integers versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue17870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17473] -m is not universally applicable
New submission from Devin Jeanpierre: Many executables in python are meant to be run on python scripts, but can't run python scripts that are part of a package. For example, one can do `python -m pdb foo.py`, but not `python -m pdb package.foo`. This makes it more difficult to interact with executable scripts within a package. In particular, the following will NOT work in general: `python -m pdb package/foo.py` It would be easier if these modules gained their own `-m` argument to specify import paths instead of files. For example, the third party coverage module does this, and can be run using the command `python -m coverage run -m package.foo`. What follows is a small list of scripts present as modules in the Python stdlib that involve manipulating other scripts, and so could benefit from a -m option. pdb profile doctest trace modulefinder tabnanny pyclbr dis In the case of pydoc, unittest (unittest discover, etc.) -- these are special cases, as they interpret input as either a path OR a module via guessing. There may not be any benefit to adding a -m option. -- messages: 184564 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: -m is not universally applicable type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1677] Ctrl-C will exit out of Python interpreter in Windows
Devin Jeanpierre added the comment: For extra clarification, this issue can crop up with even a single press of ctrl-c. It's not really related to multiple presses, except that pressing it more increases the odds of it happening. -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue1677> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12947] doctest directive examples in library/doctest.html lack the flags
Changes by Devin Jeanpierre : -- title: Examples in library/doctest.html lack the flags -> doctest directive examples in library/doctest.html lack the flags ___ Python tracker <http://bugs.python.org/issue12947> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14865] #doctest: directives removed from doctest chapter examples
Devin Jeanpierre added the comment: This is a duplicate of http://bugs.python.org/issue12947 -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue14865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13998] Lookbehind assertions go behind the start position for the match
Devin Jeanpierre added the comment: If it's intended behaviour, then I'd request that the documentation specifically mention lookbehind assertions the way it does with "^". Saying "it's slightly different" doesn't make clear the ways in which it is different, and that's important for people writing or using regular expressions. -- ___ Python tracker <http://bugs.python.org/issue13998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13998] Lookbehind assertions go behind the start position for the match
New submission from Devin Jeanpierre :
compiled regex objects' match method offers an optional "pos" parameter
described to be roughly equivalent to slicing except for how it treats the "^"
operation. See http://docs.python.org/library/re.html#re.RegexObject.search
However, the behavior of lookbehind assertions also differs:
>>> re.compile("(?<=a)b").match("ab", 1)
<_sre.SRE_Match object at 0x...>
>>> re.compile("(?<=a)b").match("ab"[1:])
>>>
This alone might be a documentation bug, but the behavior is also inconsistent
with the behavior of lookahead assertions, which do *not* look past the endpos:
>>> re.compile("a(?=b)").match("ab", 0, 1)
>>> re.compile("a(?=b)").match("ab")
<_sre.SRE_Match object at 0x...>
>>>
--
components: Regular Expressions
messages: 153188
nosy: Devin Jeanpierre, ezio.melotti
priority: normal
severity: normal
status: open
title: Lookbehind assertions go behind the start position for the match
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13998>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Devin Jeanpierre added the comment: It'd be nice if we had some sort of representative benchmark for real-world uses of Python regexps. The JS guys have all pitched in to create such a thing for uses of regexps on thew web. I don't know of any such thing for Python. I agree that a Python implementation wouldn't be useful for some cases. On the other hand, I believe it would be fine (or at least tolerable) for some others. I don't know the ratio between the two. -- ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Devin Jeanpierre added the comment: > In practice, I expect that a pure Python implementation of a regular > expression engine would only be fast enough to be usable on PyPy. Not sure why this is necessarily true. I'd expect a pure-Python implementation to be maybe 200 times as slow. Many queries (those on relatively short strings that backtrack little) finish within microseconds. On this scale, a couple of orders of magnitudes is not noticeable by humans (unless it adds up), and even where it gets noticeable, it's better than having nothing at all or a non-working program (up until a point). python -m timeit -n 100 -s "import re; x = re.compile(r'.*<\s*help\s*>([^<]*)<\s*/\s*help.*>'); data = ' '*1000 + '< help >' + 'abc'*100 + ''" "x.match(data)" 100 loops, best of 3: 3.27 usec per loop -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13691] pydoc help (or help('help')) claims to run a help utility; does nothing
Devin Jeanpierre added the comment:
> IMO, help('help') should document the help function, not start an interactive
> help session (that’d be help()).
Ahhh, that explains it. help('help') isn't ever meant to be called; it's
supposed to be:
>>> help()
...
help> help
...
the call to "help" at the help> prompt is equivalent to help('help').
help('help') should do something different, such as say how to use the help
function, as you say. Whereas "help> help" makes sense.
--
___
Python tracker
<http://bugs.python.org/issue13691>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13691] pydoc help (or help('help')) claims to run a help utility; does nothing
New submission from Devin Jeanpierre :
What follows is a copy-paste of a shell session. Notice that at the end, rather
than being inside the online help utility, I'm still in the interactive
interpreter. I was able to duplicate this on python3.2, python2.7, and
python2.6 (verifying it on other versions would have required installing them).
Reading the source in trunk, there is nothing that looks like it actually
should run this interactive help session. It's just missing.
I guess nobody used this, eh? I've attached a patch that should fix it. I'm not
sure how you want to handle adding a test for this, so please advise me on that.
-
>>> help('help')
Welcome to Python 3.2! This is the online help utility.
If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.
Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules. To quit this help utility and
return to the interpreter, just type "quit".
To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics". Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".
>>>
------
components: Library (Lib)
files: r74214.diff
keywords: patch
messages: 150427
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: pydoc help (or help('help')) claims to run a help utility; does nothing
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file24121/r74214.diff
___
Python tracker
<http://bugs.python.org/issue13691>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Devin Jeanpierre added the comment: > Amaury did not suggest to use openat, but the new opener argument to open, > which was especially added for use cases such as the one discussed here: Sorry, yes. Wrong words, same thought. We can implement this using opener, but we could implement this with os.open before. What's changed, except that there's more ways to do it? (There is slightly more versatility with the opener method, but no more obviousness and no less typing). My understanding from reading the other thread is that this is not the primary use-case of the new parameter for open(). In fact, this ticket was not really mentioned at all there. -- ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Devin Jeanpierre added the comment: C11 uses 'x' for this, for what it's worth. This is not a "duplicate issue". The openat solution is no easier than the os.open solution. -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12705] Make compile('1\n2\n', '', 'single') raise an exception instead of silently truncating?
New submission from Devin Jeanpierre :
(this is copy-pasted from
http://mail.python.org/pipermail/python-ideas/2011-July/010787.html )
compile('1\n2\n', '','single') == compile('1\n', '','single').
That is, it ignores the second statement ('2\n'),
without offering a way for the caller to detect this.
Considering that 'single' is primarily used to emulate the behaviour
of the Python interpreter, most of the time, giving it multiple
statements is an impossibility, and so that case doesn't matter and
could raise an exception without affecting existing code. For example,
the code module meets this description, as do debuggers and such.
However, in cases where it _is_ possible to give the compiler multiple
statements, the user should be warned that his input isn't valid,
somehow. For example, the following doctest will mysteriously fail,
because it was written incorrectly (doctest uses 'single'):
>>> import sys
... sys.stdout.write('foo\n')
foo
This is because the second statement in the doctest was silently
discarded by compile(). It might not always be clear to users how to
fix this, and I think this kind of non-obvious error would exist in
any use of 'single' that can in theory involve multiple statements,
through user error or program bug. So I'd appreciate it if compile()
raised an exception in this case. Perhaps SyntaxError or ValueError.
--
components: Interpreter Core
messages: 141735
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Make compile('1\n2\n', '', 'single') raise an exception instead of
silently truncating?
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue12705>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12486] tokenize module should have a unicode API
New submission from Devin Jeanpierre :
tokenize only deals with bytes. Users might want to deal with unicode source
(for example, if python source is embedded into a document with an
already-known encoding).
The naive approach might be something like:
def my_readline():
return my_oldreadline().encode('utf-8')
But this doesn't work for python source that declares its encoding, which might
be something other than utf-8. The only safe ways are to either manually add a
coding line yourself (there are lots of ways, I picked a dumb one):
def my_readline_safe(was_read=[]):
if not was_read:
was_read.append(True)can
return b'# coding: utf-8'
return my_oldreadline().encode('utf-8')
tokenstream = tokenize.tokenize(my_readline_safe)
Or to use the same my_readline as before (no added coding line), but instead of
passing it to tokenize.tokenize, you could pass it to the undocumented
_tokenize function:
tokenstream = tokenize._tokenize(my_readline, 'utf-8')
Or, ideally, you'd just pass the original readline that produces unicode into a
utokenize function:
tokenstream = tokenize.utokenize(my_oldreadline)
--
components: Library (Lib)
messages: 139733
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module should have a unicode API
___
Python tracker
<http://bugs.python.org/issue12486>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11909] Doctest sees directives in strings when it should only see them in comments
Devin Jeanpierre added the comment: Updated. -- Added file: http://bugs.python.org/file22562/comments3.diff ___ Python tracker <http://bugs.python.org/issue11909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11909] Doctest sees directives in strings when it should only see them in comments
Devin Jeanpierre added the comment: Erp I forgot to run this against the rest of the tests. Disregard, I'll fix it up a bit later. -- ___ Python tracker <http://bugs.python.org/issue11909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11909] Doctest sees directives in strings when it should only see them in comments
Devin Jeanpierre added the comment: Updated patch to newest revision, and to use _tokenize function and includes a test case to verify that it ignores the encoding directive during the tokenization (and every other) step. I'll file a tokenize bug separately. -- Added file: http://bugs.python.org/file22559/comments.diff ___ Python tracker <http://bugs.python.org/issue11909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12475] Generator bug allows you to chain arbitrary tracebacks to the next raised exception
Changes by Devin Jeanpierre : Removed file: http://bugs.python.org/file22550/exception_chaining.py ___ Python tracker <http://bugs.python.org/issue12475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12475] Generator bug allows you to chain arbitrary tracebacks to the next raised exception
New submission from Devin Jeanpierre : It's probably best shown by example: http://ideone.com/4YkqV Have fun! This one looks hard. Some notes: Exchanging g2() for iter([1]) makes this go away. Wrapping g2 inside a non-generator iterator does not make this go away. Removing the call to next(it) after it = g2() makes the problem go away, as does replacing those two lines with next(g2()). The file used in that ideone paste is attached for your convenience. --- Debugging is impractical for me with this bug in existence. It never stopped printing the traceback before I killed the process. (And let's forget about debug prints!) -- components: Interpreter Core files: exception_chaining.py messages: 139670 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Generator bug allows you to chain arbitrary tracebacks to the next raised exception type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file22550/exception_chaining.py ___ Python tracker <http://bugs.python.org/issue12475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11909] Doctest sees directives in strings when it should only see them in comments
Devin Jeanpierre added the comment: You're right, and good catch. If a doctest starts with a "#coding:XXX" line, this should break. One option is to replace the call to tokenize.tokenize with a call to tokenize._tokenize and pass 'utf-8' as a parameter. Downside: that's a private and undocumented API. The alternative is to manually add a coding line that specifies UTF-8, so that any coding line in the doctest would be ignored. My preferred option would be to add the ability to read unicode to the tokenize API, and then use that. I can file a separate ticket if that sounds good, since it's probably useful to others too. One other thing to be worried about -- I'm not sure how doctest would treat tests with leading "coding:XXX" lines. I'd hope it ignores them, if it doesn't then this is more complicated and the above stuff wouldn't work. I'll see if I have the time to play around with this (and add more test cases to the patch, correspondingly) this weekend. -- ___ Python tracker <http://bugs.python.org/issue11909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12063] tokenize module appears to treat unterminated single and double-quoted strings inconsistently
New submission from Devin Jeanpierre :
Tokenizing `' 1 2 3` versus `''' 1 2 3` yields different results.
Tokenizing `' 1 2 3` gives:
1,0-1,1:ERRORTOKEN "'"
1,2-1,3:NUMBER '1'
1,4-1,5:NUMBER '2'
1,6-1,7:NUMBER '3'
2,0-2,0:ENDMARKER ''
while tokenizing `''' 1 2 3` yields:
Traceback (most recent call last):
File "prog.py", line 4, in
tokenize.tokenize(iter(["''' 1 2 3"]).next)
File "/usr/lib/python2.6/tokenize.py", line 169, in tokenize
tokenize_loop(readline, tokeneater)
File "/usr/lib/python2.6/tokenize.py", line 175, in tokenize_loop
for token_info in generate_tokens(readline):
File "/usr/lib/python2.6/tokenize.py", line 296, in generate_tokens
raise TokenError, ("EOF in multi-line string", strstart)
tokenize.TokenError: ('EOF in multi-line string', (1, 0))
Apparently tokenize decides to re-tokenize after the erroneous quote in the
case of a single-quote, but not a triple-quote. I guess that this is because
retokenizing the rest of the file after an unclosed triple-quote would be
expensive; however, I've also been told it's very strange and possibly wrong
for tokenize to be inconsistent this way.
If this is the right behavior, I guess I'd like it if it were documented. This
sort of thing is confusing / potentially misleading for users of the tokenize
module. Or at least, when I saw how single quotes were handled, I assumed
incorrectly that all quotes were handled that way.
--
messages: 135836
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module appears to treat unterminated single and double-quoted
strings inconsistently
___
Python tracker
<http://bugs.python.org/issue12063>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11909] Doctest sees directives in strings when it should only see them in comments
New submission from Devin Jeanpierre : >From the doctest source: 'Option directives are comments starting with "doctest:". Warning: this may give false positives for string-literals that contain the string "#doctest:". Eliminating these false positives would require actually parsing the string; but we limit them by ignoring any line containing "#doctest:" that is *followed* by a quote mark.' This isn't a huge deal, but it's a bit annoying. Above being confusing, this is in contradiction with the doctest documentation, which states: 'Doctest directives are expressed as a special Python comment following an example’s source code' No mention is made of this corner case where the regexp breaks. As per the comment in the source, the patched version parses the source using the tokenize module, and runs a modified directive regex on all comment tokens to find directives. -- components: Library (Lib) files: comments.diff keywords: patch messages: 134278 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Doctest sees directives in strings when it should only see them in comments Added file: http://bugs.python.org/file21757/comments.diff ___ Python tracker <http://bugs.python.org/issue11909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11791] python -m doctest has a -v flag that it ignores
Devin Jeanpierre added the comment: *Sigh*, I'm just confused. Sorry, must have screwed up what I passed as verbose somewhere, so that it didn't check sys.argv. -- resolution: -> invalid status: open -> closed versions: +Python 3.3 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue11791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11791] python -m doctest has a -v flag that it ignores
New submission from Devin Jeanpierre : The usage string details a -v option, but python -m doctest doesn't use a -v option. The attached patch adds that. -- files: doctest_verbosity.diff keywords: patch messages: 133195 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: python -m doctest has a -v flag that it ignores versions: Python 3.2 Added file: http://bugs.python.org/file21559/doctest_verbosity.diff ___ Python tracker <http://bugs.python.org/issue11791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1677] Ctrl-C will exit out of Python interpreter in Windows
Devin Jeanpierre added the comment: Windows 7 64-bit (on the metal, not in a VM), can confirm. Holding down Ctrl+C will (eventually) halt Python on all the versions I have installed: 2.3, 2.7, 3.0, 3.1, 3.2. (All of these are 32-bit Pythons). Haven't done anything silly like try to install readline on Windows. I also tried it on cygwin Python (2.6), held down for maybe 20 seconds, didn't crash. -- nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue1677> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10837] Issue catching KeyboardInterrupt while reading stdin
Devin Jeanpierre added the comment: Sorry, forgot to mention my system. 64-bit Windows 7. -- ___ Python tracker <http://bugs.python.org/issue10837> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10837] Issue catching KeyboardInterrupt while reading stdin
Devin Jeanpierre added the comment: I can confirm this behavior on 2.7. On 3.2 for me it prints "done.", but not "Interrupted!" ------ nosy: +Devin Jeanpierre ___ Python tracker <http://bugs.python.org/issue10837> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
New submission from Devin Jeanpierre : PyObject_RichCoareBool is, according to the documentation in trunk (Doc\c-api\object.rst), exactly the same as PyObject_RichCompare, except it 1, 0, or -1 for error, false, and true respectively. However, it differs in behavior by both that, and also by assuming that identity implies equality. This noted in a two year-old ML post (sadly, no bug report was posted as best as I can find): http://mail.python.org/pipermail/python-list/2009-March/1195170.html Ideally PyObject_RichCompareBool should probably be named something else, since it can no longer be used, strictly, as "PyObject_RichCompare, but returning a C bool" (or, rather, a C int). Some suggestions were offered in the mailing list thread above. I'm filing this as a documentation bug because I find that outcome unlikely. At least the documentation should note the difference in behavior, so that people do not accidentally write C code that does not behave as intended. This issue is related to, but different from issue 4296, which objected to the new container behavior created by the change to PyObject_RichCompareBool. My only objection here is that the latter change does not appear to be documented. I would supply a patch for the tests, but PyObject_RichCompareBool is apparently not directly tested anywhere, just tested obliquely through testing the containment operator, and this was changed by the same commit that changed PyObject_RichCompareBool. I don't know how to word the (very small!) change to the docs. -- assignee: docs@python components: Documentation messages: 126306 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation ___ Python tracker <http://bugs.python.org/issue10912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10771] descriptor protocol documentation has two different definitions of "owner" class
New submission from Devin Jeanpierre : In trunk/Doc/reference/datamodel.rst , under _Implementing Descriptors_, the documentation states: `The following methods only apply when an instance of the class containing the method (a so-called *descriptor* class) appears in the class dictionary of another new-style class, known as the *owner* class. [...]` Immediately below, in the documentation for __get__, it says, `*owner* is always the owner class [...]`. These two uses of "the owner class" are incompatible, because there is only one class which matches the first use: the class where the descriptor was initially assigned to a class attribute; however, for the second use, any descendant class may be called "the owner class". This is demonstrated in the attached doctest file. It is kind of hard to create a better definition for "owner" as used in `__get__`, though. It can't be said to be the class with the descriptor in its class dict, because it can be present in the class dict of some class in the MRO of the owner. It can't be said to be an attribute, because it has to be in a class dict of an ancestor node. It might be possible to change the definition to call the owner class something like, "the class from which the descriptor was invoked", and if that isn't clear enough, provide examples (TypeDescriptor from the attached doctest file might work as an example); however, this would involve reworking the structure of the paragraph substantially. I personally would prefer this option. The paragraph is already badly structured; for example, it defines two terms in a single and rather complex sentence, and should probably be split up into a list of definitions rather than an explanatory jumble paragraph. In addition, this paragraph is the only place in the documentation where this idea of "the owner class" is used in this way. In the descriptions of the descriptor protocol methods below it, "the owner class" always refers to the class from which the attribute was accessed, or the type from which an instance had the attribute accessed. Alternatively, it could be simpler to replace all references below from "the owner class" to "any class with the owner class in the MRO". -- assignee: d...@python components: Documentation files: descriptor.py.doctest messages: 124630 nosy: Devin Jeanpierre, d...@python priority: normal severity: normal status: open title: descriptor protocol documentation has two different definitions of "owner" class versions: Python 2.7 Added file: http://bugs.python.org/file20160/descriptor.py.doctest ___ Python tracker <http://bugs.python.org/issue10771> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5581] abc.abstractproperty() docs list fget as required; fget is not required by abc.abstractproperty()
New submission from Devin Jeanpierre : The documentation uses the function signature `abc.abstractproperty(fget[, fset[, fdel[, doc]]])`, implying that fget is mandatory, and all other arguments are optional. The correct version would be `abc.abstractproperty([fget[, fset[, fdel[, doc)`, or else to change abc.abstractproperty() to require fget (I have not compiled 2.7+ to test if this is the case, I only know that the docs in trunk continue to use this signature). I initially suspected that I misunderstood the signature syntax, but other functions use it as I would assume-- for instance, the Built-In Functions documentation lists `property([fget[, fset[, fdel[, doc)`. -- assignee: georg.brandl components: Documentation messages: 84277 nosy: Devin Jeanpierre, georg.brandl severity: normal status: open title: abc.abstractproperty() docs list fget as required; fget is not required by abc.abstractproperty() versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2867] curses-howto link in curses module documentation gives a 404
New submission from Devin Jeanpierre <[EMAIL PROTECTED]>: In the curses module documentation < http://docs.python.org/lib/module- curses.html >, there is a link to a curses-howto, at < http://www.python.org/doc/howto/curses/curses.html >. That page doesn't exist: it gives an HTTP 404. I am aware that the last time I reported a documentation error it was actually fixed in the unreleased most recent version of the docs. I am not sure where that was meant-- I can't find anything but the 2.6 alpha docs < http://docs.python.org/dev/ >, where the error is indeed corrected (< http://docs.python.org/dev/library/curses.html >, < http://docs.python.org/dev/howto/curses.html >). If was what was meant (I'd always thought that errors would get corrected right away (in the same version), so it doesn't fit with my expectations), then I apologize for making a wasteful report. I figured that it would be better to risk a bit of time wasted than leave an error until later. -- assignee: georg.brandl components: Documentation messages: 66871 nosy: Devin Jeanpierre, georg.brandl severity: normal status: open title: curses-howto link in curses module documentation gives a 404 versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2867> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1702] Word "alias" used in confusing way to compare open() and file()
New submission from Devin Jeanpierre: I was slightly misled by the wording of part of the docs (http://docs.python.org/lib/bltin-file-objects.html): "file() is new in Python 2.2. The older built-in open() is an alias for file()." I actually thought it meant that open was an alias of file, so that 'open is file'. However, >>> open is file False I feel that "alias" is the wrong word to use here, though I don't know a suitable replacement. -- components: Documentation messages: 59007 nosy: Devin Jeanpierre severity: minor status: open title: Word "alias" used in confusing way to compare open() and file() type: rfe __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1702> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
