[Python-Dev] Re: PEP 638: Syntactic macros

2023-02-02 Thread David Mertz, Ph.D. 
On Thu, Feb 2, 2023 at 12:46 PM Stéfane Fermigier  wrote:

> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
> https://oeis.org/wiki/List_of_LaTeX_mathematical_symbols
> NB: on a very basic level, I remember trying, a few years ago, to use the
> Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
> for several reasons, including the fact that Python didn't like it as a
> variable name.
>

I use the `vim` conceal plugin to make some of these appear on screen while
I'm editing. So, for example, when I type `set()` I see `∅`.  When I type
`all(...)` I see `∀(...)`.

Much to the chagrin of Moshe Zadka, when I type `None` I see `ℵ` ...
because I argue that ℵ_0 really should be considered an inaccessible
cardinal :-).

However, it never causes me problems because the files on disk are just
plain old ASCII (for the most part), and the special symbols are just what
my screen shows, not overloads to underlying operators.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3BFWMNHH5VMVROWNKH77ORZL2ECDPP7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

2022-07-21 Thread David Mertz, Ph.D. 
I feel similarly as Steven. I'm even less important to the development of
CPython than he is. But like him, switching to Discourse means I simply
won't try to follow development.

Mailing list are friendly and easily manageable. In the small amount I've
used Discourse, it feels unwieldy and less friendly. More importantly, it
makes it "that other thing I have to go check." Email is something I will
automatically examine every day.

But again, I'm not the audience who matters, which I well recognize.

On Thu, Jul 21, 2022, 6:50 PM Steven Barker  wrote:

> On Mon, Jul 18, 2022 at 6:28 AM Petr Viktorin  wrote:
>
>> On 16. 07. 22 8:48, Miro Hrončok wrote:
>> > On 15. 07. 22 13:18, Petr Viktorin wrote:
>> >> - You can use discuss.python.org's “mailing list mode” (which
>> >> subscribes you to all new posts), possibly with filtering and/or
>> >> categorizing messages locally.
>>
> [...]
>
>> > What would be a good resource to read about this - where do I learn how
>> > to use discuss.python.org's in the “mailing list mode”
>>
>> Is this note enough?
>>
>> https://devguide.python.org/developer-workflow/communication-channels/?highlight=discourse#enabling-mailing-list-mode
>>
> [...]
>
> So last night I tried activating mailing list mode, and I'm not remotely
> satisfied with the experience so far. Where mailing lists are concerned,
> I'm *only *subscribed to python-dev. Not python-users, not -ideas, not
> -packaging (if that's still a thing). But Discourse's mailing list mode
> sends me messages for all of those things in such a volume that it drowns
> out any discussions on topics that would have shown up on python-dev (I
> think one PEP discussion message came in overnight, compared to 20+ posts
> on other tags). After the first two -users messages came in almost
> immediately, I tried telling discourse to mute the tags I don't care about,
> but it seems not to work at all. The page with the mailing list mode toggle
> warns that it overrides other email settings, so I think I just get
> everything regardless of other settings.
>
> If my only option is to be subscribed to a firehose of stuff I don't care
> about, I'm going to disable mailing list mode and if python-dev dies, I'll
> pretty much quit following Python's development. Now, I'm not a very
> important Python developer, I'm not a core dev, and my contributions are a
> few bug reports and a few patches over many years. But if there's no way to
> lurk on a modest-volume mailing list and contribute only occasionally,
> you're not going to get nearly as many people paying attention. I'm sure I
> could set up a whole suite of filters on my own end (e.g. discard any email
> with a subject starting with "[py] [Users]"), but that's an absurd and
> unnecessary burden, and it will only get worse the more categories you add
> to discourse (and I think the ease of adding categories is supposed to be a
> *feature*). This plan is going to drive developers like me away.
>
> For discourse mailing list mode to be a reasonable substitute for
> python-dev, it needs filtering on the sending end to work. Ideally there
> would be a way to subscribe only to the things I care about. Maybe that
> exists, but it's buried in menus I don't understand (or which mailing list
> mode overrides).
>
> Rather than comparing the number of posters on discourse vs python-dev,
> have we compared stats for how many people receive the messages?
>
> ___
> 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/6QAP5NCX4NODNLKTIFYW5FO33757L3AK/
> 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/Y4PYIV3SOSPKEWAE5NIDMODOQVX4UQBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread David Mertz, Ph.D. 
FWIW, I find Discourse (and everything similar that I've seen), awkward,
difficult to use, poorly organized, and in every way inferior to my mail
client.

Obviously, other people differ in opinion. Quite likely the majority of
cpython developers disagree. I don't think I'm entirely alone in this
experience though. Of course it's possible that the move will happen (I'm
basically a lurker here, andy preference really shouldn't be very
important).

On Thu, Apr 7, 2022, 8:17 PM Gregory P. Smith  wrote:

>
> On Thu, Apr 7, 2022 at 4:31 PM Jean Abou Samra  wrote:
>
>>
>> I'm only a lurker here, but find the split between this mailing list
>> and various Discourse categories a little confusing from the outside.
>> As far as I understand, the Discourse server was originally an experiment.
>> Today, it has grown far past the size of an experiment though. Are there
>> any plans to retire either Discourse or the mailing list and use a
>> unified communication channel? This is a curiosity question.
>>
>
> We feel it too. We've been finding Discourse more useful from a community
> moderation and thread management point of view as well as offering markdown
> text and code rendering. Ideal for PEP discussions. Many of us expect
> python-dev to wind up obsoleted by Discourse as a result. I encourage
> everyone to use https://discuss.python.org/ first for Dev audience
> communications. And for lurkers and subscribers here to enable email
> notifications for categories of interest over there.
>
> -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/2TPHCHVB7NEMMTEWWYBYFZNIFBEE2S4W/
> 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/E2UCA43NV3XEU7JHRJZVLTEHSD634S4U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New PEP website is horrible to read on mobile device

2022-03-15 Thread David Mertz, Ph.D. 
I get pretty much the same thing as the OP on Chrome 99.0.4844.58; Android
11; Pixel 2 XL; Build RP1A.201005.004.A1.

However, it gets more readable if I force Desktop site and zoom a bit.
These facts are pretty common for a lot of websites, and I never gave it
much thought.  But yes, the mobile version could be better responsive.

On Tue, Mar 15, 2022 at 5:17 PM Terry Reedy  wrote:

> On 3/15/2022 10:06 AM, Nathan Cook wrote:
> > Please make https://peps.python.org/  more
> > responsive to various form factors
> >
> > See attached screenshot from Chrome version 99.0.4844.58 on my Pixel
> > 3aXL running Android 12
>
> Are you sure that the site looks any different that it did at the older
> url, www.python.org/peps/ ?  In any case, when I go there with Chrome on
> my (old) Nexus 6P, pages are originally wrapped to the screen size.  If
> I zoom in, a horizontal scrollbar is added (and suppressed) and I have
> to scroll horizontally with my finger.  On the phone, Google search page
> results act the same.  So do the wikipedia pages I tested.  (On my
> desktop monitor, they rewrap on both Chrome and Firefox, although the
> layout is different in the two browswers.)
>
>
> --
> Terry Jan Reedy
>
> ___
> 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/SVJRYYCZ2YEAJ7OH6TE3TV4TEX4TBUE4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/HDYPGCGIAK6UOIAOTNBEI6HAB7DEPQEM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D. 
These are binary wheel installs though, no? Which means 3.8 version and
3.10 version were compiled at different times, even for the same NumPy
version. Also for different platforms, I don't know which you are on.

I haven't checked what's on PyPI for each version. I think PyFFT is largely
using NumPy.

You can find details with something like

>>> import numpy.distutils
>>> numpy.distutils.unixccompiler.sysconfig.get_config_vars()

I suspect that will indicate interesting compiler differences even for the
"same version."

As Chris Barker mentions, this will probably find people more familiar with
the issue on the NumPy mailing list.

On Sun, Dec 19, 2021, 2:11 PM Tigran Aivazian 
wrote:

> In both cases I installed numpy using "sudo -H pip install numpy". And
> just now I upgraded numpy in 3.8 using "sudo -H pip3.8 install --upgrade
> numpy".
>
> I will try to simplify the program by removing all the higher level
> complexity and see what I find.
> ___
> 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/SPI6K4LNO5BFLIUGYBHCMYCXX7FO7YV5/
> 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/ZDLL5GSFY4CTCDBLJEB62EOWBRX775NQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D. 
Not the version, but the build. Did you compile NumPy from source using the
same compiler with both Python versions? If not, that remains my strong
hunch about performance difference.

Given what your programs do, it sure seems like the large majority of
runtime is spent in supporting numeric libraries, not in Python interpreter
itself.

Profiling is the way to find out.

On Sun, Dec 19, 2021, 1:52 PM Tigran Aivazian 
wrote:

> To eliminate the possibility of being affected by the different versions
> of numpy I have just now upgraded numpy in Python 3.8 environment to the
> latest version, so both 3.8 and 3.10 and using numpy 1.21.4 and still the
> timing is exactly the same.
> ___
> 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/THPN4OWM3A335LDO7HVIQSIDFFVO5URZ/
> 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/5KW7PUQADRY35YBX4IWOHFVZFPGMPNFB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D. 
My guess is that this difference is predominantly different builds of
NumPy.  For example, the Intel optimized builds are very good, and a speed
difference of the magnitude shown in this note are typical.  E.g.
https://www.intel.com/content/www/us/en/developer/articles/technical/numpyscipy-with-intel-mkl.html

On Sun, Dec 19, 2021 at 12:24 PM  wrote:

> Hello,
>
> Being a programmer myself I realise that a report on performance
> degradation should ideally contain a small test program that clearly
> reproduces the problem. However, unfortunately, I do not have the time at
> present to isolate the issue to a small test case. But the good news (or
> bad news, I suppose) is that the problem appears to be reasonably general,
> namely it happens with two completely different programs.
>
> Anyway, what I am claiming is that Python 3.10 is between 1.5 and 2.5
> times SLOWER than Python 3.8, for rather generic scientific calculations
> such as Fourier analysis, ODE solving and plotting. On the one hand, the
> "test case" is a rather complex program that calculates Wigner function of
> a quantum system and the result is 9 seconds when run with 3.8 and 23
> seconds when run with 3.10 (very easy to reproduce: just clone this
> repository: https://github.com/tigran123/quantum-infodynamics and run
> "time bin/harmonic-oscillator-solve.sh" from the dynamics subdirectory and
> then edit initgauss.py and solve.py to point to python3.10 and run it
> again). Make sure your TMPDIR points somewhere fast. My machine is a very
> fast 6-core i7-6800K at 4.2GHz and 128GB RAM. The storage is also a very
> fast NVMe, about 3GB/s.
>
> After this try a completely different program which simulates a
> mathematical pendulum using PyQT (GUI) and it gives FPS:14-15 when run with
> 3.8 and only 11-12 when run with 3.10. Again, it is easy to reproduce if
> you have cloned the above repository: just go to
> classical-mechanics/pendulum subdirectory and run psim.py (click on the
> Play button in the control window and observe FPS in the plot window). Then
> edit psim.py to point to Python 3.10 and run it again. You would need
> PyQt5, matplotlib, numpy, scipy, pyFFTW for these programs to work.
>
> I realise that you would much prefer a small specific test case, but I
> still hope that this report is "better than nothing". I do really desire to
> help improve Python and will provide more information if requested. I use
> Python everywhere, even in Termux on Android, and am quite saddened by this
> degradation...
>
> With Python 3.8 I used these package versions:
>
> matplotlib  3.1.3
> numpy   1.18.1
> pyFFTW0.12.0
> PyQt55.13.2
> scipy  1.4.1
>
> With Python 3.10 I used these package versions:
>
> matplotlib  3.5.0
> numpy  1.21.4
> pyFFTW   0.12.0
> PyQt5   5.15.6
> scipy1.7.3
>
> Both Python 3.8 and 3.10 were compiled and installed by myself with
> "./configure --enable-optimizations ; make ; sudo make install".
>
> Kind regards,
> Tigran
> ___
> 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/34FP7FEG36UVBFW3ZDTL7GOQRSRBSXTQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/5NOZDWLEPH4CBGC6LGQ7BOSJBVZKVZFJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python release announcement format

2021-12-19 Thread David Mertz, Ph.D. 
On Sun, Dec 19, 2021, 11:49 AM Steven D'Aprano

> And both the download and the webpage listing the checksum are over https.
> If we don't trust https, the whole internet is broken and changing to a
> stronger checksum won't help. A hypothetical MITM attacker capable of
> breaking https and injecting new content into the download file can
> likewise change the checksum.
>

I think the attack is Mallory can influence Alice to use an installer
obtained from somewhere else (e.g. a caching proxy, a shared drive, a thumb
drive, embedded in an OS distribution, etc).

As "assurance" Mallory tells Alice to validate the installer against the
hash published on python.org, which Mallory has not compromised.

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

[Python-Dev] Re: The current state of typing PEPs

2021-11-29 Thread David Mertz, Ph.D. 
On Mon, Nov 29, 2021 at 8:17 PM Guido van Rossum  wrote:

> Why would it need to be reiterated? Are there really people who believe
> that such code would become invalid? AFAIK *everybody* here agrees that
> this should stay valid. So who would we be reiterating it for?
>

I'm certainly not alone, among people on this list, in regard to the
following. But I teach a lot of people who are coders, but not necessarily
senior (in Python, or otherwise).  I also mentor/lead such junior
programmers.

I find it quite common when people who haven't known Python for 20 years
see type annotations, they have trouble getting the optional and gradual
nature of them.  Explaining that is certainly not impossible, nor even all
that difficult.  However, it DOES need to be explained.  Especially when
less experienced Pythonistas have worked with statically typed languages,
they often see code with type annotations and overgeneralize to their
requirement.

I don't know exactly what that means about *where* this needs to be
explained.  Maybe just by trainers and authors.  But maybe things in
official Python documentation as well, which seem more definitive.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/H2P7KUV6IRZLKZ3G73RJGJN5U6NZOCYQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

2021-11-14 Thread David Mertz, Ph.D. 
On Sun, Nov 14, 2021, 2:14 PM Christopher Barker

> It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL LETTER
>> E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH ACUTE}",
>> which are different ways of writing the same thing.
>>
>
> Why does someone that wants to use, .e.g. "é" in an identifier have to be
> able to represent it two different ways in a code file?
>

