[Python-Dev] Re: PEP 622: Structural Pattern Matching

[jakub]

   print("Not a point")
> 
> We can use keyword parameters too.  The following patterns are all
> equivalent (and all bind the y attribute to the var
> variable):
> Point(1, var)
> Point(1, y=var)
> Point(x=1, y=var)
> Point(y=var, x=1)
> 
> Patterns can be arbitrarily nested.  For example, if we have a short
> list of points, we could match it like this:
> match points:
> case []:
> print("No points")
> case [Point(0, 0)]:
> print("The origin")
> case [Point(x, y)]:
> print(f"Single point {x}, {y}")
> case [Point(0, y1), Point(0, y2)]:
> print(f"Two on the Y axis at {y1}, {y2}")
> case _:
> print("Something else")
> 
> We can add an if clause to a pattern, known as a "guard".  If the
> guard is false, match goes on to try the next case block.  Note
> that variable extraction happens before the guard is evaluated:
> match point:
> case Point(x, y) if x == y:
> print(f"Y=X at {x}")
> case Point(x, y):
> print(f"Not on the diagonal")
> 
> Several other key features:
> 
> Like unpacking assignments, tuple and list patterns have exactly the
> same meaning and actually match arbitrary sequences.  An important
> exception is that they don't match iterators or strings.
> (Technically, the target must be an instance of
> collections.abc.Sequence.)
> 
> Sequence patterns support wildcards: [x, y, *rest] and (x, y,
> *rest) work similar to wildcards in unpacking assignments.  The
> name after * may also be _, so (x, y, *_) matches a
> sequence
> of at least two items without binding the remaining items.
> 
> Mapping patterns: {"bandwidth": b, "latency": l} extracts the
> "bandwidth" and "latency" values from a dict.  Unlike sequence
> patterns, extra keys are ignored.  A wildcard **rest is also
> supported.  (But **_ would be redundant, so it not allowed.)
> 
> Subpatterns may be extracted using the walrus (:=) operator:
> case (Point(x1, y1), p2 := Point(x2, y2)): ...
> 
> 
> Patterns may use named constants.  These must be dotted names; a
> single name can be made into a constant value by prefixing it with a
> dot to prevent it from being interpreted as a variable extraction:
> RED, GREEN, BLUE = 0, 1, 2
> 
> match color:
> case .RED:
> print("I see red!")
> case .GREEN:
> print("Grass is green")
> case .BLUE:
> print("I'm feeling the blues :(")
> 
> 
> Classes can customize how they are matched by defining a
> __match__() method.
> Read the PEP
> for details.

Wow, I totally didn't see this coming, not after seeing what seems like a lot 
of rejected ideas on this topic (there was at least one PEP already that 
proposed this, right?). I have to admire the authors' determination to write 
such a lengthy and (from skimming it) complex and comprehensive proposal *and* 
providing a reference implementation on top of that, the amount of work 
(including internal bikeshedding) must've been substantial.

Needless to say it's +1 from my humble person, big time, and I wouldn't want 
the comment below to detract from that.

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.

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

Re: [Python-Dev] SK-CSIRT identified malicious software libraries in the official Python package repository, PyPI

[Jakub Wilk]

* Victor Stinner , 2017-09-15, 23:08:

Why not just reserving the name but don't provide any download file?


Is is possible at the moment?
I tried "python setup.py register", but all I got was:

Server response (410): Project pre-registration is no longer required or 
supported, so continue directly to uploading files.

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

[Jakub Wilk]

* Guido van Rossum , 2017-10-27, 08:35:
The "why" question is not very interesting -- it probably wasn't in 
PCRE and nobody was familiar with it when we moved off PCRE (maybe it 
wasn't even in Perl at the time -- it was ~15 years ago).


Perl supports \G since v5.0, released in 1994.
PCRE supports it since v4.0, released in 2003.

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

[Jakub Wilk]

* Guido van Rossum , 2017-10-28, 14:05:
even if we outright switched there would *still* be two versions, 
because regex itself has an internal versioning scheme where V0 claims 
to be strictly compatible with re and V1 explicitly changes the 
matching rules in some cases. (I don't know if this means that you have 
to request V1 to use \G though.)


No, \G is available in the V0 mode.

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Jakub Wilk]

* Barry Warsaw , 2017-11-06, 15:56:
We also depend on ldap3 <https://pypi.org/project/ldap3/>. Suddenly we 
get a SyntaxError because ldap3 has a module ldap3/strategy/async.py. 
I say "suddenly" because of course *if* DeprecationWarnings had been 
enabled by default, I'm sure someone would have noticed that those 
imports were telling the developers about the impending problem in 
Python 3.6.


