[Python-ideas] Re: Abstract dataclasses and dataclass fields

[Eric V. Smith via Python-ideas]

On 12/21/2023 4:38 PM, Steve Jorgensen wrote:

I am finding that it would be useful to be able to define a dataclass that is 
an abstract base class and define some of its field as abstract.

As I am typing this, I realize that I could presumably write some code to 
implement what I'm asking for. Maybe it is a good enough idea to make part of 
the standard API in any case though? I'm thinking that a field would be made 
abstract by passing `abstract=True` as an argument to `dataclasses.field()`.


You're better off discussing this on discuss.python.org as this mailing 
list is basically dead.


And when you do post over there, please provide an example. It's not 
clear what would happen in the generated code if abstract=True.


Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGCCUFTP6KNKZF4ZLPQWWB2WCSM7BR2X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: re.match(pattern, string, require=True)

[Eric V. Smith via Python-ideas]

On 10/21/2023 8:31 PM, Chris Angelico wrote:

On Sun, 22 Oct 2023 at 11:29, MRAB  wrote:

I think what the OP wants is to have re.match either return a match or
raise an exception.

Yes, and my point is that simply attempting to access an attribute
will do exactly that. It's not a silent failure.

Why create a new argument, then mandate that you use it everywhere,
just to achieve what's already happening?


Because the end user message would be much better, and the exception 
would point to the exact line where the match didn't occur, instead of 
some subsequent line.


Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5HRZYV54IUK43VX5WRULEZ6CH3IP35OO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Eric V. Smith via Python-ideas]

On Sep 23, 2023, at 5:37 PM, Dom Grigonis  wrote:It seems that my guess was correct. There was a commit, when only the first part was working:https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381aSince I wrote that commit: no one is saying it’s impossible or overly difficult, just that the benefit of having it doesn’t justify the cost of adding it. Costs include implementation, testing, teaching, cognitive load on all readers, etc.I understand that you think it’s worth the cost. Others, including me, do not.Eric So it does seem that it can be done manageably, while all editors with f-string support would benefit instantaneously without extra effort or unnecessary complications such as `typing` library.Regards,DGOn 23 Sep 2023, at 23:55, Dom Grigonis  wrote:the output will have the _expression_ textThis is exactly what I want. If there was an extra check for validity at parser level, it is a plus.You want to produce a name, that is an identifier. Not necessarily, I want the first part of f’{expr=}’.There are outputs:a) `expr=repr(expr)`b) `repr(expr)`why is it a bad idea to have:c) `expr` without `repr(expr)`?This does cover `identifier only` case as well, but is not limited to it.Is it difficult to achieve? Apologies if I am missing something, but if you know the workings of python, could you point me to where f’{expr=}' is parsed and compiled?Obviously I might be wrong, but it is difficult to believe that it is done in such way, that I can have B, A, but not A without B. Would appreciate if you convinced me with some support for your rather strong statements.Regards,DGOn 23 Sep 2023, at 23:18, Tiago Illipronti Girardi  wrote:I think I did something wrong and we are responding to one another instead of the list, please correct this if you can.Let's start with `f'{name=}'`. This is from the docs (the link has the docs for f-strings, so read it):When the equal sign '=' is provided, the output will have the _expression_ text, the '=' and the evaluated value. Spaces after the opening brace '{', within the _expression_ and after the '=' are all retained in the output. By default, the '=' causes the repr() of the _expression_ to be provided, unless there is a format specified. When a format is specified it defaults to the str() of the _expression_ unless a conversion '!r' is declared.That's not what you want. You want to produce a name, that is an identifier. The semantics of name binding are described here. Which means that you cannot infer the name from the value.Python only deals with values, not names. The names are how you refer to the values. That is the semantics. There's no inverse transformation embedded in the language. That's what everyone is trying to communicate to you.If you pay close attention to the execution model there is a link from the name to the object but not the other way around, so you can't get it from the object. That's it. You need to change the whole execution model (that is the interpreter) to get what you  wantEm sáb., 23 de set. de 2023 às 13:16, Dom Grigonis  escreveu:On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi  wrote:The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, with `str` if it is `s`, or with `ascii` if its `a`.With a new format `id` or `i` it would do nothing, but it could signal to an editor that it is an identifier (editors, I believe, already parse the contents of the curly brackets on f-strings).I know the formatting syntax, I wasn’t clear what your point was. I see now that you are referring to new syntax which does nothing apart from signalling the editor.Your suggestion is leaning towards python adapting to the editor, while I would argue that things are simpler and more robust if editors treat code _expression_ as code _expression_ and strings as strings. Making a mess here does seem like too big of a cost for not so profound benefits of what I am proposing.Identifiers are syntactical constructs in python, they only have semantics given a context, and more than one identifier can have the same semantic meaning in a given context, which makes your proposal a no-go from start.Can you elaborate on this?Given f’{expr=}’ syntax already exists, how is this an issue for my proposal?Except if we were to change the whole execution model of the language.Although I am open to be proven wrong. Could you give an explanation why stripping `repr(expr)` part from f’{expr=}’ and leaving expr literal is problematic, given substituting expr literal is already being done?However, for the "change this identifier from this to that" case (which is an editor problem), subclassing `typing.LiteralString` would basically solve the problem:```x = 6print(typing.Id('x') = f'{x}')```Or import Id from typing to save some keystrokes.With an interpreter change to the f-string we could do something like:```print(f'In this context 

