Re: [Python-ideas] Adding new lines to "Zen of Python"

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

Re: [Python-ideas] Adding new lines to "Zen of Python"

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

[Python-ideas] factory for efficient creation of many dicts with the same keys

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: #

[Python-ideas] Adding new lines to "Zen of Python"

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

Re: [Python-ideas] Adding new lines to "Zen of Python"

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

Re: [Python-ideas] Hexadecimal floating literals

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

[Python-ideas] Add a more disciplined ways of registering ABCs

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

Re: [Python-ideas] lazy import via __future__ or compiler analysis

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

Re: [Python-ideas] lazy import via __future__ or compiler analysis

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

Re: [Python-ideas] factory for efficient creation of many dicts with the same keys

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

Re: [Python-ideas] lazy import via __future__ or compiler analysis

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

Re: [Python-ideas] factory for efficient creation of many dicts with the same keys

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?

Re: [Python-ideas] Hexadecimal floating literals

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

Re: [Python-ideas] Hexadecimal floating literals

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

Re: [Python-ideas] Adding new lines to "Zen of Python"

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,

Re: [Python-ideas] Adding new lines to "Zen of Python"

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

[Python-ideas] Hexadecimal floating literals

The support of hexadecimal floating literals (like 0xC.68p+2) is included in just released C++17 standard. Seems this becomes a mainstream. In Python float.hex() returns hexadecimal string representation. Is it a time to add more support of hexadecimal floating literals? Accept them in float

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 8:11 PM, Eric Snow wrote: > First of all, thanks for the feedback and encouragement! Responses > in-line below. I hope it's helpful! More responses in-line as well. > On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith wrote: >>