Mailman 3 November 2009 - stdlib-sig

Re: [stdlib-sig] futures - a new package for asynchronous execution
by Brian Quinlan 21 Feb '10

21 Feb '10

On Nov 8, 2009, at 7:01 PM, Jeffrey Yasskin wrote: > Did you mean to drop the list? Feel free to cc them back in when you > reply. No, that was a brain malfunction. Redirecting the discussion to the list. > On Sat, Nov 7, 2009 at 3:31 PM, Brian Quinlan <brian(a)sweetapp.com> > wrote: >> >> On 8 Nov 2009, at 06:37, Jeffrey Yasskin wrote: >> >>> On Sat, Nov 7, 2009 at 7:32 AM, Jesse Noller <jnoller(a)gmail.com> >>> wrote: >>>> >>>> On Sat, Nov 7, 2009 at 10:21 AM, Antoine Pitrou <solipsis(a)pitrou.net >>>> > >>>> wrote: >>>>> >>>>>> Which API? My comment wasn't aimed at the API of the package - >>>>>> in the >>>>>> time I got to scan it last night nothing jumped out at me as >>>>>> overly >>>>>> offensive API-wise. >>>>> >>>>> Not offensive, but probably too complicated if it's meant to be >>>>> a simple >>>>> helper. Anyway, let's wait for the PEP. >>>> >>>> >>>> The PEP is right here: >>>> >>>> http://code.google.com/p/pythonfutures/source/browse/trunk/PEP.txt >>>> >>>> I'm interested in hearing specific complaints about the API in the >>>> context of what it's trying to *do*. The only thing which jumped >>>> out >>>> at me was the number of methods on FutureList; but then again, each >>>> one of those makes conceptual sense, even if they are verbose - >>>> they're explicit on what's being done. >>> >>> Overall, I like the idea of having futures in the standard library, >>> and I like the idea of pulling common bits of multiprocessing and >>> threading into a concurrent.* package. Here's my >>> stream-of-consciousness review of the PEP. I'll try to ** things >>> that >>> really affect the API. >>> >>> The "Interface" section should start with a conceptual description >>> of >>> what Executor, Future, and FutureList are. Something like "An >>> Executor >>> is an object you can hand tasks to, which will run them for you, >>> usually in another thread or process. A Future represents a task >>> that >>> may or may not have completed yet, and which can be waited for and >>> its >>> value or exception queries. A FutureList is ... <haven't read that >>> far>." >>> >>> ** The Executor interface is pretty redundant, and it's missing the >>> most basic call. Fundamentally, all you need is an >>> Executor.execute(callable) method returning None, >> >> How do you extract the results? > > To implement submit in terms of execute, you write something like: > > def submit(executor, callable): > future = Future() > def worker(): > try: > result = callable() > except: > future.set_exception(sys.exc_info()) > else: > future.set_value(result) > executor.execute(worker) > return future I see. I'm not sure if that abstraction is useful but I get it now. >>> and all the >>> future-oriented methods can be built on top of that. I'd support >>> using >>> Executor.submit(callable) for the simplest method instead, which >>> returns a Future, but there should be some way for implementers to >>> only implement execute() and get submit either for free or with a >>> 1-line definition. (I'm using method names from >>> >>> http://java.sun.com/javase/6/docs/api/java/util/concurrent/ExecutorService.… >>> in case I'm unclear about the semantics here.) run_to_futures, >>> run_to_results, and map should be implementable on top of the Future >>> interface, and shouldn't need to be methods on Executor. I'd >>> recommend >>> they be demoted to helper functions in the concurrent.futures module >>> unless there's a reason they need to be methods, and that reason >>> should be documented in the PEP. >>> >>> ** run_to_futures() shouldn't take a return_when argument. It should >>> be possible to wait for those conditions on any list of Futures. >>> (_not_ just a FutureList) >> >> I packaged up Futures into FutureLists to fix an annoyance that I >> have with >> the Java implementation - you have all of these Future objects but no >> convenient way of operating over them. > > Yep, I totally agree with that annoyance. Note, though, that Java has > the CompletionService to support nearly same use cases as > run_to_futures. CompletionService's use case is handling results as they finish (just like the callbacks do in Deferreds). The FutureList use case is querying e.g. which callables raised, which returned, which are still running? >> I made the FutureList the unit of waiting because: >> 1. I couldn't think of a use case where this wasn't sufficient > > Take your webcrawl example. In a couple years, when Futures are widely > accepted, it's quite possible that urllib.request.urlopen() will > return a Future instead of a file. Then I'd like to request a bunch of > URLs and process each as they come back. With the run_to_futures (or > CompletionService) API, urllib would instead have to take a set of > requests to open at once, which makes its API much harder to design. > With a wait-for-any function, urllib could continue to return a single > Future and let its users combine several results. If we go down this road then we should just switch to Twisted :-) Seriously, the idea is that no one would ever change their API to accommodate futures - they are a way of making a library with no notion of concurrency concurrent. But I am starting to be convinced that individual futures are a good idea because it makes the run/submit method easier to use. > Alternately, say you have an RPC system returning Futures. You've sent > off RPCs A, B, and C. Now you need two separate subsystems D and E to > do something with the results, except that D can continue when either > A or B finishes, but E can continue when either B or C finishes. Can D > and E express just what they need to express, or do they have to deal > with futures they don't really care about? > >> 2. It makes the internal locking semantics a bit easier and faster >> (if you >> can wait on any future then the wait has to acquire a lock for >> every future >> [in a consistent order to prevent deadlocks when other threads are >> doing the >> same thing with an intersecting set of futures], add a result >> listener for >> each and then great some sort of object to aggregate their state) > > Yep. I suspect the extra overhead isn't significant compared to the > cost of scheduling threads. > >> But I am thinking that maybe FutureLists aren't the right >> abstraction. >> >>> The code sample looks like Executor is a context manager. What does >>> its __exit__ do? shutdown()? shutdown&awaitTermination? I prefer >>> waiting in Executor.__exit__, since that makes it easier for users >>> to >>> avoid having tasks run after they've cleaned up data those tasks >>> depend on. But that could be my C++ bias, where we have to be sure >>> to >>> free memory in the right places. Frank, does Java run into any >>> problems with people cleaning things up that an Executor's tasks >>> depend on without awaiting for the Executor first? >>> >>> shutdown should explain why it's important. Specifically, since the >>> Executor controls threads, and those threads hold a reference to the >>> Executor, nothing will get garbage collected without the explicit >>> call. >> >> Actually, the threads hold a weakref to the Executor so they can >> exit (when >> the work queue is empty) if the Executor is collected. Here is the >> code from >> futures/thread.py: >> >> while True: >> try: >> work_item = work_queue.get(block=True, timeout=0.1) >> except queue.Empty: >> executor = executor_reference() >> # Exit if: >> # - The interpreter is shutting down OR >> # - The executor that owns the worker has been collected OR >> # - The executor that owns the worker has been shutdown. >> if _shutdown or executor is None or executor._shutdown: >> return > > Oh, yeah, that sounds like it might work. So why does shutdown exist? It does work - there are tests and everything :-) .shutdown exists for the same reason that .close exists on files: - Python does not guarantee any particular GC strategy - tracebacks and other objects may retain a reference in an unexpected way - sometimes you want to free your resources before the function exits > >>> ** What happens when FutureList.wait(FIRST_COMPLETED) is called >>> twice? >>> Does it return immediately the second time? Does it wait for the >>> second task to finish? I'm inclined to think that FutureList >>> should go >>> away and be replaced by functions that just take lists of Futures. >> >> It waits until a new future is completed. > > That seems confusing, since it's no longer the "FIRST" completed. Maybe "NEXT_COMPLETED" would be better. Cheers, Brian > >>> In general, I think the has_done_futures(), exception_futures(), >>> etc. >>> are fine even though their results may be out of date by the time >>> you >>> inspect them. That's because any individual Future goes >>> monotonically >>> from not-started->running->(exception|value), so users can take >>> advantage of even an out-of-date done_futures() result. However, >>> it's >>> dangerous to have several query functions, since users may think >>> that >>> running_futures() `union` done_futures() `union` cancelled_futures() >>> covers the whole FutureList, but instead a Future can move between >>> two >>> of the sets between two of those calls. Instead, perhaps an atomic >>> partition() function would be better, which returns a collection of >>> sub-lists that cover the whole original set. >>> >>> I would rename result() to get() (or maybe Antoine's suggestion of >>> __call__) to match Java. I'm not sure exception() needs to exist. >>> >>> --- More general points --- >>> >>> ** Java's Futures made a mistake in not supporting work stealing, >>> and >>> this has caused deadlocks at Google. Specifically, in a bounded-size >>> thread or process pool, when a task in the pool can wait for work >>> running in the same pool, you can fill up the pool with tasks that >>> are >>> waiting for tasks that haven't started running yet. To avoid this, >>> Future.get() should be able to steal the task it's waiting on out of >>> the pool's queue and run it immediately. >>> >>> ** I think both the Future-oriented blocking model and the >>> callback-based model Deferreds support are important for different >>> situations. Futures tend to be easier to program with, while >>> Deferreds >>> use fewer threads and can have more predictable latencies. It should >>> be possible to create a Future from a Deferred or a Deferred from a >>> Future without taking up a thread.

