[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Kyle Stanley]

> Hm, but doesn't the OP's example require *synchronously* reading and
writing the state?

Correct. But in the OP's example, they wanted to use their own
"FakeCondition" for reading and writing the state, rather than the
executor's internal condition (which is bypassed when you directly access
or modify the state through future._state instead of the public methods).
That's why I proposed to add something like future.state(). In the case of
the OP's example, they would presumably access future.state() through
"FakeCondition".

Or am I misunderstanding something?

On Mon, Feb 17, 2020 at 12:03 AM Guido van Rossum  wrote:

> Hm, but doesn't the OP's example require *synchronously* reading and
> writing the state?
>
> On Sun, Feb 16, 2020 at 4:47 PM Kyle Stanley  wrote:
>
>> > That sounds useful to me indeed.  I assume you mean something like a
>> > state() method?  We already have Queue.qsize() which works a bit like
>> > this (unlocked and advisory).
>>
>> Yep, a `Future.state()` method is exactly what I had in mind! I hadn't
>> considered that `Queue.qsize()` was analogous, but that's a perfect example.
>>
>> Based on the proposal in the OP, I had considered that it might also be
>> needed to be able to manually set the state of the future through something
>> like a `Future.set_state()`, which would have a parameter for accessing it
>> safely through the condition's RLock, and another without it (in case they
>> want to specify their own, such as in the OP's example code).
>>
>> Lastly, it seemed also useful to be able to publicly use the future state
>> constants. This isn't necessary for extending them, but IMO it would look
>> better from an API design perspective to use `future.set_state(cf.RUNNING)`
>> instead of `future.set_state(cf._base.RUNNING)` or
>> `future.set_state("running") [1].
>>
>> Combining the above, this would look something like
>> `future.set_state(cf.FINISHED)`, instead of the current private means of
>> modifying them with `future._state = cf._base.FINISHED` or `future._state =
>> "finished"`.
>>
>> Personally, I'm most strongly in favor of adding Future.state(), as it
>> would be personally useful for me (for reasons previously mentioned); but I
>> think that the other two would be useful for properly extending the Future
>> class without having to access private members. This was more formally
>> proposed in https://bugs.python.org/issue39645.
>>
>>
>> [1] - Setting running was just an example, although normally that would
>> be just done in the executor through `Future.set_running_or_notify_cancel
>> ()`.
>>
>> On Sun, Feb 16, 2020 at 6:00 PM Antoine Pitrou 
>> wrote:
>>
>>> On Sun, 16 Feb 2020 17:41:36 -0500
>>> Kyle Stanley  wrote:
>>> >
>>> > As a side note, are we still interested in expanding the public API
>>> for the
>>> > Future class? Particularly for a public means of accessing the state.
>>> The
>>> > primary motivation for it was this topic, but I could easily the same
>>> > issues coming up with custom Future and Executor classes; not to
>>> mention
>>> > the general debugging usefulness for being able to log the current
>>> state of
>>> > the future (without relying on private members).
>>>
>>> That sounds useful to me indeed.  I assume you mean something like a
>>> state() method?  We already have Queue.qsize() which works a bit like
>>> this (unlocked and advisory).
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>> ___
>>> Python-ideas mailing list -- python-ideas@python.org
>>> To unsubscribe send an email to python-ideas-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/7ZQE3IB4NR7ZPLLKWIY54PW3X5K6YWUF/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/BT5AKV4AOACU6TFYI6MIQXC6RK7BQFEK/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JQWCUIV5VLKAI54TVGNZQTR72R4LVK4E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Guido van Rossum]

Hm, but doesn't the OP's example require *synchronously* reading and
writing the state?

On Sun, Feb 16, 2020 at 4:47 PM Kyle Stanley  wrote:

> > That sounds useful to me indeed.  I assume you mean something like a
> > state() method?  We already have Queue.qsize() which works a bit like
> > this (unlocked and advisory).
>
> Yep, a `Future.state()` method is exactly what I had in mind! I hadn't
> considered that `Queue.qsize()` was analogous, but that's a perfect example.
>
> Based on the proposal in the OP, I had considered that it might also be
> needed to be able to manually set the state of the future through something
> like a `Future.set_state()`, which would have a parameter for accessing it
> safely through the condition's RLock, and another without it (in case they
> want to specify their own, such as in the OP's example code).
>
> Lastly, it seemed also useful to be able to publicly use the future state
> constants. This isn't necessary for extending them, but IMO it would look
> better from an API design perspective to use `future.set_state(cf.RUNNING)`
> instead of `future.set_state(cf._base.RUNNING)` or
> `future.set_state("running") [1].
>
> Combining the above, this would look something like
> `future.set_state(cf.FINISHED)`, instead of the current private means of
> modifying them with `future._state = cf._base.FINISHED` or `future._state =
> "finished"`.
>
> Personally, I'm most strongly in favor of adding Future.state(), as it
> would be personally useful for me (for reasons previously mentioned); but I
> think that the other two would be useful for properly extending the Future
> class without having to access private members. This was more formally
> proposed in https://bugs.python.org/issue39645.
>
>
> [1] - Setting running was just an example, although normally that would be
> just done in the executor through `Future.set_running_or_notify_cancel()`.
>
>
> On Sun, Feb 16, 2020 at 6:00 PM Antoine Pitrou 
> wrote:
>
>> On Sun, 16 Feb 2020 17:41:36 -0500
>> Kyle Stanley  wrote:
>> >
>> > As a side note, are we still interested in expanding the public API for
>> the
>> > Future class? Particularly for a public means of accessing the state.
>> The
>> > primary motivation for it was this topic, but I could easily the same
>> > issues coming up with custom Future and Executor classes; not to mention
>> > the general debugging usefulness for being able to log the current
>> state of
>> > the future (without relying on private members).
>>
>> That sounds useful to me indeed.  I assume you mean something like a
>> state() method?  We already have Queue.qsize() which works a bit like
>> this (unlocked and advisory).
>>
>> Regards
>>
>> Antoine.
>>
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/7ZQE3IB4NR7ZPLLKWIY54PW3X5K6YWUF/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BT5AKV4AOACU6TFYI6MIQXC6RK7BQFEK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7LPVJ6OPAFG7IZDGYU5FDXD4SX54KDN4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Traits