Imagine that two different programmers work with the same code base, and
their text editors or keystrokes enter "é" in different ways.

Or imagine just one programmer doing so on two different
machines/environments.

As an example, I wrote this reply on my Android tablet (with such-and-such
OS version). I have no idea what actual codepoint(s) are entered when I
press and hold the "e" key for a couple seconds to pop up character
variations.

If I wrote it on OSX, I'd probably press "alt-e e" on my US International
key layout. Again, no idea what codepoints actually are entered. If I did
it on Linux, I'd use "ctrl-shift u 00e9". In that case, I actually know the
codepoint.
___
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/F2GZT7YJTIZWTCPQXDSPVQICE3YK2TZ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Having Sorted Containers in stdlib?

2021-11-10 Thread David Mertz, Ph.D. 
I agree with Tim. Subject, of course, to the same caveat Tim mentions: does
the creator want this?

I haven't used the library much, but it's obviously top quality, and adding
pure-Python code is less burden than C implementations.

On Wed, Nov 10, 2021, 10:19 PM Tim Peters  wrote:

> [Bob Fang ]
> > This is a modest proposal to consider having sorted containers
> > (http://www.grantjenks.com/docs/sortedcontainers/) in standard library.
>
> +1 from me, but if and only if Grant Jenks (its author) wants that too.
>
> It's first-rate code in all respects, including that it's a fine
> example _of_ Python programming (it's not written in C - in Python).
>
> People often say "well, put a thing on PyPI first, and see whether
> people really want it!".
>
> SortedContainers has been on PyPI for years straight now, and still
> gets hundreds of thousands of downloads from there every day:
>
> https://pypistats.org/packages/sortedcontainers
>
> So it's already widely adopted in the community. What else would it
> need to prove?
>
> If it still doesn't qualify, "well, put a thing on PyPI first" is just
> obstructionism ;-)
> ___
> 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/SE6YOVJQI6OEWNM5SAQL3X5VPEFGVZAA/
> 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/5NOGVTADSSSWPEWNHAMR35QYJJA7JDXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

2021-11-02 Thread David Mertz, Ph.D. 
This is an amazing document, Petr. Really great work!

I think I agree with Marc-André that putting it in the actual Python
documentation would give it more visibility than in a PEP.

On Tue, Nov 2, 2021, 1:06 PM Marc-Andre Lemburg  wrote:

> On 01.11.2021 13:17, Petr Viktorin wrote:
> >> PEP: 
> >> Title: Unicode Security Considerations for Python
> >> Author: Petr Viktorin 
> >> Status: Active
> >> Type: Informational
> >> Content-Type: text/x-rst
> >> Created: 01-Nov-2021
> >> Post-History:
>
> Thanks for writing this up. I'm not sure whether a PEP is the right place
> for such documentation, though. Wouldn't it be more visible in the standard
> Python documentation ?
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Nov 02 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FSFG2B3LCWU5PQWX3WRIOJGNV2JFW4AU/
> 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/6PHPDZRCYNA44NHSHXPBL7QMWXMHXWGU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Semi-proposal: Tagged None

2021-10-21 Thread David Mertz, Ph.D. 
I've moved this to python-ideas where it is more appropriate, as Chris
notes

On Thu, Oct 21, 2021, 8:42 PM Chris Angelico  wrote:

> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
>  wrote:
> >
> > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano 
> wrote:
> >>
> >> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> >> > None and its ilk often conflate too many qualities. For example, is it
> >> > missing because it doesn't exist, it never existed, or because we
> never
> >> > received a value, despite knowing it must exist?
> >
> >
> >>
> >> 30+ years later, and we cannot easily, reliably or portably use NAN
> >> payloads. Most people don't care. If we offerred them a dozen or a
> >> thousand distinct sentinels for all the various kinds of missing data,
> >> how many people would use them and how many would just stick to plain
> >> old None?
> >
> >
> > In data science, I have been frustrated by the sparsity of ways of
> spelling "missing value."
>
> Might be worth redirecting this to -ideas.
>
> > Besides the distinction Michael points out, and that Steven did in
> relation to NaNs with payloads, I encounter missingness of various other
> sorts as well.  Crucially,  an important kind of missing data is data where
> the value I received seems unreliable and I have decided to *impute*
> missingness rather than accept a value I believe is unreliable.
> >
> > But there is also something akin to what Michael points out (maybe it's
> just an example).  For example, "middle name" is something that some people
> simply do not have, other people choose not to provide on a survey, and
> others still we just don't know anything beyond "it's not there."
> >
>
> And some people have more than one (I have a brother with two of
> them). Not the best example to use, since names have WAY more
> complexities than different types of absence, but there are other
> cases where that sort of thing comes up. For instance, if someone says
> on a survey that s/he is in Australia, and then you ask for a
> postcode, then leaving it blank should be recorded as "chose not to
> provide"; but if the country is listed as Timor-Leste / East Timor,
> then "not applicable" would be appropriate, since the country doesn't
> use postal codes.
>
> > Of course, when I impute missingness, I can do so at various stages of
> data cleaning, and for various different reasons or confidences.  None (or
> NaN) are sort of OK, but carrying metadata as to the nature of missingness
> would be nice.
> >
>
> Right. Using postcodes as an example again, for someone in Australia,
> a postcode of "E3B 0H8" doesn't make sense, as that isn't the format
> we use. So you could wipe that out and replace it with "No postal
> code, malformed data entered".
>
> > So my strawman suggestion is tagging None's.  I suppose spellings like
> `None[reason]` or `None(reason)` are appealing.
> >
> > An obvious problem that I recognize is that it's not obvious this can
> "play nice" with the common idiom `if mydata is not None: ...`.  None
> really is a singleton, and a "tagged singleton" or "annotated singleton"
> probably doesn't work well with Python's object model.
> >
> > My goal, of course, would be to have TaggedNone be a kind of subclass of
> None, in the same way that bool is a subclass of int, and hence True is a
> kind of 1.  However, I'd want a large number of custom None's, with some
> sort of accessible string or numeric code or something to inspect which one
> it was.
> >
>
> But this is where I start to disagree. None should remain a singleton,
> but "no data available" could be its own thing, tied in with the way
> that you do your data storage and stats. As such, you wouldn't be
> checking it with 'is', so you wouldn't have that problem (the Python
> 'is' operator will only ever test for actual object identity).
>
> Keep None simple and dependable, and then "Missing Data" can be an
> entire class of values if you so desire.
>
> 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/6NY5NQCJR3ROFBWWFOVD47HJFBQJC3IZ/
> 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/CFNI2QLBJ5D3YOQZ2TSZHZHQCPXCGAUN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Semi-proposal: Tagged None