https://github.com/cannatag/ldap3/issues/428


"import async" would indeed cause deprecation warning, but that's not 
what ldap3 does. The only uses of the now-keyword "async" in their 
codebase are like this:


  from ..strategy.async import AsyncStrategy
  from .async import AsyncStrategy

These do not provoke deprecation warnings from Python 3.6. (They 
probably should!)


I'm afraid that showing deprecation warnings by default wouldn't have 
helped in this particular case.


--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)

[Jakub Wilk]

* Nick Coghlan , 2017-12-06, 16:15:
Something I've just noticed that needs to be clarified: on Linux, "C" 
locale and "POSIX" locale are aliases, but this isn't true in general 
(e.g. it's not the case on *BSD systems, including Mac OS X).
For those of us with little to no BSD/MacOS experience, can you give a 
quick run-down of the differences between "C" and "POSIX"?


POSIX says that "C" and "POSIX" are equivalent[0].

The one that's relevant to default locale detection is just the string 
that "setlocale(LC_CTYPE, NULL)" returns.


POSIX doesn't require any particular return value for setlocale() calls. 
It's only guaranteed that the returned string can be used in subsequent 
setlocale() calls to restore the original locale.


So in the POSIX locale, a compliant setlocale() implementation could 
return "C", or "POSIX", or even something entirely different.



Beyond that, I don't know what the actual functional differences are.


I don't believe there are any.


[0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)

[Jakub Wilk]

* Victor Stinner , 2018-09-06, 16:40:
I'm also dubious about PyYAML which allows to run arbitrary Python code 
in a configuration *by default*. But well, it seems like nobody stepped 
in to change the default.


PyYAML maintainers intend to change the default soon:
https://github.com/yaml/pyyaml/issues/207

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jakub Kulík]

Hi, that was me fixing Oracle Solaris related issues.

To be completely honest, I wasn't sure if you would be interested in some
of our patches, because I thought that Python works without issues on
Illumos based systems and our patches might be very Oracle Solaris
specific. It seems that I was wrong (especially if I am the only one making
more Solaris fixes) - and looking at the OpenIndiana repo confirms that
suspicion because their Python 3.7 is almost exact copy of our repo with
the same patches fixing the same issues.

I am more than happy to help with Solaris related Python development. It
seems like Illumos is still pretty similar, hitting the same issues, so we
don't have to be afraid that fixes for one will break the other (especially
once/if Illumos build bot will be available). I will do more of those first
three points you mentioned and also upstream more of our patches, of which
we have several (
https://github.com/oracle/solaris-userland/tree/master/components/python/python39/
).

Also, as mentioned in the bug tracker, we are looking at how to provide
build bots running on Oracle Solaris.

Jakub

pá 30. 10. 2020 v 13:54 odesílatel Victor Stinner 
napsal:

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

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Jakub Stasiak]

> 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-Dev] Re: Signature discrepancies between documentation and implementation

[Jakub Stasiak]

> 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

[Jakub Stasiak]

> 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

[Jakub Stasiak]

> 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/

Re: [Python-Dev] re performance

[Jakub Wilk]

* Armin Rigo , 2017-01-28, 12:44:
The theoretical kind of regexp is about giving a "yes/no" answer, whereas the 
concrete "re" or "regexp" modules gives a match object, which lets you ask for 
the subgroups' location, for example. Strange at it may seem, I am not aware 
of a way to do that using the linear-time approach of the theory---if it 
answers "yes", then you have no way of knowing *where* the subgroups matched.


Another issue is that the theoretical engine has no notion of 
greedy/non-greedy matching.


RE2 has linear execution time, and it supports both capture groups and 
greedy/non-greedy matching.


The implementation is explained in this article:
https://swtch.com/~rsc/regexp/regexp3.html

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

[Jakub Wilk]

This is a very bad idea.

It seems to based on an assumption that the C locale is always some kind of 
pathology. Admittedly, it sometimes is a result of misconfiguration or a 
mistake. (But I don't see why it's the interpreter's job to correct such 
mistakes.) However, in some cases the C locale is a normal environment for 
system services, cron scripts, distro package builds and whatnot.


It's possible to write Python programs that are locale-agnostic.
It's also possible to write programs that are locale-dependent, but handle 
ASCII as locale encoding gracefully.
Or you might want to write a program that intentionally aborts with an 
explanatory error message when the locale encoding doesn't have sufficient 
Unicode coverage. ("Errors should never pass silently" anyone?)


With this proposal, none of the above seems possible to correctly implement in 
Python.


* Nick Coghlan , 2017-03-05, 17:50:
Another common failure case is developers specifying ``LANG=C`` in order to 
see otherwise translated user interface messages in English, rather than the 
more narrowly scoped ``LC_MESSAGES=C``.


