[Python-Dev] Re: Origins of iterators and iterables

2021-05-31 Thread Sebastian Rittau 

Am 30.05.21 um 19:08 schrieb Guido van Rossum:
Returning "self" as the iterator was originally only intended to paper 
over the case where you want to write


it = iter(a)

for x in it:
    ...

-- basically we wanted 'for x in iter(a)' and 'for x in a' to have the 
same meaning.


The above use case (iterator being iterable themselves) was a very good 
design decision. In fact, I have a blog post dating back from 2006 where 
I berated Java from not doing the same: 
https://rittau.org/2006/11/java-iterators-are-not-iterable/. To take my 
example from there converted to python:


class Tree:
    def depth_first() -> Iterator[...]: ...
    def breath_first() -> Iterator[...]: ...

for item in tree.depth_first(): ...

This example would not work if "iter(it)" would not return "self".

 - Sebastian

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

[Python-Dev] Farewell, for now :)

2021-05-31 Thread Kyle Stanley 
Hi all,

Last week, I started a new thread on discuss.python.org
 about my
intention to take a further extended break from open source to continue my
mental health healing process. Just wanted to announce it in the other
channels as well since I know that not everyone has the bandwidth to keep
up with more than just the MLs.

In the thread, I discussed my intention to pursue the path of becoming a
Buddhist monk for some time, and recently detailed my adventures at a local
Thai temple. Check it out if you are interested. :)

With Loving Regards,
-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
)
*Pronouns: they/them **(why is my pronoun here?*

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

[Python-Dev] Re: name for new Enum decorator

2021-05-31 Thread Luciano Ramalho 
On Fri, May 28, 2021 at 7:00 PM Joao S. O. Bueno  wrote:
> "check_all_bits_defined" or something along it.

Best suggestion so far. Similar:

"ensure_all_bits_named"

I am all for brainstorming, as we've been doing for a few days. Maybe
we need to brainstorm some more.

I just don't think the goal should be finding a one/two-word name for
the decorator.

I see no need to find something shorter than a short sentence. After
all, defining a new enum is not something we do all the time.

Cheers,

Luciano


>
> On Fri, 28 May 2021 at 18:30, Ethan Furman  wrote:
>>
>> On 5/28/21 12:43 AM, Petr Viktorin wrote:
>>  > On 28. 05. 21 5:24, Ethan Furman wrote:
>>
>>  >>  class FlagWithMasks(IntFlag):
>>  >>  DEFAULT = 0x0
>>  >>
>>  >>  FIRST_MASK = 0xF
>>  >>  FIRST_ROUND = 0x0
>>  >>  FIRST_CEIL = 0x1
>>  >>  FIRST_TRUNC = 0x2
>>  >>
>>  >>  SECOND_MASK = 0xF0
>>  >>  SECOND_RECALC = 0x00
>>  >>  SECOND_NO_RECALC = 0x10
>>  >>
>>  >>  THIRD_MASK = 0xF00
>>  >>  THIRD_DISCARD = 0x000
>>  >>  THIRD_KEEP = 0x100
>>  >>
>>  >> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are 
>> aliasing values
>>  >> that don't exist, but it seems intentional and not an error.
>>  >
>>  > Are you looking for a decorator for the whole Enum, or a way to mark 
>> individual *values* as masks?
>>
>> The decorator is for whole enum.  The issue is not that some values are 
>> masks, but whether the absence of named bits
>> covered by the mask is an error.
>>
>> --
>> ~Ethan~
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-dev@python.org/message/OM5M774MP5QPLFXZ7OVGBPR7ZFB6X35A/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/WX7YCSRRDJWLVJUMLGBZL34OP7JW4MDQ/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3BBRVAW2AKDUXNJYLCIPK2V7BX4CWMGF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

2021-05-31 Thread Glenn Linderman 

On 5/31/2021 1:37 PM, Luciano Ramalho wrote:

On Fri, May 28, 2021 at 7:00 PM Joao S. O. Bueno  wrote:

"check_all_bits_defined" or something along it.

Best suggestion so far. Similar:

"ensure_all_bits_named"

I am all for brainstorming, as we've been doing for a few days. Maybe
we need to brainstorm some more.

I just don't think the goal should be finding a one/two-word name for
the decorator.

I see no need to find something shorter than a short sentence. After
all, defining a new enum is not something we do all the time.

Cheers,

Luciano


In this vein, I suggest these variations

    @name_all_used_flags
    @require_individual_flag_names

Clearly some flags may not be used, and need not be named, but this 
would require all the used flags to be (individually) named, without 
precluding combinations of same.


And while I am guilty of using the word "bits" in prior suggestions, I 
realized today that the name of the Enum variety under discussion is 
"IntFlag" not "IntBits", so it seems more appropriate to use the word 
"flag" or "flags" rather than "bits", even though the implementation of 
a boolean flag is a single bit.


So I withdraw my prior suggestions of  @all_bits_defined  and 
@unique_bits in favor of  @all_flags_defined and @unique_flags.



Digression/Extensions:

I'm also starting to wonder if Flag & IntFlag should be restricted to 
individual flags and combinations, and if another variety of Enum, that 
is very, very similar, should be called IntBitfields.  On the other 
hand, if there are a few flags and a small bitfield or two, that are 
sufficiently related, having them contained in a single Enum might be 
appropriate, and such has certainly been used on pre-existing APIs with 
plain int values manipulated with logical operators.


Without having any clue as to how hard the implementation might be, or 
how it would conflict with other uses of decorators, and without any 
concern for the exact details of the implementation, if another syntax 
would be easier, I wonder if something along the lines of new syntax 
would be preferable to a decorator, when the possibility exists for both 
flags and bitfields to be defined in the same Enum:


class SomeSpecificInt( IntBitfields ):
   COLORS( 3 ): flags = {
     RED = 1
     GREEN = 2
 BLUE = 4
 PURPLE = RED | BLUE
 },
  OPACITY( 4 ): int,
  DITHER( 4 ): values = {
    CROSSHATCH = auto(),
    SLANTED30DEGREES = auto(),
    SLANTED45DEGREES = auto(),
    SLANTED60DEGREES = auto(),
    DOTS25PERCENT = auto(),
    DOTS50PERCENT = auto(),
    DOTS75PERCENT = auto(),
    },
  }

The idea here would be that "flags" values would be unique bits that are 
in a 3-bit field, OPACITY would be an integer in a 4-bit field, and 
DITHER would be a set of unique values (only 4 defined so far, but 
allowing up to 15 values in a 4-bit field for future expansion).


To require the COLORS to have uniquely named flags, a different keyword 
would be used instead of or in addition to "flags": COLORS( 3 ): 
individual flags   [or  COLORS( 3 ): individual_flags ]


I realize this adds more complexity, and is far beyond the original 
proposal, but it also adds missing power to subdivided int values. The 
values for DITHER would be from 1-15 when extracted or cast, with the 
shifting done by the Enum implementation.


Or maybe instead of the above proposal, the decorator approach could be 
taken for individual IntFlag classes, but a new "CombinedEnum" could be 
defined to join multiple Enum classes into a single "int" with 
bitfields.  In that case, the explicit bitfield sizes given in the above 
syntax would only be used for CombinedEnum, but the member Enum classes 
that are combined would have to meet the constraint of fitting their 
values into that many bits.

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