2021-10-21 Thread David Mertz, Ph.D. 
On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano  wrote:

> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> > None and its ilk often conflate too many qualities. For example, is it
> > missing because it doesn't exist, it never existed, or because we never
> > received a value, despite knowing it must exist?
>


> 30+ years later, and we cannot easily, reliably or portably use NAN
> payloads. Most people don't care. If we offerred them a dozen or a
> thousand distinct sentinels for all the various kinds of missing data,
> how many people would use them and how many would just stick to plain
> old None?


In data science, I have been frustrated by the sparsity of ways of spelling
"missing value."

Besides the distinction Michael points out, and that Steven did in relation
to NaNs with payloads, I encounter missingness of various other sorts as
well.  Crucially,  an important kind of missing data is data where the
value I received seems unreliable and I have decided to *impute*
missingness rather than accept a value I believe is unreliable.

But there is also something akin to what Michael points out (maybe it's
just an example).  For example, "middle name" is something that some people
simply do not have, other people choose not to provide on a survey, and
others still we just don't know anything beyond "it's not there."

Of course, when I impute missingness, I can do so at various stages of data
cleaning, and for various different reasons or confidences.  None (or NaN)
are sort of OK, but carrying metadata as to the nature of missingness would
be nice.

So my strawman suggestion is tagging None's.  I suppose spellings like
`None[reason]` or `None(reason)` are appealing.

