[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
I believe that one of the most popular Python domains that benefit from
"abusing" indexes is data analysis in the numpy/Pandas world.
I am not familiar enough with Pandas to make useful speculation on how
named indexes could enhance the usage of dataframes, - maybe someone more
familiar can come up with suggestions on how this syntax could be useful?
On Fri, 10 Jul 2020 at 09:24, Ricky Teachey wrote:
>
>
> On Fri, Jul 10, 2020, 6:54 AM Jonathan Fine wrote:
>
>> Hi All
>>
>> SUMMARY
>> This is a longish post. It looks at the idea in general terms, and
>> outlines a way to get the desired semantics (by not syntax) with Python as
>> it is today. And this would be forward compatible with the new syntax, if
>> provided later.
>>
>
> This post was filled with inspiring ideas for me. Thank you.
>
>
>> PRESENT
>> I like the idea of allowing
>> >>> d[1, 2, 3, a=4, b=5]
>> and will explore it further.
>>
>> First, we can already write
>> >>> f(1, 2, 3, a=4, b=5)
>> but that only works for the get operation. For set the present behaviour
>> is
>> >>> f(1, 2, 3, a=4, b=5) = None
>> SyntaxError: can't assign to function call
>> and I see no good reason to change that.
>>
>> Going further, I'd say that allowing both
>> >>> d[something] = value
>> >>> value = d[something]
>> is essential to the difference between f(something) and d[something].
>> Both are expressions, but only one of them can be assigned to.
>>
>
>
>> Here goes. First syntax.
>> >>> value = d[K(1, 2, 3, a=4, b=5)]
>> >>> d[K(1, 2, 3, a=4, b=5)] = value
>>
>
>
> My mind instantly went to the idea of using this syntax as a way write
> single line mathematical function definitions:
>
> f[x, y] = x + y
>
> The example function doesn't even require the suggested K() object since
> no kwargs or defaults are used.
>
> Of course one would need to instantiate any these single line functions
> using a little bit of boilerplate up top. But this could be when you
> provide the docstring:
>
> f = MathFunction("Simple math function")
> f[x, y] = x + y
>
> And calling them would use a different bracket type (parentheses):
>
> >>> f(1,2)
> 3
>
> ...but these are surmountable hurdles.
>
>> ___
> 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/QKDZ4Y6KBIVEFJ34ITLZHUT4IPE3QBBQ/
> 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/VUY3NPQ2FBAJ4L6LAMR7CU757IQRZFCN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Feature] Body closure
You know you can simply pass functions as parameters, right? def lock(func, *args): # ...setup result = func(*args) #... teardown return result. And then, with 3 more lines you do a decorator out of that def locked(func): # <'lock' body as above> return lock in the end: @locked def mythings(): # code that runs 'locked' ... On Mon, 13 Jul 2020 at 17:48, wrote: > Today I think about lambda in Python and what if we introduce the new > syntax: > ```python > def lock(*args, closure): > # Do some stuff > closure() # Call closure > # Finish stuff > > if __name__ == '__main__': > lock(): > # Do some things here is thread safe > ``` > > This feature could be very similar as in `Kotlin` inline functions > https://kotlinlang.org/docs/reference/inline-functions.html > ___ > 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/HAIFGFE5YUCGLEWFPT3K2N3H6WBK4KQ7/ > 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/QTLUKWVALORYHCS23SUHN4GSEAVOGHZS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Sat, 4 Jul 2020 at 12:51, Random832 wrote: > On Fri, Jul 3, 2020, at 03:57, Wes Turner wrote: > > Can a Sequence be infinite? If so, an equality test of two > > nonterminating sequences would be a nonterminating operation. > > I think not - an infinite sequence would make len, contains, and reversed > ill-defined (it also wouldn't allow certain kinds of slices) > > > Do Sized and *Reversible* imply that a sequence terminates? > > Could __len__ return inf? > > __len__ must return an integer. > > > Perhaps `Ordered` is a requisite condition for defining a comparator > > for Sequences. > > `OrderedSequence`? > > > > Are there unordered Sequences for which a default `__eq__` / `__cmp__` > > (et. al) would be wrong or inappropriate? > > I don't think so [index as a mixin implies being ordered, i think]... the > bigger problem is the one I mentioned earlier, that allowing comparison > between sequences of different types is inconsistent with tuple and list. > As far as types are concerned, the `__eq__` should worry about it - just Sequences that are a subtype of other, or the other being a subtype of one, should be able to compare equal (As happens with lists and tuples as well: subclasses of both will compare equal to base lists and tuples with the same content.). The code for that is on my first reply to Guido, above: if not issubclass(type(other), type(self)) and not issubclass(type(self), type(other)): return False I am actually using that on the file that motivated me sending the first e-mail here -as it makes sense in that project. ___ 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/IVQHP3XAHTNCVAOJQ3BCYXCZU5ZJS4QK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka wrote: > 30.06.20 18:58, Joao S. O. Bueno пише: > > I ended up writting an __eq__ - and in the process I found it is not > > _that_ straightforward due > > to having to check subclasses types when comparing. > > (given Base sequence A, child class B(A), class C(A) and class B1(B) - > > Instances of B and B1 can be > > equal, but instances of B and C should always be different) - or in > > Python, inside __eq__ : > > if not issubclass(type(other), type(self)) and not > > issubclass(type(self), type(other)): > > return False > > It would be more correct to return NotImplemented. > > Also, it is enough to test isinstance(other, type(self)) because > other.__eq__(self) be called first if the type of other is a subclass of > the type of self. > Ah - yes. Half the logic is already on the __eq__ semantics - thanks. Well, I am updating that on my code right now. Anyway I am not seeing anyone opposing this going into col...abc.Sequence - Maybe it is ok for a BPO? (yes, there is this consideration I had, and also Guido, that it would create new behavior in classes that already exist, but I saw no way that could break code not specially crafted to break with this change.) ___ > 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/K2P4ZWF6FIRPCRKUH7IHZHMC7E3HVJER/ > 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/KMG42UKBB3PCVLK6BTW6OQRJWPESLJJI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __eq__ to colletions.abc.Sequence ?
On Fri, 3 Jul 2020 at 03:07, Random832 wrote: > On Wed, Jul 1, 2020, at 08:23, Joao S. O. Bueno wrote: > > collections.mixins.SlicedSequence that would override `__delitem__`, > > `__setitem__` and `__getitem__` and > > handle slices could pair up with the "ComparableSequence" - people > > could use these "a la carte", and > > no backwards compatibility would be hurt. > > This one raises the question of where you put the single-item accessors. Really - I think I had worked on this once, but the slicing support was via decorators. > And sliced __delitem__ may be difficult to implement efficiently without > knowing the internals of the sequence type. > Indeed, as would __setitem__ inserting asequence larger than the target slice - (or shorter). There are log of corner cases there hard to get right. But, yes, it would be so inefficient that probably it is better left for a 3rdy party package than the stdlib. So - let's just drop these out of the proposal and maybe check if Sequence.__eq__ is worth it. > ___ > 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/7HLNBVJSVA5S5EDOK7LFCQNWUMOTJXLS/ > 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/LJO4GXTOT7FYWIRFJDALPA44KH5KLDL7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
If you need custom sort-orders and slicing for dicts, I've implemented
a b-tree backed mapping that can do just that a couple weeks ago -
you are welcome to use it:
https://github.com/jsbueno/extradict/blob/80817e75eabdde5583aa828c04beae6a20d3c4f7/extradict/binary_tree_dict.py#L354
(just "pip install extradict" )
It does not support numeric indexing, though - you'd need a pair of
TreeDict's to do it:
```py
from extradict import TreeDict
a = TreeDict(('abc', 'bar'), ('def', 'foo'), ('ghi', 'baz'), ('jkl',
'bam'))
a["a":"f"]
out: ['bar', 'foo']
b = TreeDict(*((i, key) for i, key in enumerate(a)))
# Using numeric keys for range from 'a' keys:
[(key, a[key]) for key in b[1:4]]
out: [('def', 'foo'), ('ghi', 'baz')]
```
On Mon, 29 Jun 2020 at 08:59, Hans Ginzel wrote:
> Thank you.
>
> On Fri, Jun 26, 2020 at 02:50:22PM -0300, Joao S. O. Bueno wrote:
> >On Fri, 26 Jun 2020 at 14:30, Hans Ginzel wrote:
> >> thank you for making dict ordered.
> >> Is it planned to access key,value pair(s) by index? See
> >> https://stackoverflow.com/a/44687752/2556118 for example. Both for
> >> reading and (re)writing?
> >> Is it planned to insert pair(s) on exact index? Or generally to slice?
> See
> >> splice() in Perl, https://perldoc.perl.org/functions/splice.html.
> >> …
> >>
> >These are odd requirements.
> >
> >No - Python dictionaries are ordered, by order of insertion only, but one
> >can't generally do any manipulation by the numeric index of
> >a dictionary entry - and it will stay that way.
>
> That is fully corret to respect the _insertion_ order.
>
> >If you need such an hybrid data structure, you could just have
> >a list of tuples as data structure, and use collections.abc.MutableMapping
> >to provide a dict-like interface to it (an index for better than linear
> search).
> >
> >I could create such a data structure if you want,
>
> Thank you, I will write it myself.
> H.
>
___
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/FVYEJCS47XAHGT262DYYO3BTZLRHYT5X/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python WebAssembly Support
Thre are already projects that build Python using Web Assembly - But as far as I know, these do not have a good interface with the document DOM. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/ Maybe you'd like to take a look at Brython instead - it is a compliant Python implementatoin that transpiles Python to javascript on the client side - TL;DR: you get to write
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On Fri, 26 Jun 2020 at 14:30, Hans Ginzel wrote: > Date: Fri, 26 Jun 2020 18:47:44 +0200 > From: Hans Ginzel > To: Hans Ginzel > Subject: Access (ordered) dict by index; insert slice > > Hello, > > thank you for making dict ordered. > Is it planned to access key,value pair(s) by index? See > https://stackoverflow.com/a/44687752/2556118 for example. Both for > reading and (re)writing? > Is it planned to insert pair(s) on exact index? Or generally to slice? See > splice() in Perl, https://perldoc.perl.org/functions/splice.html. > > Use case: Represent database table metadata (columns). It is useful as to > access columns both by name and by index as to insert column on specific > position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, > “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or > table storage size optimisation by aligning). > > These are odd requirements. No - Python dictionaries are ordered, by order of insertion only, but one can't generally do any manipulation by the numeric index of a dictionary entry - and it will stay that way. If you need such an hybrid data structure, you could just have a list of tuples as data structure, and use collections.abc.MutableMapping to provide a dict-like interface to it (and even a parallel dictionary to be used as an index for better than linear search). I could create such a data structure if you want, but I don't see that as useful enough to be part of the language. The part allowing slice-assignment seems, actually, quite confusion prone - since in dictionaries the order is order of insertion, not alphabetical order or any other. > Thank you in advance, > Hans > PS1: Named tuples cannot be used, are immutable. > PS2: See > https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash > ___ > 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/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ > 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/JKFZB2AGNPKD55CU75IMZQOCVGCPHMND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On Mon, 29 Jun 2020 at 17:03, Joao S. O. Bueno
wrote:
> If you need custom sort-orders and slicing for dicts, I've implemented
> a b-tree backed mapping that can do just that a couple weeks ago -
> you are welcome to use it:
>
> https://github.com/jsbueno/extradict/blob/80817e75eabdde5583aa828c04beae6a20d3c4f7/extradict/binary_tree_dict.py#L354
>
> (just "pip install extradict" )
>
> It does not support numeric indexing, though - you'd need a pair of
> TreeDict's to do it:
>
> ```py
> from extradict import TreeDict
>
> a = TreeDict(('abc', 'bar'), ('def', 'foo'), ('ghi', 'baz'), ('jkl',
> 'bam'))
> a["a":"f"]
> out: ['bar', 'foo']
> b = TreeDict(*((i, key) for i, key in enumerate(a)))
> # Using numeric keys for range from 'a' keys:
> [(key, a[key]) for key in b[1:4]]
> out: [('def', 'foo'), ('ghi', 'baz')]
>
> ```
>
> (Meh, I was fiddling with the snippet above in thee-mail composotion and
messed it - the
range that is output in the listing is the corresponding to b[1:3], and the
lib outputs it correctly)
___
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/WDPJH6GCBBFNER3U47EHF7EYLIDMNFTT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal to introduce pattern matching syntax
On Mon, 22 Jun 2020 at 13:08, Michael Christensen
wrote:
> Concerning parameters in the as section: I think using `with` would make
> it easier to understand.
>
> try match result:
> as Dog:
> print("Dog")
> as Cat with lives:
> print(f"Cat with {lives} lives")
> as tuple with (arg1, arg2):
> print(f"Tuple with args {arg1}, {arg2}")
> else:
> print("Nothing matched")
>
>
I for one could not even parse the example in the first e-mail. This
version
using "with" makes sense for me.
To start, it should be a starter that between `as` and `:` one should able
to write
an arbitrary Python expression, and not trying to invent yet another new
language
inside Python for this syntax (as what has taken place with annotations)
> Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone
> Get Outlook for Android
>
> --
> *From:* nate lust
> *Sent:* Monday, June 22, 2020 9:17:01 AM
> *To:* python-ideas
> *Subject:* [Python-ideas] Proposal to introduce pattern matching syntax
>
>
> Hello,
>
> I have been working on an idea that would introduce pattern matching
> syntax to python. I now have this syntax implemented in cpython, and feel
> this is the right time to gather further input. The repository and branch
> can be found at https://github.com/natelust/cpython/tree/match_syntax.
> The new syntax would clean up readability, ease things like visitor pattern
> style programming, localize matching behavior to a class, and support
> better signaling amongst other things. This is the tl;dr, I will get into a
> longer discussion below, but first I want to introduce the syntax and how
> it works with the following simple example.
>
> result = some_function_call()
>
> try match result: # try match some_function_call(): is also supported
>
> as Dog:
>
> print("is a dog")
>
> as Cat(lives):
>
> print(f"is a cat with {lives} lives")
>
> as tuple(result1, result2):
>
> print(f"got two results {result1} and {result2}")
>
> else:
>
> print("unknown result")
>
>
The statement begins with a new compound keyword "try match" . This is
> treated as one logical block, the word match is not being turned into a
> keyword. There are no backwards compatibility issues as previously no
> symbols were allowed between try and :. The try match compound keyword was
> chosen to make it clearer to users that this is distinct from a try block,
> provide a hint on what the block is doing, and follow the Python tradition
> of being sensible when spoken out loud to an English speaker. This keyword
> is followed by an expression that is to be matched, called the match target.
>
> What follows is one or more match blocks. A match block is started with
> the keyword ‘as’ followed by a type, and optionally parameters.
>
> Matching begins by calling a __match__ (class)method on the type, with the
> match target as a parameter. The match method must return an object that
> can be evaluated as a bool. If the return value is True, the code block in
> this match branch is executed, and execution is passed to whatever comes
> after the match syntax. If __match__ returns False, execution is passed to
> the next match branch for testing.
>
> If a match branch contains a group of parameters, they are used in the
> matching process as well. If __match__ returns True, then the match target
> will be tested for the presence of a __unpack__ method. If there is no such
> method, the match target is tried as a sequence. If both of these fail,
> execution moves on. If there is a __unpack__ method, it is called and is
> expected to return a sequence. The length of the sequence (either the
> result of __unpack__, or the match target itself) is compared to the number
> of supplied arguments. If they match the sequence is unpacked into
> variables defined by the arguments and the match is considered a success
> and the body is executed. If the length of the sequence does not match the
> number of arguments, the match branch fails and execution continues. This
> is useful for differentiating tuples of different lengths, or objects that
> unpack differently depending on state.
>
> If all the match blocks are tested and fail, the try match statement will
> check for the presence of an else clause. If this is present the body is
> executed. This serves as a default execution block.
>
> What is the __match__ method and how does it determine if a match target
> is a match? This change introduces __match__ as a new default method on
> ‘object’. The default implementation first checks the match target with the
> ‘is’ operator against the object containing the __match__ method. If that
> is false, then it checks the match target using isinstnace. Objects are
> free to implement whatever __match__ method they want provided it matches
> the interface.
>
> This proposal also introduces __unpack__ as a new interface, but does not
[Python-ideas] Re: Proposal to introduce pattern matching syntax
One should never underestimate the power of Guido's time machine. > ___ 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/4JLKRRBP37IFHTGYHV53Z5MLHVDYCVSM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make `del x` an expression evaluating to `x`
On Thu, 12 Mar 2020 at 14:09, Paul Moore wrote:
>
> On Thu, 12 Mar 2020 at 16:57, Eric Wieser wrote:
> >
> > It looks like actually this can be be built as a function today:
> >
> > def move(name):
> > return inspect.currentframe().f_back.f_locals.pop(name)
> >
> > Which works as follows, but it feels awkward to pass variable names by
> > strings (and will confuse linters):
> >
> > >>> for v in itertools.combinations([1, 2, 3], 1):
> > ...print(id(move("v")))
> > 1718903397008
> > 1718903397008
> > 1718903397008
>
> I'm both impressed and horrified by this :-)
>
Even - it just works because it is on the top-level
scope of a module - and would not work
if called from a function, where `locals()` modification
actually do not affect the local variables.
(And that behavior that was sort of "in the air" was
well documented and defined prior to Python 3.8
in PEP 558)
But for the module-level-scope locals() == globals() is just a
plain dictionary, not one working as a proxy to slotted local variables
(And in a class body, locals() is watever is returned from the metaclass
`__prepare__` method )
> Paul
> ___
> 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/42KOI2RBK7PI4IAZZARAANKE5BIKL7KS/
> 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/U7MPJNVBBTFQHK55TBLML7CJFQXPUN75/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Faster object representation for UIs
That is definitely not language-behavior material - and should be a worry of the authors of whatever projects have objects that demand so much processing to generate a "repr". It certainly is not a common problema met with - I often have to deal with cumbersome repr's (even in my own projects), but due to their size. If an object performs recursive external-resource queries just for ordinarily printing a repr, to a point it is getting in the way of interactive use it obviously should not, and should create a separate "full_repr(...)" method for that. note that you can _already_ accept an optional parameter in the `__repr__` method to behave like you proposed - or your `__repr__` could check a setting somewhere to find out the behavior it should have. On Fri, 24 Jul 2020 at 12:14, Gábor Bernát wrote: > Hello, I'd like to bring to your attention > https://bugs.python.org/issue41383. The core idea here is per Elizaveta > Shashkova: > > I would like to have a lazy repr evaluation for the objects! Sometimes > users have many really large objects, and when debugger is trying to show > them in Variables View (=show their string representation) it can takes a > lot of time. We do some tricks, but they not always work. It would be > really-really cool to have parameter in repr, which defines max number of > symbols we want to evaluate during repr for this object. > Maybe repr is not the best here, because that should be interpreter > meaningful, but instead the __str__ method that's better for this. Maybe we > could pass in an optional limit argument to these methods, so that the user > can decide what to print depending on how many characters he has left? > > Any takes, better ideas how we could help this problem? > > Thanks, > > Bernat > ___ > 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/O7TCM7F4XQAMAQJ43C6SAVKC7M2C4QHR/ > 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/ZEEM4G7SFWLAOZ324UYOSH3U7IOZOB2J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: default parameter in fuctions to clean up flow
Anyway, that is feasible via a decorator. Since it can't be done the wya you are proposing as is, since having a function as a default argument is valid Python (and the function is not called) - and having new syntax for this would be more cumbersome than using a decorator, I think that closes the gap. If such a decorator would be useful enough to cut it into the stlib, is another question though - I'd probably find it occasionally useful myself, but even so, I am +0 on this - it is not like ``` if parameter is sentinel: parameter = factory() ``` would be too much to type. On a second thought - proper documenting and giving visibility to a decorator like this could make it be used in patterns like ``` @factoryargs def myfunction(a, b, c=list): pass ``` and we could see a drop in the newcomers to Python putting a `[]` as default argument. Ok - I just convinced myself - I am +1 for such a decorator now. Now, please, the S.O. link. (that is me needing 2 more upvotes to round another 10K rep) On Mon, 27 Jul 2020 at 20:42, Richard Damon wrote: > On 7/27/20 10:01 AM, Peter Moore wrote: > > I have had a long standing unanswered question on on stackoverflow: is > it possible to pass a function to a default parameter so that you could do > in essence things like this. > > > > def time_diff(target_time, curr_time= lambda : datetime.now() ): > > return curr_time - target_time > > > > this would be an syntactical improvement over this style where you have > if statement to initialize a missing parameter. > > > > def time_diff(target_time, curr_time=None): > >if curr_time == None: > > curr_time = datetime.datetime.now() > >return curr_time - target_time > I will point out that you CAN pass a function as the default value of a > function parameter, and it means that the parameter will be bound to the > function itself, so it becomes a callable (so doesn't help you in your > case). But this does become an impediment to trying to define it this > way, you need somehow to distinguish between the function itself being > the default value, or some magically invocation of the function at each > call. > > -- > Richard Damon > ___ > 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/64ZTCJWJO74KD2EFUOSICOPT6XTSBO2R/ > 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/EGFSGULHXBRT2HNEDRN4GJ36DQUSR3RX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
I agree - the three builtin methods are almost the same (not sure if there is any difference at all), while there is no trivial way to check for a valid float, or otherwise a chosen representation of a decimal number without resorting to a try-except statement, or complicated verification schemes that have to deal with a lot of corner cases. For validity one has to check if there are only digits - and decimal points - and the "-" unary sign. What if there is more of a "." in the string? what if the "-" is not the first character? And besides validity checking, there are also validity choices: What if an unary "+" is present? Whitespace ok? "_" as digit separator ok? scientific exponential notation accepted? What about Inf and Nan literals? What about taking into account the locale setting? But maybe, instead of yet another str method, a "parsefloat" function that could get arguments and sensitive defaults for some choices - it could live in "math" or "numbers". I think it would be preferable than, say, adding a lot of options to the `float` constructor. These are the options I can think of the top of my mind: ```python def parsefloat( input: str, /, *, unary_minus: Bool = True, unary_plus: Bool = False, exponential: Bool = False, inf_literal: Bool = False, nan_literal: Bool = False, whitespace: Bool = False, use_locale: Bool = False, digit_separators: Bool = False, base: int = 10 (?), decimal_places: Optional[int]=None(?), enforce_decimal_places: Bool = False(?), raise_on_error: Bool = False(?), ...) -> Tuple[Bool, float]: ... ``` The return value would consitss of a boolean, where True would indicate success, and then the number. Or it could return a single float, returning a NaN in case of parsing error. this is simple callable - but it could be built on top of a class that could take the configurations and parse more than one number - it would be fit as a float parser to be supplied for tasks like Json decoding, or converting values in a Pandas Series. On Sun, 27 Dec 2020 at 14:12, Tushar Sadhwani wrote: > str currently has methods like isdecimal, isnumeric and isdigit, but there > isn't an isfloat check, which could be very handy. > > a trivial implementation could be as simple as: > > try: > float(self) > return True > except ValueError: > return False > ___ > 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/KEUR54FVEE7FRY4RGLK4IGTJOTKXQH5H/ > 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/7FJVCF746GOBTM5OD2TGRUCBGB2VSTIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote: > On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno > wrote: > > > > I agree - the three builtin methods are almost the same (not sure if > > there is any difference at all), > > Yes - they all check if the string matches a particular set of characters. > > > while there is no trivial way to check for a valid > > float, or otherwise a chosen representation of a decimal number without > resorting > > to a try-except statement, or complicated verification schemes that have > > to deal with a lot of corner cases. > > If you want to know whether the float() call will throw, the best way > to check is to call float() and see if it throws. > > > For validity one has to check if there are only digits - and decimal > points - > > and the "-" unary sign. What if there is more of a "." in the string? > > what if the "-" is not the first character? > > And besides validity checking, there are also validity choices: > > What if an unary "+" is present? Whitespace ok? "_" as digit separator > ok? > > scientific exponential notation accepted? What about Inf and Nan > literals? > > What about taking into account the locale setting? > > > > But maybe, instead of yet another str method, a "parsefloat" function > > that could get arguments and sensitive defaults for some choices - > > it could live in "math" or "numbers". > > How about a built-in called "float", which either returns the > floating-point value represented by the string, or signals an invalid > string with an exception? > > > I think it would be preferable than, say, adding a lot of options > > to the `float` constructor. These are the options I can think > > of the top of my mind: > > YAGNI. If you want to allow specific subsets of valid options, it's > not that hard to do your own validation. > > > The return value would consitss of a boolean, where True would indicate > success, and then the number. > > Or it could return a single float, returning a NaN in case of parsing > error. > > Or it could raise in the case of parsing error. That's the Pythonic way. > > Sorry, I thought my message conveyed that I know "float" exists, and try/except is the current usable pattern (it is in the original posting anyway) I tried to make clear this should be in addition to that - But yes, I failed to mention in my message that I think such a function would mostly benefit beginners learning around with "input" and "print" - it is painful to suddenly have to tour the students on several other concepts just to get a correct user-inputed number. (OTOH, yes, for code on this level, one normally won't be concerned if the program user will be typing "1.02e2" on the `input` prompt). The point is exactly that parsing a number correctly, and moreover respecting these options, is subject to error and the stdlib could benefit from a construct that would not require a try/except block for everything. (As you can see, I contemplate that raising may be a desired option for a flexible function, and there is an option for that in my example signature) . 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/F5TGEV5V4ZKAPSD5AI62EJ6YZRKQQPFQ/ > 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/X3DYXKVBABN7IUCQQM7TWL4O3OUPW7U3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: async types?
A while back I could make a proof of concept of this with current Python, no modifications needed. The text is in portuguese -by I believe automatic translation should be enough for the non-code parts. https://pt.stackoverflow.com/questions/390755/%c3%89-poss%c3%advel-definir-como-async-o-m%c3%a9todo-inicializador-de-uma-classe-em-python/390895#390895 Maybe it is worth putting that thing on a Pypi package? On Wed, 25 Nov 2020 at 07:22, Ben Avrahami wrote: > Hi all, this is a general feeler for if this idea has any traction: > > All too often I see the following pattern in asyncio 3rd-party libs, > either in their own source code or in the inusage: > ``` > inst = SomeClass() > await inst.initialize() > ``` > > What happens here is that, since coroutines cannot be used inside __init__ > methods, the __init__ method only stores the parameters, and another, > asynchronous method actually initializes the object. This led many > 3rd-party libs to use factory methods to create their class instances, > which is unideal for both users and developers. We see this pattern in > nearly any async 3rd-party lib I came across. > > To solve this, I propose a new metaclass: `AsyncType`. The core difference > between AsyncType and type is that when called, AsyncType will produce a > coroutine that asynchronously calls __new__ and __init__, and returns the > instance, allowing simply for `instance = await SomeClass()`. In classes of > `AsyncType`, the __new__ and __init__ methods must be async methods > (returning coroutines). > > As an additional syntactic sugar, we could also have an `async > class(base)` declaration that implicitly sets the class's metaclass to be > AsyncType (or raise a TypeError if that is impossible). > > This proposal is obviously incomplete, and there are many open questions: > what about __del__? How would one easily make an async ABC (without a > metaclass conflict)? How would an async class easily inherit from a sync > class (suppose sync class A implements __new__, and async class B(A) > implements __init__)? Perhaps `AsyncType` should only make the __init__ > method async and leave __new__ synchronous? > > I'd just like to get ahead of the (not unjustified) argument that > constructors should be lightweight: > 1. Python's __init__ is not strictly a constructor. It is, as the name > implies, an initializer, that makes the type usable. Constructing the type > without initializing it makes no sense and has no usages, so why seperate > the operations? > 2. We can see numerous examples of (syncronous) connect-on-initialize > classes in the standard library, including ftplib, smtplib, and pretty much > most *lib modules in the standard library "Internet Protocols and Support" > doc page. > 3. The "initialize in a separate method" pattern produces some > strange-looking code where the class holds on to its initialization params > even though it doesn't really need them after the separate methods. The > classes should now also consider and safe-guard against cases where the > separate method is called twice, or not at all. > > What does the community think about this idea? > ___ > 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/DMTLZD6HLY6JTG2WY5RYSXFX3KLZQB46/ > 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/LBAJ3QC3V7GJUTITYD5HBTDSO7RUHKKT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thinking about dead simple import hooks...
And how would Python compute the "full basename of the file to be
imported"?
How could it guess among all directories on sys.path the one containing
the "file", and check if it is a file or a package without going through
the existing mechanism?
Maybe this proposal is good - but possibly, just cutingt the "full
basename" and pass
to the "simple hook" whatever string is on the import statement would be
better.
On Tue, 8 Dec 2020 at 06:30, Paul Sokolovsky wrote:
> Hello,
>
> It would be nice to have a simple and easy way to override module
> importing, instead of that babylon which CPython has in that regard.
> (Even if initially "limited" to filesystem importing, most people
> won't ever find that limiting at all.)
>
> The desired semantics would be:
>
> For "import foo", before "/path1/foo.py", "/path2/foo.py" (where
> /path1:/path2 come from sys.path) is tried to be imported, a
> user-defined hook function can be called. It should take just one param
> - full basename of the module to be imported, e.g. "/path1/foo",
> "/path2/foo" for the cases above. The hook should either return a
> module object, the result of the import, or None to signal that standard
> processing should take place. The hook should be aware that there might
> have been previous hooks, and it's current hook's responsibility to call
> them.
>
> Example of a hook:
>
> def import_hook(path):
> if os.path.exists(path + ".my_ext"):
> mod = imp.new_module("")
> # populate mod here
> return mod
>
> A crucial semantic detail is that all possible module types from one
> sys.path entry should be tried first, before going to the next entry.
> (CPython import extensibility instead seems to be built around idea
> that it's fine to do multiple passes over sys.path, loading only a
> particular extension module type on each pass, which is not the desired
> semantics).
>
> Questions:
>
> 1. Does anybody know such thing to already exist?
> 2. Would you tweak anything in the API/boilerplate semantics of the
> above?
>
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
> ___
> 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/NIQQVA3OJFUHL3INBMBUBMTP24W74XEO/
> 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/NKMLGALBWLXEFKKRXM6MY3ISE64F4AAA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Lazy Type Casting
On Wed, 9 Dec 2020 at 09:27, Mathew Elman wrote: > I agree that if you are using them as iterables, then the type is usually > not important because you are treating their type as just iter-able. The > lazy iterable would more or less just be the same as passing in > `iter(sequence)`. > > This is for other use cases where the use of the object is specific to the > type, e.g. a case where in the outer scope you construct a list and mutate > it but when it is passed to an inner scope, you want to enforce that it can > be accessed but not mutated. Likewise if lazy built in types were > implemented in python then getting a slice of a sequence could also be done > lazily, whereas my understanding at the moment is that it has to create a > whole new sequence. > If you need this for annotations/typing alone, can't you just use `typing.cast` in the inner scope? (or before calling it for that matter) Anyway, mypy at least wil error if you annotate the inner scope as a "Sequence" (in contrast with MutableSequence), and will error if you try to change the Sequence - and it stlll remain compatible with incoming "MutableSequences". For the cases it does not cover, there is still "cast" - and it feels _a lot_ simpler than having actual runtime lazy objetcs as primitives in the language. > ___ > 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/ZQIXX5632QT7QH5YCZGTTLPJ5ZQF7XOH/ > 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/IWY3I4ZTPT2ZV7XFMGGSGOWHT3UOXA53/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add decorator_with_params function to functools module
Is it really worth it? Fact is, while it can shave off some lines of code, I think it is interesting to know _which_ lines of code - Usually when one writes a decorator, it is expected that they will know what they are writing, and will want to be in control of their code. Delegating this to a decorator-decorator that is to be copied and pasted, and will definitely change call-order, and when your decorator is called, is something that I, at least, would be wary to use. Meanwhile, when I want this pattern, it really takes me 2 LoC inside the decorator to have the same functionality, and still be 100% in control of when my function is called: ``` from functools import partial def mydecorator(func=None, /, *, param1=None, **kwargs): if func is None: return partial(mydcorator, param1=None, **kwargs) # decorator code goes here ... ``` So, yes, your proposal has some utility - but I consider it to be marginal - it is the kind of stuff that I'd rather see on a 3rdy party package with extra-stuff to help building decorators than on stdlib. On Mon, 30 Nov 2020 at 17:04, Yurii Karabas <1998uri...@gmail.com> wrote: > The idea of `decorator_factory` is to eliminate boilerplate code that used > to create a decorator with parameters. > > A perfect example is how `dataclass` decorator can be simplified from this: > ``` > def dataclass(cls=None, /, *, init=True, repr=True, eq=True, order=False, > unsafe_hash=False, frozen=False): > def wrap(cls): > return _process_class(cls, init, repr, eq, order, unsafe_hash, > frozen) > > # See if we're being called as @dataclass or @dataclass(). > if cls is None: > # We're called with parens. > return wrap > > # We're called as @dataclass without parens. > return wrap(cls) > ``` > To this: > @functools.decorator_factory > def dataclass(cls, /, *, init=True, repr=True, eq=True, order=False, > unsafe_hash=False, frozen=False): > return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen) > ``` > ___ > 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/NMCDVBOYFXEKZ4L3ASLNYL2NBATJ3VCX/ > 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/OU4VVMBE74KXK6HF6G7LEFP735AJM4G2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making "Any" a builtin
I still like the approach of doing `import typing as t` - (or other short name of ones preference). Bcause in the end, any argument used to bring "Any" as a built-in could be used in favor of any other element in typing anway. Typing "t.Any, t.Union, t.Optional" is not a hassle and immediately readable, even by someone who just opened the file and skipped the "import" session. No need for tens of names from "typing.*" to be on the module namespace (or builtins). On Wed, 2 Dec 2020 at 02:41, Christopher Barker wrote: > They pasted the code / results as screenshots. > > But you got the gist. > > In the future, it's really better to use plain text for email lists. > > -CHB > > > On Tue, Dec 1, 2020 at 9:33 PM Steven D'Aprano > wrote: > >> On Mon, Nov 30, 2020 at 05:19:13PM +0400, Abdulla Al Kathiri wrote: >> >> > In python 3.9, I get the following error: >> > >> > >> > In python 3.10, I get no runtime errors: >> > >> > >> > >> > >> >> Did you forget to paste the text? Or did gmail eat it? >> >> >> > However, Pylance (I am not sure about mypy) didn’t recognize Any. >> Instead it made it “Unknown”. >> >> That's probably a question for the Pylance devs, but my guess is that >> anything flagged as "Any" type is the same as flagging it as "I don't >> know what that type is". >> >> >> > In fact, I can put anything in 3.10 annotation and it runs just fine. >> > I am not sure if this is the intention of Python3.10 >> >> Yes, Python 3.10 makes the `from __future__ import annotations` >> behaviour occur automatically. See PEP 563: >> >> https://www.python.org/dev/peps/pep-0563/ >> >> (At least, I'm guessing that's what is happening here, it has to be a >> guess because I can't see the code you run and the error you get.) >> >> >> >> -- >> Steve >> ___ >> 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/YMJ5NMD3OQOMKWHMMOZAE3WWGHZJD7OY/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Christopher Barker, PhD > > 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/UGRPHAKLN2D7CKHNIZYKW2X6OIIJU6QV/ > 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/CITQTZ72VQLDT5DCGLBPSTIPWZMNKLQA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enable subscription operator for generator expressions
Although that is not a pattern I recall I had needed, but for the first item in a generator, I recognize it is more complicated than it should to be able to do that. However, not only that would be too big a change for all this objects I think one would expect an object providing index access with `[]` to also have a `len`. Also, see it as potentially making a lot of code error-prone: let's say one gets passed a generator where a sequence is expected. In current Python, if an item is accessed by index, one just get an explicit IndexError. If objects change to having indexes, two consecutive access to `gen[1]` will consume the generator and return different values. That could be very confusing. On the other hand, as I said, I can't come up with a simple pattern to get the nth item - so probably we should think of an easy and performant way. One way I can think of is to have a named parameter to the `next` built-in that would allow one to move forward more than one position. Say: `fith_element = next(gen, skip=4) ` and finally, one way I could think of retrieving the n element is: In [19]: a = (i for i in range(0, 100, 10)) In [20]: next(b for i, b in enumerate(a) if i==5) Out[20]: 50 It definitely feels like there should be a simpler way, but I just could not come up with it. On Tue, 17 Nov 2020 at 10:35, Nuri Jung wrote: > How about enabling subscription operator (`[]`) for generator expressions? > Also for all `zip()`, `key()`, etc. They could be evaluated in the > background only for the requested amount, to avoid evaluating the whole > expression to something like a list or tuple, then indexed. > ___ > 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/WDJWOB4NVIIQPJWBNZCF5K4SXZJIARFZ/ > 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/BB4ZMINMSVUG4N5XOB7P25FZW2IRV67K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery
Sorry - personally I think this is absolutely ugly :-) So I will bikeshed. If this thread even go ahead - since the idea is not that bad, maybe allowing `try` on the same line? Then it would be inline with `elif` - but still structured "English like" try: statement except ValueError try: statement2 except TypeError: ... I had sometimes needed 2 and maybe up to 3 levels of this, nothing 'blocker', but maybe, just maybe, it would not be bad. However, in real life, usually one wants to put more statements on the `except` clause than a bare nested try block. (logging, etc...) On Tue, 15 Jun 2021 at 21:58, Chris Angelico wrote: > On Wed, Jun 16, 2021 at 10:51 AM Soni L. wrote: > > > > Sometimes it would be useful to be able to write: > > > > def foo(): > > try: return thing() > > except ValueError; > > try: return otherthing() > > except ValueError; > > try: return yetotherthing() > > except ValueError; > > if shouldraise(): raise > > > > But currently this needs to be written like so: > > > > def foo(): > > try: return thing() > > except ValueError: > > try: return otherthing() > > except ValueError: > > try: return yetotherthing() > > except ValueError: > > if shouldraise(): raise > > > > Look at all that unnecessary indentation! Would be nice to get rid of it. > > Dangerous idea - my first interpretation of that syntax was that it > would be equivalent to "except ValueError: pass", which would be very > confusing (it's subtly different in your example with return, and > drastically different in other cases). > > Are you doing this sort of thing a lot? And if you are, do you > actually need/want the exception chaining that comes from burying more > and more code into the except clauses? I know this is just a trivial > example, but I'd be looking to see if it can be done with a loop > instead. > > def foo(): > for func in (thing, otherthing, yetotherthing): > try: return func() > except ValueError: pass > > or something like that. > > 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/CJCSPO4N3RBGMXDFPT7HHIFROM4BZLN6/ > 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/ISYQKXGEVJOA3SY3SKJ7EZ4TUIS2ZGBC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
On Fri, 14 May 2021 at 09:24, Martin Teichmann
wrote:
> Hi list,
>
> when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code which
> supports higher precision. Decimals come to mind, but also sympy. This loss
> of precision could be avoided if the result of a division is a fraction
> instead: a fraction is exact.
>
"...Although practicality beats purity."
This is a nice idea, but I think this ship has sailed.
Performance reasons apart, I think that most builtin (as in compiled from C
or other native code) calls that expect a float simply won't work
with a Fraction object as it is today in Python.
Yes, not for the drawbacks, this could be nice - but it spells
an avalanche of trouble, a lot of which due to the fact that the Fraction
type
and all concepts in the Numeric Tower, had not sem much active use
in a lot of domains Python is used.
If you take all examples on the static typing frontend, for example,
they all check for "float" when requiring non-integer numbers.
(Instead of, say "numbers.Real") - so almost all type-annotated code
would break with this change.
>
> So when writing Decimal(1/3), currently we lose the precision in the
> division, something that the Decimal module cannot undo. With my proposal,
> the entire precision is retained, and it works as expected. This is even
> more clear for sympy, a Package for symbolic calculations: currently, sympy
> cannot do much about "1/2 * m * v**2", although it looks like a perfectly
> fine formula. But sympy only sees "0.5" instead of "1/2", which is not
> usable in symbolic calculations.
>
> I am aware that this would be a huge change. But we have had such a change
> in the past, from integers having a floor division in Python 2, to a float
> in Python 3. Compared to this, this is actually a small change: the value
> of the result is only different by the small pecision loss of floats. The
> bigger problem is caused by the fact that some code may rely on the fact
> that a value is a float. This can be fixed easily by simply calling
> float(), which is also backwards-compatible, it will work on older versions
> of Python as well.
>
> I have prototyped this here:
> https://github.com/tecki/cpython/tree/int-divide-fraction
> The prototype uses the fractions.Fraction class written in Python as
> result for integer true divisions. I expected that to go horribly wrong,
> but astonishingly it did not. Only a small number of tests of Python fail,
> mostly those where it is explicitly tested whether an object is a float. So
> I lowered the bar even more and tried to compile and test numpy. And also
> there, except some tests that very explicitly require floats, it worked
> fine.
>
> In order to showcase how that would look like, let me give an example
> session:
>
> >>> 5/6-4/15
> 17/30
> >>> a=22/7
> >>> f"{a}"
> '22/7'
> >>> f"{a:f}"
> '3.142857'
> >>> from decimal import Decimal
> >>> Decimal(1/3)
> Decimal('0.')
>
> As a comparison, the same with current Python:
>
> >>> 5/6-4/15
> 0.5667
> >>> a=22/7
> >>> f"{a}"
> '3.142857142857143'
> >>> f"{a:f}"
> '3.142857'
> >>> from decimal import Decimal
> >>> Decimal(1/3)
> Decimal('0.14829616256247390992939472198486328125')
>
> Cheers
>
> Martin
> ___
> 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/RM4JDTGQCOW3MGIKIGEP2BIFOTFFAZI4/
> 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/OCE5TKXEZ3F3UGSLVKPZMHMKA6CH5CQT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add static variable storage in functions
You can just use nonlocal variables: def stator(): static_var_1 = 0 def myfunc(n): nonlocal static_var_1 static_var_1 += n return static_var_1 return myfunc myfunc = stator() del stator Or you can attach any variable to the function itself: def myfunc(n): if not hasattr(myfunc, "static_var_1"): myfunc.static_var_1 = 0 myfunc.static_var_1 += n return myfunc.static_var_1 There are several options to get the effect that static variables would have, not to mention that states of this type are better held as class attributes anyway. BTW: # callable singleton - AKA "function": class myfunc(metaclass=lambda *args: type(*args)()): def __init__(self): self.static_var_1 = 0 def __call__(self, n): self.static_var_1 += n return self.static_var_1 Or, as you put it in the first e-mail, the static var could be built into a data structure in the default arguments of the function. (There are also contextvars, threading.local, etc...) I can't see a separate "static" declaration being of any use. Beginners needing the functionality should just resort to either globals or plain classes to keep state. As you get the way Python works, there are plenty of ways to keep the state, without making the language more complicated. On Thu, 27 May 2021 at 14:06, Chris Angelico wrote: > On Fri, May 28, 2021 at 2:44 AM Shreyan Avigyan > wrote: > > > > My proposal is somewhat the sum of all of your ideas. Well I propose > there should a STORE_STATIC_FAST opcode that stores a static variable. > Static variable will be declared only once and will be initialized to None > (statement syntax will be similar to that of global). It will be > initialized in MAKE_FUNCTION. Now it will be set by STORE_STATIC_FAST. > Where will the variables be stored? It will have references in locals and > __statics__. Therefore LOAD_FAST can find it. So I don't hope there will be > performance decrease but performance increase is also not guaranteed. :-) > > > > The duplicated store fixes half the problem, but it still fails on the > recursion example that I posted in reply to Steve. It would be a nice > optimization, but it may or may not be sufficient. > > > And if these are thread unsafe then is __defaults__ also thread unsafe? > > > > Thread safety isn't a problem with constants. Python guarantees that > internal details (like CPython's reference counts) aren't going to be > trampled on, and inside your code, nothing is going to change > __defaults__ (unless you're doing something bizarre, in which case it > isn't about __defaults__ any more). Thread safety only becomes an > issue when you have something like this: > > counter = 0 > def get_next(): > global counter > counter += 1 > return counter > > This disassembles to: > > 6 0 LOAD_GLOBAL 0 (counter) > 2 LOAD_CONST 1 (1) > 4 INPLACE_ADD > 6 STORE_GLOBAL 0 (counter) > > 7 8 LOAD_GLOBAL 0 (counter) > 10 RETURN_VALUE > > A context switch can happen between any two of those instructions. > That means one thread could load the global, then another thread could > load the same value, resulting in both of them writing back the same > incremented value. Or, between opcodes 6 and 8 (between the lines of > Python code), you could store the value, then fetch back a different > value. > > None of this is a problem if you're using constants. The only reason > to use statics instead of global constants is performance - the > "len=len" trick is specific to this performance advantage - but you > don't have to worry about thread safety. > > 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/DD62RX2ZFOOKQFIHXRFH2LABOFYE4HSZ/ > 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/3BWG6CPWAVS4POG6WICZOHPVHNWWJTUT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add static variable storage in functions
On Thu, 27 May 2021 at 10:39, Paul Moore wrote: [...] > the performance aspect, function > attributes provide this functionality, but there's a significant > problem with using them because you can't access them other than by > referencing the *name* of the function being defined. > [...] > > It would be nice to have a better way to reference function attributes > from within a function. (This would also help write recursive > functions that could be safely renamed, but I'm not sure many people > would necessarily think that's a good thing ;-)) > Now, yes, being able to reference a function from inside itself is a feature I had missed over the years. > > Paul > ___ 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/QVECOJRFJ4DVIN4CV3RH5T2AAPRWBF4P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: String comprehension
I started seeing this, as the objecting people are putting, something that
is
really outside of the scope.
But it just did occur to me that having to use str.join _inside_ an
f-string
expression is somewhat cumbersome
I mean, think of a typical repr for a sequence class:
return f"MyClass({', '.join(str(item) for item in self) } )"
So, maybe, not going for another kind of string, or string comprehensions,
but rather for
a formatting acceptable by the format-mini-language that could do a "map to
str and join" when
the item is a generator?
This maybe would: suffice the O.P. request, introduce no fundamental
changes in the
way we think the language, _and_ be somewhat useful.
The example above could become
return f"MyClass({self:, j}"
The "j" suffix meaning to use ", " as the separator, and map the items to
"str"
- this, if the option is kept terse as the other indicators in the format
mini language, or
could maybe be more readable (bikeshed at will) .
(Other than that, I hope it is clear I am with Steven, Chris, Christopher
et al. on the objections
to the 'string comprehension' proposal as it is)
On Sat, 1 May 2021 at 17:36, Christopher Barker wrote:
>
>
> On Fri, Apr 30, 2021 at 11:15 PM Valentin Berlier
> wrote:
>
>> > You could say that f-strings are redundant because they can't do
>> anything that str.format can't, but they make it possible to shave off the
>> static overhead of going through python's protocols and enable additional
>> optimizations.
>
>
> But that was not the primary motivator for adding them to the language.
>
> Nor is it the primary motivator for using them. I really like f-strings,
> and I have never even thought about their performance characteristics.
>
> With regard to the possible performance benefits of “string
> comprehensions”: Python is already poorly performant when working with
> strings character by character. Which is one reason we have nifty string
> methods like .replace() and .translate. (And join).
>
> I’d bet that many (most?) potential “string comprehensions” would perform
> better if done with string methods, even if they were optimized.
>
> Another note that I don’t think has been said explicitly— yes strings are
> Sequences, but they are a very special case in that they can contain only
> one type of thing: length-1 strings. Which massively reduces the possible
> kinds of comprehensions one might write, and I suspect most of those are
> already covered by string methods.
>
> [actually, I think this is a similar point as that made by David Mertz)
>
> -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/Z3J727MCT46XPDUAEQLH7ZWEKO7QZKTX/
> 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/OX7F5N5KPOEBD27OBZAGWQBTA3SDJNAO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow syntax "func(arg=x if condition)"
I've missed this feature on occasion as well. +1 for whatever that counts; On Mon, 22 Mar 2021 at 17:30, Caleb Donovick wrote: > Never needed this for lists but definitely had the pain for kwargs. Seems > very reasonable for that use case, +0.5. > > In libraries I control I can make sure to use the same default values for > functions and their wrappers. > However when wrapping functions I don't control there is not a great way > to do this. And I end up > incrementally building up a kwargs dict. I suppose the same thing could > occur with *args lists so it makes sense for > both positional and keyword arguments. > > Yes one could do something like: > ``` > def fun(a, b=0): ... > def wraps_fun(args, b=inspect.signature(fun).parameters['b'].default): ... > ``` > But I would hardly call that clear. Further it is not robust as would > fail if `fun` is itself wrapped in way > that destroys its signature. E.g.: > ``` > def destroy_signature(f): > # should decorate here with functools.wraps(f) > def wrapper(*args, **kwargs): > return f(*args, **kwargs) > return wrapper > ``` > > Caleb > ___ > 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/2EHOQDIIK7BMAY54KG44Z45IYWDDSZSW/ > 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/TWZVNIEE3R2ZLMSLPUCC27DJI5XH6MY3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
Sorry - previous reply was sent empty. So, you probably can do with `asyncio.run`: ``` In [26]: import asyncio In [27]: asyncio.run(asyncio.sleep(2)) ``` https://docs.python.org/3/library/asyncio-task.html#asyncio.run On Wed, 24 Mar 2021 at 06:44, wrote: > It is not the same, it will work in interactive mode But I want to > run application without interactive mode > ___ > 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/O4ME7K7ZVXULFBLAVTP3CTKLXI6O4R65/ > 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/ISSAANO5V63MDYFP2UV3MABJLZM3LDVA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
On Wed, 24 Mar 2021 at 06:44, wrote: > It is not the same, it will work in interactive mode But I want to > run application without interactive mode > ___ > 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/O4ME7K7ZVXULFBLAVTP3CTKLXI6O4R65/ > 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/IKC4YHVBICRWFBM4LU5JWBRJGC5QYF2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, 17 Feb 2021 at 15:31, Ethan Furman wrote: > On 2/17/21 8:47 AM, Random832 wrote: > > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: > > >> except a couple of characters. So what currently looks like > >> > >> some_list.sort(key=lambda e: e[3].priority) > >> > >> would then be > >> > >> some_list.sort(key=(e)->e[3].priority) > > > > Let's not pretend the key argument being keyword-only isn't a wart. > Surely this would be better if it could be some_list.sort(e->e[3].priority). > > No need to pretend, it isn't a wart. > > -1 on removing the lambda keyword. Just because excessive punctuation > works for other languages does not mean it's a good fit for Python. > > Indeed - I think typing `import this` is enough to see that this change would directly contradict 6 of the first 7 guidelines in the zen. If someone comes with a "pythonic" way to lift restrictions on lambda, that could be something for debate, but so far this is just about uglifying it, and creating a new syntax matching exactly what exists today. Moreover I'd like to remind people so much worried about expressiveness in less and less characters that Lambda is much less needed in Python than in similar languages due to the existence of the comprehensions and generator expression constructs. The energy spent here could be focused instead on having an equivalent of comprehensions for "reduce", for example. > -- > ~Ethan~ > ___ > 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/IU7DEE5WZFWDKFDPUZAYCV5DPGFGSAJK/ > 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/POJMDVA5WPCOXJUHCQPPK5ZE6ZW6GOXM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri < alkathiri.abdu...@gmail.com> wrote: > How is this not pythonic? > > series.apply(x -> x**2) > Compared to.. > series.apply(lambda x: x**2) > > > (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can write it > without parenthesis like the example above) are pythonic enough to my eyes. > Well, for m eyes, the above is definetellly "perlonic" . it could be "j" before being Pyrhon. This is Pythonic: def f1(x, y): return x + y def f2(): return 0 def f3(x): return x ** 2 And it took me a while looking at our example to check it was not really fuction composition with default parameters, or what. I mentioned violation of 6 of the first 7 phrases in the famous "zen of Python" - most important of which can be reasonably agreed is the 7th: "Readability counts". If you don't want readability at all in exchange for typing a few keywords (which more and more automatic tools can auto-complete), I'd suggest going for the "forth" language. Abdulla > > On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno > wrote: > > If someone comes with a "pythonic" way to lift restrictions on > lambda, that could be something for debate, but so far this is > just about uglifying it, and creating a new syntax matching > exactly what exists today. > > > ___ 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/GL4TPNMIDZTH63WO6E6QNZX57NGYZH2L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: multiprocessing: hybrid CPUs
So, It is out of scope of Pythonmultiprocessing, and, as I perceive it, from the stdlib as a whole to be able to allocate specific cores for each subprocess - that is automatically done by the O.S. (and of course, the O.S. having an interface for it, one can write a specific Python library which would allow this granularity, and it could even check core capabilities). As it stands however, is that you simply have to change your approach: instead of dividing yoru workload into different cores before starting, the common approach there is to set up worker processes, one per core, or per processor thread, and use those as a pool of resources to which you submit your processing work in chunks. In that way, if a worker happens to be in a faster core, it will be done with its chunk earlier and accept more work before slower cores are available. If you use "concurrent.futures" or a similar approach, this pattern will happen naturally with no specific fiddling needed on your part. On Wed, 18 Aug 2021 at 09:19, wrote: > Hello, > > before posting to python-dev I thought is is the best to discuss this > here. And I assume that someone else had the same idea then me before. > Maybe you can point me to the relevant discussion/ticket. > > I read about Intels hybrid CPUs. It means there are multiple cores e.g. > 8 high-speed cores and 8 low-speed (but more energy efficient) cores > combined in one CPU. > > In my use cases I do parallelize with Pythons multiprocessing package to > work on millions of rows on pandas.DataFrame objects. This are task that > are not vecotrizable. I simple cut the DataFrame horizontal in pieces > (numbered by the available cores). > > But when the cores are different in there "speed" I need to know that. > e.g. with a 16 core CPU where half of the cores low/slow and every core > has 1 million rows to work on. The 8 high speed cores are finishing > earlier and just waiting untill the slow cores are finished. It would be > more efficient if the 8 high speed cores each would work on 1,3 million > rows and the low speed cores each on 0,7 million rows. It is not perfect > but better. I know that they will not finish all at the same timepoint. > But their end time will be closer together. > > But to do this I need to know the type of the cores. > > Am I wrong? > > Are there any plans in the Python development taking this into account? > > Kind > Christian > ___ > 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/C3BYESZBZT2PNQSWCW3HGD25AGABJGOJ/ > 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/K4MVBQMCOVE64CG76WSBXH5MJZSWRQ3Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
On Tue, 14 Sept 2021 at 22:59, David Mertz, Ph.D.
wrote:
> I think this would be convenient.
>
> And yes, it's not thread safe. But neither is os.chdir() to start with.
> Someone whose script, or library, wants to chdir can already shoot
> themselves in the foot. This makes that slightly less likely, not more.
>
The problem is someone thinking that by using this they would not be
shooting themselves on the foot
because "wow, a 2021 adition to the stdlib will certainly be thread and
async safe".
I am with Chris Angelico in that this would be dangerous.
>
> In terms of the bikeshed color, I think putting this in `pathlib` is the
> best approach for "modern Python."
>
OTOH, on Pathlib we could have a proper implementation that could take care
of _all_ in context file operations, and internally use absolute paths
(instead
of calling chdir). Such an implementation would work.
```
with Path("/tmp").workdir as mydir:
with mydir.open("myfile"):
...
```
and maybe could be practical enough to stirr people away from "chdir".
>
>
> On Tue, Sep 14, 2021, 7:37 PM Cameron Simpson wrote:
>
>> On 15Sep2021 07:50, Chris Angelico wrote:
>> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
>> >> I know I'm atypical, but I have quite a lot of multithreaded stuff,
>> >> including command line code. So while it'd be ok to avoid this context
>> >> manager for my own code, I fear library modules, either stdlib or pypi,
>> >> quietly using this in their code, making them unuseable in the general
>> >> case. Unrepairably unuseable, for the user.
>> >
>> >Library code shouldn't be changing the working directory, context
>> >manager or not. That belongs to the application.
>>
>> Entirely agree.
>>
>> I'm concerned that convenient stackable chdir is a bug magnet, and would
>> creep into library code. Maybe not in the stdlib, but there's no point
>> writing such a context manager if it isn't goingg to be used, and
>> therefore it could get used in library code. Imagine when a popular pypi
>> module starts using it internally and breaks a multithreaded app
>> previously relying on it?
>>
>> ___
> 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/KM6NEMJTUIMRTRTR4IZCW3CAZ264JBY2/
> 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/6SURJ3IUMBH7IJTHQTZLOYXAY4SLFHIM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a decorators called @staticproperty
All that is needed is a descriptor which calls the decorated functiosn
without any parameters.
This could serve to use classes as namespaces for "live" globals - if one
will do some sort
of reactive programing, it might even find some use.
A descriptor with a for that would be something like:
class staticproperty:
def __init__(self, func, setter=None):
self.func = func
self.setter = setter
def __get__(self, instance, owner):
return self.func
# setter code (won't work statically)
def __set__(self, instance, value):
return self.setter(value)
def setter(self, func):
return type(self)(self.func, func)
I wrote the "setter" code above, but actually it won't work statically -
for the descriptor protocol to call __set__ it must be operating with an
instance of the class. It could still work involving metaclasses - but if
you want the
setter only, the above snippet should work.
Should it be on the stdlib? I don't think so - its usage would be too
specific, and
there are differing interpretations to what it should actually do.
On Sat, 18 Dec 2021 at 14:23, Christopher Barker
wrote:
> I'm confused about what a staticproperty would even be.
>
> Usually, properties are a way to provide an interface that "looks like" a
> simple attribute, but does some computation under the hood. But that
> computation usually requires instance data to do its thing -- so a static
> one wouldn't be useful.
>
> In fact, in Python, a staticmethod is not very useful at all anyway, all
> it is is a function that lives in the class namespace. Making it a property
> would make it look like a class attribute.
>
> Hmm, I guess one use case would be to make a read only class attribute.
>
> Anyway, the thing is that both staticmethod and property are implimented
> using descriptors, which I think can only be invoked by instance attribute
> lookup. That is, the class attribute IS a descriptor instance.
>
> And Chris A says -- there may be a way to get a similar effect with
> Metaclasses, but we'd have to know what your goal is to advise on how to do
> that.
>
> Note: you can put a descriptor on class, and the __get__ will be called,
> to get part of what I think you want:
>
> In [52]: class Ten:
> ...: def __get__(self, obj, objtype=None):
> ...: return 10
> ...: def __set__(self, obj, value):
> ...: raise AttributeError("attribute can not be set")
> ...:
>
> In [53]: class A:
> ...: y = Ten()
> ...:
>
> # attribute access does call the descriptor's __get__:
>
> In [54]: A.y
> Out[54]: 10
>
> But setting the attribute replaces the descriptor, rather than raising an
> exception:
>
> In [55]: A.y = 12
>
> In [56]: A.y
> Out[56]: 12
>
> Honestly, I don't quite "get" how all this works, but the usual thing is
> for Descriptors to be invoked on instance attribute access.
>
> -CHB
>
>
> On Sat, Dec 18, 2021 at 8:30 AM wrote:
>
>> In the following situations:
>>
>>
>> class Data(object):
>> @staticmethod
>> @property
>> def imagesTotal():
>> return 10
>>
>> print(Data.imagesTotal)
>>
>>
>> The "print(Data.imagesTotal)" can't print "10", it print "> object at 0x...>".
>>
>> It might be a good idea to use "@staticproperty" to solve this problem.
>> "@staticproperty" is a decorators, it mix the @staticmethod and @property.
>> Then the static property has getter and setter.
>> ___
>> 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/DEC3AA2NN5KTI5LQ6M7FIRLPDYLNSP7G/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> 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/7WACW25ZZELEMVWE6CAX7DICPIJUXGYC/
> 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/BHHMB75QGOVCA5SU6QU57EDQHY4RN2TQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Thu, 9 Dec 2021 at 17:54, deavid wrote: > Hi, I would like to hear the opinion of Python's community on enforcing > types in the future for the language. > here goes opinion: "no"! strong no. while _using_ tooling that have correct typing is a bit easier, it can make it hard to write code, code harder to read, and in some instances, simply make it almost impossible type correctly what once has been one of the best features of the language: things that are broad into what they accept, strict in what they return, while not being ambiguous. As an example, I will let you with the buitin functions "min" and "max". Write teh pure-Python correct annotation for those, and you will understand what people mean by "typing can be painful". Moreover, you missed that there are very different profiles of Python users. Professional coders working in big projects can take advantage of all the points you listed - but a lot of people just want a way to "give orders to the computer". ___ 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/X7WS7IOT5Q7ECXIX3OWXQSEHY5A7PMFS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
Just a short one, for everyone agreeing type.Annotated does the job, but thinks we need new syntax, because it is verbose: You can already do: from typing import Annotated as A And: attr: A[type, "docstring goes here"] I see no need for any new syntax. (and maybe adding typing.Docstring for the cases when one just wants the docs, but no type annotation) On Tue, 14 Dec 2021 at 06:19, Steven D'Aprano wrote: > On Tue, Dec 14, 2021 at 12:38:55AM +0900, Stephen J. Turnbull wrote: > > Steven D'Aprano writes: > > > On Sun, Dec 12, 2021 at 08:44:25PM -0500, Ricky Teachey wrote: > > > > > > class C: > > > > x: Annotated [Any, "spam"] > > > > > > > > help(C.x) > > > > > > > And it seems reasonable to try and create a way for it to work. > > > > > > By default, for arbitrary classes, no, it *shouldn't* work, because > for > > > arbitrary classes we cannot treat type hints as doc strings. > > > > Why not? In the sense that we establish a standard protocol for > > attaching them, and if there isn't one there, then 'help' would ignore > > that attribute or provide an empty docstring or whatever default > > action seems appropriate (presumably it would at least tell us the > > type! even if the hint is not an Annotated). > > Anything is possible! And if this is for your own code you can do > anything you like. > > But if you want this to be a language feature, that means getting > Steering Council approval, and while I don't speak for them, I am > confident, well, 90% confident, that they will agree with Guido that > *annotations are primarily for type-hinting*. > > I am also confident (say, 75% confident) that they will *disagree* that > annotations are **only** for type-hinting, so there is that. > > But of course if anyone thinks different, and believes that the SC will > bless "string annotations are docstrings" as a language feature, write a > PEP and go for it! > > > > At least not without buy in from the core devs, including people like > > > Guido who care very much about typing. And that will probably need a > > > PEP. > > > > It's true that changing help will require buy-in from the core devs, > > as it's a built-in. But: > > > > > But to change the language > > > > Where's the language change? What am I missing? Or are you using > > this loosely to include builtins or even the whole stdlib? > > Yes, it is somewhat loose, meaning the language proper, the builtins and > stdlib. > > Right now, we have: > > class C: > attr: expression > > causes the annotation to be stored in the `__annotations__` dunder. If > all you want is to write your own metaclass or decorator to read the > __annotations__ and extract strings and stick them into C.mydocstrings, > you can do that right now, no questions asked. > > But if you want to use a dunder like __attrdocs__, say, then dunders are > reserved for use for the language and we're supposed to ask first before > inventing new ones. So there's that. > > And if you want this to new behaviour -- extracting strings from > annotations to use as docstrings -- to be in the language (including the > stdlib and builtins) then again we need approval. At the very least we > need at least one core dev to review, accept and merge the PR. And I > expect that the core devs would push it back to the typing group and > SC for a decision. > > (That's what I would do if I knew how to merge PRs :-) > > > > It needs one thing: a standard place to put the documentation. I don't > > think just stuffing a string in __metadata__ is a good idea; that will > > be an annoyance to existing users of the __metadata__ attribute. > > There is no guarantee or language-wide meaning to the metadata, every > consumer of Annotated type aliases *must* be prepared to skip metadata > they don't know how to process. > > It's like consumers of email. The email headers can contain arbitrary > metadata that you have no clue how to handle, you are required to leave > it and skip over it. > > But the beauty of Annotated is that it already exists and we can start > using it today. If anyone wishes to push for a syntax change, or a new > convenience type in the typing module: > > attr: Docstring["this is a doc string"] > > then you can do so, but you will still have to get the change approved. > > And what are type checkers supposed to do with it? Now every type > checker has to learn to try Docstring as an alias for Any. What if you > want to declare a type as well? > > > > I think it probably should be an attribute on Annotated instances, to > > avoid tromping on existing uses of the __metadata__ attribute, > > Is there a syntax change? If there is, then you definitely need SC > approval for syntax changed. > > If not, how does the Annotated type know which piece of metadata gets > moved into the attribute? > > Annotated[Any, fe, fi, fo, fum, "docstring", eeny, meany, miny, mo] > > *We* can recognise that clearly item number 5 is the docstring, but how > does
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
> On Mon, 14 Mar 2022 at 23:35, wrote:
> >
> > Currently:
> > l = [] # new empty list
> > t = () # new empty tuple
> > s = set() # new empty set (no clean and consistent way of initializing
> regarding the others) <<<
> > d = {} # new empty dictionary
> >
> > Possible solution:
> > s = {} # new empty set
> > d = {:} # new empty dictionary (the ":" is a reference to key-value
> pairs)
>
> Nope, that would break tons of existing code. Not gonna happen.
>
Of couse not. (And I mean it).
- but what about keeping what exists and adding {,} for an empty set?
(it is not that unlike the one-element tuple, which already exists)
>
> 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/PCPZPHCNXOW6ADAOUXY25MTRDNXI4EQI/
> 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/LLS7SPT4XHLDCSHHKK3ZKXTHKA4R2LMV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary
Do you know what else would work for being able
to enter empty sets?
A prefix to {} , like "s"
a = s{}
and
b = f{}
for an empty frozenset
(/me ducks, and hides in a place Chris won't find me)
On Mon, Mar 14, 2022 at 10:29 AM Chris Angelico wrote:
> On Tue, 15 Mar 2022 at 00:07, Joao S. O. Bueno
> wrote:
> >
> >
> >
> > On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
> >>
> >> On Mon, 14 Mar 2022 at 23:35, wrote:
> >> >
> >> > Currently:
> >> > l = [] # new empty list
> >> > t = () # new empty tuple
> >> > s = set() # new empty set (no clean and consistent way of
> initializing regarding the others) <<<
> >> > d = {} # new empty dictionary
> >> >
> >> > Possible solution:
> >> > s = {} # new empty set
> >> > d = {:} # new empty dictionary (the ":" is a reference to key-value
> pairs)
> >>
> >> Nope, that would break tons of existing code. Not gonna happen.
> >
> > Of couse not. (And I mean it).
> > - but what about keeping what exists and adding {,} for an empty set?
> > (it is not that unlike the one-element tuple, which already exists)
>
> That's more plausible. However, the one-element tuple is actually
> written like this:
>
> t = x,
>
> The parentheses are a common form of clarity (and included in the
> repr), but aren't actually the part of the syntax that makes it a
> tuple - the comma is. So there's no real parallel, and it's basically
> "what can we write that wouldn't be ambiguous?", which is a weak
> justification.
>
> Unfortunately, Python simply doesn't have enough symbols available.
> Using precisely one opener/closer for each type is highly limiting,
> since the only characters available are those on a US-English keyboard
> and in the ASCII set. It would be nice if, for instance, ∅ could mean
> "new empty set", but then we'd need a way to type it, and it'd end up
> coming right back around to "just type set(), it's easier".
>
> I wonder what it would be like to have a fork of Python that
> introduces some non-ASCII non-US-English syntax, purely to give people
> a chance to play around with it. Someone might actually set up an
> editor feature so that "set()" transforms into "∅", not just visually
> but in the file, and since it's restricted to an input feature in the
> editor, it avoids the usual problems of "what if you shadow the name
> set". Who knows? Maybe it would catch on, maybe it wouldn't.
>
> It's not all that difficult to hack on Python and add this feature. I
> did it a while back, but since I didn't use sets enough to bother
> figuring out an input method, didn't end up using it. If you want to
> write it as a pure source-code transformation, {*()} is a syntax-only
> way to generate an empty set, so it'll guarantee that you don't run
> into name shadowing issues; but it would be better to make it actual
> syntax (and thus avoid unpacking a tuple into your set for no reason),
> and also change the repr accordingly.
>
> 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/NYNTWQKJM4NOC72UPHVTUOUFCECYMZNW/
> 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/3465RMUBJBH453BNS4L2F7JCFYYWKBNA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
I'd be in favor of a nice syntax for named mapping unpacking.
But while we are at discussion - I'd point out it is "possible" (not easy)
with
current day syntax, by abusing the command "import" -
One can set appropriate import hooks that would enable
either for the current module, or maybe, in a context ("with") block
the use of import targeting a variable - so, the syntax
from mymap import key1, key2
can work.
Downside: it will be much slower than an assignment.
I have something similar working, but it is currently based
on monkey patching builtins.__import__ - upgrading it to properly
using the import machinery is on the roadmap.
On Fri, Feb 11, 2022 at 8:25 AM Matsuoka Takuo
wrote:
> On Fri, 11 Feb 2022 at 04:02, Christopher Barker
> wrote:
> >
> > Just one note:
> >
> > On Thu, Feb 10, 2022 at 6:56 AM Chris Angelico wrote:
> >>
> >> > (2) For the form of the assignment target, I think an analogy with the
> >> > reception of function arguments could also be considered.
> >
> >
> > I think so -- maybe only because it's new, but folks are certainly far
> more familiar with **kwargs than pattern matching.
>
> Structural pattern matching does a more general assignment than
> happens at passing of function arguments. So the latter is simpler,
> but is sufficient (at least conceptually) for the form of assignment
> considered here. However, both of them may lead to distinct pieces of
> syntax, both of which might possibly be useful.
>
> Best regards,
> Takuo Matsuoka
> ___
> 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/N6MXW3HNFJBBUY3BCJBQTGA6WGEQGDMI/
> 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/UC57YSWO7KLAXADXE5UCL3ILP4W7ZNMO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
TL;DR: You know you can call the method on any class you want just by explicitly writting the class name instead os "super()" don't you? That said, the current MRO (and super) behavior is what folks arrived at almost 20 years ago, the "C3 algorithm", in Python 2.3 after a little tweak from the behavior of new-style classes in Python 2.2. It is doucmented here - https://www.python.org/download/releases/2.3/mro/ - and it is the "least surprise" and "most correct" way to do it, as the document itself explains. In particular, as it gets to what seems to trouble you - " 4) Multiple parent : the method / attribute can't be resolved in the class itself, and can be resolved by at least 2 of its parents, then an ExplicitResolutionRequired error should be raised" - that is exactly the point the MRO algorithm kicks in, in a way that ultimately makes sense to ensure any overridden method in the inheritance hierarchy is called, most specialized first. Eventual hierarchies where the rules there won't fit are the cases where one is free to call whatever method they wish explicitly, as if super never existed. On Sat, Mar 26, 2022 at 2:00 PM malmiteria wrote: > Hi, > > Before anything, i made a github repository about this topic here : > https://github.com/malmiteria/super-alternative-to-super > > The core of what i wanna discuss here is that i don't think mro and super > (mainly because it relies on mro) are very pythonic. Mainly that some > behaviors of the mro are too implicit, and are silencing what really should > be errors. > > > > Let me explain : > in case of multiple inheritence, resolving a child method from it's parent > isn't an obvious task, and mro comes as a solution to that. However, i > don't understand why we don't let the programmer solve it. I think this is > similar to a merge conflict, and not letting the programmer resolve the > conflict feels like silencing an error. This is especially infuriating when > you realise that mro doesn't solve all possible scenarios, and then, simply > refuses the opportunity to solve it to the programmer. > Then, super relying on mro gives off some weird behaviors, mainly, it's > possible for a child definition to affect what a call to super means in > it's parent. This feels like a side effect (which is the 'too implicit' > thing i refer to). > I also don't understand why we can't simply pass the parent targeted as > argument to super, instead of having no argument, or having to pass the > current class and instances as argument : > super(child) is a proxy to parent, when super(parent) would make more > sense to be the proxy to parent, in my mind. > > I dive in more depths about those topics in the readme of the github > repository i linked at the top of this comment. > > > > what i propose is a solution that would follow those rules: > > The mro alternative, which i called explicit method resolution aka EMR > (which is probably not a good name since i apply it, as mro, to all class > attributes), follow those rules : > 1) Straightforward case : the class definition has the method / attribute > : this is the one EMR should resolve to > 2) Not found : the method / attribute can't be resolved in the class > itself, or by any of it's parents, then it should raise an AttributeError > 3) Only on parent : the method / attribute can't be resolved in the class > itself, and can only be resolved by one of it's parents, this is the one > EMR should resolve to > 4) Multiple parent : the method / attribute can't be resolved in the > class itself, and can be resolved by at least 2 of it's parents, then an > ExplicitResolutionRequired error should be raised > 5) Transimittin errors : the method / attribute can't be resolved in the > class itself, and one parent at least raises an ExplicitResolutionRequired > error, then it should raise an ExplicitResolutionRequired error > 6) (optional?) Single source : when multiple parent can resolve a method > from a single source (in case of diamond shape inheritence), the > ExplicitResolutionRequired is not needed > > The super alternative, which i called __as_parent__ should follow those > rules : > 1) reliability : the target __as_parent__ points to should not depend on > anything other than the argument passed to it > 2) expliciteness : in case of multiple inheritence, the parent targetted > should be passed as an argument to the __as_parent__ method. > 3) impliciteness : in case of simple inheritence, it is not needed to > specify the parent targeted (since there can only be one, and it make it > closer to the actual behavior of super in most cases) > 4) ancestors as targets : should be able to target ancestors, either > direct or not (which is needed in case two grandparent define a method that > a single parent share, there would be no other way to solve the > ExplicitResolutionRequired otherwise) > > > > this solution has a few advantages in my mind : > - the current mro and super are more tightly coupled than the
[Python-ideas] Re: Anonymous namedtuples, revisited
On Fri, Mar 25, 2022 at 12:17 AM Brendan Barnwell wrote: > On 2022-03-24 10:43, Andrew Svetlov wrote: > > The proposal doesn't work well with type hints: atuple(a=1, b=2) and > > atuple(a="a", b="b") generates the same type. > > I'm neither here nor there on the original proposal, but I just > want to > push back against this reasoning. Type hints are an entirely optional > feature of Python which do not affect the runtime behavior of Python > code in any way (except insofar as other code explicitly reads the > annotations), and this has been explicitly reiterated multiple times > (e.g., in PEPs). In my view, how something interacts with typing has no > relevance in evaluating a proposal such as this. To allow typing > considerations to constrain Python's future development in any way > whatsoever is to slide down the slippery slope which was explicitly > disavowed in PEP 484, namely a gradual move towards a de facto > "requirement" for static typing. I would most heartily prefer to avoid > that. > > strong +1 > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no > path, and leave a trail." > --author unknown > ___ > 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/L67XX3TUEOFNLL4EJ56SX4UQAAV3TOU5/ > 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/5TFHEWOGACIWV5N5CGI64UAELCXVUIUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
> but I don't think we should underestimate the cost of even this small
complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity increase" cost is
_negative_. People might waste
more time looking for a way of spelling a frozenset literal than just
filling in "frozenset()".
I for one, even knowing that the cost of writing "frozenset({1,2,3})" is
negligible, would
"feel" better there was a way to spell that without the needless
conversions.
That said, an appropriate prefix for the {} just as we do for strigns would
be nice, and
I disagree that it would be a significant source for "bugs". The "@{" is a
nice
way out if people think "f{}" would be too close to "f()". And "<1,2,3>"
just for frozensets
are indeed overkill. We already do "literal prefixing" with `"` after all.
and formally extending this
prefix usage as needed for other literals seems like a nice path.
But, as far as bikeshedding go, we also have "literal sufixing" (2.0j
anyone?)- maybe
"{1,2,3}f" ?
On Mon, Jan 17, 2022 at 2:43 PM Christopher Barker
wrote:
> On Mon, Jan 17, 2022 at 9:07 AM Ronald Oussoren
> wrote:
>
>>
>> For example:
>>
>> If flag in {‘the’, ‘allowable’, ‘flags’}:
>> …
>>
>> If a frozen set was even a little bit faster or used less memory, it
>> would be nice to be able to create one directly.
>>
>>
>> Not really relevant for the discussion, but CPython automaticly creates a
>> frozenset here (set display with immutable members) as an optimisation.
>>
>
> I think it's quite relevant to the discussion, because as far as I can
> tell, better performance in particular cases is the primary motivator.
>
> Funny that this has come up -- not too long ago, I did some
> experiments with code like the above: and to the surprise of myself and
> some other long-time Pythonistas I work with, using sets, rather tha tuples
> in those kinds of constructs, e.g.:
>
> if something in :
>
> was always as faster or faster with sets than tuples. That was surprising
> because we assumed that construction of a set would be slower than
> construction of a tuple. And that was probably the case ten years ago. The
> proof is in the pudding,so I never bothered to figure out why, but now I
> know :-)
>
> Back to the topic at hand -- IIUC, set constants are already optimized, so
> the only places having a frozenset display would be when it is a constant,
> and it has to be a frozenset, where a regular one won't do.
>
> And that would only be noticeable if it was in a function that didn't do
> much else, and was called often. And in that case, it could be put in the
> global scope to ameliorate some of that cost.
>
> I believe Stephens' point is that the benefit may be fairly small, but so
> is the cost. I'm not so sure. I kind of like the idea myself, and the cost
> does seem small, but I don't think we should underestimate the cost of even
> this small complexity increase in the language. Sure, folks don't have
> toeven know it exists to write fine code, but it would be one more thing
> that newbies will need to figure out when they see it in others' code.
>
> In fact, there' a lot of what I might call "Python Scripters" that aren't
> even familiar with the set display at all.
>
> -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/Q2VUUY6I4JJHQOHMO2JMMRPZGVZU44N6/
> 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/VB4OI47LQ4PMNG6IQRFIQ2BR2LZII5L3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "frozen" operator Re: Revisiting a frozenset display literal
>
> Yes, but have you _seen_ the bickering about the existing bracket
>
> choices just for frozenset? Eww. Hence the going for a distinct operator
> altogether. Yes, I'd prefer brackets of some kind too, but they're
> taken.
>
> If one uses prefixes, you start from 53 valid (all latin areas, upper,
lower and @)
new brackets for {} .
I can't see how they are "all taken" when the strongest argument against
prefixing seems to be "but _only strings_ should have prefixes".
(with the "typing f{} instead of f() is going to be a bug magnet"
as a runner up). None of those stand up to any logical analysis
It is ok voting that "the language should not be made more complex
at this point, and we won't add any new syntax for a frozenset", but
I think that if it is agreed that frozensets are ok, a prefix
is just straightforward.
And then, adopting prefixes for curly braces, you have 52 other
bracket types to try and sell this "generic freezer operator"
you are presenting here. :-).
On Fri, Jan 21, 2022 at 5:52 AM Cameron Simpson wrote:
> On 21Jan2022 01:16, MRAB wrote:
> >On 2022-01-21 00:18, Cameron Simpson wrote:
> >>This all feels to me like a special case of "wanting a constant for
> >>bytecode". What is we had a "freeze" operator, eg:
> >> |foo|
> [...]
> >>Paired with a __freeze__ dunder method, this applies to any type, not
> >>just sets. (Where appropriate of course.)
> >> |{1,2,3}| frozen set
> >> |[1,2,3]| tuple!
> >> |any-iterable| tuple!
> >> |{1:2, 3:4}|frozen dict
> [...]
> >>My main question is: is the syntax unambiguous?
> >>
> >I don't know whether it's unambiguous, but it could be confusing.
> >
> >For example, what does this mean:
> >| a | b |
> >?
>
> Yeah.
>
> >It's:
> >| (a | b) |
> >I think.
>
> Probably. Running precedence the other way (or even worse, letting the
> valid combinations just shake out) would be confusing.
>
> >The problem is that '|' could be an opening '|', a closing '|', or an
> >infix '|'.
> >
> >You don't get this problem with differing open and closing pairs such
> >as '(' and ')'.
>
> Yes, but have you _seen_ the bickering about the existing bracket
> choices just for frozenset? Eww. Hence the going for a distinct operator
> altogether. Yes, I'd prefer brackets of some kind too, but they're
> taken.
>
> Cheers,
> Cameron Simpson
> ___
> 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/FZN74PZJBZCLULMT5AMTT6MP2L6RCENP/
> 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/RW6AHZAHRNGWV2HPULVC7J45GO7NEGOP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
>
> I don't understand polynomials as frozensets. What's the point of
> representing them that way? Particularly if you're converting to and
> from dicts all the time, why not represent them as dicts? Or as some
> custom mapping type, if you need it to be hashable?
Sorry for deviating here, but this kind of argumentation is one
that is sensitive for me - but here it is:
I personally do not think the comment above adds anything to the
discussion at hand.
We've been presented to a real-world use case of frozensets that would
benefit in readability from having a dedicated literal. How good it is to
question the way it is coded without even checking the project out?
(and even so, do that publicly in a non related discussion?)
I had this happen to me in an email here, when I tried an early
version of match/case in a code in a project of mine. Despite
being a more or less internal API, the code was bashed in
a way, in an unasked for code review,
it took out the fun I had in coding the project for months.
So, please, take care when deviating from the discussion at hand.
Back on topic:
It looks like this thing of "prefixes are valid for strigns and no good
for anything else" is, as yoiu put it, Chris, a personal thing.
Do we have anyone else in this thread commenting (or even
"+1ing") on that side? As I've mentioned a couple
of times before: is there any other arguments against
"f{}" other than "prefixes should be for strings only"
(and the"bug magnet" perceived by many as a plain
incorrect statement )?
If there is not, then we are not at "there is no viable syntax",
as prefixable braces are perfectly viable. It is whether it should be
done or not, despite some people finding it ugly, which is subjective.
At that point, I argue that despite adding still more things to
the syntax, it is one that will spare time in average than the other
way around, due to the time people, needing frozensets for
the first time in any project, waste looking for a literal syntax for them
only to find out there is not any.
On Fri, Jan 21, 2022 at 9:16 AM Chris Angelico wrote:
> On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin
> wrote:
> >
> > On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
> >>
> >> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
> >>>
> >>> Christopher Barker writes:
> >>>
> >>> > If this does all come to pass, then:
> >>> >
> >>> > s = {3,8,2}.frozen()
> >>> > will be slightly faster, in some case, than
> >>> > s = frozenset({3,8,2}
> >>> >
> >>> > but the result would be the same.
> >>> >
> >>> > There are plenty of tricks to in python to get a touch more
> performance,
> >>> > this would just be one more
> >>> > and frankly pretty rare that it would make an noticable difference
> at all.
> >>> >
> >>> > +1 on this
> >>> > +0 on f{}
> >>> > -1 on making frozenset a keyword
> >>>
> >>> Stated better than I could, expresses my feelings exactly. Sticking
> >>> to integers (in floats I'd be less than -0 on f{}), I'll go with
> >>> Chris's ratings, too.
> >>>
> >>> Steve
> >>
> >>
> >> Another agreement with Chris' ratings:
> >>
> >> +1 for .frozen()
> >> +0 on f{}
> >> -1 on keyword for frozenset
> >
> >
> > I really don't understand (having read everything above) why anyone
> prefers {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some
> other languages might get confused (e.g. in Mathematica this is function
> call syntax) but that's true of anything: you have to learn Python syntax
> to use Python. The fact that {1,2,3} is a set and f{1,2,3} is a frozenset
> is not difficult to explain or to understand, especially in a language that
> already uses single letter prefixes for other things.
> >
> > The .frozen() method is a strangely indirect way to achieve a minor
> optimisation. Outside of attempting to achieve that optimisation it's
> basically useless because any time you would have written obj.frozen() you
> could have simply written frozenset(obj) so it does nothing to improve code
> that uses frozensets.
> >
>
> If set.frozen() is optimized, then str.upper() can be optimized the
> same way, which means there's a lot of places where constant folding
> can be used. We commonly write code like "7*24*60*60" to mean the
> number of seconds in a week, confident that it'll be exactly as fast
> as writing "604800", and there's no particular reason that method
> calls can't get the same optimization, other than that it hasn't been
> done yet.
>
> While dedicated syntax might be as good, it also wouldn't help with
> string methods (or int methods - I don't see it a lot currently, but
> maybe (1234).to_bytes() could become more popular), and it would also
> be completely backward incompatible - you can't feature-test for
> syntax without a lot of hassle with imports and alternates. In
> contrast, code that wants to use set.frozen() can at least test for
> that with a simple try/except in the same module.
>
> Not one of the proposed
[Python-ideas] Re: Revisiting a frozenset display literal
Maybe the "special optimizable method" will solve some of the problems, and
appraise the "no new syntax" folks. But IMHO, it (1) it is more verbose
than the prefix/suffix new syntax alternatives, to the point of getting
in the way of reading
mysets = [{1 ,2 ,3 }.freeze(), {4,5,6}.freeze()]
X
mysets = [{f{1, 2, 3}, f{4, 5, 6}]
and (2), as stated, although introducing no new syntax, require
fiddling in a couple of places in order to actually work in an optimized
way,
and the optimization would end up as an "implementation detail".
(In order not to generate yet another message): I've seem no new arguments
by the opponents of "f{...}"at all - but re-stating that "strings are
different than sets".
Indeed: strings(bytestrings, raw, fstrings) have a lot of factors in common
that the
other built-in datatypes don't share. But the prefix thing is orthogonal to
that,
and the same motivations that led to the introduction of quote-prefixes for
strings
to start with apply here, with no drawbacks. As already stated
in other messages, calling it a "bug magnet" is a gross exaggeration. One
would
get a "NameError" on the first try and have it either fixed seconds later,
or revisiting the concept of functions and calling functions, which would
be needed anyway, in case the person in error is a begginner
to programming in general.
best regards,
js
-><-
On Wed, Jan 19, 2022 at 10:14 AM Steven D'Aprano
wrote:
> On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote:
>
> > PEP 351 for the frozen protocol was rejected. I didn't read why, but
> > it's probably hard to resurrect.
>
> This is not a proposal for a generic frozen protocol. It is a simple
> proposal for a set method that returns a frozenset, with the aim that
> the peephole optimiser will be able to optimise the call out for set
> displays consisting only of literals.
>
>
> --
> Steve
> ___
> 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/BH2VZ3RSI3KRQ4F6P6HHZ23APR6CBQ3R/
> 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/PPON7EOH7ZFQDEQNACMLPR3RQS55ZUKQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Revisiting a frozenset display literal
>
> Also, it is standard in Python to avoid properties if the computation
> could be expensive. Copying a large set or millions of elements into a
> frozenset could be expensive, so we should keep it a method call.
Here is another hint that this usage would not resolve the problem of
having a literal frozenset. Even in the core of this discussion, with folks
participating and knowing what they are talking about, the first thing that
comes to mind when seeing a method call is that the target set would
be copied. The messages are just about no-need to copy this
into a frozenset.
But upon seeing a method call, we can just think first of a runtime behavior
Correctly, btw. Any optimization there would be an exception, that people
would
have to know by heart.
On Wed, Jan 19, 2022 at 10:31 AM Steven D'Aprano
wrote:
> On Wed, Jan 19, 2022 at 07:12:04AM -0500, Ricky Teachey wrote:
> > Why does it need to be called at all?
> >
> > {1, 2, 3}.frozen
>
> For the same reason that most methods are methods, not properties.
>
> The aim of a good API is not to minimize the amount of typing, it is to
> communicate the *meaning* of the code as best as possible.
>
> `{1, 2, 3}.frozen` says that the result is an attribute (property,
> member) of the set. Like *name* to a person, or *tail* to a dog, the
> attribute API represents something which is part of, or a quality of,
> the object. The frozenset is not an attribute of the set, it is a
> transformation of the set into a different type.
>
> A transformation should be written as an explicit function or method
> call, not as attribute access. Yes, we can hide that transformation
> behind a property just to save typing two characters, but that is an
> abuse of notation.
>
> Also, it is standard in Python to avoid properties if the computation
> could be expensive. Copying a large set or millions of elements into a
> frozenset could be expensive, so we should keep it a method call.
>
>
> --
> Steve
> ___
> 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/WS5IXNJKETM5JICWCYJPDOF2HNK75DNK/
> 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/T55L2JOA6PVHV473RHYU45SQOHHH3IHQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On Mon, Apr 11, 2022 at 3:39 AM Chris Angelico wrote: On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull > wrote: > > [1] They don't have to be big problems or proprietary code; computing > > Fibonacci sequences will do, if you can find a way to make MI relevant > > to that task. > > > > > We shall now hold a funeral for the brain cells lost by everyone who > just read that code. > Fortunately, I was still through my Monday morning cup of coffee - it took most of the damage. ___ 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/FMDT6JFLBN5SHOC6DLMUMAMG4AXCTXRQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On Tue, Apr 12, 2022 at 1:59 PM malmiteria wrote: > Ronald Oussoren writes: > > > To be blunt: That’s not going to happen because this is big backward > compatibility break. Either that, or this adds a > > second way to define classes. Both are good reasons to keep the status > quo. > > the breaking is limited MI with name collision, so likely rare enough, and > i've already mentionned that i'm perfectly willing to implement my proposal > and run it against whatever selection of python repos, to check for real > life exemple of breakings, so we can measure how bad it would actually be. > Sorry. I thought we were past this point and you had understood and agreed that any change in this respect would not change the current behavior of MRO and super, requiring either a different call than super, and/or a different metaclass for all the hierarchy, to start with. TL;DR: ***Changing the current behavior of super itself or the MRO formula is just not going to happen.*** And it is not me saying this. If you won't spare replying on the list, you can spare yourself from checking "whether this would break things". It would. But even if it does not break a particular project, that is not negotiable. And I am not saying that these changes,even as "add-ons" to the language are being considered either - IMHO you failed so far in presenting any evidence of your point or more people that would ask for the features you are proposing. The playful example you brought here with the Gobelin hierarchy, for example, could be addressed with a multitude of approaches, including custom-metaclases and even `__init_subclass__` methods, that would collect the methods with "name collision" and allow one to select a strategy when calling them. So, a custom base class or custom metaclass could attend your needs - and that does not need to live in the language core. > The most common case of breaking would be the django style mixins, which i > propose a dedicated feature for, adoption. > Essentially a way to declare more than your parent, but their parents too, > recursively. > would look like that: > ``` > class A(B(C)): ... > ``` > the adoption syntax is non breaking, as it's simply an addition to the > language, and has values on its own. > I'll make a dedicated post, but i'm a bit out of time for that now, > especially since i'm getting the survey ready. > I'll add some question to get infos that could help debate this feature > too, so i guess i'll wait for the survey result. > > Once adoption is ... adopted, and start getting used, the more it goes on, > the less breaking change will occur. > > And, on top of that, the actual change needed to switch from today's > solution to adoption is extremly simple. > replace > ``` > class A(B,C): ... > ``` > with > ``` > class A(B(C)): ... > ``` > That's it. > > So the amount of actual breakings left shouldn't be enough to justify > denying this feature IMO. Again, we'll have a clearer view on that once we > get experimental data. > What's to look for is usage of super in MI cases, since each super call in > MI today should be replaced by one super call per parent, in my proposal. > If this turns out to be an issue, we can try to imagine solution for it. > Maybe a solution such as : super calls implicitely run a super call to each > parent when there's multiple parent, and super isn't given arguments. This > i think would behave strictly as today's super + MRO, except for cases > where one class appears multiple time in an inheritance tree. > The last breaking change would be that scenario, class appearing multiple > time in an inheritance tree. > And we're getting on even rarer occasions here, but again, we can think of > solutions here. > > As much as i understand we don't want breaking change, i don't think it is > *that* strong an argument, in this case. > And, on its own, breaking changes aren't a strict veto, there's been some, > and there's gonna be more. > Overall, they are an upgrade cost we really wanna make as less expensive > as possible, but an worthwhile upgrade overcomes the upgrade costs. And, if > it improves something, the longer we wait, the more the current behavior > can deal its damage, it should be considered in the balance too. > Breaking changes are an momentary cost, while not upgrading might have a > smaller, but constant cost. > ___ > 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/LP22REU3YWWLRDOTKAZMTCC5EMHYP53A/ > 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
[Python-ideas] Re: mro and super don't feel so pythonic
On Fri, Apr 15, 2022 at 2:44 PM malmiteria wrote: > I got an idea that *should* allow for some (keyword : some) of the changes > i want without any breaks, i kinda wanna take the time to think about it, and > once i'm a bit more sure of it, i'll talk about it in details. Since you are thinking of ways that won't break current code, you might as well think of ways that won't need any syntax modification/adding extra features to the language. The current capabilities we get, including being able to customize the metaclass __getattribute__ method, might allow for that - and you'd have the advantage that your ideas could be immediately be made available in a pypi package. > > ___ 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/KAJEBWZRL2OMQ3GDRQG6XNENUXS7LLWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
I take the freedom to interpret 'no news == good news' on this thread -
nominally that there are no major disagreements that a decorator
to auto-commit `__init__` atributes to the instance could be a nice addition
to the stdlib.
I also assume it is uncontroversial enough for not needing a PEP.
I remember a similar thread from a couple years ago where the thread ended
up agreeing on such a decorator as well.
I would then like to take the opportunity to bike-shed a bit on this, and
maybe we
can get out of here with a BPO and an actual implementation.
So,
1) Would it live better in "dataclasses" or "functools"? Or some other
package?
2) What about: the usage of the decorator without arguments would imply in
committing all of
`__init__` arguments as instance attributes, and two, mutually exclusive,
optional kwonly
"parameters" and "except" parameters could be used with a list of
arguments to set?
2.1) The usage of a "parameters" argument to the decorator would even pick
names from an
eventual "**kwargs" "__init__" parameter, which otherwise would be
commited be left alone/
2.2) would it make sense to have another argument to specify how "**kwargs"
should be treated?
I see three options: (i) ignore it altogether, (ii) commit it as a
dictionary, (iii) commit all keys in kwargs as
instance attributes, (iii.a) "safe commit" keys in kwargs, avoiding
overriding methods and class attributes.
(whatever the option here, while the principle of "less features are
safer" in a first release, should consider
if it would be possible to include the new features later in a
backwards compatible way)
3) While the Python implementation for such a decorator is somewhat
straightforward, are there any chances
of making it static-annotation friendly? AFAIK dataclasses just work with
static type checking because
the @dataclass thecorator is special-cased in the checker tools themselves.
Would that be the same case here?
4) Naming. What about "@commitargs"?
5) Should it emit a warning (or TypeError) when decorating anything but a
function named `__init__ ` ?
On Wed, Apr 20, 2022 at 3:14 PM Joao S. O. Bueno
wrote:
>
>
> On Wed, Apr 20, 2022 at 12:30 PM Pablo Alcain
> wrote:
>
>>
>> Regarding the usage of a decorator to do the auto-assignment, I think
>> that it has an issue regarding how to select a subset of the variables that
>> you would be setting. In the general case, you can probably get away with
>> calling `autoassign`. But, for example, if you want to set a but not b,
>> you'd probably have to use a string as the identifier of the parameters
>> that you want to assign:
>>
>> ```
>> class MyKlass:
>> @autoassign('a')
>> def __init__(self, a, b):
>> print(b)
>>
>> ```
>>
>> This, in my perspective, brings two things: the first one is that you'd
>> be repeating everywhere the list of names, so for example doing refactors
>> like changing a variable name would be a bit error-prone: If you change the
>> variable from `a` to `my_var_name`, you'd have to also change the list in
>> the autoassign. It's not a lot, but it can induce some errors because of
>> the repetition. On the other hand, I guess it would be a bit hard for IDEs
>> and static checkers to follow this execution path. I know that I'm only one
>> data point, but for what it's worth, I was very excited with the idea but
>> this prevented me from actually implementing this solution on a day-to-day
>> basis: it felt a bit fragile and induced me to some errors.
>>
>
> IMO, that is trivially resolvable by doing the decorator, by default,
> assign all parameters. If it tkaes a string or sequence with parameter
> names, then, it will just bind those (still shorter than one line
> `self.attr = attr` for each attribute.
>
> And for the fragility: that is the advantage of having a robust
> implementation of something like this on the stdlib: it is not something
> most people will go out of their way to write their own, since the tradeoff
> is just
> copy and paste a bunch of plain assignments.
>
> But having it right and known, could chop off tens of lines of useless
> code in, probably the majority of Python projects.
>
>
> Also answering Christopher Barker:
>
> This has a subtle, but different use than dataclasses.
> It might be grouped in the dataclasses module, on the stdlib.
>
>
>
>>
>> About dataclasses, the point that Chris mentions, I think that they are
>> in a different scope from this, since they do much more stuff. But, beyond
>> this, a solution on the dataclass style would face a similar scenario:
>> since the `__init__` is autogenerate
[Python-ideas] Re: Auto assignment of attributes
On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote: > Hey Joao! For what it's worth, I'm not a big fan of the proposal to be > honest, for the reasons I have already mentioned. I'm not heavily against > it, but I would most likely not use it. Nevertheless, I believe it would > need a PEP since it probably can change substantially the way Python code > is being written. > > I think that discussion can probably belong to a specific thread with the > proposal with your questions summary there so everyone can contribute to > the implementation that, clearly, has some interesting points that it would > be better if we could discuss in detail. > > I would very much like for us to evaluate, in this thread, the original > proposal we sent, regarding if anyone else thinks it would make sense to > add a new syntax for the binding of attributes. > > Sorry. It looks like you are claiming... the _thread_ , is that it? Very well. The thread may be all yours! BTW, I am -1 on these changes. > Pablo > ___ 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/MSNOSJK2M3QLCUDUBVQNEFMDQF3YWIWD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Wed, Apr 20, 2022 at 12:30 PM Pablo Alcain wrote:
>
> Regarding the usage of a decorator to do the auto-assignment, I think that
> it has an issue regarding how to select a subset of the variables that you
> would be setting. In the general case, you can probably get away with
> calling `autoassign`. But, for example, if you want to set a but not b,
> you'd probably have to use a string as the identifier of the parameters
> that you want to assign:
>
> ```
> class MyKlass:
> @autoassign('a')
> def __init__(self, a, b):
> print(b)
>
> ```
>
> This, in my perspective, brings two things: the first one is that you'd be
> repeating everywhere the list of names, so for example doing refactors like
> changing a variable name would be a bit error-prone: If you change the
> variable from `a` to `my_var_name`, you'd have to also change the list in
> the autoassign. It's not a lot, but it can induce some errors because of
> the repetition. On the other hand, I guess it would be a bit hard for IDEs
> and static checkers to follow this execution path. I know that I'm only one
> data point, but for what it's worth, I was very excited with the idea but
> this prevented me from actually implementing this solution on a day-to-day
> basis: it felt a bit fragile and induced me to some errors.
>
IMO, that is trivially resolvable by doing the decorator, by default,
assign all parameters. If it tkaes a string or sequence with parameter
names, then, it will just bind those (still shorter than one line
`self.attr = attr` for each attribute.
And for the fragility: that is the advantage of having a robust
implementation of something like this on the stdlib: it is not something
most people will go out of their way to write their own, since the tradeoff
is just
copy and paste a bunch of plain assignments.
But having it right and known, could chop off tens of lines of useless code
in, probably the majority of Python projects.
Also answering Christopher Barker:
This has a subtle, but different use than dataclasses.
It might be grouped in the dataclasses module, on the stdlib.
>
> About dataclasses, the point that Chris mentions, I think that they are in
> a different scope from this, since they do much more stuff. But, beyond
> this, a solution on the dataclass style would face a similar scenario:
> since the `__init__` is autogenerated, you would also be in a tight spot in
> the situation of "how would I bind only one of the items?". Again, now I'm
> talking about my experience, but I think that it's very hard to think that
> we could replace "classes" with "dataclasses" altogether. Here's an example
> of one of the (unexpected for me) things that happen when you try to do
> inheritance on dataclasses: https://peps.python.org/pep-0557/#inheritance.
>
> Overall, I think that it's hard to think about a solution to this problem
> that is clean and robust without adding new syntax with it. I would like to
> hear your thoughts on this (and everyone else's of course!)
>
> Cheers,
> Pablo
>
> On Mon, Apr 18, 2022 at 9:55 PM Christopher Barker
> wrote:
>
>> On Mon, Apr 18, 2022 at 4:24 PM Joao S. O. Bueno
>> wrote:
>>
>>> I for one am all for the inclusion of a decorator targeting either the
>>> __init__ method
>>> or the class itself to perform this binding of known arguments to
>>> instance attributes
>>> prior to entering __init__. It could live either in functools or
>>> dataclasses itself.
>>>
>>
>> Isn’t this what dataclasses already accomplish? I understand that it’s
>> the reverse— with a dataclass, you specify the fields, and the __init__ is
>> generated, whereas this proposal is ttt be at you’d write an __init__, and
>> the attributes would be set — but other than taste, is there a practical
>> difference?
>>
>> -CHB
>>
>>
>>> On Sat, Apr 16, 2022 at 5:49 PM Pablo Alcain
>>> wrote:
>>>
>>>> The problem of assigning init arguments as attributes has appeared
>>>> several times in the past (
>>>> https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3DOFA5VWMGJMJGRDC7JZTRKEPPZNU/
>>>> was the most recent we could find) and is already handled in dataclasses.
>>>>
>>>> Lately, discussing this topic with a friend, we thought that using a
>>>> specific token could be a possible approach, so you could do:
>>>>
>>>> class MyClass:
>>>>
>>>> def __init__(self, @a, @b, c):
>>>>
>>>> pass
>>>>
>>>> and it would be analogous to doing:
>>>>
>>>&
[Python-ideas] Re: Auto assignment of attributes
There is no need for a whole new syntax for what can trivially be accomplished by a decorator, and a simple one, in this cases. I for one am all for the inclusion of a decorator targeting either the __init__ method or the class itself to perform this binding of known arguments to instance attributes prior to entering __init__. It could live either in functools or dataclasses itself. On Sat, Apr 16, 2022 at 5:49 PM Pablo Alcain wrote: > The problem of assigning init arguments as attributes has appeared several > times in the past ( > https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3DOFA5VWMGJMJGRDC7JZTRKEPPZNU/ > was the most recent we could find) and is already handled in dataclasses. > > Lately, discussing this topic with a friend, we thought that using a > specific token could be a possible approach, so you could do: > > class MyClass: > > def __init__(self, @a, @b, c): > > pass > > and it would be analogous to doing: > > class MyClass: > > def __init__(self, a, b, c): > > self.a = a > > self.b = b > > Then, you would instantiate the class as usual, and the variables tagged > with `@` would be bound to the object: > > >>> objekt = MyClass(2, 3, 4) > > >>> print(objekt.b) > > 3 > > >>> print(objekt.c) > > AttributeError: 'MyClass' object has no attribute 'c' > > > We have a working implementation here if anyone wants to take a look at: > https://github.com/pabloalcain/cpython/tree/feature/auto_attribute. Keep > in mind that we have limited knowledge about how to modify cpython itself, > and which would the best places be to do the modifications, so it's more > than likely that some design decisions aren't very sound ( > https://devguide.python.org/grammar/ and > https://devguide.python.org/parser/ were incredibly helpful). > > Besides the implementation, we would like to know what the community > thinks on whether this might have any value. While developing this, we > realized that Crystal already has this feature (eg > https://github.com/askn/crystal-by-example/blob/master/struct/struct.cr) > with the same syntax; which is kind of expected, considering it's syntax is > based on Ruby. > > > Random collection of thoughts: > > 1. If auto-assignment made sense in general, one of the reasons we went > for this rather than the decorator approach is that we wouldn't like to > have a list of strings that can vary decoupled from the actual argument > name. > > 2. The current implementation of `@` works for any function, not only > init. We don't know if this would actually be a desirable feature. > > 3. It also works with any function in the wild. This mostly allows for > monkey-patching to work out of the box: > > >>> class Klass: > > ... def __init__(self): > > ... pass > > ... > > >>> def add_parameter(k, @p): > > ... pass > > ... > > >>> Klass.add_parameter = add_parameter > > >>> objekt = Klass() > > >>> print(objekt.p) > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'Klass' object has no attribute 'p' > > >>> objekt.add_parameter(11) > > >>> print(objekt.p) > > 11 > > Again, we are not sure if this is desirable, but it's what made most sense > for us at the moment. > > 4. Adding the `@` token to the argument doesn’t remove the variable from > the function/method scope, so this would be perfectly valid: > > >>> def my_function(k, @parameter): > > ... print(parameter) > > >>> my_function(objekt, 4) > > 4 > > >>> k.parameter > > 4 > > > > 5. We didn’t implement it for lambda functions. > > Cheers, > > Pablo and Quimey > > ___ > 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/SCXHEWCHBJN3A7DPGGPPFLSTMBLLAOTX/ > 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/HUGRGXVT7NBWSXI2ILZOMFIRWV4KIQ5Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
Hi. I've replied to the first e-mail on this thread, more than 10 days ago.
I am back, though I've read most of what was written.
I don't think things have improved, but you sure are consuming everyone's
time
You are still repeating this:
"more in line with the expectation of the majority, "
Though, as already asked, there is zero (nothing) to support that.
I've seen exactly _one_ e-mail among those in the thread, that seemed
to need something different from the current status quo - though not
exactly what you offer. I replied in private as that user's needs could
be fulfilled with a custom metaclass, offering personal help with that (and
did not get a reply).
So, I'd suggest to you, if not for others, at least for myself, that you'd
get some
backup on what this "majority" you claim could be. Could you set, I don't
know,
some online form? With questions like:
"on the following scenario, what do you [think|prefer] 'super' [does|could
do]?"
Then we can check. No need for "majority" - get at least some 10
respondents, with 2 or 3 of those
thinking the same as you, and then maybe it would make sense insisting
on this path, as there could be something in there.
Otherwise, just admit these are some features you thought of yourself, and
not even you seem
to be quite sure of which should be the specs or deterministic outcome (if
any) when
calling parent class methods with M.I. Get your ideas out into some
packages,
gists, blog posts - some of what you want can be got with custom metaclasses
(except when retrieving dunder methods for operators, like __add__), and I
can
even help you to come up with those if you want. But these are toys
nonetheless,
which might see the "light of the day" maybe once a year in a codebase.
best regards,
js
-><-
On Thu, Apr 7, 2022 at 12:39 PM malmiteria wrote:
> Antoine Rozo writes:
> > If the only feature you need from super is the proxy one, why don't you
> > code your own parent-proxy-type?
>
> I did :
> https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py
>
> This is irrelevant to the discussion we're having i think.
> Essentially, I'm arguing against today's state of some edge case of MRO +
> super, and against the UX associated with it.
> Those are issues with today's python, and the update that i propose would
> reduce the UX problems with super and MRO, would allow for use case of
> super more in line with the expectation of the majority, and would open the
> door to a few cases locked behind MRO errors today.
> Technically, with my proposal, you could even do circular inheritance,
> which is definitely unheard of today:
> ```
> class Day:
> def tell_time(self):
> print("it's daytime")
> sleep(1)
> super().tell_time()
>
> class Night(Day):
> def tell_time(self):
> print("it's night time")
> sleep(1)
> super().tell_time()
>
> Day.__bases__ = (Night, )
>
> Day().tell_time() # infinitely loops over "it's daytime" and "it's night
> time"
> ```
> That would be an incredibely easy way to articulate process that repeat in
> a cycle, with no end, cron style.
> No need to get multiple class too:
> ```
> class CronTask:
> def task(self):
> # do something
> time.sleep(1)
> super().task()
>
> CronTask.__bases__ = (CronTask, )
>
> CronTask().task() # runs the task forever with a time sleep in between
> ```
>
> I'm convinced there's some smart designs that are banned from python
> because of MRO and super's limitations.
> ___
> 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/BKFSLLICTCAYBPIZBTVW4Y4OPT3UKBZ2/
> 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/BVZ7UIEHFGX3V66P2COWOY7UK3WCCSDA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generalized deferred computation in Python
On Fri, Jun 24, 2022 at 10:05 PM Chris Angelico wrote:
>
> Hmmm, I think possibly you're misunderstanding the nature of class
> slots, then. The most important part is that they are looked up on the
> *class*, not the instance; but there are some other quirks too:
Sorry, no. I know how those work.
> >>> class Meta(type):
> ... def __getattribute__(self, attr):
> ... print("Fetching %s from the metaclass" % attr)
> ... return super().__getattribute__(attr)
> ...
> >>> class Demo(metaclass=Meta):
> ... def __getattribute__(self, attr):
> ... print("Fetching %s from the class" % attr)
> ... return super().__getattribute__(attr)
> ...
> >>> x = Demo()
> >>> x * 2
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unsupported operand type(s) for *: 'Demo' and 'int'
>
> Neither the metaclass nor the class itself had __getattribute__
Yes - if you go back to my first e-mail on the thread, and the example code,
that is why I am saying all along the proxy have to explicitly define all
possible dunder methods.
I've repeateadly written that all _other_ methods and attributes access
go through __getattribute__.
> called, because __mul__ goes into the corresponding slot. HOWEVER:
>
> >>> Demo().__mul__
> Fetching __mul__ from the class
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 4, in __getattribute__
> Fetching __dict__ from the class
> Fetching __class__ from the class
> Fetching __dict__ from the metaclass
> Fetching __bases__ from the metaclass
> AttributeError: 'Demo' object has no attribute '__mul__'. Did you
> mean: '__module__'?
>
> If you explicitly ask for the dunder method, it does go through
> __getattribute__.
Please.
I know that. The thing is if I define in a class both
"__add__" and "__getattribte__" I will cover both
"instance + 0" and "instance.__add__(0)"
.(...)
>
> That's a consequence of it being a proxy, though. You're assuming that
> a proxy is the only option. Proxies are never fully transparent, and
> that's a fundamental difficulty with working with them; you can't
> treat them like the underlying object, you have to think of them as
> proxies forever.
No, not in Python.
Once you have a proxy class that cover all dundeer methods to operate and
return
the proxied object, whoever will make use of that proxy will have it
working in a transparent way.
In any code that don't try direct memory access to the proxied object data.
"Lelo" objects from that link can be freely passed around and used -
at one point, if the object is not dropped, code has to go through one of
the dunder methods -
there is no way Python code can do any calculation or output the proxied
object without doing so.
And that experiment worked fantastically fine in doing so, better than I
thought it would,
and that is the only thng I am trying to say.
>
> The original proposal, if I'm not mistaken, was that the "deferred
> thing" really truly would become the resulting object. That requires
> compiler support, but it makes everything behave sanely: basic
> identity checks function as you'd expect, there are no bizarre traps
> with weak references, C-implemented functions don't have to be
> rewritten to cope with them, etc, etc, etc.
So, as I 've written from the first message, this would require deep
suport in
the language, which the proxy approach does not.
>
> > A similar proxy that is used in day to day coding is a super()
instance, and I
> > never saw one needing `super(cls, instance) is instance` to be true.
>
> That's partly because super() deliberately does NOT return a
> transparent, or even nearly-transparent, proxy. The point of it is to
> have different behaviour from the underlying instance. So, obviously,
> the super object itself has to be a distinct thing.
>
> Usually, a proxy offers some kind of special value that makes it
> distinct from the original object (otherwise why have it?), so it'll
> often have some special attributes that tie in with that (for
> instance, a proxy for objects stored in a database might have an
> "is_unsaved" attribute/method to show whether it's been assigned a
> unique ID yet). This is one of very few places where there's no value
> whatsoever in keeping the proxy around; you just want to go straight
> to the real object with minimal fuss.
and that is acheived when what happens when all the dunder methods
transparently work on the real object: minimal fuss. inst + other work,
str(inst) work, print(inst) work, because it will call str(inst) further
down,.
>
> > > Then you are not talking about the same thing at all. You're talking
> > > about a completely different concept, and you *are* the "you" from my
> > > last paragraphs.
> >
> > I see.
> > I've stepped in because that approach worked _really_ well, and I don't
think
> > it is _all_ that different from the proposal on the thread, and is
instead a
> > middleground not involving "inplace object mutation",
[Python-ideas] Re: Generalized deferred computation in Python
On Fri, Jun 24, 2022 at 5:38 AM Chris Angelico wrote: > > On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno wrote: > > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote: > >> How much benefit would this be? You're proposing a syntactic construct > >> for something that isn't used all that often, so it needs to be a > >> fairly dramatic improvement in the cases where it _is_ used. > >> > > > > Excuse-me > > Who is the "you" you are referring to in the last paragraphs? > > (honest question) > > > > I am not proposing this - the proto-pep is David Mertz' . > > You, because you're the one who devised the version that I was > responding to. His version is a much more in-depth change, although it > has other issues. ok. > > > I just pointed out that the language, as it is today,can handle > > the inner part of the deferred object, as it is. > > Yes, but with the limitations that I described. Indeed - I don't want to argue about that, just point out that the natural way things work in Python as is, some of those limitations do not apply. > > (if one just adds all possible dunder methods to your proxy example > > above, for example) > > I still don't understand why you treat dunder methods as special here. > Are you, or are you not, relying on __getattribute__? Have you taken > tp_* slots into account? I had not thought about tp_*slots - I am just considering pure Python code: any slot which does not alias to a visible dunder method would map to the proxy instead, in a straightforward way for one looking only at the Python code. Maybe some of the not mapped slots might cause some undesired effects, and should trigger the resolve as well. . The reason I am treating dunder attributes as special is simply because it is what cPython does when resolving any operator with an object - any other attribute access, from Python code, goes through __getattribute__, but the code path triggered by operators (+, -, ..., not, len, str) does not. > > > Moreover, there could be an attribute namespace to deal/modify the object > > so - retrieving the "real" object could be trivial. (the original would > > actually be retrieved in _any_ operation with with the object that would > > make use of its dunder attributes - think "str", or "myobj + 3", since the proxy > > dunder would forward the operation to the wrapped object corresponding > > method. > > Okay, here's an exercise for you. Given any function f(), ascertain > whether these two calls returned the same object: > > x = f() > y = later f() > > You do not know what kind of object it is. You just have to write the > code that will answer the question of whether the second call to f() > returned the exact same object as the first call. Calling str() on the > two objects is insufficient, for instance. Calling id(y) is not going > to touch any of y's dunder methods - it's just going to return the ID > of the proxy, so it'll always show as different. It won't work, indeed. unless there are reserved attributes that would cause the explicit resolve. Even if it is not given, and there is no way for a "is" comparison, this derives from the natural usage of the proxy, with no exceptional behaviors needed. The proxy is not the underlying object, after all. And not even a convention such as a ".__deferred_resolve__" call could solve it: the simpler path I pointed out does not involve "in place attribute substitution". But such a method could return resolve and return the wrapped object, and then: `(z := resolve(y)) is x`, would work , as well as id(resolve(y)) == id(x), but "y"would still be the proxy <- no magic needed, and that is the point I wanted to bring. A similar proxy that is used in day to day coding is a super() instance, and I never saw one needing `super(cls, instance) is instance` to be true. [...] > Then you are not talking about the same thing at all. You're talking > about a completely different concept, and you *are* the "you" from my > last paragraphs. I see. I've stepped in because that approach worked _really_ well, and I don't think it is _all_ that different from the proposal on the thread, and is instead a middleground not involving "inplace object mutation", that could make something very close to that proposal feasible. Maybe I'd be more happy to see a generic way to implement "super proxys" like these in a less hacky way, and then those could be used to build the deferred objects as in this proposal, than this specific implementation. In the example project itself, Lelo, the proxys are used to calculate the object in a subprocess, rather than just delaying their resolve in-thread. > > > I just wrote
[Python-ideas] Re: Generalized deferred computation in Python
On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote:
> On Fri, 24 Jun 2022 at 13:26, Joao S. O. Bueno
> wrote:
> >
> >
> >
> > On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico wrote:
> >>
> >> On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno
> wrote:
> >> >
> >> > Martin Di Paola wrote:
> >> > > Three cases: Dask/PySpark, Django's ORM and selectq. All of them
> >> > > implement deferred expressions but all of them "compute" them in
> very
> >> > > specific ways (aka, they plan and execute the computation
> differently).
> >> >
> >> >
> >> > So - I've been hit with the "transparency execution of deferred code"
> dilemma
> >> > before.
> >> >
> >> > What happens is that: Python, at one point will have to "use" an
> object - and that use
> >> > is through calling one of the dunder methods. Up to that time, like,
> just writing the object name
> >> > in a no-operation line, does nothing. (unless the line is in a REPL,
> which will then call the __repr__
> >> > method in the object).
> >>
> >> Why are dunder methods special? Does being passed to some other
> >> function also do nothing? What about a non-dunder attribute?
> >
> >
> > Non-dunder attributes goes through obj.__getattribute__ at which point
> evaluation
> > is triggered anyway.
>
> Hmm, do they actually, or is that only if it's defined? But okay. In
> that case, simply describe it as "accessing any attribute".
>
> >> Especially, does being involved in an 'is' check count as using an
> object?
> >
> >
> > "is" is not "using', and will be always false or true as for any other
> object.
> > Under this approach, the delayed object is a proxy, and remains a proxy,
> > so this would have side-effects in code consuming the object.
> > (extensions expecting strict built-in types might not work with a
> > proxy for an int or str) - but "is" comparison should bring 0 surprises.
>
> At this point, I'm wondering if the proposal's been watered down to
> being nearly useless. You don't get the actual object, it's always a
> proxy, and EVERY attribute lookup on EVERY object has to first check
> to see if it's a special proxy.
>
> >> dflt = fetch_cached_object("default")
> >> mine = later fetch_cached_object(user.keyword)
> >> ...
> >> if mine is dflt: ... # "using" mine? Or not?
> >>
> >> Does it make a difference whether the object has previously been poked
> >> in some other way?
> >
> >
> > In this case, "mine" should be a proxy for the evaluation of the call
> > of "fetch_cached_object" which clearly IS NOT the returned
> > object stored in "dflt".
> >
> > This is so little, or so much, surprising as verifying that "bool([])"
> yields False:
> > it just follows the language inner workings, with not special casing.
>
> If it's defined as a proxy, then yes, that's the case - it will never
> be that object, neither before nor after the undeferral. But that
> means that a "later" expression will never truly become the actual
> object, so you always have to keep that in mind. I foresee a large
> number of style guides decrying the use of identity checks because
> they "won't work" with deferred objects.
>
> > Of course, this if this proposal goes forward - I am just pointing that
> the
> > existing mechanisms in the language can already support it in a way
> > with no modification. If "is" triggering the resolve is desired, or if
> > is desired the delayed object should be replaced "in place", instead
> > of using a proxy, another approach would be needed - and
> > I'd favor the "already working" proxy approach I presented here.
> >
> > (I won't dare touch the bike-shedding about the syntax on this, though)
> >
>
> Right, but if the existing mechanisms are sufficient, why not just use
> them? We *have* lambda expressions. It wouldn't be THAT hard to define
> a small wrapper - okay, the syntax is a bit clunky, but bear with me:
>
> class later:
> def __init__(self, func):
> self.func = func
> self.__is_real = False
> def __getattribute__(self, attr):
> self.__makereal()
> return getattr(self.__wrapped, attr)
> def __makereal(self):
> if self.__is_real: return
> self.__wrapped = self.func()
> self.__is
[Python-ideas] Re: Generalized deferred computation in Python
On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico wrote:
> On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno
> wrote:
> >
> > Martin Di Paola wrote:
> > > Three cases: Dask/PySpark, Django's ORM and selectq. All of them
> > > implement deferred expressions but all of them "compute" them in very
> > > specific ways (aka, they plan and execute the computation differently).
> >
> >
> > So - I've been hit with the "transparency execution of deferred code"
> dilemma
> > before.
> >
> > What happens is that: Python, at one point will have to "use" an object
> - and that use
> > is through calling one of the dunder methods. Up to that time, like,
> just writing the object name
> > in a no-operation line, does nothing. (unless the line is in a REPL,
> which will then call the __repr__
> > method in the object).
>
> Why are dunder methods special? Does being passed to some other
> function also do nothing? What about a non-dunder attribute?
>
Non-dunder attributes goes through obj.__getattribute__ at which point
evaluation
is triggered anyway.
>
> Especially, does being involved in an 'is' check count as using an object?
>
"is" is not "using', and will be always false or true as for any other
object.
Under this approach, the delayed object is a proxy, and remains a proxy,
so this would have side-effects in code consuming the object.
(extensions expecting strict built-in types might not work with a
proxy for an int or str) - but "is" comparison should bring 0 surprises.
>
> dflt = fetch_cached_object("default")
> mine = later fetch_cached_object(user.keyword)
> ...
> if mine is dflt: ... # "using" mine? Or not?
>
> Does it make a difference whether the object has previously been poked
> in some other way?
>
In this case, "mine" should be a proxy for the evaluation of the call
of "fetch_cached_object" which clearly IS NOT the returned
object stored in "dflt".
This is so little, or so much, surprising as verifying that "bool([])"
yields False:
it just follows the language inner workings, with not special casing.
Of course, this if this proposal goes forward - I am just pointing that the
existing mechanisms in the language can already support it in a way
with no modification. If "is" triggering the resolve is desired, or if
is desired the delayed object should be replaced "in place", instead
of using a proxy, another approach would be needed - and
I'd favor the "already working" proxy approach I presented here.
(I won't dare touch the bike-shedding about the syntax on this, though)
> 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/HUJ36AA34SZU7D5Q4G6N5UFFKYUOGOFT/
> 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/EY3HWBNPVSY5IVZPYN75BXSAFQDEMPNM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generalized deferred computation in Python
Martin Di Paola wrote: > Three cases: Dask/PySpark, Django's ORM and selectq. All of them > implement deferred expressions but all of them "compute" them in very > specific ways (aka, they plan and execute the computation differently). So - I've been hit with the "transparency execution of deferred code" dilemma before. What happens is that: Python, at one point will have to "use" an object - and that use is through calling one of the dunder methods. Up to that time, like, just writing the object name in a no-operation line, does nothing. (unless the line is in a REPL, which will then call the __repr__ method in the object). I have implemented a toy project far in the past that would implement "all possible" dunder methods, and proxy those to the underlying object, for a "future type" that was calculated off-process, and did not need any ".value()" or ".result()" methods to be called. Any such an object, that has slots for all dunder methods, any of which, when called, would trigger the resolve, could work today, without any modification, to implement the proposed behavior. And all that is needed to be possible to manipulate the object before the evaluation takes place, is a single reserved name, within the object namespace, that is not a proxy to evaluation. It could be special-cased within the object's class __getattribute__ itself: not even a new reserved dunder slot would be needed: that is: "getattr(myobj, "_is_deferred", False)" would not trigger the evaluation. (although a special slot for it in object would allow plain checking using "myobj.__is_deferred__" without the need to use getattr or hasattr) So, all that would be needed for such a feature would be keyword support to build this special proxy type. That said, the usefulness or not of this proposal can be better thought, as well, as, knowing that this "special attribute" mechanism can be used to add further inspection/modification mechanisms to the delayed objects. The act of "filling in all possible dunder methods" itself is quite hacky, but even if done in C, I don't think it could be avoided. Here is the code I referred to that implements the same proxy type that would be needed for this feature - (IRRC it is even pip installable): https://bitbucket.org/jsbueno/lelo/src/master/lelo/_lelo.py On Wed, Jun 22, 2022 at 11:46 AM Martin Di Paola wrote: > Hi David, I read the PEP and I think it would be useful to expand the > Motivation and Examples sections. > > While indeed Dask uses lazy evaluation to build a complex computation > without executing it, I don't think that it is the whole story. > > Dask takes this deferred complex computation and *plans* how to execute it > and then it *executes* it in non-obvious/direct ways. > > For example, the computation of the min() of a dataframe can be done > computing the min() of each partition of the dataframe and then > computing the min() of them. Here is where the plan and the execution > stages play. > > All of this is hidden from the developer. From his/her perspective the > min() is called once over the whole dataframe. > > Dask's deferred computations are "useless" without the > planning/execution plan. > > PySpark, like Dask, does exactly the same. > > But what about Django's ORM? Indeed Django allows you the build a SQL > query without executing it. You can then perform more subqueries, > joins and group by without executing them. > > Only when you need the real data the query is executed. > > This is another example of deferred execution similar to Dask/PySpark > however when we consider the planning/execution stages the similarities > ends there. > > Django's ORM writes a SQL query and send it to a SQL database. > > Another example of deferred execution would be my library to interact > with web pages programmatically: selectq. > > Very much like an ORM, you can select elements from a web page, perform > subselections and unions without really interacting with the web page. > > Only when you want to get the data from the page is when the deferred > computations are executed and like an ORM, the plan done by selectq is > to build a single xpath and then execute it using Selenium. > > So... > > Three cases: Dask/PySpark, Django's ORM and selectq. All of them > implement deferred expressions but all of them "compute" them in very > specific ways (aka, they plan and execute the computation differently). > > Would those libs (and probably others) do benefit from the PEP? How? > > Thanks, > Martin. > > On Tue, Jun 21, 2022 at 04:53:44PM -0400, David Mertz, Ph.D. wrote: > >Here is a very rough draft of an idea I've floated often, but not with > much > >specification. Take this as "ideas" with little firm commitment to > details > >from me. PRs, or issues, or whatever, can go to > >https://github.com/DavidMertz/peps/blob/master/pep-.rst as well as > >mentioning them in this thread. > > > >PEP: > >Title: Generalized deferred computation > >Author: David Mertz >
[Python-ideas] Re: Adding a .find() method to list
Still - the "filter" call is almost as simple as it can get for a generic
enough way to do what you are requesting.
There is some boiler plate needed around it if you want an actual eager
result or a default value, if no match is found, that is true - but still,
given a list like
On Sat, May 7, 2022 at 1:51 PM Paul Moore wrote:
> On Sat, 7 May 2022 at 16:42, wrote:
> >
> > In its current implementation, the list type does not provide a simple
> and straightforward way to retrieve one of its elements that fits a certain
> criteria.
> >
> > If you had to get the user where user['id'] == 2 from this list of
> users, for example, how would you do it?
> >
> > users = [
> > {'id': 1,'name': 'john'},
> > {'id': 2, 'name': 'anna'},
> > {'id': 3, 'name': 'bruce'},
> > ]
> >
> > # way too verbose and not pythonic
> > ids = [user['id'] for user in users]
> > index = ids.index(2)
> > user_2 = users[index]
>
user_2 = next(filter(lambda record: record["id"] == 2, users), default_val)
Or otherwise, use some library to have some higher level options to
manipulate
your data structures, even if they are lists of dictionaries.
I am right now working on "rows" (github: turicas/rows) package and charged
with
creating possibilities of lazy querying the data structures. This is
currently working
on my development branch:
In [26]: import rows
In [27]: zz =rows.table.FlexibleTable()
In [28]: zz.extend(users)
In [29]: zz
Out[29]:
In [30]: zz.filter = "id = 2"
In [31]: zz
Out[31]:
In [32]: zz[0]
Out[32]: Row(id=2, name='anna')
(or, if you want dicts back, you have to configure the Table instance:
In [33]: zz.row_class = dict
In [34]: zz[0]
Out[34]: {'id': 2, 'name': 'anna'}
)
https://github.com/turicas/rows/tree/feature/queries
> >
> > # short, but it feels a bit janky
> > user_2 = next((user for user in users if user['id'] == 2), None)
> >
> > # this is okay-ish, i guess
> > users_dict = {user['id']: user for user in users}
> > user_2 = users_dict.get(2)
> >
> >
> > In my opinion, the list type could have something along these lines:
> >
> > class MyList(list):
> > def find(self, func, default=None):
> > for i in self:
> > if func(i):
> > return i
> > return default
> >
> > my_list = MyList(users)
> > user_2 = my_list.find(lambda user: user['id'] == 2)
> > print(user_2) # {'id': 2, 'name': 'anna'}
>
> You seem to want a function, but it's not obvious to me why you need that.
>
> found = None
> for user in users:
> if user["id"] == 2:
> found = user
> break
>
> seems fine to me. If you need a function
>
> def find_user(id):
> for user in users:
> if user["id"] == id:
> return user
>
> works fine.
>
> Python is very much a procedural language, and "simple and
> straightforward" often equates to a few statements, or a loop, or
> similar. Unlike functional languages, where people tend to think of
> "simple" code as being about combining basic functions into compound
> expressions that do "clever stuff", Python code tends to be viewed as
> "simple and straightforward" (or "Pythonic" if you like) if it
> *doesn't* try to combine too much into one expression, but describes
> what you're doing in a step by step manner.
>
> So yes, a list doesn't provide the sort of "find" method you're
> suggesting. That's because a loop is easy, and does the job just fine.
>
> Paul
> ___
> 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/IIO2LDWQ7L3N2SJYV6SFJQ5KHMKWSFNU/
> 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/5NJGVVEUJXWUMNYZPJTZJAQCT4QKW5H3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enum should use __class_getitem__
Although ENUMs are already complicated enough, this proposals frees up messing with the EnumMeta metaclass in some cases - it makes sense. I've subclassed EnumMeta once for adding some feature in a project, and it never feels the "quite right" thing to do. On Tue, Apr 26, 2022 at 6:12 PM Stefan Nelson-Lindall < stefan.nelsonlind...@gmail.com> wrote: > EnumMeta implements its own __getitem__ function which doesn't respect > __class_getitem__. Now that __class_getitem__ exists, this behavior feels > unintuitive. For instance > > ``` > class Directions(enum.Enum): > LEFT = "LEFT" > RIGHT = "RIGHT" > > def __class_getitem__(cls, name): > return super().__class_getitem__(name.upper()) > > # fails with KeyError -- __class_getitem__ never called > assert Directions["left"] == Directions["LEFT"] == Directions.LEFT > ``` > > doesn't work, and the only way to implement this behavior is something like > > ``` > class MyEnumMeta(enum.EnumMeta): > def __getitem__(cls, name): > return cls.__class_getitem__(name) > > class MyEnum(enum.Enum, metaclass=MyEnumMeta): > def __class_getitem__(cls, name): > return cls._member_map_[name] > > class Directions(MyEnum): ... > ``` > > there might be some compatibility issues with code written between 3.4 and > 3.11, but not supporting __class_getitem__ feels like it violates the > principle of least surprise with the more recent data models. > ___ > 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/4VURZ4ZXPZRQ726KZH5DAOI47XXUKBI2/ > 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/NSN667S6QVHSV74XSZ6LFT5JNIRHFYFO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
Anyway, there is something dataclasses do today that prevent you from jsut
adding a @dataclass for binding __init__ attributes from an otherwise
"complete class that does things": it overwrites __init__ itself - one hass
to resort to write "__post_init__" instead,¨
That means that if some class you would like to have all the explicit named
parameters associated as attributes, and then pass other parameters to be
taken care of by the super-class, it simply does not work:
```
In [17]: from dataclasses import dataclass
In [18]:
In [18]: @dataclass
...: class A:
...: a: int
...: def __post_init__(self, **kwargs):
...: print(kwargs)
...:
In [19]: A(1, b=3)
---
TypeError Traceback (most recent call last)
Input In [19], in ()
> 1 A(1, b=3)
TypeError: A.__init__() got an unexpected keyword argument 'b'
```
No way to have "b" reach "__post_init__" and even less ways to have it be
passed on to any super().__init__ of "A", unless I manually write
A.__init__
A "language dedicated method" to do just the part of auto assigning the
attributes, is much more straightforward than converting the whole thing
into a dataclass.
I re-iterate that while I'd find this an useful addition, I think new
syntax for this would be overkill.
On Tue, May 3, 2022 at 12:34 AM Christopher Barker
wrote:
> On Mon, May 2, 2022 at 7:42 PM Steven D'Aprano
> wrote:
>
>> On Sun, May 01, 2022 at 10:40:49PM -0700, Christopher Barker wrote:
>>
>> > Yes, any class could use this feature (though it's more limited than
>> what
>> > dataclasses do) -- what I was getting is is that it would not be
>> > (particularly) useful for all classes -- only classes where there are a
>> lot
>> > of __init__ parameters that can be auto-assigned. And that use case
>> > overlaps to some extent with dataclasses.
>>
>> Ah, the penny drops! That makes sense.
>>
>>
>> > > Named tuples support all of that too.
>> > >
>> >
>> > No, they don't -- you can add methods, though with a klunky interface,
>>
>> Its the same class+def interface used for adding methods to any class,
>> just with a call to namedtuple as the base class.
>>
>> class Thingy(namedtuple("Thingy", "spam eggs cheese")):
>> def method(self, arg):
>> pass
>>
>> I think it is a beautifully elegant interface.
>>
>>
>> > and they ARE tuples under the hood which does come with restrictions.
>>
>> That is a very good point.
>>
>>
>> > And the
>> > immutability means that added methods can't actually do very much.
>>
>> TIL that string and Decimal methods don't do much.
>>
>> *wink*
>>
>>
>> > > One of the reasons I have not glommed onto dataclasses is that for my
>> > > purposes, they don't seem to add much that named tuples didn't already
>> > > give us.
>> > >
>> >
>> > ahh -- that may be because you think of them as "mutable named tuples"
>> --
>> > that is, the only reason you'd want to use them is if you want your
>> > "record" to be mutable. But I think you miss the larger picture.
>> [...]
>> > I suspect you may have missed the power of datclasses because you
>> started
>> > with this assumption. Maybe it's because I'm not much of a database guy,
>> > but I don't think in terms of records.
>>
>> I'm not a database guy either. When I say record, I mean in the sense of
>> Pascal records, or what C calls structs. A collection of named fields
>> holding data.
>>
>> Objects fundamentally have three properties: identity, state, and
>> behaviour. The behaviour comes from methods operating on the object's
>> state. And that state is normally a collection of named fields holding
>> data. That is, a record.
>>
>> If your class is written in C, like the builtins, you can avoid
>> exposing the names of your data fields, thus giving the illusion from
>> Python that they don't have a name. But at the C level, they have a
>> name, otherwise you can't refer to them from your C code.
>>
>>
>> > For me, datclasses are a way to make a general purpose class that hold a
>> > bunch of data,
>>
>> I.e. a bunch of named fields, or a record :-)
>>
>>
>> > and have the boilerplate written for me.
>>
>> Yes, I get that part.
>>
>> I just find the boilerplate to be less of a cognitive burden than
>> learning the details of dataclasses. Perhaps that's because I've been
>> fortunate enough to not have to deal with classes with vast amounts of
>> boilerplate. Or I'm just slow to recognise Blub features :-)
>>
>>
>> > And what
>> > dataclasses add that makes them so flexible is that they:
>> >
>> > - allow for various custom fields:
>> >- notably default factories to handle mutable defaults
>> > - provide a way to customise the initialization
>> > - and critically, provide a collection of field objects that can be
>> used to
>> > customize behavior.
>>
>> That sounds like a class builder mini-framework.
>
>
> Now you get it :-)
>
> What you describe as
[Python-ideas] Re: Add __name__ to functools.partial object
Actually, there is a good motive IMO for a partial function to have __name__ and __qualname__: the code one is passing a partial function might expect these attributes to be presented in the callable it get. It is just a matter of unifying the interface for callables that are often used as arguments in calls, and as such, even if __name__ and __qualname__ are fixed and immutable strings, this would be an improvement. (say, a partial callable __name__ could be fixed to "" just as a lambda's __name__ is "") On Tue, Aug 30, 2022 at 4:29 PM Wes Turner wrote: > Would a property or a copy be faster for existing and possible use cases? > In practice, how frequently will __qual/name__ be called on partials? > > - Copying __qual/name__ would definitely be a performance regression > > - There are probably as many use cases for partials as other methods of > functional composition, > - __qual/name__ support is not yet extant > > - it's faster to run e.g. a grid search *without* partials, due to > function call overhead, due to scope allocation on the stack in stackful > pythons [1] > > [1] Hyper Parameter Search > Scaling hyperparameter searches > > https://ml.dask.org/hyper-parameter-search.html#scaling-hyperparameter-searches > > [2] Pipeline caching in TPOT > http://epistasislab.github.io/tpot/using/#pipeline-caching-in-tpot > #parallel-training-with-dask ; TPOT generates actual python source code > instead of an ensemble of partials > > > > > > On Tue, Aug 30, 2022, 12:07 PM Charles Machalow > wrote: > >> We may be able to do __name__/__qualname__ as a property to make it >> evaluate when called as opposed to computed once on creation. That way we >> just work with .func upon call so no need for extra references, etc. >> >> As for documentation generation tools, it may be different at first, >> though I believe the existing ispartial checks would catch partials still. >> If they want to (in a new version) swap to using __name__/__qualname__ that >> should be fine, but this likely wouldn't inherently break existing tools. >> >> - Charlie Scott Machalow >> >> >> On Mon, Aug 29, 2022 at 11:08 PM Wes Turner wrote: >> >>> Is there a non-performance regressive way to proxy attr access to >>> func.__name__ of the partial function (or method; Callable)? >>> >>> Would this affect documentation generation tools like e.g. >>> sphinx-spidoc, which IIRC use __name__ and probably now __qualname__ for >>> generating argspecs in RST for HTML and LaTeX? >>> >>> >>> - https://docs.python.org/3/library/inspect.html >>> - functions and methods have __name__ and __qualname__ >>> - see: sphinx.utils.inspect >>> >>> - https://docs.python.org/3/library/functools.html#functools.partial >>> - >>> https://docs.python.org/3/library/functools.html#functools.partialmethod >>> - https://docs.python.org/3/library/functools.html#partial-objects >>> >>> > partial Objects¶ >>> > partial objects are callable objects created by partial(). They have >>> three read-only attributes: >>> > >>> > partial.func >>> > A callable object or function. Calls to the partial object will be >>> forwarded to func with new arguments and keywords. >>> > >>> > partial.args >>> > The leftmost positional arguments that will be prepended to the >>> positional arguments provided to a partial object call. >>> > >>> > partial.keywords >>> > The keyword arguments that will be supplied when the partial object is >>> called. >>> >>> > partial objects are like function objects in that they are callable, >>> weak referencable, and can have attributes. There are some important >>> differences. For instance, the __name__ and __doc__ attributes are not >>> created automatically. Also, partial objects defined in classes behave like >>> static methods and do not transform into bound methods during instance >>> attribute look-up. >>> >>> >>> - https://www.sphinx-doc.org/en/master/man/sphinx-apidoc.html >>> - https://www.sphinx-doc.org/en/master/_modules/sphinx/ext/autodoc.html >>> : 18 references to __qualname__, >>> >>> >>> https://github.com/sphinx-doc/sphinx/blob/5.x/sphinx/util/inspect.py#L49-L66 >>> : >>> >>> ```python >>> def unwrap_all(obj: Any, *, stop: Optional[Callable] = None) -> Any: >>> """ >>> Get an original object from wrapped object (unwrapping partials, >>> wrapped >>> functions, and other decorators). >>> """ >>> while True: >>> if stop and stop(obj): >>> return obj >>> elif ispartial(obj): >>> obj = obj.func >>> elif inspect.isroutine(obj) and hasattr(obj, '__wrapped__'): >>> obj = obj.__wrapped__ # type: ignore >>> elif isclassmethod(obj): >>> obj = obj.__func__ >>> elif isstaticmethod(obj): >>> obj = obj.__func__ >>> else: >>> return obj >>> ``` >>> >>> From >>> https://github.com/sphinx-doc/sphinx/blob/5.x/sphinx/util/inspect.py#L173-L186 >>> : >>> >>> ```python >>> def unpartial(obj: Any) -> Any: >>>
[Python-ideas] Re: Idea: Tagged strings in python
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 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/LFWSTEFW46ATMCTRRM6FZYCYX7WQBWSG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow more flexibility for describing bytes objects.
Well - one can already do:
x = bytes.fromhex
x("01 23 45 67 89")
As for base64, I really, really, don't see a use case where allowing base64
native strings as
part oif the syntax could be useful - less so when decoding is one call
away.
Base64 was already created to allow one to convey arbitrary data as strings
- let them be strings,
As for the "x" mode: I think the burden - including cognitive when teaching
Python - to include
new prefix strings easily overcome any gains there might be - again, more
so once that
a call like `bytes.frohex` is readily available.
js
-><-
On Wed, Nov 23, 2022 at 9:33 AM Ronald Hoogenboom via Python-ideas <
python-ideas@python.org> wrote:
> Refer to PEP 3137 and PEP 358.
>
>
>
> Bytes objects are for conveying binary data (or encoded strings). Such
> binary data is customary specified in hex-dump or base64 format in source
> files.
>
> It would be nice to introduce a way in python to do that ‘natively’ (at
> lexical analysis time) using x-strings and y-strings (in lieu of f-strings).
>
>
>
> x-strings:
>
>
>
> x”0123456789abcdef” (x-prefixed quoted string of
> even-numbered amount of characters of the set [0-9a-fA-F], whitespace
> ignored)
>
> equivalent to:
>
> b”\x01\x23\x45\x67\x89\xab\xcd\xef” (but more readable)
>
>
>
> y-strings:
>
>
>
> y”ASNFZ4mrze8=” (y-prefixed quoted string of valid base64,
> whitespace ignored)
>
> equivalent to:
>
> b”\x01\x23\x45\x67\x89\xab\xcd\xef” (but shorter)
>
>
>
> This is not a replacement of the hex/base64 encoding, binascii packages
> etc. It just gives the programmer more freedom to specify literal bytes
> objects in the source code.
>
>
> ___
> 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/VGXARYOPWYXUVGF6FA4DPMHCKIQVQF6L/
> 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/E7ZTS5OGHRT42TIP3WBSYTLZ6L6MPMK7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
I hope you are at least aware that over the years various multi-year attempts to create Python sandboxes ultimately failed to the point of being altogether abandoned. Python and Javascript differ fundamentally that Python runtime is intrinsically bound to I/O, like filesystem access - which is a thing that is isolated and "plugged-in by the environment" in Javascript. Besides that, the object model allows one to - sometimes not so easily, but always consistently - bypass any write-restrictions to variables and other memory states that would be used to restrict any access. Ultimately any sandboxing in Python has to be accomplished at OS level (like running everything in a container), at which point there is no granularity to restrict individual Python packages or modules anyway. On Sun, Feb 26, 2023 at 12:32 PM python--- via Python-ideas < python-ideas@python.org> wrote: > Hello all, > > Supply chain attacks are becoming a pressing concern in software > development due to the large number of dependencies and multiple attack > vectors. Using third party modules (libraries, packages etc) is always a > risk but the true potential of these attacks is now being weaponized. One > way to deal with the risk is by limiting access to sensitive APIs like > filesystem, shell, network and ffi so that packages which aren't explicitly > granted permissions cannot use them, reducing their ability to do damage. > > For example, a yaml parser should not need to use ffi, network nor shell. > A command line argument parser library should not use network, ffi nor > filesystem. Deno, a runtime for Typescript contains an interesting > implementation of a permissions model for APIs. > > I strongly think Python could benefit from such functionality and hacked > together a quick experiment here: https://github.com/R9295/cpython > Currently, it only prevents module imports in a very elementary manner but > perhaps it can be of use to spark a discussion for an implementation. > > Looking forward to your thoughts, > Aarnav > ___ > 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/MZNP5ZJBLMUO74PMZGWJGM6TAZXBK5AS/ > 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/U6YSNV5N2YATTZDSGXU4USA3P7TKEIBZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ampersand operator for strings
On Mon, Mar 6, 2023 at 12:51 AM David Mertz, Ph.D.
wrote:
> Is it really that much longer to write `f"{s1} {s2}"` when you want that?
>
As for being that much longer: yes it is.
The more important factor is, I think, the increase in complexity +
readabiity for default strings is worth it in this case.
One nice thing to think about might be how to make string subclassing to be
more useful - so this kind of thing could be done for whoever needs it in
one more idiomatic project. The drawback is how cumbersome it is to
instantiate a string subclass compared to a string literal. (I just got an
idea, but it would be too offtopic here - if I think it is worth, I will
post it in a new thread later)
>
> Maybe a couple characters more total, but once you are in an f-string, you
> can also do a zillion other things at the same time.
>
> On Sun, Mar 5, 2023 at 10:42 PM Rob Cliffe via Python-ideas <
> python-ideas@python.org> wrote:
>
>> Tl;dr: Join strings together with exactly one space between non-blank
>> text where they join.
>>
>> I propose a meaning for
>> s1 & s2
>> where s1 and s2 are strings.
>> Namely, that it should be equivalent to
>> s1.rstrip() + (' ' if (s1.strip() and s2.strip()) else '') +
>> s2.lstrip()
>> Informally, this will join the two strings together with exactly one space
>> between the last non-blank text in s1 and the first non-blank text in s2.
>> Example: " bar " & "foo"==" bar
>> foo"
>>
>> This operator is associative, so there is no ambiguity in expressions
>> such as
>> s1 & s2 & s3
>> There *is* a possible ambiguity in expressions such as
>> s1 & s2 + s3
>> where the relative precedence of `&` and `+` matters when s2 consists
>> solely of white space. E.g.
>> " A " & " " + " C" would evaluate
>> to " A C"
>> not to " A C"
>> because `+` has a higher precedence than '&'.
>>
>> Utility:
>> In decades of experience with another language which had such an
>> operator
>> (spelt differently) I have frequently found it useful for
>> constructing
>> human-readable output (e.g. log output, debug/error messages,
>> on-screen labels).
>>
>> Cognitive burden:
>> This would of course be one more thing to learn.
>> But I suggest that it is fairly intuitive that
>> s1 + s2
>> s1 & s2
>> both suggest that two strings are being combined in some way.
>>
>> Bars to overcome:
>> This change would require no fundamental change to Python;
>> just adding an `__and__ function to the str class.
>>
>> Backward compatibility:
>> Given that `str1 & str2` currently raises TypeError,
>> this change would be close to 100% backward-compatible.
>>
>> Alternative meanings:
>> As far as I know nobody has ever suggested an alternative meaning
>> for `&` on strings.
>>
>> Bikeshedding:
>> (1) I don't think it is important for the utility of this change
>> whether `&` strips off all whitespace, or just spaces.
>> I think it is better if it strips off all whitespace,
>> so that it can be understood as working similarly to strip().
>> (2) The definition could be simplified to
>> s1.rstrip() + ' ' + s2.lstrip()
>> (leave an initial/final space when one string is whitespace
>> only).
>> Again the operator would be associative.
>> Again I don't think this is important.
>>
>> Rob Cliffe
>> ___
>> 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/66XP7GY56XU7H3P52IJENLSWJFW53XIN/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> 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-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/M7H3VZFEUJFZDO3BAAVUGXNKBH6WF4NA/
> 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/2XXY57LCSNNS6SVRUIYBSA6QT2P7RH4F/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ampersand operator for strings
On Mon, Mar 6, 2023 at 7:37 AM Steven D'Aprano wrote: > (...) > I like the look of the & operator for concatenation, so I want to like > this proposal. But I think I will need to see real world code to > understand when it would be useful. > I'd say we paint the shed blue. I mean - maybe "|" is more pleasant when thinking about concatenation. > > > -- > Steve > > ___ 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/LYZ3ZAQNIUP3CCNWDGZWYAGBFLUFPHK2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allowing `str.format` to format one or more parameters instead of all parameters
On Sat, Apr 22, 2023 at 10:06 AM Damian Cross wrote: > That would have the effect that every use of str.format for everyone would > start producing partially-formatted strings if an argument is accidentally > omitted instead of raising an error. Some people might not like that. > ___ > If that is all there is for a downside, this is actually quite weak. You just changed my mind to +1 on the proposal. Worst case scenario, one goes from one non-running program to a running program producing partially incorrect output. Any legacy code that was not working in the first place, is obviously, clearly, not critical for anyone, otherwise it would have been fixed already. We can't stal all augmenting to language functionalities because "some is used with the fact writing incorrect code in this way used to produce an error before". Ultimately, by this logic, it would be impossible to add even any new keyword only parameters to any stdlib call, because "there might be some code out there using this parameter, and that used to raise an error" ___ 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/TULTZSF4M5E3AU5MPNMIGSKIKDSF36RR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Explicit encapsulation is better than implicit hardcoding?
"it's a bit more challenging to obtain a separate asyncio loop." Just call `asyncio.new_event_loop` and you can have as many event loops in the same thread as you want. On Thu, Jun 8, 2023 at 10:58 AM Dom Grigonis wrote: > Hey there! I'm curious to know what this group thinks about the implicit > design of many Python libraries, both core and open source. What I mean by > "implicit design" is when an interface of library is established and > initialised at module’s level rather than explicitly encapsulated in > classes. > > Couple of the examples: > 1. logging > 2. asyncio > > Both of the libraries (by design) allow only 1 framework per process, > which can be limiting. Although it's easier to hack the logging library > to obtain an independent hierarchy with separate root node, it's a bit more > challenging to obtain a separate asyncio loop. > > Allowing users to instantiate a fresh instance of framework would be > advantageous in various ways: > > 1. "Explicit is better than implicit" - easier to understand, inherit, and > edit. > 2. The ability to instantiate multiple framework nodes leads in a > modifiable, therefore easier to comprehend workflow. For example, having > separate logging and asyncio on a thread would provide for greater design > freedom. > 3. Code reusability. When I am looking for code (to avoid reinventing the > wheel), whenever I find initialisations at the module level it is a signal > that the code is not easily reusable, and I continue my search. I'll return > to such code as a last option. > > I think such design is reasonable for “end result” products, that are not > at the risk of becoming standard dependencies, but is it a good idea to > continue this standard practice for "building block" libraries? > > It is not a complaint in and of itself (maybe a bit), but rather an > attempt to spark a discussion about whether more modular and explicitly > contained architecture would help the Python community the most in the long > run. > > > > > > > ___ > 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/M7D7G6R6RYKPX4AM2SDERYOKT4ISXODN/ > 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/MHYVBO7ALVNYXG6JGH7XPNPITJ6YGUDB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.
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) >> >> 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#76533091 I like the dataclasses.attribute idea, though - (but it will also require static type checking tools to review their dataclass 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.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/C5QJQT5YV7UOKFF57PWD4VSF4RWUDOSF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Julia envy
If you use Python's own arrays and generator expressions instead of list
comprehension (by just dropping the `[ ]`s),
you will get each number converted to the target type in memory as soon as
it is calculated. (It will be a full
Python float/int instance during the calculation itself, though).
This won't work with the usual numpy array constructors as those need the
array size beforehand - but if you know
the size beforehand, there is probably a numpy constructor with no need to
go through Python arrays first (but I don't know one by heart)
```
import numpy as np
import array
data = np.array(array.array("b", (int(127 * cos(i/100)) for i in
range(628))), dtype="int8", copy=False)
```
On Fri, Jun 23, 2023 at 10:53 AM Neal Becker wrote:
> One item I admire from Julia and miss in python/numpy,
>
> I often use the power of python list comprehension to process data. This
> data often needs to be converted to numpy for other operations, for
> example
> fancy indexing. The fact that operations using comprehensions (which
> produce lists) and operations on numpy arrays use different incompatible
> data structures requires conversions between lists and numpy arrays.
> Comprehensions in Julia produce arrays directly (I believe), removing the
> need for conversions.
>
> I don't see any easy way to improve this. Any ideas?
>
> Thanks,
> Neal
>
> --
> *Those who don't understand recursion are doomed to repeat it*
> ___
> 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/SRT377EAT4BAOFNMXXX7J7UFFQAJZBPZ/
> 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/IJB2VJHRVY5TUXILQDV4CZJEKPPTWHP2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.
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. > 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#76533091 > > I like the dataclasses.attribute idea, though - (but it will also require > static type checking tools to review their > dataclass 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.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/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/B3YHKCWMD2LN6VYNMGY4WHZWZFKGP3TC/ Code of Conduct: http://python.org/psf/codeofconduct/
