Mailman 3 January 2010 - Python-Dev

Data descriptor doc/implementation inconsistency
by Benjamin Peterson Jan. 12, 2010

Jan. 12, 2010

Consider this program: class Descr(object): def __init__(self, name): self.name = name def __set__(self, instance, what): instance.__dict__[self.name] = what class X(object): attr = Descr("attr") x = X() print(x.attr) x.attr = 42 print(x.attr) It gives in output: <__main__.Descr object at 0x7fe1c9b28150> 42 The documentation [1] says that Descr is a data descriptor because it defines the __set__ method. It also states that data descriptors always override … [View More]

4 5

Improve open() to support reading file starting with an unicode BOM
by Victor Stinner Jan. 12, 2010

Jan. 12, 2010

Hi, Builtin open() function is unable to open an UTF-16/32 file starting with a BOM if the encoding is not specified (raise an unicode error). For an UTF-8 file starting with a BOM, read()/readline() returns also the BOM whereas the BOM should be "ignored". See recent issues related to reading an UTF-8 text file including a BOM: #7185 (csv) and #7519 (ConfigParser). Such file can be opened in unicode mode with the UTF-8-SIG encoding, but it's possible to do better. I propose to improve … [View More]

17 56

Re: [Python-Dev] Data descriptor doc/implementation inconsistency
by Łukasz Rekucki Jan. 11, 2010

Jan. 11, 2010