An obvious problem that I recognize is that it's not obvious this can "play
nice" with the common idiom `if mydata is not None: ...`.  None really is a
singleton, and a "tagged singleton" or "annotated singleton" probably
doesn't work well with Python's object model.

My goal, of course, would be to have TaggedNone be a kind of subclass of
None, in the same way that bool is a subclass of int, and hence True is a
kind of 1.  However, I'd want a large number of custom None's, with some
sort of accessible string or numeric code or something to inspect which one
it was.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/HAGJBRBXVWGGU2HRMVEWRNQSGUD75IYT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread David Mertz, Ph.D. 
On Mon, Oct 18, 2021 at 6:49 PM Paul Moore  wrote:

> On Mon, 18 Oct 2021 at 19:29, Guido van Rossum  wrote:
> > y = None  # Default
> > if config is not None:
> >   handler = config.get("handler")
> >   if handler is not None:
> > parameters = handler.get("parameters")
> > if parameters is not None:
> >   y = parameters.get("y")
>
> For this particular usage, I'd much rather have a functional API, like
> y = get_config(config, "handler", "parameters", "y")
>

I agree with Paul here... and am pretty sure I did the last time this went
around.  Whenever the issue comes up, it's about JSON.  Or *maybe* about
something very similar that goes by another name or format details.

