Python-ideas October 2016

python-ideas@python.org

109 participants
65 discussions

warn/error when using a method as boolean in ifs/whiles

by Sven R. Kunze

Hey python-ideas, on django-developers, an intriguing idea appeared: https://groups.google.com/d/msg/django-developers/4bntzg1HwwY/HHHjbDnLBQAJ """ It seems to me that the default `method.__bool__` is undesirable in Jinja2 templates. I do not know Jinja2 well enough, but maybe they could benefit from a patch where `if`-statements give a warning/error when the expression is a callable (with the default `FunctionType.__bool__`? This would solve the issue not just for the methods you mention, but more in general. [Or maybe Python itself should have that warning/error?] """ Background: Django implemented form.is_valid as a function. During development, people fall into the trap of believing it's a property or boolean attribute. That's usually not big deal but can take substantial amount of time when writing non trivial code among which reside following innocuous-looking lines: if obj.has_special_property: # will always # be executed What do you think about that Python emitting an warning/error as described above? Cheers, Sven

4 years, 4 months

Adding full() to collections.deque

by Tarek Ziadé

Hey, When creating deque instances using a value for maxlen, it would be nice to have a .full() method like what Queue provides, so one may do: my_deque = deque(maxlen=300) if my_deque.full(): do_something() instead of doing: if len(my_deque) == my_deque.maxlen: do_something() If people think it's a good idea, I can add a ticket in the tracker and try to provide a patch for the collections module maintainer. If this was already talked about, or is a bad idea, sorry! :) Cheers Tarek -- Tarek Ziadé | coding: https://ziade.org | running: https://foule.es | twitter: @tarek_ziade

4 years, 4 months

Re: [Python-ideas] [Python-Dev] Optimizing list.sort() by checking type in advance

by Guido van Rossum