6 20

standardizing the deprecation policy (and how noisy they are)
by Brett Cannon 14 Nov '09

14 Nov '09

During the moratorium PEP discussions Guido said he wanted to quiet down deprecation warnings. I see there being two options on this. One is to keep things as is, but to require two releases with PendingDeprecationWarning so there are three years of silent-by-default warnings to update your code. But that last release before removal came would still be noisy. The other option is to simply have all warnings filtered out by default. We could alter -W so that when it is used w/o an argument it turns to what is currently the default behaviour (or even turn all warnings which is more than what happens now). This will require that people proactively check for warnings when updating for compatibility, else they will eventually use a Python release where there code will simply break because something changed. This route means we do not have to specify any deprecation policy right now (that would be a separate discussion). Channeling Guido he is after the latter, but a general discussion would still be good since he didn't explicitly say what he was after other than to quiet down warnings. -Brett

20 73

futures - a new package for asynchronous execution
by Brian Quinlan 13 Nov '09

13 Nov '09

Hey all, I'd like to propose adding a module/package to Python that makes it easy to parallelize arbitrary function calls. I recently wrote a solution for the use case of parallelizing network copies and RPC using threads without forcing the user to explicitly creating thread pools, work queues, etc. I have a concrete implementation that I'll describe below but I'd be happy to hear about other strategies! The basic idea is to implement an asynchronous execution method patterned heavily on java.util.concurrent (but less lame because Python has functions as first-class objects). Here is a fairly advanced example: import futures import functools import urllib.request URLS = [ 'http://www.foxnews.com/', 'http://www.cnn.com/', 'http://europe.wsj.com/', 'http://www.bbc.co.uk/', 'http://some-made-up-domain.com/'] def load_url(url, timeout): return urllib.request.urlopen(url, timeout=timeout).read() # Use a thread pool with 5 threads to download the URLs. Using a pool # of processes would involve changing the initialization to: # with futures.ProcessPoolExecutor(max_processes=5) as executor with futures.ThreadPoolExecutor(max_threads=5) as executor: future_list = executor.run_to_futures( [functools.partial(load_url, url, 30) for url in URLS]) # Check the results of each future. for url, future in zip(URLS, future_list): if future.exception() is not None: print('%r generated an exception: %s' % (url, future.exception())) else: print('%r page is %d bytes' % (url, len(future.result()))) In this example, executor.run_to_futures() returns only when every url has been retrieved but it is possible to return immediately, on the first completion or on the first failure depending on the desired work pattern. The complete docs are here: http://sweetapp.com/futures/ A draft PEP is here: http://code.google.com/p/pythonfutures/source/browse/trunk/PEP.txt And the code is here: http://pypi.python.org/pypi/futures3/ All feedback appreciated! Cheers, Brian

