[Python-Dev] Re: Help with the grail browser

[Martin Panter]

On 30/05/2021, Prakhar Sehgal  wrote:
> The latest version of Grail is 0.6 which was released in 1999 was made for
> Python 1 but I want to make one compatible with Python 3. But I need help
> for that. Currently me and Guido van Rossum are working on this. Any help
> will be welcomed. This is the link for the GitHub repo:
> https://github.com/PrakharPythonProgrammer/Grail-0.6

Quite a while ago I got Grail working with Python 3. That was in the
era of 3.3; there might be more deprecated modules since (I'm thinking
the "formatter" module at least). I'm pretty sure I put all the
important changes on the "py3" branch on my Git Hub repository, at
. It may be useful
to you.

-Martin.
___
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/RQTC4E3Q3I6PHXCQOX23AV6K2FTQ47EG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barney Gale]

+1 on 'complete'.

If 'enum.unique()' means 'every value has at most one name', then perhaps
`enum.complete()` can mean 'every value has at least one name'? Or is that
not accurate?

Other suggestions: 'occupied', 'full', 'exhaustive'.

Barney

On Mon, 31 May 2021 at 00:02, Jeff Allen  wrote:

> On 28/05/2021 04:24, Ethan Furman wrote:
>
>
> The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE
> are aliases for certain flag combinations.  But what if we have something
> like:
>
> class Color(Flag):
> RED = 1# 0001
> BLUE = 4   # 0100
> WHITE = 7  # 0111
>
> ...
>
> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator to verify that a Flag has no
> missing aliased values that can be used when the programmer thinks it's
> appropriate... but I have no idea what to call it.
>
> Any nominations?
>
> The propery you are looking for IIUC is that if a bit position is 1 in any
> member, then there is a member with only that bit set. I am seeing these
> members as sets of elements (bit positions) and therefore you want
> optionally to ensure that your enumeration has a name for every singleton
> set, into which any member could be analysed.
>
> Words like "basis", "complete", "analytic", or "indicator" (as in
> indicator function) come to mind. I find "singletonian" attractive, but
> no-one will know what it means, and I just made it up.
>
> Jeff
> ___
> 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/7VN5Z5FSN3CH33KKQELX63L7JW6WEB2L/
> 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/O5LBIFIBVAYDKBDKBXE5HDY4TA6SAUFO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jeff Allen]

On 28/05/2021 04:24, Ethan Furman wrote:


The flags RED, GREEN, and BLUE are all canonical, while PURPLE and 
WHITE are aliases for certain flag combinations.  But what if we have 
something like:


    class Color(Flag):
    RED = 1    # 0001
    BLUE = 4   # 0100
    WHITE = 7  # 0111

...

So, like the enum.unique decorator that can be used when duplicate 
names should be an error, I'm adding a new decorator to verify that a 
Flag has no missing aliased values that can be used when the 
programmer thinks it's appropriate... but I have no idea what to call it.


Any nominations?

The propery you are looking for IIUC is that if a bit position is 1 in 
any member, then there is a member with only that bit set. I am seeing 
these members as sets of elements (bit positions) and therefore you want 
optionally to ensure that your enumeration has a name for every 
singleton set, into which any member could be analysed.


Words like "basis", "complete", "analytic", or "indicator" (as in 
indicator function) come to mind. I find "singletonian" attractive, but 
no-one will know what it means, and I just made it up.


Jeff

___
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/7VN5Z5FSN3CH33KKQELX63L7JW6WEB2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Implementing async enumerate

[Thomas Grainger]

https://aiostream.readthedocs.io/en/stable/operators.html#aiostream.stream.enumerate

Is a nice version of an async enumerate. It also handles aclosing
___
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/OOVBZZA4X2JF57K3GH3II46BYJSUWTCU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Origins of iterators and iterables

[Guido van Rossum]

On Sun, May 30, 2021 at 9:10 AM Julien Palard  wrote:

>
>  > is the fact some things (like generators) give iterators instead of
>  > iterables as a hint they're not "rewindable" was initially thought
>  > of and part of the design, or it emerged later.
>

