[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Raymond Hettinger]

> On Oct 30, 2020, at 4:51 PM, Gregory P. Smith  wrote:
> 
> On Fri, Oct 30, 2020 at 1:14 PM Raymond Hettinger 
>  wrote:
> FWIW, when the tracker issue landed with a PR, I became concerned that it 
> would be applied without further discussion and without consulting users.
> 
> An issue and a PR doesn't simply mean "it is happening".

There have been a number of issues/pr pairs this year that have followed 
exactly that path.  

While we'll never know for sure, it is my belief that this would have been 
applied had I not drawn attention to it.  Very few people follow the bug 
tracker everyday — the sparse Solaris community almost certainly would not have 
been aware of the tracker entry.   Likewise, I don't think there would have 
been a python-dev thread; otherwise, it would have happened *prior* to the PR, 
the tracker issue, and all of the comments from the people affected.  The call 
for helpers was made only *after* the user pleas not to pull the trigger.  

It's all fine now.  The decision is being broadly discussed.  That is what is 
important.


Raymond  

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

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[Tin Tvrtković]

A small update on this, since I've been playing with it.

I'm trying to implement a websocket proxy, since it's an example of a toy
project that needs to juggle two long-lived asyncio connections at once.
I'm using Starlette/Uvicorn for the server part (the part that accepts the
connection) and aiohttp's client functionality to connect to an echo server
on the Internet.

I've settled on the async iterator interface as a good building block for
this, not queues. Turns out an async iterator looks very much as the read
interface for a Go channel (they spit out values and signal their closure).
Aiohttp already provides an async iterator interface for reading from the
upstream server. Starlette doesn't, but an adapter is very easy to write.

Now that we've settled on a suitable interface, a helper function (wait_on)
is easy to write. (Code omitted for brevity.) This is the entire request
handler:

async def ws_proxy(client: WebSocket):
await client.accept()
async with ClientSession() as session:
async with session.ws_connect("wss://echo.websocket.org") as s:
c = starlette_websocket_iterator(client)
async for r in wait_on(c, s):
match r:
case (src, None):
print(f"{src} closed the connection")
break
case (src, msg) if src is c:
print(f"CLIENT: {msg}")
await s.send_str(msg)
case (src, msg) if src is s:
print(f"SERVER: {msg}")
await client.send_text(msg.data)

So yeah, the helper yields tuples of the source and message, using None as
a sentinel for closure. Guards are used to match on the source, using
iterator identity. My first version just used `case (s, msg):` hoping to
match on the identity of s, but that doesn't work since s is not a literal.

I'd say this is pretty cool. With the ecosystem moving to async iterators
for streams of data (or just writing adapters), I'd say this style of
programming is quite readable and understandable.

On Tue, Oct 27, 2020 at 1:16 AM Tin Tvrtković  wrote:

> Hello,
>
> Go channels are indeed very similar to asyncio Queues, with some added
> features like channels being closable. (There is also special syntax in the
> select statement, `val, ok <- chan`, that will set the `ok` variable to
> false if the channel has been closed.) A larger difference, I think, is
> that in Go channels are used practically everywhere, more so than asyncio
> Queues. They are an abstraction the vast majority of Go concurrency is
> built upon.
>
> Building this for asyncio tasks, instead of just queues, would be much
> more useful in Python.
>
> Contemplating this some more, I would agree we don't need an async match.
> A function and some types to match on would probably be enough to get us
> close to a select statement in a PEP634 Python. I guess the challenge is
> designing these matchable types for ease of use now, and I need to study
> the pattern matching PEPs in more detail to be able to contribute here.
>
> On one hand, this means this problem can be solved by a third party
> library. On the other hand, I feel like this would be very useful so it
> might be worth it to have it somewhere in the stdlib asyncio namespace.
>
> Since `asyncio.wait` can yield multiple tasks in the completed set, this
> would probably have to be wrapped in an `async for`.
>
>
>
> On Mon, Oct 26, 2020 at 12:33 PM Gustavo Carneiro 
> wrote:
>
>> It's true that asyncio.wait provides the tools that you need, but it's a
>> bit clunky to use correctly.
>>
>> Maybe would be something along the lines of:
>>
>> --
>> queue1 = asyncio.Queue()
>> queue2 = asyncio.Queue()
>> ...
>> get1 = asyncio.create_task(queue1.get())
>> get2 = asyncio.create_task(queue2.get())
>> await asyncio.wait({get1, get2}, return_when=asyncio.FIRST_COMPLETED)
>> match [task.done() for task in (get1, get2)]:
>> case [True, False]:  get2.cancel(); item1 = await get1; 
>> case [False, True]:  get1.cancel(); item2 = await get2; 
>> case [True, True]:  item1 = await get1; ; item2 = await get2;
>> 
>> --
>>
>> If asyncio.Queue() is the equivalent of Go channels, perhaps it would be
>> worth designing a new API for asyncio.Queue, one that is better suited to
>> the match statement:
>>
>> class Queue:
>>async def read_wait(self) -> 'Queue':
>>"""
>>Waits until the queue has at least one item ready to read, without
>> actually consuming the item.
>>"""
>>
>> Then we could more easily use match statement with multiple queues, thus:
>>
>> --
>> async def ready_queue(*queues: asyncio.Queue) -> asyncio.Queue:
>>"""
>>Take multiple queue parameters and waits for at least one of them to
>> have items pending to read, returning that queue.
>>"""
>>await asyncio.wait({queue.read_wait() for queue in queues},
>> 

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Gregory P. Smith]

On Fri, Oct 30, 2020 at 2:30 PM Garrett D'Amore via Python-Dev <
python-dev@python.org> wrote:

> I’m not on this list.  But I have offered to help - if there are tasks
> that need to be done to help this I can help put the weight of a commercial
> entity behind it whether that involves assigning our developers to work on
> this, helping pay for external developers to do so, or assisting with
> access to machine resources.
>
> For the record there are multiple  illumos distributions and most are both
> free and run reasonably well in virtual machines. Claiming that developers
> don’t have access as a reason to discontinue the port is a bit
> disingenuous. Anyone can get access if they want and if they can figure out
> how to login and use Linux then this should be pretty close to trivial for
> them.
>

Thanks!  It usually isn't just about access.  This email thread and related
tweets appear to have served their purpose: To drum up volunteers+resources
from the otherwise potentially impacted communities.  The valuable thing is
developer time.

Access: I took it upon myself to spin up some Solaris-derivative VMs for
Python dev things in the (now distant) past.  It wasn't a positive
experience, I won't do it again.  Bonus on top of that: Oracle, the owner
of Solaris, is *still* actively attempting to destroy the entire software
industry .
Working on anything attempting to directly benefit them is a major ethical
violation for me.  Others make their own choices.

I won't even spin up major BSD VMs anymore for a similar reason.  It isn't
a good positive use of my time, even despite having an enjoyable past with
those OSes and knowing several past and present Free/Net/OpenBSD core devs.

I look forward to new *Solaris buildbot(s) joining the fleet,
-gps
___
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/7Y7BXPMRPYJE6CUCMIYBY3EXOKQLMIVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Gregory P. Smith]

On Fri, Oct 30, 2020 at 1:14 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

> FWIW, when the tracker issue landed with a PR, I became concerned that it
> would be applied without further discussion and without consulting users.


An issue and a PR doesn't simply mean "it is happening".  It is an
effective way to communicate and demonstrate a possible change.  It appears
to have served its purpose.
___
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/BSN5BIHQWBXZ2G5EXVWKEIEBC4X6KJYO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Skip Montanaro]

On Thu, Oct 29, 2020, 6:32 PM Gregory P. Smith  wrote:

> I agree, remove Solaris support. Nobody willing to contribute seems
> interested.
>

*sniff* I spent a lot of professional time in front of SunOS and Solaris
screens. But yes, I agree. It seems time to give Solaris the boot.

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

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Greg Ewing]

On 31/10/20 7:22 am, Mark Shannon wrote:

On 30/10/2020 4:09 pm, Brandt Bucher wrote:
Anyone who reduces pattern matching 
to "a fancy switch statement" probably isn't the right person to be 
discussing its semantics and usefulness with.


Pattern matching is a fancy switch statement, if you define "fancy" 
appropriately ;)


I think Brandt's point is that it sounded as though you were making
a derogatory remark about the statement option, and that people are
likely to stop listening to someone who does that kind of thing.


OOI, what is the reasoning for choosing a statement, not an expression?


Which is a *much* better way to say what I think you were trying to
say.

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Garrett D'Amore via Python-Dev]

I’m not on this list.  But I have offered to help - if there are tasks that 
need to be done to help this I can help put the weight of a commercial entity 
behind it whether that involves assigning our developers to work on this, 
helping pay for external developers to do so, or assisting with access to 
machine resources. 

