Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Guido van Rossum]

On Wed, Jan 3, 2018 at 8:24 AM, Random832  wrote:

> On Sun, Dec 31, 2017, at 00:33, Guido van Rossum wrote:
> > I'm not keen on this recommendation. An argument that takes a Set[Foo]
> > would mean that in order to specify:
> > - no flags: you'd have to pass set() -- you can't use {} since that's an
> > empty dict, not an empty set
>
> Optional[Set[Foo]]?
>
> > - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> > - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR |
> > Foo.BAZ
>
> Maybe the flags themselves should be of a type that you can do both with
> (i.e. each value is a set containing itself).
>

That's pretty much what the enum.Flag type does.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Random832]

On Sun, Dec 31, 2017, at 00:33, Guido van Rossum wrote:
> I'm not keen on this recommendation. An argument that takes a Set[Foo]
> would mean that in order to specify:
> - no flags: you'd have to pass set() -- you can't use {} since that's an
> empty dict, not an empty set

Optional[Set[Foo]]?

> - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR |
> Foo.BAZ

Maybe the flags themselves should be of a type that you can do both with (i.e. 
each value is a set containing itself).
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Guido van Rossum]

The enum.Flag type solves all this neatly.

On Mon, Jan 1, 2018 at 2:43 PM, Barry Scott  wrote:

> I'm guessing that what this thread is about is coming up with an API rule
> that makes
> providing a set of boolean options available to a function or class in the
> least error prone way.
>
> Its the error prone nature of integer bit masks that is behind the enum
> suggestion I assume.
>
> From the C tradition we have the integer bit mask which is error prone as
> there is no type checking that the masks belong to the option flags.
>
> Some APIs use calls with lots of keyword args that you set true or false
> and even none to mean default.
>
> The suggestion for a set of enums from this thread. You would need a class
> to represent a set of a particular enum to get type safety.
>
> List of strings or enums.
>
> You could even use a class that represents the options and set up an
> instance and pass it in. Hard to get wrong.
>
> I can see that all these styles have their place and each designer will
> pick the style they think fits the API they
> are designing.
>
> Barry
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Barry Scott]

I'm guessing that what this thread is about is coming up with an API rule that 
makes
providing a set of boolean options available to a function or class in the 
least error prone way.

Its the error prone nature of integer bit masks that is behind the enum 
suggestion I assume.

>From the C tradition we have the integer bit mask which is error prone as 
>there is no type checking that the masks belong to the option flags.

Some APIs use calls with lots of keyword args that you set true or false and 
even none to mean default.

The suggestion for a set of enums from this thread. You would need a class to 
represent a set of a particular enum to get type safety.

List of strings or enums.

You could even use a class that represents the options and set up an instance 
and pass it in. Hard to get wrong.

I can see that all these styles have their place and each designer will pick 
the style they think fits the API they
are designing.

Barry

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Franklin? Lee]

On Sun, Dec 31, 2017 at 12:09 PM, MRAB  wrote:
> On 2017-12-31 08:13, Paddy3118 wrote:
>>
>> Hmm, yea I had not thought of how it would look - I had thought formost of
>> not needing to necessarily learn about bitsets.when learning about passing a
>> large number of optional flags to a function.
>>
>> Although the default could be None, interpreted as an empty set of zero
>> values.; a set of one or more enums does use more characters compared to
>> or-ing flags...
>>
> None is often used to represent a default, which might not be an empty set.

I see no reason not to allow an iterable collection of flags. That
will at least allow [] and ().
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[MRAB]

On 2017-12-31 08:13, Paddy3118 wrote:
Hmm, yea I had not thought of how it would look - I had thought formost 
of not needing to necessarily learn about bitsets.when learning about 
passing a large number of optional flags to a function.


Although the default could be None, interpreted as an empty set of zero 
values.; a set of one or more enums does use more characters compared to 
or-ing flags...



None is often used to represent a default, which might not be an empty set.


On Sunday, 31 December 2017 05:34:23 UTC, Guido van Rossum wrote:

On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee
 wrote:

