[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Guido van Rossum]

Can you try this?

async def __sleep(self):
await None

On Thu, Feb 18, 2021 at 22:31 Luciano Ramalho  wrote:

> Follow up question: what's the plan to replace this use of
> `@types.coroutine` in `asyncio/tasks.py`? [1]
>
> @types.coroutine
> def __sleep0():
>  ""
>  yield
>
> [1]
> https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L585
>
> Best,
>
> Luciano
>
> On Fri, Feb 19, 2021 at 2:31 AM Luciano Ramalho 
> wrote:
> >
> > On Fri, Feb 19, 2021 at 1:59 AM Guido van Rossum 
> wrote:
> > >> 1) What Python construct is to be used at the end of a chain of await
> > >> calls, if not of a generator-based coroutine decorated with
> > >> `@types.coroutine` and using a `yield` expression in its body?
> >
> > > At the end of the chain you can call the __await__() method which
> gives an iterator, and then you call next() or send() on that iterator.
> Each next()/send() call then represents an await step, and send() in
> general is used to provide an awaited result. Eventually this will raise
> StopIteration with a value indicating the ultimate result (the return value
> of the top-level async def).
> >
> > All right, that made sense to me. Thank you so much, Guido.
> >
> > Thanks for the clarification about `@types.coroutine` as well.
> >
> > Take care,
> >
> > Luciano
> >
> >
> > --
> > Luciano Ramalho
> > |  Author of Fluent Python (O'Reilly, 2015)
> > | http://shop.oreilly.com/product/0636920032519.do
> > |  Technical Principal at ThoughtWorks
> > |  Twitter: @ramalhoorg
>
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
>
-- 
--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/UAG36OWYCNOYSXQXRBIWML7IHR4IKEAO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Dan Stromberg]

On Thu, Feb 18, 2021 at 9:39 PM David Mertz  wrote:

> As Skip pointed out to me privately, there are some minor limitations with
> this version.  E.g.:
>
> % python
> >>> import glob
> >>> import sys
> >>> print 'hello'
> hello
> >>> print 2+2
> 4
> >>> print 2*2
> Unhandled exception: run-time error: integer overflow
> Stack backtrace (innermost last):
>   File "", line 1
>

Huh.  I wonder what's different about my build:
$ /usr/local/cpython-0.9/bin/python
below cmd output started 2021 Thu Feb 18 10:24:00 PM PST
>>> 2*2
4
>>> print 2*2
4
>>>

You can download a script to build it and a bunch of other python versions
at https://stromberg.dnsalias.org/~strombrg/cpythons/
It includes all the tarballs you should need, at least for Debian. I
believe I used it on CentOS recently as well.  I haven't tried it on Ubuntu
in a while.
It depends on https://stromberg.dnsalias.org/~strombrg/cobble.html - and
I'd like to think that's its only external dependency.

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

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Luciano Ramalho]

Follow up question: what's the plan to replace this use of
`@types.coroutine` in `asyncio/tasks.py`? [1]

@types.coroutine
def __sleep0():
 ""
 yield

[1] https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L585

Best,

Luciano

On Fri, Feb 19, 2021 at 2:31 AM Luciano Ramalho  wrote:
>
> On Fri, Feb 19, 2021 at 1:59 AM Guido van Rossum  wrote:
> >> 1) What Python construct is to be used at the end of a chain of await
> >> calls, if not of a generator-based coroutine decorated with
> >> `@types.coroutine` and using a `yield` expression in its body?
>
> > At the end of the chain you can call the __await__() method which gives an 
> > iterator, and then you call next() or send() on that iterator. Each 
> > next()/send() call then represents an await step, and send() in general is 
> > used to provide an awaited result. Eventually this will raise StopIteration 
> > with a value indicating the ultimate result (the return value of the 
> > top-level async def).
>
> All right, that made sense to me. Thank you so much, Guido.
>
> Thanks for the clarification about `@types.coroutine` as well.
>
> Take care,
>
> Luciano
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg



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

[Python-Dev] Re: Python 0.9.1

[David Mertz]

I've provided this excellent language interpreter as a conda package.  For
users of conda, you can install it (on Linux) with:

conda install -c davidmertz python=0.9

(perhaps put it in a different environment than base).

I'm embarrassed by how much effort that took me. I used to teach
conda-build at Anaconda, but I've forgotten everything about how it works.
There may have been another way to do it, but what this installs uses a
hack.  There might have been some other way to do this, but:

% cat `which python`
#!/bin/bash
PYTHONPATH=$CONDA_PREFIX/lib/ python-0.9.1

The manpage works though. As Skip pointed out to me privately, there are
some minor limitations with this version.  E.g.:

% python
>>> import glob
>>> import sys
>>> print 'hello'
hello
>>> print 2+2
4
>>> print 2*2
Unhandled exception: run-time error: integer overflow
Stack backtrace (innermost last):
  File "", line 1

It's easy enough to work around that though:

>>> def mult(a, b):
... total = 0
... for _ in range(a):
... total = total + b
... return total
...
>>> mult(2, 2)
4


On Tue, Feb 16, 2021 at 10:01 PM Skip Montanaro 
wrote:

> A note to webmas...@python.org from an astute user named Hiromi in Japan* 
> referred
> us to Guido's shell archives for the 0.9.1 release from 1991. As that
> wasn't listed in the historical releases README file:
>
> https://legacy.python.org/download/releases/src/README
>
> I pulled the shar files (and a patch), then made a few tweaks to get it to
> build:
>
> % ./python
> >>> print 'hello world!'
> hello world!
> >>> import sys
> >>> dir(sys)
> ['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin',
> 'stdout']
> >>> sys.modules
> {'builtin': ; 'sys': ; '__main__':  '__main__'>}
> >>> sys.exit(0)
>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>
> There is a new directory named "shar" with the original files, a small
> README file and a compile.patch file between the original code and the
> runnable code.
>
> It was a pleasant diversion for a couple hours. I was tired of shovelling
> snow anyway... Thank you, Hiromi.
>
> Skip
>
> *  Hiromi is bcc'd on this note in case he cares to comment. I didn't want
> to publish his email beyond the bounds of the webmaster alias without his
> permission.
>
> ___
> 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/VZYELIYAQWUHHGIIEPPJFREDX6F24KMN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/6HRFITORPFZBO6V7VQ5AAVDIEVFNWHQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Luciano Ramalho]

On Fri, Feb 19, 2021 at 1:59 AM Guido van Rossum  wrote:
>> 1) What Python construct is to be used at the end of a chain of await
>> calls, if not of a generator-based coroutine decorated with
>> `@types.coroutine` and using a `yield` expression in its body?

> At the end of the chain you can call the __await__() method which gives an 
> iterator, and then you call next() or send() on that iterator. Each 
> next()/send() call then represents an await step, and send() in general is 
> used to provide an awaited result. Eventually this will raise StopIteration 
> with a value indicating the ultimate result (the return value of the 
> top-level async def).

All right, that made sense to me. Thank you so much, Guido.

Thanks for the clarification about `@types.coroutine` as well.

Take care,

Luciano


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

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Guido van Rossum]

On Thu, Feb 18, 2021 at 8:23 PM Luciano Ramalho  wrote:

> Thanks for your reply, Guido.
>
> On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum 
> wrote:
> > Reading the doc section you link to, it's pretty clear that
> `@asyncio.coroutine` will be removed.
>
> The *Note* right at the top of [1] says "Support for generator-based
> coroutines is deprecated and is scheduled for removal in Python 3.10."
>
> [1]
> https://docs.python.org/3/library/asyncio-task.html#generator-based-coroutines
>
> But PEP 492 [2] says:
>
> "Since, internally, coroutines are a special kind of generators, every
> await is suspended by a yield somewhere down the chain of await calls"
>
> [2] https://www.python.org/dev/peps/pep-0492/#await-expression
>
> If that part of PEP 492 is no longer accurate, then I have a couple of
> questions:
>
> 1) What Python construct is to be used at the end of a chain of await
> calls, if not of a generator-based coroutine decorated with
> `@types.coroutine` and using a `yield` expression in its body?
>
> 2) Given that the sole purpose of `@types.coroutine` is to decorate
> generator-based coroutines to become awaitable, will that decorator
> also be removed, along with "support for generator-based coroutines"?
>
> Best,
>
> Luciano
>

It looks like types.coroutine will remain (it does not contain code to warn
about deprecation like asyncio.coroutine does), but I don't think it is
required to end a chain of coroutines -- it may have been an oversight that
we did not start deprecating it. (But in any case it won't be supported by
asyncio.)