And there already exists a pretty good, pretty standard, approach called
JSONPath that deals with exactly this kind of thing.  This, in turn, is
largely the same as XPath which serves the same role for XML documents.

I don't think it necessarily needs to be in the standard library, but the
mini-language for extracting data from trees with frequently missing
branches can very well simply be a mini-language.  It'll wind up a lot like
XPath/JSONPath, but something a little bit different could be good too.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/S5Q4OVZIJUQ5AG4HNIRGN4NALCNJGWOW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

2021-09-20 Thread David Mertz, Ph.D. 
I know I'm strongly -1 on allowing much more than currently exists for
f-strings. For basically the same reason Stephen explains.

Newlines inside braces, for example, go way too far away from readability.
Nested expressions also feel like an attractive nuisance. I use f-strings
all the time, but in much the same way a thousand character regular
expression is an abuse (even if perfectly well defined grammatically),
really complex f-strings worries look and feel much the same.

On Mon, Sep 20, 2021, 9:39 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Eric V. Smith writes:
>
>  > >> But this does not:
>  > >>
>  > >> f'{1 +
>  > >> 2}'
>  > >
>  > > The later is an error with or without the 'f' prefix and I think that
>  > > this should continue to be the case.
>  > >
>  > The thought is that anything that's within braces {} and is a valid
>  > expression should be allowed.
>
> -0  FWIW, some thoughts specific to me, I don't know how
> representative they might be of others.
>
> I guess you could argue that the braces are a kind of expression-level
> parenthesis, but I don't "see" them that way.  I see *one* string with
> eval'able format expressions embedded in it, so that single-quoted
> strings can't have embedded newlines.  I also don't see the braces as
> expression-level syntax (after all, they already have two different
> meanings at expression level), I see them as part of f-string syntax.
> So even with triple-quoted strings, my eyes "want" to see parentheses
> or line continuation (which already work).
>
> I'm sure I could get used to the syntax.  But ...
>
> Is this syntax useful?  Or is it just a variant of purity trying to
> escape Pandora's virtualbox?  I mean, am I going to see it often
> enough to get used to it?  Or am I going to WTF at it for the rest of
> my life?
> ___
> 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/RPFHA55JDGX522UL2KXIRZKDPIOVDP66/
> 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/I7ZQTEZJMTUZF5KQSNQVTUCFEXYAVPAO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object

