Mailman 3 December 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to … [View More]

43 364

Call functools.update_wrapper on Mock(wraps=func)
by Lucas Wiman Dec. 30, 2022

Dec. 30, 2022

For code that uses annotations / signature, wrapping a callable in a Mock object does not work correctly: >>> import typing, inspect, functools >>> from unittest.mock import Mock >>> >>> def incr(i: int) -> int: ... return i+1 ... >>> wrapped = Mock(wraps=incr) >>> inspect.signature(wrapped) <Signature (*args, **kwargs)> >>> typing.get_type_hints(wrapped) Traceback (most recent call last): File "<stdin>", line … [View More]

1 0

Re: Idea: Tagged strings in python
by Brendan Barnwell Dec. 24, 2022

Dec. 24, 2022

Sorry, accidentally replied off-list. . . On 2022-12-19 11:36, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 06:29, Brendan Barnwell <brenbarn(a)brenbarn.net> wrote: >> >> On 2022-12-19 03:45, Chris Angelico wrote: >>> On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano <steve(a)pearwood.info> wrote: >>>>> But this much (say with a better validator) gets you static type checking, >>>>> syntax highlighting, and inherent documentation … [View More]of intent. >>>> >>>> Any half-way decent static type-checker will immediately fail as soon as >>>> you call a method on this html string, because it will know that the >>>> method returns a vanilla string, not a html string. >>> >>> But what does it even mean to uppercase an HTML string? Unless you >>> define that operation specifically, the most logical meaning is >>> "convert it into a plain string, and uppercase that". Or, similarly, >>> slicing an HTML string. You could give that a completely different >>> meaning (maybe defining its children to be tags, and slicing is taking >>> a selection of those), but if you don't, slicing isn't really a >>> meaningful operation. >> >> I don't agree with that at all. What it means for an HTML string to be >> a subclass of a normal string is that all normal string operations still >> work on an HTML string --- just like what it means for any instance of a >> subclass to be an instance of the superclass is that you can do anything >> to the subclass that you could do to the superclass. Every character in >> an HTML string is still a character and can still be uppercased. The >> string is still a sequence of characters and can be sliced. All such >> operations still have a perfectly natural meaning. > > And that part is already true. None of this changes. That's guaranteed > by the concept of subclassing. But what you're doing is string > operations on a string. > >> We just want them to >> now return an *HTML* string when they're done instead of a normal one. >> The point of having a subclass is to define *additional* behavior while >> still retaining the superclass behavior as well. > > So how is it still an "HTML" string if you slice out parts of it and > it isn't valid HTML any more? What it means for me for something to "be an HTML string" (or more precisely, to be an instance of HTMLString or whatever the class name is) is for it to be a string that has an extra tag attached to the object that means "this is HTML". That's it. You can make an HTML string that contains utter gobbledegook if you want. Of course, some operations may fail (like if it has a .validate() method) but that doesn't mean it's not still an instance of that class. Or, if you do want that, you can override the slicing method to raise an error if the result isn't valid HTML. The point is that overrides are for specifying the *new* behavior of the subclass (i.e., not allowing certain slice operations); you shouldn't have to override methods just to retain the superclass behavior. I mean, we were talking about this in the context of syntax highlighting. The utility of HTML-string highlighting would be seriously reduced if only *valid* HTML could be in an HTML string. >> Personally I find Python's behavior in this regard (not just for >> strings but for other builtin types) to be one of its most irritating >> warts. > > See my example regarding a StrEnum and tell me whether that would be > more irritating. I can't run that example myself as I don't have Python 3.11 set up. But just from what you showed, I don't find it convincing. Enums are special in that they are specifically designed to allow only a fixed set of values. I see that as the uncommon case, rather than the common one of subclassing an "open-ended" class to create a new "open-ended" class (i.e., one that does not pre-specify exactly which values are allowed). So no, I don't think it would be more irritating. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown [View Less]

8 28

Re: Idea: Tagged strings in python
by Rob Cliffe Dec. 22, 2022

Dec. 22, 2022

On 19/12/2022 03:23, David Mertz, Ph.D. wrote: > On Sun, Dec 18, 2022 at 8:29 PM Steven D'Aprano <steve(a)pearwood.info> > wrote: > > > However, if you want to allow these types to possibly *do* > something with > > the strings inside (validate them, canonicalize them, do a > security check, > > etc), I think I like the other way: > > class html(str): pass > > class css(str): pass > > The problem with this … [View More]

1 0

Idea: Tagged strings in python
by emil＠emilstenstrom.se Dec. 22, 2022

Dec. 22, 2022