Paddy might want something like this:
- For existing APIs which take int or IntFlag flags, allow them to
also take a set (or perhaps any collection) of flags.
- In new APIs, take sets of Enum flags, and don't make them IntFlag.
- Documentation should show preference toward using sets of Enum
flags. Tutorials should pass sets.


I'm not keen on this recommendation. An argument that takes a
Set[Foo] would mean that in order to specify:
- no flags: you'd have to pass set() -- you can't use {} since
that's an empty dict, not an empty set
- one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
- two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than
Foo.BAR | Foo.BAZ

I think for each of these the proposal would be strictly worse than
the current convention.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hmm, yea I had not thought of how it would look - I had thought formost of 
not needing to necessarily learn about bitsets.when learning about passing 
a large number of optional flags to a function.

Although the default could be None, interpreted as an empty set of zero 
values.; a set of one or more enums does use more characters compared to 
or-ing flags...

On Sunday, 31 December 2017 05:34:23 UTC, Guido van Rossum wrote:
>
> On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee  > wrote:
>>
>> Paddy might want something like this:
>> - For existing APIs which take int or IntFlag flags, allow them to
>> also take a set (or perhaps any collection) of flags.
>> - In new APIs, take sets of Enum flags, and don't make them IntFlag.
>> - Documentation should show preference toward using sets of Enum
>> flags. Tutorials should pass sets.
>
>
> I'm not keen on this recommendation. An argument that takes a Set[Foo] 
> would mean that in order to specify:
> - no flags: you'd have to pass set() -- you can't use {} since that's an 
> empty dict, not an empty set
> - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR | 
> Foo.BAZ
>
> I think for each of these the proposal would be strictly worse than the 
> current convention.
>
> -- 
> --Guido van Rossum (python.org/~guido)
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Guido van Rossum]

I should probably clarify that for this to work, Foo must derive from
enum.Flags. See https://docs.python.org/3/library/enum.html#flag.
(Or enum.IntFlag, https://docs.python.org/3/library/enum.html#intflag.)

Note that when using Flag, you can name the "zero" value (Color.BLACK in
the 3rd example). When using IntFlag, you just use 0.

On Sat, Dec 30, 2017 at 9:33 PM, Guido van Rossum  wrote:

> On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee <
> leewangzhong+pyt...@gmail.com> wrote:
>>
>> Paddy might want something like this:
>> - For existing APIs which take int or IntFlag flags, allow them to
>> also take a set (or perhaps any collection) of flags.
>> - In new APIs, take sets of Enum flags, and don't make them IntFlag.
>> - Documentation should show preference toward using sets of Enum
>> flags. Tutorials should pass sets.
>
>
> I'm not keen on this recommendation. An argument that takes a Set[Foo]
> would mean that in order to specify:
> - no flags: you'd have to pass set() -- you can't use {} since that's an
> empty dict, not an empty set
> - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR |
> Foo.BAZ
>
> I think for each of these the proposal would be strictly worse than the
> current convention.
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Guido van Rossum]

On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee <
leewangzhong+pyt...@gmail.com> wrote:
>
> Paddy might want something like this:
> - For existing APIs which take int or IntFlag flags, allow them to
> also take a set (or perhaps any collection) of flags.
> - In new APIs, take sets of Enum flags, and don't make them IntFlag.
> - Documentation should show preference toward using sets of Enum
> flags. Tutorials should pass sets.


I'm not keen on this recommendation. An argument that takes a Set[Foo]
would mean that in order to specify:
- no flags: you'd have to pass set() -- you can't use {} since that's an
empty dict, not an empty set
- one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
- two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR |
Foo.BAZ

I think for each of these the proposal would be strictly worse than the
current convention.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Franklin? Lee]