[Python-ideas] Re: [dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.

[Eric V. Smith via Python-ideas]

On 6/23/2023 11:34 AM, Joao S. O. Bueno wrote:



On Fri, Jun 23, 2023 at 12:18 PM Eric V. Smith  wrote:



On Jun 23, 2023, at 9:34 AM, Joao S. O. Bueno 
wrote:




On Fri, Jun 23, 2023 at 2:35 AM Jelle Zijlstra
 wrote:



El jue, 22 jun 2023 a las 8:22, Randolf Scholz
() escribió:

Dataclasses should provide a way to ignore a type hinted
attributes, and not consider them as fields.

For example, some attributes might be derived during
`__post_init__` from the values of the fields or other
variables.

If one wants to still type hint these attributes, one has
to awkward workarounds to avoid having dataclass
interpret them as fields.
(https://stackoverflow.com/questions/76532816)



But it’s not clear (to me) why not being a field is desirable. Why
is it important?


Can't know  - not my design, it was Randolf's question.
They might represent an internal state that should not be relayed on 
serialization or conversion, for example.
I can imagine some scenarios where I'd want some instance attributes 
to be shorter lived and non-transient,
although, I'd more likely build the class "manually" instead of a 
dataclass - or, more likely, put the dataclass under

a wrapper layer that would handle the "perishable" states.

I think you can make dataclasses itself ignore the field by judicious 
use of `field` parameters. If there's some code that's looking through 
`dataclasses.fields` but wants to ignore some fields, irrespective of 
what dataclasses is doing, then I'd say it's on the caller to have a 
list of fields to ignore.


But without knowing the use case, it's hard to say.

Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PTJFEC3EQGP4TDDMF6TA7AENOBTOVMSO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.

[Eric V. Smith via Python-ideas]

On Jun 23, 2023, at 9:34 AM, Joao S. O. Bueno  wrote:On Fri, Jun 23, 2023 at 2:35 AM Jelle Zijlstra  wrote:El jue, 22 jun 2023 a las 8:22, Randolf Scholz () escribió:Dataclasses should provide a way to ignore a type hinted attributes, and not consider them as fields.

For example, some attributes might be derived during `__post_init__` from the values of the fields or other variables.

If one wants to still type hint these attributes, one has to awkward workarounds to avoid having dataclass interpret them as fields. (https://stackoverflow.com/questions/76532816)But it’s not clear (to me) why not being a field is desirable. Why is it important?Eric

I propose `NON_FIELDS` sentinel, analogous to `KW_ONLY`. (alternative name suggestions welcome). when writing a dataclass, all attributes after this sentinel are ignored and not considered fields.

```
@dataclass
class Foo:
    field0: int
    field1: int

    _: KW_ONLY

   fieldN: int

    _: NON_FIELDS

    attr0: int   # @dataclass will ignore this type hint.How is this different from `attr0: int = field(init=False)`?attr0 would be listed as a `field` in the introspectable attributes of the dataclass in this way.That is why I did not suggest that in my initial answer to Randolf on stackoverflow:https://stackoverflow.com/questions/76532816/type-hint-extra-attributes-not-fields/76533091#76533091I like the dataclasses.attribute idea, though - (but it will also require static type checking tools to review theirdataclass special casing - it looks like there is no escape from that).   
```

Additionally one could consider adding an `attribute` typing construct, such that `attr0: attribute[int]` would mark it as a non-field attribute.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P67URFV2JJRFD6J5TXD44EEBO4IRTEYF/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HS5E5XNHKLO47Q6UPF5QVUCIK2FR6VSF/
Code of Conduct: http://python.org/psf/codeofconduct/

___Python-ideas mailing list -- python-ideas@python.orgTo unsubscribe send an email to python-ideas-le...@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/C5QJQT5YV7UOKFF57PWD4VSF4RWUDOSF/Code of Conduct: http://python.org/psf/codeofconduct/___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AIBVZMIW7KYLY3T5Y3FNK2POVSNBIUTJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecate misleading escapes in strings

[Eric V. Smith via Python-ideas]

You should bring this up on https://discuss.python.org/c/ideas/6 , which is 
where ideas are discussed these days. 

This mailing list should be retired. I’ll mention that elsewhere. 

--
Eric

> On Feb 16, 2023, at 9:57 AM, Arusekk  wrote:
> 
> Hi all!
> 
> I was writing a tutorial on the distinction between bytes and strings
> and why it is important, when I saw the root cause.  People coming from
> C, Perl, Python 2 and similar languages tend to misinterpret "\x90" for
> b"\x90" often.  My idea is that Python could deprecate string literals
> containing any non-ASCII codepoints specified in any way different from
> unicode or unicode escapes (\u, \U, \N).
> 
> (Actually I found that I started having the idea already back in 2021 on
> StackOverflow[1].  The question is an excellent example of what I mean.)
> 
> I would not go so far to follow JSON (disallowing \x11 and \222 escapes
> completely), but while writing "\x00" or "\0" is useful and widely used,
> "\x99" (and especially "\777"!) is probably marginal and definitely less
> explicit than "\u0099" (in the Zen of explicit better than implicit).
> Byte strings do not treat b"\u00ff" as b"\xff".
> 
> In the first part of implementing it, Python could raise a SyntaxWarning
> (or should it be DeprecationWarning? BytesWarning?), suggesting "\x99"
> to either become b"\u0099" or b"\x99", eventually promoting it to some
> equally helpful SyntaxError.  All of it could be hidden behind a feature
> like from __future__ import backslashes (one nice name I can think of).
> 
> The new regular expression for octals would be \\[01]?[0-7]{1,2} and
> \\x[0-7][0-9A-Fa-f] for hexadecimals, hopefully not confusing anyone,
> and not much more complex than the old ones.
> 
> In the meantime, probably between introducing a warning and changing it
> to become an error (the most reasonable timeline I can think of now),
> the default ascii() representation should eventually use the \u0099 form
> for all such codepoints, to keep the invariant of eval(ascii(x)) == x
> without syntax warnings.  repr() is also affected, but it is fortunately
> limited to the [\x80-\xa0\xad] range.  I mean [\u0080-\u00a0\u00ad] :-)
> 
> Another timeline would be to change the repr first, initially hidden
> under an interpreter flag or environment variable, then officially
> deprecate it in the documentation, then introduce the error guarded by
> from __future__ import backslashes or another flag, then make the repr
> use \u by default, then add the warning and finally make it always raise
> an error.
> As a precedent, breaking repr() was not a dealbreaker when introducing
> randomized seeds (even repr({"a", "b"}) is now unpredictable).
> 
> This would be of course a breaking change for a lot of unit tests, and
> stuff like pickle should probably support old syntax, delaying any such
> change until a new protocol comes (if it applies to the newest one ---
> quite sure it does not).  Such a breaking change must be used wisely.
> Other changes to octal escapes could be sneaked in, based on conclusions
> from the 2018 'Python octal escape character encoding "wats"' thread[2]
> (I like writing "\0" and "\4" though, just to make my opinion clear).
> If going the whole hog, the 2015 'Make non-meaningful backslashes
> illegal in string literals' thread[3] could be revived as well, maybe
> even with "\f\v" deprecated, "\e" = "\33" introduced and such.
> 
> Please let me know what you think, what else could break, and is it
> useful anywhere else apart from my use case, and what similar problems
> you have.
> 
> Cheers,
> Arusekk
> 
> [1]: https://stackoverflow.com/q/64832281/3869724
> [2]: 
> https://mail.python.org/archives/list/python-ideas@python.org/thread/ARBCIPEQB32XBS7T3JMKUDIZ7BZGFTL6/
> [3]: 
> https://mail.python.org/archives/list/python-ideas@python.org/message/PJXKDJQT4XW6ZSMIIK7KAZ4OCDAO6DUT/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/ITBFU4GPJJVXTHT57WNLASXKL4R4MPF5/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U47V6UYDCA43N5QD4OBANZQDCO3YG2X6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Tagged strings in python

[Eric V. Smith via Python-ideas]

Jim Baker's draft PEP gives runtime behavior to tagged strings. I agree 
it would all be pointless if it's just hints to an editor. Sorry, I 
again don't have a handy link to his PEP. But it's similar in spirit to 
PEP 501.


Eric

On 12/22/2022 2:36 PM, Joao S. O. Bueno wrote:
I am not enthusiastic about this idea at all: as I perceive it it is 
an IDE problem, external to the language, and

should be resolved there - maybe with a recommendation PEP.

But on the other hand, I had seem tens of e-mails discussing 
string-subclassing, so that
annotations could suffice as a hint to inner-string highlighting - and 
then: subclassing is not

really needed at all:
Maybe we can allow string tagging in annotations by using 
`str['html']`, "str['css']"  and so on.
(the typing module even could take no-op names such as "html", "css", 
etc... to mean those
without any other signs, so stuff could be annotated like `template: 
html = ""` which the
the same typing machinery that makes things like `TypedDict`. 
`Required`, etc...
 work would present these as plain "str" to the runtime, while 
allowing any

 tooling to perceive it as a specialized class.


In other words, one could then either write:

mytemplate: str['html'] = " "

Or

from typing import html
mytemplate: html = ...

(the former way could be used for arbitrary tagging as proposed by the
O.P. , and it would be trivial to add a "register" function to 
declaratively create

new tags at static-analysis time.

This syntax has the benefits that static type checkers can take 
full-beneffit of
the string subtypes, correctly pointing out when a "CSS" string is 
passed as
an argument that should contain "HTML", with no drawbacks, no syntax 
changes,

and no backwards compatibility breaks.

On Thu, Dec 22, 2022 at 1:42 AM Christopher Barker 
 wrote:



On Wed, Dec 21, 2022 at 9:35 AM Chris Angelico 
wrote:

>From the look of things, PyUnicode_Join (the internal
function that
handles str.join()) uses a lot of "reaching into the data
structure"
operations for efficiency. It uses PyUnicode_Check (aka
"isinstance(x,
str)") rather than PyUnicode_CheckExact (aka "type(x) is str") and
then proceeds to cast the pointer and directly inspect its
members.

As such, I don't think UserString can ever truly be a str, 



I had figured subclasses of str wouldn’t be full players in the C
code — but join() us pretty fundamental:-(

-CHB
-- 
Christopher Barker, PhD (Chris)


Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/C2HG3QJOU5SLU536CGOJ26VKXVEBZYBH/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/LFWSTEFW46ATMCTRRM6FZYCYX7WQBWSG/
Code of Conduct:http://python.org/psf/codeofconduct/___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/52ERBBVWPRGXKNSVXUQCNC33DYEHTSER/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Tagged strings in python

[Eric V. Smith via Python-ideas]

Jim Baker has been working on tagged strings, and Guido has a working 
implementation. See https://github.com/jimbaker/tagstr/issues/1

I thought Jim had a draft PEP on this somewhere, but I can’t find it. 

--
Eric

> On Dec 17, 2022, at 11:14 AM, e...@emilstenstrom.se wrote:
> 
> 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 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 = ''
>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''. 
> * 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-identifiers
>  - 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_literals#tagged_templates).
>  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 

[Python-ideas] Re: Allow more flexibility for describing bytes objects.

[Eric V. Smith via Python-ideas]

On 11/23/2022 3:02 PM, Chris Angelico wrote:

On Thu, 24 Nov 2022 at 06:46, Barry Scott  wrote:

I have written a lot of low level protocol and IOCTL calls that cannot think of 
a time this would have helped me.
struct is often a mean to create blocks of binary data.

Long strings of binary data would be a maintenance issue. What do all the bits 
mean?

Sounds like a system of compile-time evaluation - as a way to extend
constant folding to more forms - might be the way to do this, then. I
don't think the compiler can optimize this:

x = bytes.fromhex("0123456789abcdef")

and while it's theoretically possible to optimize this, it falls down
badly on the "why was this written like this?" test:

x = b"".fromhex("0123456789abcdef")

But suppose there were some way to say "this is intended to be a
compile-time constant, please evaluate it and retain the result as a
literal". Obviously this is only valid if the result is a type that
can be saved, but it would allow some quite nice optimizations that
might even include struct calls.


PEP 638 – Syntactic Macros would be perfect for this. It gives this 
example for f-strings: "The f-string |f"..."| could be implemented as 
macro as |f!("...")|. Not quite as nice to read, but would still be 
useful for experimenting with."



On the flip side, the performance gain probably wouldn't be all that
much compared to doing the work at import time. For literals used in
tight loops, there'd still be SOME benefit (if the work is done at
import time, it would have to be stored as a global, and that means
the inner loop is looking up a global rather than loading a constant),
but it would have to be a fairly hot piece of code to be worth the
effort.


That would be the beauty of 638: if it's important to one piece of code, 
it could be just enabled there. Of course the implementing macro would 
need to be either part of your application or become a dependency.


But I'm under no delusions that this PEP will ever get accepted, 
unfortunately.


Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3UANICJKEZ7FMNAXCVU7PVBLATJAFOBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Void type

[Eric V. Smith via Python-ideas]

Sorry for top posting: I’m on the road. 

inspect.signature can help with this. 

--
Eric

> On Jul 27, 2022, at 9:22 AM, Chris Angelico  wrote:
> 
> On Wed, 27 Jul 2022 at 22:54, Mathew Elman  wrote:
>> 
>> Chris Angelico wrote:
 Again, I am not pro this idea, just answering the questions you're asking 
 as I see them :)
>>> Yeah. I think you're doing a great job of showing why this is a bad idea :)
>> 
>> I do think the desire to fix the "wrapper not needing to know the defaults 
>> of wrapped" problem is admirable.
>> Is this the right approach? No, I think not.
> 
> Wrapper not needing to know the defaults of the wrapped can be solved
> with *a,**kw. This modifies the problem into "callers of the wrapper
> now don't know anything about the signature". I'd rather look into
> ways of solving that problem instead - ways of taking a function
> signature, making specific changes to it (usually adding and/or
> removing args, but maybe other changes), and then making that your
> declared signature. At the moment, it's only possible to copy a
> signature as is (with functools.wraps() and equivalents).
> 
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/66RPVNZGZS5BLYNNVGPTCHOHXDFMLO2L/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HAXN7644YAHVEGKSQJU4SGSJHNLR6ZWG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Generalized deferred computation in Python

[Eric V. Smith via Python-ideas]

> On Jun 22, 2022, at 2:12 PM, Paul Moore  wrote:
> 
> On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D.  
> wrote:
>> 
>> Hi Martin,
>> 
>> Short answer: yes, I agree.
>> Slightly longer: I would be eternally grateful if you wish to contribute to 
>> the PEP with any such expansion of the Motivation and Expansion.
> 
> One concern I have, triggered by Martin's Dask, PySpark and Django
> examples, is that we've seen proposals in the past for "deferred
> expression" objects that capture an unevaluated expression, and make
> its AST available for user code to manipulate. The three examples here
> could all use such a feature, as could other ORMs (and I'm sure there
> are other use cases). This is in contrast to your proposal, which
> doesn't seem to help those use cases (if it does, I'd like to
> understand how).
> 
> The key distinction seems to be that with your proposal, evaluation is
> "on reference" and unavoidable, whereas in the other proposals I've
> seen, evaluation happens on demand (and as a result, it's also
> possible to work with the expression AST *before* evaluation). My
> concern is that we're unlikely to be able to justify *two* forms of
> "deferred expression" construct in Python, and your proposal, by
> requiring transparent evaluation on reference, would preclude any
> processing (such as optimisation, name injection, or other forms of
> AST manipulation) of the expression before evaluation.
> 
> I suspect that you consider evaluation-on-reference as an important
> feature of your proposal, but could you consider explicit evaluation
> as an alternative? Or at the very least address in the PEP the fact
> that this would close the door on future explicit evaluation models?

Every time I’ve looked at this, I come back to: other than the clunky syntax, 
how is explicit evaluation different from a zero-argument lambda?

Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7OFY7ES6ON3I2QQEVAAATUX2OUHD5L2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a line_offsets() method to str

[Eric V. Smith via Python-ideas]

On 6/18/2022 5:34 PM, Paul Moore wrote:

After all, it has the
advantage of working on older versions of Python (and given that one
of your use cases is Textual, I can't imagine anyone would be happy if
that required Python 2.12+...)


Guido's "no 2.8" shirt apparently didn't stop 2.9 through 2.11!

Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7C5JCOJTDO47R5QDSN7WGOEBABPMIAEX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

[Eric V. Smith via Python-ideas]

On 6/17/2022 10:53 AM, Chris Angelico wrote:

The only two possible behaviours are:

1) It does the single obvious thing: n defaults to the length of
items, and items defaults to an empty tuple.
2) It raises UnboundLocalError if you omit n.

