[Python-Dev] Re: macOS issues with 3.8.7rc1
> On 9 Dec 2020, at 19:59, Steve Holden wrote: > > A general wish not to disadvantage those with older hardware any more than > they already are? > > Just a shot in the dark. > > > On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith wrote: > > > As a meta question: Is there a good reason to support binaries running on > macOS earlier than ~ $latest_version-1? > > Aren't systems running those old releases rather than upgrading unsupported > by Apple, never to be patched, and thus not wise to even have on a network? > > Yes, that means some very old hardware becomes useless as Apple drops > support. But that is what people signed up for when they bought it. Why > should that be our problem? > > (It sounds like y'all will make it work, that's great! I'm really just > wondering where the motivation comes from) > > -gps > > On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc wrote: > On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren wrote: > > >> On 8 Dec 2020, at 19:59, Gregory Szorc wrote: >> >> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding >> macOS. >> >> Without the changes from https://github.com/python/cpython/pull/22855 >> backported, attempting to build a portable binary on macOS 11 (e.g. by >> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: >> 'XXX' is only available on macOS 10.13 or newer >> [-Wunguarded-availability-new]` warnings during the build. This warning >> could be innocuous if there is run-time probing in place (the symbols in >> question are weakly linked, which is good). But if I'm reading the code >> correctly, run-time probing was introduced by commits like eee543722 and >> isn't present in 3.8.7rc1. >> >> I don't have a machine with older macOS sitting around to test, but I'm >> fairly certain the lack of these patches means binaries built on macOS 11 >> will blow up at run-time when run on older macOS versions. >> >> These same patches also taught CPython to build and run properly on Apple >> ARM hardware. I suspect some people will care about these being backported >> to 3.8. >> > We know. Backporting the relevant changes to 3.8 is taking more time than I > had hoped. It doesn’t help that I’ve been busy at work and don’t have as much > energy during the weekend as I’d like. > > The backport to 3.9 was fairly easy because there were few changes between > master and the 3.9 branch at the time. Sadly there have been conflicting > changes since 3.8 was forked (in particular in posixmodule.c). > > The current best practice for building binaries that work on macOS 10.9 is to > build on that release (or rather, with that SDK). That doesn’t help if you > want to build Universal 2 binaries though. > > Thank you for your hard work devising the patches and working to backport > them. > > I personally care a lot about these patches and I have the technical > competency to perform the backport. If you need help, I could potentially > find time to hack on it. Just email me privately (or ping @indygreg on > GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely > cherry pick the patches for > https://github.com/indygreg/python-build-standalone. And I'm sure other > downstream packagers will want them as well. So having them in an unreleased > 3.8 branch is better than not having them at all. > ___ > 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/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/ > 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/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/ > 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/7ZSZVIVUVM35GELRKGXWAJ3HLYU6G6OJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ I wouldn’t be surprised if there’s a group of people that won’t ever upgrade to 10.15+ for variety of reasons (including loss of 32-bit application support) so there’s also that. Jakub ___ 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-d
[Python-Dev] Re: Signature discrepancies between documentation and implementation
> On 9 Feb 2021, at 11:22, Erlend Aasland wrote: > > Hi all, > > What's the recommended approach with issues like > https://bugs.python.org/issue43094? Change the docs or the implementation? I > did a quick search on bpo, but could not find similar past issues. > > > > Erlend To provide some context as you looked for issues on bpo: in the two I was involved in[1][2] the resolution was to update the documenttion to reflect the actual situation. Best, Jakub [1] https://bugs.python.org/issue42230 [2] https://bugs.python.org/issue38580 ___ 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/FHWE3YHZNZE7QRTSH5FA4Z7A2LQUBROB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Merge Request Review Reminder
> On 20 Mar 2021, at 04:39, Guido van Rossum wrote: > > Honestly this is an example of a module that would have been better off > outside the stdlib. > > On Fri, Mar 19, 2021 at 14:43 Senthil Kumaran wrote: > On Mon, Feb 15, 2021 at 8:36 AM Faisal Mahmood > wrote: > > > > Hello, > > > > I hope you are all well, I currently have an issue / merge request that has > > become stale and as per the guidelines I am sending this e-mail to request > > someone to review it for me please. > > > > Issue Number: 42861 (https://bugs.python.org/issue42861) > > Pull Request: 24180 (https://github.com/python/cpython/pull/24180) > > > > Could you share some motivation references that could help explain why > this next_network method will be helpful? Is this common enough to > warrant a method in the stdlib IP-Address module? > If there is prior-art in other external libraries or libraries of > other languages, that will be helpful to know and review too. > > I had looked at this a month ago when you pinged for review, but I > could not immediately determine the benefit of having this method in > stdlib, irrespective of implementation correctness or API Signature. > I also lack extensive experience with ipv6. > > Thanks, > Senthil I don’t know if this is gonna support Faisal’s cause (“It’s used in a third party library in the wild, that means stdlib could use it!”) or the exact opposite (“it’s provided by a third party library, so may as well use third party library and stdlib doesn’t necessarily need this”) but the quite popular netaddr library that I’m a maintainer of does have IPNetwork.next() and IPNetwork.previous() methods[1][2]. The main difference is that in netaddr: * next() and previous() can produce networks arbitrary number of steps away, not just the first closest network forwards or backwards * going from a network to its supernetwork or subnetwork is done through a separate set of supernet() and subnet() methods[3][4] I can’t say how many library users actually consume this particular section of the API, of course, but I expect this API to be used and it seems rather useful. Best, Jakub [1] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.next [2] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.previous [3] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.subnet [4] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.supernet ___ 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/NN2OTO7Z4326CL5T3SLJQDZBRKZXOIPG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Merge Request Review Reminder
> On 22 Mar 2021, at 13:07, Faisal Mahmood wrote:
>
> Thanks Jakub, I wasn't aware of the netaddr library but just gave it a play
> and it does seem very similar and I think it's very useful and completely
> valid.
>
> I think the subtle difference is also that my implementation allows you to
> specify the next prefix as well, so it won't just find the next prefix of the
> same size. This is a common use case when you are trying to find free
> address spaces, you will need to look for networks of different sizes
> depending on what you are doing.
>
> Currently, you could say that you were given a network of 10.200.20.0/24 and
> asked to split this network into a bunch of /26 networks, you can do this
> easily using the subnets method:
> >>> list(IPv4Network("10.200.20.0/24").subnets(prefixlen_diff=2))
> [IPv4Network('10.200.20.0/26'), IPv4Network('10.200.20.64/26'),
> IPv4Network('10.200.20.128/26'), IPv4Network('10.200.20.192/26')]
>
> That is very simple and effective, but not a very realistic example of how
> you would split networks up. Given how limited the IPv4 address space is,
> normally you may have to use that /24 block for multiple things, so can't
> just simply split it up into /26's, you may need to instead get two /30's,
> one /27 and one /25. Currently, I don't think there is any straightforward
> way to do this without a 'next_network' method that I have implemented.
>
> Example, given a network of 10.200.20.0/24, to get two /30's out of it, one
> /27 and one /25, I would do the following with my method:
> >>> first_network = IPv4Network("10.200.20.0/30")
> # first_network = IPv4Network("10.200.20.0/30")
>
> Then get the next one (note not specifying prefix just gives me another /30 -
> i.e. same prefix size):
> >>> second_network = first_network.next_network()
> # second_network = IPv4Network("10.200.20.4/30")
>
> Then I would need to get the /27, so do this:
> >>> third_network = second_network.next_network(new_prefixlen=27)
> # third_network = IPv4Network("10.200.20.32/27)
>
> Finally the /25:
> >>> fourth_network = third_network.next_network(new_prefixlen=25)
> # fourth_network = IPv4Network("10.200.20.128/25)
>
> When you are dealing with the same prefix size for each new network, I think
> it's just a simple case of adding 1 to the broadcast address each time, but
> when you have different prefix sizes it's a bit more complicated.
>
> On Sat, 20 Mar 2021 at 22:04, Jakub Stasiak wrote:
>
>
>
> I don’t know if this is gonna support Faisal’s cause (“It’s used in a third
> party library in the wild, that means stdlib could use it!”) or the exact
> opposite (“it’s provided by a third party library, so may as well use third
> party library and stdlib doesn’t necessarily need this”) but the quite
> popular netaddr library that I’m a maintainer of does have IPNetwork.next()
> and IPNetwork.previous() methods[1][2]. The main difference is that in
> netaddr:
>
> * next() and previous() can produce networks arbitrary number of steps away,
> not just the first closest network forwards or backwards
> * going from a network to its supernetwork or subnetwork is done through a
> separate set of supernet() and subnet() methods[3][4]
>
> I can’t say how many library users actually consume this particular section
> of the API, of course, but I expect this API to be used and it seems rather
> useful.
>
> Best,
> Jakub
>
> [1] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.next
> [2]
> https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.previous
> [3] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.subnet
> [4]
> https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.supernet
Thank you for the explanation – now I understand better how that prefix
parameter is useful.
It’s not *that* difficult to emulate this using netaddr, there’s an extra
switch-to-supernet or switch-to-subnet step but that’s about it:
>>> from netaddr import IPNetwork
>>> first_network = IPNetwork("10.200.20.0/30")
>>> second_network = first_network.next()
>>> second_network
IPNetwork('10.200.20.4/30')
>>> third_network = second_network.supernet(27)[0].next()
>>> third_network
IPNetwork('10.200.20.32/27')
>>> fourth_network = third_network.supernet(25)[0].next()
>>> fourth_network
IPNetwork('10.200.20.128/25’)
That said, if merging this into the Python stdlib doesn’t work out I’m open to
improving netaddr’s interface to better serve this use case.
Best wishes,
Jakub
___
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/NA422HQIN232FSCHSO3QQMGOPVZ4QM6W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
> On 24 Jun 2020, at 17:57, mi...@drach.uk wrote: > > To me match also sound confusing as a keyword. You don't match things to > cases in English. > Maybe match x: against 1? https://idioms.thefreedictionary.com/match+against > > match point: >against (x, 1): >... >against (1, y): >... > > Better yet it feels to me to have: > > > handle point: >as (x, 1): >... >as (1, y): >... >as None: >... > ___ > 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/LGPOSO6L2GUFMR2RZ6YMAECGG4TMPIZD/ > Code of Conduct: http://python.org/psf/codeofconduct/ I think the match/case terminology is so common in this area that introducing different names for this would be counterproductive. ___ 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/4AEQ47MONYJSG6OEMDN4GGW6UOL6Q6YX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
> On 24 Jun 2020, at 19:14, Guido van Rossum wrote:
>
> (Jakub, next time please trim the original post from your quote to what's
> necessary.)
>
Apologies, unintentional, I was replying from the web interface since I wasn’t
subscribed to this gorup when the thread was started and I clicked some wrong
buttons.
>
> So, now for the one thing that makes me unhappy: the rejected idea to make it
> an expression. In my short experience with pattern matching, mainly in Rust,
> roughly half (very vague estimate) of its usefulness came from it being an
> expression. It's even small things like
>
> let i = match i {
> 9 => 10,
> 10 => 9,
> _ => i,
> };
>
> and
>
> let mut file: Box = match filename.as_ref() {
> "-" => Box::new(io::stdout()),
> _ => Box::new(File::create(filename).expect("Cannot open file for
> writing")),
> };
>
> and it adds up. I'm not sure how to approach this with Python syntax and I'll
> think about this, but I feel that it'd be a huge missed opportunity to not
> have this.
>
> We considered it, but it simply doesn't work, for the same reason that we
> haven't been able to find a suitable multi-line lambda expression. Since
> Python fundamentally is not an expression language, this is no great loss --
> you simply write a match statement that assigns a value to the variable in
> each branch. Alternatively, the match could be inside a function and each
> block could return a value.
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
That’s fair, but there’s a way in which this doesn’t have to be equivalent to
multi-line lambda expressions. Granted, I should’ve clarified that I thought
about it being an expression in a very limited, special way.
Let’s take one example from the PEP text:
match greeting:
case "":
print("Hello!")
case name:
print(f"Hi {name}!”)
Let’s say we allow prepending “match …” with an assignment and the value of the
assignment is the value of the last statement/expression in the block that’s
selected, this allows for the following hypothetical code:
message = match greeting:
case "":
"Hello!"
case name:
f"Hi {name}!”
So I didn’t express this clearly – it’s not a bout full-blown match expressions
but rather an optional "assigning form” of match statements. This seems like it
wouldn’t affect parsing massively.
Jakub
___
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/5EDYHAPP7CTBXQD5LQFR4A25BVTC3BZN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
> On 9 Jul 2020, at 17:49, Federico Salerno wrote: > > On 09/07/2020 01:27, Ethan Furman wrote: >> On 07/08/2020 10:44 AM, Ethan Furman wrote: >> >>> So namespaced variables only... is there a recommendation on handling >>> global() and local() type variables? >> >> Okay, some off-list discussion clarified that for me: >> >> - easiest way is to use a guard >> >> >>> ``` >>> def foo(x, spam): >>> match x: >>> case Point(p, q, context=c) if c == spam: >>> # Match >>> ``` > I like this one. Doesn't it also solve the issue of store vs. load? > Everything is stored but the guard clause can look-up. I have to say I find this to be the most satisfactory solution – everything else (dot previously, no dot now, any other single character hypotheticaly) provides users with IMO too big of a footgun to shoot themselves with. Jakub ___ 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/NXHOLMMS23GLN5QR6BQOHT6ABTI4IOIW/ Code of Conduct: http://python.org/psf/codeofconduct/
