Seconds and milliseconds confusion in python thin client

[Igor Sapego-2]

Hi Igniters,

I've noticed a weird behaviour of python thin client. In those places where
we have
timeouts or any other parameters that take time in some places we treat it
like integer
number of milliseconds, in others it can take both floats (as a number of
seconds)
and ints (number of milliseconds). This approach looks very confusing to me
as
it leads to things where tx_start(1) and tx_start(1.0) are not actually the
same thing.

AFAIK in python the most common way to pass time to such functions is to
use floats
as a number of seconds. This is the approach I propose to use in our API as
well. Let's
deprecate usage of ints in those functions with the appropriate warning
before getting rid
of it.

What do you think?

Best Regards,
Igor

[Ivan Daschinsky]

Igor, I suppose that you are probably right. But there is no need to notice
or deprecate something. This functionality is not released yet

вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:

> Hi Igniters,
>
> I've noticed a weird behaviour of python thin client. In those places where
> we have
> timeouts or any other parameters that take time in some places we treat it
> like integer
> number of milliseconds, in others it can take both floats (as a number of
> seconds)
> and ints (number of milliseconds). This approach looks very confusing to me
> as
> it leads to things where tx_start(1) and tx_start(1.0) are not actually the
> same thing.
>
> AFAIK in python the most common way to pass time to such functions is to
> use floats
> as a number of seconds. This is the approach I propose to use in our API as
> well. Let's
> deprecate usage of ints in those functions with the appropriate warning
> before getting rid
> of it.
>
> What do you think?
>
> Best Regards,
> Igor
>

[Ivan Daschinsky]

BTW, common approach is to treat both ints and floats as seconds. Floats
are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0)
and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it,
stop voting for 0.5.0.rc0 and schedule next vote.

вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky <[hidden email]>:

> Igor, I suppose that you are probably right. But there is no need to
> notice or deprecate something. This functionality is not released yet
>
> вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:
>
>> Hi Igniters,
>>
>> I've noticed a weird behaviour of python thin client. In those places
>> where
>> we have
>> timeouts or any other parameters that take time in some places we treat it
>> like integer
>> number of milliseconds, in others it can take both floats (as a number of
>> seconds)
>> and ints (number of milliseconds). This approach looks very confusing to
>> me
>> as
>> it leads to things where tx_start(1) and tx_start(1.0) are not actually
>> the
>> same thing.
>>
>> AFAIK in python the most common way to pass time to such functions is to
>> use floats
>> as a number of seconds. This is the approach I propose to use in our API
>> as
>> well. Let's
>> deprecate usage of ints in those functions with the appropriate warning
>> before getting rid
>> of it.
>>
>> What do you think?
>>
>> Best Regards,
>> Igor
>>
>

[Igor Sapego-2]

Why is it not released?

I can see client.sql(timeout) in 0.4.0 for example, which is int number of
ms.

Best Regards,
Igor


On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky <[hidden email]>
wrote:

> BTW, common approach is to treat both ints and floats as seconds. Floats
> are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0)
> and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it,
> stop voting for 0.5.0.rc0 and schedule next vote.
>
> вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky <[hidden email]>:
>
> > Igor, I suppose that you are probably right. But there is no need to
> > notice or deprecate something. This functionality is not released yet
> >
> > вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:
> >
> >> Hi Igniters,
> >>
> >> I've noticed a weird behaviour of python thin client. In those places
> >> where
> >> we have
> >> timeouts or any other parameters that take time in some places we treat
> it
> >> like integer
> >> number of milliseconds, in others it can take both floats (as a number
> of
> >> seconds)
> >> and ints (number of milliseconds). This approach looks very confusing to
> >> me
> >> as
> >> it leads to things where tx_start(1) and tx_start(1.0) are not actually
> >> the
> >> same thing.
> >>
> >> AFAIK in python the most common way to pass time to such functions is to
> >> use floats
> >> as a number of seconds. This is the approach I propose to use in our API
> >> as
> >> well. Let's
> >> deprecate usage of ints in those functions with the appropriate warning
> >> before getting rid
> >> of it.
> >>
> >> What do you think?
> >>
> >> Best Regards,
> >> Igor
> >>
> >
>