...

Would you prefer that I simply mandate that it be permitted, and then
a future version of Python changes it to be an exception? Or the other
way around? Because I could do that. Maybe it would reduce the
arguments. Pun intended, and I am not apologizing for it.


A third option would be that it's a syntax error for you to define such 
a function. This would be my preferred approach. This way, you can 
always assign semantics in the future. Sure, there are some cases you 
might want to support with the as-specified undefined behavior, but I 
don't think that's a good design.


If CPython 3.x works a certain way (especially if there's a test for 
it), you can be sure that other implementations will work the same way, 
and you can be sure that you can never change the behavior in the 
future. No amount of "but we said it was undefined" will allow us to 
change such behavior.


It would be like 3.7 saying "yeah, we said dicts are ordered in 3.6 but 
you shouldn't count on it, so we're going to make them unordered in 
3.7". It would just never happen.


That all said, I'm still -1 on this PEP, for reasons I won't rehash.

Eric



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XLG4Q2YSKAB5FKEX6EXPTGWOUYQFO3SU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: default as a keyword argument for dict.get and dict.pop

[Eric V. Smith via Python-ideas]

On 6/7/2022 4:59 PM, Chris Angelico wrote:

On Wed, 8 Jun 2022 at 00:36,  wrote:

Hello!

Do you know if there has been discussions around why is the default argument is 
positional only in the dict methods get and pop?