On Fri, Dec 29, 2017 at 11:25 PM, Steven D'Aprano  wrote:
> On Sat, Dec 30, 2017 at 02:56:46AM +1100, Chris Angelico wrote:
>> On Sat, Dec 30, 2017 at 2:38 AM, Steven D'Aprano  wrote:
>> > The lack of support for the `in` operator is a major difference, but
>> > there's also `len` (equivalent to "count the one bits"), superset
>> > and subset testing, various in-place mutator methods, etc. Java has a
>> > BitSet class, and you can see the typical sorts of operations
>> > commonly required:
>> >
>> > https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html
>>
>> Okay. A subclass of int could easily add a few more. Counting the 1
>> bits isn't difficult; superset and subset testing are actually the
>> same as 'contains' but with more than one bit at a time. (In fact,
>> checking if a set contains a subset is *easier* with ints than with
>> actual sets!) Are in-place mutators that big a deal? I'm sure there
>> are sets in languages with no mutables.
>
> We seem to be talking at cross-purposes.
>
> Obviously we can and do already use ints as if they were set-like data
> structures. For example, the re module already does so. If you want to
> call that a kind of "bit set", I'm okay with that, but Wikipedia
> suggests that "bit array" is the canonical name:
>
> "bit array (also known as bit map , bit set, bit string, or
> bit vector)"
>
> https://en.wikipedia.org/wiki/Bit_array
>
> The obvious reason why is that sets are unordered but arrays of bits are
> not: 0b1000 is not the same "set" as 0b0010.

I think "bit-set" was used because it has semantic meaning in this context.

In your example, it is not the bits that are ordered, but the values,
which have a canonical order (or, more generally, a specified order).
0b1000 represents the set {3}, while 0b0010 represents the set {1}. A
bit set representation is, in fact, unordered, since {1,3} and {3,1}
are both represented by the same int. The values of a bit array are
the bits themselves, but the values of a bitset are the indices which
have a 1.

> I think I have beaten this dead horse enough. This was a minor point
> about the terminology being used, so I think we're now just waiting on
> Paddy to clarify what his proposal means in concrete terms.

Paddy might want something like this:
- For existing APIs which take int or IntFlag flags, allow them to
also take a set (or perhaps any collection) of flags.
- In new APIs, take sets of Enum flags, and don't make them IntFlag.
- Documentation should show preference toward using sets of Enum
flags. Tutorials should pass sets.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Steven D'Aprano]

On Sat, Dec 30, 2017 at 02:56:46AM +1100, Chris Angelico wrote:
> On Sat, Dec 30, 2017 at 2:38 AM, Steven D'Aprano  wrote:
> > The lack of support for the `in` operator is a major difference, but
> > there's also `len` (equivalent to "count the one bits"), superset
> > and subset testing, various in-place mutator methods, etc. Java has a
> > BitSet class, and you can see the typical sorts of operations
> > commonly required:
> >
> > https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html
> 
> Okay. A subclass of int could easily add a few more. Counting the 1
> bits isn't difficult; superset and subset testing are actually the
> same as 'contains' but with more than one bit at a time. (In fact,
> checking if a set contains a subset is *easier* with ints than with
> actual sets!) Are in-place mutators that big a deal? I'm sure there
> are sets in languages with no mutables.

We seem to be talking at cross-purposes.

Obviously we can and do already use ints as if they were set-like data 
structures. For example, the re module already does so. If you want to 
call that a kind of "bit set", I'm okay with that, but Wikipedia 
suggests that "bit array" is the canonical name:

"bit array (also known as bit map , bit set, bit string, or
bit vector)"

https://en.wikipedia.org/wiki/Bit_array

The obvious reason why is that sets are unordered but arrays of bits are 
not: 0b1000 is not the same "set" as 0b0010.

However, the point I was making was that ints don't provide the same 
interface as sets. I don't deny that you can use an int to provide 
set-like functionality, or that with sufficient effort you could 
subclass int to do so, but what you cannot do is seemlessly interchange 
an int for a set and visa versa and expect the code to work without 
modification. Even if the function is limited to using the set-like 
functionality.

I think I have beaten this dead horse enough. This was a minor point 
about the terminology being used, so I think we're now just waiting on 
Paddy to clarify what his proposal means in concrete terms.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Chris Angelico]

On Sat, Dec 30, 2017 at 3:56 AM, Stephan Hoyer  wrote:
> We already have a built-in immutable set for Python. It's called frozenset.

This is true, but AIUI its API is based primarily on that of the
(mutable) set. If you were creating a greenfield ImmutableSet class,
what would its API look like?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Stephan Hoyer]

