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/

[Python-ideas] Allow to compile debug extension against release Python in Windows

[Ivan Pozdeev via Python-ideas]

The Windows version of pyconfig.h has the following construct:

    if defined(_DEBUG)
   pragma comment(lib,"python37_d.lib")
    elif defined(Py_LIMITED_API)
   pragma comment(lib,"python3.lib")
    else
   pragma comment(lib,"python37.lib")
    endif /* _DEBUG */

which fails the compilation of a debug version of an extension. Making 
debugging it... difficult.


Perhaps we could define some other constant?

I'm not sure whether such compilation is a good idea in general, so 
asking here at first.


--
Regards,
Ivan

___
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] Make MappingView inherit from Collection instead of Sized

[Guido van Rossum]

This sounds like a good observation. I recommend opening a bug and
preparing a PR if you can (a PR would also help finding if there are any
problems with the idea).

On Dec 29, 2017 9:50 AM, "Yahya Abou 'Imran via Python-ideas" <
python-ideas@python.org> wrote:

> After I generate an UML diagram from collections.abc, I found very strange
> that MappingView inherit from Sized instead of Collection (new in python
> 3.6).
>
> Yes, MappingView only define __len__ and not __iter__ and __contains__,
> but all of its subclasses define them (KeysView, ValuesView and ItemViews).
>
> I tried to run the tests in test/test_collections.py after making this
> change and on only one fail :
>
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/test/test_collections.py", line 789, in
> test_Collection
> self.assertNotIsInstance(x, Collection)
> AssertionError: dict_values([]) is an instance of  'collections.abc.Collection'>
>
> Wich is absolutely wrong, since in reality a dict_values instance has the
> behaviour of a Collection:
>
> >>> vals = {1:'a', 2: 'b'}.values()
> >>> 'a' in vals
> True
> >>> 'c' in vals
> False
> >>> len(vals)
> 2
> >>> for val in vals:
> ... print(val)
> ...
> a
> b
>
> The only lack is that it doesn't define a __contains__ method:
>
> >>> '__contains__' in vals
> False
>
> It uses __iter__ to find the presence of the value.
>
> But, hey: we have register() for this cases! In fact, when MappingView
> inherit from Collection, dict_values is considered as a subclass of
> Collection since it's in the register of ValuesView, causing the above
> bug...
> So, the test have to be changed, and dict_values must be placed in the
> samples that pass the test, and not in the ones that fail it.
>
> Maybe we can open an issue on the python bug tracker?
>
> ___
> 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 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/

[Python-ideas] Make MappingView inherit from Collection instead of Sized

[Yahya Abou 'Imran via Python-ideas]

After I generate an UML diagram from collections.abc, I found very strange that 
MappingView inherit from Sized instead of Collection (new in python 3.6).

Yes, MappingView only define __len__ and not __iter__ and __contains__, but all 
of its subclasses define them (KeysView, ValuesView and ItemViews).

I tried to run the tests in test/test_collections.py after making this change 
and on only one fail :

Traceback (most recent call last):
  File "/usr/lib/python3.6/test/test_collections.py", line 789, in 
test_Collection
self.assertNotIsInstance(x, Collection)
AssertionError: dict_values([]) is an instance of 

Wich is absolutely wrong, since in reality a dict_values instance has the 
behaviour of a Collection:

>>> vals = {1:'a', 2: 'b'}.values()
>>> 'a' in vals
True
>>> 'c' in vals
False
>>> len(vals)
2
>>> for val in vals:
... print(val)
...
a
b

The only lack is that it doesn't define a __contains__ method:

>>> '__contains__' in vals
False

It uses __iter__ to find the presence of the value.

But, hey: we have register() for this cases! In fact, when MappingView inherit 
from Collection, dict_values is considered as a subclass of Collection since 
it's in the register of ValuesView, causing the above bug...
So, the test have to be changed, and dict_values must be placed in the samples 
that pass the test, and not in the ones that fail it.

Maybe we can open an issue on the python bug tracker?___
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] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Serhiy Storchaka]

29.12.17 16:43, Nick Coghlan пише:

On 29 December 2017 at 22:58, Erik Bray  wrote:

Okay, and it's broken.


Broken in what way? It has a fairly extensive test suite in
https://github.com/python/cpython/blob/master/Lib/test/test_index.py
(and some additional indirect testing in test_slice.py, which assumes
that it works as advertised).


Unfortunately the pure Python implementation doesn't work correctly in 
corner cases (https://bugs.python.org/issue18712). But in CPython the C 
implementation is used. Maybe Erik means something other.



The unsigned long and unsigned long long conversions should likely be
consistent with their signed counterparts and allow lossy conversions
via `__int__`.


There is a code that relies on the atomicity of these functions. Calling 
__int__ or __index__ will introduce vulnerabilities in the existing code.


___
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] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Richard Damon]

On 12/29/17 9:56 AM, Antoine Pitrou wrote:

(*) I got curious and went through the maze of type definitions on
GNU/Linux.  Which gives:

#define __S32_TYPEDEF __signed__ int
#define __PID_T_TYPE__S32_TYPE
__STD_TYPE __PID_T_TYPE __pid_t;
typedef __pid_t pid_t;


Regards

Antoine.


One quick side note, just because it mapped to signed int on that Linux, 
doesn't mean it will always map to signed int on all Linuxes. One of the 
reasons for the multiple levels of indirection in types is to allow a 
given distribution to configure some parameter types to be 'optimal' for 
that implementation.


--
Richard Damon

___
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] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Antoine Pitrou]

