Mailman 3 August 2012 - Python-ideas

Re: [Python-ideas] issue15824
by Ben Toews 10 Sep '12

10 Sep '12

Hello, We have been discussing the value of having namedtuple as the return type for urlparse.urlparse and urlparse.urlsplit. See that thread here: http://bugs.python.org/issue15824 . I jumped the gun and submitted a patch without seeing if anyone else thought different behavior was desirable. My argument is that it would be a major usability improvement if the return type supported item assignment. Currently, something like the following is necessary in order to parse, make changes, and unparse: import urlparse url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha')) url[1] = 'python.com' new_url = urllib.urlunparse(url) I think this is really clunky. I don't see any reason why we should be using a type that doesn't support item assignment and needs to be casted to a another type in order to make changes. I think an interface like this is more useful: import urlparse url = urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha') url.netloc = 'www.python.com' urlparse.urlunparse(url) What do other people think? -- -Ben Toews

3 2

itertools.chunks(iterable, size, fill=None)
by anatoly techtonik 03 Sep '12

03 Sep '12

Now that Python 3 is all about iterators (which is a user killer feature for Python according to StackOverflow - http://stackoverflow.com/questions/tagged/python) would it be nice to introduce more first class functions to work with them? One function to be exact to split string into chunks. itertools.chunks(iterable, size, fill=None) Which is the 33th most voted Python question on SO - http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-even… P.S. CC'ing to python-dev@ to notify about the thread in python-ideas.

15 25

Verbose traceback formatting
by Mike Graham 31 Aug '12

31 Aug '12

It's possible to give a lot more on error than the default traceback gives you. I propose that Python should ship a more verbose formatter and a command line switch to use it. Here's an example of IPython's verbose formatter. I wrote a buggy program: > def f(a): > x = a * 4 > y = a - 4 > return x / y > > def main(): > for i in xrange(100): > f(i) > > main() and then ran it in IPython with verbose tracebacks and got the following output: > ZeroDivisionError Traceback (most recent call last) > > /home/mike/foo.py in <module>() > 8 f(i) > 9 > ---> 10 main() > global main = <function main at 0x10bd7d0> > 11 > 12 > > /home/mike/foo.py in main() > 6 def main(): > 7 for i in xrange(100): > ----> 8 f(i) > global f = <function f at 0x10bd758> > i = 4 > 9 > 10 main() > > /home/mike/foo.py in f(a=4) > 2 x = a * 4 > 3 y = a - 4 > ----> 4 return x / y > x = 16 > y = 0 > 5 > 6 def main(): > > ZeroDivisionError: integer division or modulo by zero This is very handy! The reprs of all locals are input so I can see what the values of a, x, and y were when I had my error and there are a few lines of code on either side of the line that matters to help me get oriented. The former feature is the more powerful one, although enabling this by default is a bad idea; (first and foremost, this can be a security hazard). I can't count how many trips into pdb this would have saved me. I think having this feature be part of Python itself would be very helpful to new learners and to those helping them. I constantly deal with learners seeking help who are unable to clearly provide the actual values and types of the objects in the code they're having trouble with; it would be nice simply to say, "Show me a verbose traceback" and might even help them to debug their code without assistance. Mike

7 11

Add a "hasmethod()" builtin?
by Guido van Rossum 31 Aug '12

31 Aug '12

There's a concept that's sometimes useful when explaining behavior of certain Python operations in terms of simpler ones, and it is "does the class of x define a method m?". This currently cannot expressed using hasattr(): hasattr(x, 'm') might find an instance variable named m, but that is not a method (and there are contexts where they are not interchangeable); hasattr(type(x), 'm') might find a *metaclass* method. Example of the former (assume Python 3): class C: def __add__(self, other): return 42 c = C() c.__add__ = lambda *args: 0 c + 1 # prints 42, not 0 Example of the latter: class C: pass c = C() hasattr(C, 'mro') # prints True, since mro() is a method of the standard metaclass ('type'). c.mro() # raises AttributeError The use case I am mainly thinking of is the formal explanation of the semantics of binary (and other) operators, e.g. def __add__(a, b): r = NotImplemented if hasmethod(a, '__add__'): r = a.__add__(b) if r is NotImplemented and hasmethod(b, '__radd__'): r = b.__radd__(a) if r is NotImplemented: raise TypeError return r (Caveat: it's even more complicated if type(b) is a subclass of type(a).) I'm not sure if it would be better if the first argument of hasmethod() was a type instead of an instance (so the example would use hasattr(type(a), '__add__') etc.). It's also interesting to figure out what should happen for proxy types. (Proxy types in general need a better foundation.) Thoughts? -- --Guido van Rossum (python.org/~guido)

5 4

Unpack of sequences
by Carlo Pires 31 Aug '12

31 Aug '12

Hi, I was just wondering why unpack of sequences did not follow same behavior of functions parameters. I mean: first, *rest = 'a b c'.split() should work in python, why doesn't it? -- Carlo Pires

17 53

hook zipfile.ZipExtFile to check secure hash sums
by Daniel Holth 30 Aug '12

30 Aug '12

I am checking the sha256 sums of all the files in a zip archive as it is being extracted by overriding ZipExtFile._update_crc, but it is inconvenient. It would be nice to have a hook, for example the ZipExtFile constructor could be a property of ZipFile and conveniently replaced with a ZipExtFile subclass.

3 4

inheriting docstrings and mutable docstings for classes
by Mark Adam 24 Aug '12

24 Aug '12

On Thu, Jun 9, 2011 at 8:05 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > On Fri, Jun 10, 2011 at 9:54 AM, Eric Snow <ericsnowcurrently(a)gmail.com> > wrote: > > I'm +1 on having __doc__ be inherited. > > -1. Subclasses are not the same thing as the original class so > docstring inheritance should be requested explicitly. > > Hmm, subclasses are supposed to represent an IS-A relationship in my oldschool OOP books, typically a specialization of a more general (ie. abstract) outer class. The multiple-inheritance case does make things a bit more sloppy, but then this problem has already been resolved by the BDFL via MRO, the same could probably apply with docstrings, with the user updating or using a blank docstring when that general rule doesn't work. In any case, I found myself wanting this auto-inheritance for easier testing with doctest. I don't want my subclasses to mess up invariants in my parent classes, and if the doctests were inherited this would be easy to check. Just my (late) 2 cents worth after examining the current python issues list. mark Sorry for any formatting problems, this is a forward after accidently replying only to ncoghlan.

3 2

Programming recommendations (PEP 8) and boolean values
by Michael Foord 12 Aug '12

12 Aug '12

Hey all, True and False are singletons, so if you want to check precisely for True and False then an identity check seems appropriate. However the "Programming Recommendations" section of PEP 8 has this to say on the topic: Don't compare boolean values to True or False using ==. Yes: if greeting: No: if greeting == True: Worse: if greeting is True: http://www.python.org/dev/peps/pep-0008/#programming-recommendations It seems to me that there is an important distinction between testing that an object is either the boolean True or False and merely checking the "truthiness" of an object. Many a bug has been caused by an empty container object (or some other falsey object) falling into an "if not value" clause that was actually meant to check for the presence of False or None. Why does PEP 8 recommend not testing "boolean values" (which to me implies "values you expect to be a bool") using equality or identity, and more specifically why does it say that using an identity check is worse than an equality check? As this is Python-ideas and not python-list, my specific suggestion is to modify the wording of that section - or just removing it altogether as I don't think it can be adequately clarified without using lots of words. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

24 41

Standard types documentation (was Re: Programming recommendations (PEP 8) and boolean values)
by Nick Coghlan 08 Aug '12

08 Aug '12

On Thu, Aug 9, 2012 at 11:43 AM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > As a result, there is no one place where one can find information > about bool. I wonder if it should go somewhere under section 4.4. > After all, > > >>> isinstance(True, int) > True I'll be working on the builtin types documentation at the PyConAU sprints in a couple of weeks. They haven't aged well :( Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-ideas] Programming recommendations (PEP 8) and boolean values
by Steven D'Aprano 08 Aug '12

08 Aug '12

Taking the liberty to return this to the mailing list. On 09/08/12 08:05, Michael Foord wrote: >> > Why does the PEP say that == True is preferred to is True? >>> >> >> > >> > Because there surely are still libraries out there that return 0 and 1 >> > as true/false values. The bool type was introduced in (by memory) >> > Python 2.2 or 2.3, so very old code may fail, or worse, silently do the >> > wrong thing if you use "is True". >> > >> > > Surely? I haven't seen one in*years*. Nevertheless, "return 1" is still legal Python and was once the idiomatic way of returning a flag. If you don't have a good reason to break such old code, why break it? -- Steven

1 0