Setting LANGUAGE=en might be better, because it doesn't affect locale encoding 
either, and it works even when LC_ALL is set.



Three such locales will be tried:

* ``C.UTF-8`` (available at least in Debian, Ubuntu, and Fedora 25+, and 
expected to be available by default in a future version of glibc)

* ``C.utf8`` (available at least in HP-UX)
* ``UTF-8`` (available in at least some \*BSD variants)


Calling the C locale "legacy" is a bit unfair, when there's even no agreement 
what the name of the successor is supposed to be...


NB, both "C.UTF-8" and "C.utf8" work on Fedora, thanks to glibc normalizing the 
encoding part. Only "C.UTF-8" works on Debian, though, for whatever reason.


For ``C.UTF-8`` and ``C.utf8``, the coercion will be implemented by actually 
setting the ``LANG`` and ``LC_ALL`` environment variables to the candidate 
locale name,


Sounds wrong. This will override all LC_*, even if they were originally set to 
something different that C.


Python detected LC_CTYPE=C, LC_ALL & LANG set to C.UTF-8 (set another locale 
or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour).


Comma splice.

s/set/was set/ would probably make it clearer.

Python detected LC_CTYPE=C, LC_CTYPE set to UTF-8 (set another locale or 
PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour).


Ditto.

The second sentence providing recommendations would be conditionally compiled 
based on the operating system (e.g. recommending ``LC_CTYPE=UTF-8`` on \*BSD 
systems.


Note that at least OpenBSD supports both "C.UTF-8" and "UTF-8" locales.

While this PEP ensures that developers that need to do so can still opt-in to 
running their Python code in the legacy C locale,


Yeah, no, it doesn't.

It's impossible do disable coercion from Python code, because it happens to 
early. The best you can do is to write a wrapper script in a different language 
that sets PYTHONCOERCECLOCALE=0; but then you still get a spurious warning.


--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 545: Python Documentation Translations

[Jakub Wilk]

Typos:

english -> English
Febrary -> February
insted -> instead
redundent -> redundant

* Julien Palard , 2017-03-29, 07:47:
It's redundant to display both language and country code if they're the same, 
for example: "de-DE" or "fr-FR".


This wording is unfortunate. It seems to imply that you can meaningfully 
compare a language code and a territory code for equality. This is not the 
case. For example, Belarusian (language code "be") is mainly spoken in Belarus 
(country code "by"), not in Belgium (country code "be").


--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Helping contributors with chores (do we have to?)

[Jakub Wilk]

* Paul Sokolovsky , 2017-06-25, 11:47:
A GitHub PR is just a git branch (in somebody else's repository, but also in 
the repository it's submitted to). So, like any git branch, you can fetch it, 
re-branch to your local branch, apply any changes to it, rebase, push 
anywhere.


Right, this is documented here:
https://help.github.com/articles/checking-out-pull-requests-locally/

There're also various tools for dealing specifically with git branch layout as 
used by Github, and every real man writes their own


I have this in my gitconfig:

[alias]
hub-pr = ! "_g() { set -e -u; git fetch origin \"pull/$1/head:gh-$1\" && git checkout 
\"gh-$1\"; }; _g"

If I want to checkout PR#42, I do:

$ git hub-pr 42

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Jakub Stasiak]

> 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

[Jakub Stasiak]

> 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)

[Jakub Stasiak]

> 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/

[Python-Dev] flock in Python 3

[Jakub QB Dorňák]

Hi all,

writing a threaded application I've been surprised that there is no object api 
for fcntl.flock implementing __enter__() and __exit__() methods to be used with 
'with' statement.
I have written one (https://pypi.python.org/pypi), but I wonder whether this 
could get into the Python Standard Library.

Regards,
QB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] flock in Python 3

[Jakub QB Dorňák]

You are right, it should be https://pypi.python.org/pypi/flock

- Original Message -
From: "Benjamin Peterson" 
To: "Jakub QB Dorňák" , "Python Dev" 
Sent: Friday, April 11, 2014 6:38:43 PM
Subject: Re: [Python-Dev] flock in Python 3

On Fri, Apr 11, 2014, at 5:58, Jakub QB Dorňák wrote:
> Hi all,
> 
> writing a threaded application I've been surprised that there is no
> object api for fcntl.flock implementing __enter__() and __exit__()
> methods to be used with 'with' statement.
> I have written one (https://pypi.python.org/pypi), but I wonder whether
> this could get into the Python Standard Library.

That link PyPi link is broken.

I think it would be nicer to have a high-level API for cross-platform
file locking. IIRC, flock can be rather non-portable.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com