[Ivan Daschinsky]

Ops, i don't even know about it. I believe that this is so rarely used, i
don't even noticed it. I am talking about transactions and expiry policy. I
suppose that in the case of sql we can simply change it.

ср, 16 июн. 2021 г., 00:46 Igor Sapego <[hidden email]>:

> Why is it not released?
>
> I can see client.sql(timeout) in 0.4.0 for example, which is int number of
> ms.
>
> Best Regards,
> Igor
>
>
> On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky <[hidden email]>
> wrote:
>
> > BTW, common approach is to treat both ints and floats as seconds. Floats
> > are used to set timeout with millisecods precision. I.e.
> asyncio.sleep(1.0)
> > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for
> it,
> > stop voting for 0.5.0.rc0 and schedule next vote.
> >
> > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky <[hidden email]>:
> >
> > > Igor, I suppose that you are probably right. But there is no need to
> > > notice or deprecate something. This functionality is not released yet
> > >
> > > вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:
> > >
> > >> Hi Igniters,
> > >>
> > >> I've noticed a weird behaviour of python thin client. In those places
> > >> where
> > >> we have
> > >> timeouts or any other parameters that take time in some places we
> treat
> > it
> > >> like integer
> > >> number of milliseconds, in others it can take both floats (as a number
> > of
> > >> seconds)
> > >> and ints (number of milliseconds). This approach looks very confusing
> to
> > >> me
> > >> as
> > >> it leads to things where tx_start(1) and tx_start(1.0) are not
> actually
> > >> the
> > >> same thing.
> > >>
> > >> AFAIK in python the most common way to pass time to such functions is
> to
> > >> use floats
> > >> as a number of seconds. This is the approach I propose to use in our
> API
> > >> as
> > >> well. Let's
> > >> deprecate usage of ints in those functions with the appropriate
> warning
> > >> before getting rid
> > >> of it.
> > >>
> > >> What do you think?
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >
> >
>

[Ivan Daschinsky]

I've created ticket for it https://issues.apache.org/jira/browse/IGNITE-14911

ср, 16 июн. 2021 г. в 08:37, Ivan Daschinsky <[hidden email]>:

>
> Ops, i don't even know about it. I believe that this is so rarely used, i don't even noticed it. I am talking about transactions and expiry policy. I suppose that in the case of sql we can simply change it.
>
> ср, 16 июн. 2021 г., 00:46 Igor Sapego <[hidden email]>:
>>
>> Why is it not released?
>>
>> I can see client.sql(timeout) in 0.4.0 for example, which is int number of
>> ms.
>>
>> Best Regards,
>> Igor
>>
>>
>> On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky <[hidden email]>
>> wrote:
>>
>> > BTW, common approach is to treat both ints and floats as seconds. Floats
>> > are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0)
>> > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it,
>> > stop voting for 0.5.0.rc0 and schedule next vote.
>> >
>> > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky <[hidden email]>:
>> >
>> > > Igor, I suppose that you are probably right. But there is no need to
>> > > notice or deprecate something. This functionality is not released yet
>> > >
>> > > вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:
>> > >
>> > >> Hi Igniters,
>> > >>
>> > >> I've noticed a weird behaviour of python thin client. In those places
>> > >> where
>> > >> we have
>> > >> timeouts or any other parameters that take time in some places we treat
>> > it
>> > >> like integer
>> > >> number of milliseconds, in others it can take both floats (as a number
>> > of
>> > >> seconds)
>> > >> and ints (number of milliseconds). This approach looks very confusing to
>> > >> me
>> > >> as
>> > >> it leads to things where tx_start(1) and tx_start(1.0) are not actually
>> > >> the
>> > >> same thing.
>> > >>
>> > >> AFAIK in python the most common way to pass time to such functions is to
>> > >> use floats
>> > >> as a number of seconds. This is the approach I propose to use in our API
>> > >> as
>> > >> well. Let's
>> > >> deprecate usage of ints in those functions with the appropriate warning
>> > >> before getting rid
>> > >> of it.
>> > >>
>> > >> What do you think?
>> > >>
>> > >> Best Regards,
>> > >> Igor
>> > >>
>> > >
>> >

