On Tue, Aug 20, 2019 at 1:41 PM Robert Bradshaw wrote:
> On Mon, Aug 19, 2019 at 5:44 PM Ahmet Altay wrote:
> >
> >
> >
> > On Mon, Aug 19, 2019 at 9:56 AM Brian Hulette
> wrote:
> >>
> >>
> >>
> >> On Fri, Aug 16, 2019 at 5:17 PM Chad Dombrova
> wrote:
>
> >> Agreed on float since
On Mon, Aug 19, 2019 at 5:44 PM Ahmet Altay wrote:
>
>
>
> On Mon, Aug 19, 2019 at 9:56 AM Brian Hulette wrote:
>>
>>
>>
>> On Fri, Aug 16, 2019 at 5:17 PM Chad Dombrova wrote:
>> Agreed on float since it seems to trivially map to a double, but I’m
>> torn on int still. While I
On Mon, Aug 19, 2019 at 9:56 AM Brian Hulette wrote:
>
>
> On Fri, Aug 16, 2019 at 5:17 PM Chad Dombrova wrote:
>
>> >> Agreed on float since it seems to trivially map to a double, but I’m
>>> torn on int still. While I do want int type hints to work, it doesn’t seem
>>> appropriate to map it
On Fri, Aug 16, 2019 at 5:17 PM Chad Dombrova wrote:
> >> Agreed on float since it seems to trivially map to a double, but I’m
>> torn on int still. While I do want int type hints to work, it doesn’t seem
>> appropriate to map it to AtomicType.INT64, since it has a completely
>> different range
>
> >> Agreed on float since it seems to trivially map to a double, but I’m
> torn on int still. While I do want int type hints to work, it doesn’t seem
> appropriate to map it to AtomicType.INT64, since it has a completely
> different range of values.
> >>
> >> Let’s say we used native int for
On Wed, Aug 7, 2019 at 11:12 PM Brian Hulette wrote:
>
> Thanks for all the suggestions, I've added responses inline.
>
> On Wed, Aug 7, 2019 at 12:52 PM Chad Dombrova wrote:
>>
>> There’s a lot of ground to cover here, so I’m going to pull from a few
>> different responses.
>>
>>
Thanks for all the suggestions, I've added responses inline.
On Wed, Aug 7, 2019 at 12:52 PM Chad Dombrova wrote:
> There’s a lot of ground to cover here, so I’m going to pull from a few
> different responses.
> --
>
> numpy ints
>
> A properly written library should
On Tue, Aug 6, 2019 at 3:55 AM Robert Bradshaw wrote:
> On Sun, Aug 4, 2019 at 12:03 AM Chad Dombrova wrote:
> >
> > Hi,
> >
> > This looks like a great feature.
> >
> > Is there a plan to eventually support custom field types?
> >
> > I assume adding support for dataclasses in python 3.7+
On Wed, Aug 7, 2019 at 10:51 AM Brian Hulette wrote:
> If it is not a big deal supporting both sounds good. I was actually
>> referring to your comment about typing.Collection not being available on
>> python 2.
>>
>
> Oh, of course, sorry somehow that completely slipped my mind. Now that I'm
>
>
> If it is not a big deal supporting both sounds good. I was actually
> referring to your comment about typing.Collection not being available on
> python 2.
>
Oh, of course, sorry somehow that completely slipped my mind. Now that I'm
actually thinking it through, you're right there are several
On Sun, Aug 4, 2019 at 12:03 AM Chad Dombrova wrote:
>
> Hi,
>
> This looks like a great feature.
>
> Is there a plan to eventually support custom field types?
>
> I assume adding support for dataclasses in python 3.7+ should be trivial to
> do in a follow up PR. Do you see any complications
Hi,
This looks like a great feature.
Is there a plan to eventually support custom field types?
I assume adding support for dataclasses in python 3.7+ should be trivial to
do in a follow up PR. Do you see any complications with that? The main
advantage that dataclasses have over NamedTuple in
To clarify, I am happy to start with implementation and iterating on it. I
do not want to block this late into the discussion.
On Fri, Aug 2, 2019 at 6:03 PM Brian Hulette wrote:
> I meant "or sub-class it and define fields with type annotations" not
> "with attributes". I believe that version
I meant "or sub-class it and define fields with type annotations" not "with
attributes". I believe that version doesn't work in python 2 since it
doesn't support the `name: type` syntax.
On Fri, Aug 2, 2019 at 5:55 PM Brian Hulette wrote:
> > Do we need to support python 2? If supporting python
> Do we need to support python 2? If supporting python 2 will complicate
things, we could make this a python3 only feature.
I don't think supporting python 2 complicates things. It's just that there
are two different ways to use typing.NamedTuple in python 3 - you can
either instantiate it and
Thank you Brian.
I did not spend enough time yet to review. Some early questions, I
apologize if I missed an earlier discussion.
- Do we need to support python 2? If supporting python 2 will complicate
things, we could make this a python3 only feature.
- Why are we mapping to numpy types? Design
tl;dr: I have a PR at [1] that defines an initial Schema API in python
based on the typing module, and uses typing.NamedTuple to represent a
Schema. There are some risks with that approach but I propose we move
forward with it as a first draft and iterate.
I've opened up a PR [1] that implements
17 matches
Mail list logo
