Let's not change pprint.
On Fri, Dec 22, 2017 at 7:44 AM, Eric Fahlgren
wrote:
> On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> I understand the motivation to guarantee order, but it's a programmer
>> convenience that has nothing to do w
On Fri, Dec 22, 2017 at 1:18 PM, MRAB wrote:
>
>> The function is "any", the type is "Any", and "any" != "Any", although I
> wonder how many people will be caught out by that...
enough that it's a bad idea
oh well.
-CHB
> ___
> Python-Dev ma
On 2017-12-22 21:02, Mike Miller wrote:
On 2017-12-22 12:15, Chris Barker wrote:
Would it be crazy to bring typing.Any into the builtin namespace?
@dataclass:
a: Any
b: Any = 34
c: int = 0
That reads pretty well to me
> And having Any available in the built in namespace
On 2017-12-22 12:15, Chris Barker wrote:
Would it be crazy to bring typing.Any into the builtin namespace?
@dataclass:
a: Any
b: Any = 34
c: int = 0
That reads pretty well to me
> And having Any available in the built in namespace may help in other cases
where
There is al
There name Data seems very intuitive to me without suggesting type
declaration as Any does (but it can still be treated as a synonym by actual
type checkers)
On Dec 22, 2017 12:12 PM, "Paul Moore" wrote:
> On 22 December 2017 at 19:50, Gregory P. Smith wrote:
>
> > My preference for this is "ju
On Fri, Dec 22, 2017 at 10:10 AM, Stephan Hoyer wrote:
> On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi
> wrote:
>
>>
> * ... (ellipsis): this class may or may not be used with static type
>> checkers, use the inferred type in the latter case
>>
>
> * "field docstring": this class should not
On 22 December 2017 at 19:50, Gregory P. Smith wrote:
> My preference for this is "just use Any" for anyone not concerned about the
> type. But if we wanted to make it more opaque so that people need not
> realizing that they are actually type annotations, I suggest adding an alias
> for Any in
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 syntax that you can
>>> always use attrs instead to avoid type
On Thu, Dec 21, 2017 at 10:47 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> > On Dec 21, 2017, at 3:21 PM, Gregory P. Smith wrote:
> >
> > It seems a suggested use is "from dataclasses import dataclass"
> >
> > But people are already familiar with "from collections import
> nam
On Fri, Dec 22, 2017 at 11:40 AM Chris Barker wrote:
> On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon
>
But I think the key point I want to make is Guido chose dataclasses to
>> support using the type hints syntax specifically over how attrs does
>> things, so I don't see this thread trying to wo
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 syntax that you can
>> always use attrs instead to avoid type hints.
>>
>
sure -- but this doesn't really address the i
On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi
wrote:
> For me, the three options for "don't care" have a bit different meaning:
>
> * typing.Any: this class is supposed to be used with static type checkers,
> but this field is too dynamic
> * ... (ellipsis): this class may or may not be used wi
On Thu, Dec 21, 2017, 03:37 Ivan Levkivskyi, wrote:
> 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
datacl
ACTIVITY SUMMARY (2017-12-15 - 2017-12-22)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6342 (+12)
closed 37819 (+64)
total 44161 (+76)
Open issues wi
On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> I understand the motivation to guarantee order, but it's a programmer
> convenience that has nothing to do with the idea of mapping, and the
> particular (insertion) order is very special and usual
15 matches
Mail list logo
