[issue28240] Enhance the timeit module: display average +- std dev instead of minimum
Changes by Maciej Fijalkowski : -- nosy: -fijall ___ Python tracker <http://bugs.python.org/issue28240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
Maciej Fijalkowski added the comment: On windows the profiler runs in a separate thread and pauses/restarts other threads (hence the requirements are slightly different). HEAD_LOCK etc. are def not async-signal safe, but it's not an issue on linux -- ___ Python tracker <http://bugs.python.org/issue27483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
New submission from Maciej Fijalkowski: Hi The use case here is for C-based statistical profilers. When running vmprof on linux/os x, you can get the current thread state from PyThreadState_GetUnchecked or a similar solution. However, on windows you need to walk all the interpreter state, for which there is an API. However that API is only ever used with locks (HEAD_LOCK/HEAD_UNLOCK), which are not exposed, which turns API mostly useless. -- messages: 270188 nosy: fijall, haypo priority: normal severity: normal status: open title: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c type: enhancement ___ Python tracker <http://bugs.python.org/issue27483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: The easiest way to check is to run the tests attached -- ___ Python tracker <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: Then maybe it's fixed, I have no idea -- ___ Python tracker <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: Apparently you can't have an opinion from ctypes experts. Can you please commit the upstream fix that has been committed 3 years ago or just stop vendoring random, old, broken version of ctypes if you can't maintain it enough to pull fixes from upstream? -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26461] PyInterpreterState_Head(), PyThreadState_Next() etc can't be sanely used
New submission from Maciej Fijalkowski: All the internal uses of this API guard everything with HEAD_LOCK/HEAD_UNLOCK that's not exposed. It's not safe to traverse the whole API without holding those locks and those locks are static and module local -- messages: 261030 nosy: fijall priority: normal severity: normal status: open title: PyInterpreterState_Head(), PyThreadState_Next() etc can't be sanely used ___ Python tracker <http://bugs.python.org/issue26461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26459] Windows build instructions are very inaccurate
New submission from Maciej Fijalkowski: I've tried following the dev guide (still not successful) to compile a debug version of cpython 2.7 and a couple issues that I run into: * The VS2010 vs VS2008 confustion - the docs say "most versions before 3.3 use VS2008" - what does it mean by "most"? The current cpython trunk seems to work only on 2010 (with a variety of fun errors). * VS2010 is hard to download, as is 2008 - direct links would help * nowhere it's mentioned that you need to run stuff from VS console * the readme and the devguide disagree on a few points - readme seems to be better, but also not ideal * the docs don't say how to get svn.exe (that is install tortoiseHG, but then select extra tools from somewhere) * the build seems to require perl, despite claiming it's not Other things are misguiding too, but fixing all of the above would be a massive step forward -- assignee: docs@python components: Documentation messages: 261009 nosy: docs@python, fijall priority: normal severity: normal status: open title: Windows build instructions are very inaccurate versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue26459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25130] Make tests more PyPy compatible
Maciej Fijalkowski added the comment: Hi Looking through your comments, yes, maybe those tests or those things require fixing. We at pypy don't have enough will to fight python-dev most of the time, so the usual approach is to do "minimal hack that works" without trying to dwelve into why this or that works that way. Obviously feel free to fix the underlaying issue, we'll be happy to commit it to pypy -- ___ Python tracker <http://bugs.python.org/issue25130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25106] Hash computation speedup for {buffer, string, unicode}object
Maciej Fijalkowski added the comment: I find numbers really hard to believe. It would mean that over 40% of django templates is string hashing (assuming 2x speedup) which really sounds unbelievable. In fact in PyPy I never found string hashing to be significant while I would expect PyPy to have string hashing more of a bottleneck, since it's almost never optimized away really. What made you think string hashing is a good target for optimizations? -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue25106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25130] Make tests more PyPy compatible
Maciej Fijalkowski added the comment: Hi I can answer precise questions, which tests are you asking about? Note that if the point is to unify the test suite, would be cool to make changes to both pypy and cpython and not just change cpython one. -- ___ Python tracker <http://bugs.python.org/issue25130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19336] No API to get events from epoll without allocating a list
Changes by Maciej Fijalkowski : -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue19336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Maciej Fijalkowski added the comment: It's not "a copy for systems that don't provide libffi", since CPython makes zero effort to try to use system libffi if present. -- ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Maciej Fijalkowski added the comment: The issue is reported upstrem and is/will be fixed -- ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17245] ctypes libffi needs to align the x86 stack to 16 bytes
Maciej Fijalkowski added the comment: This patch is not in the whatever version ubuntu supplies. Btw, this is code duplication, since there is already darwin alignment, see 17423 -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue17245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Changes by Maciej Fijalkowski : -- keywords: +patch Added file: http://bugs.python.org/file29412/ffi.diff ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Changes by Maciej Fijalkowski : Added file: http://bugs.python.org/file29411/x.c ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Changes by Maciej Fijalkowski : Removed file: http://bugs.python.org/file29409/x.c ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
Changes by Maciej Fijalkowski : Added file: http://bugs.python.org/file29410/x.py ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17423] libffi on 32bit is broken on linux
New submission from Maciej Fijalkowski: The bug is a little tricky to reproduce. You need a 32bit linux. First compile x.c with: gcc -O3 -g -shared -o x.so x.c -std=c99 -msse3 -ftree-vectorize -mfpmath=sse and run x.py. It segfaults because the alignment of stack is not preserved (and it's assumed on a modern linux). Patch attached. -- files: x.c messages: 184193 nosy: fijall priority: normal severity: normal status: open title: libffi on 32bit is broken on linux type: crash Added file: http://bugs.python.org/file29409/x.c ___ Python tracker <http://bugs.python.org/issue17423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17232] Improve -O docs
Maciej Fijalkowski added the comment: Also IMO -OO should stop talking about optimizations. Maybe "Do what -O does and discard docstrings"? -- ___ Python tracker <http://bugs.python.org/issue17232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17232] Improve -O docs
Maciej Fijalkowski added the comment: There were not for at least 10 years. I would also be the first one to strongly object adding optimizations only under -O, because that already changes semantics. -- ___ Python tracker <http://bugs.python.org/issue17232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17232] Improve -O docs
New submission from Maciej Fijalkowski: This is what the current documentation says: -O Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE. -OO Discard docstrings in addition to the -O optimizations. As far as I know, the only "optimization" that's done is removal of __debug__ sections and assert statements and has been like this for years. Maybe it should say so "-O does not do any optimizations, only removes assert statement" or so. -- assignee: docs@python components: Documentation messages: 182365 nosy: docs@python, fijall priority: normal severity: normal status: open title: Improve -O docs type: behavior ___ Python tracker <http://bugs.python.org/issue17232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17231] Mark __del__ not being called in cycles as an impl detail
New submission from Maciej Fijalkowski: Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev discussion -- assignee: docs@python components: Documentation messages: 182364 nosy: docs@python, fijall priority: normal severity: normal status: open title: Mark __del__ not being called in cycles as an impl detail type: behavior ___ Python tracker <http://bugs.python.org/issue17231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1285086] urllib.quote is too slow
Maciej Fijalkowski added the comment: As per discussion on python-dev, this bug should probably be reopened and the patch maybe reverted as relying on the refcounting hack is both dodgy and hurts other implementations, like PyPy. -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue1285086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: Hi. This is what we did with Armin: http://bpaste.net/show/32123/ It seems there is still *some* information leaking via side-channels, although it's a bit unclear what. Feel free to play with it (try swapping, having different object etc.) -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: On Fri, Jun 15, 2012 at 10:09 AM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > > Note that this does not relief you from using a time-independent > comparison > > function. If you call some hash function (which time is known to the > > attacker), then you compare it against a stored hashed version. If you > use > > a normal compare you're leaking the hash. This is indeed not as bad as > > leaking the password, but it has been demonstrated that one-direction > > functions are still vulnerable to some sort of attacks, so it's not ideal > > either. > > But you don't leak the hash - you leak the first byte of the hash if you > make 256 tries, and the first two bytes if you make 65536 tries. To leak > the first four bytes of the hash, you need to make 2**32 tries. > So this is equivalent to a brute-force attack, which works just as well > against a time-independent function. So using a time-independent > function does not add any security. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue15061> > ___ > Martin, you fail to understand how this works. You don't do 2**32 tries to leak the 4 charaters, you need 4 * 256, that's why this attack is so bad, because the time needed for the next character is brute force, but then you can move on to the next one. -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack wrote: > > Hynek Schlawack added the comment: > > >> and any other place that compares passwords, tokens, … > > > > No no no. Any sensible place to compare passwords would use some > > sort of one-way function (password hash) before the comparison, > > so that someone breaking into the machine will not gain the clear > > text passwords. > > I agree that this is the right way to do. However I disagree that it's > also the only sensible way to do in the real world. Sometimes you just > _have_ to compare sensitive strings, whether you like it or not. > > I see your point that adding such a function would leverage bad security > behavior and thus may be a bad thing. The usefulness of such a function to > some(?) people is IMHO not disputable though. > Note that this does not relief you from using a time-independent comparison function. If you call some hash function (which time is known to the attacker), then you compare it against a stored hashed version. If you use a normal compare you're leaking the hash. This is indeed not as bad as leaking the password, but it has been demonstrated that one-direction functions are still vulnerable to some sort of attacks, so it's not ideal either. -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: On Fri, Jun 15, 2012 at 9:47 AM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > > To repeat, the specific feature being proposed for retention is: > > To repeat, no use case has been demonstrated for that function. It > has been added because it was fun to write, not because it is useful. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue15061> > ___ > Is comparing passwords against a secure one not useful? -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: On Fri, Jun 15, 2012 at 9:41 AM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > To repeat, the specific feature being proposed for retention is: > > * a function called hmac.total_compare() that is clearly documented as > being still vulnerable to timing analysis given a sufficiently > sophisticated attacker, while still being more resistant to such analysis > than the standard comparison operator > > * restricting that function to operating on bytes, to eliminate timing > variations associated with encoding/decoding of Unicode text and reduce > those associated with the calculation of integer values > > Leaking less information on each comparison is intended to increase the > effectiveness of higher level timing attack countermeasures (such as rate > limiting and lockouts). Anyone that would use "hmac.total_compare" and call > it done is likely using ordinary comparison today (which is even worse). > > -- > > ___ > Python tracker > <http://bugs.python.org/issue15061> > ___ > Nick, I fail to understand why are you opposing writing such a function in C. Such a function can be provably time-independent (and as MvL says this is a binary state), at least as long as it operates on bytes (I'll refrain from asking about unicode, I think it's possible, but I dunno). For the same function in python it's at the very least much harder to prove (and has bugs as we've seen) Cheers, fijal -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: Hi Christian. It's either secure or it's not. If it's not, there is no point in introducing it at all as I don't think it's a good idea to have a kind-of-secure-but-i-dont-know functions in stdlib. If you restrict input to bytes it looks okish, but I looked at all the code that's invoked on the C side and it's quite a lot of code. Does you or anyone else actually go and review all the C code that's called via various operations to check if it does or does not depend on the value of various characters? I can't tell myself, it's too long. -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: For unicode at the very least it's not an improvement at all. With the patch mentioned that does encode it's also not an improvement at all. Prove as in reason about the function in C and make sure it does not do any conditionals depending on the input data. This is much easier than it is in Python. We did this exercise for PyPy once, just for the sake of it. We looked at generated IR and made sure a comparison is not leaking any data. As far as the function goes right now - I don't know. For now following the entire code of long_bitwise is a lot of effort - I genuinely can't say that it'll be the same for all numbers of 0-255. Can you? It's easier with low-level language simply (And yes, this is one of the few cases where I would argue it makes sense to implement something in C :) -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: export not explore. Why can't I edit my own post? -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment: Antoine, seriously? You want to explore a function that's called "secure" when the only thing you know about it is "probably secure"? This is extremely tricky business and I think it should be called secure only if you can prove it's secure. Otherwise it's plain insecure and should not be named that. -- ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski added the comment:
Ah unicodes. is encode('unicode-internal') independent on the string
characters? I heavily doubt so. you leak at least some information through that
function alone.
--
___
Python tracker
<http://bugs.python.org/issue15061>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information of length of strings
Maciej Fijalkowski added the comment: secure_compare leaks the password always. Note that it takes different time to create a result of ord() depending whether it's <=100 or > 100 due to caching of small numbers. Such functions should be written in C. -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue15061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14212] Segfault when using re.finditer over mmap
New submission from Maciej Fijalkowski : Example to get a segfault attached. Crashes under python3 as well. -- files: x.py messages: 155028 nosy: fijall priority: normal severity: normal status: open title: Segfault when using re.finditer over mmap type: crash versions: Python 2.7 Added file: http://bugs.python.org/file24747/x.py ___ Python tracker <http://bugs.python.org/issue14212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10994] implementation details in sys module
Maciej Fijalkowski added the comment: > > Which experts you had in mind? > People who know how the Python implementation works. I'm serious. What semantics would make sense to anyone? Even if you know implementation quite well a single number per object does not provide enough information. -- ___ Python tracker <http://bugs.python.org/issue10994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10994] implementation details in sys module
Maciej Fijalkowski added the comment: I can hardly think about a specification that would potentially help me identify actual sizes. Even as a rough estimation. Which experts you had in mind? -- ___ Python tracker <http://bugs.python.org/issue10994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10994] implementation details in sys module
Maciej Fijalkowski added the comment: I suppose wrt getsizeof it's more of "if you provide us with a reasonable expectations, we can implement this" other than anything else. -- ___ Python tracker <http://bugs.python.org/issue10994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10994] implementation details in sys module
New submission from Maciej Fijalkowski : sys module documentation (as it is online) has some things that in my opinion should be marked as implementation details, but are not. Feel free to counter why not. Some of them has info it should be used for specialized purposes only, but IMO it's not the same as not mandatory for other implementations. Temporary list: _clear_type_cache dllhandle getrefcount getdlopenflags (?) getsizeof - it might be not well defined on other implementations setdlopenflags api_version -- assignee: docs@python components: Documentation messages: 126925 nosy: docs@python, fijall priority: normal severity: normal status: open title: implementation details in sys module type: behavior ___ Python tracker <http://bugs.python.org/issue10994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Maciej Fijalkowski : -- nosy: +fijall ___ Python tracker <http://bugs.python.org/issue10399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10244] PEP100 has broken links
Maciej Fijalkowski added the comment: That is really weird, it definitely doesn't for me. Anyway, closing the ticket then. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue10244> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10244] PEP100 has broken links
Maciej Fijalkowski added the comment: Python starship is down, I thought it's permanently down, isn't it? -- ___ Python tracker <http://bugs.python.org/issue10244> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10244] PEP100 has broken links
New submission from Maciej Fijalkowski : PEP100 (http://www.python.org/dev/peps/pep-0100/) links to python starship. Should it just link to python.org for the newest version of this doc? -- assignee: d...@python components: Documentation messages: 119967 nosy: d...@python, fijall priority: normal severity: normal status: open title: PEP100 has broken links ___ Python tracker <http://bugs.python.org/issue10244> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