We already have a built-in immutable set for Python. It's called frozenset.
On Fri, Dec 29, 2017 at 10:56 AM Chris Angelico  wrote:

> On Sat, Dec 30, 2017 at 2:38 AM, Steven D'Aprano 
> wrote:
> > The lack of support for the `in` operator is a major difference, but
> > there's also `len` (equivalent to "count the one bits"), superset
> > and subset testing, various in-place mutator methods, etc. Java has a
> > BitSet class, and you can see the typical sorts of operations
> > commonly required:
> >
> > https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html
>
> Okay. A subclass of int could easily add a few more. Counting the 1
> bits isn't difficult; superset and subset testing are actually the
> same as 'contains' but with more than one bit at a time. (In fact,
> checking if a set contains a subset is *easier* with ints than with
> actual sets!) Are in-place mutators that big a deal? I'm sure there
> are sets in languages with no mutables.
>
> > Of course we can emulate set-like operations using ints, but the
> > interfaces are different, which is my point. Here's how to clear all the
> > flags of a set or int:
> >
> > the_flags.clear()
> >
> > the_flags = 0  # clear all the bits in an int
>
> That's a consequence of Python's mutability distinction. I don't think
> it's a fundamental difference. You could just as easily use "the_flags
> = set()" if it weren't for aliasing.
>
> > Setting a flag is *almost* the same between the two:
> >
> > the_flags |= {flag}  # set
> >
> > the_flags |= flag  # int
>
> That's because you can implicitly upcast a bitflag to a bitset.
> Effectively, ints give you a short-hand that sets can't. But if you
> explicitly call BitSet(flag) to create a set containing one flag, it
> would have the same effect.
>
> > although for sets, there are two other ways to set a flag which aren't
> > supported by ints:
> >
> > the_flags.add(flag)
> > the_flags.update({flag})
> >
> > Similarly for clearing flags:
> >
> > the_flags.discard(flag)
> >
> > the_flags & ~flag
>
> Mutability again. If you were to create an ImmutableSet type in
> Python, what would its API look like? My suspicion is that it'd
> largely use operators, and that it'd end up looking a lot like the
> integer API.
>
> An integer, at its lowest level, is represented as a set of bits. It's
> no more crazy to use an int as a set of bits than to use a string as a
> set of characters:
>
> https://docs.python.org/3/library/stdtypes.html#str.strip
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Chris Angelico]

On Sat, Dec 30, 2017 at 2:38 AM, Steven D'Aprano  wrote:
> The lack of support for the `in` operator is a major difference, but
> there's also `len` (equivalent to "count the one bits"), superset
> and subset testing, various in-place mutator methods, etc. Java has a
> BitSet class, and you can see the typical sorts of operations
> commonly required:
>
> https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html

Okay. A subclass of int could easily add a few more. Counting the 1
bits isn't difficult; superset and subset testing are actually the
same as 'contains' but with more than one bit at a time. (In fact,
checking if a set contains a subset is *easier* with ints than with
actual sets!) Are in-place mutators that big a deal? I'm sure there
are sets in languages with no mutables.

> Of course we can emulate set-like operations using ints, but the
> interfaces are different, which is my point. Here's how to clear all the
> flags of a set or int:
>
> the_flags.clear()
>
> the_flags = 0  # clear all the bits in an int

That's a consequence of Python's mutability distinction. I don't think
it's a fundamental difference. You could just as easily use "the_flags
= set()" if it weren't for aliasing.

> Setting a flag is *almost* the same between the two:
>
> the_flags |= {flag}  # set
>
> the_flags |= flag  # int

That's because you can implicitly upcast a bitflag to a bitset.
Effectively, ints give you a short-hand that sets can't. But if you
explicitly call BitSet(flag) to create a set containing one flag, it
would have the same effect.

> although for sets, there are two other ways to set a flag which aren't
> supported by ints:
>
> the_flags.add(flag)
> the_flags.update({flag})
>
> Similarly for clearing flags:
>
> the_flags.discard(flag)
>
> the_flags & ~flag

Mutability again. If you were to create an ImmutableSet type in
Python, what would its API look like? My suspicion is that it'd
largely use operators, and that it'd end up looking a lot like the
integer API.