On Sat, 30 Dec 2017 00:43:07 +1000
Nick Coghlan  wrote:
> 
> >  That doesn't change my other point that some
> > functions that could previously take non-int arguments can no
> > longer--if we agree on that at least then I can set about making a bug
> > report and fixing it.  
> 
> The size_t, ssize_t and void pointer conversions should only accept
> true integers (so either no fallback, or fall back to `__index__`).
> 
> The unsigned long and unsigned long long conversions should likely be
> consistent with their signed counterparts and allow lossy conversions
> via `__int__`.

That is the statu quo indeed... but the destination C type shouldn't
be used as a criterion of which __dunder__ method is called.

For example, let's assume I'm writing a piece of code that expects a
pid number.  The C type is `pid_t`, which presumably translates either
to a C `int` or `long` (*).  But it's not right to accept a float
there...

I think we really need a bunch a `PyIndex_AsXXX` functions
(`PyIndex_AsLong`, etc.) to complement the current `PyLong_AsXXX`
functions.  That way, every `PyLong_AsXXX` function can continue
calling `__int__` (if they ever did so), while `PyIndex_AsXXX` would
only call `__index__`.


(*) I got curious and went through the maze of type definitions on
GNU/Linux.  Which gives:

#define __S32_TYPEDEF __signed__ int
#define __PID_T_TYPE__S32_TYPE
__STD_TYPE __PID_T_TYPE __pid_t;
typedef __pid_t pid_t;


Regards

Antoine.


___
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] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Nick Coghlan]

On 29 December 2017 at 22:58, Erik Bray  wrote:
> On Thu, Dec 28, 2017 at 8:42 PM, Serhiy Storchaka  wrote:
>> 28.12.17 12:10, Erik Bray пише:
>>>
>>> There's no index() alternative to int().
>>
>>
>> operator.index()
>
> Okay, and it's broken.

Broken in what way? It has a fairly extensive test suite in
https://github.com/python/cpython/blob/master/Lib/test/test_index.py
(and some additional indirect testing in test_slice.py, which assumes
that it works as advertised).

>  That doesn't change my other point that some
> functions that could previously take non-int arguments can no
> longer--if we agree on that at least then I can set about making a bug
> report and fixing it.

The size_t, ssize_t and void pointer conversions should only accept
true integers (so either no fallback, or fall back to `__index__`).

The unsigned long and unsigned long long conversions should likely be
consistent with their signed counterparts and allow lossy conversions
via `__int__`.

I'm less sure about the conversion to double, but allowing that to be
used on float objects without reporting a type error seems like a bug
magnet to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Erik Bray]

On Thu, Dec 28, 2017 at 8:42 PM, Serhiy Storchaka  wrote:
> 28.12.17 12:10, Erik Bray пише:
>>
>> There's no index() alternative to int().
>
>
> operator.index()

Okay, and it's broken.  That doesn't change my other point that some
functions that could previously take non-int arguments can no
longer--if we agree on that at least then I can set about making a bug
report and fixing it.
___
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] Internal function idea

[Stephen J. Turnbull]

On Sat, Dec 23, 2017, 09:23 William Rose,  wrote:

 > I had an idea that it could be helpful to have local functions as
 > well as normal ones. They would be called the same way as normal
 > ones but def would be replaced by internal and inside they could
 > only access variables they have defined and inputs to them so no
 > global variables or class variables. I think this could be used
 > to save people accidentally changing variables you dont' want to
 > change when updating your code. Let me know what you think!

I suspect you misunderstand how variables (actually, name bindings)
work in Python.  If you do understand, I don't understand what you're
guarding against.  With current semantics, code inside a function
cannot change a global binding, although it can refer to one:

>>> def f():
...  x=3
...  return x
... 
>>> def g():
...  return x
... 
>>> x = 0
>>> y = f()# Changes x?
>>> z = g()
>>> print("x =", x, "y =", y, "z =", z)
x = 0 y = 3 z = 0  # Nope.
>>> def h():
...  y = x + 5
...  x = y # Changes x?
...  return x
... 
>>> w = h()# Nope, it crashes your program instead!
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in h
UnboundLocalError: local variable 'x' referenced before assignment

You *can* use the global and nonlocal declarations to override the
normal automatic assumption that names are local to the scope in
which they are bound:

>>> def a():
...  global x
...  x = 42
...  return x
... 
>>> a()
42
>>> x
42

Prohibiting this last would be un-Pythonic, IMO (violates the
"consenting adults" principle).  Similarly for class variables, which
can only be accessed using attribute notation.  There are also
conventions, prefixing "_" or "__", which indicate "this is private,
mess with it at your own risk", and actually munge the name internally
to make it impossible to access accidentally (including in derived
classes).


___
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] Internal function idea

[Chris Angelico]

On Fri, Dec 29, 2017 at 5:03 PM, Franklin? Lee
 wrote:
> On Fri, Dec 29, 2017 at 1:01 AM, Chris Angelico  wrote:
>> On Fri, Dec 29, 2017 at 1:31 PM, Franklin? Lee
>>  wrote:
>>> On Thu, Dec 28, 2017 at 5:21 AM, William Rose  
>>> wrote:
 I agree with the point that it should allow builtin but the main purpose of
 it is to not allow global variables
>>>
>>> But functions are also accessed using global names. What is your
>>> answer to the potential problem of programmers being reluctant to
>>> factor out code into new functions?
>>
>> Code review, training, mentorship. If you try to make the language too
>> restrictive, all you end up doing is forcing people to creatively get
>> around its limitations. Make the language expressive, and then teach
>> people how to use it well.
>>
>> Can you show some examples of code that would be improved by this
>> "internal function" concept?
>
> Hey, I'm the one saying that internal functions will promote bad habits.

My apologies for the lack of clarity; this "you" was addressing the OP
primarily.

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/