For the record there are multiple  illumos distributions and most are both free 
and run reasonably well in virtual machines. Claiming that developers don’t 
have access as a reason to discontinue the port is a bit disingenuous. Anyone 
can get access if they want and if they can figure out how to login and use 
Linux then this should be pretty close to trivial for them. 

What’s more likely is that some group of developers aren’t interested in 
supporting stuff they don’t actively use.  I get it.  It’s easier to work in a 
monoculture. But in this case there are many many more users of this that would 
be impacted than a naive examination of downloads will show.

Of course this all presumes that the core Python team still places value on 
being a cross platform portable tool. I can help solve most of the other 
concerns - except for this one. 

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Paul Moore]

On Fri, 30 Oct 2020 at 20:13, Raymond Hettinger
 wrote:
>
> I vote against removal.
>
> We have no compelling need to disrupt an entire community and ecosystem even 
> though it it is small.
[...]
> Given this kind of user response, I think it would irresponsible to drop 
> support.

I vote for leaving things as they are. There are clearly users who
value the current level of support. No core developer *has* to fix
Solaris issues if they feel their time is better spent elsewhere, so I
don't see the point of spending effort ripping out code that (some)
people find useful. And in Raymond's follow up he mentions someone
who's offering resources to help. Let's take them up on that.

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Raymond Hettinger]

Here are a couple comments on the Twitter thread that warrant your attention.

Apparently, this is being used by the European Space Agency on their space 
craft.
-- https://twitter.com/nikolaivk/status/1322094167980466178

"To be clear I will put some money where my mouth is.  If we need to invest 
resources either in the form of developers or dollars to keep the port alive we 
will. By we I mean RackTop and/or Staysail Systems." -- 
https://twitter.com/gedamore/status/1321959956199866369


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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Raymond Hettinger]

I vote against removal.

We have no compelling need to disrupt an entire community and ecosystem even 
though it it is small.  

To anyone chiming in to say, yes drop the support, ask whether you've consulted 
any of the users — they should have a say in the matter. It is better for them 
to be a bit neglected than to be cut it off entirely.

FWIW, when the tracker issue landed with a PR, I became concerned that it would 
be applied without further discussion and without consulting users.  So I asked 
on Twitter whether Solaris was being used.  If you're interested in the 
responses, see the thread at: https://twitter.com/i/status/1321917936668340227 
(Victor can't see it because he blocked my account a long time ago).  Also take 
a look at the user comments on the tracker: https://bugs.python.org/issue42173 
.  For those who don't follow links, here's a sample:

* "Platform genocide is both unnecessary and unwarranted." -- brett3
* "Please do not drop support." -- jm650
* "I just want to lend my voice in favor of maintaining "Solarish" support as 
well, and offer what help I may for resolving issues."-- robertfrench
* "No no no, please don't." -- tbalbers
* "Please do not drop support for SunOS." -- mariuspana
* "Please continue support for Solaris/IllumOS! This is very important for us." 
-- marcheschi
* "Please don't drop Solaris support, we still use it to this day." -- abarbu
* ... and many more will the same flavor

Given this kind of user response, I think it would irresponsible to drop 
support.


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

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Chris Angelico]

On Sat, Oct 31, 2020 at 5:31 AM Mark Shannon  wrote:
> > It's right here that you lose me. Anyone who reduces pattern matching to "a 
> > fancy switch statement" probably isn't the right person to be discussing 
> > its semantics and usefulness with. It seems that some people just can't 
> > separate the two ideas in their mind. It's like calling a class a "fancy 
> > module".
>
> Pattern matching is a fancy switch statement, if you define "fancy"
> appropriately ;)
>
> Reducing pattern matching to some sort of switch statement is exactly
> what a good implementation should do. It's what compilers are for.
> The comparison seems entirely reasonable to me.

"What compilers are for" is turning useful high level constructs into
low level executable forms. I don't think anyone would say that a for
loop is just a fancy GOTO, even though it gets compiled into one.

I don't care how the compiler represents something; I care how I'll be
using it. A regular expression isn't, to me, a state machine - it's a
way to describe a text pattern.

> > It's okay that you feel that way, but hopefully you'll understand if people 
> > start to tune out messages that contain these sorts of comments.
> >
>
> What does "these sorts of comments" mean?
> Ones that you disagree with?
>
> If I am wrong, please explain why in an as objective a fashion as possible.

Considering how subjective your posts in this thread are, there's some
irony in begging for the complaint to be objective.

> >> I would ask anyone who wants pattern matching adding to Python, to not 
> >> support PEP 634.
> >
> > Seriously?
>
> Yes. Absolutely.
> PEP 634 is seriously flawed.

FUD. You haven't given a single reason for it to be considered flawed,
you've just said that it 'is' flawed, as though we should already know
what's wrong with it.

I don't draw this parallel lightly, but Mark, you're actually sounding
scarily similar to jmf and his anti-PEP393 posts. Extremely light on
actual arguments, and entirely based on emotive complaints and an
assumption that your readers already know why this is somehow a bad
thing.

If you want PEP 634 to be rejected, explain why. Don't try to get us
to go back over the past thousands of posts (never mind the ones
stretching back ten years even).

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Gregory P. Smith]

On Fri, Oct 30, 2020 at 11:03 AM Brett Cannon  wrote:

>
> On Fri, Oct 30, 2020 at 6:37 AM Pablo Galindo Salgado 
> wrote:
>
>> >Two volunteer core developers and at least one buildbot would help a
>> > lot to ensure that Python is working on Solaris for real, and reduce
>> > the number of open Solaris issues. If it happens, I'm perfectly fine
>> > with keeping Solaris support.
>> > I also hope that more people will contribute to maintain the code, not
>> > only Ronald and Jesús. Many people wrote to me that Python is a key
>> > component of Illumos (the package manager is written in Python). So
>> > maybe Python on Illumos deserves some love?
>>
>> If we decide to take the proposal seriously, I think it may be beneficial
>> to establish a deadline for having the buildbot green and the issues
>> fixed,
>> so the promise of having "real" support at some point in the future does
>> actually manifest itself or it does not block following Victor's proposal
>> if it
>> actually does not happen.
>>
>
> I agree, and so maybe it's time to more formally establish what platforms
> we do support, such that any platform not listed is not considered
> supported. We could reorient PEP 11 towards that and for each platform we
> list:
>
> 1. Which buildbot must be green for that platform to be considered
> supported
> 2. Who is in charge of submitting patches to keep that buildbot green (and
> what that minimum number of people is)
> 3. We have an agreed upon timeline that if a buildbot stays red for longer
> than the specified time then the platform is considered abandoned
> 4. We all agree to prioritize patches from the people listed for a
> platform to fix their buildbots if they are not core devs
> 5. We have a clear definition of "platform" (e.g. is "Linux" a platform,
> or does it break down to individual distros?)
>
> Would there be anything else we would want for a platform for us to be
> willing to consider it supported?
>

If we're going to explicitly list Platforms, that gets messy to maintain.
It becomes important to draw a distinction between types of support.
Support is not a boolean.  We're autoconf based on the posix side (like it
or not) which leads to a lot of things that for the most part just mostly
work, regardless of support.  That is working as intended.

Generally, recent enough of each of: Linux distros (all architectures),
macOS, Windows, and AIX.  But that alone does not constitute a platform.

But to define things explicitly you need a definition of what a Platform is:

is it an OS kernel? what version(s)? compiler toolchain? what versions? Is
it also the C library? what version(s) of which libc variants (linux has at
least three)? other system libraries? what versions? specific CPU
architectures? what versions.  The matrix gets huge.

It can be defined.

But then you need to clarify the different levels of not being in that
matrix. "on the list, all clear" vs "likely works, no guarantees" vs
"expect lots of test failures" vs "expect extension module build failures"
vs "expect the core interpreter build to fail".

We've not done this in the past.  Would it even add value?

It is much easier to look at the list of buildbots tagged "stable".  and
consider that "on the list, all clear" and everything else is in an
unspecified one of the other four+ categories without arguments over which
sub-support list any given thing is in.

-gps


> -Brett
>
>
>>
>> On Fri, 30 Oct 2020 at 12:54, Victor Stinner  wrote:
>>
>>> Hi Ronald,
>>>
>>> Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren 
>>> a écrit :
>>> > I agree. That’s what I tried to write, its not just providing a
>>> buildbot but also making sure that it keeps working and stays green.
>>>
>>> This is really great!
>>>
>>> Jesús Cea Avión is also a volunteer to maintain the Solaris (see the
>>> bpo).
>>>
>>> Moreover, it seems like some people would like to provide servers to
>>> run a Solaris buildbot. Example:
>>> https://bugs.python.org/issue42173#msg379895
>>>
>>> Two volunteer core developers and at least one buildbot would help a
>>> lot to ensure that Python is working on Solaris for real, and reduce
>>> the number of open Solaris issues. If it happens, I'm perfectly fine
>>> with keeping Solaris support.
>>>
>>> I also hope that more people will contribute to maintain the code, not
>>> only Ronald and Jesús. Many people wrote to me that Python is a key
>>> component of Illumos (the package manager is written in Python). So
>>> maybe Python on Illumos deserves some love?
>>>
>>> There are many ways to contribute to the Solaris support of Python:
>>>
>>> * Comment Solaris issues (bugs.python.org, search for "Solaris" in the
>>> title)
>>> * Propose PRs to fix issues or implement Solaris specific features
>>> * Review Solaris PRs
>>> * Provide Solaris servers accessible to Python core developers (SSH
>>> access)
>>> * Donate to the CPython project:
>>>
>>>   * https://www.python.org/psf/donations/python-dev/
>>>   * 

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Paul Moore]