An integer, at its lowest level, is represented as a set of bits. It's
no more crazy to use an int as a set of bits than to use a string as a
set of characters:

https://docs.python.org/3/library/stdtypes.html#str.strip

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Steven D'Aprano]

On Fri, Dec 29, 2017 at 10:26:22PM +1100, Chris Angelico wrote:
> On Fri, Dec 29, 2017 at 7:18 PM, Steven D'Aprano  wrote:
> > Since ints don't provide a set-like interface, they aren't strictly
> > speaking bitsets. But in any case, nobody is stopping people from using
> > sets of enum values.
> 
> I'm not sure what "set-like interface" you'd be looking for, but the
> built-in set type has a lot of the same operations as an integer does,
> and the semantics are virtually identical to a set of bits. The only
> one you really lack is __contains__, which could easily be added:

The lack of support for the `in` operator is a major difference, but 
there's also `len` (equivalent to "count the one bits"), superset 
and subset testing, various in-place mutator methods, etc. Java has a 
BitSet class, and you can see the typical sorts of operations 
commonly required:

https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html

Of course we can emulate set-like operations using ints, but the 
interfaces are different, which is my point. Here's how to clear all the 
flags of a set or int:

the_flags.clear()

the_flags = 0  # clear all the bits in an int


Setting a flag is *almost* the same between the two:

the_flags |= {flag}  # set

the_flags |= flag  # int


although for sets, there are two other ways to set a flag which aren't 
supported by ints:

the_flags.add(flag)
the_flags.update({flag})

Similarly for clearing flags:

the_flags.discard(flag)

the_flags & ~flag



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Chris Angelico]

On Fri, Dec 29, 2017 at 7:18 PM, Steven D'Aprano  wrote:
> Since ints don't provide a set-like interface, they aren't strictly
> speaking bitsets. But in any case, nobody is stopping people from using
> sets of enum values.

I'm not sure what "set-like interface" you'd be looking for, but the
built-in set type has a lot of the same operations as an integer does,
and the semantics are virtually identical to a set of bits. The only
one you really lack is __contains__, which could easily be added:

class BitSet(int):
def __contains__(self, bit):
return (self & bit) == bit

>>> x = BitSet(1|2|8|32)
>>> 2 in x
True
>>> 4 in x
False

Set union, intersection, etc are all provided using the same operators
in sets and ints.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Steven D'Aprano]

On Thu, Dec 28, 2017 at 12:23:53PM -0800, Paddy3118 wrote:

> Hi Steve, I did not write an attack on the "Python devs". 

I didn't say you attacked anyone and your implication that I did is 
unfair.


> Re-read my 
> original with a little less hostility and there should be room for an 
> interpretation, (which I meant), that does not warrant such a hostile reply.

Please re-read my response without the hair-trigger defensiveness. 
Disagreement is not hostility. Questioning your statements is not 
hostility. None of us are entitled to only positive responses that agree 
with what we suggest, but we are all entitled to the presumption that we 
are arguing in good faith.


See also:

https://mail.python.org/pipermail/python-ideas/2017-December/048448.html

and:

https://mail.python.org/pipermail/python-ideas/2017-December/048449.html

(I don't agree with *everything* Brett says, but its a good starting 
point.)

 
> The original is written in the hope of furthering discussion on the need 
> for what is deemed pythonic , and on what Python is taught , as the 
> language itself changes.

Right -- and I responded to that discussion.

I asked some genuine questions which you haven't responded to. Let me 
rephrase them:

- Are we currently promoting ints as bitsets?

- How is it relevant that "someone" (who?) wrote a description of using 
ints as bitsets and then deleted it?

- Why is a set of Enums the Pythonic way?


> We now have enums if you want to pass a set of flags to a function then you 
> could have them as separate arguments - but that leads to long and 
> cumbersome parameter lists; you could, and many do, have flags that are 
> individual powers of two and then or them together and pass the result - 
> creating a bitset; but we can now have the flags as separate enum.Enums and 
> pass a set of values to a function as the flag set. 

And no one is stopping anyone from writing code that does so.


