[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: +18034 pull_request: https://github.com/python/cpython/pull/18674 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: -18034 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: -18032 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: -18031 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: +18033 pull_request: https://github.com/python/cpython/pull/18675 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- pull_requests: +18032 pull_request: https://github.com/python/cpython/pull/18674 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
Change by Andy Lester : -- keywords: +patch pull_requests: +18031 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18673 ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39770] Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c
New submission from Andy Lester : The array_modexec function in Modules/arraymodule.c has a loop that calculates the number of elements in the descriptors array. This size was used at one point, but is no longer. The loop can be removed. -- components: Interpreter Core messages: 362772 nosy: petdance priority: normal severity: normal status: open title: Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c ___ Python tracker <https://bugs.python.org/issue39770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39736] const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c
Change by Andy Lester : -- keywords: +patch pull_requests: +18003 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18637 ___ Python tracker <https://bugs.python.org/issue39736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39736] const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c
New submission from Andy Lester : In Modules/_datetimemodule.c, the char *timespec and char *specs[] can be made const. Their contents are never modified. In ndarray_get_format in Modules/_testbuffer.c, char *fmt can be made const. -- components: Interpreter Core messages: 362565 nosy: petdance priority: normal severity: normal status: open title: const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c ___ Python tracker <https://bugs.python.org/issue39736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment: Just added a new PR to finish off the remaining places to use Py_IS_TYPE() https://github.com/python/cpython/pull/18601 -- ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Change by Andy Lester : -- pull_requests: +17968 pull_request: https://github.com/python/cpython/pull/18601 ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39721] Fix constness of members of tok_state struct.
Change by Andy Lester : -- keywords: +patch pull_requests: +17967 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18600 ___ Python tracker <https://bugs.python.org/issue39721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39721] Fix constness of members of tok_state struct.
New submission from Andy Lester : The function PyTokenizer_FromUTF8 from Parser/tokenizer.c had a comment: /* XXX: constify members. */ This patch addresses that. In the tok_state struct: * end and start were non-const but could be made const * str and input were const but should have been non-const Changes to support this include: * decode_str() now returns a char * since it is allocated. * PyTokenizer_FromString() and PyTokenizer_FromUTF8() each creates a new char * for an allocate string instead of reusing the input const char *. * PyTokenizer_Get() and tok_get() now take const char ** arguments. * Various local vars are const or non-const accordingly. I was able to remove five casts that cast away constness. -- components: Interpreter Core messages: 362441 nosy: petdance priority: normal severity: normal status: open title: Fix constness of members of tok_state struct. ___ Python tracker <https://bugs.python.org/issue39721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39684] PyUnicode_IsIdentifier has two if/thens that can be combined
Change by Andy Lester : -- pull_requests: -17937 ___ Python tracker <https://bugs.python.org/issue39684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39684] PyUnicode_IsIdentifier has two if/thens that can be combined
Change by Andy Lester : -- pull_requests: +17947 pull_request: https://github.com/python/cpython/pull/18565 ___ Python tracker <https://bugs.python.org/issue39684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38691] importlib: PYTHONCASEOK should be ignored when using python3 -E
Change by Andy Lester : -- nosy: +petdance ___ Python tracker <https://bugs.python.org/issue38691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39684] PyUnicode_IsIdentifier has two if/thens that can be combined
Change by Andy Lester : -- keywords: +patch pull_requests: +17937 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18557 ___ Python tracker <https://bugs.python.org/issue39684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39684] PyUnicode_IsIdentifier has two if/thens that can be combined
New submission from Andy Lester :
These two code if/thens can be combined
if (ready) {
kind = PyUnicode_KIND(self);
data = PyUnicode_DATA(self);
}
else {
wstr = _PyUnicode_WSTR(self);
}
Py_UCS4 ch;
if (ready) {
ch = PyUnicode_READ(kind, data, 0);
}
else {
ch = wstr[0];
}
--
components: Interpreter Core
messages: 362250
nosy: petdance
priority: normal
severity: normal
status: open
title: PyUnicode_IsIdentifier has two if/thens that can be combined
___
Python tracker
<https://bugs.python.org/issue39684>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment: All I'm saying is that I think Py_IS_TYPE is a great idea, and that Py_IS_TYPE should take const arguments, since its arguments are not modified. If you think that should go in a different ticket, then I can make that happen. -- ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment:
> Would you mind to explain how it's an issue to modify PyObject* temporarily
> during a function call?
It's not a problem to modify the PyObject* during a function call. However,
many functions don't need to modify the object, but are still taking non-const
PyObject* arguments.
For example if I have this code:
if (Py_TYPE(deque) == _type) {
That doesn't modify deque to check the type, but because Py_TYPE casts away the
constness, deque can't be a const object.
However, with the new Py_IS_TYPE function:
if (Py_IS_TYPE(deque, _type)) {
and these two changes:
-static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type) {
+static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {
return ob->ob_type == type;
}
-#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST(ob), type)
+#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(((const PyObject*)(ob)), type)
the deque variable can be const.
Another example of a common pattern that I believe could benefit from this is
Py_TYPE(ob)->tp_name. That could be turned into Py_TYPE_NAME(ob) and that
would allow the ob to be a const pointer.
If we can keep functions that don't modify the object to accept const PyObject*
it will help make things safer in the long run.
--
___
Python tracker
<https://bugs.python.org/issue39573>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment: I'm hoping that a goal here is to make static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type) actually be static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) -- ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment: @vstinner would it be helpful if I went on a sweep looking for places we can use the new Py_IS_TYPE macro? Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct. -- nosy: +petdance ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39630] Const some pointers to string literals
Change by Andy Lester : -- keywords: +patch pull_requests: +17886 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18510 ___ Python tracker <https://bugs.python.org/issue39630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39630] Const some pointers to string literals
New submission from Andy Lester : Here are some fixes of char * pointers to literals that should be const char * in these four files. +++ Objects/frameobject.c +++ Objects/genobject.c +++ Python/codecs.c +++ Python/errors.c -- components: Interpreter Core messages: 361982 nosy: petdance priority: normal severity: normal status: open title: Const some pointers to string literals type: enhancement ___ Python tracker <https://bugs.python.org/issue39630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39621] md5_compress() in Modules/md5module.c can take a const buf
Change by Andy Lester : -- keywords: +patch pull_requests: +17871 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18497 ___ Python tracker <https://bugs.python.org/issue39621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39621] md5_compress() in Modules/md5module.c can take a const buf
New submission from Andy Lester : The function md5_compress does not modify its buffer argument. static void md5_compress(struct md5_state *md5, unsigned char *buf) buf should be const. -- components: Extension Modules messages: 361932 nosy: petdance priority: normal severity: normal status: open title: md5_compress() in Modules/md5module.c can take a const buf type: enhancement ___ Python tracker <https://bugs.python.org/issue39621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39620] PyObject_GetAttrString and tp_getattr do not agree
Andy Lester added the comment: Do you know why it was reverted? (Granted, it was 15 years ago...) It looks like the original changeset is trying to address at least two different problems with non-const string literals. My ticket here is focusing only on getattrfunc and setattrfunc. The handling of all the kwlist is a separate issue, that I'm about to write up as a different ticket. -- ___ Python tracker <https://bugs.python.org/issue39620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39620] PyObject_GetAttrString and tp_getattr do not agree
New submission from Andy Lester : PyObject_GetAttrString(PyObject *v, const char *name) typedef PyObject *(*getattrfunc)(PyObject *, char *) The outer PyObject_GetAttrString takes a const char *name, but then casts away the const when calling the underlying tp_getattr. This means that an underlying function would be free to modify or free() the char* passed in to it, which might be, for example, a string literal, which would be a Bad Thing. The setattr function pair has the same problem. The API doc at https://docs.python.org/3/c-api/typeobj.html says that the tp_getattr and tp_setattr slots are deprecated. If they're not going away soon, I would think this should be addressed. Fixing this in the cPython code by making tp_getattr and tp_setattr take const char * pointers would be simple. I don't have any idea how much outside code it would affect. -- components: C API messages: 361929 nosy: petdance priority: normal severity: normal status: open title: PyObject_GetAttrString and tp_getattr do not agree type: enhancement ___ Python tracker <https://bugs.python.org/issue39620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39605] Fix some casts to not cast away const
Change by Andy Lester : -- keywords: +patch pull_requests: +17827 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18453 ___ Python tracker <https://bugs.python.org/issue39605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39605] Fix some casts to not cast away const
New submission from Andy Lester : gcc -Wcast-qual turns up a number of instances of casting away constness of pointers. Some of these can be safely modified, by either: * Adding the const to the type cast, as in: -return _PyUnicode_FromUCS1((unsigned char*)s, size); +return _PyUnicode_FromUCS1((const unsigned char*)s, size); * Removing the cast entirely, because it's not necessary (but probably was at one time), as in: -PyDTrace_FUNCTION_ENTRY((char *)filename, (char *)funcname, lineno); +PyDTrace_FUNCTION_ENTRY(filename, funcname, lineno); These changes will not change code, but they will make it much easier to check for errors in consts. -- components: Interpreter Core messages: 361780 nosy: petdance priority: normal severity: normal status: open title: Fix some casts to not cast away const type: enhancement ___ Python tracker <https://bugs.python.org/issue39605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Andy Lester added the comment: > Yes, Py_INCREF and Py_DECREF change the type, and therefore constness. Understood. The changes that I have proposed are not to objects that get sent through Py_INCREF/Py_DECREF. If they did, -Wcast-qual would have caught it. -Wcast-qual catches if you cast, say, a const char * to a char *. Let's let this stay closed and I'll resubmit with a clearer ticket & PR. -- ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Andy Lester added the comment: I'm sorry, I think my comment was misleading. The changes I had proposed were not making the object itself const, but some of the arguments in the static worker functions. For example: -tb_displayline(PyObject *f, PyObject *filename, int lineno, PyObject *name) +tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name) and -tb_printinternal(PyTracebackObject *tb, PyObject *f, long limit) +tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit) I've got -Wincompatible-pointer-types-discards-qualifiers and -Wcast-qual turned on, and no errors occur. Is there somewhere in the deep internals of the Python macros where constness can be changed but the compiler isn't reporting on it? Thanks, Andy -- ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: -17798 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17799 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: -17794 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: +17798 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17797 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- keywords: +patch pull_requests: +17794 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18420 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17793 pull_request: https://github.com/python/cpython/pull/18420 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
New submission from Andy Lester : The functions tb_displayline and tb_printinternal can take const pointers on some of their arguments. tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name) tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit) -- components: Interpreter Core messages: 361643 nosy: petdance priority: normal severity: normal status: open title: Functions in Python/traceback.c can take const pointer arguments type: enhancement ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
Andy Lester added the comment: Thanks for replying. I figured that might be the case, which is why I made a ticket before bothering with a pull request. I've also seen this kind of thing around: i = ctx->pattern[0]; Py_ssize_t groupref = i+i; instead of Py_ssize_t groupref = ctx->pattern[0]*2; Is that also the kind of thing we would leave for the compiler to sort out? -- ___ Python tracker <https://bugs.python.org/issue39588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: I'm closing this as it seems there's not much interest in this. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
New submission from Andy Lester : Four functions in Objects/unicodectype.c copy values out of lookup tables with a for loop int i; for (i = 0; i < n; i++) res[i] = _PyUnicode_ExtendedCase[index + i]; instead of a memcpy memcpy(res, &_PyUnicode_ExtendedCase[index], n * sizeof(Py_UCS4)); My Apple clang version 11.0.0 on my Mac optimizes away the for loop and generates equivalent code to the memcpy. gcc 4.8.5 on my Linux box (the newest GCC I have) does not optimize away the loop. The four functions are: _PyUnicode_ToLowerFull _PyUnicode_ToTitleFull _PyUnicode_ToUpperFull _PyUnicode_ToFoldedFull -- components: Unicode messages: 361636 nosy: ezio.melotti, petdance, vstinner priority: normal severity: normal status: open title: Use memcpy() instead of for() loops in _PyUnicode_To* type: performance ___ Python tracker <https://bugs.python.org/issue39588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: Re: branch prediction. The branch if (c1>=37 && c1<=126) could just as easily be if (c1>=0 && c1<=126) with no other changes to the code. It could be just if (c1<=126) if c1 wasn't signed. As far as branch prediction, we could make it something like if (c1>=0 && c1<=255) and expand the table lookup, depending on what the likely inputs are. I could play around with that some if anyone was interested. I'm not trying to push on this. Just sharing some thoughts and research. -- ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment:
Yes, I ran it multiple times on my 2013 Macbook Pro and got ~10% speedup. I
also ran it on my Linux VM (that I only use for development) and got a speedup
but less so.
The code I used to run the tests is at:
https://github.com/petdance/cpython/blob/Issue39150/timetests
LOG=timelog.txt
NRUNS=100
NFILES=100
if [ -x ./python.exe ] ; then
PYTHON=./python.exe
else
PYTHON=./python
fi
# Build a file list, but throw out some that have syntax errors.
# Use the 100 biggest files.
FILES=$(
find . -name '*.py' -type f -ls \
| grep -v Tools/test2to3/ \
| grep -v Lib/lib2to3/tests/ \
| grep -v Lib/test/badsyntax \
| grep -v Lib/test/bad_coding \
| sort -r -n -k7 \
| awk '{print $11}' \
| head -n $NFILES
)
echo "Compiling $NFILES files for $NRUNS iterations"
rm -f $LOG
for (( i=1; i<=$NRUNS; i++ )) do
echo "Run $i"
{ time $PYTHON -m py_compile $FILES; } >> $LOG 2>&1
done
perl -ne'if(/real\s+0m([\d.]+)s/){$t+=$1;$n++} END { printf "%d runs, average
%0.4f\n", $n, $t/$n}' $LOG
--
___
Python tracker
<https://bugs.python.org/issue39150>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment:
I tried out some experimenting with the lookup table vs. the switch
statement.
The relevant diff (not including the patches to the code generator) is:
--- Parser/token.c
+++ Parser/token.c
@@ -77,31 +77,36 @@
int
PyToken_OneChar(int c1)
{
-switch (c1) {
-case '%': return PERCENT;
-case '&': return AMPER;
-case '(': return LPAR;
-case ')': return RPAR;
-case '*': return STAR;
-case '+': return PLUS;
-case ',': return COMMA;
-case '-': return MINUS;
-case '.': return DOT;
-case '/': return SLASH;
-case ':': return COLON;
-case ';': return SEMI;
-case '<': return LESS;
-case '=': return EQUAL;
-case '>': return GREATER;
-case '@': return AT;
-case '[': return LSQB;
-case ']': return RSQB;
-case '^': return CIRCUMFLEX;
-case '{': return LBRACE;
-case '|': return VBAR;
-case '}': return RBRACE;
-case '~': return TILDE;
-}
+static char op_lookup[] = {
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,PERCENT, AMPER, OP,
+LPAR, RPAR, STAR, PLUS, COMMA,
+MINUS, DOT, SLASH, OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,COLON, SEMI,
+LESS, EQUAL, GREATER, OP,AT,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,LSQB, OP,RSQB, CIRCUMFLEX,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,LBRACE,VBAR,
+RBRACE,TILDE
+};
+if (c1>=37 && c1<=126)
+return op_lookup[c1];
return OP;
}
To test the speed change, I couldn't use pyperformance, because the only
thing I wanted to time was the In my testing, I didn't use pyperformance
because the only part of the code I wanted to test was the actual
compilation of the code. My solution for this was to find the 100 largest
*.py files in the cpython repo and compile them like so:
python -m py_compile $(List-of-big-*.py-files)
The speedup was significant: My table-driven lookup ran the compile tests
about 10% than the existing switch approach. That was without
--enable-optimizations in my configure.
However, as pablogsal suspected, with PGO enabled, the two approaches ran
the code in pretty much the same speed.
I do think that there may be merit in using a table-driven approach that
generates less code and doesn't rely on PGO speeding things up.
If anyone's interested, all my work is on branch Issue39150 in my fork
petdance/cpython.
--
___
Python tracker
<https://bugs.python.org/issue39150>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39146] too much memory consumption in re.compile unicode
Change by Andy Lester : -- components: +Regular Expressions -Library (Lib) nosy: +ezio.melotti, mrabarnett ___ Python tracker <https://bugs.python.org/issue39146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: Thank you. I appreciate the pointer. -- ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
New submission from Andy Lester : PyToken_OneChar in Parser/token.c is autogenerated. I suspect it may be faster and smaller if it were a lookup into a static table of ops rather than a switch statement. Check to see if it is. -- components: Interpreter Core messages: 358975 nosy: petdance priority: normal severity: normal status: open title: See if PyToken_OneChar would be faster as a lookup table type: enhancement ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39127] _Py_HashPointer's void * argument should be const
Change by Andy Lester : -- keywords: +patch pull_requests: +17145 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17690 ___ Python tracker <https://bugs.python.org/issue39127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39127] _Py_HashPointer's void * argument should be const
New submission from Andy Lester : _Py_HashPointer in Python/pyhash.c takes a pointer argument that can be made const. This will let compiler and static analyzers know that the pointer's target is not modified. You can also change calls to _Py_HashPointer that are down-casting pointers. For example, in meth_hash in Objects/methodobject.c, this call can have the void * changed to const void *. y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); -- components: Interpreter Core messages: 358839 nosy: petdance priority: normal severity: normal status: open title: _Py_HashPointer's void * argument should be const ___ Python tracker <https://bugs.python.org/issue39127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Thanks for the help, Christian! -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Our user was able to fix this issue by upgrading the OpenSSL version used on the client side from 1.0.1e-fips to 1.1.1. It seems to me that Python's SSL support cannot do anything about this issue. As far as I'm concerned ths issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: More details about the environment this happens on: Python 3.5.7 (default, Aug 16 2019, 10:17:32) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
New submission from Andy Maier : A user of our pywbem package gets an SSLError with message "[SSL] EC lib (_ssl.c:728)" when invoking the connect() method on an SSL wrapped socket. See https://github.com/pywbem/pywbem/issues/1950. The issue is that with this error message, it is not possible for us to figure out what the problem is and how to correct it. This happens with CPython 3.5. I have tried to find the place in _ssl.c (https://github.com/python/cpython/blob/3.5/Modules/_ssl.c) where a string "EC lib" or " lib" is created but did not find it there. I have two requests: 1. Please explain what the reason is for this exception and what to change in the environment to make it work. 2. Please improve the message in this exception so that it is self-explanatory. -- assignee: christian.heimes components: SSL messages: 356654 nosy: andymaier, christian.heimes priority: normal severity: normal status: open title: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)" versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37871] 40 * 473 grid of "é" has a single wrong character on Windows
New submission from ANdy :
# To reproduce:
# Put this text in a file `a.py` and run `py a.py`.
# Or just run: py -c "print(('é' * 40 + '\n') * 473)"
# Scroll up for a while. One of the lines will be:
# ��ééé
# (You can spot this because it's slightly longer than the other lines.)
# The error is consistently on line 237, column 21 (1-indexed).
# The error reproduces on Windows but not Linux. Tested in both powershell and
CMD.
# (Failed to reproduce on either a real Linux machine or on Ubuntu with WSL.)
# On Windows, the error reproduces every time consistently.
# There is no error if N = 472 or 474.
N = 473
# There is no error if W = 39 or 41.
# (I tested with console windows of varying sizes, all well over 40 characters.)
W = 40
# There is no error if ch = "e" with no accent.
# There is still an error for other unicode characters like "Ö" or "ü".
ch = "é"
# There is no error without newlines.
s = (ch * W + "\n") * N
# Assert the string itself is correct.
assert all(c in (ch, "\n") for c in s)
print(s)
# There is no error if we use N separate print statements
# instead of printing a single string with N newlines.
# Similar scripts written in Groovy, JS and Ruby have no error.
# Groovy: System.out.println(("é" * 40 + "\n") * 473)
# JS: console.log(("é".repeat(40) + "\n").repeat(473))
# Ruby: puts(("é" * 40 + "\n") * 473)
--
components: Windows
messages: 349837
nosy: anhans, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 40 * 473 grid of "é" has a single wrong character on Windows
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22121] IDLE should start with HOME as the initial working directory
Andy Harrington added the comment: This is really important for newbies. They have no business being in the system Python folder. And Idle is for newbies! I was teaching an intro Python class, and tried to help a student who had been writing programs in Idle, but now could not get Python going. It took many minutes for me to discover that he had created a new file while the shell window had focus, and innocently saved the file as math.py, without looking for a new directory to put it in. What a pain tracking that down! -- nosy: +andyharrington ___ Python tracker <https://bugs.python.org/issue22121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37542] UDP sendto() sends duplicate packets
Change by Andy Papageorgiou : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue37542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37542] UDP sendto() sends duplicate packets
New submission from Andy Papageorgiou :
Wireshark reports two identical back to back packets sent for each sendto(),
timing between packets is between 2 and 10us.
Note this is on a point to point ethernet (just 1 cable, no switches, routers
or anything else in between) to an embedded platform (Zynq ARM) from an intel
i7 Window 10 laptop from 2018. The python code is running on the laptop.
python code:
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
s.bind(('', 5704))
while(more_to_send == TRUE)
s.sendto(bytes_to_send, (HOST, UDP_PORT))
data = s.recv(1024)
Wireshark log.
43204 80.146000 192.168.1.20192.168.1.10UDP 566 5704 →
5604 Len=524 (payload)
43205 80.146003 192.168.1.20192.168.1.10UDP 566 5704 →
5604 Len=524 (duplicate at payload time + 3us)
43206 80.149112 192.168.1.10192.168.1.20UDP 48 5604 →
5704 Len=6 (ack)
43207 80.149306 192.168.1.20192.168.1.10UDP 566 5704 →
5604 Len=524 (payload)
43208 80.149311 192.168.1.20192.168.1.10UDP 566 5704 →
5604 Len=524 (duplicate at payload time +5us)
I am suspicious this is an artefact of the point to point link.
--
components: Library (Lib)
messages: 347614
nosy: Andy Papageorgiou
priority: normal
severity: normal
status: open
title: UDP sendto() sends duplicate packets
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37542>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36774] f-strings: Add a !d conversion for ease of debugging
Change by Andy Dirnberger : -- nosy: +dirn ___ Python tracker <https://bugs.python.org/issue36774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34864] In Idle, Mac tabs make bottom editor line with cursor location disappear
Andy Harrington added the comment: This appears to be a system settings option in Mac OS Sierra set under the Dock, "prefer tabs when opening documents". With that choice, when there is the tab bar in an Idle edit window (more than one window superimposed, with tabs) the the whole bottom line with the horizontal separator line segment disappears: seems like no allowance is made for the vertical space taken up by the tab bar at top. There is a workaround: turn off this OS option, but unfortunate to need to do that, and the user has no warning that it is necessary. I only noticed this when I switched to a new machine and was doing initial diddling with the system options, and did not realize that i was not setting it up as I had it on my previous machine. Dr. Andrew N. Harrington Computer Science Department Graduate Program Director g...@cs.luc.edu Loyola University Chicago 207 Doyle Center, 1052 W Loyola Ave. http://www.cs.luc.edu/~anh Phone: 773-508-3569 Dept. Fax:773-508-3739 ahar...@luc.edu (as professor, not gpd role) On Mon, Oct 1, 2018 at 9:30 PM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > I do not see this 64-bit 3.7.1rc1 (see #34863) on 10.13.6 with, I believe, > default settings. > > Are you reporting multiple tabs as a bug, or a feature resulting from > intentional settings? If the latter, this may be something the tcl/tk does > not support properly. Ned and Tal, do either of you know anything about > this? > > In any case, is the status bar missing, or is the cursor position missing > from the status bar. > > -- > nosy: +ned.deily, taleinat > > ___ > Python tracker > <https://bugs.python.org/issue34864> > ___ > -- ___ Python tracker <https://bugs.python.org/issue34864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34864] In Idle, Mac tabs make bottom editor line with cursor location disappear
New submission from Andy Harrington : Mac now puts multiple tabs inside of application window instead of starting a separate window (with some OS settings). With just one file being edited in Idle (no tab line) the bottom line with the numerical cursor coordinates is visible. When there are multiple tabs (and the tabbing heading therefore) the bottom cursor coordinates are missing. -- assignee: terry.reedy components: IDLE messages: 326822 nosy: andyharrington, terry.reedy priority: normal severity: normal status: open title: In Idle, Mac tabs make bottom editor line with cursor location disappear versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34863] Idle Mac scrolling only down
New submission from Andy Harrington : In a source file in Idle I scroll down no matter which way I rotate the mouse wheel. This happens in no other app. Mac High Sierra OS. I have the Mac scrolling setup "natural" - backwards from the Windows directions. -- assignee: terry.reedy components: IDLE messages: 326821 nosy: andyharrington, terry.reedy priority: normal severity: normal status: open title: Idle Mac scrolling only down type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34598] How to fix? Error in Kali linux python 2.7 - Collecting pip From cffi callback : Traceback (most recent call last): File "/usr/local/lib/pytho
New submission from andy polandski :
root@kali:~# python get-pip.py
Collecting pip
>From cffi callback :
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in
wrapper
_lib.X509_up_ref(x509)
AttributeError: 'module' object has no attribute 'X509_up_ref'
Retrying (Retry(total=4, connect=None, read=None, redirect=None,
status=None)) after connection broken by 'SSLError(SSLError("bad handshake:
Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify
failed')],)",),)': /simple/pip/
--
messages: 324702
nosy: andy polandski
priority: normal
severity: normal
status: open
title: How to fix? Error in Kali linux python 2.7 - Collecting pip From cffi
callback : Traceback (most recent
call last): File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py",
line 309, in wrapper
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue34598>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34434] Removal of kwargs for int() etc not described as change
New submission from Andy Maier : Python 3.7 removed support for passing the argument to the built-in functions int(), bool(), float(), list() and tuple() as a keyword argument. This change is described in the "What's New" for 3.7 (https://docs.python.org/3/whatsnew/3.7.html) in section "API and Feature Removals": Functions bool(), float(), list() and tuple() no longer take keyword arguments. The first argument of int() can now be passed only as positional argument. The issue is that this change is not described in the documentation of these built-in functions. -- messages: 323756 nosy: andymaier priority: normal severity: normal status: open title: Removal of kwargs for int() etc not described as change type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed
Andy Balaam <m...@artificialworlds.net> added the comment: I would argue that this makes as_completed a lot more useful than it is now, so would be worth adding (maybe after 3.7). But, if this does not go into asyncio, is there another library where it would belong? Or should this be a completely new library? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31809] ssl module unnecessarily pins the client curve when using ECDH
Andy <grr...@surfsup.at> added the comment: Thanks for adding the test! If the official stance is that only the latest OpenSSL is supported then this is definitely WAI. Sounds like a good policy... I'll close this issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31809] ssl module unnecessarily pins the client curve when using ECDH
Andy <grr...@surfsup.at> added the comment: While debugging I reproduced this on - 'OpenSSL 1.1.0f 25 May 2017' - 'OpenSSL 1.0.1f 6 Jan 2014' - and 'BoringSSL', latest. using Python 2.7.12, 2.7.13, 2.7.6 and 3.5.3. This was all on Debian. Note that since I used Python <2.7.14 (or equivalent for 3.x) for all tests, the check "... && !defined(OPENSSL_VERSION_1_1)" is missing and therefore the bug *always* triggers regardless of OpenSSL version. I'm not sure I agree that this one curve is a good default. Note that openssl has 81 curves currently (openssl ecparam -list_curves) and probably can use most of them to connect to a server - accommodating a variety of server setups. Restricting this list to one single curve seems suboptimal. Think about it like this, if tomorrow we find an issue with that particular curve, all servers can just migrate to a different one and all clients will be able to connect just fine - except those that use Python, they will not be able to talk to those servers ever again until they are upgraded. I mean in the end it's your call but having a *client* just accepting one single security parameter and nothing else doesn't seem right. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed
Andy Balaam added the comment: bump -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed
Changes by Andy Balaam <m...@artificialworlds.net>: -- pull_requests: +2475 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed
New submission from Andy Balaam: asyncio.as_completed allows us to provide lots of coroutines (or Futures) to schedule, and then deal with the results as soon as they are available, in a loop, or a streaming style. I propose to allow as_completed to work on very large numbers of coroutines, provided through a generator (rather than a list). In order to make this practical, we need to limit the number of coroutines that are scheduled simultaneously to a reasonable number. For tasks that open files or sockets, a reasonable number might be 1000 or fewer. For other tasks, a much larger number might be reasonable, but we would still like some limit to prevent us running out of memory. I suggest adding a "limit" argument to as_completed that limits the number of coroutines that it schedules simultaneously. For me, the key advantage of as_completed (in the proposed modified form) is that it enables a streaming style that looks quite like synchronous code, but is efficient in terms of memory usage (as you'd expect from a streaming style): #!/usr/bin/env python3 import asyncio import sys limit = int(sys.argv[1]) async def double(x): await asyncio.sleep(1) return x * 2 async def print_doubles(): coros = (double(x) for x in range(100)) for res in asyncio.as_completed(coros, limit=limit): r = await res if r % 10 == 0: print(r) loop = asyncio.get_event_loop() loop.run_until_complete(print_doubles()) loop.close() Using my prototype implementation, this runs faster and uses much less memory on my machine when you run it with a limit of 100K instead of 1 million concurrent tasks: $ /usr/bin/time --format "Memory usage: %MKB\tTime: %e seconds" ./example 100 Memory usage: 2234552KB Time: 97.52 seconds $ /usr/bin/time --format "Memory usage: %MKB\tTime: %e seconds" ./example 10 Memory usage: 252732KB Time: 94.13 seconds I have been working on an implementation and there is some discussion in my blog posts: http://www.artificialworlds.net/blog/2017/06/12/making-100-million-requests-with-python-aiohttp/ and http://www.artificialworlds.net/blog/2017/06/27/adding-a-concurrency-limit-to-pythons-asyncio-as_completed/ Possibly the most controversial thing about this proposal is the fact that we need to allow passing a generator to as_completed instead of enforcing that it be a list. This is fundamental to allowing the style I outlined above, but it's possible that we can do better than the blanket allowing of all generators that I did. -- components: asyncio messages: 296982 nosy: andybalaam, yselivanov priority: normal severity: normal status: open title: Allow limiting the number of concurrent tasks in asyncio.as_completed type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError
Andy Edwards added the comment: I'm seeing this issue in Python 2.7 Andys-MacBook-Pro:jcore-api-py andy$ which python /Library/Frameworks/Python.framework/Versions/2.7/bin/python Andys-MacBook-Pro:jcore-api-py andy$ python setup.py test running test running egg_info writing requirements to jcore_api.egg-info/requires.txt writing jcore_api.egg-info/PKG-INFO writing top-level names to jcore_api.egg-info/top_level.txt writing dependency_links to jcore_api.egg-info/dependency_links.txt reading manifest file 'jcore_api.egg-info/SOURCES.txt' writing manifest file 'jcore_api.egg-info/SOURCES.txt' running build_ext . -- Ran 21 tests in 3.423s OK Andys-MacBook-Pro:jcore-api-py andy$ python setup.py test running test running egg_info writing requirements to jcore_api.egg-info/requires.txt writing jcore_api.egg-info/PKG-INFO writing top-level names to jcore_api.egg-info/top_level.txt writing dependency_links to jcore_api.egg-info/dependency_links.txt reading manifest file 'jcore_api.egg-info/SOURCES.txt' writing manifest file 'jcore_api.egg-info/SOURCES.txt' running build_ext . -- Ran 21 tests in 3.422s OK Exception in thread jcore.io receiver: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner self.run() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run self.__target(*self.__args, **self.__kwargs) File "/Users/andy/jcore-api-py/jcore_api/_connection.py", line 104, in _run_recv_thread traceback.print_exc() AttributeError: 'NoneType' object has no attribute 'print_exc' -- nosy: +jedwards1211 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Just for completeness: The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: @leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the os-release file. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Nir currently proposes to change the package name from "ld" to "dist". See https://github.com/nir0s/ld/issues/103 Comments on this name change proposal are welcome (over there). On "Given the unremarkable simplicity of implementing this function correctly ...": It seems to me that this is over-simplifying the task somewhat. Nir's "ld" package needs to understand all of the (currently) three different formats on Linux, and goes for a precedence-based approach to consolidate the information. Also, determining supposedly simple things like a reliable distro ID, or a precise distro version is not trivial, given that some Linux distros provide their data quite inconsistently between the different data sources and sometimes change things like distro ID incompatibly in a new minor release. Overall, I can only encourage people to try out the "ld" package (v0.5.0 is currently on PyPI) and give feedback (on its GitHub project). Does the deprecation and removal of these functions discriminate Linux compared to Windows and OS-X? Maybe, but I'm pragmatic here, and for me the important criteria is the one that was stated from the beginning in this discussion: The higher change rate in Linux fits quite well with the approach of having a separate package that is not part of the standard Python. Does that mean that less batteries are now included in Python out of the box: Yes, a very small part of the batteries is now no longer included. But maybe one day when the "ld" package is perfect and does not require a high change rate anymore, it gets added to standard Python. Also, there are many packages the average Python project needs these days that are no longer coming with standard Python (six, setuptools, pbr, better unit testers, lxml, M2Crypto, Sphinx, lxml, ). If you look at the long backlog of pull requests and open issues in standard Python, it is a good thing actually, not to overload the community maintaining the standard Python even further. But that is a bit off-topic for this issue, I am just mentioning it in order to beg for acceptance for the approach taken for linux distro information. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Martin, I just noticed that your fix must already be active. My link to tzinfo now lands on the long description. So maybe it was not a user error of mine that resolved the problem with the two methods (I was pretty sure I had tried the same syntax I use now), but whatever did the trick in your change. Anyway, thanks much for this quick turnaround!! Andy -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Martin, I can now link to the two methods e.g. via :meth:`py:datetime.tzinfo.utcoffset`, and it resolves nicely. See here (linking to Python 2): https://pywbem.readthedocs.org/en/latest/#pywbem.MinutesFromUTC Don't know why it now works, probably user error I would say. Your change is still appreciated, and it would be great if it could also go into Python 2.7 :-) Hope I'm not asking for too much. On Python build: hg config problem sounds like a good path. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Ok. If these methods generate index entries, maybe the problem is on my side by not linking them correctly. So let's try with the other two changes. Unfortunately, I cannot easily build cpython at the moment to verify, I moved to Linux and when trying to build cpython, bash rejects the configure script because of trailing CR characters. This is a freshly installed hg package on Ubuntu 14.04, against a fresh clone of the cpython repo. Any idea what is happening there? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
Andy Maier added the comment: Hi Martin! The intersphinx stuff is simply linking from a Sphinx RST documentation to a different Sphinx RST documentation, using support from the intersphinx extension of Sphinx. I think the name comes from the interwiki links in MediaWiki. It only comes into play here because my particular documentation is outside of the Python documentation. The same issues would arise when linking from other places in the Python documentation. Your explanation about :noindex: hits the nail on the head, I think. It seems to me that a minimal variant for fixing this would be: * add :noindex: to the class markup for the short descriptions of tzinfo and timezone. * add a class markup for tzinfo at its long description. I don't know whether that solves the method linking issue, though, but its worth a try. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26678] Incorrect linking to elements in datetime package
New submission from Andy Maier: Hi, I did search for these in the open bugs, but did not find any matching bug. I have a project that revealed that some of its InterSphinx links to existing classes/types or methods to not resolve their targets, or to resolve to a target that is not the right one (IMO). This issue here describes everything I found in the datetime package. Line numbers in this issue apply to the datetime.rst file as of commit 96a98bcaac70 (https://hg.python.org/cpython/file/96a98bcaac70/Doc/library/datetime.rst). * class datetime.tzinfo: An intersphinx link to it gets resolved but targets the short description of the class in the intro (line 106 of datetime.rst), and I did not find a way to target the full description (line 1552), which is really what this should be resolved to (IMO). I suspect that this has to do with the fact that this class has only one anchor on its short description on line 106, while companion classes such as datetime.datetime have two anchors (lines 91 and 681) where the last one wins (and happens to be the long description). However, see the next item. * class datetime.timezone: Same issue as for class datetime.tzinfo; links get resolved but land on the short intro. However, this time there are two anchors (lines 113 and 1795). So maybe my suspicion above is rather speculation... * method datetime.tzinfo.utcoffset: An intersphinx link to it does not get resolved. On line 1579 in datetime.rst, there is a `.. method:: tzinfo.utcoffset(dt)` but at least these intersphinx links did not get resolved: :func:`py:tzinfo.utcoffset` :func:`py:datetime.tzinfo.utcoffset` Do method anchors need the anchor for their defining class close by to work? Which because if the first issue above, would be the short version of it, way above. (Again speculation) * Same for method datetime.tzinfo.dst -- assignee: docs@python components: Documentation messages: 262698 nosy: andymaier, docs@python priority: normal severity: normal status: open title: Incorrect linking to elements in datetime package type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Nir, I appreciate very much what you are doing. I was about to do the same ;-) I'll review your code shortly. I like the idea to use /etc/os-release, as it has the most complete information. Stay tuned. Andy Am 6. Dezember 2015 18:12:52 MEZ, schrieb Nir Cohen <rep...@bugs.python.org>: > >Nir Cohen added the comment: > >I have a premliminary implementation of it: https://github.com/nir0s/ld > >Would love some help. It tries to use adhere to the standards >(os-release first, lsb-release later, then, distro-specific release >files). > >It also returns more types of values then there were before. > >-- >nosy: +nir0s > >___ >Python tracker <rep...@bugs.python.org> ><http://bugs.python.org/issue1322> >___ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have posted v14 of the patch (for the 3.5 'default' branch), based on Martin's v13. v14 addresses all comments Martin made, as described in my responses to them (see patch set 10). On Issue 4395: That issue should be pursued in addition to this issue; it seems Martin's patch for it is complementary to the patch for this issue here. On Issue 22000: I agree that that issue is addressed by the patch for this issue here. All: Please review the v14 patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Andy Maier andreas.r.ma...@gmx.de: Added file: http://bugs.python.org/file38303/issue12067-expressions-py3.5_v14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Andy Maier added the comment: Do we really think that a package on pypi solves the problem better? The discussion only shows that it is more likely we end up with multiple different packages on pypi, instead of one that is commonly agreed. I agree it is tough to get to an agreed upon approach, but having this in the Python base at least ensures that it is the one approach everybody uses. The /etc/os-release format seems to be used more often now, so I'm wondering why we cannot come up with a reasonable approach that is backwards compatible, supports /etc/os-release, and (if still needed), also /etc/lsb-release and the lsb_release script. Again: If we ever want to end up with just one package on pypi, that very discussion needs to happen. It seems to me that if the approach should be compatible, then we cannot use the new generic files (lsb* and os-release) first. The currently implemented approach needs to be used first. Then the new generic files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Changes by Andy Maier andreas.r.ma...@gmx.de: -- nosy: +andymaier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23328] urllib2 fails for proxy credentials that contain a '/' character
Andy Reitz added the comment: Sure, but the question is who should do the encoding -- the user, or python? I think it would be better for python to read the password from the environment variable, and encode it before using it. I think this is what users expect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23328 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23328] urllib2 fails for proxy credentials that contain a '/' character
Andy Reitz added the comment: The proxy credentials are supplied by our sysadmin. My understanding is that the http_proxy env variable doesn't require URI encoding. In addition, the same credentials work fine with curl. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23328 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23328] urllib2 fails for proxy credentials that contain a '/' character
New submission from Andy Reitz:
On Python 2.7.9, if I set an https_proxy environment variable, where the
password contains a '/' character, urllib2 fails. Given this test code:
import os, urllib
os.environ['http_proxy'] = http://someuser:a/b@10.11.12.13:1234;
f = urllib.urlopen('http://www.python.org')
data = f.read()
print data
I expect this error message (because my sample proxy is totally bogus):
[areitz@SOMEHOST ~]$ python2.7 test.py
Traceback (most recent call last):
File test.py, line 3, in module
f = urllib.urlopen('http://www.python.org')
File /usr/lib64/python2.7/urllib.py, line 87, in urlopen
return opener.open(url)
File /usr/lib64/python2.7/urllib.py, line 213, in open
return getattr(self, name)(url)
File /usr/lib64/python2.7/urllib.py, line 350, in open_http
h.endheaders(data)
File /usr/lib64/python2.7/httplib.py, line 997, in endheaders
self._send_output(message_body)
File /usr/lib64/python2.7/httplib.py, line 850, in _send_output
self.send(msg)
File /usr/lib64/python2.7/httplib.py, line 812, in send
self.connect()
File /usr/lib64/python2.7/httplib.py, line 793, in connect
self.timeout, self.source_address)
File /usr/lib64/python2.7/socket.py, line 571, in create_connection
raise err
IOError: [Errno socket error] [Errno 101] Network is unreachable
Instead, I receive this error:
[areitz@SOMEHOST ~]$ python2.7 test.py
Traceback (most recent call last):
File test.py, line 3, in module
f = urllib.urlopen('http://www.python.org')
File /usr/lib64/python2.7/urllib.py, line 87, in urlopen
return opener.open(url)
File /usr/lib64/python2.7/urllib.py, line 213, in open
return getattr(self, name)(url)
File /usr/lib64/python2.7/urllib.py, line 339, in open_http
h = httplib.HTTP(host)
File /usr/lib64/python2.7/httplib.py, line 1107, in __init__
self._setup(self._connection_class(host, port, strict))
File /usr/lib64/python2.7/httplib.py, line 712, in __init__
(self.host, self.port) = self._get_hostport(host, port)
File /usr/lib64/python2.7/httplib.py, line 754, in _get_hostport
raise InvalidURL(nonnumeric port: '%s' % host[i+1:])
httplib.InvalidURL: nonnumeric port: 'a'
Note that from the error, it seems as if urllib2 is incorrectly parsing the
password from the proxy URL. When trying this with curl 7.19.7, I see the
proper behavior (the correct password is parsed from the proxy URL).
--
components: Library (Lib)
messages: 234809
nosy: Andy.Reitz
priority: normal
severity: normal
status: open
title: urllib2 fails for proxy credentials that contain a '/' character
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23328
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23328] urllib2 fails for proxy credentials that contain a '/' character
Andy Reitz added the comment:
Sorry, went a bit too quickly -- here is the sample code that I meant to use:
import os, urllib2
os.environ['http_proxy'] = http://someuser:a/b@10.11.12.13:1234;
f = urllib2.urlopen('http://www.python.org')
data = f.read()
print data
And the stack trace that I receive:
Traceback (most recent call last):
File test.py, line 3, in module
f = urllib2.urlopen('http://www.python.org')
File /usr/lib64/python2.7/urllib2.py, line 154, in urlopen
return opener.open(url, data, timeout)
File /usr/lib64/python2.7/urllib2.py, line 431, in open
response = self._open(req, data)
File /usr/lib64/python2.7/urllib2.py, line 449, in _open
'_open', req)
File /usr/lib64/python2.7/urllib2.py, line 409, in _call_chain
result = func(*args)
File /usr/lib64/python2.7/urllib2.py, line 1227, in http_open
return self.do_open(httplib.HTTPConnection, req)
File /usr/lib64/python2.7/urllib2.py, line 1166, in do_open
h = http_class(host, timeout=req.timeout, **http_conn_args)
File /usr/lib64/python2.7/httplib.py, line 712, in __init__
(self.host, self.port) = self._get_hostport(host, port)
File /usr/lib64/python2.7/httplib.py, line 754, in _get_hostport
raise InvalidURL(nonnumeric port: '%s' % host[i+1:])
httplib.InvalidURL: nonnumeric port: 'a'
It actually looks the same -- so I suppose this issue affects both urllib and
urllib2.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23328
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: This breaks custom actions. e.g.: class dict_action(argparse.Action): def __init__(self, *a, **k): argparse.Action.__init__(self, *a, **k) TypeError: __init__() got an unexpected keyword argument 'allow_abbrev' -- nosy: +xobes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: Ignore previous comment, I wish I could delete it. I simply provided the allow_abbrev to the wrong function and spent zero time investigating the error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have posted v12 of the patch, which addresses all comments since v11. This Python 3.4 patch can be applied to the default (3.5 dev) branch as well. I will start working on a similar patch for Python 2.7 now. -- Added file: http://bugs.python.org/file36978/issue12067-expressions-py34_v12.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I have addressed the comments by Jim Jewett, Martin Panter and of myself in a new version v11, which got posted. For the expression.rst doc file, this version of the patch has its diff sections in a logical order, so that the original text and the patched text are close by each other. Please review. -- Added file: http://bugs.python.org/file36920/issue12067-expressions-py34_v11.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: I also made sure in both files that the line length of any changed or new lines is max 80. Sorry if that creates extra changes when looking at deltas between change sets. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: @Guido: Agree to all you said in your #msg226496. There is additional information about comparison in: - Tutorial (5.8. Comparing Sequences and Other Types), - Library Reference (5.3. Comparisons), - Language Reference (3.3.1. Basic customization) that needs to be reviewed in light of this patch. I'm just not sure I want to make this patch even larger as it is already, and tend to do that in a follow on issue and patch (unless directed otherwise). Andy -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22001] containers same does not always mean __eq__.
Andy Maier added the comment: I reviewed the issues discussed here and believe that the patch for #Issue 12067 adresses all of them (and yes, it is large, unfortunately). It became large because I think that more needed to be fixed. May I suggest to review that patch. Andy -- nosy: +andymaier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Uploading v10 of the patch, which addresses all review comments made on v9. There is one open question back to Martin Panter about which different types of byte sequences can be compared in Py 3.4. I also believe this patch addresses all of Issue 22001. Let me know if you find that that is not the case. If we continue to scope this patch to only the comparison chapter of the language reference, then I think we are done (see msg229229 about other places that need review and possibly updates). Please review the patch v10. -- Added file: http://bugs.python.org/file36896/issue12067-expressions-py34_v10.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Here is the delta between v9 and v10 of the patch, if people want to see just that. -- Added file: http://bugs.python.org/file36897/issue12067-expressions-py34_delta-v9-v10.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Andy Maier added the comment: Just wanted to say that i will continue working on this, working in the comments made so far... Andy -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