On Fri, 30 Oct 2020 at 18:30, Mark Shannon  wrote:
>
> Hi Brandt,
>
> On 30/10/2020 4:09 pm, Brandt Bucher wrote:
> >> Can we discuss whether we want pattern matching in Python and the broader 
> >> semantics first, before dealing with low level details?
> >
> > This is a huge step backward. These discussions have already taken place, 
> > over the last 10 years.
>
> So what you are saying is that I'm not allowed to voice my opinions,
> because it is outside a time frame of your choosing?

I certainly wouldn't say that, but I do think that if you're not
taking into account the extended history of ideas and of people
expressing a desire for some kind of pattern matching in Python, then
you shouldn't be surprised if people consider your objections
insufficiently well-informed.

> >
> > Here's just a sampling:
> >
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/IEJFUSFC5GBDKFIPCAGS7JYXV5WGVAXP/
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/GTRRJHUG4W2LXGDH4AU46SI3DLWXJF6A/
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/EURSG3MYEFHXDDL2474PQNQZFJ3CUIOX/
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/NTQEL3HRUJMULQYI6RDBTXQ2H3KHBBRO/
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/NEC54II2RB3JRGHDP6PX3NOEALRAK6BV/
> > - 
> > https://mail.python.org/archives/list/python-id...@python.org/thread/T3VBUFECTLZMB424MBBGUHCI24YA4FPT/
> >
> > We read all of these and more back way in March, before we even started 
> > brainstorming syntax and semantics.
> >
> >> Do we want a fancy switch statement, or a powerful expression?
> >
> > It's right here that you lose me. Anyone who reduces pattern matching to "a 
> > fancy switch statement" probably isn't the right person to be discussing 
> > its semantics and usefulness with. It seems that some people just can't 
> > separate the two ideas in their mind. It's like calling a class a "fancy 
> > module".
>
> Pattern matching is a fancy switch statement, if you define "fancy"
> appropriately ;)

Everything is a goto if you want to play reductionist games. In
practice, though, the proposed match statement feels more like the
constructs in recent languages like Rust than like the C switch
statement.

> Reducing pattern matching to some sort of switch statement is exactly
> what a good implementation should do. It's what compilers are for.
> The comparison seems entirely reasonable to me.

Yes, the implementation might do this. But the *semantics* are what
matter here, and they are firmly in the area of "how developers should
think about the construct". Anyone thinking about pattern matching
with the C switch statement in mind is going to miss a huge amount of
the power and expressiveness of the construct.

> OOI, what is the reasoning for choosing a statement, not an expression?
>
> >
> > It's okay that you feel that way, but hopefully you'll understand if people 
> > start to tune out messages that contain these sorts of comments.
> >
>
> What does "these sorts of comments" mean?
> Ones that you disagree with?

Personally, I'm likely to tune out messages that seem to be ignoring
or dismissing big chunks of the discussion. Not "because I disagree",
but because there's no option for discussion or compromise if you
don't address the arguments already made in favour of pattern
matching.

To give one example, you say "Can we discuss whether we want pattern
matching in Python and the broader semantics first". I'd say yes we
do. There are many examples in the discussions so far on the PEPs (and
plenty more in the 10 years of history that Brandt mentioned) where
people have said they like how a given piece of code looks as a match
statement. You may not agree, but language features don't have to be
something that *everyone* likes, as long as there's sufficient value
to a sufficiently large user base to offset the costs of the feature.

Can you provide a counter-argument, or are you just asking that we go
round that discussion again, with no new information to add?

> If I am wrong, please explain why in an as objective a fashion as possible.

You are wrong that there is no support for pattern matching. See the
number of posts in support. You are wrong that pattern matching is
"just a fancy switch" - see examples in the PEP of many things a C
switch can't do (destructuring, for a start). If you want to claim
that's just "fancy", then I'd ask for a clarification of how far you
consider "fancy" to go, and why you consider a sufficiently fancy
switch to be useless based on an assumption that a non-fancy switch
would be. Hopefully that's a start towards objectively explaining why
I consider that you are wrong.

> >> What special method(s) should be added?
> >
> > None. PEP 622 originally added one, but even that is more than we need 
> > right now. Some people may need to register their mappings or sequences as 
> > Mappings or 

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Sebastian Wiedenroth]

> Am 30.10.2020 um 19:13 schrieb Gregory P. Smith :
> 
> 
> 
> FWIW making a PR that adds platform specific test skips or expected failure 
> decorators is a good way to start bringing up new buildbots.  It serves as 
> effective documentation of what does and doesn't work that lives directly in 
> the codebase, in a way that can be evolved over time as more is made to work.


Ok great, thanks for the guidance.
I'll see what needs to be done for this.

Best,
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/3CCTCMLTVFLGDEMUPCWOARFVWGQ2HNI4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Mark Shannon]

Hi Brandt,

On 30/10/2020 4:09 pm, Brandt Bucher wrote:

Can we discuss whether we want pattern matching in Python and the broader 
semantics first, before dealing with low level details?


This is a huge step backward. These discussions have already taken place, over 
the last 10 years.


So what you are saying is that I'm not allowed to voice my opinions, 
because it is outside a time frame of your choosing?




Here's just a sampling:

- 
https://mail.python.org/archives/list/python-id...@python.org/thread/IEJFUSFC5GBDKFIPCAGS7JYXV5WGVAXP/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/GTRRJHUG4W2LXGDH4AU46SI3DLWXJF6A/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/EURSG3MYEFHXDDL2474PQNQZFJ3CUIOX/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/NTQEL3HRUJMULQYI6RDBTXQ2H3KHBBRO/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/NEC54II2RB3JRGHDP6PX3NOEALRAK6BV/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/T3VBUFECTLZMB424MBBGUHCI24YA4FPT/

We read all of these and more back way in March, before we even started 
brainstorming syntax and semantics.


Do we want a fancy switch statement, or a powerful expression?


It's right here that you lose me. Anyone who reduces pattern matching to "a fancy switch 
statement" probably isn't the right person to be discussing its semantics and usefulness with. 
It seems that some people just can't separate the two ideas in their mind. It's like calling a 
class a "fancy module".


Pattern matching is a fancy switch statement, if you define "fancy" 
appropriately ;)


Reducing pattern matching to some sort of switch statement is exactly 
what a good implementation should do. It's what compilers are for.

The comparison seems entirely reasonable to me.

OOI, what is the reasoning for choosing a statement, not an expression?



It's okay that you feel that way, but hopefully you'll understand if people 
start to tune out messages that contain these sorts of comments.



What does "these sorts of comments" mean?
Ones that you disagree with?

If I am wrong, please explain why in an as objective a fashion as possible.



What special method(s) should be added?


None. PEP 622 originally added one, but even that is more than we need right 
now. Some people may need to register their mappings or sequences as Mappings 
or Sequences, but otherwise that's it.


Much of the language uses special methods. Why should pattern matching 
be so different?


Why make this opt-out, rather than opt-in, given the potential for 
unwanted side effects?





I would ask anyone who wants pattern matching adding to Python, to not support 
PEP 634.


Seriously?


Yes. Absolutely.
PEP 634 is seriously flawed.



I would ask anyone who wants pattern matching added to Python to carefully 
consider the PEPs for themselves (particularly PEP 636, which is much less dry 
and contains more examples and commentary). We've written four of the largest, 
most detailed PEPs of any new feature I've seen, complete with a working 
implementation that we've made available from any browser. Of course it's not 
the *only* way of getting pattern matching... but if you want it, this is 
probably your *best* shot at getting it.
Given the size of the proposed change to the language, it really isn't 
that detailed.


The browser based implementation is nice, though :)

Cheers,
Mark.




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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Gregory P. Smith]

On Fri, Oct 30, 2020 at 8:26 AM Sebastian Wiedenroth 
wrote:

> Hi,
>
> I've already commented on the issue, but want to make a few more points
> here as well.
>
> Removing Solaris support would not only impact Oracle Solaris but the open
> source illumos community as well.
> Both systems share the "SunOS" uname for historical reasons. Removing
> support would be a disaster for us.
>
> We are a small community compared to Linux, but there are illumos
> distributions (OpenIndiana, OmniOS, SmartOS, Tribblix, ...) that have many
> python users.
> It's also an essential part of our tooling and package management.
>
> I've offered to host an illumos buildbot before but it was not accepted
> because not all tests passed at that time.
> There is active work going on to get this debugged and fixed.
> If it is acceptable to skip some tests we can have the buildbot online
> tomorrow.
>

