[Python-Dev] Apologies from the CBS autoresponder
My many apologies to those who had their New Year interrupted by my company's inane autoresponder. I'm afraid that I went on leave for a week without suspending list delivery just as my company changed its name and sent out (unknown to me) an automatic message to *everything* coming in to the old address. I've pulled the plug on that address's subscription, altho' I suspect some list admin got there before me. Apologies again. Tim Golden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: pydev summary for 2006-12-01 to 2006-12-15
Calvin Spealman wrote: > [...] > --- > Creating dicts from dict subclasses > --- > > A common problem of subclassing built-in types (dict, in this case) arose > trying > to move weakref.WeakValueDictionary to a subclass of dict, rather than > UserDict. > > [NOTE: Could someone give a better description of this? I don't know enough of > the issue here to write any content full enough. Thanks.] The problem is that if you pass a mapping (i.e. something with a keys() method) to the dict constructor, it uses keys() and __getitem__() to make a copy. However if the argument is a subclass of dict, any overwritten keys() or __getitem__() methods are ignored. Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000-checkins] r53335 - in python/branches/p3yk: Doc/Makefile.deps Doc/lib/lib.tex Doc/lib/libsets.tex Doc/lib/libstdtypes.tex Lib/msilib/__init__.py Lib/sets.py Lib/test/test
On 1/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > Should we bother with deprecating 'sets' in the 2.x series? I'd say so, yes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
cc'ing python-dev - followups should probably go there, rather than the p3yk list. So here's my latest plan: - Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning (or maybe just of Warning) - Add a -W py3k shortcut, which is the same as "-W once:Py3kDeprecationWarning" - Add a C int (as in previous patch) that is also set to 1 if the command line flag is specified. This is because there's no easy or quick way to check that a warning has been set - and calling into the warnings code is expensive, even if the C code warnings module is done. We can revisit this if the C version of warnings grows some extra features to make this less awful. For 2.6, we make a single -t (mixing tabs and spaces) the default, and maybe add -T to suppress this. DeprecationWarning for 2.6: - `foo` (backticks) - input() The following are the list of things that get Py3kDeprecationWarnings (so far): integer division - make "-Q warn" the default when -W py3k specified coerce() - going away apply() - going away intern() - moving to sys (we should also move it to sys, and make intern() - call sys.intern()) file.xreadlines() - going away dict.has_key() - use 'in dict' <> - use != (aka "MakeBarryCryDeprecationWarning") __(get|set|del)slice__ __coerce__ - gone __(div|idiv|rdiv)__ - no replacement? __nonzero__ - we should add __bool__ to 2.6, and then warn people. Not sure we can rename the nb_nonzero slot, though. For the various __foo__ slots, it might be nice to warn when they're defined, rather than used, but I've not looked into how hard this would be to do, or whether it would still work with .pyc files and the like. On the other hand, warning on use might also let us pick up when C code modules use the same functions. There's other changes that are probably too hard to warn about, because there's not an easy replacement - the exec and print statements come to mind here. Comments? What else should get warnings? Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