At the end of the chain you can call the __await__() method which gives an
iterator, and then you call next() or send() on that iterator. Each
next()/send() call then represents an await step, and send() in general is
used to provide an awaited result. Eventually this will raise StopIteration
with a value indicating the ultimate result (the return value of the
top-level async def).

The code used to "drive" a chain of await calls is called a trampoline. But
writing a trampoline is not easy, and the only example I know of is
asyncio's Task class, in particular its __step() method, which of course is
beyond complicated because it has to handle so many special cases.

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

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Luciano Ramalho]

Thanks for your reply, Guido.

On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum  wrote:
> Reading the doc section you link to, it's pretty clear that 
> `@asyncio.coroutine` will be removed.

The *Note* right at the top of [1] says "Support for generator-based
coroutines is deprecated and is scheduled for removal in Python 3.10."

[1] 
https://docs.python.org/3/library/asyncio-task.html#generator-based-coroutines

But PEP 492 [2] says:

"Since, internally, coroutines are a special kind of generators, every
await is suspended by a yield somewhere down the chain of await calls"

[2] https://www.python.org/dev/peps/pep-0492/#await-expression

If that part of PEP 492 is no longer accurate, then I have a couple of
questions:

1) What Python construct is to be used at the end of a chain of await
calls, if not of a generator-based coroutine decorated with
`@types.coroutine` and using a `yield` expression in its body?

2) Given that the sole purpose of `@types.coroutine` is to decorate
generator-based coroutines to become awaitable, will that decorator
also be removed, along with "support for generator-based coroutines"?

Best,

Luciano

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

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

[Guido van Rossum]

On Thu, Feb 18, 2021 at 3:57 PM Luciano Ramalho  wrote:

> I am not a Python core developer, but my question relates
> to changes that are expected in Python 3.10, so I felt this was the
> best forum to ask. Please let me know if I should discuss this
> elsewhere or file a documentation bug.
>
> First of all, thank you Yuri Selivanov and everybody who contributed
> to the overhaul of the asyncio docs which are now much better
> organized.
>
> In the process of updating "Fluent Python" to cover Python 3.9, I
> learned that the "Generator-based coroutines" section in the asyncio
> docs warns that "Support for generator-based coroutines is deprecated
> and is scheduled for removal in Python 3.10." [1]
>
> [1]
> https://docs.python.org/3/library/asyncio-task.html#generator-based-coroutines
>
> I don't understand that warning, given that PEP 492 lists as one of
> the awaitable types:
>
> * A generator-based coroutine object returned from a function
> decorated with types.coroutine().
>
> Perhaps what is going to be removed is support for old style
> generator-based coroutines decorated with @asyncio.coroutine, or not
> decorated (which historically also worked)?
>
> I'd appreciate some clarification on exactly what is going to be removed.
>

Reading the doc section you link to, it's pretty clear that
`@asyncio.coroutine` will be removed.

The fact that it's mentioned in PEP 492 is irrelevant -- there is no rule
that says we can't evolve Python to invalidate APIs specified in past PEPs,
as long as the deprecation process is followed (which it is in this case).


> Maybe we also need updates to the Glossary [2] to bridge the gap
> between our previous use of the word "coroutine" (as in PEP 342) and
> the way we are using it today, when we are not being explicit about
> "native coroutines". In particular, the Glossary has no entry at all
> for "generator-based coroutine"—those marked with @types.coroutine.
>
> [2] https://docs.python.org/3/glossary.html
>

Why would it require a glossary entry? It's right there in the first link
you give as the section header. And it's an outmoded concept (which was
clear from the moment 'async def' was invented).

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

[Python-Dev] Clarification on the removal of generator-based coroutines in 3.10

[Luciano Ramalho]

I am not a Python core developer, but my question relates
to changes that are expected in Python 3.10, so I felt this was the
best forum to ask. Please let me know if I should discuss this
elsewhere or file a documentation bug.

First of all, thank you Yuri Selivanov and everybody who contributed
to the overhaul of the asyncio docs which are now much better
organized.

In the process of updating "Fluent Python" to cover Python 3.9, I
learned that the "Generator-based coroutines" section in the asyncio
docs warns that "Support for generator-based coroutines is deprecated
and is scheduled for removal in Python 3.10." [1]

[1] 
https://docs.python.org/3/library/asyncio-task.html#generator-based-coroutines

I don't understand that warning, given that PEP 492 lists as one of
the awaitable types:

* A generator-based coroutine object returned from a function
decorated with types.coroutine().

