Mailman 3 February 2011 - Python-ideas

Alternative formatting styles for logging events in Python 3.3
by Nick Coghlan 10 Feb '11

10 Feb '11

Via the new "style" parameter to logging.Formatter objects, Python 3.2 adds support for newer formatting styles (str.format, string.template) when defining output formats for log messages. However, actual logging calls are still constrained to using %-formatting if they want to benefit from the "lazy formatting" feature (you can obviously generate pre-formatted messages any way you like). For 3.3, I'd like to propose extending this flexibility to the input side as well: 1. Add an optional style parameter to logging.Logger and logging.getLogger. This would then become the "default style" for any messages logged using that logger. In the case of getLogger, if the logger already exists and the styles don't match, raise an exception. 2. Add an optional style parameter to the Logger event recording methods (debug(), info(), et al) and the module level convenience functions. If supplied, this would override the default choice configured in the logger for that particular message. By default, all loggers (including the root logger) would continue to expect %-formatting. However, applications and libraries would be free to use the alternative formatting for their own logging without affecting other loggers. Thoughts? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Change the array declaration syntax.
by Arthur 08 Feb '11

08 Feb '11

(Sorry for any spelling errors, I'm using Google translator to write this message) Lists and tuples are data structures dynamically typed, and that's great! Makes writing code easier, and allows the developer to keep the focus on more important things. However, when these structures contain large amounts of elements, or when the program requires a lot of computational resources, dynamic typingbecomes a waste if the lists and tuples not use it. One way to avoid wasting resources with dynamic typing where it is unnecessary is to use the array class. The current syntax for creating arrays is: >>> from array import * #necessary to create lists of single type >>> var = array('i',[1,2,3]) #the first argument is the type and the second is the list This class is the solution when working with lists, but there is something similar when working with tuples. Thus, the variable "var" is a list, not a tuple, even if it is declared with with a tuple instead of a list: >>> var = array('i',(1,2,3)) >>> var array('i', [1, 2, 3]) I think, as well as raw strings in Python 2, lists and tuples could be declared a "single type" using a prefix. >>> var1 = i[1, 2, 3] # a singletype int list, as a current array >>> var2 = i('1', '2', '3') # a singletype int tuple, as a current array, but immutable My suggestion is to allow the type of element in the list or tuple is specified if the addition of a prefix before '[' or '('. This would simplify the use of arrays and improve the performance of programs that make use of lists of "single type". Besides creating tuples " single type". This seems more efficient, not wasting computing resources without polluting the code or make the language more complicated. For more information about the class array, the address of the documentation is http://docs.python.org/library/array.html . Thank You and Goodbye! Sig: Arthur Julião -------------------------------------------------- ---------------------------------------------- "Quero que a estrada venha sempre até você e que o vento esteja sempre a seu favor, quero que haja sempre uma cerveja em sua mão e que esteja ao seu lado seu grande amor." (Tempo Ruim - A Arte do Insulto - Matanza)

5 5

Add a feature similar to C++ "using some_namespace"
by Manuel Bärenz 08 Feb '11

08 Feb '11

In C++, the the approach to the namespace problem is having different namespaces that should not contain different definitions of the same name. Members of a namespace can be accessed explicitly by e.g. calling "std::cout<< etc." or "using namespace std; cout<< etc." I understand Pythons approach to be "objects can be used as namespaces and their attributes are the names they contain". I find this a very beautiful way of solving the issue, but it has a downside, in my opinion, because it lacks the "using" directive from C++. If the object is a module, we can of course do "from mymodule import spam, eggs". But if it is not a module, this does not work. Consider for example: class Spam(object): def frobnicate(self): self.eggs = self.buy_eggs() self.scrambled = self.scramble(self.eggs) return self.scrambled> 42 This could be easier to implement and read if we had something like: class Spam(object): def frobnicate(self): using self: eggs = buy_eggs() scrambled = scramble(eggs) return scrambled> 42 Of course this opens a lot of conceptual questions like how should this using block behave if self doesn't have an attribute called "eggs", but I think it is worth considering.

6 6