2021-09-08 Thread David Mertz, Ph.D. 
Thanks Serhiy,

I've made the few additional changes you noted in the PR.  I took out my
attempt with path_t.  However, here is why I think argument clinic (or
something else?!) is actually intercepting the attempted call:

With my temporary debugging, I have this function in Modules/_gdbmmodule.c:

[clinic start generated code]*/

static PyObject *
dbmopen_impl(PyObject *module, PyObject *filename, const char *flags,
 int mode)
/*[clinic end generated code: output=9527750f5df90764
input=812b7d74399ceb0e]*/
{
PyObject_Print(filename, stdout, 0);
printf(" from _gdbmmodule.c (XXX)\n");
/* ... rest of function ...*/

And I have a very simplified test script:

import _gdbm
import sys
from pathlib import Path

print(sys.version)
path = '/tmp/tmp.db'

db = _gdbm.open(path, 'c')
print("Opened with string path")
db.close()

db = _gdbm.open(Path(path), 'c')
print("Opened with path-like")
db.close()

The output of running this is:

3.11.0a0 (heads/bpo-45133-dirty:0376feb030, Sep  8 2021, 00:39:39) [GCC
10.3.0]
'/tmp/tmp.db' from _gdbmmodule.c (XXX)
Opened with string path
Traceback (most recent call last):
  File "/home/dmertz/tmp/pathlike-dbm.py", line 12, in 
db = _gdbm.open(Path(path), 'c')
 ^^^
TypeError: open() argument 1 must be str, not PosixPath

So before I get to the first line of the _gdbm.open() function, the
TypeError is already occurring when passed a PosixPath.

On Wed, Sep 8, 2021 at 3:49 AM Serhiy Storchaka  wrote:

> 08.09.21 08:19, David Mertz, Ph.D. пише:
> > I attempted to do this today, as my first actual contribution to CPython
> > itself.  I think the prior attempt went down a wrong path, which is why
> > neither PR could actually pass tests.
> >
> > I've been looking at `posixmodule.c` for comparison, specifically.
>
> The code in posixmodule.c is a bad example, because it is too general
> and supports many options. It gives the patch as char* and wchat_t* (on
> Windows), supports file descriptors and None, and format error messages
> for functions supporting multiple types. But if you only need a path as
> char*, you can just use PyUnicode_FSConverter().
>
> There is an existing PR for this issue. It looks correct in general, but
> I left some comments.
>
> ___
> 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/LQGU6DM5ZSDPCAXKLEII6YIF4HQI52NG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/4K5MDPKTF6D3UFC3S6GRL7TESSXFLCN2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object

2021-09-07 Thread David Mertz, Ph.D. 
I attempted to do this today, as my first actual contribution to CPython
itself.  I think the prior attempt went down a wrong path, which is why
neither PR could actually pass tests.

I've been looking at `posixmodule.c` for comparison, specifically.  The key
thing, I believe, is not to use `PyObject *filename` in the
`dpmopen_impl()` calls at all, but rather `path_t *path`.  I tried some
absolutely crude instrumentation to see why the `PyOS_FSPath` macro and the
rest wasn't doing what it seems like it should (i.e. sticking `printf()`s
in the .c files).  Eventually I realized that argument clinic is stopping
me from even getting to the body of the function when `filename` was a
PosixPath, so anything that PyOS_FSPath does is moot.