Hm... I don't think that was a big part of the original design. The true
difference between iterable and iterator is that the iterator stores the
state needed to iterate over a given iterable with a for-loop. So if you
have an array, and you have two loops over them (e.g. nested, like this:

for x in a:
for y in a:
print(x, y, x+y)

) then you need separate iterator objects so that advancing the inner
iterator doesn't affect the outer iterator. This is why you can't store the
iteration state in the iterable (the array) but must use a separate object.

Iterators themselves cannot rewind -- at least, there's no standard API for
it, and although nothing stops you from adding such an API to a *specific*
iterator type, it's not a common pattern.

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.

IIRC iterables returning "self" as the iterator in other cases first came
up for files, where we had long been struggling to find the best API to get
all the lines of the file while still benefiting from buffering (calling
f.readline() in a loop was too slow).

The first version of this API was f.readlines(), which returned a list of
strings. But we realized this could potentially use up too much memory, so
we added an optional "hint" argument so you could say f.readlines(10)
and get a number of lines approximately corresponding to 10 bytes. This
required people to write fairly tedious double loops to loop over all lines
efficiently, e.g.

while 1:
lines = f.readlines(10)
if not lines:
break
for line in lines:


Maybe there was an intermediate step (I vaguely recall a special dunder?),
but eventually we realized that the best way to write this was just

for line in f:


(the iterator can buffer internally) and we accepted that you can only
iterate once over a file -- we just told people "if you double-iterate over
a file it doesn't work right".

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/MZIQYMPEBEHUGY6HPHNWK3OTDFPQJ73G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Le 5/30/21 à 4:31 PM, Guido van Rossum a écrit :
> What are you trying to get from the archives? It is *possible* that I
> have a personal archive saved somewhere.

I'm not even sure I remember my initial question... But it could be:

 > is the fact some things (like generators) give iterators instead of
 > iterables as a hint they're not "rewindable" was initially thought
 > of and part of the design, or it emerged later.

Then I went yak shaving...
--
[Julien Palard](https://mdk.fr)

___
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/IMQ4ZIURLUBTXOLKNYVQJAMDSJR2XYTE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Help with the grail browser

[Prakhar Sehgal]

The latest version of Grail is 0.6 which was released in 1999 was made for
Python 1 but I want to make one compatible with Python 3. But I need help
for that. Currently me and Guido van Rossum are working on this. Any help
will be welcomed. This is the link for the GitHub repo:
https://github.com/PrakharPythonProgrammer/Grail-0.6

Sincerely
Prakhar
___
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/RSDQ7GAQZOIDGDESENSMMTD7J6RTIVWS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Guido van Rossum]

What are you trying to get from the archives? It is *possible* that I have
a personal archive saved somewhere.

On Sun, May 30, 2021 at 02:39 Julien Palard  wrote:

> Le 5/29/21 à 11:14 PM, Guido van Rossum a écrit :
> > It looks like what's left of the archives is largely spam?
>
> Yes.
>
> SourceForge staff has manually hidden most spam on this list a few days
> ago to help see better, but the interesting discussion is no longer here.
>
> They checked in the mbox file on disk and found no more messages, and
> they don't have a backup.
>
> Web archive did not captured the mails on sourceforge neither, but
> sourceforge support found a now disapeared archive of the list were
> captured by web archive [1], but it contains only subject names, not
> actual messages.
>
> [1]:
> https://web.archive.org/web/*/http://www.geocrawler.com/archives/3/9283/*
> --
> [Julien Palard](https://mdk.fr)
>
> --
--Guido (mobile)
___
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/OILF3B3PDEGAO45MJNF3WNLK2UJGLDRK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Le 5/29/21 à 11:14 PM, Guido van Rossum a écrit :
> It looks like what's left of the archives is largely spam?

Yes.

SourceForge staff has manually hidden most spam on this list a few days
ago to help see better, but the interesting discussion is no longer here.

They checked in the mbox file on disk and found no more messages, and
they don't have a backup.

Web archive did not captured the mails on sourceforge neither, but
sourceforge support found a now disapeared archive of the list were
captured by web archive [1], but it contains only subject names, not
actual messages.

[1]:
https://web.archive.org/web/*/http://www.geocrawler.com/archives/3/9283/*
--
[Julien Palard](https://mdk.fr)

___
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/UBLRBZ44TMJMFLGYPXFPQEWMTJIKFJTQ/
Code of Conduct: http://python.org/psf/codeofconduct/