[issue19067] Built-in range docstrings are not PEP-8 compatible
New submission from Marco Buttu: The range documentation is not PEP-8 compatible: range.__doc__.splitlines()[-1] 'Returns a virtual sequence of numbers from start to stop by step.' range.__reversed__.__doc__ 'Returns a reverse iterator.' range.index.__doc__.splitlines()[-1] 'Raises ValueError if the value is not present.' They should have been 'Return...' and 'Raise...'. Patch is attached -- assignee: docs@python components: Documentation files: rangeobject.patch keywords: patch messages: 198244 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Built-in range docstrings are not PEP-8 compatible type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31838/rangeobject.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19068] Some built-in complex docstrings are not PEP-8 compatible
New submission from Marco Buttu: As reported in the title: complex.conjugate.__doc__.splitlines()[-1] 'Returns the complex conjugate of its argument. (3-4j).conjugate() == 3+4j.' complex.__format__.__doc__.splitlines()[-1] 'Converts to a string according to format_spec.' They should have been 'Return...' and 'Convert...'. Patch is attached -- assignee: docs@python components: Documentation files: complexobject.patch keywords: patch messages: 198245 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Some built-in complex docstrings are not PEP-8 compatible versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31839/complexobject.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19068] Some built-in complex docstrings are not PEP-8 compatible
Changes by Marco Buttu marco.bu...@gmail.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19069] Built-in float docstrings are not PEP-8 compatible
New submission from Marco Buttu: As reported in the title: float.as_integer_ratio.__doc__.splitlines()[2] 'Returns a pair of integers, whose ratio is exactly equal to the original' float.as_integer_ratio.__doc__.splitlines()[4] 'Raises OverflowError on infinities and a ValueError on NaNs.' float.conjugate.__doc__ 'Returns self, the complex conjugate of any float.' float.is_integer.__doc__ 'Returns True if the float is an integer.' float.__setformat__.__doc__.splitlines()[-2] 'Overrides the automatic determination of C-level floating point type.' ... They should have been 'Return...', 'Raise...' and 'Override...' Patch is attached -- assignee: docs@python components: Documentation files: floatobject.patch keywords: patch messages: 198246 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Built-in float docstrings are not PEP-8 compatible type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31840/floatobject.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19069 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19021] AttributeError in Popen.__del__
Terry J. Reedy added the comment: When the patch to #12085 is changed, as has been agreed, I think, this issue should go away. Moving the deletion of builtins to later in the shutdown process has be discussed and maybe implemented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19001] test_gdb fails on Fedora buildbot
Nick Coghlan added the comment: My F19 system (which works) shows gdb-7.6-34, while the new debugging output Antoine added shows 7.3.50.20110722-16.fc16 on F16 Maybe the new gdb version check needs to be looking for 7.4+ rather than 7.3+? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19001] test_gdb fails on Fedora buildbot
Nick Coghlan added the comment: Hmm, I also noticed some issues with 2.7/3.2 on the RHEL 6 buildbot (similar to those previously reported in issue 15043). I'll keep tinkering with it. -- keywords: +buildbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
Georg Brandl added the comment: Using the warning directive can be backported from the 3.x docs. For 3.x, it's already prominent enough. Your screen border is not everyone's screen border. -- nosy: +georg.brandl versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
anatoly techtonik added the comment: The scope of warning is wrong. It is not a warning for open() call, and that's why it is easy to miss. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
Roundup Robot added the comment: New changeset 1d850260a356 by Georg Brandl in branch '2.7': Closes #19061: make shelve security warning consistent between 2.x and 3.x. http://hg.python.org/cpython/rev/1d850260a356 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
Georg Brandl added the comment: Oh, please. It's big and red and directly below the open() description, how could you miss it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19001] test_gdb fails on Fedora buildbot
Nick Coghlan added the comment: Looks like the RHEL 6 failures may have just been a change on the OS side that reintroduced the need for this old workaround: http://docs.python.org/devguide/faq.html#how-do-i-update-my-auto-load-safe-path-to-allow-test-gdb-to-run I restored that FAQ, applied the config change on the buildbot and fixed the 2.7 branch to skip rather than fail (as it was previously supposed to, but the line that actually did the skip was lost in a backport from 3.x somewhere along the line). -- nosy: +bkabrda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19043] Remove detailed listing of all versions from LICENSE, Doc/license.rst
Roundup Robot added the comment: New changeset 7a8616f21f26 by Georg Brandl in branch '2.7': Closes #19043: remove detailed listing of versions from license files http://hg.python.org/cpython/rev/7a8616f21f26 -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19043] Remove detailed listing of all versions from LICENSE, Doc/license.rst
Roundup Robot added the comment: New changeset 59b6c3280827 by Georg Brandl in branch '3.3': Closes #19043: remove detailed listing of versions from license files http://hg.python.org/cpython/rev/59b6c3280827 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19070] In place operators of weakref.proxy() not returning self.
New submission from Graham Dumpleton:
When a weakref.proxy() is used to wrap a class instance which implements in
place operators, when one applies the in place operator to the proxy, one could
argue the variable holding the proxy should still be a reference to the proxy
after the in place operator has been done. Instead the variable is replaced
with the class instance the proxy was wrapping.
So for the code:
from __future__ import print_function
import weakref
class Class(object):
def __init__(self, value):
self.value = value
def __iadd__(self, value):
self.value += value
return self
c = Class(1)
p = weakref.proxy(c)
print('p.value', p.value)
print('type(p)', type(p))
p += 1
print('p.value', p.value)
print('type(p)', type(p))
one gets:
$ python3.3 weakproxytest.py
p.value 1
type(p) class 'weakproxy'
p.value 2
type(p) class '__main__.Class'
One might expect type(p) at the end to still be class 'weakproxy'.
In the weakref.proxy() C code, all the operators are set up with preprocessor
macros.
#define WRAP_BINARY(method, generic) \
static PyObject * \
method(PyObject *x, PyObject *y) { \
UNWRAP(x); \
UNWRAP(y); \
return generic(x, y); \
}
#define WRAP_TERNARY(method, generic) \
static PyObject * \
method(PyObject *proxy, PyObject *v, PyObject *w) { \
UNWRAP(proxy); \
UNWRAP(v); \
if (w != NULL) \
UNWRAP(w); \
return generic(proxy, v, w); \
}
These are fine for:
WRAP_BINARY(proxy_add, PyNumber_Add)
WRAP_BINARY(proxy_sub, PyNumber_Subtract)
WRAP_BINARY(proxy_mul, PyNumber_Multiply)
WRAP_BINARY(proxy_div, PyNumber_Divide)
WRAP_BINARY(proxy_floor_div, PyNumber_FloorDivide)
WRAP_BINARY(proxy_true_div, PyNumber_TrueDivide)
WRAP_BINARY(proxy_mod, PyNumber_Remainder)
WRAP_BINARY(proxy_divmod, PyNumber_Divmod)
WRAP_TERNARY(proxy_pow, PyNumber_Power)
WRAP_BINARY(proxy_lshift, PyNumber_Lshift)
WRAP_BINARY(proxy_rshift, PyNumber_Rshift)
WRAP_BINARY(proxy_and, PyNumber_And)
WRAP_BINARY(proxy_xor, PyNumber_Xor)
WRAP_BINARY(proxy_or, PyNumber_Or)
Because a result is being returned and the original is not modified.
Use of those macros gives the unexpected result for:
WRAP_BINARY(proxy_iadd, PyNumber_InPlaceAdd)
WRAP_BINARY(proxy_isub, PyNumber_InPlaceSubtract)
WRAP_BINARY(proxy_imul, PyNumber_InPlaceMultiply)
WRAP_BINARY(proxy_idiv, PyNumber_InPlaceDivide)
WRAP_BINARY(proxy_ifloor_div, PyNumber_InPlaceFloorDivide)
WRAP_BINARY(proxy_itrue_div, PyNumber_InPlaceTrueDivide)
WRAP_BINARY(proxy_imod, PyNumber_InPlaceRemainder)
WRAP_TERNARY(proxy_ipow, PyNumber_InPlacePower)
WRAP_BINARY(proxy_ilshift, PyNumber_InPlaceLshift)
WRAP_BINARY(proxy_irshift, PyNumber_InPlaceRshift)
WRAP_BINARY(proxy_iand, PyNumber_InPlaceAnd)
WRAP_BINARY(proxy_ixor, PyNumber_InPlaceXor)
WRAP_BINARY(proxy_ior, PyNumber_InPlaceOr)
This is because the macro returns the result from the API call, such as
PyNumber_InPlaceAdd() where as it should notionally be returning 'proxy' so
that the variable holding the weakref proxy instance is set to the proxy object
again and not the result of the inner API call.
In changing this though there is a complication which one would have to deal
with.
If the result of the inner API call such as PyNumber_InPlaceAdd() is the same
as the original object wrapped by the weakref proxy, then all is fine.
What though should be done if it is different as notionally this means that the
reference to the wrapped object would need to be changed to the new value.
The issue is that if one had to replace the reference to the wrapped object
with a different one due to the in place operator, then notionally the whole
existence of that weakref is invalidated as you would no longer be tracking the
same object the weakref proxy was created for.
This odd situation is perhaps why the code was originally written the way it
was, although that then sees the weakref proxy being replaced which could cause
different problems with the callback not later being called since the weakref
proxy can be destroyed before the object it wrapped. As there is nothing in the
documentation of the code which calls out such a decision, not sure if it was
deliberate or simply an oversight.
Overall I am not completely sure what the answer should be, so I am logging it
as interesting behaviour. Maybe this odd case needs to be called out in the
documentation in some way at least. That or in place operators simply shouldn't
be allowed on a weakref proxy because of the issues it can cause either way.
--
components: Library (Lib)
messages: 198257
nosy: grahamd
priority: normal
severity: normal
status: open
title: In place operators of weakref.proxy() not returning self.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19070
___
[issue19070] In place operators of weakref.proxy() not returning self.
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +ncoghlan, tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19070 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
anatoly techtonik added the comment: On Sun, Sep 22, 2013 at 12:42 PM, Georg Brandl rep...@bugs.python.orgwrote: Oh, please. It's big and red and directly below the open() description, how could you miss it? I believe that it is pretty easy with mobile browser due to screen constraints. Can you test this on your mobile devices? As for your argument about my border not being everyone's border, I believe that my border accounts for 18%+ of browser market share. http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-201308-201308-bar I would be even more interested to see docs.python.org stats, which may be more, because reading docs from tablet is more convenient, or less, because there tables are not good development platforms for Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
Georg Brandl added the comment: I believe that it is pretty easy with mobile browser due to screen constraints. Can you test this on your mobile devices? Sorry, but we don't adapt the docs *content* to any specific device. You should never only read just a screenful in any case. This is technical documentation, not a news article! If you believe that you can improve the docs *design* (the CSS, mainly) to work better on mobile devices, be my guest! There are certainly optimization opportunities, but that never relieves you of making sure you read the whole content that's relevant to you. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19024] Document asterisk (*), splat or star operator
anatoly techtonik added the comment: 223 people + me out of 1422 disagree with you both. http://stackoverflow.com/questions/101268/hidden-features-of-python -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19024] Document asterisk (*), splat or star operator
anatoly techtonik added the comment: To narrow the point of conflict, I say that argument unpacking *operators* should have a prominent place in Python documentation that people can link to. Current page http://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists is about functionality, not about operators, and therefore usage of these while studying Python code can not be tracked back to documentation. Which is why it is hidden. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19070] In place operators of weakref.proxy() not returning self.
Nick Coghlan added the comment: Ouch :P Perhaps the least-incompatible fix would be to switch to returning the proxy if the object returned is the proxied object (which would do the right thing for proxies to mutable objects), while preserving the current behaviour when the in-place operation returns a new object? That behaviour is still somewhat broken, but there's no obviously non-broken behaviour in that case, and this broadly preserves compatibility with the status quo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19070 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19047] Assorted weakref docs improvements
Roundup Robot added the comment: New changeset caa16423b324 by Nick Coghlan in branch 'default': Close #19047: weakref doc cleanups http://hg.python.org/cpython/rev/caa16423b324 -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19047 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19021] AttributeError in Popen.__del__
Oleg Oshmyan added the comment: But the thing is, builtins are already supposed to be the very last thing destroyed at shutdown. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19071] Documentation on what self is for module-level functions is misleading/wrong.
New submission from Graham Dumpleton:
In the documentation for Python 2.X at:
http://docs.python.org/2/extending/extending.html#a-simple-example
it says:
The self argument points to the module object for module-level functions; for a
method it would point to the object instance.
In respect of module-level functions this is misleading or arguably wrong.
If one uses Py_InitModule() or Py_InitModule3(), then self is actually passed
through as NULL for module-level functions in Python 2.
There is a caveat on use of Py_InitModule4() which used to be mentioned in
documentation for Python 2.6 at:
http://docs.python.org/release/2.6.7/c-api/structures.html#METH_VARARGS
where it says:
This is the typical calling convention, where the methods have the type
PyCFunction. The function expects two PyObject* values. The first one is the
self object for methods; for module functions, it has the value given to
Py_InitModule4() (or NULL if Py_InitModule() was used).
Although one can supply a special argument to Py_InitModule4() which will be
supplied as self, this still isn't the module object and in fact the module
object for the module will not even exist at the point Py_InitModule4() is
called so it is not possible to pass it in. Plus within the init function of an
extension, the module object is not that which would end up being used in a
specific interpreter due to how the init function is only called once and a
copy then made of the module for each interpreter.
This actual page in the documentation was changed in Python 2.7 and now in:
http://docs.python.org/2/c-api/structures.html#METH_VARARGS
says:
The function expects two PyObject* values. The first one is the self object for
methods; for module functions, it is the module object.
So the reference to Py_InitModule4() was removed and simply says that module
object is supplied, which isn't actually the case.
Now, that NULL is always passed for Py_InitModule() and Py_InitModule3() is the
case with Python 2. In Python 3 at some point, the code in Python internals was
changed so the module object is actually passed as documented.
So, maybe the intent was that when in Python 3 the code was changed to pass the
module object to module-level functions that it be back ported to Python 2.7
and the documentation so changed, but looks like that back porting was never
done, or if it was, it has been broken somewhere along the way.
Code used to verify this is all attached.
If compiled and installed for Python 3 one gets:
import mymodule._extension
id(mymodule._extension)
4480540328
mymodule._extension.function()
module 'mymodule._extension' from
'/Users/graham/Projects/python-c-extension-template/lib/python3.3/site-packages/mymodule/_extension.so'
id(mymodule._extension.function())
4480540328
If compiled and installed for Python 2.7 one gets:
import mymodule._extension
id(mymodule._extension)
4554745960
mymodule._extension.function()
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: no module supplied for self
The function in the extension module was doing:
static PyObject *extension_function(PyObject *self, PyObject *args)
{
if (!self) {
PyErr_SetString(PyExc_TypeError, no module supplied for self);
return NULL;
}
Py_INCREF(self);
return self;
}
--
assignee: docs@python
components: Documentation
files: example.tar
messages: 198265
nosy: docs@python, grahamd
priority: normal
severity: normal
status: open
title: Documentation on what self is for module-level functions is
misleading/wrong.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31841/example.tar
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19071
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
anatoly techtonik added the comment: On Sun, Sep 22, 2013 at 2:11 PM, Georg Brandl rep...@bugs.python.orgwrote: Georg Brandl added the comment: I believe that it is pretty easy with mobile browser due to screen constraints. Can you test this on your mobile devices? Sorry, but we don't adapt the docs *content* to any specific device. You should never only read just a screenful in any case. This is technical documentation, not a news article! I am sorry, but you're misplacing arguments. It looks like this: me[1] open() function description is a wrong place for warning that is related to a whole module you[2] common, it is visible, that's the point anyway me[3] it is not visible on mobile you[4] we do not support mobile [3] makes your point [2] invalid. And your point [4] doesn't apply as an answer to [1]. Now my arguments are: 1. Warning is located in the wrong place (bug is trivial, not important) 2. Wrong place causes problems with mobiles (trivial, somewhat matters) And you argument that users (or is it for me personally?) should never read only screenful for a module description is rather strange for the most of us. Why are things always in the last place you look for them? Because you stop looking when you find them. I highly recommend you to read this book - http://www.sensible.com/chapter.html - it's awesome. And just for amusement - http://uxmyths.com/post/647473628/myth-people-read-on-the-web If you believe that you can improve the docs *design* (the CSS, mainly) to work better on mobile devices, be my guest! There are certainly optimization opportunities, but that never relieves you of making sure you read the whole content that's relevant to you. There is nothing wrong with CSS or mobile design. There is an issue with the placement of this specific piece of information, which comes detached from the place (module description) where it belongs. Although the effect of this bug is partially with background workaround, the cause is still there. To make it more real scenario for you. In corporate environment somebody who issues a recommendation, is not necessarily the person who implements it. If you're implementing everything yourself, of course you won't miss the details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19024] Document asterisk (*), splat or star operator
Nick Coghlan added the comment: Unfortunately, there's currently no good place for this kind of detailed syntax reference documentation to go. The library reference doesn't cover syntax, the tutorial doesn't go into detailed semantics, and the language reference is written more for language implementors than it is for users. My Python User's Reference project (http://svn.python.org/view/sandbox/trunk/userref/README.txt?view=markup) was designed to fill that gap, but I never found the time to do the ReST conversion myself, and nobody ever expressed interest in helping out with it, so it's now five years out of date. Creating a cut down version of that as the Python Syntax Reference might be a reasonable approach. However, it's a project that could easily start life outside the core CPython repository. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19071] Documentation on what self is for module-level functions is misleading/wrong.
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +loewis, ncoghlan, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19071 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
Georg Brandl added the comment: me[1] open() function description is a wrong place for warning that is related to a whole module you[2] common, it is visible, that's the point anyway me[3] it is not visible on mobile you[4] we do not support mobile Your complaint was that it is located under screen border. My reply is that what the screen border is is highly device specific and that we don't cater to specific devices, therefore rejecting your complaint. I never said we don't support mobile. That's it for me and this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19065] sqlite3 timestamp adapter chokes on timezones
Antoine Pitrou added the comment: This would be an useful improvement. Do you want to post a patch? See guidelines at http://docs.python.org/devguide/ -- nosy: +belopolsky, ghaering, lemburg, pitrou stage: - needs patch type: - enhancement versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19065 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19061] Shelve documentation security warning is not visible
anatoly techtonik added the comment: On Sun, Sep 22, 2013 at 2:57 PM, Georg Brandl rep...@bugs.python.orgwrote: Georg Brandl added the comment: me[1] open() function description is a wrong place for warning that is related to a whole module you[2] common, it is visible, that's the point anyway me[3] it is not visible on mobile you[4] we do not support mobile Your complaint was that it is located under screen border. My reply is that what the screen border is is highly device specific and that we don't cater to specific devices, therefore rejecting your complaint. I never said we don't support mobile. That's it for me and this issue. Well, at least now you know how I read the replies. Glad we settled this down. Now it would be nice if somebody with CLA for docs could just move this block upper. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18553] os.isatty() is not Unix only
anatoly techtonik added the comment: I having a snippet to fix that, should I open a new issue for patch? Please open a new issue. Reference is welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18553 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18626] Make python -m inspect name meaningful
Roundup Robot added the comment: New changeset 2e1335245f8f by Nick Coghlan in branch 'default': Close #18626: add a basic CLI for the inspect module http://hg.python.org/cpython/rev/2e1335245f8f -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18626 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18626] Make python -m inspect name meaningful
Nick Coghlan added the comment: Thanks for the initial patch Claudiu - I tweaked it a bit before committing it. * as you suggested, displaying the source is the default, with a --details option to display the formatted info instead * changed the displayed details (e.g. only displaying the search path for packages, displaying the line number for classes and functions * a few tweaks to the actual implementation (e.g. using partition over find, avoiding tracebacks for a couple of likely user errors) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18626 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable
New submission from Graham Dumpleton:
The classmethod decorator when applied to a function of a class, does not
honour the descriptor binding protocol for whatever it wraps. This means it
will fail when applied around a function which has a decorator already applied
to it and where that decorator expects that the descriptor binding protocol is
executed in order to properly bind the function to the class.
A decorator may want to do this where it is implemented so as to be able to
determine automatically the context it is used in. That is, one magic decorator
that can work around functions, instance methods, class methods and classes,
thereby avoiding the need to have multiple distinct decorator implementations
for the different use case.
So in the following example code:
class BoundWrapper(object):
def __init__(self, wrapped):
self.__wrapped__ = wrapped
def __call__(self, *args, **kwargs):
print('BoundWrapper.__call__()', args, kwargs)
print('__wrapped__.__self__', self.__wrapped__.__self__)
return self.__wrapped__(*args, **kwargs)
class Wrapper(object):
def __init__(self, wrapped):
self.__wrapped__ = wrapped
def __get__(self, instance, owner):
bound_function = self.__wrapped__.__get__(instance, owner)
return BoundWrapper(bound_function)
def decorator(wrapped):
return Wrapper(wrapped)
class Class(object):
@decorator
def function_im(self):
print('Class.function_im()', self)
@decorator
@classmethod
def function_cm_inner(cls):
print('Class.function_cm_inner()', cls)
@classmethod
@decorator
def function_cm_outer(cls):
print('Class.function_cm_outer()', cls)
c = Class()
c.function_im()
print()
Class.function_cm_inner()
print()
Class.function_cm_outer()
A failure is encountered of:
$ python3.3 cmgettest.py
BoundWrapper.__call__() () {}
__wrapped__.__self__ __main__.Class object at 0x1029fc150
Class.function_im() __main__.Class object at 0x1029fc150
BoundWrapper.__call__() () {}
__wrapped__.__self__ class '__main__.Class'
Class.function_cm_inner() class '__main__.Class'
Traceback (most recent call last):
File cmgettest.py, line 40, in module
Class.function_cm_outer()
TypeError: 'Wrapper' object is not callable
IOW, everything is fine when the decorator is applied around the classmethod,
but when it is placed inside of the classmethod, a failure occurs because the
decorator object is not callable.
One could argue that the error is easily avoided by adding a __call__() method
to the Wrapper class, but that defeats the purpose of what is trying to be
achieved in using this pattern. That is that one can within the bound wrapper
after binding occurs, determine from the __self__ of the bound function, the
fact that it was a class method. This can be inferred from the fact that
__self__ is a class type.
If the classmethod decorator tp_descr_get implementation is changed so as to
properly apply the descriptor binding protocol to the wrapped object, then what
is being described is possible.
Having it honour the descriptor binding protocol also seems to make application
of the Python object model more consistent.
A patch is attached which does exactly this.
The result for the above test after the patch is applied is:
BoundWrapper.__call__() () {}
__wrapped__.__self__ __main__.Class object at 0x10ad237d0
Class.function_im() __main__.Class object at 0x10ad237d0
BoundWrapper.__call__() () {}
__wrapped__.__self__ class '__main__.Class'
Class.function_cm_inner() class '__main__.Class'
BoundWrapper.__call__() () {}
__wrapped__.__self__ class '__main__.Class'
Class.function_cm_outer() class '__main__.Class'
That is, the decorator whether it is inside or outside now sees things in the
same way.
If one also tests for calling of the classmethod via the instance:
print()
c.function_cm_inner()
print()
c.function_cm_outer()
Everything again also works out how want it:
BoundWrapper.__call__() () {}
__wrapped__.__self__ class '__main__.Class'
Class.function_cm_inner() class '__main__.Class'
BoundWrapper.__call__() () {}
__wrapped__.__self__ class '__main__.Class'
Class.function_cm_outer() class '__main__.Class'
FWIW, the shortcoming of classmethod not applying the descriptor binding
protocol to the wrapped object, was found in writing a new object proxy and
decorator library called 'wrapt'. This issue in the classmethod implementation
is the one thing that has prevented wrapt having a system of writing decorators
that can magically work out the context it is used in all the time. Would be
nice to see it fixed. :-)
The wrapt library can be found at:
https://github.com/GrahamDumpleton/wrapt
http://wrapt.readthedocs.org
The limitation in the classmethod implementation is noted in the wrapt
documentation at:
http://wrapt.readthedocs.org/en/v1.1.2/issues.html#classmethod-get
--
components: Interpreter Core
files: funcobject.c.diff
[issue19073] Inability to specific __qualname__ as a property on a class instance.
New submission from Graham Dumpleton: Python 3 introduced __qualname__. This attribute exists on class types and also instances of certain class types, such as functions. For example: def f(): pass print(f.__name__) print(f.__qualname__) class Class: pass print(Class.__name__) print(Class.__qualname__) yields: f f Class Class An instance of a class however does not have __name__ or __qualname__ attributes. With: c = Class() print(c.__name__) print(c.__qualname__) yielding: Traceback (most recent call last): File qualnametest.py, line 13, in module print(c.__name__) AttributeError: 'Class' object has no attribute '__name__' Traceback (most recent call last): File qualnametest.py, line 14, in module print(c.__qualname__) AttributeError: 'Class' object has no attribute '__qualname__' For a class, it is possible to override the __name__ attribute using a property. class Class: @property def __name__(self): return 'override' c = Class() print(c.__name__) With the result being: override This is useful in writing object proxies or function wrappers for decorators as rather than having to copy the __name__ attribute into the wrapper, the lookup can be deferred until when it is required. The same though cannot be done for __qualname__. With: class Class: @property def __qualname__(self): return 'override' yielding an error when the class definition is being processed: Traceback (most recent call last): File qualnametest.py, line 16, in module class Class: TypeError: type __qualname__ must be a str, not property This means the same trick cannot be used in object proxies and function wrappers and instead __qualname__ must be copied and assigned explicitly as a string attribute in the __init__() function of the object proxy or function wrapper. I can sort of understand a prohibition on __qualname__ being a string attribute in certain cases, especially if overriding it on a type or instance where __qualname__ attribute already exists, but I don't understand why a limitation would be imposed to prevent using a property as a means of generating the value for a class instance which doesn't otherwise have a __qualname__ attribute. There is no similar restriction for __name__. Unless there is a good specific reason for this behaviour, the ability to override it with a property in cases where the __qualname__ attribute didn't already exist, would be handy for proxies and wrappers. -- components: Interpreter Core messages: 198275 nosy: grahamd priority: normal severity: normal status: open title: Inability to specific __qualname__ as a property on a class instance. type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19073] Inability to specific __qualname__ as a property on a class instance.
Antoine Pitrou added the comment: I guess this would be a harmless improvement in any case. -- nosy: +pitrou stage: - needs patch type: behavior - enhancement versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4366] cannot find -lpythonX.X when building Python on FreeBSD with --enable-shared
koobs added the comment: Attaching an initial patch with the following changes: - Update comment - Add original (#1600860) and current issue ID references - Remove sys.platform conditional - Remove NOOP sysconfig.get_config_var call (Reported by: birkenfeld) This results in all platforms receiving the same treatment as the default, which is consistent with the comment -- Added file: http://bugs.python.org/file31843/python-issue4366.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4366 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18978] Allow urllib.request.Request subclasses to override method
Roundup Robot added the comment: New changeset 6d6d68c068ad by Jason R. Coombs in branch 'default': Issue #18978: Allow Request.method to be defined at the class level. http://hg.python.org/cpython/rev/6d6d68c068ad New changeset 2b2744cfb08f by Jason R. Coombs in branch 'default': Issue #18978: A more elegant technique for resolving the method http://hg.python.org/cpython/rev/2b2744cfb08f New changeset 061eb75339e2 by Jason R. Coombs in branch 'default': Issue #18978: Add tests to capture expected behavior for class-level method overrides. http://hg.python.org/cpython/rev/061eb75339e2 New changeset 8620aea9bbca by Jason R. Coombs in branch 'default': Close #18978: Merge changes. http://hg.python.org/cpython/rev/8620aea9bbca -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18978 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
New submission from anatoly techtonik: http://docs.python.org/2/faq/gui.html - this page misses info about PySide. -- assignee: docs@python components: Documentation messages: 198279 nosy: docs@python, techtonik priority: normal severity: normal status: open title: Add PySide to GUI FAQ versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18978] Allow urllib.request.Request subclasses to override method
Roundup Robot added the comment: New changeset 7f13d5ecf71f by Jason R. Coombs in branch 'default': Issue #18978: Update docs to reflect explicitly the ability to set the attribute at the class level. http://hg.python.org/cpython/rev/7f13d5ecf71f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18978 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18986] Add a case-insensitive case-preserving dict
Jason R. Coombs added the comment: I just want to say thanks for working on this. I also have needed this functionality for various needs in the past. To fulfill my needs, I wrote this implementation: https://bitbucket.org/jaraco/jaraco.util/src/1ab3e7061f96bc5e179b6b2c46b06d1c20f87129/jaraco/util/dictlib.py?at=default#cl-221 That implementation is used in the irc library for a case-insensitive dict, but using the IRC-specific standard for case insensitivity (https://bitbucket.org/jaraco/irc/src/1576b10dc2923d4d7234319d2d1e11a5080e1f7d/irc/dict.py?at=default#cl-49). I share this just to add a +1 for the need and to provide additional use cases and implementations for reference. -- nosy: +jason.coombs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19064] can't run py3 benchmarks
Brett Cannon added the comment: ``python3 perf.py -fb mako_v2 ../opt/python ../x32opt/python`` obviously assuming you are specifying Python 3 interpreters. =) Feel free to tweak any docs you think should be touched up to make that more obvious. -- assignee: brett.cannon - pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19064] can't run py3 benchmarks
Antoine Pitrou added the comment: Well... It wasn't really obvious to me :-) Why shouldn't the child interpreter decide which lib to use, though? perf.py is just an executable script (and its shebang specifies python, not python3). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Changes by Brett Cannon br...@python.org: -- priority: normal - low stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Brett Cannon added the comment: I say we just delete that page. Trying to keep up with GUI toolkits is a losing battle (as shown by this bug report) and not worth our time and effort to try to maintain. Search engines are your friend in this instance. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19064] can't run py3 benchmarks
Brett Cannon added the comment: Originally that didn't work too well because the benchmark suite could run Python 2 and Python 3 benchmarks simultaneously, but I don't know if that still works after the 2/3 merge. As for having interpreter under test make the choice of what version to use is fine by me, it's just the current solution was the easiest to implement. If you want to change than go for it! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Christian Heimes added the comment: The wiki is probably a better place for such information. -- nosy: +christian.heimes versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15329] clarify which deque methods are thread-safe
anatoly techtonik added the comment: So, is deque a faster replacement for Queue.Queue or not? -- nosy: +techtonik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19065] sqlite3 timestamp adapter chokes on timezones
Alexander Belopolsky added the comment: Sounds like a reasonable request, but the proposed code does not seem to work for the Eastern hemisphere (negative tz offsets.) I am not very familiar with sqlite module. What timestamp format does it use? Isn't it some varian of ISO 3339? See issue 15873. -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19065 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19024] Document asterisk (*), splat or star operator
Terry J. Reedy added the comment: The StackOverflow question and answer about function calls is 5 years old and therefore out of date with respect to #12531, which specifically added index entries for function calls. Perhaps my Python 3 symbol glossary Python3 Syntax Symbol Uses https://code.google.com/p/xploro/downloads/detail?name=PySymbols.htmlcan=1q= could be expanded a bit or combined with other text, as well as being a basis for adding index entries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19022] Improve handling of type.__abstractmethods__ descriptor
Daniel Urban added the comment: I like the 3rd alternative the most. It seems to me, that __abstractmethods__ is currently an undocumented implementation detail of ABCs. The 1st alternative would cause every type to have an empty __abstractmethods__ (which is technically correct, but probably not very useful). It seems to me that the 2nd alternative would not help very much in the original problem mentioned in issue10006 (automatically looking up every name found in dir). So I think, that the best would be to fix type.__dir__ this way. (Although, if we really want to document and use __abstractmethods__ on every type, then of course we should do the 1st alternative.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19022 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api
Alexander Belopolsky added the comment: See also #5907. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1820 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185124] pydoc doesn't find all module doc strings
Sunny added the comment: I've rewritten the source_synopsis function to use the tokenize module. It should now work with triple single quotes and hopefully all the other cases where __doc__ returns a string. Since tokenize.tokenize needs a file object that is opened in binary mode, in the case of a StringIO object, i am reading the whole object and converting it to a BytesIO object. I don't know if that is the right way. Also, the only instance i could find where source_synopsis is called with a StringIO object is in the ModuleScanner.run method. Maybe we could tweak this call to pass a byte-stream object to avoid the overhead of re-conversion? All the current tests pass. -- keywords: +patch nosy: +sunfinite Added file: http://bugs.python.org/file31844/myfirst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
anatoly techtonik added the comment: If only wiki had a theme like Sphinx docs.. But I agree that static FAQ look dead compared to wiki or stackoverflow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Eli Bendersky added the comment: +1 to delete -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19075] Add sorting algorithm visualization to turtledemo
New submission from Jason Yeo: My university uses python to teach sorting algorithms. It will be great if the turtledemo comes with a visualization of some of the algorithms. I have attached a patch for it. -- components: Demos and Tools files: animation.diff keywords: patch messages: 198295 nosy: Jason.Yeo priority: normal severity: normal status: open title: Add sorting algorithm visualization to turtledemo type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file31845/animation.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19075] Add sorting algorithm visualization to turtledemo
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19075] Add sorting algorithm visualization to turtledemo
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +gregorlingl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19047] Assorted weakref docs improvements
Richard Oudkerk added the comment: Thanks for the doc cleanup -- I am rather busy right now. Note that stuff does still get replaced by None at shutdown, and this can still produce errors, even if they are much harder to trigger. If I run the following program import _weakref import collections a = hello class Foo(object): def __del__(self): print(a) collections.foo = Foo() _weakref.foo = Foo() then depending on the initial hashseed I get a reproducible error: $ PYTHONHASHSEED=7 python-release /tmp/bad.py Exception ignored in: bound method Foo.__del__ of __main__.Foo object at 0xb733db8c Traceback (most recent call last): File /tmp/bad.py, line 8, in __del__ TypeError: 'NoneType' object is not callable (Personally I would like to see a flag set late during shutdown which blocks __del__ methods from running.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19047 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18967] Find a less conflict prone approach to Misc/NEWS
Terry J. Reedy added the comment: +lots on ending News Merge Hell. After too many bad experiences, I now avoid pushing non-Idle patches that require a News entry. Even for those who do not mind merge conflicts, there is still the waste of time. The premise of non-checkout code management is that code expands with the number developers, so merge conflicts should stay rare. Making everyone edit the same few areas of one file subverts this premise. The switch to hg introduced push races. A merge conflict lengthens the time required to fix things after losing a race. This increases the chance of loosing the race a second time. This has happened to me. These problems would be worse if there were more active developers, which we need. Some possible solutions. 1. Get hg to ignore lower context, which is the source of conflicts. The upper context of == Section Title - == is never a problem. 2. Generate news entry from commit message on an *opt-in* basis using a section tag line **Section, where Section is one of Code, Lib, Text, Doc, Idle. Only pay attention to the first letter. Only text before the tag line would go in News. Example commit message: Issue #12345: fix the bug. This is also the news entry. Patch by New Contributor **Lib Comment for developers only. This would work for at well over half of existing commits. I consider the elimination of duplication a bonus. A developer who preferred to write an independent News entry still could. 3. I though of separate News.3.3, News.3.4. While this would prevent forward merge conflicts (very helpful), it would not solve within version pull-merge conflicts, as when loosing a push race. 4. I thought of putting adding enough blank lines between header and first entries so that if more blanks were added with entries, the lower context could be 3 blank lines, and hence no conflict. However, when hg does diffs and must choose, it sees upper blank lines as context and lower blank lines as new, whereas the opposite would be needed for this to work. But this choice enables the following idea. 5. Add a new Log file with each entry consisting of a tag line, the entry, and 3 blank lines. If == **Lib Issue #12345. Fix bug. This is News entry. Patch by New Contributor === were augmented to == **Lib Issue #12345. Fix bug. This is News entry. Patch by New Contributor **Code Issue #12348. Add feature. This is another News entry. = the diff would start with three blank lines of context. === **Code Issue #12348. Add feature. This is another News entry. + + + == 6. Have a directory of personal log files, one for each developer, that get periodically merged into news and emptied (or deleted when a release is tagged). The advantage, and only advantage, over a joint log file is not having to enforce the spacing of a joint log file. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16038] ftplib: unlimited readline() from connection
Barry A. Warsaw added the comment: Okay, this one is quite odd. It's definitely a timing issue. If I put a `import time; time.sleep(1)` at the beginning of test_retrlines_too_line() -- i.e. first line of the method -- then the test reliably passes. If I put a `print(len(line))` just before the maxline test in FTP.retrlines(), then the test will pass just as reliably. If I put that retrlines() print *after* the maxline test, then it passes sometimes and fails sometimes. When if fails, it's only ready 12 bytes from the `fp.readline()` call. When it passes, it's reading 8193 bytes (thus triggering the expected exception). I really hate to put a sleep in the test to make it pass. Obviously it would be better not to fudge this race condition, but I don't know the code well enough to know where the race is yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16038 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16039] imaplib: unlimited readline() from connection
Barry A. Warsaw added the comment: Looks good for 2.6. The NEWS file hunk doesn't apply, but I'll fix that when I commit this to 2.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16039 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16039] imaplib: unlimited readline() from connection
Roundup Robot added the comment: New changeset 4190568ceda0 by Barry Warsaw in branch '2.6': - Issue #16039: CVE-2013-1752: Change use of readline in imaplib module to http://hg.python.org/cpython/rev/4190568ceda0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16039 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16039] imaplib: unlimited readline() from connection
Barry A. Warsaw added the comment: Since the merge 2.6 - 2.7 did not apply cleanly, and had other problems. I null merged the 2.6 changes. I'll leave it to Benjamin to work out whatever patches 2.7 needs. -- versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16039 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16042] smtplib: unlimited readline() from connection
Barry A. Warsaw added the comment: Please don't add 2.6 back to the Versions, unless there's actually something to do for 2.6. AFAIK, this issue is resolved for 2.6. -- versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Changes by Brett Cannon br...@python.org: -- assignee: docs@python - brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18967] Find a less conflict prone approach to Misc/NEWS
Ezio Melotti added the comment: Even for those who do not mind merge conflicts, there is still the waste of time. If you know what you are doing the waste is minimal. I sometimes import, check, commit, merge, and push a patch on 3 branches in less than a minute (it was a trivial patch that didn't require to run the test suite), and fixing conflicts in Misc/NEWS is something that can be done in a few seconds, even when the merge goes completely wrong (ctrl+2, ctrl+1, ctrl+s, ctrl+q when it goes right; ctrl+q, hg revert Misc/NEWS, copy/paste the entry when it goes wrong). If you are trying to figure out how to use a merge tool or understanding why there is a merge conflict, what branches are involved, what should be merged and in what order, what should be committed/reverted/updated, then it will take more time (even more if you get it wrong and you have to start over), but the pattern is always the same once you learn it. The switch to hg introduced push races. A merge conflict lengthens the time required to fix things after losing a race. This increases the chance of loosing the race a second time. This has happened to me. There are two kind of conflicts: 1) conflicts while merging files between branches on the same machine; 2) conflicts with changesets pushed by other developers; The first kind is usually trivial to fix (see above). The second kind (i.e. push race) might indeed be more complex [0], but it can still be solved in less than a minute. Of course in that minute someone else might push again, but you must be very unlucky (or very slow). These problems would be worse if there were more active developers, which we need. Even if we get twice as many active developers, I think push races would still be quite rare since there are usually hours between each push. Once 2.7 is closed the chances of conflict will further decrease. Some possible solutions. 1. Get hg to ignore lower context, which is the source of conflicts. This could possibly be done with a merge hook (see one of my previous message). I'm not sure it can be done by ignoring the lower context, but something should be doable. 2. Generate news entry from commit message on an *opt-in* basis using a section tag line **Section, where Section is one of Code, Lib, Text, Doc, Idle. I'm -1 on adding tags and use them to generate Misc/NEWS. 3. I though of separate News.3.3, News.3.4. While this would prevent forward merge conflicts (very helpful), it would not solve within version pull-merge conflicts, as when loosing a push race. Also if I fix a bug in 3.3 and 3.4, will I have to add the news manually in two different files? Now HG does it for me automatically since there's only one file -- having to edit separate files seems like a step backward. I don't know if creating News.3.4 by using hg cp on News.3.3 will automatically add the entry on both, but even if it does it won't probably solve the original problem. 4. I thought of putting adding enough blank lines between header and first entries so that if more blanks were added with entries, the lower context could be 3 blank lines, and hence no conflict. This sounds like an hack, and I'm not sure it will work (hg might try to include more context in the diff if there are only empty lines). 5. Add a new Log file with each entry consisting of a tag line, the entry, and 3 blank lines. See previous point. 6. Have a directory of personal log files, one for each developer, that get periodically merged into news and emptied (or deleted when a release is tagged). The advantage, and only advantage, over a joint log file is not having to enforce the spacing of a joint log file. IIRC the Twisted devs do something similar, but with a separate file for each NEWS entry. Something similar was also discussed when this came up on python-dev a few months ago. [0]: http://docs.python.org/devguide/faq.html#i-got-abort-push-creates-new-remote-heads-while-pushing-what-do-i-do -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Ezio Melotti added the comment: Note that we have a somewhat similar HOWTO about using Python in the web: http://docs.python.org/dev/howto/webservers.html The HOWTO mentions at the top that it can't keep track of all the several web framework and links to the wiki for a more updated page. The same approach could be followed here too, if we want to keep that page. -- assignee: brett.cannon - docs@python nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19074] Add PySide to GUI FAQ
Antoine Pitrou added the comment: Actually PySide is mentioned in the 3.x version of the docs. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19030] inspect.getmembers and inspect.classify_class_attrs mishandle descriptors
Ethan Furman added the comment: Current patch has a little more code cleanup and a bunch more tests. I copied and adapted test_property to test_VirtualAttribute, and VirtualAttribute passes every test except the __slots__ test where __doc__ is not supposed to copy. I think the problem there is that VA is a python object and already has a __doc__ so having __slots__ not show __doc__ doesn't help. I put a skipIf(hasattr, obj, '__doc__') around that test. I'm still not crazy about the name VirtualAttribute... oh well. If no negative feedback by mid-week I'll commit, as I would really like this code to be the next alpha. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19030 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19030] inspect.getmembers and inspect.classify_class_attrs mishandle descriptors
Changes by Ethan Furman et...@stoneleaf.us: Added file: http://bugs.python.org/file31846/issue19030.stoneleaf.04.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19030 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19025] Deleting attribute of Enum gives misleading error message
Ethan Furman added the comment: Okay, I changed my mind about __delattr__. Having it say AttributeError: cannot delete Enum member is certainly nicer than AttributeError: MemberName -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19025 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19025] Deleting attribute of Enum gives misleading error message
Roundup Robot added the comment: New changeset ed011b0d7daf by Ethan Furman in branch 'default': Close #19025: Better error message when trying to delete an Enum member. http://hg.python.org/cpython/rev/ed011b0d7daf -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19025 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19076] Pdb.do_break calls error with obsolete file kwarg
New submission from Michael Smith: Pretty straightforward: File /usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pdb.py, line 675, in do_break self.error(err, file=self.stdout) TypeError: error() got an unexpected keyword argument 'file' Sure enough, line 675 reads: self.error(err, file=self.stdout) but line 448: def error(self, msg): -- components: Extension Modules messages: 198309 nosy: Michael.Smith priority: normal severity: normal status: open title: Pdb.do_break calls error with obsolete file kwarg versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19011] Enum should have a __getattr__ that makes all the instances available from an instance
Ethan Furman added the comment: Posted a message on PyDev, but unless I get feedback saying it's a bad idea, or I find some implementation issue, I'll go ahead and make the change. So either a doc patch or an enum patch will be in alpha3. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19011 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19040] Problems with overriding Enum.__new__
Ethan Furman added the comment: How about this note after the AutoNumber example? .. note:: The :meth:`__new__` method, if defined, is used during creation of the Enum members; it is then replaced by Enum's :meth:`__new__` which is used after class creation for lookup of existing members. Due to the way Enums are supposed to behave, there is no way to customize Enum's :meth:`__new__`. -- nosy: +barry, eli.bendersky stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19040 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19040] Problems with overriding Enum.__new__
Eli Bendersky added the comment: LGTM, Ethan. You know how I feel about customization in general ;-) We should give Enum a term or two in the stdlib to learn how it's being used and abused - we can always *add* customization in the future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19040 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19030] inspect.getmembers and inspect.classify_class_attrs mishandle descriptors
Nick Coghlan added the comment: I suggest DynamicClassAttribute for the descriptor name. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19030 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19040] Problems with overriding Enum.__new__
Ethan Furman added the comment: Yup, just trying to add some explanation on how it currently works. Drekin, I'm sure you've already figured this out, but for those who may read this in the future: what you need is a helper function: def OptionalEnum(value): could also be OptionalEnum(enum, value) try: return SomeEnum(value) # or return enum(value) except ValueError: return value -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19040 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19076] Pdb.do_break calls error with obsolete file kwarg
Changes by Berker Peksag berker.pek...@gmail.com: -- components: +Library (Lib) nosy: +berker.peksag, georg.brandl stage: - needs patch versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