10 53

Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
by Laura Creighton 10 Nov '09

10 Nov '09

In a message of Mon, 09 Nov 2009 07:10:08 +0100, Antoine Pitrou writes: > >> There is also the argument that if people are told they have to >> explicitly turn on warnings to get them and the switch turns them all >> on then it might be the case that more people will see and deal with >> PendingDeprecationWarnings than they do now. The arguments that people >> will not switch them on is based on current practice. Guido's and >> Greg's argument is that habits will change such that it is not going >> to be an issue. > >Well as I said this helps only if the package has 100% test coverage, >such that the developer is sure to exercise all code paths when he/she >runs the test suite with warnings explicitly enabled. > >Besides, as Yuvgoog pointed out, this would not help the casual hobbyist >programmer (or professional non-programmer, such as a scientist) who >doesn't really have a clue that those warnings exist and are important >to check for. > >Regards > >Antoine. Experience has shown that when people get used to seeing 'a bunch of warnings that don't really matter' they either a) turn them off or b) ignore them, even when they are telling them valuable things that they should be paying attention to. So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings. I appreciate the desire to help the casual programmer, but it is not clear to me that this will turn out to actually be helpful. Teaching people to run their code through some sort of code-checker every so often strikes me as more likely to be so. Laura

8 11

standardizing the deprecation policy (and how noisy they are)
by Nicolas Chauvat 10 Nov '09