FWIW making a PR that adds platform specific test skips or expected failure
decorators is a good way to start bringing up new buildbots.  It serves as
effective documentation of what does and doesn't work that lives directly
in the codebase, in a way that can be evolved over time as more is made to
work.

-gps

On the ticket many users and developers have offered to step up, myself
> included.
> In our IRC channel we also had some discussions yesterday and we're hoping
> to bring more patches upstream soon.
>
> If there is interest in ssh access to illumos systems that is also
> something I can offer.
>
> Please let us know if there is more we need to do to keep python on
> illumos supported.
>
> Best regards,
> 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/UL4MQAKQZOIEEA2DHNJNB4BB4J3QR7FY/
> 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/S3MDFH6PHZR2TN4NYLM4PBNQPHQZZMWW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-10-23 - 2020-10-30)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7626 (+18)
  closed 46322 (+64)
  total  53948 (+82)

Open issues with patches: 3063 


Issues opened (60)
==

#30681: email.utils.parsedate_to_datetime() should return None when da
https://bugs.python.org/issue30681  reopened by serhiy.storchaka

#41919: Modify test_codecs to use the new codecs.unregister() function
https://bugs.python.org/issue41919  reopened by pablogsal

#42131: [zipimport] Update zipimport to use specs
https://bugs.python.org/issue42131  opened by brett.cannon

#42132: Use specs instead of just __loader__ in C code
https://bugs.python.org/issue42132  opened by brett.cannon

#42133: Update the stdlib to fall back to __spec__.parent if __loader_
https://bugs.python.org/issue42133  opened by brett.cannon

#42134: Raise ImportWarning when falling back to find_module()
https://bugs.python.org/issue42134  opened by brett.cannon

#42135: [importlib] Deprecate find_module() implementations
https://bugs.python.org/issue42135  opened by brett.cannon

#42136: [importlib] deprecate module_repr() methods
https://bugs.python.org/issue42136  opened by brett.cannon

#42137: Raise an ImportWarning for calling module_repr() on loaders
https://bugs.python.org/issue42137  opened by brett.cannon

#42140: asyncio.wait function creates futures set two times
https://bugs.python.org/issue42140  opened by dutradda

#42142: FAIL tkinter ttk LabeledScale test_resize, and more
https://bugs.python.org/issue42142  opened by terry.reedy

#42146: subprocess.Popen() leaks cwd in case of uid/gid overflow
https://bugs.python.org/issue42146  opened by izbyshev

#42149: Python 'make test' failed inside ssh+tmux
https://bugs.python.org/issue42149  opened by kmash

#42151: Pure Python xml.etree.ElementTree is missing default attribute
https://bugs.python.org/issue42151  opened by obfusk

#42152: Use PyDict_Contains() and PyDict_SetDefault() instead of PyDic
https://bugs.python.org/issue42152  opened by serhiy.storchaka

#42153: doc: library imaplib a url not available
https://bugs.python.org/issue42153  opened by chrisxiao

#42154: Bad proxy returned immediately after BaseManager server restar
https://bugs.python.org/issue42154  opened by jryan

#42158: http.server doesn't guess n-quads, n-triples, notation3 and Tr
https://bugs.python.org/issue42158  opened by DylanVanAssche

#42159: AsyncMock restores stopped patch if same object stopped multip
https://bugs.python.org/issue42159  opened by lisroach

#42162: The license page for Python 3.0 is messed up
https://bugs.python.org/issue42162  opened by MaT1g3R

#42163: _replace() no longer works on platform.uname_result objects
https://bugs.python.org/issue42163  opened by cs-shadow

#42164: Python fails to compile in the Fedora Stable LTO buildbots
https://bugs.python.org/issue42164  opened by pablogsal

#42166: corrupted size vs. prev_size
https://bugs.python.org/issue42166  opened by kannanf9t

#42167: Documentation for SETUP_WITH opcode is wrong
https://bugs.python.org/issue42167  opened by pxeger

#42171: Add PEP 573 to the stable ABI
https://bugs.python.org/issue42171  opened by petr.viktorin

#42173: Drop Solaris support
https://bugs.python.org/issue42173  opened by vstinner

#42174: shutil.get_terminal_size() returns 0 when run in a pty
https://bugs.python.org/issue42174  opened by The Compiler

#42177: Improving KeyError exception
https://bugs.python.org/issue42177  opened by zingero

#42178: failed pickle hangs python on exit in CMD.exe only
https://bugs.python.org/issue42178  opened by charles.mcmarrow.4

#42179: Clarify chaining exceptions in tutorial/errors.rst
https://bugs.python.org/issue42179  opened by Vladimir Ryabtsev

#42181: describe PyEval_CallObjectWithKeywords and its replacement
https://bugs.python.org/issue42181  opened by j5w6

#42182: 3.10 Documentation Not Hyperlinking Some Methods
https://bugs.python.org/issue42182  opened by kj

#42183: Stack overflow error with asyncio.all_tasks and wait_for
https://bugs.python.org/issue42183  opened by Gobot1234

#42184: pdb exits unexpectedly when calling args
https://bugs.python.org/issue42184  opened by xgenadam

#42185: class body bytecode uses less efficient *_NAME opcodes
https://bugs.python.org/issue42185  opened by gregory.p.smith

#42186: unittest overrides more serious warnings filter added before u
https://bugs.python.org/issue42186  opened by yilei

#42187: Deprecating / removing token.ISTERMINAL/ISNONTERMINAL
https://bugs.python.org/issue42187  opened by BTaskaya

#42188: forkserver not reused in child processes
https://bugs.python.org/issue42188  opened by cchomey

#42189: copy.deepcopy() no longer works on platform.uname_result objec
https://bugs.python.org/issue42189  opened by rocallahan

#42190: global declarations affect too much inside exec or 

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Brett Cannon]

On Fri, Oct 30, 2020 at 6:37 AM Pablo Galindo Salgado 
wrote:

> >Two volunteer core developers and at least one buildbot would help a
> > lot to ensure that Python is working on Solaris for real, and reduce
> > the number of open Solaris issues. If it happens, I'm perfectly fine
> > with keeping Solaris support.
> > I also hope that more people will contribute to maintain the code, not
> > only Ronald and Jesús. Many people wrote to me that Python is a key
> > component of Illumos (the package manager is written in Python). So
> > maybe Python on Illumos deserves some love?
>
> If we decide to take the proposal seriously, I think it may be beneficial
> to establish a deadline for having the buildbot green and the issues fixed,
> so the promise of having "real" support at some point in the future does
> actually manifest itself or it does not block following Victor's proposal
> if it
> actually does not happen.
>

I agree, and so maybe it's time to more formally establish what platforms
we do support, such that any platform not listed is not considered
supported. We could reorient PEP 11 towards that and for each platform we
list:

1. Which buildbot must be green for that platform to be considered supported
2. Who is in charge of submitting patches to keep that buildbot green (and
what that minimum number of people is)
3. We have an agreed upon timeline that if a buildbot stays red for longer
than the specified time then the platform is considered abandoned
4. We all agree to prioritize patches from the people listed for a platform
to fix their buildbots if they are not core devs
5. We have a clear definition of "platform" (e.g. is "Linux" a platform, or
does it break down to individual distros?)

Would there be anything else we would want for a platform for us to be
willing to consider it supported?

-Brett


>
> On Fri, 30 Oct 2020 at 12:54, Victor Stinner  wrote:
>
>> Hi Ronald,
>>
>> Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren  a
>> écrit :
>> > I agree. That’s what I tried to write, its not just providing a
>> buildbot but also making sure that it keeps working and stays green.
>>
>> This is really great!
>>
>> Jesús Cea Avión is also a volunteer to maintain the Solaris (see the bpo).
>>
>> Moreover, it seems like some people would like to provide servers to
>> run a Solaris buildbot. Example:
>> https://bugs.python.org/issue42173#msg379895
>>
>> Two volunteer core developers and at least one buildbot would help a
>> lot to ensure that Python is working on Solaris for real, and reduce
>> the number of open Solaris issues. If it happens, I'm perfectly fine
>> with keeping Solaris support.
>>
>> I also hope that more people will contribute to maintain the code, not
>> only Ronald and Jesús. Many people wrote to me that Python is a key
>> component of Illumos (the package manager is written in Python). So
>> maybe Python on Illumos deserves some love?
>>
>> There are many ways to contribute to the Solaris support of Python:
>>
>> * Comment Solaris issues (bugs.python.org, search for "Solaris" in the
>> title)
>> * Propose PRs to fix issues or implement Solaris specific features
>> * Review Solaris PRs
>> * Provide Solaris servers accessible to Python core developers (SSH
>> access)
>> * Donate to the CPython project:
>>
>>   * https://www.python.org/psf/donations/python-dev/
>>   * https://github.com/sponsors/python
>>
>> * etc.
>>
>> See also the https://devguide.python.org/ if you would like to
>> contribute to Python.
>>
>> By the way, thanks Jakub Kulík (CC-ed to this email) who fixed
>> multiple Solaris issues in the last 2 years ;-)
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>>
> ___
> 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/732XMDFCTUNDP2GPFQWWUTLWBQFLLINR/
> 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/FNHHQRYM2F3WPMT45P3AS4KPTFRG5ZJT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Site Packages under LIB folder