> This new way means that people being taught the method can use a knowledge 
> of sets and enums - no need to know about powers of two,, what happens when 
> they are bit-or'd together; and bitsets.

Personally, I think that sets and Enums are no easier to learn than bit 
twiddling. But YMMV.


> We have gone to a higher level description of what we are doing; no 
> need to mired in the details of the how of what one wants to achieve.

Whether we use an int or a set of Enums, we still need to understand the 
details of how to set and clear flags, and test for them.


  THE_FLAG = 8
  the_flags = THE_FLAG | ANOTHER_FLAG

  if the_flags & THE_FLAG:
  print("flag is set")


versus:


  class MyFlags(Enum):
  THE_FLAG = "whatever"

  the flags = {THE_FLAG, ANOTHER_FLAG}

  if MyFlags.THE_FLAG in the_flags:
  print("flag is set")


Honestly, I'm not seeing a *lot* of difference here.


[...]
> As for re, and otheralready written libraries, their is no need to change 
> them, 

I see. It wasn't clear to me. It seemed to me that you were suggesting 
changing the re module, since that was just an "implementation" detail.


> but other Pythoneers might well opt to not use bitsets, but rather 
> sets of enum values.

Since ints don't provide a set-like interface, they aren't strictly 
speaking bitsets. But in any case, nobody is stopping people from using 
sets of enum values.

If you have a concrete proposal, then please state it explicitly. I 
thought I understood your proposal:

change the implementation of re to use sets of Enums in order
to promote their use and act as an example of best practice
and Pythonic style

but apparently I misunderstood. Sorry. 

So now I'm left puzzled as to what you actually want. Can you be 
explicit and explain what you expect us to do when you say we should 
"teach" and "promote" (your words) Enums instead of using ints? Please 
be concrete.

- Should we change the standard library, and if so, in what ways?

- Should we change the documentation? Which parts?

- Insert something in PEP 8 about using sets of Enums?

- Re-write the tutorial? Where?

- Something else?

Without a concrete proposal, I don't think this discussion is going 
anywhere.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Inada, can I take your point as being that execution speed is an issue? 

I am coming from the "Python as higher level, more programmer-centric 
language"direction.

In the past, useful but slow things have spurred actions to speed them up. ___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Steve, I did not write an attack on the "Python devs". Re-read my 
original with a little less hostility and there should be room for an 
interpretation, (which I meant), that does not warrant such a hostile reply.

The original is written in the hope of furthering discussion on the need 
for what is deemed pythonic , and on what Python is taught , as the 
language itself changes.
We now have enums if you want to pass a set of flags to a function then you 
could have them as separate arguments - but that leads to long and 
cumbersome parameter lists; you could, and many do, have flags that are 
individual powers of two and then or them together and pass the result - 
creating a bitset; but we can now have the flags as separate enum.Enums and 
pass a set of values to a function as the flag set. 

This new way means that people being taught the method can use a knowledge 
of sets and enums - no need to know about powers of two,, what happens when 
they are bit-or'd together; and bitsets. We have gone to a higher level 
description of what we are doing; no need to mired in the details of the 
how of what one wants to achieve. bitsets can be taught as an optimisation.

As for re, and otheralready written libraries, their is no need to change 
them, but other Pythoneers might well opt to not use bitsets, but rather 
sets of enum values.