10 Nov '09

Hi List, Guido said: > At Google we use a hacked-up version of pylint which seems infinitely > flexible in the checks you can specify. I assume that the public > version of pylint is just as capable -- someone just needs to write a > rule for it. Now that you mention it... I have tried in the past to get people from Google to contribute these changes back to the trunk_, but without success. There will be a `pylint bug day`_ via internet on nov 25th, 2009. Any chance you could pass the info to the Google employees in charge of the hacked-up version of pylint ? .. _trunk: http://www.logilab.org/hg/pylint .. _`pylint bug day`: http://www.logilab.org/blogentry/18781 Thanks in advance, PS: If someone else from the list is reading this and wants to join and maybe implement the checking rule mentionned above in the thread, please do! -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances

1 0

Re: [stdlib-sig] standardizing the deprecation policy (and hownoisy they are)
by Laura Creighton 10 Nov '09

10 Nov '09

In a message of Mon, 09 Nov 2009 20:03:33 EST, geremy condra writes: >On Mon, Nov 9, 2009 at 7:01 PM, Guido van Rossum <guido(a)python.org> wrote >: >> On Mon, Nov 9, 2009 at 3:44 PM, geremy condra <debatem1(a)gmail.com> wrot >e: >>> the idea >>> that we shouldn't put blinking lights and sirens on the crushomatic 90 >00 >>> because people might eventually ignore them doesn't strike me as being >>> all that smart. >> >> I'm sorry, but you're really not getting the point. The crushomatic >> already *has* a blinking light and a siren and everyone is *already* >> ignoring them, because they go off all the time, whenever a person >> gets closer than 6 feet. So we have no way to warn them when there >> *really* is a danger, like when a person is about to put their hand >> into the blender. >> >> The solution is to make the machine less dangerous (e.g. if you open >> the lid the motor is cut off), not to argue that the siren is really >> important. > >Rereading my post I don't see any place where I seem to have >argued that deprecation warnings were "really important", but >in case that's how it sounded, let me clarify: I don't think this >argument is anything other than lots and lots of bikeshedding, >since these warnings can already be explicitly silenced by the >very people this is designed to protect. My point is that 'designing to protect people' is not enough, you need to actually protect them. And while in general 'logically this should protect them' is enough -- (and what intelligent people often mean by 'designing to protect people') -- when it comes to issues of cognative psychology, the important lessons to learn are the ones that teach you is where this one fails ---- by trying to protect X, or at least make it easier for X, you end up making it harder. >Having said that, if you think that deprecation warnings are >mostly noise, why not ask the pylint and pychecker devs to >handle that and drop the warnings altogether? I am all for this. And I am all for Marc André's suggestion to raise the barrier for deprecations themselves as well. Laura > >Geremy Condra >_______________________________________________ >stdlib-sig mailing list >stdlib-sig(a)python.org >http://mail.python.org/mailman/listinfo/stdlib-sig