I think in the end the new code should be even simpler than the main (3.11)
branch.  All I really need to do with a `path_t` is be able to call:

PyObject *self = newgdbmobject(state, name, iflags, mode);

That is, `name` is simply the filename as char* (the other parameters are
independent of the path-like issue).

Does anyone have pointers to an example or documentation about doing this?
The patterns in posixmodule.c are suggestive, but I'm not sure of the
missing pieces.

Also, I copied the typedef for path_t from posixmodule.c to both
`_dbmmodule.c` and `_gdbmmodule.c`.  I know that's also going to be wrong,
and it should be pulled into an .h file.  Any idea about which one?
`posixmodule.h` seems like a possibility, but then I'd need to repeat it in
`winreparse.h`.  Maybe a new name?



On Tue, Sep 7, 2021 at 1:11 PM Guido van Rossum  wrote:

> If someone posted a Pull Request that added this, it would be looked upon
> favorably I'm sure.
>
> On Tue, Sep 7, 2021 at 8:31 AM Christopher Barker 
> wrote:
>
>> it looks like this as had a BPO for over a year:
>>
>> https://bugs.python.org/issue40563
>>
>> I suggest pinging that (and maybe python-dev) to see what's up.
>>
>> NOTE: first check 3.10 :-)
>>
>> -CHB
>>
>>
>> On Tue, Sep 7, 2021 at 5:05 AM Evan Greenup via Python-ideas <
>> python-id...@python.org> wrote:
>>
>>> Currently, in Python 3.9, `dbm.open()`, `dbm.gnu.open()` and
>>> `dbm.ndbm.open()` doesn't support path-like object, class defined in
>>> `pathlib`.
>>>
>>> It would be nice to add support with it.
>>>
>>>
___
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/QSS5SCSK2ZXNBQSGYIRSED6UMWB32PAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Problems with dict subclassing performance

2021-08-16 Thread David Mertz, Ph.D. 
I also haven't the faintest idea what might be intended by the phrase "I
pretend your immediate excuses".

But whatever the intention, it is clear Marco has veered off into angry
ranting territory. Him taking a couple weeks away from this list would be
an extremely good idea.

On Sun, Aug 15, 2021, 5:53 PM Marco Sulla 
wrote:

> On Sun, 15 Aug 2021 at 23:33, Tim Peters 
> wrote:ople have said now, including me, they had no idea what
> > you meant.by "I pretend your immediate excuses". It's not a complaint
> > that it's expressed inelegantly, but that they can't make _any_ sense
> > of it. By my count, this is at least the second time you've declined
> > to explain what you meant, but instead implied the person who said
> > they couldn't understand it was being dishonest.
>
> I repeat, even the worst AI will understand from the context what I
> meant. But let me do a very rude example:
>
>
> What if I said to Steven "I pretend immediate suck my $%#$"? Do you
> think you and the others will not understand the sense? :D
>
> C'Mon, you are offending my poor intelligence.
>
> As I wanted to say, I pretend from Steven his excuses for his
> insinuation, immediately. Is this clear now, or must I take an English
> course at Cambridge?
> ___
> 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/O3JB3FE33KMT3OHZCVH3XO6VNJTGH5NL/
> 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/TAIEAKBBUXQNDSXUR3PVW2CTIPLJONDI/
Code of Conduct: http://python.org/psf/codeofconduct/