[issue35515] Matrix operator star creates a false matrix
New submission from Arnaud : It seems that the definition of a matrix like this: a=[[0,0]]*4 does not create the matrix correctly by create 4 times the same pointer. After the matrix creation, a print(a) gives the following result: [[0, 0], [0, 0], [0, 0], [0, 0]] which looks normal print(type(a)) and print(type(a[1]) give also the correct result: list But when we try to change a matrix element: a[2][0]=1 print(a) gives a false result: [[1, 0], [1, 0], [1, 0], [1, 0]] When the matrix definition is done like this: a=[[0, 0], [0, 0], [0, 0], [0, 0]] the behavior is "as expected" a[2][0]=1 print(a) gives the correct result: [[0, 0], [0, 0], [1, 0], [0, 0]] -- components: Interpreter Core files: python_bugreport.py messages: 331955 nosy: [email protected] priority: normal severity: normal status: open title: Matrix operator star creates a false matrix type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: https://bugs.python.org/file48001/python_bugreport.py ___ Python tracker <https://bugs.python.org/issue35515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13026] Dis module - documentation of MAKE_FUNCTION
New submission from Arnaud Delobelle : The description of the opcode MAKE_FUNCTION in the dis module document is out of date. It still describes the 2.X version of the opcode: """ MAKE_FUNCTION(argc) Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc default parameters, which are found below TOS. """ According to http://hg.python.org/cpython/file/default/Python/ceval.c#l2684: 2684 int posdefaults = oparg & 0xff; 2685 int kwdefaults = (oparg>>8) & 0xff; 2686 int num_annotations = (oparg >> 16) & 0x7fff; So the documentation should read something like """ MAKE_FUNCTION(argc) Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc & 0xFF positional default parameters, (argc >> 8) & 0xFF keyword only default parameters, and (argc >> 16) & 0x7FFF parameter annotations which are push below TOS in this order. For each keyword only default, the name of the parameter is pushed just below its default value. On top of all the annotations, a tuple is pushed listing the parameter names for these annotations. """ -- assignee: docs@python components: Documentation messages: 144393 nosy: arno, docs@python, terry.reedy priority: normal severity: normal status: open title: Dis module - documentation of MAKE_FUNCTION versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13026] Dis module - documentation of MAKE_FUNCTION
Arnaud Delobelle added the comment: Yes, you are correct. Reading this again, I don't think I should have used the word "pushed" as it sounds like the effect of the opcode is to push stuff onto the stack, whereas I was only trying to describe what is on the stack just before the opcode is executed. -- ___ Python tracker <http://bugs.python.org/issue13026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13026] Dis module - documentation of MAKE_FUNCTION
Arnaud Delobelle added the comment: This reads a lot better. Perhaps change (with name and object in separate positions) to something like (with name just below object on the stack) -- ___ Python tracker <http://bugs.python.org/issue13026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Any news about applying these patches? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13373] Unexpected blocking call to multiprocessing.Queue.get with a timeout
New submission from Arnaud Ysmal : Using get(timeout=1) on a multiprocessing.Queue sometimes leads to a blocking get. It seems that there is no check whether the timeout has expired after acquiring the lock but before the time.time(), which can cause a call to poll() with a negative timeout. (patch attached) -- components: Library (Lib) files: multiprocessing_queues.patch keywords: patch messages: 147319 nosy: stacktic priority: normal severity: normal status: open title: Unexpected blocking call to multiprocessing.Queue.get with a timeout type: behavior Added file: http://bugs.python.org/file23638/multiprocessing_queues.patch ___ Python tracker <http://bugs.python.org/issue13373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Does the patch I attached fix your issue? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: It would definitely help if you could apply the patch for Python 2.7 manually on your local installation (after making a backup of course). You can just download the patch for Python 2.7 then (only the first part of the patch can be applied, the second part is for the test so it doesn't matter): # cd /usr/lib/python2.7/ # patch -b -p2 -i /PATH/TO/THE/PATCH Thanks much. -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: I have had a look at the issue more closely and my initial patch was not completely right as it didn't work properly with argparse_test.py despite all tests passing. Therefore, I have amended my patch to not check whether action.default was a basestring which didn't make sense at all, but check instead if action.default is None (action.default default value is None if not given to add_argument as far as I understand). I also added a test for the issue reported above as it was missing and ran patchcheck to make sure everything was fine. All the tests (include argparse_test.py) passes without problem. Could you please apply them? Many thanks. -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23775/py2.7-argparse-call-type-function-once-v3.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23776/py3k-argparse-call-type-function-once-v3.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: BTW, about argparse_test, the default should be either '0' or 0 but not '\t' AFAIK because even the default value is converted using the given type function. It fails even with the last 2.7 version but it works well with my patch... -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment:
> Could you add a test to verify that custom actions are still getting
> the converted values passed to their __call__? I suspect this may not
> be happening under the current patch - if that's the case, you may
> also need to add conversions in _get_values, where the lines look like
> "value = action.default".
There seems to be already a test for that, namely TestActionUserDefined,
which use type=float and type=int. The value is properly converted to
{int,float} when passed to __call__(). Just in case, I also tested with
a 'type' function I defined myself (which only returns float()) for
OptionalAction and it's working fine.
> Also, "action.default == getattr(namespace, action.dest)" should
> probably use "is" instead of "==".
Good point, it would be much better. Thanks for the advice. I have just
modified the patch with that.
--
___
Python tracker
<http://bugs.python.org/issue12776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23972/py2.7-argparse-call-type-function-once-v4.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23973/py3k-argparse-call-type-function-once-v4.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13522] Document error return values for PyFloat_* and PyComplex_*
Arnaud Calmettes added the comment: Hi, Here is the patch I propose for this issue. This is my first attempt to contribute to Python, so please don't hit me too hard if I did something wrong. :) When browsing the source code of complexobject.c, I also noticed that the return values of the _Py_c_quot and _Py_c_pow (which return zero in case of error) weren't documented at http://docs.python.org/dev/c-api/complex.html#_Py_c_quot -- nosy: +arnaudc Added file: http://bugs.python.org/file24007/patch ___ Python tracker <http://bugs.python.org/issue13522> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13522] Document error return values for PyFloat_* and PyComplex_*
Arnaud Calmettes added the comment: I fixed the typo and the markup. -- Added file: http://bugs.python.org/file24009/patch ___ Python tracker <http://bugs.python.org/issue13522> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13522] Document error return values for PyFloat_* and PyComplex_*
Arnaud Calmettes added the comment: Fixed. -- Added file: http://bugs.python.org/file24014/diff_complex_rst ___ Python tracker <http://bugs.python.org/issue13522> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13522] Document error return values for PyFloat_* and PyComplex_*
Arnaud Calmettes added the comment: Previous patch was also wrong, sorry! -- keywords: +patch Added file: http://bugs.python.org/file24015/complex.rst-2.patch ___ Python tracker <http://bugs.python.org/issue13522> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13617] Reject embedded null characters in wchar* strings
Arnaud Calmettes added the comment: Here is a patch for the documentation. I added warnings for, PyUnicode_AsWideChar*, PyUnicode_EncodeFSDefault and PyUnicode_AsUnicode*, since they're all concerned by this issue. -- nosy: +arnaudc Added file: http://bugs.python.org/file24034/doc_unicode.patch ___ Python tracker <http://bugs.python.org/issue13617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13617] Reject embedded null characters in wchar* strings
Arnaud Calmettes added the comment: I removed the hints "using wcslen on the result of PyUnicode_AsWideChar*", since the resulting wchar_t strings may not be null-terminated -- Added file: http://bugs.python.org/file24037/doc_unicode-2.patch ___ Python tracker <http://bugs.python.org/issue13617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13620] Support Chrome in webbrowser.py
Arnaud Calmettes added the comment: Hi. The patch works fine on my box with Chromium 16 under Archlinux. However, I think it might not work under Ubuntu or Debian, since the program is named "chromium-browser" on these distros, and it is missing from the list of tested browser. I am setting up an Ubuntu box to test and confirm this. -- nosy: +arnaudc ___ Python tracker <http://bugs.python.org/issue13620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13620] Support Chrome in webbrowser.py
Arnaud Calmettes added the comment: The new patch works under Ubuntu but not not under Archlinux anymore (where the program is named "chromium"). Here is a patch that works with python 3.3 under both distributions. -- Added file: http://bugs.python.org/file24056/webbrowser.py-2.patch ___ Python tracker <http://bugs.python.org/issue13620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13620] Support Chrome in webbrowser.py
Arnaud Calmettes added the comment: Here is a patch against the 3.3 documentation, mentionning the new supported browser types. -- Added file: http://bugs.python.org/file24057/webbrowser_doc.patch ___ Python tracker <http://bugs.python.org/issue13620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
New submission from Arnaud Fontaine : When specifying a function to be called in type keyword argument of add_argument(), the function is actually called twice (when a default value is set and then when the argument is given). While this may not be a problem in most cases (such as converting to an int for example), it is an issue for example when trying to open a file whose filename is given as a default value but is not accessible for whatever reason because the first call will fail whereas only the second should be done. I know this may sound like a twisted example but the type function should not be called twice anyhow IMHO. I tested with Python 2.7 and 3.2 from Debian packages only but the bug seems to be present in py3k and 2.7 hg branches as well. I have attached a small script showing the issue and two patches (for 2.7 and tip (py3k) hg branches), including an additional test case. All argparse tests pass well with 2.7 and 3.2. Hope that's ok. -- components: Library (Lib) files: example-argparse-type-function-called-twice.py messages: 142306 nosy: arnau priority: normal severity: normal status: open title: argparse: type conversion function should be called only once type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22926/example-argparse-type-function-called-twice.py ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : -- keywords: +patch Added file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment:
Thanks for the review. Sorry to send that here instead of the review page, but
I get an error when replying: "Invalid XSRF token.".
> This looks good, especially if all existing tests still pass as you report,
> but
> I wonder about one thing: you have removed the part where the conversion
> function was applied to the default value, so I expected you to edit the other
> line were the conversion function was already called, but that’s not the
> case.
> Am I misunderstanding something?
Yes, sorry, I should have perhaps explained it in further details... Here are
some examples:
* Example test case 1:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('--foo bar'.split())
=> Before the patch, type function is called in parse_known_args() for the
default given in add_argument(), and then in _parse_known_args() for '--foo
bar' given in parse_args above, whereas type function should have been called
only for the second one.
* Example test case 2:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func)
parser.parse_args('--foo bar'.split())
=> This was already working well before my patch.
* Example test case 3:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('')
=> type_foo_func is called after parsing arguments (none in this case) in my
patch.
Therefore, my patch just moves the function type call after parsing the
arguments (given to parse_args()) instead of before, only and only if it was
not previously given in parse_args().
> http://bugs.python.org/review/12776/diff/3181/9898#newcode1985
> Lib/argparse.py:1985: if hasattr(namespace, action.dest) and \
> It is recommended to use parens to group multi-line statements, backslashes
> are
> error-prone.
I have just updated the patch on the bug report. Thanks.
--
___
Python tracker
<http://bugs.python.org/issue12776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Removed file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Removed file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22978/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22979/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9717] operator module - "in place" operators documentation
New submission from Arnaud Delobelle : More detailed explanation of how in place operators work, and how they are related to the operator module iadd, isub, ... functions. Submitted following this message on python-list: http://mail.python.org/pipermail/python-list/2010-August/1254243.html -- assignee: d...@python components: Documentation files: operator_inplace.diff keywords: patch messages: 115237 nosy: arno, d...@python priority: normal severity: normal status: open title: operator module - "in place" operators documentation versions: Python 3.3 Added file: http://bugs.python.org/file18682/operator_inplace.diff ___ Python tracker <http://bugs.python.org/issue9717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9717] operator module - "in place" operators documentation
Arnaud Delobelle added the comment: Terry: I agree that augmented assignement should be described better in the language reference. I guess that would warrant opening another issue? However I tend to think that the term "in-place operation" is a good one. BTW: - the reference of "(See section Primaries for the syntax definitions for the last three symbols.)" is probably there to point to the definition of what can go on the left side of the augmented assignement symbol (what used to be called an "lvalue") - "With the exception of assigning to tuples ": this refers to the fact that whereas x, y, z = l is correct syntax, x, y, z += l isn't. Raymond: I agree that the operator doc would be clearer if better structured. So I put forward another patch to operator.rst, structuring it more clearly and providing a more detailed introduction to the "In-place operations" section, but not trying to detail the workings of augmented assignement in general. -- Added file: http://bugs.python.org/file18752/operator_structured.diff ___ Python tracker <http://bugs.python.org/issue9717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10017] pprint.pprint raises TypeError on dictionaries with user-defined types as keys
New submission from Arnaud Delobelle :
The pprint function in the python 3.1 pprint module fails when
printing a dictionary containing more than one item and with one item
being a user-defined type. It seems pprint tries to sort the keys but
fails, (maybe because calling __lt__ on a user-defined type doesn't
bind its first argument to 'self'? Looking into pprint.py would
probably yield the answer).
This seems related to issue 3976 but it was fixed in r76389 and
r76390. My example below fails in r79147. I'm not in a position to check more
recent revisions right now.
In Python 2.6, the following works fine:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pprint import pprint
>>> class A(object): pass
...
>>> pprint({A:1, 1:2})
{1: 2, : 1}
But in Python 3.1, it fails with the error below:
Python 3.1.2 (r312:79147, Apr 15 2010, 12:35:07)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pprint import pprint
>>> class A: pass
...
>>> pprint({A:1, 1:2})
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.1/pprint.py", line 55, in pprint
printer.pprint(object)
File "/usr/lib/python3.1/pprint.py", line 132, in pprint
self._format(object, self._stream, 0, 0, {}, 0)
File "/usr/lib/python3.1/pprint.py", line 155, in _format
rep = self._repr(object, context, level - 1)
File "/usr/lib/python3.1/pprint.py", line 242, in _repr
self._depth, level)
File "/usr/lib/python3.1/pprint.py", line 254, in format
return _safe_repr(object, context, maxlevels, level)
File "/usr/lib/python3.1/pprint.py", line 296, in _safe_repr
items = sorted(object.items(), key=_safe_tuple)
File "/usr/lib/python3.1/pprint.py", line 89, in __lt__
rv = self.obj.__lt__(other.obj)
TypeError: expected 1 arguments, got 0
--
components: Library (Lib)
messages: 117895
nosy: arno
priority: normal
severity: normal
status: open
title: pprint.pprint raises TypeError on dictionaries with user-defined types
as keys
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue10017>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3004] Bug in slice.indices()
New submission from Arnaud Bergeron <[EMAIL PROTECTED]>: When calling the indices method of a slice object with a negative stop larger in absolute value than the length passed, the returned stop value is always -1. It should be 0 when the step is positive. Current behavior: >>> slice(-10).indices(11) (0, 1, 1) >>> slice(-10).indices(10) (0, 0, 1) >>> slice(-10).indices(9) (0, -1, 1) >>> slice(-10).indices(8) (0, -1, 1) Expected behavior: >>> slice(-10).indices(11) (0, 1, 1) >>> slice(-10).indices(10) (0, 0, 1) >>> slice(-10).indices(9) (0, 0, 1) >>> slice(-10).indices(8) (0, 0, 1) The patch I submit trivially fixes this while preserving the expected -1 when the step is negative like in: >>> slice(None, -10, -1).indices(8) (7, -1, -1) This issue affects python 2.5 and 2.6 at least. I did not test with other versions. -- components: Interpreter Core files: slice.patch keywords: patch messages: 67506 nosy: anakha severity: normal status: open title: Bug in slice.indices() type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file10466/slice.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3004] Bug in slice.indices()
Arnaud Bergeron <[EMAIL PROTECTED]> added the comment: It's for code that I am developping. I developped a class to allow full slicing over iterators (like what islice does, but with negative indexes). When I have a positive step I just foward the call to isclice using slice.indices() to compute my limits. But with this behavior, I am forced to wrap the indices() call with a function that patches this case. I agree that for the common usage of computing the limits of a for loop it doesn't matter. But it is really surprising when you realise this behavior is what is causing these exceptions after having passed half a day trying to debug your code. In fact, I think this bug should really be more of a documentation bug and I should propose a patch to add clearer documentation to this method. But the fix proposed should also go in because: - it's trivial - it's better Documentation for the method will be submitted later tomorrow. Should I post another report or just attach it to this one? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3069] Let set.union and set.intersection accept multiple arguments
New submission from Arnaud Delobelle <[EMAIL PROTECTED]>: The patch allows the following syntax for s set/frozenset: * s.union(a, b, c,...) * s.update(a, b, c,...) * s.intersection(a, b, c,...) * s.intersection_update(a, b, c,...) By extension: * set.union(a, b, c,...) # provided a is a set/frozenset * ... Union is extended by iterative application of set_union_internal Intersection is optimized by sorting all sets/frozensets/dicts in increasing order of size and only iterating over elements in the smallest. This was discussed on python-ideas: http://groups.google.com/group/python- ideas/browse_thread/thread/945a6c989ab905a3/54defd5e62b9a2a6 -- components: Interpreter Core files: set_ui_varargs.diff keywords: patch messages: 67878 nosy: arno severity: normal status: open title: Let set.union and set.intersection accept multiple arguments type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10565/set_ui_varargs.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3069] Let set.union and set.intersection accept multiple arguments
Arnaud Delobelle <[EMAIL PROTECTED]> added the comment: I must have diffed my patch against the wrong revision then, because I haven't seen it. I had finished it last thursday, but have had a very hectic few days and only found a few minutes to send it this evening. Something must have gone wrong & the patch must be against last thursday's revision I guess. Anyway it doesn't matter too much as you have started making the changes and it's easy to isolate set_intersection, which is a whole new function, in the patch file. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3004] Bug in slice.indices()
Arnaud Bergeron <[EMAIL PROTECTED]> added the comment: Don't blame me for the delay, I have long days (yes, really up to 96 hours long :) As for the documentation patch, I'm not certain anymore about it. Unless I bloat the description to about one full screen worth of text, there will always be surprises for the user. And describing only one little part in detail feels inconsistent. So unless I'm just a really bad writer, I think the current doc could be left as-is. I'm still all for the attached patch. Comments anyone? Or does this needs more nagging? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3004] Bug in slice.indices()
Arnaud Bergeron <[EMAIL PROTECTED]> added the comment: Would these do? self.assertEqual(slice(None, -10).indices(10), (0, 0, 1)) self.assertEqual(slice(None, -11, ).indices(10), (0, 0, 1)) self.assertEqual(slice(None, -12, -1).indices(10), (9, -1, -1)) If yes, test_slice.patch adds them. Added file: http://bugs.python.org/file10653/test_slice.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
New submission from Arnaud Fontaine : For example, PyUnicode_FromFormat() does not specify the return value but it does not seem to be only one. I only have a basic knowledge of Python C/API, so I am not sure whether it is meaningful. -- assignee: georg.brandl components: Documentation messages: 101959 nosy: arnau, georg.brandl severity: normal status: open title: Missing return values for PyUnicode C/API functions type: feature request versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
Arnaud Fontaine added the comment: I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is most specified for most functions in Unicode Object (at least). -- ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
Arnaud Fontaine added the comment: I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is not specified for most functions in Unicode Object (at least). -- ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37956] UUID authorize version 6+ with variant RFC 4122
New submission from mael arnaud :
The docs stipulates:
UUID.version
The UUID version number (1 through 5, meaningful only when the variant is
RFC_4122).
But you can absolutely do:
>>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464")
which yields:
>>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464").variant
'specified in RFC 4122'
>>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464").version
11
Since versions above 5 are not defined in the RFC 4122, is it relevant to allow
such UUIDs to exist?
Every other tool on the internet seem to reject them (but I guess they are
regex based). At the very least, maybe the docs should mention something about
it, since I'm not sure anyone expects a UUID to be valid and have a version
above 5?
--
components: Library (Lib)
messages: 350546
nosy: Erawpalassalg
priority: normal
severity: normal
status: open
title: UUID authorize version 6+ with variant RFC 4122
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37956>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37633] Py_CompileString and PyParser_SimpleParseString not exported in python38.dll
Arnaud Diederen added the comment: Python 3.8 was released yesterday, but this issue was unfortunately not addressed, making it as an embedded runtime. Are there plans to fix this for a minor 3.8 release? Thanks! -- nosy: +Arnaud Diederen ___ Python tracker <https://bugs.python.org/issue37633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: ping? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Could you please apply this patch? It's been 4 months without reply now... -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18047] Descriptors get invoked in old-style objects and classes
Arnaud Porterie added the comment: Sorry if I am missing something, but it seems that the documentation doesn't match the behavior: the doc says that descriptors are invoked only for new styles objects and classes, while the attached code seems to prove the contrary. If my understanding is correct, either the doc or the code should be changed accordingly. -- ___ Python tracker <http://bugs.python.org/issue18047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19497] selectors and modify()
Changes by Arnaud Faure : -- files: modify_data.patch keywords: patch nosy: Arnaud.Faure priority: normal severity: normal status: open title: selectors and modify() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file32499/modify_data.patch ___ Python tracker <http://bugs.python.org/issue19497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19497] selectors and modify()
Arnaud Faure added the comment: Didn't thaught about that :( Did my way throught the developper tutorial, got the default cpython repo, did the modif, run patchcheck then the tests with ./python -m test -j3. Thanks for your patience ;) -- Added file: http://bugs.python.org/file32503/modify_data.2.patch ___ Python tracker <http://bugs.python.org/issue19497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19497] selectors and modify()
Arnaud Faure added the comment: patch updated -- Added file: http://bugs.python.org/file32504/modify_data.3.patch ___ Python tracker <http://bugs.python.org/issue19497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19497] selectors and modify()
Arnaud Faure added the comment: Corrected and cleaned -- Added file: http://bugs.python.org/file32512/modify_data_use_a_shortcut.patch ___ Python tracker <http://bugs.python.org/issue19497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21308] PEP 466: backport ssl changes
Arnaud Fontaine added the comment: Would it be possible to also backport the changes to httplib.py to support TLS SNI as many libraries (including setuptools) relies on this module to download files and some servers reject clients not supporting TLS SNI (such as cloud.github.com)? I have added a patch for Python 2.7.8. Thanks for working on the backports of SSL changes! -- nosy: +arnau Added file: http://bugs.python.org/file36174/tls_sni_httplib.patch ___ Python tracker <http://bugs.python.org/issue21308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20613] Wrong line information in bytecode generated by compiler module
New submission from Arnaud Fontaine: I know that compiler module is deprecated since 2.6, but I found a regression introduced in version 2.7 by the following cleanup commit (replacing pyassem.py modified in this commit by the one just before does not trigger this bug): http://hg.python.org/releasing/2.7.6/rev/42faa8054c3d Actually, there is nothing wrong when executing the generated bytecode, it's just that tracebacks and anything that display source code from the generated bytecode object gets sometimes completely wrong when there is if/elif/else because of compiler.pyassem.order_blocks(). This issue was found when noticing that tracebacks in Zope Python Script (using RestrictedPython which in turn uses compiler module) were displaying completely wrong line information and stepping with pdb into the source code was displaying wrong source code and line information too. After investigating, I found out that the problem is actually in compiler module and wrote a small program triggering the bug (I know that some variables are undefined but it does not matter here): if if1: if1_entered = 1 if if2: if subif1: subif1_entered = 1 elif subif2: subif2_entered = 1 subif_ended = 1 Using compiler module to generate the bytecode with the program attached returns two different bytecodes: $ python2.7 compiler_wrong_ordering_block_test.py 1 0 LOAD_NAME0 (if1) 3 POP_JUMP_IF_FALSE 30 2 6 LOAD_CONST 1 (1) 9 STORE_NAME 1 (if1_entered) 12 JUMP_FORWARD15 (to 30) 7 >> 15 LOAD_NAME2 (subif2) 18 POP_JUMP_IF_FALSE 51 8 21 LOAD_CONST 1 (1) 24 STORE_NAME 3 (subif2_entered) 27 JUMP_FORWARD21 (to 51) >> 30 LOAD_NAME4 (if2) 33 POP_JUMP_IF_FALSE 60 36 LOAD_NAME5 (subif1) 39 POP_JUMP_IF_FALSE 15 42 LOAD_CONST 1 (1) 45 STORE_NAME 6 (subif1_entered) 48 JUMP_FORWARD 0 (to 51) 10 >> 51 LOAD_CONST 1 (1) 54 STORE_NAME 7 (subif_ended) 57 JUMP_FORWARD 0 (to 60) >> 60 LOAD_CONST 0 (None) 63 RETURN_VALUE 1 0 LOAD_NAME0 (if1) 3 POP_JUMP_IF_FALSE 15 2 6 LOAD_CONST 1 (1) 9 STORE_NAME 1 (if1_entered) 12 JUMP_FORWARD 0 (to 15) 4 >> 15 LOAD_NAME2 (if2) 18 POP_JUMP_IF_FALSE 60 5 21 LOAD_NAME3 (subif1) 24 POP_JUMP_IF_FALSE 36 6 27 LOAD_CONST 1 (1) 30 STORE_NAME 4 (subif1_entered) 33 JUMP_FORWARD15 (to 51) 7 >> 36 LOAD_NAME5 (subif2) 39 POP_JUMP_IF_FALSE 51 8 42 LOAD_CONST 1 (1) 45 STORE_NAME 6 (subif2_entered) 48 JUMP_FORWARD 0 (to 51) 10 >> 51 LOAD_CONST 1 (1) 54 STORE_NAME 7 (subif_ended) 57 JUMP_FORWARD 0 (to 60) >> 60 LOAD_CONST 0 (None) 63 RETURN_VALUE As you can see from the output above, the first generated bytecode gets all the line numbers (lnotab) messed up because 'subif2' block (and its children too) is emitted *before* its 'dominator' block, namely 'if2'. Now, compiler.pyassem.order_blocks() arranges blocks to be emitted within a 'dominators' dict where the key is a block and the value a list of blocks which must be emitted *before* that one. However, for at least 'if/elif' blocks (created by compiler.pycodegen.CodeGenerator().visitIf()), the 'elif' block (subif2) does not have prev/next (where prev and next define respectively the parent and children blocks) sets to its parent (if2) as it is only set for the first 'if' (subif1) and furthermore for some reasons I don't know the code asserts that next list length must be equal to 1 anyway (anyone knows why BTW?)... Thus, when creating 'dominators' dict using next/prev block attributes, the 'elif' block (subif2) ends up being considered kind of an orphan block because next/prev is not set and thus could be emitted anytime... Enabling debug mode in compiler.pyassem and adding a print call in order_blocks() to display 'dominators' dict co
[issue18047] Descriptors get invoked in old-style objects and classes
New submission from Arnaud Porterie: In the Data Model section of the documentation regarding descriptors invokations (http://docs.python.org/2/reference/datamodel.html#invoking-descriptors), it is said: Note that descriptors are only invoked for new style objects or classes (ones that subclass object() or type()). However, it seems this restriction isn't enforced in practice: Python 2.7.4 (default, May 16 2013, 13:28:03) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Desc(object): ... def __get__(self, obj, cls): ... return 'test' ... >>> class A: # Not inheriting object here ... desc = Desc() ... >>> A().desc 'test' I dived into CPython's code and saw no trace of a test for new-style classes in the descriptor invokation code path (down in classobject.c / instance_getattr2). Unfortunately, fixing this behavior doesn't seem trivial as class methods appear to be implemented as descriptor themselves. In other words, and from my understanding, restricting descriptor invokation to new-style objects and classes would prevent method calls on old-style classes. -- components: Interpreter Core files: desc.py messages: 189896 nosy: icecrime priority: normal severity: normal status: open title: Descriptors get invoked in old-style objects and classes type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30356/desc.py ___ Python tracker <http://bugs.python.org/issue18047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23240] pip 6.0.6- pip install command is broken
New submission from arnaud gaboury:
gabx@hortensia ➤➤ ~ % pip3.4 install websocket-client
Exception:
Traceback (most recent call last):
File "/usr/lib/python3.4/site-packages/pip/basecommand.py", line 232, in main
status = self.run(options, args)
File "/usr/lib/python3.4/site-packages/pip/commands/install.py", line 339, in
run
requirement_set.prepare_files(finder)
File "/usr/lib/python3.4/site-packages/pip/req/req_set.py", line 229, in
prepare_files
req_to_install.check_if_exists()
File "/usr/lib/python3.4/site-packages/pip/req/req_install.py", line 928, in
check_if_exists
self.satisfied_by = pkg_resources.get_distribution(self.req)
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
461, in get_distribution
dist = get_provider(dist)
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
341, in get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
870, in require
needed = self.resolve(parse_requirements(requirements))
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
740, in resolve
env = Environment(self.entries)
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
927, in __init__
self.scan(search_path)
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
957, in scan
self.add(dist)
File
"/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line
977, in add
dists.sort(key=operator.attrgetter('hashcmp'), reverse=True)
TypeError: unorderable types: NoneType() < str()
-
gabx@hortensia ➤➤ ~ % pip list
aiohttp (0.9.1)
apparmor (2.9.1)
appdirs (1.3.0)
.
--
gabx@hortensia ➤➤ ~ % pip show six
---
Name: six
Version: 1.9.0
Location: /usr/lib/python3.4/site-packages
Requires:
--
gabx@hortensia ➤➤ ~ % pip install ranger
Requirement already satisfied (use --upgrade to upgrade): ranger in
/usr/lib/python3.4/site-packages
--
pip install seems broken when installing a new package.
--
components: Distutils
messages: 234021
nosy: dstufft, eric.araujo, gabx
priority: normal
severity: normal
status: open
title: pip 6.0.6- pip install command is broken
type: crash
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue23240>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25824] 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll
New submission from Arnaud Diederen: [First of all let me say I'm not all that familiar with Windows, so please let me know if the wording in my analysis below is not clear and/or misleading.] It would appear the 32-bit installer for Python 2.7.11 creates the registry key: --- HKLM\Software\Wow6432Node\Python\PythonCore\2.7\PythonPath --- (...just like previous 2.7 versions did.) However, registry accesses (PC/getpathp.c's getpythonpath()) are done like so: --- (...) keyBuf = keyBufPtr = PyMem_RawMalloc(keyBufLen); if (keyBuf==NULL) goto done; memcpy_s(keyBufPtr, keyBufLen, keyPrefix, sizeof(keyPrefix)-sizeof(WCHAR)); keyBufPtr += Py_ARRAY_LENGTH(keyPrefix) - 1; mbstowcs(keyBufPtr, PyWin_DLLVersionString, versionLen); (...) --- where 'PyWin_DLLVersionString' now is "2.7-32": --- .rsrc:1E2760FA unicode 0, <2.7-32>,0 --- (it used to be "2.7" in previous versions) Thus, the key that python27.dll builds is: HKLM\Software\Wow6432Node\Python\PythonCore\2.7-32\PythonPath and not HKLM\Software\Wow6432Node\Python\PythonCore\2.7\PythonPath and consequently the runtime cannot build a proper sys.path, which causes embedded interpreters to fail loading core modules. As a workaround, it seems renaming the registry key to its "-32"-suffixed name, does help. -- components: Installation messages: 256113 nosy: aundro priority: normal severity: normal status: open title: 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20613] Wrong line information in bytecode generated by compiler module
Arnaud Fontaine added the comment: compiler module being deprecated does not mean that it's not used. For example, it is used by RestrictedPython as part of Zope2. As I could not figure out a way to fix this bug properly, I reverted the following commit and have not had any problem so far (nor my colleagues): https://hg.python.org/cpython/raw-rev/42faa8054c3d I have attached the reverted patch to this bug report in case of. -- keywords: +patch Added file: http://bugs.python.org/file38418/fix_compiler_module_issue_20613.patch ___ Python tracker <http://bugs.python.org/issue20613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36207] robotsparser deny all with some rules
Arnaud LIPERINI-DIAZ added the comment: Do you have documentation about robotParser ? The robot.txt of this website works fine : https://vauros.com/ -- nosy: +Arnaud LIPERINI-DIAZ ___ Python tracker <https://bugs.python.org/issue36207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