3 3

Re: [stdlib-sig] standardizing the deprecation policy (and hownoisy they are)
by Laura Creighton 10 Nov '09

10 Nov '09

In a message of Mon, 09 Nov 2009 18:14:07 EST, geremy condra writes: >On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger <python(a)rcn.com> wrote: >> >> [Brett Cannon] >>> >>> This is obviously coming down to difference of opinion. I don't view >>> switching warnings off by default as shooting anyone in the foot. I >>> put it on the same level as making sure you have unit tests; it's just >>> part of your testing and verification process that your users just >>> don't need to know about. >> >> Nice summary. FWIW, I concur with Brett. No one needs to see >> warnings/deprecations except for the developer who controls the code. >> Even that developer may only need to see it at one point during the >> development process. Further, the developer controlling the code >> just may not care -- the script can be for single use, for a class proj >ect, >> or some other purpose that doesn't require being notified of what may >> change in a later version of Python. >> >> >> Raymond > >If they don't care, why does it matter whether they see it or not? >Seems like an argument for the status quo. > >Geremy Condra The reason that it matters is that having seen it a few times may make it impossible for them to see it in the future. We studied precisely this in determining 'how often should C programmers run lint' back in the 1980s for DCIEM (The Canadian department of War). I started out as a firm proponent of 'you should run lint every time' and 'you should fix your lint errors as soon as you see them'. It turned out that this was the wrong idea. Most people were completely unable to fix their lint errors as they showed up. They were unable to _see_ their lint errors as they showed up. Because they were concentrating on the code that they were writing, all errors and warnings about code that wasn't the focus of their concentration didn't register with them consciously. They were blind to these errors and warnings because their concentration was somewhere else. Which wouldn't be so bad if, once they stopped concentrating on the code they were writing, they were then free to see the lint errors again, and fix them then. But a very strange thing had happened by that point. They had become used to the lint errors that they weren't paying attention to, and so they _still_ couldn't see them, even when they wanted to, because they were habituated to them. It was striking. You could ask the people to read their lint output, looking for 'Warning: long assignment may lose accuracy' messages, and they would read right by that message, and say, no, they didn't have one. You could get them to read all of their lint messages, out loud, to the whole room, and they would read them one by one, including the one that said 'Warning: long assignment may lose accuracy' and go on to the next message and _still_ not notice that they had found what you had asked them to look for. These are people who are most sincere in looking for these errors, those who dearly wanted to fix them at this point in time. But the development process that they had at this time destroyed their ability to make use of the warnings that lint was giving them. To use lint well, they needed to use it _only_ when they were at a point in their thinking when they were receptive to seeing such messages. (And, given that we were giving the poor bastards problems in string manipulation, which they all had to do with C pointer arithmetic, and that many of the soldiers were sticking with ed, the editor they knew, rather than newfangled things such as emacs, and the HCR screen editor -- this was before vi, they had one heck of a lot to keep in their heads when they were programming. Lots of the time they were not receptive to seeing any warnings at all.) What we concluded was that people should only run lint on their C programs when they wanted to fix those errors lint found. While they were busy concentrating on other things, they shouldn't run it. And it is bad to warn people unless you already have their attention, and they are looking for warnings. Otherwise, they may habituate themselves to seeing the warning, and you will lose your chance to ever warn them. Does this generalise to 'Python should never raise warnings unless they are asked for'? I don't know. The v7 lint of 1983 or so was one of the chattiest programs on the planet. And most of the warnings that our soldiers got were about bad code in somebody else's library which they couldn't modify anyway. So the pressure to become blind to warnings -- all warnings -- was pretty high. This isn't the case with Python. And the cognitive load to program at all, doing string manipulation in C using ed as your programming language of choice ... I know that at the time I did not think I was doing anything particularly difficult, but I was 20 then. I cannot imagine doing it now. What I object to is the blind acceptance of the notion that 'it will do good for programmers to see deprecation warnings that they were not expecting or looking for'. All the evidence I know runs against this one - first they won't see them because they weren't looking for them ... their minds are on other things, and then they won't see them because they _CANNOT_ any more, because they have been overly exposed to such things. It would be really nice to run a cognitive experiment to test how well warning messages are seen. We ran one at DCIEM to test this. We had our soldiers' lint runs changed so that for each of them, 8 times in a day, they would get a lint warning that would instruct them to say a certain word to a certain person (in the room where the printer was) for a small reward ... a chocolate bar, a piece of pie, and the important note on their service record that they were an exceptionally observant person. In a group of 35 soldiers, we generally got 4-5 who saw every message and 18-22 who saw none. Of course, this was _after_ they had been habituated to seeing the messages. I don't know how it would work for fresh students. One thing we were able to prove -- which has been amply demonstrated by others -- is that newbies who lack the experience to trust their ability to 'overlook those things that do not matter' are those best served by warning messages. They pay attention better than the experienced. But I don't see any way to identify new python users and give them more warnings than others showing up any time soon. Laura