[Ronald Oussoren via Python-Dev]

> On 30 Oct 2020, at 08:37, rajesh.narasim...@gmail.com wrote:
> 
> I have installed new python version 3.9, I wanted to move all the 
> site-packages that I have used in 3.8 to 3.9 lib.  Is it possible?  

This is not a list for support on Python, but a list on the development of the 
Python language. It would be better to ask on the Python-list list.

That said: In general it is not possible to move site-packages from one python 
versions to another. The primary reason is that C extensions are in general not 
compatible between versions.

> 
> I also wanted to know why we need to have lib under every specific version, 
> it would be nice if we have common lib in which I can configure those based 
> on the version I use.  Is that available already if not is that something we 
> can implement in future version this will  help most of the developers in not 
> moving the site-packages from one version to another every time we upgrade 
> the version.
There is a stable ABI that is currently used by a small subset of C extensions. 
A number of contributors are working on enhancing the APIs for the stable ABI 
to make it possible to use for more C extensions. That may lead to a future 
where it will be easier to share extensions between Python versions, but even 
then it may not be possible to just copy libraries to the new version because 
some libraries need changes to adjust for changes in the new version.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> 
> Regards
> 
> Rajesh Narasimhan
> ___
> 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/LVM5GZMAXIVKDZ2BM7SJXPCMZFED4KOO/
> 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/UB2NCXF24OZ2KIB4DIWDIJPZMGDNWHTR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Brandt Bucher]

> Can we discuss whether we want pattern matching in Python and the broader 
> semantics first, before dealing with low level details?

This is a huge step backward. These discussions have already taken place, over 
the last 10 years.

Here's just a sampling:

- 
https://mail.python.org/archives/list/python-id...@python.org/thread/IEJFUSFC5GBDKFIPCAGS7JYXV5WGVAXP/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/GTRRJHUG4W2LXGDH4AU46SI3DLWXJF6A/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/EURSG3MYEFHXDDL2474PQNQZFJ3CUIOX/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/NTQEL3HRUJMULQYI6RDBTXQ2H3KHBBRO/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/NEC54II2RB3JRGHDP6PX3NOEALRAK6BV/
- 
https://mail.python.org/archives/list/python-id...@python.org/thread/T3VBUFECTLZMB424MBBGUHCI24YA4FPT/

We read all of these and more back way in March, before we even started 
brainstorming syntax and semantics.

> Do we want a fancy switch statement, or a powerful expression?

It's right here that you lose me. Anyone who reduces pattern matching to "a 
fancy switch statement" probably isn't the right person to be discussing its 
semantics and usefulness with. It seems that some people just can't separate 
the two ideas in their mind. It's like calling a class a "fancy module".

It's okay that you feel that way, but hopefully you'll understand if people 
start to tune out messages that contain these sorts of comments.

> What special method(s) should be added?

None. PEP 622 originally added one, but even that is more than we need right 
now. Some people may need to register their mappings or sequences as Mappings 
or Sequences, but otherwise that's it.

> I would ask anyone who wants pattern matching adding to Python, to not 
> support PEP 634.

Seriously?

I would ask anyone who wants pattern matching added to Python to carefully 
consider the PEPs for themselves (particularly PEP 636, which is much less dry 
and contains more examples and commentary). We've written four of the largest, 
most detailed PEPs of any new feature I've seen, complete with a working 
implementation that we've made available from any browser. Of course it's not 
the *only* way of getting pattern matching... but if you want it, this is 
probably your *best* shot at getting it.

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Sebastian Wiedenroth]

Hi,

I've already commented on the issue, but want to make a few more points here as 
well.

Removing Solaris support would not only impact Oracle Solaris but the open 
source illumos community as well.
Both systems share the "SunOS" uname for historical reasons. Removing support 
would be a disaster for us.

We are a small community compared to Linux, but there are illumos distributions 
(OpenIndiana, OmniOS, SmartOS, Tribblix, ...) that have many python users.
It's also an essential part of our tooling and package management.

I've offered to host an illumos buildbot before but it was not accepted because 
not all tests passed at that time.
There is active work going on to get this debugged and fixed.
If it is acceptable to skip some tests we can have the buildbot online tomorrow.

On the ticket many users and developers have offered to step up, myself 
included.
In our IRC channel we also had some discussions yesterday and we're hoping to 
bring more patches upstream soon.

If there is interest in ssh access to illumos systems that is also something I 
can offer.

Please let us know if there is more we need to do to keep python on illumos 
supported.

Best regards,
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/UL4MQAKQZOIEEA2DHNJNB4BB4J3QR7FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Site Packages under LIB folder

[rajesh . narasimhan]

I have installed new python version 3.9, I wanted to move all the site-packages 
that I have used in 3.8 to 3.9 lib.  Is it possible?  

I also wanted to know why we need to have lib under every specific version, it 
would be nice if we have common lib in which I can configure those based on the 
version I use.  Is that available already if not is that something we can 
implement in future version this will  help most of the developers in not 
moving the site-packages from one version to another every time we upgrade the 
version.

Regards

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

[Python-Dev] Thoughts on PEP 634 (Structural Pattern Matching)

[Mark Shannon]

Hi everyone,

PEP 634/5/6 presents a possible implementation of pattern matching for 
Python.


Much of the discussion around PEP 634, and PEP 622 before it, seems to 
imply that PEP 634 is synonymous with pattern matching; that if you 
reject PEP 634 then you are rejecting pattern matching.


That simply isn't true.

Can we discuss whether we want pattern matching in Python and
the broader semantics first, before dealing with low level details?



Do we want pattern matching in Python at all?
-

Pattern matching works really well in statically typed, functional 
languages.


The lack of mutability, constrained scope and the ability of the 
compiler to distinguish let variables from constants means that pattern 
matching code has fewer errors, and can be compiled efficiently.


Pattern matching works less well in dynamically-typed, functional 
languages and statically-typed, procedural languages.
Nevertheless, it works well enough for it to be a popular feature in 
both erlang and rust.


In dynamically-typed, procedural languages, however, it is not clear (at 
least not to me) that it works well enough to be worthwhile.


That is not say that pattern matching could never be of value in Python, 
but PEP 635 fails to demonstrate that it can (although it does a better 
job than PEP 622).



Should match be an expression, or a statement?
--

Do we want a fancy switch statement, or a powerful expression?
Expressions have the advantage of not leaking (like comprehensions in 
Python 3), but statements are easier to work with.



Can pattern matching make it clear what is assigned?


Embedding the variables to be assigned into a pattern, makes the pattern 
concise, but requires discarding normal Python syntax and inventing a 
new sub-language. Could we make patterns fit Python better?


Is it possible to make assignment to variables clear, and unambiguous, 
and allow the use of symbolic constants at the same time?

I think it is, but PEP 634 fails to do this.


How should pattern matching be integrated with the object model?


What special method(s) should be added? How and when should they be called?
PEP 634 largely disregards the object model, meaning it has many special 
cases, and is inefficient.



The semantics must be well defined.
---

Language extensions PEPs should define the semantics of those 
extensions. For example, PEP 343 and PEP 380 both did.

https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement
https://www.python.org/dev/peps/pep-0380/#formal-semantics

PEP 634 just waves its hands and talks about undefined behavior, which 
horrifies me.



In summary,
I would ask anyone who wants pattern matching adding to Python, to not 
support PEP 634.

PEP 634 just isn't a good fit for Python, and we deserve something better.

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

[Python-Dev] Re: Improve CPython tracing performance

[Victor Stinner]

Le ven. 30 oct. 2020 à 11:02, Nick Coghlan  a écrit :
> > Ok, I've created https://bugs.python.org/issue42197 to track it.
>
> Please also have a look at PEP 558 and its draft reference
> implementation at https://github.com/python/cpython/pull/3640

I don't think that the PEP 558 and bpo-42197 are incompatible.

Debuggers and profilers usually only care of specific frames or
function calls (ex: 10% of function calls or even a single function
call in a whole application). The problem is how to make them as
efficient as possible for "no operation" calls, when they don't care
about the current frame. Avoiding PyFrame_FastToLocalsWithError() to
enter the debugger/profile and avoiding PyFrame_LocalsToFast() on exit
sounds a simple and practical solution.

