Re: [Python-3000] self-contained exceptions
On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > How about: > > > > except ExcType, e: > > try: > > # body > > finally: > > e = None > > del e > > > > Then we get the best of all three worlds: a clean explanation, a clean > > implementation, and a pure source-to-source transformation. > > Great! We need (a) an update to PEP 3100 and (b) a patch to implement > this. (Once we have this we can talk about the rest of PEP 344; > perhaps that PEP should also target Py3k only?) I've just uploaded patch #1630248 to SF. This implements the transformation (including test cases for the new behavior) and patches all places in the stdlib that relied on the old behavior. The transformation is as Phillip outlined above, with extra logic to handle the case where e is a tuple or list. Thanks, Collin Winter ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] self-contained exceptions
On 1/7/07, Collin Winter <[EMAIL PROTECTED]> wrote: On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > How about: > > > > except ExcType, e: > > try: > > # body > > finally: > > e = None > > del e > > > > Then we get the best of all three worlds: a clean explanation, a clean > > implementation, and a pure source-to-source transformation. > > Great! We need (a) an update to PEP 3100 and (b) a patch to implement > this. (Once we have this we can talk about the rest of PEP 344; > perhaps that PEP should also target Py3k only?) I've just uploaded patch #1630248 to SF. This implements the transformation (including test cases for the new behavior) and patches all places in the stdlib that relied on the old behavior. The transformation is as Phillip outlined above, with extra logic to handle the case where e is a tuple or list. Having 'e' be a tuple or list in Py3K will be rather uncommon? If you look at PEP 352 you will notice that the __getitem__ method for BaseException is going to be gone so the unpacking of an exception will not be something you can normally do. If you want to add the support for unpacking when someone subclasses BaseException and adds __getitem__ that's fine, but in the general case it won't be used very much I suspect. -Brett ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Warning for 2.6 and greater
I've been thinking a little about how and where we'd add warnings to 2.6 and later for things that will break in 3.0. My first idea is to add a command line option '-3' (or maybe '-warn3') implemented as "from __future__ import py3k". We can then put code in that optionally generates a warning if this is set. I'm concerned that we don't make this check too expensive, though - but it should be doable. A good proof-of-concept for someone keen (I'm totally out of time for the rest of this month) would be to whip up something that works and spits out a warning for, say, dictobject.c:dict_has_key(), but only when the flag is specified. Anyone else have alternate ideas? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Warning for 2.6 and greater
On 1/7/07, Anthony Baxter <[EMAIL PROTECTED]> wrote: > I've been thinking a little about how and where we'd add warnings to > 2.6 and later for things that will break in 3.0. My first idea is > to add a command line option '-3' (or maybe '-warn3') implemented > as "from __future__ import py3k". We can then put code in that > optionally generates a warning if this is set. > > I'm concerned that we don't make this check too expensive, though - I have re-implemented warnings in C which should speed things up a bit (including start up). I need to polish it off and up load it. n ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] self-contained exceptions
At 09:14 PM 1/7/2007 -0600, Collin Winter wrote: >On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > How about: > > > > > > except ExcType, e: > > > try: > > > # body > > > finally: > > > e = None > > > del e > > > > > > Then we get the best of all three worlds: a clean explanation, a clean > > > implementation, and a pure source-to-source transformation. > > > > Great! We need (a) an update to PEP 3100 and (b) a patch to implement > > this. (Once we have this we can talk about the rest of PEP 344; > > perhaps that PEP should also target Py3k only?) > >I've just uploaded patch #1630248 to SF. This implements the >transformation (including test cases for the new behavior) and patches >all places in the stdlib that relied on the old behavior. > >The transformation is as Phillip outlined above, with extra logic to >handle the case where e is a tuple or list. In the tuple or list case, there's no need to reset the variables, because then the traceback won't be present any more; the exception object will have been discarded after unpacking. ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Warning for 2.6 and greater
On Monday 08 January 2007 16:50, Anthony Baxter wrote:
> I've been thinking a little about how and where we'd add warnings
> to 2.6 and later for things that will break in 3.0. My first idea
> is to add a command line option '-3' (or maybe '-warn3')
> implemented as "from __future__ import py3k". We can then put
> code in that optionally generates a warning if this is set.
Ok, I lied - I implemented this pretty easily just now (patch
attached). As a first pass, I put in warnings for dict.has_key and
the builtin apply() function.
I've changed my mind about the from future statement. I think that
'from __future__ import py3k' says "please use whatever backwards
incompatible 3.x features that you support". I guess we could have
something like 'from __future__ import warn3k', perhaps. But this
wouldn't take effect for just the current source file, so could be
confusing.
If people are happy with this, I'll check it into the trunk, then
people can go crazy adding other warnings for 3.0-isms.
beaker% ./python
Python 2.6a0 (trunk:53285:53286M, Jan 8 2007, 18:34:47)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> 1 in {}
False
>>> {}.has_key(1)
False
>>> apply(lambda x:None, (1,))
>>>
beaker% ./python -3
Python 2.6a0 (trunk:53285:53286M, Jan 8 2007, 18:34:47)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> 1 in {}
False
>>> {}.has_key(1)
__main__:1: DeprecationWarning: dict.has_key not supported in 3.x
False
>>> apply(lambda x:None, (1,))
__main__:1: DeprecationWarning: apply() not supported in 3.x
>>>
Anthony
Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c (revision 53285)
+++ Python/bltinmodule.c (working copy)
@@ -144,6 +144,12 @@
PyObject *func, *alist = NULL, *kwdict = NULL;
PyObject *t = NULL, *retval = NULL;
+if (Py_Py3kWarningFlag &&
+PyErr_Warn(PyExc_DeprecationWarning,
+"apply() not supported in 3.x") < 0) {
+return NULL;
+}
+
if (!PyArg_UnpackTuple(args, "apply", 1, 3, &func, &alist, &kwdict))
return NULL;
if (alist != NULL) {
Index: Include/pydebug.h
===
--- Include/pydebug.h (revision 53285)
+++ Include/pydebug.h (working copy)
@@ -20,6 +20,8 @@
on the command line, and is used in 2.2 by ceval.c to make all "/" divisions
true divisions (which they will be in 3.0). */
PyAPI_DATA(int) _Py_QnewFlag;
+/* Warn about 3.x issues */
+PyAPI_DATA(int) Py_Py3kWarningFlag;
/* this is a wrapper around getenv() that pays attention to
Py_IgnoreEnvironmentFlag. It should be used for getting variables like
Index: Objects/object.c
===
--- Objects/object.c (revision 53285)
+++ Objects/object.c (working copy)
@@ -29,6 +29,7 @@
#endif /* Py_REF_DEBUG */
int Py_DivisionWarningFlag;
+int Py_Py3kWarningFlag;
/* Object allocation routines used by NEWOBJ and NEWVAROBJ macros.
These are used by the individual routines for object creation.
Index: Objects/dictobject.c
===
--- Objects/dictobject.c (revision 53285)
+++ Objects/dictobject.c (working copy)
@@ -1647,6 +1647,11 @@
long hash;
dictentry *ep;
+if (Py_Py3kWarningFlag &&
+PyErr_Warn(PyExc_DeprecationWarning,
+"dict.has_key not supported in 3.x") < 0) {
+return NULL;
+}
if (!PyString_CheckExact(key) ||
(hash = ((PyStringObject *) key)->ob_shash) == -1) {
hash = PyObject_Hash(key);
@@ -1660,6 +1665,24 @@
}
static PyObject *
+dict_contains(register dictobject *mp, PyObject *key)
+{
+ long hash;
+ dictentry *ep;
+
+ if (!PyString_CheckExact(key) ||
+ (hash = ((PyStringObject *) key)->ob_shash) == -1) {
+ hash = PyObject_Hash(key);
+ if (hash == -1)
+ return NULL;
+ }
+ ep = (mp->ma_lookup)(mp, key, hash);
+ if (ep == NULL)
+ return NULL;
+ return PyBool_FromLong(ep->me_value != NULL);
+}
+
+static PyObject *
dict_get(register dictobject *mp, PyObject *args)
{
PyObject *key;
@@ -1932,7 +1955,7 @@
"D.iteritems() -> an iterator over the (key, value) items of D");
static PyMethodDef mapp_methods[] = {
- {"__contains__",(PyCFunction)dict_has_key, METH_O | METH_COEXIST,
+ {"__contains__",(PyCFunction)dict_contains, METH_O | METH_COEXIST,
contains__doc__},
{"__getitem__", (PyCFunction)dict_subscript, METH_O | METH_COEXIST,
getitem__doc__},
Index: Modules/main.c
===
--- Modules/main.c (revision 53285)
+++ Modules/main.c (working copy)
@@ -40,7 +40,7 @@
static int orig_argc;
/* command line options */
-#define BASE_OPTS "c:dEhi