--
Sincerely yours, Ivan Daschinskiy

[Ivan Daschinsky]

I have a compromise variant.

1. Large timeouts are set usually only for expire_policy. I suggest to
support datetime.timedelta here and int as milliseconds
2. All others timeouts should accept only ints as milliseconds.
3. Only timeout in Connection as sockettimeout should remain float in
seconds, because it corresponds to socket.settimeout method in python
(accepts floating point number)

This is a compromise between usability and backward compatibility

WDYT?

ср, 16 июн. 2021 г. в 11:09, Ivan Daschinsky <[hidden email]>:

>
> I've created ticket for it https://issues.apache.org/jira/browse/IGNITE-14911
>
> ср, 16 июн. 2021 г. в 08:37, Ivan Daschinsky <[hidden email]>:
> >
> > Ops, i don't even know about it. I believe that this is so rarely used, i don't even noticed it. I am talking about transactions and expiry policy. I suppose that in the case of sql we can simply change it.
> >
> > ср, 16 июн. 2021 г., 00:46 Igor Sapego <[hidden email]>:
> >>
> >> Why is it not released?
> >>
> >> I can see client.sql(timeout) in 0.4.0 for example, which is int number of
> >> ms.
> >>
> >> Best Regards,
> >> Igor
> >>
> >>
> >> On Tue, Jun 15, 2021 at 11:52 PM Ivan Daschinsky <[hidden email]>
> >> wrote:
> >>
> >> > BTW, common approach is to treat both ints and floats as seconds. Floats
> >> > are used to set timeout with millisecods precision. I.e. asyncio.sleep(1.0)
> >> > and asyncio.sleep(1) pauses coroutine for 1 sec. Lets create ticket for it,
> >> > stop voting for 0.5.0.rc0 and schedule next vote.
> >> >
> >> > вт, 15 июн. 2021 г., 23:49 Ivan Daschinsky <[hidden email]>:
> >> >
> >> > > Igor, I suppose that you are probably right. But there is no need to
> >> > > notice or deprecate something. This functionality is not released yet
> >> > >
> >> > > вт, 15 июн. 2021 г., 23:41 Igor Sapego <[hidden email]>:
> >> > >
> >> > >> Hi Igniters,
> >> > >>
> >> > >> I've noticed a weird behaviour of python thin client. In those places
> >> > >> where
> >> > >> we have
> >> > >> timeouts or any other parameters that take time in some places we treat
> >> > it
> >> > >> like integer
> >> > >> number of milliseconds, in others it can take both floats (as a number
> >> > of
> >> > >> seconds)
> >> > >> and ints (number of milliseconds). This approach looks very confusing to
> >> > >> me
> >> > >> as
> >> > >> it leads to things where tx_start(1) and tx_start(1.0) are not actually
> >> > >> the
> >> > >> same thing.
> >> > >>
> >> > >> AFAIK in python the most common way to pass time to such functions is to
> >> > >> use floats
> >> > >> as a number of seconds. This is the approach I propose to use in our API
> >> > >> as
> >> > >> well. Let's
> >> > >> deprecate usage of ints in those functions with the appropriate warning
> >> > >> before getting rid
> >> > >> of it.
> >> > >>
> >> > >> What do you think?
> >> > >>
> >> > >> Best Regards,
> >> > >> Igor
> >> > >>
> >> > >
> >> >
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy

--
Sincerely yours, Ivan Daschinskiy