> > My concern about thread safety is about how easy it would be to make it > > thread unsafe accidentally. > > I'm intrigued what gives you the impression that Python functions and > classes are, by default, thread safe.
Well, there is thread safe, and there is thread dangerous. I have an enormous amount of code that is not strictly thread safe, but works fine when run under a multi-threaded web server because there are no cases where the same instances of objects are running in different threads. Well, not true, there are many shared function objects (and class objects). I very much assume that those function objects are not changing at run time. But having static variables would totally break that assumption. That would be like mutating class attributes, which, of course, is perfectly possible, but a little harder to do without thinking about it. or don't use shared mutable data. Exactly— and functions are always shared if you are using threads at all. But not mutable if used in the usual way. (Now that I think about it, the suggestions on this thread about putting things in the function namespace makes them mutable — but I at least have never done that. Function local static variables would be no worse in this regard than > existing features: globals, mutable default values, Mutable default values are a notable “gotcha”. classes with > attributes, etc. Yes, I think this is most like class attributes, which are probably less well known as a “gotcha”. But also not that widely used by accident. I don’t think I’ve even seen a student use them. And I sure have seen mutable default values mistakenly used in students' code. Another point -- whether there is a static variable in the function becomes a not obvious part of its API. That's probably the biggest issue -- some library author used static, and all its users may not know that, and then use the code in a multi-threaded application, or frankly in a single threaded application that isn't expecting functions to be mutated. Anyway, agreed — it is very easy to write not-thread safe code in Python now. So maybe this wouldn’t provide significantly more likelihood of it happening accidentally. One of the more disheartening things about the culture of this mailing > list is the way new proposals are held to significantly higher standards > that existing language and stdlib features do not meet. A lot of people (I thought you included) hold the view that new features SHOULD be held to a higher standard. > This is a perfect example: it's not like regular Python functions and > classes are thread-safe by default and this is introducing a new problem > that is almost unique to static variables. no -- but as above, functions themselves are immutable by default in normal usage --that would change. And since the entire point of classes is to hold state and the functions that work with that state in one place, it's expected behaviour that that state changes. Which makes me realize why I never wanted a function static variable -- if I wanted changable state associated with a function, I used a class. And most commonly there was more than one function associated with that state, so a class was the rigth solution anyway. I know that Jack Diederich says: "if a class has only two functions, and one of them is __init__ -- it's not a class", and I totally agree with him, but if you do have a case where you have some state and only one function associated with it, maybe a class IS the right solution. -CHB
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OX6IYZWC3SE2UEE7KXBPTI7FLHZ7DKW3/ Code of Conduct: http://python.org/psf/codeofconduct/
