Dear all
This is my very first email to python-ideas, and I strongly support this idea.
float.hex() does the job for float to hexadecimal conversion, and
float.fromhex() does the opposite. But a full support for hexadecimal
floating-point literals would be great (it bypasses the decimal to
floa
I curious if there are any plans to update the "Zen of Python".
What could be added to the "Zen of Python"?
What do you think?
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Zen would suppose to remove things from it, not add.
Le 08/09/2017 à 14:47, Thomas Güttler a écrit :
> I curious if there are any plans to update the "Zen of Python".
>
> What could be added to the "Zen of Python"?
>
> What do you think?
>
> Regards,
> Thomas Güttler
>
>
>
>
_
On 08.09.2017 14:47, Thomas Güttler wrote:
> I curious if there are any plans to update the "Zen of Python".
>
> What could be added to the "Zen of Python"?
>
> What do you think?
Only the Zen Master can decide on this one and it appears there's
only room for one more aphorism, but I guess that'
Hi all,
Sometimes you may need to create many dicts with the same keys, but different
values. For example, if you want to return data from DB as dicts.
I think that special type could be added to solve this task more effectively.
I created proof of concept for this and here's benchmarks:
# curre
On 08.09.2017 15:20, M.-A. Lemburg wrote:
On 08.09.2017 14:47, Thomas Güttler wrote:
I curious if there are any plans to update the "Zen of Python".
What could be added to the "Zen of Python"?
What do you think?
Only the Zen Master can decide on this one and it appears there's
only room for o
I think you've got it backwards -- if you send the patch the idea *may* be
accepted. You ought to at least show us the docs for your proposed factory,
it's a little murky from your example.
On Fri, Sep 8, 2017 at 6:34 AM, Sergey Fedoseev
wrote:
> Hi all,
>
> Sometimes you may need to create many
Hi all,
tl;dr: I propose adding a `register()` decorator, to be used like this:
@abc.register(Abc1, Abc2)
class D:
...
For preexisting classes I propose adding a magic static variable
`__registered__`, to be handled by ABCMeta:
class Abc1(metaclass=ABCMeta):
__regist
Replying here, although this was written in response to the other thread:
Hey Neil,
In general this won't work. It's not generally possible to know if a given
statement has side effects or not. As an example, one normally wouldn't
expect function or class definition to have side effects, but if a
On Sat, Sep 9, 2017 at 1:27 AM, Joshua Morton wrote:
> As a result of this, you can't even know if an import is safe, because that
> module may have side effects. That is, the module foo.py:
>
> import bar
>
> isn't known to be lazy, because bar may import and start the logging module,
> as an
On 2017-09-08, Joshua Morton wrote:
> In general this won't work. It's not generally possible to know if a given
> statement has side effects or not.
That's true but with the AST static analysis, we find anything that
has potential side effects. The question if any useful subset of
real modules p
Here's docs:
.. staticmethod:: factory(*keys)
Return a callable object that creates a dictionary from *keys* and its
operands. For example:
* ``dict.factory('1', 2, (3,))({1}, [2], {3: None})`` returns
``{'1': {1}, 2: [2], (3,): {3: None}}``.
* ``dict.factory
On 2017-09-09, Chris Angelico wrote:
> Laziness has to be complete - or, looking the other way, eager
> importing is infectious. For foo to be lazy, bar also has to be lazy;
Not with the approach I'm proposing. bar will be loaded in non-lazy
fashion at the right time, foo can still be lazy.
_
On Sat, Sep 9, 2017 at 2:36 AM, Neil Schemenauer
wrote:
> On 2017-09-09, Chris Angelico wrote:
>> Laziness has to be complete - or, looking the other way, eager
>> importing is infectious. For foo to be lazy, bar also has to be lazy;
>
> Not with the approach I'm proposing. bar will be loaded in
Thanks for your suggestion.
FYI, you can use "key-sharing dict" (PEP 412:
https://www.python.org/dev/peps/pep-0412/)
when all keys are string.
It saves not only creation time, but also memory usage.
I think it's nice for CSV parser and, as you said, DB record.
One question is, how is it useful?
W
2017-09-07 23:57 GMT-07:00 Serhiy Storchaka :
> The support of hexadecimal floating literals (like 0xC.68p+2) is included in
> just released C++17 standard. Seems this becomes a mainstream.
Floating literal using base 2 (or base 2^n, like hexadecimal, 2^4) is
the only way to get exact values in a
On Fri, Sep 8, 2017 at 12:05 PM, Victor Stinner
wrote:
> 2017-09-07 23:57 GMT-07:00 Serhiy Storchaka :
> > The support of hexadecimal floating literals (like 0xC.68p+2) is
> included in
> > just released C++17 standard. Seems this becomes a mainstream.
>
> Floating literal using base 2 (or base 2
Maybe something over-pretentious like:
If it's not automatically tested, it's broken.
Or:
Tests lie; and you need them.
Or:
Achieve reproducibility and eliminate quality variance with tests.
On Friday, September 8, 2017, Sven R. Kunze wrote:
> On 08.09.2017 15:20, M.-A. Lemburg wrote:
On 9/8/2017 8:47 AM, Thomas Güttler wrote:
I curious if there are any plans to update the "Zen of Python".
What could be added to the "Zen of Python"?
What do you think?
"Zen of Python" is a published (in the stdlib), free-verse poem by Tim
Peters. As a unitary work of art, it is not something t
Rather than 'update' the Zen of Python, it seems better to create something
original, maybe derived from the Zen, and see if it becomes popular in its
own right. It'd be fun to see extensions and alternatives, but there's no
reason to change a classic work that helped to define the culture.
Sorry
20 matches
Mail list logo