On Wednesday, 27 December 2017 05:58:00 UTC, Steven D'Aprano wrote:
>
> On Tue, Dec 26, 2017 at 12:07:52PM -0800, Paddy3118 wrote: 
>
> > Maybe it is time to deemphasize the creation and passing of what is, in 
> > effect, bit-sets as a single 
> > argument, and instead promote the passing of a set of members of an 
> > enum.Enum  constants. 
>
> That implies that we are promoting bit sets (not merely using them). 
> Where are we doing that? 
>
>
> > Thi comes about because someone wrote a description, (since deleted), 
>
> "Someone"? One of the Python core developers? 
>
> If not, well, the Python devs cannot be held responsible for what random 
> people on the internet write. 
>
>
> > of 
> > constructing bit-sets to use in passing flags to, for example, the 
> > re.compile function. 
>
> > The use of individual bits in a bit-array/bit-set to pass multiple flags 
> is 
> > an implementation detail. 
>
> It certainly is not an implementation detail -- it is a part of the 
> public, published interface to the re module. 
>
> Of course had history been different, re.compile *could* have taken a 
> set of Enums instead. But that doesn't make it an implementation detail. 
> That would be like saying that: 
>
>re.search(pattern, text, flags=0) 
>
> is an implementation detail, and we should feel free to change it to 
>
>re.examine(text, pattern, set_of_enums=frozenset()) 
>
> We can't change a public interface documented as taking an integer to 
> one taking a set of Enums without going through a deprecation period. 
>
> However, we could *add* an additional interface, where the re functions 
> that currently accept an integer flag *also* accepts a set of Enums. 
>
>
> > Should we not *first *teach the passing of a set 
> > of enum.Enum constant values in one argument as the *pythonic *way; 
>
> What makes you say that is the Pythonic way? (That's not a rhetorical 
> question.) 
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list 
> python...@python.org  
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Steven D'Aprano]

On Tue, Dec 26, 2017 at 12:07:52PM -0800, Paddy3118 wrote:

> Maybe it is time to deemphasize the creation and passing of what is, in 
> effect, bit-sets as a single 
> argument, and instead promote the passing of a set of members of an 
> enum.Enum  constants.

That implies that we are promoting bit sets (not merely using them). 
Where are we doing that?


> Thi comes about because someone wrote a description, (since deleted), 

"Someone"? One of the Python core developers?

If not, well, the Python devs cannot be held responsible for what random 
people on the internet write.


> of 
> constructing bit-sets to use in passing flags to, for example, the 
> re.compile function. 
> The use of individual bits in a bit-array/bit-set to pass multiple flags is 
> an implementation detail.

It certainly is not an implementation detail -- it is a part of the 
public, published interface to the re module.

Of course had history been different, re.compile *could* have taken a 
set of Enums instead. But that doesn't make it an implementation detail. 
That would be like saying that:

   re.search(pattern, text, flags=0)

is an implementation detail, and we should feel free to change it to

   re.examine(text, pattern, set_of_enums=frozenset())

We can't change a public interface documented as taking an integer to 
one taking a set of Enums without going through a deprecation period.

However, we could *add* an additional interface, where the re functions 
that currently accept an integer flag *also* accepts a set of Enums.


> Should we not *first *teach the passing of a set 
> of enum.Enum constant values in one argument as the *pythonic *way;

What makes you say that is the Pythonic way? (That's not a rhetorical 
question.)


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Neil Girdhar]

Wouldn't it be more pythonic to just pass flags to re.compile as Boolean 
keyword arguments?

On Tuesday, December 26, 2017 at 3:07:52 PM UTC-5, Paddy3118 wrote:
>
> Maybe it is time to deemphasize the creation and passing of what is, in 
> effect, bit-sets as a single 
> argument, and instead promote the passing of a set of members of an 
> enum.Enum  constants.
>
> Thi comes about because someone wrote a description, (since deleted), of 
> constructing bit-sets to use in passing flags to, for example, the 
> re.compile function. 
> The use of individual bits in a bit-array/bit-set to pass multiple flags is 
> an implementation detail. Should we not *first *teach the passing of a 
> set of enum.Enum constant values in one argument as the *pythonic *way; 
> and leave bit-sets and other types of enum's as a performance or 
> interoperability detail?
>
> Comments please, (And a happy new year to you :-)
>
>___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Maybe it is time to deemphasize the creation and passing of what is, in 
effect, bit-sets as a single 
argument, and instead promote the passing of a set of members of an 
enum.Enum  constants.

Thi comes about because someone wrote a description, (since deleted), of 
constructing bit-sets to use in passing flags to, for example, the 
re.compile function. 
The use of individual bits in a bit-array/bit-set to pass multiple flags is 
an implementation detail. Should we not *first *teach the passing of a set 
of enum.Enum constant values in one argument as the *pythonic *way; and 
leave bit-sets and other types of enum's as a performance or 
interoperability detail?

Comments please, (And a happy new year to you :-)

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/