Re: deprecated string module issue
On Thu, Jun 24, 2010 at 10:39 AM, GrayShark wrote: > Sorry, I meant "from string import lowercase, uppercase" > > As I was joining these two, I just changed the import to 'letters' > > So if the constants are not deprecated, why is the module? Is some > other > state then deprecated needed to describe functions and/or methods > deprecated, > but not whole modules? > > It just seems wrong, this all or nothing state. > Huh? Again: the string module is not deprecated. It simply is not. Certain functions in it were deprecated. Those were clearly marked in the documentation as deprecated -- since 2.0-ish if memory serves, if not that early, then not too long into 2.x. Those deprecated functions have been removed as of 3.x. If pylint is reporting the entire module is deprecated, pylint is wrong. Its not deprecated. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Fri, Jun 25, 2010 at 8:24 PM, WANG Cong wrote: > > Here's the thing: Python doesn't consider creating dynamic attributes > > to be questionable. Python doesn't merely allow for dynamicism, it > > encourages it. And encouraging something means to make it simple. > > > > Understand, but please consider my proposal again, if we switched to: > > setattr(foo, 'new_attr', "blah") > > by default, isn't Python still dynamic as it is? (Please teach me if I > am wrong here.) > > This why I said the questionable thing is not so much related with dynamic > programming or not. > In what possible way is: setattr(foo, 'new_attr', 'blah') getattr(foo, 'new_attr') delattr(foo, 'new_attr') Better then: foo.new_attr = 'blah' foo.new_attr del foo.new_attr I don't understand what your argument is or problem is with the regular syntax, if you want to allow the former (all of which is currently possible in Python if you prefer this style) but not the latter (all of which also works, it just uses normal syntax as everyone would expect). Do you think it should be somehow "tricky" or "more difficult" to dynamically modify an instance at runtime? For that to hold, you have to provide some pretty compelling reasoning why dynamically modifying an instance at runtime is Not Good. Only then is there a good reason to make it more difficult. (Since Python doesn't really restrict things, just makes certain rare things that are undesirable a little harder to do) --Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Class-level variables - a scoping issue
On 10/9/10 10:30 PM, John Nagle wrote: > Python protects global variables from similar confusion > by making them read-only when referenced from an inner scope > without a "global" statement. No. It doesn't. Assignments simply always apply to local variables, unless you explicitly indicate otherwise. There is no "protection" going on here. Its the exact same principle of what's going on with classes/instances; assignment to an instance always apply to variables local to that instance-- and not global to the class-- unless you explicitly indicate otherwise. There is no protection of the global going on: in all cases, you can create a new local variable that shadows the global that was previously there. The syntax is just different. For regular, free variables, you "explicitly indicate otherwise" by using the global statement. For class/instance variables, you "explicitly indicate otherwise" by doing class.var or self.__class__.var = whatever. Yes, the behavior of "get" and "set" are distinctly different. "get" in all cases -- both free variables in functions, and when getting attributes from your instance -- looks up the tree, starting at your most local namespace and walking up until it finds what you want. For free variables, this is a short list: locals(), enclosing nested function scopes, globals(), builtins. For attributes, it starts on your instance, then goes to the class, then up the superclass tree. The "sets" in all cases don't walk up the tree at all. They only set in the most local namespace, unless again, you explicitly tell it to do something else. Sure, this means you can accidentally shadow a global and run into problems. It also means you can forget that "explicitly tell it" and run into other problems. But its still a feature, and basically part of the core, fundamental object model of Python. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