Hi everyone! I'm the maintainer of a small django library called django-components. I've run into a problem that I have a language-level solution (tagged strings) to, that I think would benefit the wider python community. *Problem* A component in my library is a combination of python code, html, css and javascript. Currently I glue things together with a python file, where you put the paths to the html, css and javascript. When run, it brings all of the files together into a component. But … [View More]for small components, having to juggle four different files around is cumbersome, so I've started to look for a way to put everything related to the component _in the same file_. This makes it much easier to work on, understand, and with fewer places to make path errors. Example: class Calendar(component.Component): template_string = '<span class="calendar"></span>' css_string = '.calendar { background: pink }' js_string = 'document.getElementsByClassName("calendar)[0].onclick = function() { alert("click!") }' Seems simple enough, right? The problem is: There's no syntax highlighting in my code editor for the three other languages. This makes for a horrible developer experience, where you constantly have to hunt for characters inside of strings. You saw the missing quote in js_string right? :) If I instead use separate files, I get syntax highlighting and auto-completion for each file, because editors set language based on file type. But should I really have to choose? *Do we need a python language solution to this?* Could the code editors fix this? There's a long issue thread for vscode where this is discussed: https://github.com/Microsoft/vscode/issues/1751 - The reasoning (reasonable imho) is that this is not something that can be done generally, but that it needs to be handled at the python vscode extension level. Makes sense. Could the vscode language extension fix this? Well, the language extension has no way to know what language it should highlight. If a string is HTML or CSS. PyCharm has decided to use a "special python comment" # language=html that makes the next string be highlighted in that language. So if just all editors could standardize on that comment, everything would work? I guess so, but is that really the most intuitive API to standardize around? If the next statement is not a string, what happens? If the comment is on the same line as another statement, does it affect that line, or the next? What if there's a newline in between the comment in the string, does that work? *Suggested solution* I suggest supporting _tagged strings_ in python. They would look like html'<span class="calendar"></span>'. * Python should not hold a list of which tagged strings it should support, it should be possible to use any tag. * To avoid clashes with current raw strings and unicode strings, a tag should be required to be at least 2 characters long (I'm open to other ways to avoid this). I like this syntax because: 1. It's clear what string the tag is affecting. 2. It makes sense when you read it, even though you've never seen the syntax before. 3. It clearly communicates which language to highlight to code editors, since you can use the language identifiers that already exist: https://code.visualstudio.com/docs/languages/identifiers#_known-language-id… - for single letter languages, which are not supported to avoid clash with raw strings and unicode strings, the language extension would have to support "r-lang" and "c-lang" instead. 4. It mimics the syntax of tagged string templates in javascript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_…). So it has som precedent. (If desirable, I think mimicing javascript further and making tagged strings call a function with the tag's name, would be a great addition to Python too. This would make the syntax for parsing foreign languages much nicer. But this is not required for my specific problem, it's just a nice next possible step for this feature.) *Backwards compatibility* This syntax currently raises a invalid syntax error. So introducing this shouldn't break existing programs. Python's currently supported string types are just single letter, so the suggestion is to require tagged strings to be at least two letters. *Feedback?* What are your thoughts on this? Do you see a value in adding tagged strings to python? Are there other use-cases where this would be useful? Does the suggestion need to support calling tags as functions like in javascript to be interesting? (I'm new to python-ideas, so I hope I haven't broken some unspoken rule with this suggestion.) -- Emil Stenström [View Less]

19 46

Extending LiteralString or Literal with structural validation
by Mathew Elman Dec. 21, 2022

Dec. 21, 2022

This is somewhat inspired by the "Tagged strings in python" thread, but from a different approach. Specifically, rather than messing with runtime python, using static type analysis to help the usability of specific kinds of string literals. It would be useful to take advantage of the `LiteralString` or `Literal` type hints to add structural validation to literals. For *example*, if these could be subclassed to add a validation method: class MyLiteral(LiteralString): def … [View More]

3 3

Re: Idea: Tagged strings in python
by Steven D'Aprano Dec. 20, 2022

Dec. 20, 2022

On Mon, Dec 19, 2022 at 03:48:01PM -0800, Christopher Barker wrote: > On Mon, Dec 19, 2022 at 3:39 AM Steven D'Aprano <steve(a)pearwood.info> wrote > > > In any case, I was making a larger point that this same issue applies to > > other builtins like float, int and more. > > > Actually, I think the issue is with immutable types, rather than builtins. No. >>> class MyList(list): ... def frobinate(self): ... return "something" ... &… [View More]

2 1

[Feature Request] Add attribute font_path to the class tkinter.font.Font
by Jérémie Bergeron Dec. 14, 2022

Dec. 14, 2022

Hi, I think it would be usefull if the class tkinter.font.Font<https://docs.python.org/3/library/tkinter.font.html#module-tkinter.font> would contain the path to the font. With it, we can use many software like fonttools<https://github.com/fonttools/fonttools> to obtain more information about the font, because the class Font is very limited. You could think it would be useless, but it is a nice feature when you know a font name and need more information, but you doesnt know it's … [View More]

2 1

Nonuniform PRNG?
by David Lowry-Duda Dec. 7, 2022

Dec. 7, 2022

Inspired by the recent thread on PRNG, I began to wonder: suppose that I had a pseudorandom number generator that attempted to generate a nonuniform distribution. Suppose for instance that it was to generate a 0 bit 2/3 of the time, and a 1 bit 1/3 of the time. How would one go about testing this PRNG against an idealized (similarly biased) PRNG? - DLD

4 4

Better (?) PRNG
by James Johnson Dec. 7, 2022

Dec. 7, 2022

I wrote the attached python (3) code to improve on existing prng functions. I used the time module for one method, which resulted in disproportionate odd values, but agreeable means. I used the hashlib module for the second. It is evident that the code is amateur, but the program might result in better PRN generation. The "app" lends itself to checking, using statistical tools (see comments.) I remain a fan, James Johnson

8 23