Perhaps what is going to be removed is support for old style
generator-based coroutines decorated with @asyncio.coroutine, or not
decorated (which historically also worked)?

I'd appreciate some clarification on exactly what is going to be removed.

Maybe we also need updates to the Glossary [2] to bridge the gap
between our previous use of the word "coroutine" (as in PEP 342) and
the way we are using it today, when we are not being explicit about
"native coroutines". In particular, the Glossary has no entry at all
for "generator-based coroutine"—those marked with @types.coroutine.

[2] https://docs.python.org/3/glossary.html

Thank you for your time and help!

Cheers,

Luciano


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

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

[Oscar Benjamin]

On Thu, 18 Feb 2021 at 17:35, Brandt Bucher  wrote:
>
> Thanks for taking the time to work on this, Mark.

Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but I
can see some parts that I definitely like.

> I fear this is at the expense of most simple classes, which currently "just 
> work" with PEP 634. I'm not convinced that making it easier for very 
> complicated classes (like those in `sympy`) to participate at the expense of 
> everyday classes is a win.

While those sympy classes are quite complicated, the relevant aspect
of them is not. The issue is just that they have positional only
constructor arguments. PEP 634 does not allow for positional only
arguments in a class pattern in a way that can work in general. This
is because it requires attributes to exist for classes that would
otherwise have no need for them.

> For comparison, here is what (as I understand it) each PEP requires for a 
> class to be used in a pattern such as `C(x, y, z)`:
>
> ```py
> class C:
> """A PEP 634 matchable class."""
> __match_args__ = ...

You are presuming here that the strings in __match_args__ already
correspond to attributes. Otherwise the PEP 634 version above requires
a property to be added corresponding to each positional argument in
the constructor:

class C:
"""A PEP 634 matchable class"""
__match_args__ = ['a', 'b', 'c']
a = property(lambda self: self._rep[0])
b = property(lambda self: self._rep[1])
c = property(lambda self: self._rep[2])

At runtime case/match looks into __match_args__ and calls getattr
evaluating each property one by one (even if they all derive from the
same internal data structure).

> class C:
> """A PEP 653 matchable class."""
> __match_kind__ = MATCH_CLASS
> __attributes__ = ...
> def __deconstruct__(self):
> ...
> ```

PEP 653 says (although it wasn't immediately obvious to me from reading it):
"""
Classes which define __match_kind__ & MATCH_CLASS to be non-zero must
implement one additional special attribute, and one special method:
"""
Then much later:
"""
object.__match_kind__ will be MATCH_DEFAULT.
"""
I think that means that a simple `class C: pass` will match keyword
patterns with attributes so C(x=1) will match against any C with c.x
== 1.

To match positional arguments both __match_kind__, __attributes__ and
__deconstruct__ would need to be defined but the end result works
better for positional arguments than PEP 634 does:

- It is possible to match the number of positional arguments precisely
so a pattern C(x) would not match an object C(x, y)
- Any invertible mapping between positional arguments and internal
class state can be accommodated.

I don't think it's possible to achieve those with PEP 634.

A concrete example would be matching against a range class:

class range:
__match_args__ = ['start', 'stop', 'step']
def __init__(self, start_or_stop, stop=None, step=1):
if stop is None:
start = 0
stop = start_or_stop
else:
start = start_or_stop
self.start = start
self.stop = stop
self.step = step

With PEP 634 a pattern like range(10) will also match objects like
range(10, 20) and range(10, 20, 2) etc. I think that is not what
someone familiar with range would expect. With PEP 634 there is no way
to define __match_args__ so that positional argument patterns with
range match in a way that corresponds to its constructor syntax (or
that have useful matching semantics in this case).

I'm not entirely sure but I think that with PEP 653 you can implement this like:

def __deconstruct__(obj):
if obj.step != 1:
return obj.start, obj.stop, obj.step
elif obj.start != 0:
return obj.start, obj.stop
else:
return obj.stop

I think that would then mean you could use a pattern range(10) to
unambiguously match range(10) without matching range(10, 20) etc.

Above I suggested that any *invertible* mapping of args to state could
be supported and here there is an example of a non-invertible mapping
since range(0, 10) is the same as range(10). I might have
misunderstood but I don't think that PEP 653 makes it possible to have
a pattern range(10) and a pattern range(0, 10) both match against the
same object range(10). This means that the pattern would always need
to use the "canonical" form of the args (e.g, range(10) in this case).

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

[Python-Dev] Re: Python 0.9.1

[David Mertz]

Will someone publish an manylinux build to conda-forge (or their own
channel)?

On Thu, Feb 18, 2021 at 9:15 PM Dan Stromberg  wrote:

>
> On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky 
> wrote:
>
>> I think to resolve this issue to the completion, and avoid possibility
>> of an intermediary to add any unexpected changes/mistakes to the
>> original sources, instead of "someone making a tarball", someone should
>> make a script, which reproduces making a tarball. Then such a script
>> can be reviewed and tarball reproduced independently (e.g., by the
>> admins of python.org).
>>
>> That's exactly what I did, and attached it to the ticket above:
>> https://github.com/python/pythondotorg/issues/1734#issuecomment-781129337
>>
>> For extra details, copying my comment there:
>>
>> ---
>> I attach my version of such a script (and also paste it below for
>> reference, but if you use it, please use the attached version to avoid
>> any discrepancies due to copy-paste).
>>
>
> I got a version to build, but what's supposed to be in patchlevel.h?  It
> was just an int, but that was confusing gcc.  I commented out its #include,
> and things seemed to work without it.  The patches I used are at
> https://stromberg.dnsalias.org/svn/cpythons/trunk/python0.9/exportable-patches
>
> Sadly, it doesn't work that well with my "pythons" script (
> https://stromberg.dnsalias.org/~strombrg/pythons/), because 0.9.1's
> interpreter doesn't have a -c option.
>
> ___
> 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/XAKEELGLCWOVW77F4PV2S6MYSC7YFXZR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/YUHJS66CKPUAJVBOKVMEWKXBVTBV3EH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Dan Stromberg]

