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
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
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)
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
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
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
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?
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
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
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