On Mon, Oct 10, 2016 at 7:56 PM, Elliot Gorokhovsky <elliot.gorokhovsky(a)gmail.com> wrote: > So here's a simple attempt at taking lots of measurements just using > time.time() with lists of ints. The results are great, if they are valid > (which I leave to you to judge); even for lists with just one element, it's > 16% faster! But that's suspicious in itself -- since no comparisons are needed to sort a 1-element list, if it's still faster, there must be something else you're doing (or not doing) that's affecting the time measured. I wonder if it's the method lookup that's is slower than the entire call duration? That explains why s[:1] == 'x' is faster than s.startswith('x'), for example. A simple nit on your test code: calling time() twice per iteration could also affect things. I would just call time() once before and once after the innermost for-loops. (IIRC timeit tries to compensate for the cost of the loop itself by measuring an empty loop, but that's got its own set of problems.) Anyway, you should ignore me and listen to Tim, so I'll shut up now. -- --Guido van Rossum (python.org/~guido)

4 years, 4 months

suppressing exception context when it is not relevant

by Václav Dvořák

I'm aware of "raise ... from None" (from PEP 415). However, how can I achieve that same effect (of suppressing the "During handling of the above exception, another exception occurred" message) without having control over the code that is executed from the except clause? I thought that sys.exc_clear() could be used for this, but that function doesn't exist in Python 3 anymore. Why would I want this? I have some simple caching code that looks like (simplified): try: value = cache_dict[key] except KeyError: value = some_api.get_the_value_via_web_service_call(key) cache_dict[key] = value When there's an exception in the API call, the output will be something like this: Traceback (most recent call last): File ..., line ..., in ... KeyError: '...' During handling of the above exception, another exception occurred: Traceback (most recent call last): File ..., line ..., in ... some_api.TheInterestingException: ... But I find this misleading, as the original KeyError is not really an error at all. I could of course avoid the situation by changing the try/except (EAFP) into a test for the key's presence (LBYL) but that's not very Pythonic and less thread-friendly (not that the above is thread-safe as is, but that's beside the point). Also, yes, I could instead subclass dict and implement __missing__, but that's only a solution for this particular case. The problem (if you agree it's a problem) occurs any time an exception is not actually an error, but rather a condition that just happens to be indicated by an exception. It's unreasonable to expect all code in some_api to change their raise X to raise X from None (and it wouldn't even make sense in all cases). Is there a clean solution to avoid the unwanted exception chain in the error message? If not, would it make sense to re-introduce sys.exc_clear() for this purpose? (I originally asked about this here: http://stackoverflow. com/questions/30235516/how-to-suppress-displaying-the- parent-exception-the-cause-for-subsequent-excep but find the answer unappealing.) Vashek

4 years, 4 months

Flagging blocking functions not to be used with asyncio

by Martin Teichmann

Hi list, I am currently developing a Python library based on asyncio. Unfortunately, not all users of my library have much experience with asynchronous programming, so they often try to use blocking functions. I thought it would be a good idea if we could somehow flag blocking functions in the standard library, such that they issue a warning (or even raise an exception) if they are used in an asyncio context. For functions implemented in Python, a simple decorator should do the job. For functions implemented in C, things get a bit more complex. Thinking about it, I realized that currently the best indicator for a C function to block is that it releases the GIL. There are some false positives, like a read with O_NONBLOCK set, in which case we need a way to opt out, but in general it could be a good idea that releasing the GIL triggers a warning in an asyncio environment. Greetings Martin

4 years, 4 months

pip enhancements: check for dependent packages before uninstalling and store installation date to allow listing by it

by João Matos

Hello, I believe it would be helpful if pip checked if there are any dependent packages before uninstalling a package. If there were, it should: 1. Warn the user by listing the dependent packages; 2. Require a specific option, eg. --alldeps to uninstall all dependent packages before uninstalling the specified package; 3. Require a specific option, eg. --force to continue with the uninstall w/o uninstalling the dependent packages (which could be dangerous, but it's the current behaviour and may be useful in specific situations). This is similar to what happens with package managers in Linux. This should also work on venvs. By storing the installation date of all packages, it should allow the list command to be ordered by it. Best regards, JM

4 years, 4 months

Add "equal" builtin function

by Filipp Bakanov

For now there are many usefull builtin functions like "any", "all", etc. I'd like to propose a new builtin function "equal". It should accept iterable, and return True if all items in iterable are the same or iterable is emty. That's quite popular problem, there is a discussion of how to perform it on stackoverflow ( http://stackoverflow.com/questions/3844801/check-if-all-elements-in-a-list-…) - all suggestions are either slow or not very elegant. What do you think about it?

4 years, 4 months

if-statement in for-loop

by Dominik Gresch

Hi, I've recently found myself writing code similar to this: for i in range(10): if i == 5: continue "body" which I find a bit ugly. Obviously the same could be written as for i in range(10): if i != 5: "body" but here you would have to look at the end of the body to see if something happens when i==5. So I asked myself if a syntax as follows would be possible: for i in range(10) if i != 5: body Personally, I find this extremely intuitive since this kind of if-statement is already present in list comprehensions. What is your opinion on this? Sorry if this has been discussed before -- I didn't find anything in the archives. Best regards, Dominik Gresch

4 years, 4 months

Re: [Python-ideas] Improve error message when missing 'self' in method definition

by Sylvain Desodt

Hi all, A bit of shameless self-promotion but in case anyone interested, a while ago, I had started to work on a project to improve error message. In case anyone's interested, you can found everything at: https://github.com/SylvainDe/DidYouMean-Python . It can be invoked in different ways, one of them being a hook. For instance, you'd get something like: >>> import didyoumean_api >>> didyoumean_api.didyoumean_enablehook() >>> math.pi Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'math' is not defined*. Did you mean to import math first?* There is still a lot to be done (and the main thing would be to make it pip installable) but it may be useful if the improved error messages do not make it to the CPython interpreter. Regards Sylvain

4 years, 4 months

Suggestion: Clear screen command for the REPL

by João Matos

Hello, I would like to suggest adding a clear command (not function) to Python. It's simple purpose would be to clear the REPL screen, leaving the >>> prompt at the top left of the screen. This is something very basic but also very useful for newbies learning Python from the REPL. After some trial and errors it is best to start with a clean screen. Clearing the screen helps clear your mind. Historically it is a common command in interpreted languages. Best regards, JM

4 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas October 2016