By the way, I created https://bugs.python.org/issue40421 to prepare
the C API to make the PyFrameObject structure opaque. Once it will be
opaque, we will have more freedom on the API exposed to inspect frame
locals.

IMO it's a good idea to require function calls to inspect frame
locals, and not let developers think that PyFrameObject.f_locals is
always up-to-date and can always be modified.

I dislike PyFrame_FastToLocalsWithError() and PyFrame_LocalsToFast()
names. Maybe we should have an even more "explicit" API. Example
(without error handling):
---
// Implementation: Call PyFrame_FastToLocalsWithError() and returns
PyFrameObject.f_locals
locals = PyFrame_GetLocals();

// ... the debugger modifies some local variables in 'locals' dict ...

// Implementation: Set PyFrameObject.f_locals and call PyFrame_LocalsToFast()
PyFrame_SetLocals(locals);
---

The good news is that PyFrame_GetLocals() and PyFrame_SetLocals() can
easily be reimplemented in Python 3.9 for my compatibility header
file:
https://github.com/pythoncapi/pythoncapi_compat

Such API avoids a complex proxy and simply reuses a regular dict
object (exiting PyFrameObject.f_locals).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/65RHL2XKIYWMOCULGTI3HD3MSZSKVIBL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Victor Stinner]

Le ven. 30 oct. 2020 à 14:28, Ronald Oussoren  a écrit :
> Whoa, not so fast. I’m not volunteering work on Solaris support ;-).

Oh sorry, I misunderstood your message :-(


> That said, I’m willing to review Solaris PRs (time permitting) but cannot 
> test if changes actually work.

"Cannot test" is the kind of problem that I'm trying to point to. I
don't see how Python core developers can consider maintaining a
platform if they don't have access to it.


> P.S. Another platform to consider dropping is IRIX, I noticed in your PR that 
> there’s still some support for that platform in the code base and according 
> to wikipedia IRIX has been out of development for over 14 years 
> (https://en.wikipedia.org/wiki/IRIX).

IRIX support has been dropped in Python 2.3 (in 2003). I removed more
references to IRIX yesterday ;-)
https://github.com/python/cpython/commit/5776663675b48f011d428a5874cc3c79d1deb59e

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/7VIWRPYPQL5G6V7372ZVHA7B2CHGL3M6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Pablo Galindo Salgado]

>Two volunteer core developers and at least one buildbot would help a
> lot to ensure that Python is working on Solaris for real, and reduce
> the number of open Solaris issues. If it happens, I'm perfectly fine
> with keeping Solaris support.
> I also hope that more people will contribute to maintain the code, not
> only Ronald and Jesús. Many people wrote to me that Python is a key
> component of Illumos (the package manager is written in Python). So
> maybe Python on Illumos deserves some love?

If we decide to take the proposal seriously, I think it may be beneficial
to establish a deadline for having the buildbot green and the issues fixed,
so the promise of having "real" support at some point in the future does
actually manifest itself or it does not block following Victor's proposal
if it
actually does not happen.


On Fri, 30 Oct 2020 at 12:54, Victor Stinner  wrote:

> Hi Ronald,
>
> Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren  a
> écrit :
> > I agree. That’s what I tried to write, its not just providing a buildbot
> but also making sure that it keeps working and stays green.
>
> This is really great!
>
> Jesús Cea Avión is also a volunteer to maintain the Solaris (see the bpo).
>
> Moreover, it seems like some people would like to provide servers to
> run a Solaris buildbot. Example:
> https://bugs.python.org/issue42173#msg379895
>
> Two volunteer core developers and at least one buildbot would help a
> lot to ensure that Python is working on Solaris for real, and reduce
> the number of open Solaris issues. If it happens, I'm perfectly fine
> with keeping Solaris support.
>
> I also hope that more people will contribute to maintain the code, not
> only Ronald and Jesús. Many people wrote to me that Python is a key
> component of Illumos (the package manager is written in Python). So
> maybe Python on Illumos deserves some love?
>
> There are many ways to contribute to the Solaris support of Python:
>
> * Comment Solaris issues (bugs.python.org, search for "Solaris" in the
> title)
> * Propose PRs to fix issues or implement Solaris specific features
> * Review Solaris PRs
> * Provide Solaris servers accessible to Python core developers (SSH access)
> * Donate to the CPython project:
>
>   * https://www.python.org/psf/donations/python-dev/
>   * https://github.com/sponsors/python
>
> * etc.
>
> See also the https://devguide.python.org/ if you would like to
> contribute to Python.
>
> By the way, thanks Jakub Kulík (CC-ed to this email) who fixed
> multiple Solaris issues in the last 2 years ;-)
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
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/732XMDFCTUNDP2GPFQWWUTLWBQFLLINR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Ronald Oussoren via Python-Dev]

> On 30 Oct 2020, at 13:54, Victor Stinner  wrote:
> 
> Hi Ronald,
> 
> Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren  a 
> écrit :
>> I agree. That’s what I tried to write, its not just providing a buildbot but 
>> also making sure that it keeps working and stays green.
> 
> This is really great!

Whoa, not so fast. I’m not volunteering work on Solaris support ;-).  There is 
another user on BPO that works on Solaris stuff, see 
https://bugs.python.org/issue41839 .

I have worked with Solaris (and other “classic” UNIX systems) in the past, but 
haven’t do so in at least 15 years.  For me “cross-platform” means macOS, RHEL 
and Windows these days. 

That said, I’m willing to review Solaris PRs (time permitting) but cannot test 
if changes actually work.

[…]
> 
> By the way, thanks Jakub Kulík (CC-ed to this email) who fixed
> multiple Solaris issues in the last 2 years ;-)

That’s the BPO user I mentioned earlier :-)

P.S. Another platform to consider dropping is IRIX, I noticed in your PR that 
there’s still some support for that platform in the code base and according to 
wikipedia IRIX has been out of development for over 14 years 
(https://en.wikipedia.org/wiki/IRIX ).

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Victor Stinner]

Hi Ronald,

Le ven. 30 oct. 2020 à 12:59, Ronald Oussoren  a écrit :
> I agree. That’s what I tried to write, its not just providing a buildbot but 
> also making sure that it keeps working and stays green.

This is really great!

Jesús Cea Avión is also a volunteer to maintain the Solaris (see the bpo).

Moreover, it seems like some people would like to provide servers to
run a Solaris buildbot. Example:
https://bugs.python.org/issue42173#msg379895

Two volunteer core developers and at least one buildbot would help a
lot to ensure that Python is working on Solaris for real, and reduce
the number of open Solaris issues. If it happens, I'm perfectly fine
with keeping Solaris support.

I also hope that more people will contribute to maintain the code, not
only Ronald and Jesús. Many people wrote to me that Python is a key
component of Illumos (the package manager is written in Python). So
maybe Python on Illumos deserves some love?

There are many ways to contribute to the Solaris support of Python:

* Comment Solaris issues (bugs.python.org, search for "Solaris" in the title)
* Propose PRs to fix issues or implement Solaris specific features
* Review Solaris PRs
* Provide Solaris servers accessible to Python core developers (SSH access)
* Donate to the CPython project:

  * https://www.python.org/psf/donations/python-dev/
  * https://github.com/sponsors/python

* etc.

See also the https://devguide.python.org/ if you would like to
contribute to Python.

By the way, thanks Jakub Kulík (CC-ed to this email) who fixed
multiple Solaris issues in the last 2 years ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/NYWF4DUPFYZSKUUZ3ZHOSBQCWAF4IIQO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Ronald Oussoren via Python-Dev]

> On 30 Oct 2020, at 10:34, Pablo Galindo Salgado  wrote:
> 
> Regarding having a Solaris buildbot: if someone provides a Solaris buildbot 
> then the deal is that that someone or some other party must look after that 
> buildbot and fix problems that appear in it in a timely manner. Broken 
> buildbots stop releases and I don't want to be in a situation in which I need 
> to halt a release because the Solaris buildbot is broken and there is no-one 
> to fix it in time.
> 
> In the past, we had to dealt with similar situations and not only is 
> stressful but normally ends in me or Victor having to login in a buildbot for 
> a platform that we are not experts on to try to fix it in time.

I agree. That’s what I tried to write, its not just providing a buildbot but 
also making sure that it keeps working and stays green.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/ 

