2018-04-26 15:26 GMT+02:00 Nick Coghlan :
> On 26 April 2018 at 19:37, Jacco van Dorp wrote:
>> I'm kind of curious why everyone here seems to want to use IntFlags
>> and other mixins. The docs themselves say that their use should be
>> minimized, and tbh
On 26 April 2018 at 19:37, Jacco van Dorp wrote:
> I'm kind of curious why everyone here seems to want to use IntFlags
> and other mixins. The docs themselves say that their use should be
> minimized, and tbh I agree with them. Backwards compatiblity can be
> maintained by
I'm kind of curious why everyone here seems to want to use IntFlags
and other mixins. The docs themselves say that their use should be
minimized, and tbh I agree with them. Backwards compatiblity can be
maintained by allowing the old value and internally converting it to
the enum. Combinability is
>> It could be great. But I afraid this may add too much complexity in C
code. Maybe try to implement a simple and fast Enum for using it in the
stdlib and extend it with a richer interface in the enum module?
> I think we can do something similar to ABCMeta, i.e. the metaclass itself
will stay
On Thu, 26 Apr 2018 08:38:43 +0100
Ivan Levkivskyi
wrote:
> On 25 April 2018 at 12:01, Serhiy Storchaka
> wrote:
>
> > 25.04.18 13:15, Ivan Levkivskyi пише:
> >
> >> Hm, this is what I wanted to know. I think by
On 25 April 2018 at 12:01, Serhiy Storchaka wrote:
> 25.04.18 13:15, Ivan Levkivskyi пише:
>
>> Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we
>> can reduce the creation time of an Enum class
>> (almost) down to the creation time of a normal class,
Even if not just for the autocompletion, it would be more explicit
that it's not just a random string like you'd pass to print(), but it
has a specific meaning. Something in PEP 20 about explicit and
implicit ?
Autocompletion might be a good advantage, but 1) the IDE would need to
know what to
On 2018-04-25 12:05 PM, Guido van Rossum wrote:
On Wed, Apr 25, 2018, 02:13 Jacco van Dorp > wrote:
... Which is where the auto-completion comes in. ...
Designing the language with auto-complete in mind feels wrong to me.
It assumes a
On Wed, 25 Apr 2018 14:01:43 +0300
Serhiy Storchaka
wrote:
> 25.04.18 13:15, Ivan Levkivskyi пише:
> > Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we
> > can reduce the creation time of an Enum class
> > (almost) down to the creation time of a
On 04/25/2018 03:15 AM, Ivan Levkivskyi wrote:
On 25 April 2018 at 11:03, Serhiy Storchaka wrote:
Creating a new function is very cheap -- just around 50 ns on my computer.
Creating a new class is over two orders costly -- around 7 us for an empty
class on my computer.
Creating a new Enum
On Wed, Apr 25, 2018, 02:13 Jacco van Dorp wrote:
> ... Which is where the auto-completion comes in. ...
>
Designing the language with auto-complete in mind feels wrong to me. It
assumes a very sophisticated IDE and may lead to lazy design compromises.
--Guido
>
On Wed, Apr 25, 2018, 01:03 Jeroen Demeyer wrote:
> On 2018-04-25 09:57, Ivan Levkivskyi wrote:
> > In the latter case rewriting EnumMeta in C
>
> ... or Cython. It's a great language and I'm sure that the Python
> standard library could benefit a lot from it.
>
No, the
25.04.18 13:15, Ivan Levkivskyi пише:
Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we
can reduce the creation time of an Enum class
(almost) down to the creation time of a normal class, which may be a
4-5x speed-up. What do you think?
It could be great. But I afraid
On Wed, Apr 25, 2018 at 10:06:56AM +0200, Jacco van Dorp wrote:
> Perhaps the string encode/decode would be a better case, tho. Is it
> latin 1 or latin-1 ? utf-8 or UTF-8 ?
py> 'abc'.encode('latin 1') == 'abc'.encode('LATIN-1')
True
py> 'abc'.encode('utf8') == 'abc'.encode('UTF 8') ==
On 25 April 2018 at 11:03, Serhiy Storchaka wrote:
> 25.04.18 10:57, Ivan Levkivskyi пише:
>
>> On 25 April 2018 at 06:03, INADA Naoki songofaca...@gmail.com>> wrote:
>> enum class creation cost is much heavier than "import enum"
>> cost.
>>
25.04.18 10:57, Ivan Levkivskyi пише:
On 25 April 2018 at 06:03, INADA Naoki
> wrote:
enum class creation cost is much heavier than "import enum" cost.
Especially, "import socket, ssl" is much slower than before...
Is it slow
On Wed, Apr 25, 2018 at 7:12 PM, Jacco van Dorp wrote:
> Pycharm doesn't execute your code - it scans it. It wont know what you
> store on a function object.
How does it currently know what type something is? If you define
something using an enum, how is PyCharm going to
2018-04-25 10:30 GMT+02:00 Chris Angelico :
> On Wed, Apr 25, 2018 at 6:06 PM, Jacco van Dorp wrote:
>>> First, though, can you enumerate (pun intended) the problems with
>>> magic strings? You list "no magic strings" as a benefit, as if it's
>>>
On Wed, Apr 25, 2018 at 6:06 PM, Jacco van Dorp wrote:
>> First, though, can you enumerate (pun intended) the problems with
>> magic strings? You list "no magic strings" as a benefit, as if it's
>> self-evident; I'm not sure that it is.
>>
>> ChrisA
>
> One of my main
> First, though, can you enumerate (pun intended) the problems with
> magic strings? You list "no magic strings" as a benefit, as if it's
> self-evident; I'm not sure that it is.
>
> ChrisA
One of my main reasons would be the type-checking from tools like
Pycharm, which is the one I use. If I
On 2018-04-25 09:57, Ivan Levkivskyi wrote:
In the latter case rewriting EnumMeta in C
... or Cython. It's a great language and I'm sure that the Python
standard library could benefit a lot from it.
___
Python-ideas mailing list
On 25 April 2018 at 06:03, INADA Naoki wrote:
> On Wed, Apr 25, 2018 at 12:04 PM, Nick Coghlan wrote:
> > On 25 April 2018 at 04:56, Ethan Furman wrote:
> >> On 04/24/2018 10:32 AM, Antoine Pitrou wrote:
> >>
> >>> Also beware the
On Wed, Apr 25, 2018 at 12:04 PM, Nick Coghlan wrote:
> On 25 April 2018 at 04:56, Ethan Furman wrote:
>> On 04/24/2018 10:32 AM, Antoine Pitrou wrote:
>>
>>> Also beware the import time cost of having a widely-used module like
>>> "warnings" depend on the
On 25 April 2018 at 04:56, Ethan Furman wrote:
> On 04/24/2018 10:32 AM, Antoine Pitrou wrote:
>
>> Also beware the import time cost of having a widely-used module like
>> "warnings" depend on the "enum" module and its own dependencies.
>
>
> With all the recent changes to
On 04/24/2018 10:32 AM, Antoine Pitrou wrote:
Also beware the import time cost of having a widely-used module like
"warnings" depend on the "enum" module and its own dependencies.
With all the recent changes to Python, I should go through and see which
dependencies are no longer needed.
--
On Wed, Apr 25, 2018 at 3:19 AM, Steven D'Aprano wrote:
> On Wed, Apr 25, 2018 at 01:18:10AM +1000, Chris Angelico wrote:
>
>> First, though, can you enumerate (pun intended) the problems with
>> magic strings? You list "no magic strings" as a benefit, as if it's
>>
On Tue, 24 Apr 2018 23:58:19 +1000
Nick Coghlan wrote:
> On 24 April 2018 at 22:52, Jacco van Dorp wrote:
> > A bit ago I was reading some of the python docs (
> > https://docs.python.org/3.6/library/warnings.html ), the warning
> > module, and I
On Wed, Apr 25, 2018 at 01:18:10AM +1000, Chris Angelico wrote:
> First, though, can you enumerate (pun intended) the problems with
> magic strings? You list "no magic strings" as a benefit, as if it's
> self-evident; I'm not sure that it is.
It shouldn't be self-evident, because the use of
On 25 April 2018 at 01:06, Jacco van Dorp wrote:
> I guess we could add inconsistency as a con, then, since if the import
> system isn't working at places where you'd like to use the Enums (or
> even executing python code ?). This would mean that to the casual
> observer,
On Wed, Apr 25, 2018 at 1:06 AM, Jacco van Dorp wrote:
> I
>
> 2018-04-24 15:58 GMT+02:00 Nick Coghlan :
>> On 24 April 2018 at 22:52, Jacco van Dorp wrote:
>>> Wouldn't it be cleaner to use enums by default instead of those magic
I
2018-04-24 15:58 GMT+02:00 Nick Coghlan :
> On 24 April 2018 at 22:52, Jacco van Dorp wrote:
>> Wouldn't it be cleaner to use enums by default instead of those magic
>> strings ? for example, for warnings filter actions, (section 29.5.2),
>> quite near
On 24 April 2018 at 22:52, Jacco van Dorp wrote:
> A bit ago I was reading some of the python docs (
> https://docs.python.org/3.6/library/warnings.html ), the warning
> module, and I noticed a table of magic strings.
>
> I can think of a few other places where magic strings
A bit ago I was reading some of the python docs (
https://docs.python.org/3.6/library/warnings.html ), the warning
module, and I noticed a table of magic strings.
I can think of a few other places where magic strings are used - for
example, string encoding/decoding locales and strictness, and
33 matches
Mail list logo