> Date: Mon, 11 Jan 2010 01:51:09 +0100 > From: "Amaury Forgeot d'Arc" <amauryfa(a)gmail.com> > To: Benjamin Peterson <benjamin(a)python.org> > Cc: Python Dev <python-dev(a)python.org> > Subject: Re: [Python-Dev] Data descriptor doc/implementation > inconsistency > Message-ID: > <e27efe131001101651y68e1da25je2a8d02f5c62ef19(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 … [View More]> > Hi, > > 2010/1/11 Benjamin Peterson <benjamin(a)python.org>: >> Consider this program: >> >> class Descr(object): >> ? ?def __init__(self, name): >> ? ? ? ?self.name = name >> ? ?def __set__(self, instance, what): >> ? ? ? ?instance.__dict__[self.name] = what >> >> class X(object): >> ? ?attr = Descr("attr") >> >> x = X() >> print(x.attr) >> x.attr = 42 >> print(x.attr) >> >> It gives in output: >> >> <__main__.Descr object at 0x7fe1c9b28150> >> 42 >> >> The documentation [1] says that Descr is a data descriptor because it >> defines the __set__ method. It also states that data descriptors >> always override the value in the instance dictionary. So, the second >> line should also be the descriptor object according to the >> documentation. >> >> My question is: Is this a doc bug or a implementation bug? If the >> former, it will be the description of a data descriptor much less >> consistent, since it will require that a __get__ method be present, >> too. If the latter, the fix may break some programs relying on the >> ability to "cache" a value in the instance dictionary. >> >> [1] http://docs.python.org/reference/datamodel#invoking-descriptors > > Quoting the documentation: > """Normally, data descriptors define both __get__() and __set__(), > while non-data descriptors have just the __get__() method. > """ > Your example is neither a data descriptor nor a non-data descriptor... Actually, there is this footnote [1]: """ A descriptor can define any combination of __get__(), __set__() and __delete__(). If it does not define __get__(), then accessing the attribute even on an instance will return the descriptor object itself. If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor. """ Which would mean Descr is actually a data descriptor without a __get__(), so x.attr should always return the descriptor object itself (at least in the docs). > The thing that worries me a bit is the "x.attr" returning the Descr > object. Descriptors should remain at the class level, and instance > should only see values. I'd prefer an AttributeError in this case. > > -- > Amaury Forgeot d'Arc [1] http://docs.python.org/reference/datamodel#id7 -- Lukasz Rekucki [View Less]

1 0

Fwd: [Python-checkins] r77402 - in python/trunk: Doc/library/warnings.rst Lib/test/test_ascii_formatd.py Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c
by Brett Cannon Jan. 11, 2010

Jan. 11, 2010

Nick Coghlan thought I should forward this to python-dev so people are aware of this change and why it occurred (plus it indirectly informs Guido I finally finished the work). ---------- Forwarded message ---------- From: brett.cannon <python-checkins(a)python.org> Date: Sat, Jan 9, 2010 at 18:56 Subject: [Python-checkins] r77402 - in python/trunk: Doc/library/warnings.rst Lib/test/test_ascii_formatd.py Lib/test/test_exceptions.py Lib/warnings.py Misc/NEWS Python/_warnings.c To: python-… [View More]checkins(a)python.org Author: brett.cannon Date: Sun Jan 10 03:56:19 2010 New Revision: 77402 Log: DeprecationWarning is now silent by default. This was originally suggested by Guido, discussed on the stdlib-sig mailing list, and given the OK by Guido directly to me. What this change essentially means is that Python has taken a policy of silencing warnings that are only of interest to developers by default. This should prevent users from seeing warnings which are triggered by an application being run against a new interpreter before the app developer has a chance to update their code. Closes issue #7319. Thanks to Antoine Pitrou, Ezio Melotti, and Brian Curtin for helping with the issue. Modified: python/trunk/Doc/library/warnings.rst python/trunk/Lib/test/test_ascii_formatd.py python/trunk/Lib/test/test_exceptions.py python/trunk/Lib/warnings.py python/trunk/Misc/NEWS python/trunk/Python/_warnings.c Modified: python/trunk/Doc/library/warnings.rst ============================================================================== --- python/trunk/Doc/library/warnings.rst (original) +++ python/trunk/Doc/library/warnings.rst Sun Jan 10 03:56:19 2010 @@ -59,7 +59,7 @@ | :exc:`UserWarning` | The default category for :func:`warn`. | +----------------------------------+-----------------------------------------------+ | :exc:`DeprecationWarning` | Base category for warnings about deprecated | -| | features. | +| | features (ignored by default). | +----------------------------------+-----------------------------------------------+ | :exc:`SyntaxWarning` | Base category for warnings about dubious | | | syntactic features. | @@ -89,6 +89,9 @@ standard warning categories. A warning category must always be a subclass of the :exc:`Warning` class. +.. versionchanged:: 2.7 + :exc:`DeprecationWarning` is ignored by default. + .. _warning-filter: @@ -148,14 +151,6 @@ :mod:`warnings` module parses these when it is first imported (invalid options are ignored, after printing a message to ``sys.stderr``). -The warnings that are ignored by default may be enabled by passing :option:`-Wd` -to the interpreter. This enables default handling for all warnings, including -those that are normally ignored by default. This is particular useful for -enabling ImportWarning when debugging problems importing a developed package. -ImportWarning can also be enabled explicitly in Python code using:: - - warnings.simplefilter('default', ImportWarning) - .. _warning-suppress: @@ -226,6 +221,37 @@ entries from the warnings list before each new operation). +Updating Code For New Versions of Python +---------------------------------------- + +Warnings that are only of interest to the developer are ignored by default. As +such you should make sure to test your code with typically ignored warnings +made visible. You can do this from the command-line by passing :option:`-Wd` +to the interpreter (this is shorthand for :option:`-W default`). This enables +default handling for all warnings, including those that are ignored by default. +To change what action is taken for encountered warnings you simply change what +argument is passed to :option:`-W`, e.g. :option:`-W error`. See the +:option:`-W` flag for more details on what is possible. + +To programmatically do the same as :option:`-Wd`, use:: + + warnings.simplefilter('default') + +Make sure to execute this code as soon as possible. This prevents the +registering of what warnings have been raised from unexpectedly influencing how +future warnings are treated. + +Having certain warnings ignored by default is done to prevent a user from +seeing warnings that are only of interest to the developer. As you do not +necessarily have control over what interpreter a user uses to run their code, +it is possible that a new version of Python will be released between your +release cycles. The new interpreter release could trigger new warnings in your +code that were not there in an older interpreter, e.g. +:exc:`DeprecationWarning` for a module that you are using. While you as a +developer want to be notified that your code is using a deprecated module, to a +user this information is essentially noise and provides no benefit to them. + + .. _warning-functions: Available Functions Modified: python/trunk/Lib/test/test_ascii_formatd.py ============================================================================== --- python/trunk/Lib/test/test_ascii_formatd.py (original) +++ python/trunk/Lib/test/test_ascii_formatd.py Sun Jan 10 03:56:19 2010 @@ -4,6 +4,7 @@ import unittest from test_support import check_warnings, run_unittest, cpython_only +import warnings class FormatDeprecationTests(unittest.TestCase): @@ -17,6 +18,7 @@ buf = create_string_buffer(' ' * 100) with check_warnings() as w: + warnings.simplefilter('default') PyOS_ascii_formatd(byref(buf), sizeof(buf), '%+.10f', c_double(10.0)) self.assertEqual(buf.value, '+10.0000000000') Modified: python/trunk/Lib/test/test_exceptions.py ============================================================================== --- python/trunk/Lib/test/test_exceptions.py (original) +++ python/trunk/Lib/test/test_exceptions.py Sun Jan 10 03:56:19 2010 @@ -309,6 +309,7 @@ # BaseException.__init__ triggers a deprecation warning. exc = BaseException("foo") with warnings.catch_warnings(record=True) as w: + warnings.simplefilter('default') self.assertEquals(exc.message, "foo") self.assertEquals(len(w), 1) self.assertEquals(w[0].category, DeprecationWarning) Modified: python/trunk/Lib/warnings.py ============================================================================== --- python/trunk/Lib/warnings.py (original) +++ python/trunk/Lib/warnings.py Sun Jan 10 03:56:19 2010 @@ -383,8 +383,8 @@ # Module initialization _processoptions(sys.warnoptions) if not _warnings_defaults: - simplefilter("ignore", category=PendingDeprecationWarning, append=1) - simplefilter("ignore", category=ImportWarning, append=1) + for cls in (DeprecationWarning, PendingDeprecationWarning, ImportWarning): + simplefilter("ignore", category=cls, append=True) bytes_warning = sys.flags.bytes_warning if bytes_warning > 1: bytes_action = "error" Modified: python/trunk/Misc/NEWS ============================================================================== --- python/trunk/Misc/NEWS (original) +++ python/trunk/Misc/NEWS Sun Jan 10 03:56:19 2010 @@ -12,6 +12,8 @@ Core and Builtins ----------------- +- Issue #7319: Silence DeprecationWarning by default. + - Issue #2335: Backport set literals syntax from Python 3.x. Library Modified: python/trunk/Python/_warnings.c ============================================================================== --- python/trunk/Python/_warnings.c (original) +++ python/trunk/Python/_warnings.c Sun Jan 10 03:56:19 2010 @@ -85,10 +85,10 @@ default_action = get_warnings_attr("defaultaction"); if (default_action == NULL) { - if (PyErr_Occurred()) { - return NULL; - } - return _default_action; + if (PyErr_Occurred()) { + return NULL; + } + return _default_action; } Py_DECREF(_default_action); @@ -202,12 +202,12 @@ mod_str = PyString_AsString(filename); if (mod_str == NULL) - return NULL; + return NULL; len = PyString_Size(filename); if (len < 0) return NULL; if (len >= 3 && - strncmp(mod_str + (len - 3), ".py", 3) == 0) { + strncmp(mod_str + (len - 3), ".py", 3) == 0) { module = PyString_FromStringAndSize(mod_str, len-3); } else { @@ -251,7 +251,7 @@ name = PyObject_GetAttrString(category, "__name__"); if (name == NULL) /* XXX Can an object lack a '__name__' attribute? */ - return; + return; f_stderr = PySys_GetObject("stderr"); if (f_stderr == NULL) { @@ -341,7 +341,7 @@ rc = already_warned(registry, key, 0); if (rc == -1) goto cleanup; - else if (rc == 1) + else if (rc == 1) goto return_none; /* Else this warning hasn't been generated before. */ } @@ -492,9 +492,9 @@ /* Setup filename. */ *filename = PyDict_GetItemString(globals, "__file__"); if (*filename != NULL) { - Py_ssize_t len = PyString_Size(*filename); + Py_ssize_t len = PyString_Size(*filename); const char *file_str = PyString_AsString(*filename); - if (file_str == NULL || (len < 0 && PyErr_Occurred())) + if (file_str == NULL || (len < 0 && PyErr_Occurred())) goto handle_error; /* if filename.lower().endswith((".pyc", ".pyo")): */ @@ -506,10 +506,10 @@ tolower(file_str[len-1]) == 'o')) { *filename = PyString_FromStringAndSize(file_str, len-1); - if (*filename == NULL) - goto handle_error; - } - else + if (*filename == NULL) + goto handle_error; + } + else Py_INCREF(*filename); } else { @@ -536,8 +536,8 @@ else { /* embedded interpreters don't have sys.argv, see bug #839151 */ *filename = PyString_FromString("__main__"); - if (*filename == NULL) - goto handle_error; + if (*filename == NULL) + goto handle_error; } } if (*filename == NULL) { @@ -839,26 +839,29 @@ static PyObject * init_filters(void) { - PyObject *filters = PyList_New(3); + PyObject *filters = PyList_New(4); const char *bytes_action; if (filters == NULL) return NULL; PyList_SET_ITEM(filters, 0, + create_filter(PyExc_DeprecationWarning, "ignore")); + PyList_SET_ITEM(filters, 1, create_filter(PyExc_PendingDeprecationWarning, "ignore")); - PyList_SET_ITEM(filters, 1, create_filter(PyExc_ImportWarning, "ignore")); + PyList_SET_ITEM(filters, 2, create_filter(PyExc_ImportWarning, "ignore")); if (Py_BytesWarningFlag > 1) bytes_action = "error"; else if (Py_BytesWarningFlag) bytes_action = "default"; else bytes_action = "ignore"; - PyList_SET_ITEM(filters, 2, create_filter(PyExc_BytesWarning, + PyList_SET_ITEM(filters, 3, create_filter(PyExc_BytesWarning, bytes_action)); if (PyList_GET_ITEM(filters, 0) == NULL || PyList_GET_ITEM(filters, 1) == NULL || - PyList_GET_ITEM(filters, 2) == NULL) { + PyList_GET_ITEM(filters, 2) == NULL || + PyList_GET_ITEM(filters, 3) == NULL) { Py_DECREF(filters); return NULL; } _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins [View Less]

3 2

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
by Henning von Bargen Jan. 10, 2010

Jan. 10, 2010

If Python should support BOM when reading text files, it should also be able to *write* such files. An encoding="BOM" argument wouldn't help here, because it does not specify which encoding to use actually: UFT-8, UTF-16-LE or what? That would be a point against encoding="BOM" and pro an additional keyword argument "use_bom" or whatever with the following values: None: default (old) behaviour: don't handle BOM at all True: reading: expect BOM (raising an exception if it's … [View More]

2 1

Unladen cPickle speedups in 2.7 & 3.1
by skip＠pobox.com Jan. 10, 2010

Jan. 10, 2010

How much of the Unladen Swallow cPickle speedups have been incorporated into 2.7 & 3.1? I'm working on trying to develop patches for 2.4 and 2.6 (the two versions I currently care about at work - we will skip 2.5 entirely). It appears some of their speedups may have already been merged to trunk, but I'm not sure how much. If a patch to merge this to 2.7 is already under consideration I won't look at it, but I interpreted Collin Winter's response to my query on the u-s mailing list that … [View More]

3 4

Quick sum up about open() + BOM
by Victor Stinner Jan. 9, 2010

Jan. 9, 2010

Hi, Thanks for all the answers! I will try to sum up all ideas here. (1) Change default open() behaviour or make it optional? Guido would like to add an option and keep open() unchanged. He wrote that checking for BOM and using system locale are too much different to be the same option (encoding=None). Antoine would like to check BOM by default, because both options (system locale vs checking for BOM) is the same thing. About Antoine choice (encoding=None): which file modes would check … [View More]

9 13

--enabled-shared broken on freebsd5?
by Nicholas Bastin Jan. 9, 2010

Jan. 9, 2010

(This may occur on more platforms - I can test on more unix platforms if the consensus is this is an actual problem and I'm not just a nut) On freebsd5, if you do a simple ./configure --enable-shared in current (2.7) trunk, your python shared library will build properly, but all modules will fail to find the shared library and thus fail to build: gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_struct.o -L/u1/tmp/python2.7a1/lib -L/usr/local/lib -lpython2.… [View More]

4 7

relation between Python.asdl and Tools/compiler/ast.txt
by Yoann Padioleau Jan. 9, 2010

Jan. 9, 2010

Hi, I would like to use astgen.py to generate python classes corresponding to the AST of something I have defined in a .asdl file, along the line of what is apparently done for the python AST itself. I thought astgen.py would take as an argument a .asdl file, but apparently it instead process a file called ast.txt. Where does this file come from ? Is it generated from Python.asdl ?

2 5

Summary of Python tracker Issues
by Python tracker Jan. 9, 2010

Jan. 9, 2010

ACTIVITY SUMMARY (01/01/10 - 01/08/10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2544 open (+27) / 16937 closed (+15) / 19481 total (+42) Open issues with patches: 1017 Average duration of open issues: 708 days. Median duration of open issues: 464 days. Open Issues Breakdown open 2509 (+27) pending 34 ( +0) Issues Created Or Reopened (43) … [View More]

1 0