I already made a PR that would highlight code in PEPs half-year ago, but it
was rejected with the reason that they will be moved to RtD soon.
--
Ivan
8 Вер 2017 16:56 "Antoine Pitrou" пише:
>
> Hi,
>
> Is it possible to install pygments on the machine which builds and
> renders PEPs? It would
On 9 September 2017 at 00:14, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 16:59:57 +0200
> Ivan Levkivskyi wrote:
>
> > I already made a PR that would highlight code in PEPs half-year ago, but
> it
> > was rejected with the reason that they will be moved to RtD soon.
&
On 9 September 2017 at 01:00, Guido van Rossum wrote:
> I think it would be useful to write 1-2 sentences about the problem with
> inheritance -- in that case you pretty much have to use a metaclass,
>
>
It is not the case now. I think __init_subclass__ has almost the same
possibilities as a deco
On 10 September 2017 at 23:05, Mike Miller
wrote:
> [...]
> As the problem this PEP is solving is orthogonal to typing improvements
>
This is not the case, static support for dataclasses is an import point of
motivation.
It is hard to support static typing for many third party packages like
attr
@Larry
> "@property" 375 hits
> "def __getattr__" 28 hits
I don't think it is fair to compare occurrences of __getattr__ vs
occurrences of @property,
since in the first case one would use a single __getattr__ per class, while
in the second case
@property is required for every attribute.
@G
@Guido
> One would have to introduce some kind of convention
> where you can write properties with a leading _
One doesn't even need the @property decorator in this case.
For example:
def __getattr__(name):
g = globals()
name = '_' + name
if name in g:
return g[name]()
rai
On 14 September 2017 at 01:13, Guido van Rossum wrote:
>
> That last sentence is a key observation. Do we even know whether there are
> (non-toy) things that you can do *in principle* with __class__ assignment
> but which are too slow *in practice* to bother? And if yes, is __getattr__
> fast eno
(sorry for obvious mistakes in the example in previous e-mail)
On 14 September 2017 at 21:08, Ivan Levkivskyi wrote:
> On 14 September 2017 at 01:13, Guido van Rossum wrote:
>
>>
>> That last sentence is a key observation. Do we even know whether there
>> are (non-toy
On 14 September 2017 at 22:07, Ethan Furman wrote:
>
> For comparison's sake, what would the above look like using __class__
> assignment? And what is the performance difference?
>
>
Actually I tried but I can't implement this without module __getattr__
so that one can just write:
from typing_e
On 14 September 2017 at 22:21, Ivan Levkivskyi wrote:
> On 14 September 2017 at 22:07, Ethan Furman wrote:
>
>>
>> For comparison's sake, what would the above look like using __class__
>> assignment? And what is the performance difference?
>>
>>
>
On 14 September 2017 at 22:07, Ethan Furman wrote:
> For comparison's sake, what would the above look like using __class__
> assignment? And what is the performance difference?
>
>
FWIW I found a different solution:
# file mod.py
from typing_extensions import allow_forward_references
allow_for
On 14 September 2017 at 23:02, Ivan Levkivskyi wrote:
> On 14 September 2017 at 22:07, Ethan Furman wrote:
>
>> For comparison's sake, what would the above look like using __class__
>> assignment? And what is the performance difference?
>>
>>
> FWIW I
On 14 October 2017 at 17:49, Ethan Furman wrote:
> The problem with PEP 560 is that it doesn't allow the class definition
> protections that a metaclass does.
>
Since the discussion turned to PEP 560, I can say that I don't want this to
be a general mechanism, the PEP rationale section gives
sev
On 14 October 2017 at 18:14, Ethan Furman wrote:
> On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:
>
>>
>> Could you please elaborate more what is wrong with PEP 560 and what do
>> you mean by "class definition protections"
>>
>
> Nothing is wrong wit
On 2 November 2017 at 18:00, Brett Cannon wrote:
>
>
> On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote:
>
>> On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote:
>> [...snip...]
>
> I think the performance bit is really the big deal here.
>
>
I don't think so. Although subscripting ge
On 1 November 2017 at 23:48, Lukasz Langa wrote:
> Runtime annotation resolution and class decorators
> --
>
> Metaclasses and class decorators that need to resolve annotations for
> the current class will fail for annotations that use the name of t
I will be happy to see PEP 544 and PEP 560 in Python 3.7, and maybe also
PEP 562 (if we decide on it and I will have time).
--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
FWIW, it is common to have syntax checks in ast.c.
Especially situations like class ``C(x for x in [1]): ...`` I think would
be hard to prohibit in Grammar.
Since anyway we have many checks in ast.c already, I wouldn't care much
about implementing these corner cases in Grammar.
--
Ivan
___
Thanks Ethan for all the work!
I will be glad to see this accepted and implemented in mypy.
--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
/pep-0560/
Here I post the full text for convenience:
++
PEP: 560
Title: Core support for typing module and generic types
Author: Ivan Levkivskyi
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 03-Sep-2017
Python-Version: 3.7
Post-History: 09-Sep
addition of __dir__, as proposed by
Guido.
Here is the full text:
+
PEP: 562
Title: Module __getattr__ and __dir__
Author: Ivan Levkivskyi
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Sep-2017
Python-Version: 3.7
Post-History: 09-Sep-2017
Abstract
On 15 November 2017 at 08:43, Serhiy Storchaka wrote:
> 14.11.17 22:34, Ivan Levkivskyi пише:
>
>> This function will be called only if ``name`` is not found in the module
>> through the normal attribute lookup.
>>
>
> It is worth to mention that using name
Nick is exactly right here. Jim, if you want to propose alternative
wording, then we could consider it.
--
Ivan
On 15 November 2017 at 16:37, Nick Coghlan wrote:
> On 16 November 2017 at 00:20, Jim J. Jewett wrote:
>
>> I *think* the following will happen:
>>
>> "NewList[int]" will be eva
On 16 November 2017 at 07:56, Nick Coghlan wrote:
> On 16 November 2017 at 04:39, Ivan Levkivskyi
> wrote:
>
>> Nick is exactly right here. Jim, if you want to propose alternative
>> wording, then we could consider it.
>>
>
> Jim also raised an important poin
On 16 November 2017 at 18:58, Ethan Furman wrote:
> On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote:
>
>> On 16 November 2017 at 07:56, Nick Coghlan wrote:
>>
>
> Jim also raised an important point that needs clarification at the spec
>>>
>> >> level
On 19 November 2017 at 21:06, Mark Shannon wrote:
> By far and away the largest change in PEP 560 is the change to the
> behaviour of object.__getitem__. This is not mentioned in the PEP at all,
> but is explicit in the draft implementation.
> The implementation could implement `type.__getitem__`
On 20 November 2017 at 20:51, Guido van Rossum wrote:
> Yeah, I don't think there's an action item here except *maybe* changes to
> the wording of the PEP. Ivan?
>
Yes, I will make a small PR with a more detailed description of how
__getattr__ works.
--
Ivan
On 20 November 2017 at 10:22, Mark Shannon wrote:
> On 19/11/17 22:36, Ivan Levkivskyi wrote:
>
>> Except that there is no such thing as object._getitem__. Probably you
>> mean PyObject_GetItem (which is just what is done by BINARY_SUBSCR opcode).
>>
> In fact, I
Serhiy,
I think this is indeed a problem. For me the biggest surprise was that
`yield` inside a comprehension does not turn a surrounding function into
comprehension, see also
https://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-using-a-list-comprehension-with-corou
On 22 November 2017 at 14:38, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 15:03:09 +0200
> Serhiy Storchaka wrote:
> > From
> > https://stackoverflow.com/questions/45190729/
> differences-between-generator-comprehension-expressions.
> >
> > g = [(yield i) for i in range(3)]
> >
> > Syntact
On 22 November 2017 at 14:53, Serhiy Storchaka wrote:
> 22.11.17 15:25, Ivan Levkivskyi пише:
>
>> I think this is indeed a problem.. For me the biggest surprise was that
>> `yield` inside a comprehension does not turn a surrounding function into
>> comprehe
On 22 November 2017 at 15:09, Paul Moore wrote:
> On 22 November 2017 at 13:53, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 14:38, Antoine Pitrou
> wrote:
> >>
> >> On Wed, 22 Nov 2017 15:03:09 +0200
> >> Serhiy Storchaka wrote:
> >&
On 22 November 2017 at 15:46, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 15:15:49 +0100
> Ivan Levkivskyi wrote:
> > There are many things that I would reject in code review, but they are
> > still allowed in Python,
> > this is one of the reasons why code reviews exist
On 22 November 2017 at 15:47, Paul Moore wrote:
> I generally don't understand "await" in any context, so I deferred
> judgement on that :-) Based on your comment that they are equally
> tricky, I'd suggest we prohibit them both ;-)
>
> Less facetiously, comprehensions are defined in the language
On 22 November 2017 at 16:53, Paul Moore wrote:
> On 22 November 2017 at 15:10, Ivan Levkivskyi
> wrote:
> > I think there may be a small misunderstanding here. The situation is
> > different for comprehensions and generator expressions,
> > let me summarize the current
On 22 November 2017 at 16:56, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 15:47, Paul Moore wrote:
> [...]
> I'm all for prohibiting using 'yield' expression in generator
> expressions or comp
On 22 November 2017 at 17:24, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 17:08:14 +0100
> Ivan Levkivskyi wrote:
> > On 22 November 2017 at 16:56, Yury Selivanov
> > wrote:
> >
> > > On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi <
> levkivs..
On 22 November 2017 at 17:16, Paul Moore wrote:
> On 22 November 2017 at 16:08, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 16:56, Yury Selivanov
> > wrote:
> >>
> >> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi >
> >> wrote:
> &
Sorry, forgot some details in the second "definition":
try:
def __gen():
for i in range(3):
yield (yield i)
g = list(__gen())
finally:
del __gen
--
Ivan
___
Python-Dev mailing list
Pytho
On 22 November 2017 at 17:43, Paul Moore wrote:
> On 22 November 2017 at 16:30, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:24, Antoine Pitrou
> wrote:
> >> Given a comprehension (e.g. list comprehension) is expected to work
> >> nominally as
On 22 November 2017 at 17:50, Paul Moore wrote:
> On 22 November 2017 at 16:38, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:16, Paul Moore wrote:
> >>
> >> Docs more importantly than PEP IMO. And are you implying that there's
> >> a
On 22 November 2017 at 18:15, Paul Moore wrote:
> On 22 November 2017 at 16:47, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:43, Paul Moore wrote:
> >>
> >> On 22 November 2017 at 16:30, Ivan Levkivskyi
> >> wrote:
> >> > On 22 N
On 22 November 2017 at 18:15, Paul Moore wrote:
> On 22 November 2017 at 16:47, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:43, Paul Moore wrote:
> >>
> >> On 22 November 2017 at 16:30, Ivan Levkivskyi
> >> wrote:
> >> > On 22 N
On 22 November 2017 at 19:54, Jelle Zijlstra
wrote:
>
> One proposal is to make it so `g` gets assigned a list, and the `yield`
> happens in the enclosing scope (so the enclosing function would have to be
> a generator). This was the way things worked in Python 2, I believe.
>
> Another proposal
On 22 November 2017 at 20:15, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 11:08 AM, Ivan Levkivskyi
> wrote:
>
>> On 22 November 2017 at 19:54, Jelle Zijlstra
>> wrote:
>>
>>>
>>> One proposal is to make it so `g` gets assigned a list, and t
On 22 November 2017 at 20:05, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra > wrote
>
>> 2017-11-22 9:58 GMT-08:00 Guido van Rossum :
>>
> (OTOH, await in the same position must keep working since it's not broken
>> and not unintuitive either.)
>>
>
>
This is very q
On 22 November 2017 at 20:33, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
> wrote:
>
>> On 22 November 2017 at 20:05, Guido van Rossum wrote:
>>
>>> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra <
>>> jelle.zijls...
22 Лис 2017 22:19 "Ethan Furman" пише:
On 11/22/2017 11:01 AM, Ivan Levkivskyi wrote:
I think how to formulate these rules more "precisely" so that they will be
> all consistent even if there is a
> `yield` inside.
> The key idea is that neither comprehensions nor g
22 Лис 2017 22:33 "Ethan Furman" пише:
On 11/22/2017 01:25 PM, Ivan Levkivskyi wrote:
> 22 Лис 2017 22:19 "Ethan Furman" пише:
>
Whether it's inside or outside a function should be irrelevant -- a
>> comprehension / generator expression should have
>>
On 22 November 2017 at 21:07, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 2:37 PM, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 20:33, Guido van Rossum wrote:
> >>
> >> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi >
> >> wrote:
>
On 23 November 2017 at 01:00, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 6:46 PM, Ivan Levkivskyi
> wrote:
> [..]
> > Just found another example of intuitive behaviour:
> >
> >>>> async def f():
> > ... for i in range(3):
> >
On 23 November 2017 at 05:44, Greg Ewing
wrote:
> Ivan Levkivskyi wrote:
>
>> The key idea is that neither comprehensions nor generator expressions
>> should create a function scope surrounding the `expr`
>>
>
> I don't see how you can avoid an implici
On 23 November 2017 at 09:15, Greg Ewing
wrote:
> Ivan Levkivskyi wrote:
>
>> On 23 November 2017 at 05:44, Greg Ewing > <mailto:greg.ew...@canterbury.ac.nz>> wrote:
>>
>>def g():
>> return ((yield i) for i in range(10))
>>
>
On 23 November 2017 at 09:11, Greg Ewing
wrote:
> Ivan Levkivskyi wrote:
>
>> "People sometimes want to refactor for-loops containing `yield` into a
>> comprehension but that doesn't work (particularly because of the hidden
>> function scope) - lets make it a
On 23 November 2017 at 09:17, Greg Ewing
wrote:
> Ivan Levkivskyi wrote:
>
>> "People sometimes want to refactor for-loops containing `yield` into a
>> comprehension
>>
>
> By the way, do we have any real-life examples of people wanting to
> do this? It m
On 23 November 2017 at 11:55, Nick Coghlan wrote:
> On 23 November 2017 at 18:11, Greg Ewing
> wrote:
>
>> Ivan Levkivskyi wrote:
>>
>>> "People sometimes want to refactor for-loops containing `yield` into a
>>> comprehension but that does
On 23 November 2017 at 12:38, Ivan Levkivskyi wrote:
> On 23 November 2017 at 11:55, Nick Coghlan wrote:
>
>> On 23 November 2017 at 18:11, Greg Ewing
>> wrote:
>>
>>> Ivan Levkivskyi wrote:
>>>
>>>> "People sometimes want to refactor
On 23 November 2017 at 10:50, Paul Moore wrote:
> On 23 November 2017 at 09:14, Steve Holden wrote:
> > I would urge developers, in their improvements to the language to support
> > asynchronous programming, to bear in mind that this is (currently) a
> > minority use case. Why the rush to set co
On 23 November 2017 at 12:49, Antoine Pitrou wrote:
> On Thu, 23 Nov 2017 12:39:46 +0100
> Ivan Levkivskyi wrote:
> >
> > Also I think it makes sense to keep discussion in one place, i.e. either
> > here xor at https://bugs.python.org/issue10544
>
> T
On 23 November 2017 at 13:11, Paul Moore wrote:
> On 23 November 2017 at 12:01, Ivan Levkivskyi
> wrote:
>
> > "I don't use it, therefore it is not needed" is a great argument,
> thanks.
> > Lets just forget about two SO questions and dozens people
On 23 November 2017 at 13:30, Antoine Pitrou wrote:
> On Thu, 23 Nov 2017 14:17:32 +0200
> Serhiy Storchaka wrote:
> >
> > I used the "yield" statement, but I never used the "yield" expressions.
> > And I can't found examples. Could you please present a real-world use
> > case for the "yield" (n
On 23 November 2017 at 13:45, Paul Moore wrote:
> On 23 November 2017 at 12:28, Ivan Levkivskyi
> wrote:
> > On 23 November 2017 at 13:11, Paul Moore wrote:
> >>
> >> On 23 November 2017 at 12:01, Ivan Levkivskyi
> >> wrote:
> >>
> >> &
On 23 November 2017 at 15:21, Paul Moore wrote:
> On 23 November 2017 at 13:04, Ivan Levkivskyi
> wrote:
> > Let us forget for a moment about other problems and focus on this one:
> list
> > comprehension is currently not equivalent to a for-loop.
> > There are two o
On 23 November 2017 at 15:30, Paul Moore wrote:
> On 23 November 2017 at 14:24, Ivan Levkivskyi
> wrote:
> >> My main concern is that comprehension is not equivalent to a for loop
> >> for a specific reason - the scope issue. Has anyone looked back at the
> >>
OK, so my 24 hours are over :-)
On 24 November 2017 at 01:50, Nick Coghlan wrote:
> On 23 November 2017 at 23:04, Ivan Levkivskyi
> wrote:
>
>> I don't see why this particular case qualifies for such a radical measure
>> as an exception to syntactic rules,
>>
On 25 November 2017 at 01:22, Guido van Rossum wrote:
> The more I hear about this topic, the more I think that `await`, `yield`
> and `yield from` should all be banned from occurring in all comprehensions
> and generator expressions. That's not much different from disallowing
> `return` or `brea
On 25 November 2017 at 04:30, Guido van Rossum wrote:
> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
> wrote:
>
>> The more I hear about this topic, the more I think that `await`, `yield`
>> and `yield from` should all be banned from occurring in all comprehensions
>> and generator expressi
On 25 November 2017 at 16:57, Guido van Rossum wrote:
> On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi
> wrote:
>
>> On 25 November 2017 at 04:30, Guido van Rossum wrote:
>>
>>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
>>> wrote:
>>>
Congratulations, Eric! This is a great PEP and I am looking forward to
implement support for it in mypy ;-)
--
Ivan
On 4 December 2017 at 18:17, Guido van Rossum wrote:
> And with this, I'm accepting PEP 557, Data Classes.
>
> Eric, congrats with your efforts in proposing and implementing this
Thank you Guido!
And thanks everyone for help, discussions, and ideas (in particular Larry
who started this discussion).
I will submit a PR with implementation soon.
--
Ivan
On 4 December 2017 at 17:58, Guido van Rossum wrote:
> Ivan,
>
> Congrats on your PEP. I believe the outstanding issues
Thank you! It looks like we have a bunch of accepted PEPs today.
It is great to see all this! Thanks everyone who participated in
discussions here, on python-ideas and
on typing tracker. Special thanks to Mark who started this discussion.
--
Ivan
___
Pyt
Congratulations, Łukasz!
--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 8 December 2017 at 19:28, Raymond Hettinger
wrote:
>
> I'm hoping the typing experts will chime in here. The question is
> straight-forward. Where should we look for the signature and docstring for
> constructing instances? Should they be attached to the class, to
> __init__(), or to __new_
On 10 December 2017 at 22:24, Raymond Hettinger wrote:
> Without typing (only the first currently works):
>
> Point = namedtuple('Point', ['x', 'y', 'z']) # underlying
> store is a tuple
> Point = make_dataclass('Point', ['x', 'y', 'z']) # underlying
> store is an instance d
There is also PEP 544 (Structural subtyping, a.k.a. static duck typing),
but I think we discussed off-list that it is also not time sensitive,
given the (limited) provisional status of typing module.
(Also mypy already supports it, so the question is mainly when this support
is official after poli
On 15 December 2017 at 15:55, Yury Selivanov
wrote:
> > I don't see any problems with implementing this on types defined in C.
> This isn't harder than implementing __sizeof__ or pickling support, and
> NumPy classes already have implemented both. Maybe Yury forgot about
> METH_STATIC and METH_CL
I like this idea. I have few suggestions for the test cases you added, will
add them a bit later in the PR.
--
Ivan
On 15 December 2017 at 16:00, Serhiy Storchaka wrote:
> The class itself always is passed as the first argument to
> __class_getitem__():
>
> cls.__class_getitem__(cls, item)
On 15 December 2017 at 17:47, Yury Selivanov
wrote:
> Shouldn't we optimize the usability for pure-Python first, and then for C
> API?
>
> Right now we have the '__new__' magic method, which isn't a
> @classmethod. Making '__class_getitem__' a @classmethod will confuse
> regular Python users. F
On 15 December 2017 at 18:40, Serhiy Storchaka wrote:
> 15.12.17 19:04, Ivan Levkivskyi пише:
>
>> Good point! Pure Python will be the primary use case and we have another
>> precedent
>> for "automatic" class method: __init_subclass__ (i
On 15 December 2017 at 19:35, Serhiy Storchaka wrote:
> 15.12.17 20:02, Yury Selivanov пише:
>
>> But nobody decorates __new__ with a @staticmethod. And making
>> __class_getitem__ a @classmethod will only confuse users -- that's all
>> I'm saying.
>>
>> So I'm +1 to keep the things exactly as t
@David
What you propose as `Infer` annotation was proposed some time ago (not only
for dataclasses, there are other use cases).
The discussion is here https://github.com/python/typing/issues/276
@Chris
People are still allowed not to use dataclasses if they really don't like
type hints :-)
Serious
On 18 December 2017 at 20:38, Nick Coghlan wrote:
>
> On 19 Dec. 2017 7:00 am, "Chris Barker" wrote:
>
>
> Are there other options??
>
> plain old:
>
> @dataclass
> class C:
> a = 1
> b = 1.0
>
> would work, though then there would be no way to express fields without
> defaults:
>
>
> Th
On 13 December 2017 at 22:35, Yury Selivanov
wrote:
> [..]
> >> A new standard library module ``contextvars`` is added
> >
> > Why not add this to contextlib instead of adding a new module? IIRC
> > this was discussed relative to PEP 550, but I don't remember the
> > reason. Regardless, it woul
On 21 December 2017 at 11:22, Terry Reedy wrote:
> On 12/21/2017 4:22 AM, Eric V. Smith wrote:
>
>> On 12/21/2017 1:46 AM, Chris Barker wrote:
>>
>
> I suggest that it be clear in the docs, and ideally in the PEP, that the
>>> dataclass decorator is using the *annotation" syntax, and that the the
On 26 December 2017 at 01:41, Nick Coghlan wrote:
> On 25 December 2017 at 12:32, Ethan Smith wrote:
> > So at the moment, I don't think it is possible to implement
> singledispatch
> > on classmethod or staticmethod decorated functions.
>
> I've posted this to the PR, but adding it here as well
On 22 December 2017 at 20:55, Brett Cannon wrote:
>
>
> On Fri, Dec 22, 2017, 11:38 Chris Barker, wrote:
>
>> On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon wrote:
>>
>>> I think it's worth reminding people that if they don't like the fact
dataclasses (ab)use type hints for their succinct
FWIW the same problem was discussed a year ago when documenting typing. At
that time the discussion was not conclusive,
so that some types use class:: directive while other use data:: directive.
At that time Guido was in favour of data:: and now in view of
PEP 560 many types in typing will stop bei
I like the Guido's proposal, i.e.
if '__repr__' not in cls.__dict__:
... # generate the method
etc. I didn't find an issue to track this. Maybe we should open one?
--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On 14 January 2018 at 08:20, Chris Angelico wrote:
> On Sun, Jan 14, 2018 at 7:10 PM, joannah nanjekye
> wrote:
> > Hello,
> >
> > Apparently when you implement two methods with the same name:
> >
> > def sub(x, y):
> > print(x -y)
> >
> > def sub(x, y):
> > print(x -y)
> >
> > Even wi
Just wanted to add my 5 cents here. I am a bit surprised how people are
scared by adding `__hash__` to mutable classes.
>From my experience it is quite normal, I was always thinking about `hash()`
as hashing a _value_,
and never as hashing _identity_, if I would need the latter, there is a
differen
> I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tracking yet.
I have the same feelings. I like the GitHub issue tracker, and it would be
great to migrate there (if possible).
--
Ivan
On 21 February 2018 at 21:22, Guido van Rossum
On 22 February 2018 at 10:55, Eric V. Smith wrote:
> On 2/22/2018 1:56 AM, Raymond Hettinger wrote:
>
>> Other immutable classes in Python don't behave the same way:
>
>
>> >>> class T(tuple):
>> pass
>>
>> >>> t = T([10, 20, 30])
>> >>> t.cached = True
>>
>> >>>
Replying also to the list.
On 22 April 2018 at 09:14, Ivan Levkivskyi wrote:
> On 20 April 2018 at 21:59, Guido van Rossum wrote:
>
>> Does the PEP currently propose to *allow* that horrible example? I
>> thought Tim Peters successfully pleaded to *only* allow a single "
On 12 April 2018 at 09:59, Ethan Smith wrote:
> Hello,
>
> I've updated PEP 561 to clarify that any installed stub package should
> supersede an installed inline package. In other words if there is:
>
> /global/site-packages/pkg/
> /user/site-packages/pkg-stubs/
>
> Even if pkg in the global site
On 24 April 2018 at 08:12, Greg Ewing wrote:
> Chris Jerdonek wrote:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>>>
> "if diff, which we let equal x - x_base, and g, which ..." or
>> "if diff, which we set equal to x - x_base, and g, which " or
>> "if diff, which we define
On 7 May 2018 at 03:25, Nick Coghlan wrote:
> On 7 May 2018 at 11:30, Dan Stromberg wrote:
>
>> I'd very much like a live in a world where Jython and IronPython and
>> MicroPython and Cython and Pyjamas can all catch up and implement
>> Python 3.7, 3.8, and so forth.
>>
>
> I'm inclined to agree
On 7 May 2018 at 17:32, Brett Cannon wrote:
>
>
> On Mon, 7 May 2018 at 08:18 João Santos wrote:
>
>> Hi,
>>
>> I would like to see this go even further and have a tick-tock approach to
>> python versions, i.e. adopt new syntax and other large changes on one
>> version (for example odd versions)
> 2. Pickle support in typing is not perfect. I was going to fix it (I had
almost ready code), but lost a chance of doing this before. It can be
changed in 3.7.1, but this means that pickles of some derived typing types
created in 3.7.0 will be not compatible with future versions (may be 3.7.1
will
> But cases not supported before 3.7 (like List[int]) now produce fragile
pickles.
List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry
too much about this because it never worked in 3.6.
I remember you proposed using __getitem__ in __reduce__, but I am not sure
it is a better
On 19 June 2018 at 13:02, Nick Coghlan wrote:
> On 19 June 2018 at 16:12, INADA Naoki wrote:
> >
> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer
> wrote:
> >>
> >> On 2018-06-18 16:55, INADA Naoki wrote:
> >> > Speeding up most python function and some bultin functions was very
> >> > signif
1 - 100 of 197 matches
Mail list logo