1 0

Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
by Laura Creighton 09 Nov '09

09 Nov '09

In a message of Mon, 09 Nov 2009 17:35:35 +1100, Ben Finney writes: >Laura Creighton <lac(a)openend.se> writes: > >> So constantly spitting out DeprecationWarnings as soon as something >> becomes deprecated is a most excellent way to train people to ignore >> DeprecationWarnings. >[â¦] > >> Teaching people to run their code through some sort of code-checker >> every so often strikes me as more likely to be [helpful]. > >Why is one of these helpful but the other one not so? Why can't the run >your code through a code-checker remain as easy as running the code >with the next version of Python? > >Ben Finney Because casual programmers are not motivated to go after Deprecation Warnings and modify their code to make such things go away. They're coding to a different standard, one where you don't go off and change things unless you absolutely have to. So lots of DeprecationWarnings will only train them to ignore DeprecationWarnings, or all Warnings. Laura

3 3

Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
by Laura Creighton 09 Nov '09

09 Nov '09

In a message of Mon, 09 Nov 2009 12:37:05 +0100, Antoine Pitrou writes: >Le lundi 09 novembre 2009 Ã 09:17 +0100, Laura Creighton a Ã©crit : >> The conclusion is that 'surprising' people with unexpected warnings >> is less useful than one would think -- people tend to overlook them, >> and thus not be surprised. > >Whether or not it's "less useful than one would think" doesn't make it >useless. There are many things which fall under the former predicate and >not under the latter. For example documentation (many people don't read >it), unit tests (they give a false sense of security)... do you suggest >we drop them too? Ok, I was not strong enough. Here is what I believe: Take some sample set of 2000 programs, all of which use features which are scheduled to be deprecated. Divide them into two groups of 1000. In group A you issue DeprecationWarnings for one whole release before the one where this code will break, unless the programmer explicitly turns them off. In group B you don't issue any warnings unless the programmer asks for them. Come the day when /env/python now points to the new release, which group do you believe will have done a better job of modernising their programs? My belief is that this will be group B. I think that the number of programmers in group A who no longer saw the warnings because they were always there will greatly outnumber the ones who never run their programs with warnings turned on, and thus were completely unaware of the problem in the first place. But I am making some assumptions here -- one is that these programs will be run fairly frequently. The second assumption is that the number of programs for whom the fix will be 'change the first line to #! /usr/bin/env/some-older-version-of-python' is small. I don't know if those are decent assumptions to make. I don't have anything approaching real data as to how Python programs exist out there in the world. The "does providing Deprecation Warnings when unasked for actually help" experiement would be interesting to run. This is the sort of thing we need real numbers for, but I haven't seen any experiments to test this so far. All I have seen is indications from cognative psychology that it is really hard for people to see things when they are concentrating on something else. For instance there is the test here http://viscog.beckman.illinois.edu/media/dailytelegraph.html 'view the basketball video' which is explained here: http://www.scholarpedia.org/article/Inattentional_blindness I think that we have two things to worry about here, inattentional blindness (which is what the video tests) and problems caused by insufficient attention (as opposed to inattention). And, links that I posted before which say that people really only see what they expect, rather than what is there, and that our brains are heavily optimised for 'ignoring stuff that doesn't matter' which gets in the way of us noticing stuff that does matter. Unless we expect this. Laura

2 1

Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
by Laura Creighton 09 Nov '09

09 Nov '09

In a message of Mon, 09 Nov 2009 07:39:30 +0100, Antoine Pitrou writes: > >> Experience has shown that when people get used to seeing 'a bunch of >> warnings that don't really matter' they either a) turn them off or >> b) ignore them, even when they are telling them valuable things that >> they should be paying attention to. So constantly spitting out >> DeprecationWarnings as soon as something becomes deprecated is a >> most excellent way to train people to ignore DeprecationWarnings. > >Well at least people get a chance to see them. If some people think the >warnings are useless (even though the messages warn about removal of a >construct), they won't run a code checker either. This is not true. Once people get into the habit of 'not seeing' things, they don't see them even when they are important. This is not only true of program warnings -- somebody has done a study of how cancerous tumours are overlooked. In one particularly frightening study, doctors at the Mayo clinic went back and checked the previously 'normal' chest X-rays of patients who subsequently developed cancer. What they found was horrifying: 90% of the tumours were visible on the previous Xrays. (see Lorenz, G.B.A. et. al 1999 Miss Rate of Lung Cancer on the Chest Radiograph in Clinical Practice in _Chest_ also Berlin, Leonard 2000 Hindsight Bias in _American Journal of Roentgenology_) A test in 2002 indicated that the TSA missed 1 in every 4 guns that were attempted to be smuggled in. In 2004 a test at Newark's airport indicated the same thing. At 2005 test at O'Hare's airport had 60% of bombs and explosive materials missed, while security officials in L.A. missed 75%. (I don't have the papers for this, I read this as a clipping from the Wall Street Journal, which didn't list its sources.) So this 'it's there, but we didn't see it' is a serious problem with wideranging implications outside of generating computer warnings. But we know some things about this. The reason we are lousy at detecting such things is in large part because they are rare. Most chest Xrays show no cancer. Most bags do not contain weapons and guns. We're only good at detecting things when a) we are looking for them and b) they actually occur relatively commonly where we are looking. As what we are looking for becomes more and more rare, then we are more and more likely to overlook them when they do occur. There are lots of cognitive psychology experiments to test this, for instance: Levin and Simons 1997 Failure to Detect Changes to Attended Objects in Motion Pictures _Psychonomic Bulletin and Review_ The conclusion is that 'surprising' people with unexpected warnings is less useful than one would think -- people tend to overlook them, and thus not be surprised. It's better when people get warnings which they have asked to see. Then they tend to notice them. But poorest of all is when people have trained themselves not to see warnings at all. >If Mercurial users and developers hadn't seen those warnings at all, >perhaps Mercurial would have continued using deprecated constructs, and >ended up broken when the N+1 Python version had been released. If even >an established FLOSS project such as Mercurial is vulnerable to this >kind of risk, then any in-house or one-man project will be even more >vulnerable. I agree, but I think that Mercurial developers ought to include a set of people who are interested in looking at warnings precisely to prevent such things. Thus their use case is different from that of the casual programmer, or the user of Mercurial who has no intention of doing anything with any warnings that ever show up. The first group will notice things the most if they get warnings when they explicitly ask for it. If the warnings show up unasked for, they too can be expected to get into the habit of ignoring them. ('oh they are just warnings'). But I don't know the precise point where producing such warnings becomes more harmful than helpful. As far as I know, nobody has run any experiements to determine this. But I would suspect that blasting out all the DeprecationWarnings for 3 whole releases before something goes away would err on the 'so frequent that it is ignored' side. >Besides, do we have such a code checker that is able to find out >deprecated constructs (not talking about 2to3 here) ? I was thinking of something more primative, such as running your code with all warnings on from time to time. Laura

2 1