[Stephen J. Turnbull]

Steven D'Aprano writes:
 > On Sun, Feb 16, 2020 at 06:08:54PM +0900, Stephen J. Turnbull wrote:
 > > Answering off-list by moderator request.
 > 
 > Are you sure about that? :-)

I'm not sure about much of anything these days.  I know how to do it,
I just didn't. :-( My apologies to all.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/P5DIAGZUJYVL5SBSSZDNDUUHYLI6POOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Kyle Stanley]

> That sounds useful to me indeed.  I assume you mean something like a
> state() method?  We already have Queue.qsize() which works a bit like
> this (unlocked and advisory).

Yep, a `Future.state()` method is exactly what I had in mind! I hadn't
considered that `Queue.qsize()` was analogous, but that's a perfect example.

Based on the proposal in the OP, I had considered that it might also be
needed to be able to manually set the state of the future through something
like a `Future.set_state()`, which would have a parameter for accessing it
safely through the condition's RLock, and another without it (in case they
want to specify their own, such as in the OP's example code).

Lastly, it seemed also useful to be able to publicly use the future state
constants. This isn't necessary for extending them, but IMO it would look
better from an API design perspective to use `future.set_state(cf.RUNNING)`
instead of `future.set_state(cf._base.RUNNING)` or
`future.set_state("running") [1].

Combining the above, this would look something like
`future.set_state(cf.FINISHED)`, instead of the current private means of
modifying them with `future._state = cf._base.FINISHED` or `future._state =
"finished"`.

Personally, I'm most strongly in favor of adding Future.state(), as it
would be personally useful for me (for reasons previously mentioned); but I
think that the other two would be useful for properly extending the Future
class without having to access private members. This was more formally
proposed in https://bugs.python.org/issue39645.


[1] - Setting running was just an example, although normally that would be
just done in the executor through `Future.set_running_or_notify_cancel()`.

On Sun, Feb 16, 2020 at 6:00 PM Antoine Pitrou  wrote:

> On Sun, 16 Feb 2020 17:41:36 -0500
> Kyle Stanley  wrote:
> >
> > As a side note, are we still interested in expanding the public API for
> the
> > Future class? Particularly for a public means of accessing the state. The
> > primary motivation for it was this topic, but I could easily the same
> > issues coming up with custom Future and Executor classes; not to mention
> > the general debugging usefulness for being able to log the current state
> of
> > the future (without relying on private members).
>
> That sounds useful to me indeed.  I assume you mean something like a
> state() method?  We already have Queue.qsize() which works a bit like
> this (unlocked and advisory).
>
> Regards
>
> Antoine.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7ZQE3IB4NR7ZPLLKWIY54PW3X5K6YWUF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BT5AKV4AOACU6TFYI6MIQXC6RK7BQFEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Antoine Pitrou]

On Sun, 16 Feb 2020 17:41:36 -0500
Kyle Stanley  wrote:
> 
> As a side note, are we still interested in expanding the public API for the
> Future class? Particularly for a public means of accessing the state. The
> primary motivation for it was this topic, but I could easily the same
> issues coming up with custom Future and Executor classes; not to mention
> the general debugging usefulness for being able to log the current state of
> the future (without relying on private members).

That sounds useful to me indeed.  I assume you mean something like a
state() method?  We already have Queue.qsize() which works a bit like
this (unlocked and advisory).

Regards

Antoine.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7ZQE3IB4NR7ZPLLKWIY54PW3X5K6YWUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Kyle Stanley]

> I don't think we need to be dogmatic here.  If someone wants to provide
> it on PyPI, then be it.  But if they'd rather contribute it to the
> stdlib, we should examine the relevant PR at face value.

> Asking it to be exercised first on PyPI is worthwhile if the domain
> space is complex or there are multiple possible APIs.  It's not really
> the case here: the API is basically constrained (it must be an
> Executor) and the main unknown seems to be whether execution is lazily
> or immediate (which may be as well governed by a constructor
> parameter).  And the implementation shouldn't be very hairy either :-)

Alright, fair enough. I suppose that I hadn't adequately considered how
constrained the API and straightforward the implementation would likely be.
If you think it would very likely receive widespread enough usage to
justify adding and maintaining it to the stdlib, I fully trust your
judgement on that. (:

As a side note, are we still interested in expanding the public API for the
Future class? Particularly for a public means of accessing the state. The
primary motivation for it was this topic, but I could easily the same
issues coming up with custom Future and Executor classes; not to mention
the general debugging usefulness for being able to log the current state of
the future (without relying on private members).

On Sun, Feb 16, 2020 at 9:49 AM Antoine Pitrou  wrote:

> On Sun, 16 Feb 2020 09:29:36 -0500
> Kyle Stanley  wrote:
> >
> > After Andrew explained his own use case for it with isolating bugs to
> > ensure that the issue wasn't occurring as a result of parallelism,
> threads,
> > processes, etc; I certainly can see how it would be useful. I could also
> > see a use case in a CLI tool for a conveniently similar parallel and
> > non-parallel version, although I'd likely prefer just having an entirely
> > separate implementation. Particularly if the parallel version includes
> > diving a large, computationally intensive task into many sub-tasks (more
> > common for PPE), that seems like it could result in significant
> additional
> > unneeded overhead for the non-parallel version.
> >
> > I think at this point, it's potential usefulness is clear though. But,
> IMO,
> > the main question is now the following: would it be better *initially*
> > placed in the standard library or on PyPI (which could eventually
> > transition into stdlib if it sees widespread usage)?
>
> I don't think we need to be dogmatic here.  If someone wants to provide
> it on PyPI, then be it.  But if they'd rather contribute it to the
> stdlib, we should examine the relevant PR at face value.
>
> Asking it to be exercised first on PyPI is worthwhile if the domain
> space is complex or there are multiple possible APIs.  It's not really
> the case here: the API is basically constrained (it must be an
> Executor) and the main unknown seems to be whether execution is lazily
> or immediate (which may be as well governed by a constructor
> parameter).  And the implementation shouldn't be very hairy either :-)
>
> Regards
>
> Antoine.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/U5AOBMMGIANXFJEKMZYMWNQSY7D6RPL5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TPT67BK6XWUMYBXVAYVJYL46HXECNCPI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Guido van Rossum]

I'm happy to defer to Antoine, who is the subject expert here (and Brian
Quinlan, the original author).

On Sun, Feb 16, 2020 at 6:48 AM Antoine Pitrou  wrote:

> On Sun, 16 Feb 2020 09:29:36 -0500
> Kyle Stanley  wrote:
> >
> > After Andrew explained his own use case for it with isolating bugs to
> > ensure that the issue wasn't occurring as a result of parallelism,
> threads,
> > processes, etc; I certainly can see how it would be useful. I could also
> > see a use case in a CLI tool for a conveniently similar parallel and
> > non-parallel version, although I'd likely prefer just having an entirely
> > separate implementation. Particularly if the parallel version includes
> > diving a large, computationally intensive task into many sub-tasks (more
> > common for PPE), that seems like it could result in significant
> additional
> > unneeded overhead for the non-parallel version.
> >
> > I think at this point, it's potential usefulness is clear though. But,
> IMO,
> > the main question is now the following: would it be better *initially*
> > placed in the standard library or on PyPI (which could eventually
> > transition into stdlib if it sees widespread usage)?
>
> I don't think we need to be dogmatic here.  If someone wants to provide
> it on PyPI, then be it.  But if they'd rather contribute it to the
> stdlib, we should examine the relevant PR at face value.
>
> Asking it to be exercised first on PyPI is worthwhile if the domain
> space is complex or there are multiple possible APIs.  It's not really
> the case here: the API is basically constrained (it must be an
> Executor) and the main unknown seems to be whether execution is lazily
> or immediate (which may be as well governed by a constructor
> parameter).  And the implementation shouldn't be very hairy either :-)
>
> Regards
>
> Antoine.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/U5AOBMMGIANXFJEKMZYMWNQSY7D6RPL5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EHI2IR4QLKVY4CNZJKRT7JVUMK7T2SSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Andrew Barnert via Python-ideas]

> On Feb 16, 2020, at 05:24, ananthakrishnan15.2...@gmail.com wrote:
> 
> This module should contain operations that can be performed on binary 
> numbers.

I think you have two problems here.

The first is that you’re confusing integer values with integer literal syntax. 
It’s not just that `0b101` and `5` are the exact same number, 5, it’s also that 
all of your operations already make sense for that number 5, and almost all of 
them are already implemented as operators or methods in Python. So the main 
part of your question doesn’t even make sense.

But there is an additional problem: you want integers fixed to a specific bit 
length (and signedness). And not even necessarily the native machine lengths 32 
and 64; you want to be able to do 3-bit arithmetic on 3-bit integers.

For this, what you want is probably not a module with a bunch of functions on 
int, but a new class. I’ll call it BinaryInt, and construct it as BinaryInt(n: 
Integer, *, bits, signed=False), but I think a name that was about being 
fixed-length instead of about being binary might be less confusing, and of 
course you can decide on any constructor form you want. (You may also want to 
be able to take strings, a la decimal.Decimal.)

Whether it’s a subclass of int is up to you. The former is more convenient to 
implement, but subtyping is more important here than implementation. Do you 
want to be able to pass a BinaryInt(0b101, bits=4) to a function that wants an 
int and have it act as the integer 3, or to get a TypeError when you try it? 
(And, if the former, should mypy statically understand that is-a relationship?) 
In fact, there are actually multiple questions here: first, is-a int, is-not-a 
int but has an __int__ method, or not even that; next, if you’re not an int 
subtype, you have to decide whether to fit into the numeric tower as an Integer 
(by subclassing or registering with the ABC); finally, how you want to allow 
mixing types in operators (whether 1+BinaryInt(0b101, bits=4) should be 6, 
BinaryInt(0b110, bits=4), or TypeError).

You also have to define what happens with overflow and underflow. When you add 
4-bit unsigned 1110 and , do you get 1101 (modulo, like C),  
(saturating), or OverflowError? Is it different for signed?

And what happens when you add two numbers of different bit lengths?

You can choose whatever str makes sense for your binary ints, but its repr 
should probably look like the constructor call, probably “normalized”, so 
`repr(BinaryInt(5, bits=4))` gives you `BinaryInt(0b0101, bits=4)` and 
`repr(BinaryInt(-2, bits=4))` gives you `BinaryInt(0b1110, bits=4))` and 
`repr(BinaryInt(-2, bits=4, signed=True))` gives you `BinaryInt(-0b010, bits=4, 
signed=True)`.

Without deciding all of these things, you don’t really have a proposal.

But once you do, implementing all the dunder methods is easy, if a bit tedious. 
(You may want to look at the implementation of Fraction for some useful helper 
tricks, especially if you want to act like an int when dealing with other 
types, or even just allow adding different bit lengths.) The handful of things 
that aren’t builtin operators or methods of int, like Gray coding, you can 
decide whether to makes these methods on your type or functions. (I think 
methods make more sense. After all, how can you do gray(8) without specifying 
it’s supposed to be the 4-bit Gray code? But BinaryInt(8, bits=4, 
unsigned=True).gray() has no such problem.)

I doubt this type would be accepted into the stdlib, but even if it isn’t, once 
you build it, you have it, and you can share it on PyPI for others who want it.

Of course first you should search PyPI and make sure it doesn’t already exist. 
There are definitely modules for bitstrings, fixed-power-of-2-length ints, and 
all kinds of other related things, but I don’t know if there’s one for 
fixed-arbitrary-length ints.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XRY7MAWFUVG5U2LYZLAYIUZD3U2K5LAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Barry Scott]

> On 16 Feb 2020, at 17:49, ananthan ananthan 
>  wrote:
> 
> But there is a problem with (0b1101).
> 
> 5==0b101
> -5==-0b101
> 
> but we want output   -5==1011.
> so this is not possible by using integers with base designator "0b".

There is no such thing as an 'integers with base designator "0b"'.

I think are confusing the type that python uses for an integer with the
syntax that python allows you to use to specify an integer in your source code.

Python considers the follow the same

5
0o5
0x5
0b101

> so we have to use new Python type that represents a "binary number",which 
> accepts
> number of bits,sign of number.

You can write such a type or just mask off the results of the computation
with the python integer type.

Your example -5 in 4 bits is this

>>> print( bin( -5 & 0b ) )
0x1011

Exactly what you want?

Barry
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PUHAKO5DZ5ZWSY6R3RPKPABDHGGNV7CE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthan ananthan]

But there is a problem with (0b1101).

5==0b101
-5==-0b101

but we want output   -5==1011.
so this is not possible by using integers with base designator "0b".
so we have to use new Python type that represents a "binary number",which 
accepts
number of bits,sign of number.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NXGSX5JJRNZYA3EN3H5PRS3WKI276T6B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthan ananthan]

But there is a problem with (0b1101).

5==0b101
-5==-0b101

but we want output -5==1011.

so this is not possible by using integers with base designator "0b".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JF2M6KA5NWH743RBIGSDQMLHUE6OOUM4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Chris Angelico]

On Mon, Feb 17, 2020 at 3:40 AM Mark Dickinson  wrote:
>
> ananthakrishnan15.2001＠gmail.com wrote:
> > binary.twos_complement(0b0011)==1101
> > binary.twos_complement(0b0011)==1101
>
> How would you make that possible, when `0b0011` and `0b0011` are the 
> exact same integer?

Easy: you simply have 0b1101 and 0b1101 actually be display
phenomena. Both of them represent -3 in a particular field size.
Unfortunately the built-in bin() function doesn't take a width
argument, but you can easily create that:

def binary(n, width=None):
if width: return format(n & (1

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

a and b should be integer with base designator "b" (0b110011) .OR there should 
be a_new_ Python type that represents a "binary number",which accepts number of 
bits,sign of number.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PICGSPBWFR2GMB63SYCQQXREHTJ7XYXB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

Then can we use a new Python type that represents a "binary number",which 
accepts number of bits,sign of
number.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A7D2TDYARGSKQDLVFB2YPIIPKXELWMML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Mark Dickinson]

ananthakrishnan15.2001＠gmail.com wrote:
> binary.twos_complement(0b0011)==1101
> binary.twos_complement(0b0011)==1101

How would you make that possible, when `0b0011` and `0b0011` are the exact 
same integer?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KPE3GZNVI63CXYQW3KGA2KUQM4TLAJDY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

binary.twos_complement(0b0011)==1101
binary.twos_complement(0b0011)==1101
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WIYBPWTWPB6G2TDOKQOAIUSJWUQAH4UL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Barry Scott]

> On 16 Feb 2020, at 09:38, ananthakrishnan15.2...@gmail.com wrote:
> 
> This module should contain operations that can be performed on binary numbers.
> In the below examples a and b are binary numbers.

Assuming you mean that a "binary number" is int then python
can do what you want I think.

> 
> binary.add(a,b)

a + b

> binary.sub(a,b)

a - b

> binary.mul(a,b)

a * b

> binary.div(a,b)

a // b

> binary.ones_complement(a)//returns 1's complement of a.

~a

> binary.twos_complement(a)//returns 2's complement of a.

0 - a

> binary.dectobi(a)//converts decimal "a" to binary of "a".

If a is an int not sure what you expect this to do.

> binary.bcd(a)//returns bcd of a.

Need to know how many bits of a are to be convert then its an easy bit 
of code to write.


> binary.gray(a)   //returns grey code of a.

I suspect this to be application specific.
Are you thinking Digital TV encoding systems?
Is it just a lookup table?

> binary.min() //minimizes.

Need a definition of min

> binarybitodec//converts binar "a" to decimal of "a".

If a is an int not sure what you expect this to do.

Or are you assuming that  "binary number" is something else?
For example are your binary numbers of a specific bit width?
For example an int that only 10 bits are used?

In which case can you do the arithmetic operations as above and mask
down to the number of bits that you need?

Barry



> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/YIAFNIOKFEBVVOSNQ75W4B5MAHRMTB6I/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EQTNLUWMJYSEQLU4QK36VNQJEOQGKN4H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

wea are using 0b1101100002.
hence it will give you a syntax error.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6YVUPXSYBZVTVQYCRJCJXIGQBEJ6TSO3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Mark Dickinson]

ananthakrishnan15.2001＠gmail.com wrote:
> we can use 0b1100 instead of 1100.Then the output of
> binary.twos_complement(0b1100) will be 0b0100

That would be printed as `4`. Is that what you want?

Supposing we accept that `binary.twos_complement(0b1100) == 0b0100`. What would 
`binary.twos_complement(0b0011)` be equal to? What about 
`binary.twos_complement(0b0011)`?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NJY5FWUZXZ74DZG7T67ITV4A67MM3MVQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

I meant we should use base designator(1b110011).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RNDO2SBYR6ZILXCZO7NOH6YJQFJLOPCK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

What would you expect ones_complement(1100) to return? (I'm guessing you'd 
expect a Python int with value 11.)
What about ones_complement(1100)? (I'm guessing that you'd also expect a 
Python int with value 11 here.)
What would ones_complement(ones_complement(1100)) be?
What would ones_complement(ones_complement(1100)) be?

we can use 0b1100 instead of 1100.Then the output of 
binary.twos_complement(0b1100) will be 0b0100
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KUUBDU4DLOC7OEGXFAK6P2LOOGJLWCAP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Paul Moore]

On Sun, 16 Feb 2020 at 16:07,  wrote:
>
> what about
> >>binary.ones_complement(0b110011)
>
> or should we use something like "bitstring".

https://pypi.org/project/bitstring/

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CQE2WJO5RC64PHSVWMVJBXFA2FMUYU6J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

what about
>>binary.ones_complement(0b110011)

or should we use something like "bitstring".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NPUH633LVXCZB5JTX7VOP7OJ2GKOMFUU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Antoine Rozo]

What is 110011 here? A number written in decimal where you want to
interpret digits as binary digits?
Why don't you use 0b110011 to have a litteral written in binary
representation?

Le dim. 16 févr. 2020 à 16:32,  a écrit :
>
> I'll show the example using one's and two's complement.
> >>binary.ones_complement(110011)
> 001100
> >>binary.twos_complement(110011)
> 001101
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/RJLGYE4N7NR6JYFSA64VES375U45PIKW/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JTVV74CXKBOZJ4REKXWQWU4WGEXSNDGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Mark Dickinson]

ananthakrishnan15.2001＠gmail.com wrote:

> >>> binary.ones_complement(1101100001)
> 0010011110

I see. So you want `binary.ones_complement` to accept a nonnegative Python 
`int` whose decimal expansion consists entirely of ones and zeros, interpret 
that decimal expansion as though it's a bit-string, complement, and then return 
another such Python `int`. Is that correct? Note that in that case, the output 
you'd get above would be `10011110`, not `0010011110`.

Quite apart from whether this is a good idea or not, I can't see how this could 
even work.  Can you please answer the following?

1. What would you expect `ones_complement(1100)` to return? (I'm guessing you'd 
expect a Python `int` with value `11`.)
2. What about `ones_complement(1100)`? (I'm guessing that you'd also expect 
a Python `int` with value `11` here.)
3. What would `ones_complement(ones_complement(1100))` be?
4. What would `ones_complement(ones_complement(1100))` be?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XCFO5ZK27CSP6QPPDWTUI6AZY2O22YRW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Paul Moore]

On Sun, 16 Feb 2020 at 15:34,  wrote:
>
> I'll show the example using one's and two's complement.
> >>binary.ones_complement(110011)
> 001100

But these aren't standard Python types - well, technically, 110011
is 1,100,111,111 - 1 billion, 100 million 111 thousand one hundred and
eleven, but I suspect that's not what you intend. And the output -
001100 - is not how Python would print a standard integer type, so
either it's a new type (with its own representation) or you're not
actually using standard Python types.

Are you actually looking for some form of "bit string" type?

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W64DBXP53OIYFZLHPXMB54E5XXKPAALZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Serhiy Storchaka]

16.02.20 17:21, 
ananthakrishnan15.2...@gmail.com пише:

I'll show the example using one's and two's complement.


binary.ones_complement(1101100001)

0010011110

binary.twos_complement(1101100001)

001001


What is the type of the result of binary.ones_complement() and 
binary.twos_complement()? It is obviously some new type, because no 
builtin type has the repr '0010011110'.


What does binary.ones_complement(1101100002) return?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QV2V675J3DSJKNBL75GFCDQMSIPSOBCK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

I'll show the example using one's and two's complement.
>>binary.ones_complement(110011)
001100
>>binary.twos_complement(110011)
001101
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RJLGYE4N7NR6JYFSA64VES375U45PIKW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

we can use int(eg:110011),using base designator(eg:b,B).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AMUQ3SJQHSSCJXS2R2Q3GF2YWINZV7SB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

I'll show the example using one's and two's complement.

>>binary.ones_complement(1101100001)
0010011110
>>binary.twos_complement(1101100001)
001001
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3OLOZRBMDLW5GGDDJJXPWIHS54KRPHIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Antoine Pitrou]

On Sun, 16 Feb 2020 09:29:36 -0500
Kyle Stanley  wrote:
> 
> After Andrew explained his own use case for it with isolating bugs to
> ensure that the issue wasn't occurring as a result of parallelism, threads,
> processes, etc; I certainly can see how it would be useful. I could also
> see a use case in a CLI tool for a conveniently similar parallel and
> non-parallel version, although I'd likely prefer just having an entirely
> separate implementation. Particularly if the parallel version includes
> diving a large, computationally intensive task into many sub-tasks (more
> common for PPE), that seems like it could result in significant additional
> unneeded overhead for the non-parallel version.
> 
> I think at this point, it's potential usefulness is clear though. But, IMO,
> the main question is now the following: would it be better *initially*
> placed in the standard library or on PyPI (which could eventually
> transition into stdlib if it sees widespread usage)?

I don't think we need to be dogmatic here.  If someone wants to provide
it on PyPI, then be it.  But if they'd rather contribute it to the
stdlib, we should examine the relevant PR at face value.

Asking it to be exercised first on PyPI is worthwhile if the domain
space is complex or there are multiple possible APIs.  It's not really
the case here: the API is basically constrained (it must be an
Executor) and the main unknown seems to be whether execution is lazily
or immediate (which may be as well governed by a constructor
parameter).  And the implementation shouldn't be very hairy either :-)

Regards

Antoine.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U5AOBMMGIANXFJEKMZYMWNQSY7D6RPL5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Mark Dickinson]

ananthakrishnan15.2001＠gmail.com wrote:
> I'm proposing a module that has functions intended to work with existing 
> python
> types.

Okay, great. *Which* Python types, specifically? `int`? `bytes`?

To help us understand, please can you show example inputs to and output from 
your proposed `binary.add` function, making it clear what the types of the 
inputs and output are?



> Digital electronics is completely based on "binary number system".As python 
> is used in
> almost all fields,by adding a  seperate module for binary containing 
> operations like ones
> complement and twos complement (which are much important in digital 
> electronics) ,those
> who are in the field of digital electronics can make use of this module.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2CGWOXHZYU7AMCSZU6N5X23BYA2WNSKL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[ananthakrishnan15 . 2001]

I'm proposing a module that has functions intended to work with existing python 
types.

Digital electronics is completely based on "binary number system".As python is 
used in almost all fields,by adding a  seperate module for binary containing 
operations like ones complement and twos complement (which are much important 
in digital electronics) ,those who are in the field of digital electronics can 
make use of this module.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FPIO7MLFHJBTMNZ3LR5LL2CYF5BASOWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Kyle Stanley]

> FWIW, I agree with Andrew here.  Being able to swap a
> ThreadPoolExecutor or ProcessPoolExecutor with a serial version using
> the same API can have benefits in various situations. One is
> easier debugging (in case the problem you have to debug isn't a race
> condition, of course :-)).  Another is writing a library a command-line
> tool or library where the final decision of whether to parallelize
> execution (e.g. through a command-line option for a CLI tool) is up
> to the user, not the library developer.

After Andrew explained his own use case for it with isolating bugs to
ensure that the issue wasn't occurring as a result of parallelism, threads,
processes, etc; I certainly can see how it would be useful. I could also
see a use case in a CLI tool for a conveniently similar parallel and
non-parallel version, although I'd likely prefer just having an entirely
separate implementation. Particularly if the parallel version includes
diving a large, computationally intensive task into many sub-tasks (more
common for PPE), that seems like it could result in significant additional
unneeded overhead for the non-parallel version.

I think at this point, it's potential usefulness is clear though. But, IMO,
the main question is now the following: would it be better *initially*
placed in the standard library or on PyPI (which could eventually
transition into stdlib if it sees widespread usage)?

> It seems there are two possible design decisions for a serial executor:
> - one is to execute the task immediately on `submit()`
> - another is to execute the task lazily on `result()`

To me, it seems like the latter would be more useful for debugging
purposes, since that would be more similar to how the submitted
task/function would actually be executed. ``submit()`` could potentially
"fake" the process of scheduling the execution of the function, but without
directly executing it; perhaps with something like this:
``executor.submit()`` => create a pending item => add pending item to dict
=> add callable to call queue => fut.result() => check if in pending items
=> get from top of call queue  => run work item => pop from pending items
=> set result/exception => return result (skip last three if fut is not
in/associated with a pending item). IMO, that would be similar enough to
the general workflow followed in the executors without any of the
parallelization.

On Sun, Feb 16, 2020 at 6:29 AM Antoine Pitrou  wrote:

> On Sat, 15 Feb 2020 14:16:39 -0800
> Andrew Barnert via Python-ideas
>  wrote:
> > > On Feb 15, 2020, at 13:36, Jonathan Crall  wrote:
> > >
> > > Also, there is no duck-typed class that behaves like an executor, but
> does its processing in serial. Often times a develop will want to run a
> task in parallel, but depending on the environment they may want to disable
> threading or process execution. To address this I use a utility called a
> `SerialExecutor` which shares an API with
> ThreadPoolExecutor/ProcessPoolExecutor but executes processes sequentially
> in the same python thread:
> >
> > This makes sense. I think most futures-and-executors frameworks in other
> languages have a serial/synchronous/immediate/blocking executor just like
> this. (And the ones that don’t, it’s usually because they have a different
> way to specify the same functionality—e.g., in C++, you only use executors
> via the std::async function, and you can just pass a launch option instead
> of an executor to run synchronously.)
>
> FWIW, I agree with Andrew here.  Being able to swap a
> ThreadPoolExecutor or ProcessPoolExecutor with a serial version using
> the same API can have benefits in various situations.  One is
> easier debugging (in case the problem you have to debug isn't a race
> condition, of course :-)).  Another is writing a library a command-line
> tool or library where the final decision of whether to parallelize
> execution (e.g. through a command-line option for a CLI tool) is up
> to the user, not the library developer.
>
> It seems there are two possible design decisions for a serial executor:
> - one is to execute the task immediately on `submit()`
> - another is to execute the task lazily on `result()`
>
> This could for example be controlled by a constructor argument to
> SerialExecutor.
>
> Regards
>
> Antoine.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PCDN4JMKR7VCWXTEZSMWWIY55NTT3JOM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/l

[Python-ideas] Re: Add Binary module.

[Antoine Rozo]

And what do you call "decimal numbers"? Decimal representation of
numbers like returned by str(123456)?

Le dim. 16 févr. 2020 à 15:00, Mark Dickinson
 a écrit :
>
> ananthakrishnan15.2001＠gmail.com wrote:
> > In the below examples a and b are binary numbers.
>
> Please can you clarify what this means, in Python terms? Are you proposing a 
> _new_ Python type that represents a "binary number", or is `binary.add` (for 
> example) intended to work with existing Python types (for example `int` and 
> `str`)?
>
> Who are the intended users of the new functionality, and what would they use 
> it for? Could you perhaps show some example code that might use the module?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/VGPNG4IBWGRWPEQOAKCNTLBINWQS4BZO/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4AZ3E4BFMGPJABJ7Q4HHH6GFJTBJM5M7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Binary module.

[Mark Dickinson]

ananthakrishnan15.2001＠gmail.com wrote:
> In the below examples a and b are binary numbers.

Please can you clarify what this means, in Python terms? Are you proposing a 
_new_ Python type that represents a "binary number", or is `binary.add` (for 
example) intended to work with existing Python types (for example `int` and 
`str`)?

Who are the intended users of the new functionality, and what would they use it 
for? Could you perhaps show some example code that might use the module?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VGPNG4IBWGRWPEQOAKCNTLBINWQS4BZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add Binary module.

[ananthakrishnan15 . 2001]

This module should contain operations that can be performed on binary numbers.
In the below examples a and b are binary numbers.

binary.add(a,b)
binary.sub(a,b)
binary.mul(a,b)
binary.div(a,b)
binary.ones_complement(a)//returns 1's complement of a.
binary.twos_complement(a)//returns 2's complement of a.
binary.dectobi(a)//converts decimal "a" to binary of "a".
binary.bcd(a)//returns bcd of a.
binary.gray(a)   //returns grey code of a.
binary.min() //minimizes.
binarybitodec//converts binar "a" to decimal of "a".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YIAFNIOKFEBVVOSNQ75W4B5MAHRMTB6I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

[Antoine Pitrou]

On Sat, 15 Feb 2020 14:16:39 -0800
Andrew Barnert via Python-ideas
 wrote:
> > On Feb 15, 2020, at 13:36, Jonathan Crall  wrote:
> > 
> > Also, there is no duck-typed class that behaves like an executor, but does 
> > its processing in serial. Often times a develop will want to run a task in 
> > parallel, but depending on the environment they may want to disable 
> > threading or process execution. To address this I use a utility called a 
> > `SerialExecutor` which shares an API with 
> > ThreadPoolExecutor/ProcessPoolExecutor but executes processes sequentially 
> > in the same python thread:  
> 
> This makes sense. I think most futures-and-executors frameworks in other 
> languages have a serial/synchronous/immediate/blocking executor just like 
> this. (And the ones that don’t, it’s usually because they have a different 
> way to specify the same functionality—e.g., in C++, you only use executors 
> via the std::async function, and you can just pass a launch option instead of 
> an executor to run synchronously.)

FWIW, I agree with Andrew here.  Being able to swap a
ThreadPoolExecutor or ProcessPoolExecutor with a serial version using
the same API can have benefits in various situations.  One is
easier debugging (in case the problem you have to debug isn't a race
condition, of course :-)).  Another is writing a library a command-line
tool or library where the final decision of whether to parallelize
execution (e.g. through a command-line option for a CLI tool) is up
to the user, not the library developer.

It seems there are two possible design decisions for a serial executor:
- one is to execute the task immediately on `submit()`
- another is to execute the task lazily on `result()`

This could for example be controlled by a constructor argument to
SerialExecutor.

Regards

Antoine.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PCDN4JMKR7VCWXTEZSMWWIY55NTT3JOM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Traits

[Steven D'Aprano]

On Sun, Feb 16, 2020 at 06:08:54PM +0900, Stephen J. Turnbull wrote:
> Answering off-list by moderator request.

Are you sure about that? :-)

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MUZS5SJ2W2LQO5SJAUAEIYCOZQ7APIDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Traits

[Stephen J. Turnbull]

Soni,

Answering off-list by moderator request.

Before I go on to respond to the details, let me start by saying I'm
definitely beginning to understand why you like the Rust syntax for
traits, and maybe even some feeling for the semantics, although
they're not very well documented anywhere I found in a couple hours of
Googling and browsing.  On the other hand, I don't think some of
Rust's semantics are a good fit for Python (and go into that below).

Soni L. writes:

 > zope.interface appears to be more based on java interfaces than rust 
 > traits? I could be wrong tho.

zope.interface precedes Rust traits by at least two decades.  I don't
know what the relationship is between zope.interface and Java's
interface is.  Java was released in 1995, Zope in 1998, but Zope's
predecessor, the "Bobo object publisher," was released to the public
in the early 1990s.  Of course interface checking in a very primitive
form (function prototypes) go back to C++'s predecessor "C with
Classes" in 1979, and I imagine Lisp has had them even longer, and in
more elaborated form.  C++ got virtual functions in 1985, which is
much closer to the modern concept of separating interface from
implementation, and abstract classes (classes containing one or more
pure virtual functions) in 1989.  So this stuff was in the air for
several years before either Python or Java started development.

 > *forget* Schärli et al., this is too hard to explain if you keep
 > expecting Schärli et al. behaviour

Not gonna happen.  Thing is, I can hold two behaviors in my mind at
the same time, but it would help if you paid some respect to the
seminal paper that preceded Rust by more than a decade.  At least call
them "Rust traits".  But that doesn't help much, since the Rust
documents are really sparse, even about behavior, let alone about
rationale for the behavior.  I had to Google bug reports to find even
a mention of method name collisions.

 > when Rust quite explicitly doesn't seem to follow that.

I now think you're wrong about Rust following Schärli et al., although
it's impossible to be sure since there are differences, and the design
decision rationales aren't to be found in the places I looked.

 > now everyone's been gaslighting me because I got fed up with this
 > and idk what to do about that. but anyway,

"Gaslighting" is lying about something that both parties can see is
false.  That's not happening here.  There's definitely a lot of
confusion about what you've been talking about.

It's one thing to ask one person (such as me) to learn Rust; it's
another to ask all the core developers to do so.  It's reasonable for
you to say that your time is worth as much as anybody else's, even
Guido's (though I don't recommend saying *that* out loud!)  It's not
reasonable to say that your time is worth as much as everybody else's.

 > > In the TOSWidget example, as I understand it, in Rust:
 > >
 > > 1.  In the trivial case where exactly one of TOSWidget, Pack, and
 > >  Place implements 'config', you get that implementation, and
 > >  any code that's not happy with that is incorrect.
 > 
 > Yes, but also not quite. Rust has a bit of implicitness here for 
 > ergonomics. If there's no conflict, it can easily figure out what you 
 > want/meant.

If there's no conflict, strait figures out what you want, too.

 > Also, it's not that Pack or Place implements 'config' - they
 > *define* a 'config' interface. TOSWidget implements Pack.config
 > and/or Place.config.

It can, but it doesn't necessarily do so.  The traits can supply
default implementations.  For reasons I don't understand (but presume
are valid), Rust emphasizes traits' role in providing interfaces over
code-sharing.

 > 
 > > 2.  In the case TOSWidget implements 'config', and Pack or Place or
 > >  both implements it, you get TOSWidget's implementation, but
 > >  anything expecting Pack or Place behavior will not get it, and is
 > >  incorrect.
 > 
 > No, anything expecting Pack behaviour will get Pack behaviour, anything 
 > expecting Place behaviour gets Place behaviour, and anything dealing 
 > with TOSWidget directly gets TOSWidget behaviour. They're effectively 
 > namespaced.

"Expect" here means what the author of the code that invokes a method
on a TOSWidget object expects.  Of course you can use UFCS to
disambiguate, but that's not what most of us mean by "expecting",
that's explicitly invoking the behavior.  In Python, "expecting" means
"duck typing (ie, a method invocation) does the right thing", but UFCS
is effectively a cast, and uses normal function call syntax.  In
English, your use of that word is perfectly correct, but I guarantee
using it that way in this context will totally confuse most
Pythonistas.

 > > 3.  If both Pack and Place implement 'config', but TOSWidget does not,
 > >  you get a compile-time error.
 > 
 > No, unless you try to interact with 'config' on a TOSWidget.

Of course.  That's what most Python programmers expect.  "Duck typing