> 
> On Fri, 30 Oct 2020, 09:29 Ronald Oussoren via Python-Dev, 
> mailto:python-dev@python.org>> wrote:
> 
> > On 29 Oct 2020, at 22:43, Victor Stinner  > > wrote:
> > 
> > Hi,
> > 
> > I propose to drop the Solaris support in Python to reduce the Python
> > maintenance burden:
> > 
> >   https://bugs.python.org/issue42173 
> > 
> > I wrote a draft PR to show how much code could be removed (around 700
> > lines in 65 files):
> > 
> >   https://github.com/python/cpython/pull/23002/files 
> > 
> 
> A significant fraction of that is in comments and documentation. A number of 
> the changes in documentation would be good to go in regardless of the 
> resolution of this proposal.
> 
> > 
> > In 2016, I asked if we still wanted to maintain the Solaris support in
> > Python, because Solaris buildbots were failing for longer than 6
> > months and nobody was able to fix them. It was requested to find a
> > core developer volunteer to fix Solaris issues and to set up a Solaris
> > buildbot.
> > 
> > https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS
> >  
> > 
> > 
> > Four years later, nothing has happened. Moreover, in 2018, Oracle laid
> > off the Solaris development engineering staff. There are around 25
> > open Python bugs specific to Solaris.
> 
> As another data point: There is someone on BPO that files issues about 
> Solaris on BPO, including PRs. It might be worthwhile to ask that person if 
> they can provide a buildbot (while making clear that this results in the 
> assumption that they’d look after Solaris port).
> 
> If Solaris would get dropped I’d prefer option 2
> 
> Ronald
> —
> 
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/ 
> 
> 
> ___
> 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/XFRQ2VEBK6NKUWMC6HXOJDLAIOQHORCP/
>  
> 
> 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/A7Q7GW7ZI2EZDQSVYRCOI3S45MCS4WRZ/
> 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/DUKMN44S6GCC3N3XHNAQRD4GXZV3PSUP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Antoine Pitrou]

On Fri, 30 Oct 2020 09:34:37 +
Pablo Galindo Salgado  wrote:
> Regarding having a Solaris buildbot: if someone provides a Solaris buildbot
> then the deal is that that someone or some other party must look after that
> buildbot and fix problems that appear in it in a timely manner. Broken
> buildbots stop releases and I don't want to be in a situation in which I
> need to halt a release because the Solaris buildbot is broken and there is
> no-one to fix it in time.
> 
> In the past, we had to dealt with similar situations and not only is
> stressful but normally ends in me or Victor having to login in a buildbot
> for a platform that we are not experts on to try to fix it in time.

Seconded.  Someone providing a buildbot for a fringe platform should
also watch after regressions and be ready to submit patches when
problems arise.

Regards

Antoine.

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

[Python-Dev] Re: Improve CPython tracing performance

[Nick Coghlan]

On Fri, 30 Oct 2020 at 20:52, Fabio Zadrozny  wrote:
> On Fri, Oct 30, 2020 at 7:02 AM Nick Coghlan  wrote:
> As a note, the current implementation does allow debuggers to mutate frame 
> locals -- as long as they understand that they need to call ` 
> PyFrame_LocalsToFast ` when doing such a change -- potentially using ctypes 
> (I'm just mentioning this because PEP 558 seems to imply this isn't possible).

If that's referring to the sentence that ends with ".. without even
reliably enabling the desired functionality of allowing debuggers like
pdb to mutate local variables.", the critical word there is
"reliably".

The existing API and implementation does allow you to change local
variables from trace functions (especially if you use ctypes to access
the C API rather than sticking solely to the Python level API), it
just also messes up your application state sometimes.

> i.e.: Debuggers already *must* call ` PyFrame_LocalsToFast ` if locals from a 
> frame which is not the current frame are being mutated, so, as far as I can 
> see a debugger is already broken if it isn't doing that -- some years ago I 
> even thought about exposing it in the frame API: 
> https://bugs.python.org/issue1654367, but in the end accessing it through the 
> C-API through ctypes does get the job done, debugger authors just need to be 
> aware of it -- PyPy also has a counterpart mentioned in that issue.

It isn't primarily debuggers that are a concern for backwards
compatibility, it's trace functions manipulating the state of the
frame being traced. In the current implementation, that feature relies
on those FastToLocals and LocalsToFast conversion calls to work.

> I agree that having f_locals be a proxy that does everything transparently 
> would be better, but unfortunately I don't currently have the time available 
> to help there... in your opinion, just removing those calls as I proposed 
> (requiring that debuggers call `PyFrame_LocalsToFast`) would be acceptable? 
> If you think it is, I'll proceed on creating the PEP, otherwise I'll probably 
> just drop it until f_locals becomes a proxy (in which case I'd expect the 
> `PyFrame_FastToLocalsWithError` and  `PyFrame_LocalsToFast` to be removed in 
> the same commit which converts f_locals to a proxy).

Checking the PR branch, the write-through proxy meant I was able to
get rid of the call to PyFrame_LocalsToFast, but I couldn't get rid of
the implicit snapshot refresh due to C API compatibility concerns:
https://github.com/python/cpython/pull/3640/files#diff-a3a5c73931235f7f344c072dc755d6508e13923db3f5d581c5e88652075871cb

Assuming the PEP is eventually accepted, though, then it would be
reasonable to subsequently deprecate that implicit refresh, and say
that any trace function calling such APIs needs to make its own call
to PyLocals_RefreshViews() first.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/JS7NEH4KS5CX3PHO6RVYPHJPRWBVWLRW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improve CPython tracing performance

[Fabio Zadrozny]

On Fri, Oct 30, 2020 at 7:02 AM Nick Coghlan  wrote:

> On Fri, 30 Oct 2020 at 00:19, Fabio Zadrozny  wrote:
> > On Thu, Oct 29, 2020 at 9:45 AM Victor Stinner 
> wrote:
> >>
> >> > If it's non controversial, is a PEP needed or just an issue to track
> it would be enough to remove those 2 lines?
> >>
> >> Incompatible changes should be well documented in What's New in Python
> >> 3.10. In this case, I don't think that a deprecation period is needed.
> >>
> >> Just open an issue. Please post the URL to your issue in reply to your
> >> email. It's even better if you can write a PR to implement your idea
> >> ;-)
>
> Removing those calls would require a PEP, as it would break all sorts
> of tools in cases that currently work correctly.
>
> > Ok, I've created https://bugs.python.org/issue42197 to track it.
>
> Please also have a look at PEP 558 and its draft reference
> implementation at https://github.com/python/cpython/pull/3640
>
> The way these trampoline calls currently work isn't just slow, it's
> actually broken in various ways, and changing them to use a
> write-through proxy instead of a dict-based snapshot means that the
> cost of producing those dict-based snapshots simply because tracing is
> turned on will go away.
>
> The PEP itself didn't seem to be particularly controversial (at least
> in its current form - earlier versions drew more objections), but
> there's a bunch of preparatory work that needs to be done before it
> could seriously be submitted for final review (specifically: the
> write-through proxy isn't actually implementing the full mutable
> mapping API. In order for it to do that without excessive code
> duplication, the helper functions already written for ordered
> dictionaries needed to moved out to a separate linkable module so that
> the new write-through proxy can reuse them without taking a separate
> copy of them)
>
>
Hi Nick!

As a note, the current implementation does allow debuggers to mutate frame
locals -- as long as they understand that they need to call `
PyFrame_LocalsToFast ` when doing such a change -- potentially using ctypes
(I'm just mentioning this because PEP 558 seems to imply this isn't
possible).

i.e.: Debuggers already *must* call ` PyFrame_LocalsToFast ` if locals from
a frame which is not the current frame are being mutated, so, as far as I
can see a debugger is already broken if it isn't doing that -- some years
ago I even thought about exposing it in the frame API:
https://bugs.python.org/issue1654367, but in the end accessing it through
the C-API through ctypes does get the job done, debugger authors just need
to be aware of it -- PyPy also has a counterpart mentioned in that issue.

I agree that having f_locals be a proxy that does everything transparently
would be better, but unfortunately I don't currently have the time
available to help there... in your opinion, just removing those calls as I
proposed (requiring that debuggers call `PyFrame_LocalsToFast`) would be
acceptable? If you think it is, I'll proceed on creating the PEP, otherwise
I'll probably just drop it until f_locals becomes a proxy (in which case
I'd expect the `PyFrame_FastToLocalsWithError` and  `PyFrame_LocalsToFast`
to be removed in the same commit which converts f_locals to a proxy).

Cheers,

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

[Python-Dev] Re: Improve CPython tracing performance

[Nick Coghlan]

On Fri, 30 Oct 2020 at 00:19, Fabio Zadrozny  wrote:
> On Thu, Oct 29, 2020 at 9:45 AM Victor Stinner  wrote:
>>
>> > If it's non controversial, is a PEP needed or just an issue to track it 
>> > would be enough to remove those 2 lines?
>>
>> Incompatible changes should be well documented in What's New in Python
>> 3.10. In this case, I don't think that a deprecation period is needed.
>>
>> Just open an issue. Please post the URL to your issue in reply to your
>> email. It's even better if you can write a PR to implement your idea
>> ;-)

Removing those calls would require a PEP, as it would break all sorts
of tools in cases that currently work correctly.

> Ok, I've created https://bugs.python.org/issue42197 to track it.

Please also have a look at PEP 558 and its draft reference
implementation at https://github.com/python/cpython/pull/3640