On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky  wrote:

> I think to resolve this issue to the completion, and avoid possibility
> of an intermediary to add any unexpected changes/mistakes to the
> original sources, instead of "someone making a tarball", someone should
> make a script, which reproduces making a tarball. Then such a script
> can be reviewed and tarball reproduced independently (e.g., by the
> admins of python.org).
>
> That's exactly what I did, and attached it to the ticket above:
> https://github.com/python/pythondotorg/issues/1734#issuecomment-781129337
>
> For extra details, copying my comment there:
>
> ---
> I attach my version of such a script (and also paste it below for
> reference, but if you use it, please use the attached version to avoid
> any discrepancies due to copy-paste).
>

I got a version to build, but what's supposed to be in patchlevel.h?  It
was just an int, but that was confusing gcc.  I commented out its #include,
and things seemed to work without it.  The patches I used are at
https://stromberg.dnsalias.org/svn/cpythons/trunk/python0.9/exportable-patches

Sadly, it doesn't work that well with my "pythons" script (
https://stromberg.dnsalias.org/~strombrg/pythons/), because 0.9.1's
interpreter doesn't have a -c option.
___
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/XAKEELGLCWOVW77F4PV2S6MYSC7YFXZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

[Brandt Bucher]

Brandt Bucher wrote:
> For a pattern with no positional subpatterns, such as like `C()` or `C(x=x, 
> y=y, z=z)`: ...

> It also appears that we lose a lot of expressive "idioms" by requiring 
> `__attributes__` to be complete.

> This also means that matching classes like `types.SimpleNamespace` are much 
> less powerful under PEP 653, since the class must know which attributes are 
> "allowed" to be looked up.

Never mind these three points... I *think* setting `__match_kind__ = 
MATCH_DEFAULT` allows for arbitrary attribute extraction like this. Perhaps 
make it bit clearer?
___
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/HCXNNE3B2SS3PFTDVMAA4EWNVXD6TH7W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

[Brandt Bucher]

Thanks for taking the time to work on this, Mark.

Overall, I'm skeptical of this proposal. It seems like it takes a lot of 
"simple" things and makes them quite complex, and takes many "static" things 
and makes them quite dynamic. I feel that it also misrepresents certain aspects 
of PEP 634.

Here's a more detailed commentary:

> Pattern matching will be more usable for complex classes, by allowing classes 
> more control over which patterns they match.

I fear this is at the expense of most simple classes, which currently "just 
work" with PEP 634. I'm not convinced that making it easier for very 
complicated classes (like those in `sympy`) to participate at the expense of 
everyday classes is a win.

For comparison, here is what (as I understand it) each PEP requires for a class 
to be used in a pattern such as `C(x, y, z)`:

```py
class C:
"""A PEP 634 matchable class."""
__match_args__ = ...

class C:
"""A PEP 653 matchable class."""
__match_kind__ = MATCH_CLASS
__attributes__ = ...
def __deconstruct__(self):
...
```

For a pattern with no positional subpatterns, such as like `C()` or `C(x=x, 
y=y, z=z)`:

```py
class C:
"""A PEP 634 matchable class (all classes work)."""

class C:
"""A PEP 653 matchable class."""
__match_kind__ = MATCH_CLASS
__attributes__ = ...
def __deconstruct__(self):
...
```

It also appears that we lose a lot of expressive "idioms" by requiring 
`__attributes__` to be complete. For example, the following attribute 
extractions work with PEP 634, but not PEP 653.

```py
match subject:
case object(a=_):
# Match any object with an "a" attribute.
...
case object(x=x, y=y, z=z):
# Match any object with "x", "y", and "z" attributes, extracting them.
...
```

This also means that matching classes like `types.SimpleNamespace` are much 
less powerful under PEP 653, since the class must know which attributes are 
"allowed" to be looked up.

Further, this whole specification shifts most of the matching logic from the 
class in the pattern to the subject itself:

```py
match ChildA(), ChildB():
case Parent(a, b), Parent(x, y):
...
```

The above pattern could have completely different rules for extracting `a` and 
`b` vs `x` and `y` if either child overrides `__deconstruct__`.  I think that 
is a mistake.

> PEP 634 also privileges some builtin classes with a special form of matching, 
> the "self" match. For example the pattern `list(x)` matches a list and 
> assigns the list to `x`. By allowing classes to choose which kinds of pattern 
> they match, other classes can use this form as well.

This is already fairly trivial to implement:

```py
class C:
__match_args__ = ("_self",)
_self = property(lambda s: s)
```

You can even avoid adding a `_self` attribute if you do some magic with 
descriptors... ;). We could consider provide a decorator for this somewhere in 
the stdlib if there's demonstrated need (but I'm not sure there will be).

> All classes should ensure that the the value of `__match_kind__` follows the 
> specification. Therefore, implementations can assume, without checking, that 
> all the following are false:
> `(__match_kind__ & (MATCH_SEQUENCE | MATCH_MAPPING)) == (MATCH_SEQUENCE | 
> MATCH_MAPPING)`
> `(__match_kind__ & (MATCH_SELF | MATCH_CLASS)) == (MATCH_SELF | MATCH_CLASS)`
> `(__match_kind__ & (MATCH_SELF | MATCH_DEFAULT)) == (MATCH_SELF | 
> MATCH_DEFAULT)`
> `(__match_kind__ & (MATCH_DEFAULT | MATCH_CLASS)) == (MATCH_DEFAULT | 
> MATCH_CLASS)`

Oof. I was scratching my head for way too long at this before I noticed the 
previous sentence said "false". Maybe reword this section to indicate the 
conditions that hold *true*? :)

> Security Implications
> Preventing the possible registering or unregistering of classes as sequences 
> or a mappings, that PEP 634 allows, should improve security. However, the 
> advantage is slight and is not a motivation for this PEP.

I would say the advantage is nonexistent. How is this any different than 
tweaking the flags in a class's `__match_kind__`?

> Efficient Implementation / Implementation

I won't get too deep into this section, but on the surface most flavors of 
implementation/optimization present here are also possible with PEP 634. I 
understand that you feel there are benefits to having "rules" for what 
optimizations are legal, but we don't need to completely change the mechanics 
of the match statement in order to do so.

> Because the object model is a core part of Python, implementations already 
> handle special attribute lookup efficiently. Looking up a special attribute 
> is much faster than performing a subclass test on an abstract base class.

But calling a `__deconstruct__` method whenever positional arguments are 
present will slow down normal class matches, right? I see it as mostly a wash.

