On 11.10.2016 05:02, Tim Peters wrote:
Let's not get hung up on meta-discussion here - I always thought
"massive clusterf**k" was a precise technical term anyway ;-)
I thought so as well. ;)
http://www.urbandictionary.com/define.php?term=clusterfuck
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 peopl
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
ben
On 11 October 2016 at 13:41, Sven R. Kunze wrote:
> 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__`?
[...]
> What do you think about that Python emitting an warning/error as described
>
Hello list
I love the "new" unpacking generalisations as of pep448. And I found
myself using them rather regularly, both with lists and dict.
Today I somehow expected that [*foo for foo in bar] was equivalent to
itertools.chain(*[foo for foo in bar]), which it turned out to be a
SyntaxError.
The d
On Tue, Oct 11, 2016 at 7:02 AM, Paul Moore wrote:
> Interesting idea. There may be some issues - consider an object that
> may optionally have a handler method handle_event, and you want to
> call that method if it exists:
>
> handler = getattr(obj, 'handle_event', None)
> if handler:
>
I thought about it a lot recently. Specifically on your proposal, and in
general. Unpacking expression can have a much more uniform treatment in the
language, as an expression with special "bare tuple" type - like tuple, but
"without the braces".
It also gives mental explanation for the conditiona
On 11 October 2016 at 14:38, Eric Snow wrote:
> On Tue, Oct 11, 2016 at 7:02 AM, Paul Moore wrote:
>> Interesting idea. There may be some issues - consider an object that
>> may optionally have a handler method handle_event, and you want to
>> call that method if it exists:
>>
>> handler = ge
On Tue, Oct 11, 2016 at 02:41:34PM +0200, Sven R. Kunze wrote:
> 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
>
On 10/11/2016 07:00 AM, Steven D'Aprano wrote:
On Tue, Oct 11, 2016 at 02:41:34PM +0200, Sven R. Kunze wrote:
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
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano wrote:
> On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
>> I have an idea to improve indenting guidelines for dictionaries for better
>> readability: If a value in a dictionary literal is placed on a new line, it
>> should have (or at
Isn't the problem that you don't know if it's still full on the next
line? After all you supposedly have a multi-threaded app here,
otherwise why bother with any of that? Or maybe you can describe the
real-world use case where you wanted this in more detail? Without much
more evidence I can't suppo
On 11 October 2016 at 23:50, אלעזר wrote:
> I thought about it a lot recently. Specifically on your proposal, and in
> general. Unpacking expression can have a much more uniform treatment in the
> language, as an expression with special "bare tuple" type - like tuple, but
> "without the braces".
On Oct 11, 2016 10:40 AM, "Erik Bray" wrote:
>
> On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano
wrote:
> > On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
> >> I have an idea to improve indenting guidelines for dictionaries for
better
> >> readability: If a value in a dictionary l
Warning: the contents of this message may be dangerous for readers with
heart conditions.
So today I looked at PyFloat_RichCompare. I had been scared initially
because it was so complicated, I was worried I would miss some important
error check or something if I special cased it. So I took the fol
One option would be to decorate those functions and provide an
implementation to __bool__ or __nonzero__ which raises an exception.
Something like this
In [1]: def a(): pass
In [2]: def r(): raise RuntimeError('Do not forget to call this')
In [3]: a.__bool__ = r
In [4]: if a: pass
I don't have a
On 11 October 2016 at 23:59, Paul Moore wrote:
> Certainly. But the whole point of the warning is to catch people who
> do the wrong thing. All I'm saying is that the new warning would cause
> problems for people who omit a (currently unnecessary) "is None" check
> in the process of protecting peo
Ah! I havn't thought about that because in my use case the deque is
append-only so once it's full it discards older elements.
I guess what I really need is a regular FIFO Queue
Thanks for the feedback !
--
Tarek Ziadé | coding: https://ziade.org | running: https://foule.es |
twitter: @tarek_
On 12 October 2016 at 02:16, Elliot Gorokhovsky
wrote:
> So I thought, wow, this will give some nice numbers! But I underestimated
> the power of this optimization. You have no idea. It's crazy.
> This is just insane. This is crazy.
Not to take away from the potential for speed improvements (whic
On 11 October 2016 at 17:21, David Navarro wrote:
> Something like this
>
> In [1]: def a(): pass
> In [2]: def r(): raise RuntimeError('Do not forget to call this')
> In [3]: a.__bool__ = r
> In [4]: if a: pass
>
> I don't have an environment to test if this is possible. This would allow
> markin
On 11 October 2016 at 17:49, Nick Coghlan wrote:
> On 12 October 2016 at 02:16, Elliot Gorokhovsky
> wrote:
>> So I thought, wow, this will give some nice numbers! But I underestimated
>> the power of this optimization. You have no idea. It's crazy.
>> This is just insane. This is crazy.
>
> Not
I honestly appreciate your work on this. However, don't write as if you
were trying to sell something to the people on the mailing list. "INSANE
FLOAT PERFORMANCE!!!" seems the title of a bad YouTube video or
something lower than that, while you are just trying to tell us about
"Relevant perfor
So I got excited here. And the reason why is that I got those numbers *on
Tim's benchmark*. When I got these kinds of numbers on my benchmarks, I
figured there was probably a problem with they way I was timing, and
certainly the gains couldn't be as extreme as they suggested. But this is
on a bench
On Wednesday, October 5, 2016, Yury Selivanov
wrote:
>
>
> On 2016-10-05 2:50 PM, Nathan Goldbaum wrote:
>
>> On Wed, Oct 5, 2016 at 1:27 PM, Michel Desmoulin <
>> desmoulinmic...@gmail.com>
>> wrote:
>>
>> +1. Python does need better error messages. This and the recent new import
>>> exception w
To answer your question: I special-case unicode (strings), ints, and
floats. I am working on special-casing tuples (can even be different types,
just need homogeneity column-wise). The best speedups will be tuples of
floats: it'll bypass three layers of useless checks.
If I run it without special-
On 10/11/2016 12:08 PM, Ryan Gonzalez wrote:
On Oct 11, 2016 10:40 AM, "Erik Bray"
mailto:erik.m.b...@gmail.com>> wrote:
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano
mailto:st...@pearwood.info>> wrote:
> On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
>> I have an idea to im
On 10/11/2016 2:30 PM, Paul Moore wrote:
On 11 October 2016 at 17:49, Nick Coghlan wrote:
On 12 October 2016 at 02:16, Elliot Gorokhovsky
wrote:
So I thought, wow, this will give some nice numbers! But I underestimated
the power of this optimization. You have no idea. It's crazy.
This is just
[Elliot Gorokhovsky]
> Warning: the contents of this message may be dangerous for readers with
> heart conditions.
It appears some people are offended by your exuberance. Ignore them ;-)
> ...
> And it turns out that if you do that, PyFloat_RichCompare becomes ONE LINE
> (after we set op=Py_LT)
On 12 October 2016 at 06:58, Elliot Gorokhovsky
wrote:
> So I got excited here. And the reason why is that I got those numbers *on
> Tim's benchmark*. When I got these kinds of numbers on my benchmarks, I
> figured there was probably a problem with they way I was timing, and
> certainly the gains
29 matches
Mail list logo