I think

```
d.get(key, default=3)
```

way more readable than

```
d.get(key, 3)
```

specially since max and min builtin functions use default as a keyword argument.

With min and max, it MUST be a keyword argument, because positional
arguments are the values to be compared. So I think the main reason is
"because nobody ever bothered to do it". If there's enough value in
it, that could probably be changed, although mere consistency alone
isn't a very strong argument.


I suspect it's been this way because the API is so old. Now that we have 
Argument Clinic it would be easier to implement as a keyword argument. 
But there may also be a performance issue with keyword arguments vs. 
positional. People are touchy when it comes to dicts!


Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/73OOS3YPUDTZVWFJ5V44X66XZCNXRQV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Addition to fnmatch.py

[Eric V. Smith via Python-ideas]

On 6/5/2022 1:22 PM, Benedict Verhegghe wrote:

Op 5/06/2022 om 18:47 schreef David Mertz, Ph.D.:
Sure, that's nice enough code and has the same big-O complexity. I 
suspect set difference is a little faster (by a constant multiple) 
because it hits C code more, but I haven't benchmarked.


The OP said the elements were from fnmatch though, which explicitly 
does not promise order. So really it's just whether you like your 
code or this better aesthetically:


     list(set(b) - set(a))


I benchmarked it and indeed the list difference is a little faster.
>>> timeit.timeit('s=set(b); [x for x in a if x not in s]', setup='a = 
list(range(1)); b = list(range(1000))', number=1000)

0.6156670850032242
>>> timeit.timeit('list(set(a)-set(b))', setup='a = 
list(range(1)); b = list(range(1000))', number=1000)

0.43649216600169893

And what's more, it seems to also preserve order. I guess because a 
set is implemented like a dict, and will preserve order of you only 
remove some elements from the set.


A set doesn't guarantee order at all, and indeed it does not preserve 
creation order:


>>> s = set([10, 20, 1])
>>> s
{1, 10, 20}

You're seeing an accidental byproduct of the implementation.

Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WZFC3WAOMTQ2UQIMGBJ2VTBBOE5XUWBR/
Code of Conduct: http://python.org/psf/codeofconduct/