The way these trampoline calls currently work isn't just slow, it's
actually broken in various ways, and changing them to use a
write-through proxy instead of a dict-based snapshot means that the
cost of producing those dict-based snapshots simply because tracing is
turned on will go away.

The PEP itself didn't seem to be particularly controversial (at least
in its current form - earlier versions drew more objections), but
there's a bunch of preparatory work that needs to be done before it
could seriously be submitted for final review (specifically: the
write-through proxy isn't actually implementing the full mutable
mapping API. In order for it to do that without excessive code
duplication, the helper functions already written for ordered
dictionaries needed to moved out to a separate linkable module so that
the new write-through proxy can reuse them without taking a separate
copy of them)

Cheers,
Nick.

P.S. If that sounds like a request for help, that's because it is ;)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/RGP4UJFWUML6LQQPB4RALTBOXEHOEMHE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Pablo Galindo Salgado]

Regarding having a Solaris buildbot: if someone provides a Solaris buildbot
then the deal is that that someone or some other party must look after that
buildbot and fix problems that appear in it in a timely manner. Broken
buildbots stop releases and I don't want to be in a situation in which I
need to halt a release because the Solaris buildbot is broken and there is
no-one to fix it in time.

In the past, we had to dealt with similar situations and not only is
stressful but normally ends in me or Victor having to login in a buildbot
for a platform that we are not experts on to try to fix it in time.

On Fri, 30 Oct 2020, 09:29 Ronald Oussoren via Python-Dev, <
python-dev@python.org> wrote:

>
> > On 29 Oct 2020, at 22:43, Victor Stinner  wrote:
> >
> > Hi,
> >
> > I propose to drop the Solaris support in Python to reduce the Python
> > maintenance burden:
> >
> >   https://bugs.python.org/issue42173
> >
> > I wrote a draft PR to show how much code could be removed (around 700
> > lines in 65 files):
> >
> >   https://github.com/python/cpython/pull/23002/files
>
> A significant fraction of that is in comments and documentation. A number
> of the changes in documentation would be good to go in regardless of the
> resolution of this proposal.
>
> >
> > In 2016, I asked if we still wanted to maintain the Solaris support in
> > Python, because Solaris buildbots were failing for longer than 6
> > months and nobody was able to fix them. It was requested to find a
> > core developer volunteer to fix Solaris issues and to set up a Solaris
> > buildbot.
> >
> >
> https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS
> >
> > Four years later, nothing has happened. Moreover, in 2018, Oracle laid
> > off the Solaris development engineering staff. There are around 25
> > open Python bugs specific to Solaris.
>
> As another data point: There is someone on BPO that files issues about
> Solaris on BPO, including PRs. It might be worthwhile to ask that person if
> they can provide a buildbot (while making clear that this results in the
> assumption that they’d look after Solaris port).
>
> If Solaris would get dropped I’d prefer option 2
>
> Ronald
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>
> ___
> 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/XFRQ2VEBK6NKUWMC6HXOJDLAIOQHORCP/
> 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/A7Q7GW7ZI2EZDQSVYRCOI3S45MCS4WRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Ronald Oussoren via Python-Dev]

> On 29 Oct 2020, at 22:43, Victor Stinner  wrote:
> 
> Hi,
> 
> I propose to drop the Solaris support in Python to reduce the Python
> maintenance burden:
> 
>   https://bugs.python.org/issue42173
> 
> I wrote a draft PR to show how much code could be removed (around 700
> lines in 65 files):
> 
>   https://github.com/python/cpython/pull/23002/files

A significant fraction of that is in comments and documentation. A number of 
the changes in documentation would be good to go in regardless of the 
resolution of this proposal.

> 
> In 2016, I asked if we still wanted to maintain the Solaris support in
> Python, because Solaris buildbots were failing for longer than 6
> months and nobody was able to fix them. It was requested to find a
> core developer volunteer to fix Solaris issues and to set up a Solaris
> buildbot.
> 
> https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS
> 
> Four years later, nothing has happened. Moreover, in 2018, Oracle laid
> off the Solaris development engineering staff. There are around 25
> open Python bugs specific to Solaris.

As another data point: There is someone on BPO that files issues about Solaris 
on BPO, including PRs. It might be worthwhile to ask that person if they can 
provide a buildbot (while making clear that this results in the assumption that 
they’d look after Solaris port).

If Solaris would get dropped I’d prefer option 2

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/


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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Christian Heimes]

On 30/10/2020 08.58, Serhiy Storchaka wrote:
> It would make life of Illumos and OpenIndiana developers much harder,
> that can be seen hostile to open source community. It would make the
> code of CPython more rigid, virtually Linux-only with Windows and MacOS
> patches, and as a side effect can make harder porting it to other
> platforms. This is not great.
> 
> If you want to remove platform specific code from CPython source, do you
> consider the idea of removing support of MacOS and maintain it as
> "downstream patches"?

That's an unfair and polarizing comparison. You know as good as I that
macOS is a major platform which is actively used and maintained by
several core developers. I don't recall any core devs that maintain
Solaris port.

PEP-11 lists clear rules about platform support. As long as we don't
have a core developer for Solaris support and stable build bots, I'm all
in favor to remove the platforms.

Christian

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Serhiy Storchaka]

29.10.20 23:43, Victor Stinner пише:
> * Current best effort support (no change): changes only happen if a
> core dev volunteers to review and merge a change written by a
> contributor.

It is my preference.

Several years ago I tested and fixed Python on OpenIndiana in virtual
machine, but I was not enough motivated and the code gradually degrades.

> * Schedule the removal in 2 Python releases (Python 3.12) and start to
> announce that Solaris support is going to be removed
> 
> * Remove the Solaris code right now (my proposition): Solaris code
> will have to be maintained outside the official Python code base, as
> "downstream patches"

It would make life of Illumos and OpenIndiana developers much harder,
that can be seen hostile to open source community. It would make the
code of CPython more rigid, virtually Linux-only with Windows and MacOS
patches, and as a side effect can make harder porting it to other
platforms. This is not great.

If you want to remove platform specific code from CPython source, do you
consider the idea of removing support of MacOS and maintain it as
"downstream patches"?
___
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/WKCE33CIVYFQCSHBUI3W23DT5PKE3ZRF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Kyle Stanley]

+1 to remove support for Solaris going forward. 4 years is plenty of time
to wait for someone to volunteer to maintain it, IMO. So my preference
would be for option 3 to remove it now, but I wouldn't be opposed to option
2 either w/ deprecating support and waiting a couple versions to remove it.
I'm only opposed to option 1, since it seems very likely that it will just
continue to stagnate at this point.

On Thu, Oct 29, 2020 at 5:49 PM Victor Stinner  wrote:

> Hi,
>
> I propose to drop the Solaris support in Python to reduce the Python
> maintenance burden:
>
>https://bugs.python.org/issue42173
>
> I wrote a draft PR to show how much code could be removed (around 700
> lines in 65 files):
>
>https://github.com/python/cpython/pull/23002/files
>
> In 2016, I asked if we still wanted to maintain the Solaris support in
> Python, because Solaris buildbots were failing for longer than 6
> months and nobody was able to fix them. It was requested to find a
> core developer volunteer to fix Solaris issues and to set up a Solaris
> buildbot.
>
>
> https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS
>
> Four years later, nothing has happened. Moreover, in 2018, Oracle laid
> off the Solaris development engineering staff. There are around 25
> open Python bugs specific to Solaris.
>
> I see 3 options:
>
> * Current best effort support (no change): changes only happen if a
> core dev volunteers to review and merge a change written by a
> contributor.
>
> * Schedule the removal in 2 Python releases (Python 3.12) and start to
> announce that Solaris support is going to be removed
>
> * Remove the Solaris code right now (my proposition): Solaris code
> will have to be maintained outside the official Python code base, as
> "downstream patches"
>
>
> Solaris has a few specific features visible at the Python level:
> select.devpoll, os.stat().st_fstype and stat.S_ISDOOR().
>
> While it's unclear to me if Oracle still actively maintains Solaris
> (latest release in 2018, no major update since 2018), Illumos and
> OpenSolaris (variants or "forks") still seem to be active.
>
> In 2019, a Solaris blog post explains that Solaris 11.4 still uses
> Python 2.7 but plans to migrate to Python 3, and Python 3.4 is also
> available. These two Python versions are no longer supported.
>
> https://blogs.oracle.com/solaris/future-of-python-on-solaris
>
> The question is if the Python project has to maintain the Solaris
> specific code or if this code should now be maintained outside Python.
>
> What do you think? Should we wait 5 more years? Should we expect a
> company will offer to maintain the Solaris support? Is there a
> motivated core developer to fix Solaris issue? As I wrote, nothing has
> happened in the last 4 years...
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/
> 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/N3CQPEPNENRC6L7NIALN3JGA3O33UDD3/
Code of Conduct: http://python.org/psf/codeofconduct/