> The changes to the semantics can be summarized as:
> - Selecting the kind of pattern uses `cls

[Python-Dev] PEP 653: Precise Semantics for Pattern Matching

[Mark Shannon]

Hi everyone,

I'd like to announce a new PEP.
https://www.python.org/dev/peps/pep-0653/

It builds on PEP 634 (Structural Pattern Matching: Specification), adding:

More precise semantics.
A bit more customization for complex classes.

Its also a bit more robust and should be faster (eventually).

The syntax is unchanged, and in most cases the semantics are the same.

As always, comments and suggestions are welcome.

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

[Python-Dev] Re: Python 0.9.1

[Stefan Ring]

On Thu, Feb 18, 2021 at 10:10 AM Larry Hastings  wrote:
> Call me crazy, but... shouldn't they be checked in?  I thought we literally 
> had every revision going back to day zero.  It should be duck soup to 
> recreate the original sources--all you need is the correct revision number.

It seems to be mostly there, but the directory structure is completely
different. And the demo directory, which constitutes a significant
part of the original "distribution", is absent.

> CVS to SVN to HG to GIT, oh my,

Yeah, back in CVS times it was customary to move files around in the
repository. I’m guilty of this myself. ;)
___
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/WT6VDEQANVFLDNXHGJVFJ232MQS6EJQ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Larry Hastings]

On 2/17/21 4:45 PM, Brett Cannon wrote:
If we can get a clean copy of the original sources I think we should 
put them up under the Python org on GitHub for posterity.



Call me crazy, but... shouldn't they be checked in?  I thought we 
literally had every revision going back to day zero.  It /should/ be 
duck soup to recreate the original sources--all you need is the correct 
revision number.


CVS to SVN to HG to GIT, oh my,


//arry/

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

[Python-Dev] Re: Python 0.9.1

[M.-A. Lemburg]

On 18.02.2021 09:16, M.-A. Lemburg wrote:
> On 18.02.2021 01:45, Brett Cannon wrote:
>> If we can get a clean copy of the original sources I think we should put 
>> them up
>> under the Python org on GitHub for posterity.
> 
> There is already a page with Andrew's build on python.org:
> 
> https://www.python.org/download/releases/early/
> 
> but it's not linked from e.g. https://www.python.org/download/releases/
> 
> His page lists the details around making it work again:
> 
> http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html

I added the missing links.

>> On Wed, Feb 17, 2021 at 6:10 AM Skip Montanaro > > wrote:
>>
>> This is getting a bit more off-topic for python-dev than I'd like. I
>> will make a couple comments though, then hopefully be done with this
>> thread.
>>
>> > The original ones are here:
>> > http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/
>> > Look at http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/index.gz
>> > for the associating subjects with file names. As far as I can tell,
>> > they extract flawlessly using unshar.
>>
>> Thanks. Will check them out.
>>
>> > When I see diffs like this (your git vs. the unshar result) I tend to
>> > trust unshar more:
>>
>> ...
>>
>> Well, sure. I was trying to reverse engineer the original shar files
>> from Google's HTML. I was frankly fairly surprised that I got as close
>> to perfection as I did. I realized that Google had mangled Guido's old
>> CWI email, but didn't worry about it. I also saw the TeX macro
>> mangling, but as I wasn't planning to rebuild the documentation, I
>> didn't worry too much about that. I expected to need a bunch of manual
>> patchwork to get back to something that would even compile.
>>
>> It's nice to know that in this case, "the Internet never forgets."
>>
>> Skip
>> ___
>> 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/J6IOWRUUZ64EHFLGSNBMSNO6RIJEZO22/
>> 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/GHZYRQJOMG63MPZ6XJOBQXPCMV46GXOO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 18 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/XWLRQILHYX6HWXWJL6K4DAAQ5DVRPXXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[M.-A. Lemburg]

On 18.02.2021 01:45, Brett Cannon wrote:
> If we can get a clean copy of the original sources I think we should put them 
> up
> under the Python org on GitHub for posterity.

There is already a page with Andrew's build on python.org:

https://www.python.org/download/releases/early/

but it's not linked from e.g. https://www.python.org/download/releases/

His page lists the details around making it work again:

http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html

> On Wed, Feb 17, 2021 at 6:10 AM Skip Montanaro  > wrote:
> 
> This is getting a bit more off-topic for python-dev than I'd like. I
> will make a couple comments though, then hopefully be done with this
> thread.
> 
> > The original ones are here:
> > http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/
> > Look at http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/index.gz
> > for the associating subjects with file names. As far as I can tell,
> > they extract flawlessly using unshar.
> 
> Thanks. Will check them out.
> 
> > When I see diffs like this (your git vs. the unshar result) I tend to
> > trust unshar more:
> 
> ...
> 
> Well, sure. I was trying to reverse engineer the original shar files
> from Google's HTML. I was frankly fairly surprised that I got as close
> to perfection as I did. I realized that Google had mangled Guido's old
> CWI email, but didn't worry about it. I also saw the TeX macro
> mangling, but as I wasn't planning to rebuild the documentation, I
> didn't worry too much about that. I expected to need a bunch of manual
> patchwork to get back to something that would even compile.
> 
> It's nice to know that in this case, "the Internet never forgets."
> 
> Skip
> ___
> 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/J6IOWRUUZ64EHFLGSNBMSNO6RIJEZO22/
> 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/GHZYRQJOMG63MPZ6XJOBQXPCMV46GXOO/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 18 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/CSX6WQFKLZGDQD6E5U7XKYE5KTAGVJKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Paul Sokolovsky]

Hello,

On Wed, 17 Feb 2021 18:53:46 -0600
Skip Montanaro  wrote:

> > If we can get a clean copy of the original sources I think we
> > should put them up under the Python org on GitHub for posterity.  
> 
> Did that earlier today:
> 
> https://github.com/python/pythondotorg/issues/1734

I think to resolve this issue to the completion, and avoid possibility
of an intermediary to add any unexpected changes/mistakes to the
original sources, instead of "someone making a tarball", someone should
make a script, which reproduces making a tarball. Then such a script
can be reviewed and tarball reproduced independently (e.g., by the
admins of python.org).

That's exactly what I did, and attached it to the ticket above:
https://github.com/python/pythondotorg/issues/1734#issuecomment-781129337

For extra details, copying my comment there:

---
I attach my version of such a script (and also paste it below for
reference, but if you use it, please use the attached version to avoid
any discrepancies due to copy-paste).

The script takes care to preserve not just data, but the metadata of
the release, by setting file timestamps to the date/time of the message
which contained the 1st chunk of the shar archive. It also takes care
to create reproducible tarball, i.e. tarball archives created by
different runs of the script should byte-to-byte match each other (cf.
https://en.wikipedia.org/wiki/Reproducible_builds). Of course, that
depends on .tar and .gz formats themselves being stable (which should
be de-facto the case, and I hope their maintainers treat them as such).
As an extra measure, MD5SUMS of the individual files is also computed
and included in the tarball. Finally, the script itself is also
included, as a kind of executable documentation. That's why it's
important the script itself to be byte-perfect when recreating the
tarball. I also didn't make it executable, it should be run as sh
python-0.9.1-create-tarball.sh.

Under conditions described above, the tarball produced should have
following md5sum:

65e0c4140583c7032f35036939cf1bdd  python-0.9.1.tar.gz

https://github.com/python/pythondotorg/files/6001019/python-0.9.1-create-tarball.sh.gz

The script contents for reference (do not copy-paste, use attached
version above):

#!/bin/sh
#
# This script creates fully reproducible, bytes-perfect tarball of the
# CPython 0.9.1 release (initial public release) as posted by Guido
# van Rossum to the Usenet "alt.sources" newsgroup
# (https://en.wikipedia.org/wiki/Usenet_newsgroup). This is not first
# attempt to recover the original 0.9.1 sources, but many previous
# attempts started from the Dejanews Usenet archives, later acquired
# by Google, which have whitespace issues (tabs converted to spaces).
# This script uses alternative archive source at ftp.fi.netbsd.org,
# which doesn't have whitespace issues.
#
# This script strives to produce fully reproducible archive, and for
# this explicitly sets GMT date of all files included in the archive.
# So, for as long as TAR and GZIP formats are themselves stable across
# systems, this script should produce bytes-exact archive files on any
# system.
#

set -e
# Index: http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/index.gz
cat >urls 
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910220.11.gz#Python
 0.9.1 part 03/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.31.gz#Python
 0.9.1 part 04/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.32.gz#Python
 0.9.1 part 05/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.33.gz#Python
 0.9.1 part 06/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.34.gz#Python
 0.9.1 part 07/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.35.gz#Python
 0.9.1 part 08/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.36.gz#Python
 0.9.1 part 09/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.37.gz#Python
 0.9.1 part 10/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.38.gz#Python
 0.9.1 part 11/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.39.gz#Python
 0.9.1 part 12/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.40.gz#Python
 0.9.1 part 13/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.41.gz#Python
 0.9.1 part 14/21 <2...@charon.cwi.nl>
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/910224.42.gz#Python
 0.9.1 part 15/21 <2...@charon.cwi.nl>
http: