[Python-ideas] Add extend_const action to argparse
Forgive me if this idea has been discussed before, I searched the mailing lists, the CPython repo, and the issue tracker and was unable to find anything. I have found myself a few times in a position where I have a repeated argument that uses the `append` action, along with some convenience arguments that append a specific const to that same dest (eg: `--filter-x` being made equivalent to `--filter x` via `append_const`). This is particularly useful in cli apps that expose some kind of powerful-but-verbose filtering capability, while also providing shorter aliases for common invocations. I'm sure there are other use cases, but this is the one I'm most familiar with. The natural extension to this filtering idea are convenience args that set two const values (eg: `--filter x --filter y` being equivalent to `--filter-x-y`), but there is no `extend_const` action to enable this. While this is possible (and rather straight forward) to add via a custom action, I feel like this should be a built-in action instead. `append` has `append_const`, it seems intuitive and reasonable to expect `extend` to have `extend_const` too (my anecdotal experience the first time I came across this need was that I simply tried using `extend_const` without checking the docs, assuming it already existed). Please see this gist for a working example that may help explain the idea and intended use case more clearly: https://gist.github.com/roganartu/7c2ec129d868ecda95acfbd655ef0ab2 _______ 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/7ZHY7HFFQHIX3YWWCIJTNB4DRG2NQDOV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add _KB, _MB, _GB to numeric literals
Sorry for the late response on this. I tried to respond earlier but was stymied by issues with the mailing list server. The last time this was discussed I was the one to raise the suggestion. You can find the start of the thread: 25 Aug 2016: SI scale factors in Python https://mail.python.org/archives/list/python-ideas@python.org/message/HVHRIR4BO7CPVXZSZTMFDEHUFOLBU633/ The gist of the suggestion was that SI scale factors have been an internationally standardized way of writing real numbers for over 50 years and is a much nicer than using exponential notation, so wouldn't be a good idea to add support for SI scale factors directly into the language. There was considerable discussion but no consensus emerged for changing the base language. However, the discussion bore fruit in QuantiPhy (https://quantiphy.readthedocs.io), a Python package that incorporates the ideas and suggestions that came up during that discussion. So, while it is still not possible to use SI scale factors in Python real literals, you can use this package to easily use SI scale factors in IO. -Ken ___ 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/YBX7Z4EQXYUDCMOW7CCSGQ6MX6K5IZO7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Native support for units [was: custom literals]
Much of this discussion is based on a misconception. Units and SI scale factors are very useful in software that describes or interacts with the real world, but primarily on input and output. They are not normally used for internal calculations. The idea that one carries units on variables interior to a program, and that those units are checked for all interior calculations, is naive. Doing such thing adds unnecessary and often undesired complexity. Rather, it is generally only desirable to allow users to include scale factors and units on values they specify and values they read. This implies that it is only necessary to provide a package for reading and writing physical quantities, and indeed such a package exists: QuantiPhy. QuantiPhy came out of the ideas that were raised the last time this topic was discussed on this mailing list a few years ago. However, there are two reasons to consider adding both SI scale factors and unit in Python itself. First, SI scale factors have been an international standard way of specifying real value for over 50 years, and use of SI scale factors results in numbers that are more compact and easier to read than using exponential notation. Second, providing units with numbers provides important information, and specifying that information in a program reduces ambiguity, and providing the units results generally decreases the chance of errors. For example, consider the following three versions of the same line of code: virt /= 1048576 virt /= 1.048576e6 virt /= 1MiB The last is the easiest to read and the least ambiguous. Using the units and scale factor on the scaling constant results in an easy to read line that makes it clear what is intended. Notice that in this case the program does not use the specified units, rather the act of specifying the units clarifies the programmers intent and reduces the chance of misunderstandings or error when the code is modified by later programmers. But this suggests that it is not necessary for Python to interpret the units. The most it needs do is to save the units as an attribute so that it is available if needed later. -Ken ___ 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/GLDH5XEUHOZHQRGTEAADDANQX67V3DZ2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Restricting access to sensitive APIs with a permission model like Deno
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] Re: Restricting access to sensitive APIs with a permission model like Deno
Could you elaborate on how Python code can easily bypass that sort of restriction? >From my understanding, you can only do so with importlib by reading the raw >source and evaluating it. In that case, I can just restrict importlib? Same >with the open function which is from the io module which can also be >restricted (and removed from builtins in that case). Here's a diff of my implementation and upstream's 3.11.0 tag. It's 17 commits with most being README changes. I hope this makes it more clear. https://github.com/python/cpython/compare/3.11...R9295:cpython:policy Regards, 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/NWQCBFQECB3CI3WSHSK46FTX3MAN5Z25/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
With Python being a language heavily utilized in server and end-user applications, I would take a different approach for both. I have to admit I haven't thought much about the "normal user" in this case and focused primarily on developers. Perhaps developers shipping an application ship the code with a module policy? The way I imagine the implementation is that module restriction is recursive, so I only have to look at my top-level dependencies and not their sub-dependencies when wanting to restrict a module. Regarding the second part, I think restricting it to modules would be ideal. I also think the permissions should be like the Android model where an application can prompt you. Deno does it in an interesting manner where you can choose to be prompted, which makes sense when running an end-user application or you could reject any prompting and accept or deny the request automatically which makes sense in a server-side application. I hope this answers your questions. I am happy to elaborate if not. ___ 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/XUVRKOELTXXEYFZAJQ7E3IRNYSDTPFVO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
I override the import mechanism in cpython, so yes, the __import__ function is also accounted for. The sys.modules was something I had not considered, that's a good point. I will have to look into it. I am not sure how arbitrary code execution will be able to use native APIs without importing them. ___ 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/2YUSPKDMLFVGJLPQXJ3ISJ2VDGJN7B45/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Thank you for the insight. I have some more work to do! I will share on this thread again when I've made further changes. If you have some time, I would be grateful if you could share a few test cases such as "bypass it by spinning off a new thread", or. object.__subclasses__. code is not necessary but just pointers. Thanks and regards, 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/PJKPIHQT2XFF4BE2MSQ5NSSJVLR75SS2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Have you looked at the diff? It's not "1000+" commits as you claim. It's 17 commits with most being README changes. The base is not the master branch but the 3.11.0 release. https://github.com/python/cpython/compare/3.11...R9295:cpython:policy I do not see why you cannot audit and run this (or atleast read the code) since it's required to have a meaningful discussion, the overriding happens before the module resolution itself so sys.path is irrelevant. _______ 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/MRUPHNBP26UDO476PSLNBTXA4YUJBHYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Thank you for your insight. >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. Yes I am, I have looked at pysandbox and RestrictedPython and I believe my approach, albeit very early stage, differs from theirs. >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. If you have some time, could you provide me with an example or two? If I understand it correctly, only FFI would be able to do so, am I right? Regards, 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/K6RYERRLFVWSS3RRRJSRGAIDA2XFZBDH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
I really appreciate the pointers, thank you. I will look into them. ___ 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/JDSYZUKU6D7GWQAOM3KQEYKIFHDYILW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Makes sense, will do so. ___ 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/LJD7LVT7DNPRTV3MIJ2YLK4YTNKG37WQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] asymcio.TimerHandle.done()
I'm rewriting an existing python program using a 3rd party async library to standard asyncio. That library allows one to check if a timer created with: timer = loop.call_later(delay, callback) is active, i.e. not cancelled and the scheduled callback not executed yet. I'm missing that functionality in asyncio and would like to propose: TimerHandle.done() = True if cancelled or no longer waiting in the event loop's queue; otherwise False In that program sometimes a state is defined just by the mere existence of an active timer - no state variables, no real callbacks. I find that quite a natural mini-pattern. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Adding a .find() method to list
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]
# 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'}
___
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/3ZOLBF3TWGLIHO6LRS57I4OO5UISFGMO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
I didn't realize def foo(x, y=[]) had this strange artifact but it totally makes sense, TIL. I did not get the right idea reading the PEP though, since currently the motivation reads: > Optional function arguments, if omitted, often have some sort of logical > default value. When this value depends on other arguments, or needs to be > reevaluated each function call, there is currently no clean way to state this > in the function header. and I kinda glossed over the second use-case. I feel like more emphasis can be added since that part is what necessitates the new syntax. I do think that being able to reference other arguments is very useful in it's own right and would go a long way in helping to solve the None check problem brought up in PEP 505 even more cleanly. _______ 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/D4DP4UB7LPYPBNPTXIZDRVD6NOPMGPQP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add symlinks option at shutil.move parameters
Well, I suppose it wants simlink=False. Anyway, why not change the signature of move to def move(src, dst, **kwargs): and change the call of copytree to copytree(src, real_dst, **kwargs) ? ___ 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/ALEUCO7GE2RIFJ3CT2PQEYLO4F7BLZIK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Segmentation of string
import itertools as itools def segment(it, n=1): try: len_it = len(it) it_true = it except TypeError: it_true = tuple(it) len_it = len(it_true) size, rest = divmod(len_it, n) sizes = [size] * n for i in range(rest): sizes[-i] += 1 all_sizes = frozenset(itools.permutations(sizes)) res = [] for sizes in all_sizes: elem = [] i = 0 for size in sizes: elem.append(it[i:i+size]) i += size res.append(elem) return res ___ 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/7O64PBAIPITLTO32ZCIGPL2STKEGNQW4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Segmentation of string
Excuse me, ignore my previous post, this is the correct implementation. It
works for every iterable:
import itertools as itools
def segment(it, n=1):
if n < 1:
raise ValueError(f"Number of segment must be > 0")
try:
len_it = len(it)
it[0:0]
it_true = it
except TypeError:
it_true = tuple(it)
len_it = len(it_true)
if len_it < n:
raise ValueError(f"Iterable length {len_it} must be greater than
number of segments {n}")
size, rest = divmod(len_it, n)
sizes = [size] * n
orig_sizes = sizes.copy()
all_sizes = []
for i in range(1, rest+1):
for j in range(1, rest-i+2):
sizes[-j] += i
all_sizes.append(frozenset(itools.permutations(sizes)))
sizes = orig_sizes.copy()
if not all_sizes:
all_sizes.append((sizes, ))
res = []
for perm_sizes in all_sizes:
for sizes in perm_sizes:
elem = []
i = 0
for size in sizes:
elem.append(it_true[i:i+size])
i += size
res.append(elem)
return res
_______
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/E452LQGA3XKU5ADPTG54XP36ENXDZN2B/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add "elif" to "for_stmt" and "while_stmt"
There's already: for i in range(j): if i > 5: ... else: ... else: ... ___ 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/3HHT4L3A4PMAABPIWG6JJMGQCJFPACGC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Segmentation of string
See my implementation, is generic and not only for strings. It could be added to more-itertools, I suppose: https://mail.python.org/archives/list/python-ideas@python.org/message/E452LQGA3XKU5ADPTG54XP36ENXDZN2B/ ___ 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/TOCNFSPMUZSCFZCUEXMAOYEDYS65UDQH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Segmentation of string
Excuse me again, I just relized that my algorithm was flawed. I just inserted
in my function the brilliant algorithm of Mark Dickinson and now it works:
import itertools as itools
def segment(it, n=1):
if n < 1:
raise ValueError(f"Number of segment must be > 0, {n} found")
try:
len_it = len(it)
it[0:0]
it_true = it
except TypeError:
it_true = tuple(it)
len_it = len(it_true)
if len_it < n:
err = f"Iterable length {len_it} must be greater than number of
segments {n}"
raise ValueError(err)
return (
[it_true[i:j] for i, j in zip((0, ) + startends, startends +
(len_it, ))]
for startends in itools.combinations(range(1, len_it), n-1)
)
_______
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/KYMYVYHLILBWOSQ4LSVBWON723HJKH3D/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)
If I can spend my two cents, I think the fact the most of you prefer | is because is already how sets works. And IMHO it's a bit illogical, since sets also support -. So I do not understand why | was chosen instead of +. Furthermore, sets supports < operator, that gives you the false hope that sets can be sorted. But it's not. So I don't think sets are *not* a good example. On the contrary, I feel so **natural** to see dict1 + dict2. Furthermore, the problem is: what is better for generic functions? Maybe I need a generic function that, in its code, do also a sum of input objects. Maybe I want to support also dict. In this way writing such function is much more hard. _______ 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/GAXPZEUWV2R6LTOD4GKDOIKQRIGNSJWN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Renaming json.load()
Well, `json` and the other modules could add another standard: `serialize` and `deserialize` As an example, this is how I deserialize from a custom class: def __init__(self, source): path = None try: # most common case: JSON string self._data_raw = json.loads(source) except TypeError: try: # check if it's a dict-like object source.items self._data_raw = copy.deepcopy(source) except AttributeError: try: # maybe a file object? self._data_raw = json.load(f) except AttributeError: # maybe a PathLike? path = source except JSONDecodeError: # maybe a path string? path = source if path: with open(path) as f: self._data_raw = json.load(f) Apart the `dict` check, this logic could be applied to a `json.deserialize()` function. Python let you function overloading more simple, so why not use 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/6KZ54WSNMPB3PQELLDZAQ27SLSJPEVNS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)
Andrew Barnert wrote: > On Dec 25, 2019, at 14:57, python-ideas--- via Python-ideas > python-ideas@python.org wrote: > > If I can spend my two cents, I think the fact the > > most of you prefer | is because is already how sets works. And IMHO it's a > > bit illogical, > > since sets also support -. So I do not understand why | was chosen instead > > of +. > First, what does it matter that sets support -? You could just as well argue > that > + for list and str is illogical because int supports - and they don’t. Subtracting two lists or two strings has no sense, so the comparison is unfair. On the contrary, on sets you can apply union *and* difference. And since union seems the exact contrary of difference, it's illogical that | is used instead of +. That said, the set API at this point is consolidated. My only hope is Python does not make the same errors with `dict` or any other type. > (Although really, I think “illogical” is a strange claim to make for any > option here. It’s > logical to spell the union of two dicts the same way you spell the union of > two sets See above... > Of course you have to be careful because it’s only a partial order, and > sorting sets > that aren’t comparable is usually meaningless Indeed, what a coder really need is a isstrictsubset() method, not <. Since set1 < set2 has sense, but sorted(sets) have not. So it was better to have set1.isstrictsubset(set2) and **no** <. But, as I said, the ship was sailed for sets. > What kind of code needs to “sum” generic things that might be dicts and might > be > lists, when they mean such different things? Now I can't think about any practical example. Anyway, generally speaking, Python is full of functions that can be applied to completely different objects, just because the API is identical. If it quacks... > And why doesn’t this code also need to sum sets? Who said it does not need? It will be simply more convoluted. So I hope, again, this does not happen to `dict` too. > What’s special and common to numbers, timediffs, sequences, and dicts. but > not sets, tries, and datetimes? Well, because summing 2 datetimes has no sense? About tries, I don't remember tries in the stdlib. If so, it's OT. > Also, the PEP explicitly says that it’s not ruling out adding all of the set > operators, > just deferring it to a separate PEP to be written (and accepted or rejected) > in the > future. ...I'm not asking to support other operators and I don't really know why you think so. > you seem to have configured your python-ideas-posting address > with the name “python-ideas” rather than with a name that can be used to > distinguish you > from other people. This will make conversations confusing. it's python-ideas@***marco.sulla.e4ward.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/3MR4NMJO6SBG3JMGDE4PN74AAKIRAJKW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP for experimental/provisional features
Reading the latest discussion about PEP 622/634-636 on the Python Dev mailing
list, I've noticed there appears to be confusion about what `__future__`
imports are supposed to be used for. Multiple people in that thread (and
probably elsewhere in one of the many many threads about these PEPs) have
suggested including pattern matching as a "provisional" or "experimental"
feature that is enabled by an import from `__future__`.
I don't want to discuss whether `__future__` is the correct place for this
however (and I also don't want to discuss PEP 622/634-636 specifically).
Instead I'd like to propose a `__provisional__` namespace (or whatever color
you favor for your bike shed) for new language features/ standard library
modules that might undergo breaking changes over a couple of subsequent python
releases. This is similar to how many applications start in a version V0.1 and
undergo changes until they mature and reach V1.0.
>From the user perspective this would allow more "adventurous" users to play
>with the latest features (with the clear warning attached that they might have
>to adapt their own code over subsequent python releases) while anyone else can
>just ignore the new feature for now. From the perspective of the language
>designers the advantage I see is that they can get a first version of a
>feature out to real users to collect feedback on whether the feature is used
>as they imagined it being used and change/iterate the design if need be. It is
>simply unrealistic to get something like `asyncio` or PEP 622/634-636 perfect
>and feature complete on the first try or otherwise wait indefinitely until
>something is ready.
Some thoughts what `__provisional__` SHOULD and SHOULD NOT be used for:
- `__provisional__` SHOULD be useable at the users own discretion (e.g. no use
of provisional features in the standard library etc. )
- `__provisional__` SHOULD be a place for features with a vast design space
that need to "ripen" as use cases are explored (`asyncio` would have been the
poster child candidate for `__provisional__`)
- features SHOULD only be placed in `__provisional__` if there is a clear
commitment to the feature (the general feature is accepted by the SC before
being included in `__provisional__`). `__provisional__` SHOULD NOT be a place
where contentious PEPs are thrown into willy-nilly and postpone the decision of
whether to accept a PEP or not. Otherwise users would not only have to deal
with changes to a feature (they obviously showed interest in using) but also
with complete removal/deprecation.
- `__provisional__` SHOULD only be used for features that are additive to the
language and don't change existing code (which is what imho. what `__future__`
is for).
- `__provisional__` SHOULD have a clearly defined process (timelines etc.)
Alternative ideas that have been mentioned (in threads about PEP 622/634-636
and elsewhere) and why I personally don't think they are sufficient:
- "just throw together a library that parses strings and uses `eval`, put it
on pypi to see how that goes": For features that require new syntax this just
doesn't work imho. Using `pep622_lib.match("put your match statement here")` is
a very poor substitute for trying this out due to the influence design choices
such as keywords, indentation etc. have on usability. Examples for this are
syntax highlighting, autocomplete/autoindent/autoformat and linting which you
just don't get this way.
- various degrees of: "solve the issue of contention over new languages
features once and for all by introducing macros/preprocessors to the language":
Against this I have just my personal plea "please don't turn python into
lisp/c++".
___
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/3MOCAHEFPQDITY6AHRDIILDB5MZNTYKP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP for experimental/provisional features
> it's subject to change in future releases; you'll need to change > your code accordingly if it changes > because it's language change, it's unlikely you can conditionally > choose which syntax to use based on the version of Python being used > you enable it explicitly and accept the instability of the language > feature Thats the gist of it, yes. One example that comes to mind from PEP 622/634-636 would be the special casing of `True`, `False` to use identity (`is True`) for comparison and not equality (`== True`). As far as I remember this was not in PEP622 originally and if it were released this way would have been impossible to change later. ___________ 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/YMSTRGYDX6LH2T7W4WGXP5EJ7ERROH2X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On 12/02/2021 07:32, Paul Sokolovsky wrote: Hello, On Fri, 12 Feb 2021 18:26:53 +1100 Chris Angelico wrote: On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky wrote: ... And on the 2nd thought, that won't work. The reason it works in JS is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" means "compare a tuple for greater-or-equal". Should be safe actually - "=>" is not a valid comparison operator. It may not be a valid operator - but it reads as if it could be. using '=>' for this will decrease the readability as far as I can see. It takes a bit of mental processing to realise this isn't a valid comparison, and then more processing to understand what it does mean; it will definitely be a source of confusion for beginners. The fact that a very respected member of the community got it wrong at first sight suggests that many will do so. If we were going to do this - and I am still on the fence - I think we should avoid anything that reads like it could be confused as an operator. ___ 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/3SAONT64IU4LP4ML3XARVPESJKG25CY2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: [Python-Dev] Suggestion About Python Syntax
Dear Anthony, Greetings from another Anthony (although my friends call me Tony). Thank you for your suggestion about changes to the Python Syntax. The Idea of having curly braces with blocks of code has been considered many times, and every time it has not been accepted. When you do enough programming even in languages such as C, C++ and Java which do use Curly braces (or languages such as Pascal which use Begin/End and other such keywords), you will find that you do indent your code consistently as a matter of habit. Most serious developers in those languages will use auto-formatters to ensure that their code is nicely indented. Even though they use languages which have syntax elements to denote the start and end of a block, they recognize that indentation is a very natural way to layout code to make it readable, and they avoid 'indentation where ever they want'. Python - by adopting indentation as it does - has simply adopted a very natural form for writing code, and made it mandatory. You might be surprised to know that Python does allow semicolons at the end of statements, but they are optional, and really only used to run mutiple statements together on a single line; which is not considered to be a good style of writing. Don't be put off by this message - keep enjoying Python and learning about the world of programming. You have taken your first steps in the Python community, and we all look forward to hearing what ever ideas you might have in future. Good luck in your future journey in the computing universe. Tony Flury. On 03/03/2021 18:24, George Harding wrote: -- Forwarded message - From: *Anthony Farino* <mailto:antho...@pacemschool.org>> Date: Wed, Mar 3, 2021 at 5:52 PM Subject: [Python-Dev] Suggestion About Python Syntax To: mailto:python-...@python.org>> I love the Python scripting language, but there’s something that would make it much better. Almost every other programming language uses curly braces to enclose blocks of code and semicolons after the lines of code. That means that: 1. You can have as much white space as you want. 2. You don’t need to worry about indentation, and you can indent whenever you want. I hope that you consider these issues and fix them in Python 4 (if you ever make it). Sincerely, Anthony, age 10. -- mm m # ## m mm mm#mm # mm mmm m mm m m # # #" # # #" # #" "# #" # "m m" #mm# # # # # # # # # # #m# # # # # "mm # # "#m#" # # "# m" "" ___ Python-Dev mailing list -- python-...@python.org <mailto:python-...@python.org> To unsubscribe send an email to python-dev-le...@python.org <mailto:python-dev-le...@python.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/> Message archived at https://mail.python.org/archives/list/python-...@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/ <https://mail.python.org/archives/list/python-...@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/> ___ Python-ideas mailing list --python-ideas@python.org To unsubscribe send an email topython-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived athttps://mail.python.org/archives/list/python-ideas@python.org/message/OEIEGBD5CNZSHY3D4EIIM35WELCKHPRJ/ 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/WK3WSL4IDSMQ53F3E6LANPKLDYNLPST3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] allow initial comma
I had posted this as https://github.com/python/peps/issues/1867
The discussion so far is below.
Please make some arguments.
The major point to me is, that the symmetry is broken,
which leads to extra editing actions, like removing the comma in the first line.
I guess, this was the reason to allow the comma after the last line/entry:
`[1,2,]`.
``[,1,2]`` should also be allowed, too.
The best argument is one that says: less or more effort in this or that
situation.
For example, with `[1,2,]`, in line-wise formatting,
one can do without special action at the last line (removing the comma there).
All code from previous versions of Python would still work
after a `[,1,2]` syntax allowance were introduced.
=
rpuntaie wrote:
=
Allow initial comma
===
Final comma works:
t = (
1,
2,
)
x = [
1,
2,
]
y = {
1,
2,
}
z = {
1:11,
2:22,
}
def fun(
a,
b,
):
pass
Initial comma does not work:
t = (
, 1
, 2
)
x = [
, 1
, 2
]
y = {
, 1
, 2
}
z = {
, 1:11
, 2:22
}
def fun(
, a
, b
):
pass
To make the syntax symmetric in this regard\
gives more freedom to format the code.
I occasionally found the restriction an unnecessary nuisance.
Before writing a PEP, I would like to discuss,
- whether something like that has been proposed already?
- what counter-arguments there could be?
=
pxeger wrote:
=
This is not the appropriate place to propose language changes.
Try the
[python-ideas](https://mail.python.org/mailman3/lists/python-ideas.python.org/)
mailing list. However, I don't think you'll get anyone to agree.
What kind of code style are you using where you want to put commas at
the start of the line? That is totally non-standard
(see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and confusing.
Arbitrary symmetry is not a good reason for changing the language. We
don't have a `tnirp` function just for the sake of symmetry with
`print` because it would be pointless and add extra complication
=
rpuntaie wrote:
=
I surely agree, that not ignoring the sequence is essential. Else one
would loose identifier space and thus information. I would never have
the idea to make all permutations of `p.r.i.n.t` point to the same
function. Therefore you just made a bad example.
But the comma is just a separator. Why did they allow to have the
comma before a closing bracket/parenthesis/brace? Because of symmetry
between lines, is my guess.
Occasionally one sees many spaces just the have the final comma
aligned vertically. That could be avoided by placing the comma at the
beginning.
I personally also have a macro in the editor that evaluates a line in
the parameter list, but drops an initial comma before doing that.
Therefore this is my preferred formatting.
I don't think that [PEP](https://www.python.org/dev/peps/pep-0008)
is wrong. I just don't want to be restricted by unnecessary rules.
Rules need to have a reason beyond someone dictating them. If that is
the case, I follow them, because I see the reason, but not because
someone dictates them.
I'll go to
[Python Ide
as](https://mail.python.org/mailman3/lists/python-ideas.python.org/),
then. Thanks.
_______
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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python Idea - extension of 'with'
We are all familiar with the `with` statement for context managers, so
that the resources are correctly finalized/closed in case of an
exception either in terms
of the resources being allocated of the processing.
It is very common though to wrap the `with block` in an outer `try`
block, since although we know that the resource has been closed, at an
'application' level it is still neccessary
to deal with the exception - an example might be :
try:
with open('config.cfg', 'r') as cfg:
# Process the open file
config = load_config(cfg)
except FileNotFound:
logging.info('Config file not found - using default configuration')
except PermissionError:
logging.warning('Cannot open config .cfg - using default configuration')
config = default_config()
else:
logging.info('Using config from config.cfg')
It struck me that this is probably quite a common idiom, and we have the
main processing (of the opened resources) indented twice just to accommodate
the outer try block.
I was wondering whether a worthwhile extension might be to allow the
`with` statement to have an `except` and `else` clauses which would have
the same
semantics as wrapping the `with` block with a try - for example the
above would now look like:
with open('config.cfg', 'r') as cfg:
# Process the open file
config = load_config(cfg)
except FileNotFound:
logging.info('Config file not found - using default configuration')
except PermissionError:
logging.warning('Cannot open config .cfg - using default
configuration')
config = default_config()
else:
logging.info('Using config from config.cfg')
Treating the 'with' as an implied `try` would reduce the march to the
right - now the key processing of the resource is now indented only one
level - and the association of the exception
from the `with` block is syntactically clear.
I am not good enough with core development to put together a working
prototype, but I can imagine that this simple extension would be worth
while, but I would be more than happy to author a PEP for this if it
gets some initial positive feedback.
Open questions - that I have - should we allow `except`, `else` and
`finally` clauses (or just `except` and `else` - do we need `finally` here).
--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.com <mailto:anthony.fl...@btinternet.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/ITNCZD2GOQS7TQF7XYFWFYABDP5ZNS5G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python Idea - extension of 'with'
On 09/04/2021 19:02, Guido van Rossum wrote: But if there are two proposals with conflicting semantics for the same syntax that kills both ideas, doesn’t it? Because apparently it’s not clear what the syntax should mean. Surely it depends (if we adopt a proposal) how we document it. You could argue that very few syntax elements are entirely clear unless we explain it - which is what the point of the documentation. For example for someone who doesn't know what 'with' does, it isn't necessarily clear (just from the syntax) that 'with' ensures finalizing of resources when an exception occurs - the documentation has to explain that. IF we reject a syntax because it isn't self-explanatory that sounds like a bad precedence. -- Anthony Flury *Moble*: +44 07743 282707 *Home*: +44 (0)1206 391294 *email*: anthony.fl...@btinternet.com <mailto:anthony.fl...@btinternet.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/6Q6BEU6URZUSWJPZWJ4EKTICY2Q7ZQBZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] List comprehension operators
It would be awesome to be able to create a list with just: li = [1—100] or li = [1 .. 100] ___ 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/CQOPU4ZMADKD5WOV5G3ZB4OAWDP4YKF6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Applications user/system directories functions
Hello,
The idea is to add 3 functions to get "config", "data" and "cache" directories
that are commonly used to store application files in user home / system.
This look very straightforward to get theses directories path, but in practices
it depends on many factors like OS, environnement variables, user or system dir.
For instance, with the "config" directory:
* Linux, user: os.path.join(os.getenv("XDG_CONFIG_HOME",
os.path.expanduser("~/.config")), app_name)
* Linux, system: os.path.join("/etc", app_name)
* Windows, user: os.path.join(os.path.expandvars("%APPDATA%"), app_name)
* Windows, system: os.path.join(os.path.expandvars("%CSIDL_COMMON_APPDATA%"),
app_name)
For linux, the full spec is here:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
I see many applications that just use "~/.app_name" to not have to handle
theses cases.
The functions prototypes may look like and may be added to "shutil" (or
"os.path" ?):
def getcachedir(app_name: str=None, system: bool=False):
With
* app_name: The application name
* system: If the required directory is the systemd directory or user direcotry.
This may also be implemented as an external library, but I am not sure I would
like add add a dependency to my projects "just for this".
I can implement this if people are interested with this feature.
_______
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/MHEWO4U6SBDU7OU3JH4A62EWCANDM7I2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Applications user/system directories functions
Hello, Thanks for the suggested packages. "platfromdirs" look to be a fork of "appdirs", both seems to support many OS and cases. That look to be good non stdlib solutions. The "xdg" module seem to only support Linux, but provides more dirs 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/NVUD2ZVINI5Z3QHYUGOGGQHY67NSYHGV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
This feature is far more useful in JS because JS objects double up as mappings - Python dataclasses/attrs models/Pydantic models/named tuples/who knows what are all represented by (typed) objects in JS/TS. As soon as you want to describe your data e.g. by encoding it in a dataclass you'll no longer be able to dictionary-unpack it which will prove very frustrating. ___ 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/BOTEVLGLW325Y26ZP2BLSZGUQIVZXLZV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
I don't think we're saying anything different, I agree. The point I was making was that _after_ loading the data onto a dataclass (or equivalent), you wouldn't be able to unpack it. In JS, you can use destructuring assignment when working with "classes" (and therefore well-defined APIs), which is why it has wider applicability in JS. _______ 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/JBPJJBKUWPPYN2AM3RRC7S4B46XGPX3K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
> Please can you quote some text to show who and what you're responding to? I *think* you're responding to my post, but it's hard to be sure. Sorry, I'm using the web UI which nests replies - I forgot this is a mailing list! I was responding to your message. ___ 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/PN4TEWO6OE7NLJK7MJK6NAR2SDHDY2IU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Missing expandvars equivalent in pathlib
All,
I know that /os.path/ includes a function /expandvars(..)/ which expands
any environment variables in a given path, but from looking at the
/pathlib/ documentation It seems there is
no equivalent to /os.path.expandvars(..) on any class/ in /pathlib/, and
the recommendation seems to be to use /pathlib/ to do any and all path
manipulations, with the exception of expanding environment variables.
It appears that the recommended /pathlib/ compatible code to fully
convert any file path (which may have environment variables and or ~ or
~user constructs) to a fully resolved absolute path is :
import os.path
import pathlib
given_path = input('Provide the full path')
abs_path =
pathlib.Path(os.path.expandvars(pathlib.Path(givenpath).expanduser())).resolve()
It seems to me that /pathlib.Path/ would benefit massively from an
/os.path.expandvars(..)/ equivalent - so that the equivalent code could be :
import os.path
import pathlib
given_path = input('Provide the full path')
abs_path = pathlib.Path(givenpath).expandvars().expanduser().resolve()
I know the need to do this is likely to be a corner case, but even still
it continues dependency on /os.path/ for those programs that need to
resolve environment variables in paths, and increases the cognitive load
for this operation, , and it seems like a missed feature in /pathlib/
A change such as this shouldn't affect backwards compatibility.
What do people think - have I missed something or is pathlib missing
something ?
/Pathlib documentation
/
/https://docs.python.org/3/library/pathlib.html#module-pathlib/
--
Anthony Flury
*Moble*: +44 07743 282707
*Home*: +44 (0)1206 391294
*email*: anthony.fl...@btinternet.comBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:anthony.fl...@btinternet.com
FN:Anthony Flury
NICKNAME:Tony
N:Flury;Anthony;;;
TEL;TYPE=home;VALUE=TEXT:01206 391294
TEL;TYPE=cell;VALUE=TEXT:07743282707
UID:c00fc9c3-a56a-4584-8886-6466cf32b9c8
END:VCARD
_______
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/IJSOTVIDYLWRYEXFZCOFWSCIYHORQS6Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Comparison operator support (>= and <=) for type
Let's assume you have this model: ``` class Base: pass class A(Base): pass class B(Base): pass class C(A): pass ``` While we can do `A == B`, or `B == C` or `B == B`, I would expect to be able to compare like this as well: `A >= B (if B is subclass or itself of A)`, or `B <= C (if B is a subclass or itself of C)` Because, since == means equality check. With the same logic, a class wraps another class is actually greater than this class from its type. ___ 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/6W7HCI4UIEAUD6AVLFSJF5Q2X55LWYZA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add a `dig` method to dictionaries supporting the retrieval of nested keys
I did some searching to see if this has already been proposed before, but didn't find any evidence that it has. If so, let me know and I'll go away :) One of the tasks that I encounter frequently enough is retrieving a nested key from a nested collection of dictionaries (a dictionary of dictionaries that can be any number of layers deep). There are multiple ways of tackling this, normally done with `reduce()`, iterative looping or chained `get()`s and then handling `None`, `KeyError` or `AttributeError` appropriately. I'd like to avoid this extra code and logic and have a built-in method to facilitate this common data access pattern. I'd like to propose that we add a `dig()` method to dictionaries analogous to Ruby's `dig()` method for Ruby Hashes (reference: https://ruby-doc.org/core-2.6.0.preview2/Hash.html#method-i-dig). Initially, I'd suggest that we only support nested dictionaries, but we could also support lists and other collection types as Ruby does if we really want to. Similar to the existing `get()` method on dictionaries, I'd propose that the method return `None` if any of the keys in the chain is not found, avoiding `KeyError`. Thoughts? _______ 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/QFL76SGB562Q6C5N6ZWGNUXDIU5N7MKK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a `dig` method to dictionaries supporting the retrieval of nested keys
Thanks everyone for the feedback and suggestions. I agree that there are many ways one could easily implement this (chaining, reduce, looping, etc.). I could continue to maintain a utility function and copy that around to all of code bases where I need this functionality, which is what I do today. I think we could do better, though. It is cumbersome to update and copy around a common function across organizations and code bases. Then I have to educate the rest of the dev team and tell them that there is a function that facilitates nested key retrievals. Another alternative would be to create a common package for this and update all of my projects to use that. Given that it would be 5-15 lines of code, that feels like it would be too small to be a robust dependency and would smell like some of the minuscule dependencies in the Javascript ecosystem (example: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/). I really believe that a nested key retrieval mechanism should be a first-class offering of the standard library. It is extremely common in the Python ecosystem to find developers working with data sets comprised of nested data structures. Serializing and deserializing JSON is one of the most common functions developers do today, too. As this is a common task being performed by hundreds of thousands of developers, wouldn't it better if we had one canonical way to do it (in the spirit of PEP-20 and having one obvious way to do things)? ___ 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/2I7DBVFV7AJEN6XWKC3R7VXWSTJUXGO4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python should take a lesson from APL: Walrus operator not needed
During a recent HN discussion about the walrus operator I came to realize yet
another advantage of notation. I used APL professionally for about ten years,
which made it an obvious source of inspiration for an example that, in my
opinion, demonstrates why the Python team missed a very valuable opportunity to
take this wonderful language and start exploring the judicious introduction of
notation as a valuable tool for thought (borrowing from Ken Iverson's APL paper
with that title [0]).
To simplify, I'll define the desire for this walrus operator ":=" as "wanting
to be able to make assignments within syntax where it was previously
impossible":
if x = 5# was impossible
# and now
if x := 5 # makes is possible
A more elaborate example given in the PEP goes like this:
Current:
reductor = dispatch_table.get(cls)
if reductor:
rv = reductor(x)
else:
reductor = getattr(x, "__reduce_ex__", None)
if reductor:
rv = reductor(4)
else:
reductor = getattr(x, "__reduce__", None)
if reductor:
rv = reductor()
else:
raise Error(
"un(deep)copyable object of type %s" % cls)
Improved:
if reductor := dispatch_table.get(cls):
rv = reductor(x)
elif reductor := getattr(x, "__reduce_ex__", None):
rv = reductor(4)
elif reductor := getattr(x, "__reduce__", None):
rv = reductor()
else:
raise Error("un(deep)copyable object of type %s" % cls)
At first I thought, well, just extend "=" and be done with it. The HN thread
resulted in many comments against this idea. The one that made me think was
this one [1]:
"These two are syntactically equal and in Python there's no
way a linter can distinguish between these two:
if reductor = dispatch_table.get(cls):
if reductor == dispatch_table.get(cls):
A human being can only distinguish them through careful inspection.
The walrus operator not only prevents that problem, but makes
the intent unambiguous."
Which is a perfectly valid point. I get it.
Still, the idea of two assignment operators just didn't sit well with me.
That's when I realized I had seen this kind of a problem nearly thirty years
ago, with the introduction of "J". I won't get into the details unless someone
is interested, I'll just say that J turned APL into ASCII soup. It was and is
ugly and it completely misses the point of the very reason APL has specialized
notation; the very thing Iverson highlighted in his paper [0].
Back to Python.
This entire mess could have been avoided by making one simple change that would
have possibly nudged the language towards a very interesting era, one where a
specialized programming notation could be evolved over time for the benefit of
all. That simple change would have been the introduction and adoption of APL's
own assignment operator: "←"
In other words, these two things would have been equivalent in Python:
a ← 23
a = 23
What's neat about this is that both human and automated tools (linters, etc.)
would have no problem understanding the difference between these:
if reductor ← dispatch_table.get(cls):
if reductor == dispatch_table.get(cls):
And the larger example would become this:
if reductor ← dispatch_table.get(cls):
rv ← reductor(x)
elif reductor ← getattr(x, "__reduce_ex__", None):
rv ← reductor(4)
elif reductor ← getattr(x, "__reduce__", None):
rv ← reductor()
else:
raise Error("un(deep)copyable object of type %s" % cls)
This assignment operator would work everywhere and, for a period of time, the
"=" operator would be retained. The good news is that old code could be updated
with a simple search-and-replace. In fact, code editors could even display "="
as "←" as an option. The transition to only allowing "←" (and perhaps other
symbols) could be planned for Python 4.
Clean, simple and forward-looking. That, to me, is a good solution. Today we
have "=" and ":=" which, from my opinionated perspective, does not represent
progress at all.
[0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf
[1] https://news.ycombinator.com/item?id=21426338
_______
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/JSA2RUE5SG2XGAUM4GRBRXPZ7Z4O2UYN/
Code of Conduct: http://python.org/psf/codeofconduct/
python-ideas@python.org
Imo `&` is not a suitable replacement for `+`.
Semantically when I read "Tony & Maria" it looks closer to behaving like a
Set.union ala`{"Tony"}.union({"Maria"})`
where comparatively the addition (+) infix operator is there to facilitate
concatenation, which is a very common operation and does not behave like
Set.union.
> Examples:
> x = ("I love")
> y = ("this idea ")
> z = ("posted on November ")
> a = 18
> print (x & y & z & a) # prints I love this idea posted on November 18
Quoting the zen of Python here:
> Explicit is better than implicit.
I dont think Python should start allowing implicit type casting on select
operators for builtins at the risk of subtle gotchas for the newer programmers.
> print (x + y + z + str(a))
> and thats not much difference to worry about. Problem comes when there are
> more different
> data types need to be added and combined together.
> This would make things allot easier for many people and make string handling
> easier
> also.
The popular solution for this is explicitly formatting a string:
`f"{x}{y}{z}{a}"`
or for the more functional programmers out there folding a map
`"".join(map(str, (x, y, z, a))`
___
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/5WV6DC2W6LIU7YIXPITVYG6MLEZCP6PX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Asyncio Future.set_result_threadsafe
I agree that is counter to the basic philosophy, though there are potential use cases where it may be unavoidable to use threads. It seems the best solutions when it is then are to use run_in_executor, which automatically handles the waking up of the loop. While the Queue object doesn't work with threads, though there does seem to be a library janus which provides a thread-capbable queue object which could be another solution. -Original Message- From: Guido van Rossum To: Brian Allen Vanderburg II Cc: Python-Ideas Sent: Thu, Feb 13, 2020 1:18 am Subject: Re: [Python-ideas] Asyncio Future.set_result_threadsafe Sharing futures between threads like that goes counter to asyncio's basic philosophy (which is not to use threads :-). You already showed the solution: future._loop.call_soon_threadsafe(future.set_result, ...). If that's unacceptable for you, maybe you can wrap the future in a wrapper class that calls call_soon_threadsafe. On Wed, Feb 12, 2020 at 8:51 PM Brian Allen Vanderburg II via Python-ideas wrote: Currently asyncio.futures.Future.set_result will result in any callbacks being scheduled using loop.call_soon instead of loop.call_soon_threadsafe. However in situations where the future's result is set from a different thread, the loop might not wake up as a result of this if it is currently sleeping. def compute_something(...): loop = asyncio.get_event_loop() future = loop.create_future() manager.run_computation(future, ...) # add the computation to a thread that is running it return future async def compute_stuff(): result = await compute_something(...) loop = asyncio.get_event_loop() loop.run_until_complete(compute stuff()) loop.close() The reasoning behind it is after yielding the Future object, the ready list of the event loop is empty so when waiting for selectors the timeout value is None and it just waits. When the other thread calls set_result, the loop ready list will get updated, but it's still waiting on selectors. The other thread could call future._loop.call_soon_threadsafe(future.set_result, ...), which writes some bytes to a socket in order to wake the even loop. I'm aware there are other ways to do things like this (queues, executors, etc). It just seems that, regardless of any method used, the code holding the future with the purpose of setting a result on it should be able to be blind to other implementation details. future.set_result should be all it needs to know to call even if from another thread, or if not, a method like future.set_result_threadsafe, which would hide the details of the loop.call_soon/call_soon_threadsafe _______ 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/PLKYKFWM4EM7DHUHWOBDU2JSJM57X7GM/ Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido)Pronouns: he/him (why is my pronoun here?)_______ 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/CWV6UQUN4LFZHQK53L463OY4D4EROFXS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Control adding script path/CWD to sys.path
This is just an idea, which may not in practice be a major problem but can at times be an inconvenience. I thought I had posted this in the "python -m" thread a little while back but checking my history it does't appear I did, I do apologize if this is a duplicate. When running a python script directly, the directory of that script gets added to sys.path. When running as a module "python -m", it looks like an empty string gets added to sys.path, which appears to result in CWD being used. But, depending on the directory structure, modules imported may not be the expected modules. For instance, if developing a package 'mypackage', with some OS specific code organized into an os module or subpackage "mypackage.os", and then running something like "python -m pytest" or "pylint ..." in the directory for the package would cause an "import os" to treat the mypackage/os(.py) module or package as the top level import and cause errors. (I've actually had this happen which is what prompts this idea) There are other solutions that work right now: Don't develop a subpackage or submodule with the same name as a python package or module, or any other package or module that may be on sys.path. I think this is unrealistic as a future addition could result in a package being added that wasn't previously present and there is no way to know the names of all third-party packages Just change the directory and run the script/module from another directory that would not cause an issue. This works great, but seems to go against not presuming where the script is run from or what the CWD is. Install a script in ~/bin or somewhere to do the same at least for modules. This would set the CWD to ~/bin, and not likely to have any conflicting packages or modules, but still presumes that it must not have a conflicting module. What if my ~/bin happens to have other ".py" files marked as executable that is used for something else. It then becomes a top-level module able to be imported, and possibly interfere with other imports. I'd like to propose a python option which would disable the addition of this directory directory. Essentially something to make it possible to say "import the installed module xyz and not perhaps some script or package sitting right beside me also named xyz". Something like "python3 --no-add-cwd-to-path -m pytest". This would allow in cases where needed, to prevent added the script path or CWD to the sys.path list. This could already be done directly in code: import sys ; sys.path.pop(0) But having an option seem to be more flexible as it give the user of the script the ability to say "don't add this current directory to the python path" for existing scripts and modules without having to edit them, create a custom launcher script, or change directories, etc.___ 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/372DEVQ2MBUY76KV5ZK6HK3UONBYROTU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Control adding script path/CWD to sys.path
I'll have to check that out. It looks like it would work fine for my purposes since I normally run from virtual envs, but could be restrictive in that the user site-packages isn't added. I also found some other mentions of this: https://bugs.python.org/issue33053https://bugs.python.org/issue13475 One idea may be, when executing "python -m", check to see if the module is loaded from CWD, if so then have CWD added, but if the module is not loaded from CWD then not have it added. -Original Message- From: Nick Timkovich To: Brianvanderburg2 Cc: python-ideas@python.org Sent: Mon, Feb 24, 2020 2:52 pm Subject: Re: [Python-ideas] Control adding script path/CWD to sys.path On Mon, Feb 24, 2020 at 11:51 AM Brianvanderburg2 via Python-ideas wrote: When running a python script directly, the directory of that script gets added to sys.path. When running as a module "python -m", it looks like an empty string gets added to sys.path, which appears to result in CWD being used. Are you familiar with the -I option for "isolated mode"? https://docs.python.org/3/using/cmdline.html#id2 -I Run Python in isolated mode. This also implies -E and -s. In isolated mode sys.path contains neither the script’s directory nor the user’s site-packages directory. All PYTHON* environment variables are ignored, too. Further restrictions may be imposed to prevent the user from injecting malicious code. New in version 3.4. _______ 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/SB577SR3BEJTKWEXTREYTGGAD5CNE2S5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] is a
In cases where it makes sense to do explicit type checking (with ABCs or whatever), I really detest the look of the isinstance() function. if isinstance(thing, Fruit) and not isinstance(thing, Apple): Yucky. What I really want to write is: if thing is a Fruit and thing is not an Apple: and after thinking about it on and off for a while I wonder if it might indeed be possible to teach the parser to handle that in a way that eliminates almost all possible ambiguity with the regular "is", including perhaps 100% of all existing standard library code and almost all user code? Maybe this has been considered at some point in the past? The "is [not] a|an" proposal would at least be a strong contender for "hardest thing to search for on the internet" lol. Thanks! Gavin _______ 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/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Enhancement: Adding support for private and name mangled type hints in dataclasses module
I have a proposal for an addition to the dataclasses module that I think would make it easier to use private and name mangled variables. One of the benefits of the dataclass decorator is that it helps lessen the amount of code when you just need a simple constructor. A common pattern in python that isn't addressed by the current implementation is the pattern ```python class MyClass: def __init__(self, a: str, b: str): self._a = a self.__b = b ``` right now the only straightforward way of doing this with a dataclass is ```python @dataclass class MyClass: a: InitVar[str] b: InitVar[str] def __post_init__(self, a, b): self._a = a self.__b = b ``` My proposal would be to add two types to the dataclasses module, one called PrivateVar and one called MangledVar. These would add The above pattern (without the post_init ) using the syntax, ```python @dataclass class MyClass: a: PrivateVar[str] b: MangledVar[str] ``` I've already looked into what would need to be added to dataclasses to implement these and it's just a few lines of code since the class implementation would be very similar to InitVar. Is this something that other see the possibility of being added to python? (Also, I know name mangling isn't super common but I think it may as well be added alongside a private variable implementation)) ___ 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/4JN76TMBGA3YDN5445OR2S7OT32JH2XO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancement: Adding support for private and name mangled type hints in dataclasses module
While I agree that this is a subset of the idea of having a different attribute name, I think this naming convention is very common, and is even referenced in the python documentation. Which is why I think it would warrant being built in as opposed to using an InitVar. So the way attrs deals with private variables is actually even less ideal, because it pretends that the convention doesn't even exists since in python the variables aren't ever truly private, you can see that [here](https://www.attrs.org/en/stable/init.html#private-attributes). As for repr, I think it may actually be beneficial for these to be excluded, because if we're truly emulating private variables, a user shouldn't really know what they are without going into the code, although of course since it's python they could be fairly easily accessed through inspection and the dict attribute. Zach _______ 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/ZF4SM4KWIKBG65ZDQ4SBSXHS3HRIS4TS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Suggestion: annotated exceptions
I think on this point at lot of people will have to agree to disagree. The
clear advantage for me is that the `ZeroDivisionError` that is naturally part
of `div` is made explicit and handled in a type safe way (given than one is
using a type checker like mypy). Especially in this example I can't for the
life of me think of a situation where I would not have a `try`/`except`
directly surrounding the regular `div` with exceptions and instead let the
exception bubble up the stack and have something like
```
try:
do_lots_of_arithmetic() # code that calls div and any other similar function
except EveryArithmeticErrorYouCanThinkOf: # very bad design imho.
print('ooops something went wrong')
```
>From a cultural perspective (with python traditionally not being written in
>this style) I think writing code like this at the level of internal library
>code (that the user of the library will not see when using the library) is
>perfectly fine.
___
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/NXUC2NFJR2XTVEJ4FKDKTLHDQLT4HXF5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Suggestion: annotated exceptions
> Alas, this still doesn't work because type annotations are advisory and
> not mandatory. Regardless of the type hints given, I can still call
> div(1, "surprise") and get a TypeError.
I'd assume that everyone is a consenting adult and if someone really wanted to
shoot themselves in the foot there is no way to really prevent that (although
mypy does a good job at that). The runtime `TypeError` at the call site of the
offending code is actually what I'd prefer over code that mostly works (e.g.
`div(1, 2)`) but crashes in the rare event that someone passes `b=0` to `div.`
> Worse, because types in Python use subtyping, I can pass an int that
> does something you don't expect:
> class MyWeirdInt(int):
> def __truediv__(self, other):
> if other == 0:
> import loging
> logging.logg("tried to divide by " + other)
> raise ValueError('divided by zero')
Again there is no general way to prevent people from writing buggy code, the
most can do is try and guide people towards using a library correctly (by good
naming conventions, suitable levels of abstractions and yes also by making use
of type hints)
> So your "total function" is still not
> total: as soon as we move beyond the builtins written in C, literally
> anything can happen and any promise you make in div can be only
> advisory, not guaranteed.
> To get your "total function" you have to catch anything, but that cure
> is worse than the disease. That means that obvious bugs get suppressed
> and turned into Nothing() when they should in fact raise.
I fully agree with you that catching any possible exception just to make the
compiler happy is the worst of all possible ways to handle errors. This is
however not what I suggest; the point is not to make a function *total* in
terms of anything that can happen in the interpreter/compile/runtime/hardware -
that is what exceptions are for - but in terms of the functions api e.g.
dividing by zero being a natural part of division that has to be handled
somehow.
___
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/J6TDJXDHSUNOJSL6SXMWRQWK34HK4YZS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Suggestion: annotated exceptions
> From a cultural perspective (with python traditionally not being written in > this style) > I think writing code like this at the level of internal library code (that > the user of the > library will not see when using the library) is perfectly fine. >From a cultural perspective (with python traditionally not being written in a >functional style) I think writing code using functional-style error handling at the level of internal library code (that the user of the library will not see when using the library) is perfectly fine. _______ 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/L5WR6CEP4T4IRMT43CWFZEIUZDRJ3MNY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] propose index heap
Index heap is essential in efficient implementation of Dijkstra's algorithm, Prim's algorithm and other variants, I have implemented a concise version at https://github.com/yutao-li/libheap , I think it would be useful to have it in stdlib _______ 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/UBV7D3ZTVDDLCIMYJOEAN75X7SDOUDZP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A python_include() for cgi programming
I know what your getting at, this will work if you want to have variables in
the included file in scope in the caller of 'include', just insert it as normal
python.
Though I prefer this version as it is simpler and less error prone.
with open('myfile.py') as f: exec(f.read())
Basically, it includes the file and keep the scope of all variables that came
before this type of include statement. Very useful for this like a shared
authentication file across an entire website of multiple files/pages.
Happy Thanksgiving!
___
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/TC2T35Y53ZZN53EU56W6FRU777DPRANK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Simon's ideas [Was: How to respond to trolling (Guido van Rossum)]
Hello Simon, I'm mostly lurking this mailing list and this is my first post, so hello everybody 🙌. On Thu, Jan 12, 2017 at 12:13:03PM +0800, Simon Lovell wrote: > I feel I have to respond to this one. This discussion hasn't much to do on this mailing list and it's only generating noise. Please, would be kind enough to keep discussing this on python-list (aka comp.lang.python) where it belongs? And eventually, once discussion settles on realistic changes that /can/ be added to python you might want to submit a PEP: http://legacy.python.org/dev/peps/pep-0001/ To quote the above linked document, I believe this applies to your situation: > Asking the Python community first if an idea is original helps prevent > too much time being spent on something that is guaranteed to be > rejected based on prior discussions (searching the internet does not > always do the trick). It also helps to make sure the idea is > applicable to the entire community and not just the author. And read 5 times the following part before posting here again: > Just because an idea sounds good to the author does not mean it will > work for most people in most areas where Python is used. Even though I can only believe this is not your intent, in the end it looks pretty clear that many people, including myself, are being annoyed by these threads making the signal/noise ratio of this list very low. As I've read the original mail I knew it would end up in a low signal/noise ratio discussion because even I wanted to lecture you, Simon, about languages, grammar and compilers. Instead I killed the original thread (plonk!), as I find little interest in this discussion, but it keeps on respawning as some posters are breaking the threads. So please, be kind and have some netiquette. 🙏 Thank you, -- Bernard `Guyzmo` Pratz _______ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A more readable way to nest functions
ture with an operator, so we should then just discuss on how to add currying as a language syntax "by the book", but I'm pretty sure that's a topic already discussed before I joined this list ;-) that was my €0.02 Cheers, -- zmo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A more readable way to nest functions
tl;dr: I agree with you, Steven, as proven by my former post, augmented with the details of your reply: there's no advantage to add a new operator and language construct for this use case.— On Sun, Jan 29, 2017 at 01:30:13PM +1100, Steven D'Aprano wrote: > On Sat, Jan 28, 2017 at 03:16:27PM +0100, zmo via Python-ideas wrote: > > This idea sounds fun, so as a thought experiment why not imagine one > > way of integrating it in what I believe would be pythonic enough. > This idea is sometimes called "the Collection Pipeline" design pattern, > and is used in various command shells. Martin Fowler wrote about this > design pattern here: > https://martinfowler.com/articles/collection-pipeline/ > and I wrote a recipe for it: > https://code.activestate.com/recipes/580625-collection-pipeline-in-python/ > with a working, although basic, implementation. > print(list(map(float, filter(lambda n: 20 < n < 30, data > […] > data | Filter(lambda n: 20 < n < 30) | Map(float) | List | Print It's indeed an interesting tip and idea, and using the pipe is not a bad idea as it's a good mnemonic for anyone who used a shell. About reading order, I'm personally agnostic. > (In principle, Python built-ins could support this sort of syntax so I > could write filter, map, list, print rather than custom versions Filter, > Map, etc. […] But for Python that would be a *major* change, and not one I > wish to propose. […]) Even as an external library, I would use that kind of syntax with extreme care in python. As a python developer, one of the things I really do enjoy is that any python code looks like a python code, and that's because changing meaning of operators depending on the context is discouraged. Then, unlike Scala, C++ or Ruby, you never end up with the language looking like a new DSL for each application or framework. > > On Sat, Jan 28, 2017 at 12:41:24PM +, Ed Kellett wrote: > > So, considering it's decided that the RHS is in charge of filling up all > > the arguments of the LHS, > Is that actually decided? it's not, it's part of the thought experiment of 'if we had such syntax', how could we handle arguments? > […] so either we have a new, parallel series of functions including > Filter(...) or we write something like: > print XYZ list XYZ map XYZ lambda (f1, f2, arg): (f1, filter(f2, > arg))(float, lambda n: 20 < n < 30, data) > which is simply horrid. Maybe there could be a series of helper > functions, but I don't think this idea is workable. […] > > […] > > All in all, it can be a nice syntactic sugar to have which could make it > > more flexible working with higher order functions, but it with the way > > I'm suggesting to comply with python's arguments handling, it offers > > little advantages when the RHS is not filling LHS arguments: > > […] > I think that "literal advantage" is being very kind. The best you can > say is that you save two pairs of parentheses at the cost of three > operators and moving arguments away from the functions that use them. I said "little" not "literal" ☺ I started the whole reasoning trying to be objective and figure how such a new syntax would be integrated in python and what good use could be made of it. And in the end, I end up with something that can offer a nice syntax for a very niche case, and wouldn't be of much use most of the time. The fact that it can be implemented with some operator overload, as you nicely demonstrated just proves the fact further: this is not a good idea. > [...] > > But then it would be just another way to introduce currying as a > > language feature with an operator, so we should then just discuss on how > > to add currying as a language syntax "by the book", but I'm pretty sure > > that's a topic already discussed before I joined this list ;-) > The easiest way to support currying, or at least some form of it, is: > from functools import partial as p > p(map, float) # curries map with a single argument float > which is not quite the map(float) syntax Haskell programmers expect, > but its not awful. Indeed, I love having that available as a function! We could reopen the debate as to whether we should implement currying into python, but since my last post I've done a bit of searching, and found out it's been discussed 14 years ago: https://mail.python.org/pipermail/python-dev/2004-February/042668.html https://www.python.org/dev/peps/pep-0309/ and a few discussions, implementations of (real) currying published more recently: https://mtomassoli.wordpress.com/2012/03/18/currying-in-python/ http://code.activestate.com/rec
Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator
Hi list, I'm quite neutral to this proposition, as it's not a use case I see often myself needing. On Fri, Feb 10, 2017 at 02:55:31PM +0100, Stephan Houben wrote: […] > But if I don't understand the dot in `class foo.bar:', then what? > It's probably somewhere buried in the language spec for `class' but > realistically > I am now going to blight Stackoverflow with my questions. […] but this is definitely not a reason to dismiss a proposal. A language is aimed at evolves and introduce new syntax features, and yes, stackoverflow will get questions about it, blog articles written and RTFW updated, so you'll get the info you'll need fastly. Cheers, -- Guyzmo _______ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Optional argument to fnmatch functions treat * and ** differently
Hello, I would like fnmatch.fnmatch to have a mode where: ** matches any files and zero or more directories and subdirectories (i.e. the current behaviour of *) * matches in one path level/only to the next path separator This is essentially achievable in glob.glob from version 3.5 (with recursive=True), but glob is not suitable for my use case, as I need to work with strings and not files. I would like to gauge whether adding such behaviour behind an optional argument similar to glob's "recursive" (e.g. "glob_asterisks=False") is likely to be accepted into the standard library, before I start working on a patch. I have seen people raise the question of how to achieve this in a number of places. Somebody has also forked the Python 2 standard library fnmatch module to implement this as a standalone library: https://github.com/kianxineki/python-wildcard (which shows that the actual changes are likely to be pretty small). This request is also discussed in the following bug: http://bugs.python.org/issue28718 Not directly on point, but some may find the discussion interesting: http://stackoverflow.com/questions/18341848/fnmatch-and-recursive-path-match-with http://stackoverflow.com/questions/27726545/python-glob-but-against-a-list-of-strings-rather-than-the-filesystem I would appreciate any thoughts. Kind regards, Aaron _______ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins
I would be very happy to see a frozendict in collections :)
Just for curiosity ; apart caching, is there any optimization
that can be done on a frozendict implementation (over dict) ?
I wonder if frozendict would be implemented as dict without modification
methods, or as a particular object that by design does not easily allow
modifications.
On 28/02/2017 21:05, Matt Gilson wrote:
> I've implemented `frozendict` a few times for various projects and never
> knew about MappingProxyType. I always used `collections.abc.Mapping` ...
>
>
> On Tue, Feb 28, 2017 at 9:12 AM, David Mertz wrote:
>
>> The difference in hits might be because MappingProxyType has a funny name
>> and is in a hidden-ish location. I.e. not necessarily because it *would
>> be* less used or useful if it were more exposed.
>>
>>
> It also might be because you can use `frozenset` in python2.x code -- And
> there's lots of that lying around...
>
>
>> In either case, the name that makes sense to me would be `frozendict`.
>> That could very well live in `collections` of course.
>>
>
> Yes, I agree. Though it'd also probably need to be hashable if we were to
> give it that name. I'm not 100% sure that `MappingProxyType` works there
> as it's just a view into another mapping. If the first mapping changes, so
> does the hash. This is the same problem we have hashing tuple in some
> sense -- But tuple can say "Nope, sorry. I can't hash this because it's
> got an unhashable member". I don't think we can really do the same thing
> with a MappingProxy since most of the time, it'll be constructed from
> something else. I suppose the workaround is pretty simple though:
>
> class frozendict(MappingProxyType):
> def __init__(self, proxy):
> super().__init__(proxy.copy()) # Copy the proxy! -- Maybe need
> `copy.copy()` instead?
> def __hash__(self):
> return hash(frozenset(self.items()))
>
> This could likely be done better, but hopefully it gets the idea across...
>
>
>>
>> On Tue, Feb 28, 2017 at 7:40 AM, Ivan Levkivskyi
>> wrote:
>>
>>> Searching MappingProxyType on GitHub gives over 10,000 results.
>>> I think it probably makes sense to make mappingproxy more "visible",
>>> maybe move it to collections module? (where OrderedDict lives)
>>>
>>> I am not sure if it makes sense to move it to builtins. (for comparison
>>> frozenset gives around 1000,000 results)
>>>
>>> --
>>> Ivan
>>>
>>>
>>>
>>> On 28 February 2017 at 16:24, Joseph Hackman
>>> wrote:
>>>
>>>> +1
>>>>
>>>> I think this makes a lot of sense. What would you name the built in?
>>>>
>>>> -Joseph
>>>>
>>>>> On Feb 28, 2017, at 7:17 AM, Michel Desmoulin <
>>>> desmoulinmic...@gmail.com> wrote:
>>>>>
>>>>> We have the immutable frozenset for sets and and tuples for lists.
>>>>>
>>>>> But we also have something to manipulate dict as immutable
>>>> datastructures:
>>>>>
>>>>>>>> from types import MappingProxyType as idict
>>>>>>>> d = idict({'a':1, 'b':2, 'c':3})
>>>>>>>> d['a'] = 4
>>>>> Traceback (most recent call last):
>>>>> File "", line 1, in
>>>>>d['a'] = 4
>>>>> TypeError: 'mappingproxy' object does not support item assignment
>>>>>
>>>>> We could expose this as a built type to allow the last of the most
>>>>> important data structure in Python to be easily immutable.
>>>>>
>>>>> ___
>>>>> Python-ideas mailing list
>>>>> Python-ideas@python.org
>>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Cond
Re: [Python-ideas] π = math.pi
On Thu, Jun 01, 2017 at 11:49:43AM +0200, Victor Stinner wrote: > How do you write π (pi) with a keyboard on Windows, Linux or macOS? Use the compose key 🙌 for linux: https://help.ubuntu.com/community/ComposeKey for windows: https://github.com/SamHocevar/wincompose for macosx: http://lol.zoy.org/blog/2012/06/17/compose-key-on-os-x Then I wrote my own ~/.XCompose file with: : "π" U03C0 # GREEK SMALL LETTER PI so it's like the vim digraphs. Cheers, -- zmo _______ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] + operator on generators
Hello ! I often use generators, and itertools.chain on them. What about providing something like the following: a = (n for n in range(2)) b = (n for n in range(2, 4)) tuple(a + b) # -> 0 1 2 3 This, from user point of view, is just as how the __add__ operator works on lists and tuples. Making generators works the same way could be a great way to avoid calls to itertools.chain everywhere, and to limits the differences between generators and other "linear" collections. I do not know exactly how to implement that (i'm not that good at C, nor CPython source itself), but by seeing the sources, i imagine that i could do something like the list_concat function at Objects/listobject.c:473, but in the Objects/genobject.c file, where instead of copying elements i'm creating and initializing a new chainobject as described at Modules/itertoolsmodule.c:1792. (In pure python, the implementation would be something like `def __add__(self, othr): return itertools.chain(self, othr)`) Best regards, --lucas signature.asc Description: OpenPGP digital signature ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add a replace method to tuples
Add a "replace" method to tuples that returns a new tuple with the element at a given index replaced with a given value. Example implementation: def replace(self, index, value): return self[:index] + (value,) + self[index + 1:] See https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple for more context. Currently, tuples have 2 public methods: index and count. replace would be similarly easy to implement and similarly useful. Furthermore, it would be a natural counterpart to nametuple's _replace method.___ 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/TIHIG74ADMMZRKRNGR2TDZSXIMM6N7JM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> This could cause confusion because str.replace() has a completely different > API. We're talking about tuples here, not strings. Saying that a method's API differs for a completely different type, especially when such a difference would be expected given the difference in types, is not a valid objection. > And indeed if a replace method were added to tuples, a fair case could be > made for it having the same API, viz. replace(old, new, count=-1) Not sure what you mean by this. Please clarify. > Whereas your suggestion can be written as a simple 1-liner, as you > demonstrate. So there is no strong need for a new method for it. The same can be said for index and count, along with numerous other methods attached to Python's built-in types. Something being simple to implement does not mean it shouldn't be built-in. See Python's "batteries included" philosophy. If users find themselves re-implementing the same utility function over again and over again across different projects, it's a good sign that such a function should be part of the standard library. --- Original Message --- On Thursday, March 10th, 2022 at 8:38 PM, Rob Cliffe via Python-ideas wrote: > This could cause confusion because str.replace() has a completely different > API. > And indeed if a replace method were added to tuples, a fair case could be > made for it having the same API, viz. > replace(old, new, count=-1) > Whereas your suggestion can be written as a simple 1-liner, as you > demonstrate. So there is no strong need for a new method for it. > Best wishes > Rob Cliffe > > On 10/03/2022 03:42, wfdc via Python-ideas wrote: > >> Add a "replace" method to tuples that returns a new tuple with the element >> at a given index replaced with a given value. Example implementation: >> >> def replace(self, index, value): >> return self[:index] + (value,) + self[index + 1:] >> >> See >> https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple >> for more context. >> >> Currently, tuples have 2 public methods: index and count. replace would be >> similarly easy to implement and similarly useful. >> >> Furthermore, it would be a natural counterpart to nametuple's _replace >> method. >> >> ___ >> 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/TIHIG74ADMMZRKRNGR2TDZSXIMM6N7JM/ >> 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/AUHKWFBYGEKZBEYBE56SH2YZJF5QCNOV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> On the other hand, it might be an indication that a tuple is the wrong tool > for the job. 1. It's not. The original tuple is not being mutated. And it may be desirable to enforce that immutability at the type level. Hence the choice of tuple rather than, say, list. 2. The same "objection" would apply to namedtuple._replace, since namedtuple is also immutable. > As noted, a namedtuple DOES allow you to replace one component, and to do so > by name rather than knowing its index, so possibly that would be a better > choice here. Tuples don't have names. They have indices. The tuple equivalent of a namedtuple fieldname is an index. And that's precisely what's being used here. --- Original Message --- On Thursday, March 10th, 2022 at 11:13 PM, Chris Angelico wrote: > On Fri, 11 Mar 2022 at 14:36, Jeremiah Vivian > > nohackingofkrow...@gmail.com wrote: > > > > See Python's "batteries included" philosophy. > > > > > > If users find themselves re-implementing the same utility function over > > > again and over again across different projects, it's a good sign that > > > such a function should be part of the standard library. > > > > > > Also something I agree with. What this method does is done a lot of times > > > and it could be made a little more readable by making it into an actual > > > method. > > On the other hand, it might be an indication that a tuple is the wrong > > tool for the job. As noted, a namedtuple DOES allow you to replace one > > component, and to do so by name rather than knowing its index, so > > possibly that would be a better choice here. > > 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/AHBORWEWN26RS7KWUFUJLRLRCE53RFIB/ > > 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/TCDUJWHTQ6C74E4EBEMVYWRJNW5D2RIM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> one Stack Overflow question, with a low number of votes Mind explaining why you say 159 is a "low number of votes" for a StackOverflow question on Python? According to https://stackoverflow.com/questions/tagged/python, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% of Python questions by vote count. > And yet you haven't demonstrated that this is the case for your proposal What kind of evidence would satisfy you? And how did previous proposals you supported obtain such evidence? We've already had 2 other participants here attesting to frequent use of this functionality. > it's not clear that the OP shouldn't have been using a list in the first place This has already been explained in this thread. A list is not immutable. A tuple is. Both the old and new tuples are not mutated or mutable, and we want to keep it that way. See namedtuple's ._replace method. namedtuples are also immutable. We simply want the same functionality for tuple. --- Original Message --- On Friday, March 11th, 2022 at 4:41 AM, Paul Moore wrote: > On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > If users find themselves re-implementing the same utility function over > > again and over again across different projects, it's a good sign that such > > a function should be part of the standard library. > > And yet you haven't demonstrated that this is the case for your > > proposal (one Stack Overflow question, with a low number of votes, > > where it's not clear that the OP shouldn't have been using a list in > > the first place, isn't particularly compelling evidence). > > 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/2A6GQZJ4G7JZMSIE6M4CU4BQMQJ62XUN/ > > 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/YM3GUONPOVES6A7EV7BCXVBH5I6T7EQD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> But *humans* can be confused by "replace" having a totally different API in > different contexts. I doubt that's the case here. The closest equivalent to tuple's .replace method would be namedtuple's _.replace method, which also has a different API from string's .replace method. > I could (I believe) write "count" as an (inefficient) 1-liner, but not > "index". I suggest it's harder than you think. (Try it!) How much harder? Can you post your candidate? In any case, my point still stands. > "Not every 1-line function needs to be a built-in". Not every 1-line function needs to *not* be a built-in. > Well, you are 1 user. Have you evidence that there are (many) others? See the StackOverflow link and the 2 other participants in this thread who attested to frequent use of this functionality. --- Original Message --- On Friday, March 11th, 2022 at 6:30 AM, Rob Cliffe wrote: > On 11/03/2022 02:19, wfdc wrote: > >>> This could cause confusion because str.replace() has a completely different >>> API. >> >> We're talking about tuples here, not strings. > > Yes, I know, and tuples and strings are different. But *humans* can be > confused by "replace" having a totally different API in different contexts. > This suggests at least finding a different name for your proposed method. > >> Saying that a method's API differs for a completely different type, >> especially when such a difference would be expected given the difference in >> types, is not a valid objection. >> >>> And indeed if a replace method were added to tuples, a fair case could be >>> made for it having the same API, viz. replace(old, new, count=-1) >> >> Not sure what you mean by this. Please clarify. > > A function that replaced tuple elements by value rather than by index would > no doubt be useful to somebody (not that I'm proposing it). So it could use > the same API as str.replace(). > >>> Whereas your suggestion can be written as a simple 1-liner, as you >>> demonstrate. So there is no strong need for a new method for it. >> >> The same can be said for index and count, along with numerous other methods >> attached to Python's built-in types. > > Hm, off the top of my head, I could (I believe) write "count" as an > (inefficient) 1-liner, but not "index". I suggest it's harder than you think. > (Try it!) > >> Something being simple to implement does not mean it shouldn't be built-in. >> >> See Python's "batteries included" philosophy. > > "Not every 1-line function needs to be a built-in". > >> If users find themselves re-implementing the same utility function over >> again and over again across different projects, it's a good sign that such a >> function should be part of the standard library. > > Well, you are 1 user. Have you evidence that there are (many) others? > Best wishes > Rob Cliffe > >> --- Original Message --- >> On Thursday, March 10th, 2022 at 8:38 PM, Rob Cliffe via Python-ideas >> [](mailto:python-ideas@python.org) wrote: >> >>> This could cause confusion because str.replace() has a completely different >>> API. >>> And indeed if a replace method were added to tuples, a fair case could be >>> made for it having the same API, viz. >>> replace(old, new, count=-1) >>> Whereas your suggestion can be written as a simple 1-liner, as you >>> demonstrate. So there is no strong need for a new method for it. >>> Best wishes >>> Rob Cliffe >>> >>> On 10/03/2022 03:42, wfdc via Python-ideas wrote: >>> >>>> Add a "replace" method to tuples that returns a new tuple with the element >>>> at a given index replaced with a given value. Example implementation: >>>> >>>> def replace(self, index, value): >>>> return self[:index] + (value,) + self[index + 1:] >>>> >>>> See >>>> https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple >>>> for more context. >>>> >>>> Currently, tuples have 2 public methods: index and count. replace would be >>>> similarly easy to implement and similarly useful. >>>> >>>> Furthermore, it would be a natural counterpart to nametuple's _replace >>>> method. >>>> >>>> ___ >>>> 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/TIHIG74ADMMZRKRNGR2TDZSXIMM6N7JM/ >>>> 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/THFTFWMD72FMAMZIUKGESAYUPYM42M6L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> Not every one line function needs to be a method on a built-in type. Not every one line function needs to *not* be a method on a built-in type. See tuple's count method for an example. Again, if users find themselves re-implementing the same utility function over and over again across different projects it's a good sign that such a function should be part of the standard library. Furthermore, other users have already pointed out that my one-liner is not the most *efficient* way to implement it. And it also doesn't include bounds checking. > I like that tuples have extremely limited methods. Why's that? > Following the iterable protocol seems fine (also indexable). What does this have to do with the discussion? > If I were forced to endorse one new method for tuples, I doubt `.replace()` > would be in my top five considerations. List the 5 other methods you'd prefer over this one, and explain why you think they're in higher demand and more useful. > But if you want it, subclassing is a thing. Doesn't solve the problem. It evades the point of why such built-in methods exist in the first place. Again, if users find themselves re-implementing the same utility function over and over again across different projects it's a good sign that such a function should be part of the standard library. --- Original Message --- On Friday, March 11th, 2022 at 2:28 PM, David Mertz, Ph.D. wrote: > -1 > > Not every one line function needs to be a method on a built-in type. > > I like that tuples have extremely limited methods. Following the iterable > protocol seems fine (also indexable). > > If I were forced to endorse one new method for tuples, I doubt `.replace()` > would be in my top five considerations. > > But if you want it, subclassing is a thing. > > On Fri, Mar 11, 2022, 2:14 PM wfdc via Python-ideas > wrote: > >>> one Stack Overflow question, with a low number of votes >> >> Mind explaining why you say 159 is a "low number of votes" for a >> StackOverflow question on Python? >> >> According to https://stackoverflow.com/questions/tagged/python, this puts it >> in the top 3031 / 1908740 = 0.00159 = 0.159% of Python questions by vote >> count. >> >>> And yet you haven't demonstrated that this is the case for your >> proposal >> >> What kind of evidence would satisfy you? And how did previous proposals you >> supported obtain such evidence? >> >> We've already had 2 other participants here attesting to frequent use of >> this functionality. >> >>> it's not clear that the OP shouldn't have been using a list in >> the first place >> >> This has already been explained in this thread. A list is not immutable. A >> tuple is. Both the old and new tuples are not mutated or mutable, and we >> want to keep it that way. >> >> See namedtuple's ._replace method. namedtuples are also immutable. We simply >> want the same functionality for tuple. >> >> --- Original Message --- >> >> On Friday, March 11th, 2022 at 4:41 AM, Paul Moore >> wrote: >> >>> On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas >>> >>> python-ideas@python.org wrote: >>> >>> > If users find themselves re-implementing the same utility function over >>> > again and over again across different projects, it's a good sign that >>> > such a function should be part of the standard library. >>> >>> And yet you haven't demonstrated that this is the case for your >>> >>> proposal (one Stack Overflow question, with a low number of votes, >>> >>> where it's not clear that the OP shouldn't have been using a list in >>> >>> the first place, isn't particularly compelling evidence). >>> >>> 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/2A6GQZJ4G7JZMSIE6M4CU4BQMQJ62XUN/ >>> >>> 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/YM3GUONPOVES6A7EV7BCXVBH5I6T7EQD/ >> 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/D3RUIDA5KQDRNAVG7P4WHDAPIXZR2N5P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> You still haven't shown why a namedtuple is wrong for your use-case. See Christopher Barker's previous reply to you. Furthermore, namedtuples have *fieldnames*. Tuples have *indices*. Tuples are conceptually more appropriate if we're dealing with what are supposed to be numeric indices into some sequential datastructure, rather than a dictionary-like one. > In fact, you haven't shown anything of your use-case, other than that you've > written a one-liner and wish that it were a method. What is the larger > context in which this is such an incredibly common operation? 1. As already pointed out in the thread, the one-liner is not the most efficient way to implement it, nor does it do bounds checking. 2. See the StackOverflow link and the 2 other participants in this thread attesting to frequent use of this functionality. --- Original Message --- On Friday, March 11th, 2022 at 2:36 PM, Chris Angelico wrote: > On Sat, 12 Mar 2022 at 06:33, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > > But humans can be confused by "replace" having a totally different API in > > > different contexts. > > > > I doubt that's the case here. > > > > The closest equivalent to tuple's .replace method would be namedtuple's > > _.replace method, which also has a different API from string's .replace > > method. > > > > > I could (I believe) write "count" as an (inefficient) 1-liner, but not > > > "index". I suggest it's harder than you think. (Try it!) > > > > How much harder? Can you post your candidate? > > > > In any case, my point still stands. > > > > > "Not every 1-line function needs to be a built-in". > > > > Not every 1-line function needs to not be a built-in. > > > > > Well, you are 1 user. Have you evidence that there are (many) others? > > > > See the StackOverflow link and the 2 other participants in this thread who > > attested to frequent use of this functionality. > > You still haven't shown why a namedtuple is wrong for your use-case. > > In fact, you haven't shown anything of your use-case, other than that > > you've written a one-liner and wish that it were a method. What is the > > larger context in which this is such an incredibly common operation? > > In fact, if it's really such a frequent need, maybe you and/or other > > participants can show more than one use-case. That would be helpful in > > understanding why tuples need this as a method. > > 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/H7VCIVQD7EKM426G4PI6TU6JWLFP3POR/ > > 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/N3CR33COHAUX4OSGYVM7SQUZEJZMUEAO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> I've used Python for 23+ years now. I've had occasion where I'd use this > methods maybe in the low-tens of times. > I'd call the purpose rare at best. This comment is useless without a base rate. What's the base rate for comparable methods that *are* part of the standard library, like index and count? > I'm not going to list other one-liners that I'd also not want, but are less > rare. There are various, but none I'd advocate adding rather than writing > when I need them. Why not? If you're not willing explain or back up that comment in any capacity, which should be very easy, what was the point of making it? It's just adding noise to the discussion. --- Original Message --- On Friday, March 11th, 2022 at 2:45 PM, David Mertz, Ph.D. wrote: > On Fri, Mar 11, 2022, 2:39 PM wfdc wrote: > >>> Not every one line function needs to be a method on a built-in type. >> >> Not every one line function needs to *not* be a method on a built-in type. >> See tuple's count method for an example. > >> Again, if users find themselves re-implementing the same utility function >> over and over again across different projects it's a good sign that such a >> function should be part of the standard library. > > I've used Python for 23+ years now. I've had occasion where I'd use this > methods maybe in the low-tens of times. > > I'd call the purpose rare at best. > > I'm not going to list other one-liners that I'd also not want, but are less > rare. There are various, but none I'd advocate adding rather than writing > when I need them.___ 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/GQR5F6H2UZSY3EYX6H35SDW7HEBZ4SYL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> the "not every one-line function needs to be a builtin" principle applies > here, in my view. The "not every one-line function needs to *not* be a builtin" principle cancels it out. And the "frequently-used functionality should be built-in" (Python's "batteries included" philosophy) overrides it. > you hadn't demonstrated that your proposal satisfied the criteria that you > yourself stated How so? > proposals that succeeded often did so by surveying significant bodies of > real-world code (for example, the standard library) and pointing out where > the proposed new feature would demonstrably improve the readability or > maintainability of parts of the code. That's something we can work with. Do you have particular examples that demonstrate the kind of evidence that would satisfy you? > You do know how many people use Python? 2 people saying they do something like this isn't particularly significant. That's strawmanning my point. I said 2 participants *in this thread*. That's a very different population being sampled from to assess significance than "the entire population of Python users". > Even 2 people out of the number of regular contributors on python-ideas isn't > a lot Again, *in this thread*. > especially if you take level of participation into account - which is dangerous, because it amounts to an appeal to authority I don't see how "it amounts to an appeal to authority". Can you explain? Furthermore, the StackOverflow page provides additional evidence that this functionality is in demand. And it's not just the question itself, but the upvotes, answers, and comments on that page. > Why, in the context of that real-world problem, is a tuple (as opposed to, > say, an immutable dataclass or namedtuple, both of which have replace > methods) the demonstrably best choice, *in spite* of the fact that other > choices provide the supposedly important replace functionality? See Christopher Barker's reply to Chris Angelico. See also my reply to Chris Angelico. > The original SO question sounds suspiciously like an XY-problem to me (see https://en.wikipedia.org/wiki/XY_problem). On what basis? And again, it's not just the question itself, but the upvotes, answers, and comments on that page. > I understand *what* you want. But *why*? See my reply to Chris Angelico. --- Original Message --- On Friday, March 11th, 2022 at 2:54 PM, Paul Moore wrote: > On Fri, 11 Mar 2022 at 19:12, wfdc w...@protonmail.com wrote: > > > What kind of evidence would satisfy you? And how did previous proposals you > > supported obtain such evidence? > > Honestly, probably nothing. I don't think this is a good idea in any > > case, the "not every one-line function needs to be a builtin" > > principle applies here, in my view. You may have a different view, > > that's fine. My reason for pointing out that you hadn't demonstrated > > that your proposal satisfied the criteria that you yourself stated, is > > that you might find someone more sympathetic to the proposal, and if > > so, this is the sort of evidence that you'd need in order to take this > > to python-dev or to create a PR, if you were to have any chance of > > success. > > In the past, proposals that succeeded often did so by surveying > > significant bodies of real-world code (for example, the standard > > library) and pointing out where the proposed new feature would > > demonstrably improve the readability or maintainability of parts of > > the code. > > > We've already had 2 other participants here attesting to frequent use of > > this functionality. > > You do know how many people use Python? 2 people saying they do > > something like this isn't particularly significant. Even 2 people out > > of the number of regular contributors on python-ideas isn't a lot > > (especially if you take level of participation into account - which is > > dangerous, because it amounts to an appeal to authority, but how else > > are you going to demonstrate that a non-trivial number of the millions > > of people who use Python would find this helpful? > > > > it's not clear that the OP shouldn't have been using a list in > > > > > > the first place > > > > This has already been explained in this thread. A list is not immutable. A > > tuple is. Both the old and new tuples are not mutated or mutable, and we > > want to keep it that way. > > Yes, I understand that if you want to create a new immutable tuple > > with one value changed, you need to build it from the parts of the > > original.
[Python-ideas] Re: Add a replace method to tuples
> you haven't shown us what your use-case actually is Any use-case where you'd want to modify an entry of an immutable sequence. Modifying an immutable datastructure is not a contradictory statement. In fact, there's a whole literature on it. See https://en.wikipedia.org/wiki/Purely_functional_data_structure https://en.wikipedia.org/wiki/Persistent_data_structure As Marco Sulla pointed, out, "Performance apart, this will allow you to code in functional style more easily." namedtuple's ._replace method is an existing example (as is record updating in Haskell, which is a purely functional language, with the attending benefits of immutability). For me *specifically*, my latest use-case is in a game-theoretic setting where the tuple represents a strategy profile. But the details of that would take us far beyond the scope of the discussion. > whether it would actually be more appropriate for a list instead Lists are not immutable, so they fail the criteria. > Do all your tuples have the same length? In an inner context, yes. But in an outer context, no. What I mean by that is that, in my particular case, the number of entries is a hyperparameter. --- Original Message --- On Friday, March 11th, 2022 at 2:56 PM, Chris Angelico wrote: > On Sat, 12 Mar 2022 at 06:50, wfdc w...@protonmail.com wrote: > > > > You still haven't shown why a namedtuple is wrong for your use-case. > > > > See Christopher Barker's previous reply to you. > > > > Furthermore, namedtuples have fieldnames. Tuples have indices. Tuples are > > conceptually more appropriate if we're dealing with what are supposed to be > > numeric indices into some sequential datastructure, rather than a > > dictionary-like one. > > You keep saying this sort of thing, but you haven't shown us what your > > use-case actually is, and whether it would actually be more > > appropriate for a list instead. > > Do all your tuples have the same length? > > 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/L5BMYZANGKP2FKO2OE3AOJDZEKEOQ4HT/ > > 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/V5YY2SSTL4JUTNAQGLZSH5572V5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> why haven't you used a list 1. A list is not immutable. 2. I don't want to modify the original sequence. --- Original Message --- On Friday, March 11th, 2022 at 4:07 PM, Marco Sulla wrote: > On Fri, 11 Mar 2022 at 21:39, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > For me specifically, my latest use-case is in a game-theoretic setting > > where the tuple represents a strategy profile. But the details of that > > would take us far beyond the scope of the discussion. > > Well, but I think this is the point. I mean, why haven't you used a > > list? I suppose the main doubt for me and the others is here. > > I mean, I like your proposal (but this probably is not helping you > > here...), and I'm somewhat attracted by functional programming. But I > > never programmed in functional style. It's more a sympathy and a > > fascination than a real need. But maybe you can change my mind with > > your personal experience, as I changed my opinion about OOP a long > > time ago. _______ 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/QWTHGR3NRYPUDHZPDOCYTW27BSHZNWFJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
How about something like def index(self, x): return next(i for i, a in enumerate(self) if a == x) Including start and end: def index(self, x, start=0, end=-1): return next(i for i, a in tuple(enumerate(self))[start:end] if a == x) --- Original Message --- On Friday, March 11th, 2022 at 4:02 PM, Rob Cliffe wrote: > On 11/03/2022 19:30, wfdc wrote: > >>> I could (I believe) write "count" as an (inefficient) 1-liner, but not >>> "index". I suggest it's harder than you think. (Try it!) >> >> How much harder? Can you post your candidate? > > It was you that said it could be a 1-liner. The burden of proof is on you, if > you still want to argue the point. > 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/SDI3WIUEWB4CIMA4JU7SBRVRUEFE3TXO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
Don't yell. You just effectively re-implemented Christopher Barker's solution (which was also present in the StackOverflow thread), with the downside that it fails the immutability criterion. Saying "just be careful not to mutate the original datastructure" isn't a solution. There's a reason we have immutable types: To enforce immutability. Otherwise, why aren't you proposing getting rid of the tuple type entirely? --- Original Message --- On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. wrote: > On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas > wrote: > >>> why haven't you used a list >> 2. I don't want to modify the original sequence. > > There's a really easy solution for you that will even be more perfomant. > > Use a list and DON'T modify the original! > > This is ABSOLUTELY an XY-problem which fact was difficult to wrestle out > of you. > >>>> stuff1 = [a, b, c, d] >>>> stuff2 = stuff1[:] >>>> stuff2[2] = e___ 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/K2UOQGYTQVARPHTVYDPW76JGKQ2PT4K4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
Wrong. If you're not willing to make substantive contributions to this thread, I suggest you refrain from posting further. --- Original Message --- On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D. wrote: > So it appears the "problem" this is intended to solve is "Python isn't > Haskell." > > But Haskell exists, and this is a non-problem looking for a solution. > > On Fri, Mar 11, 2022, 4:39 PM wfdc wrote: > >> Don't yell. >> >> You just effectively re-implemented Christopher Barker's solution (which was >> also present in the StackOverflow thread), with the downside that it fails >> the immutability criterion. >> >> Saying "just be careful not to mutate the original datastructure" isn't a >> solution. There's a reason we have immutable types: To enforce >> immutability. Otherwise, why aren't you proposing getting rid of the tuple >> type entirely? >> >> --- Original Message --- >> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. >> wrote: >> >>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas >>> wrote: >>> >>>>> why haven't you used a list >>>> 2. I don't want to modify the original sequence. >>> >>> There's a really easy solution for you that will even be more perfomant. >>> >>> Use a list and DON'T modify the original! >>> >>> This is ABSOLUTELY an XY-problem which fact was difficult to wrestle >>> out of you. >>> >>>>>> stuff1 = [a, b, c, d] >>>>>> stuff2 = stuff1[:] >>>>>> stuff2[2] = e___ 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/DUJND4AXSODQAKRMA7NYRYREBXBAZ635/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
(To be clear, I'm saying David Mertz's proposal fails the immutability criterion, not Christopher Barker's.) --- Original Message --- On Friday, March 11th, 2022 at 4:39 PM, wfdc wrote: > Don't yell. > > You just effectively re-implemented Christopher Barker's solution (which was > also present in the StackOverflow thread), with the downside that it fails > the immutability criterion. > > Saying "just be careful not to mutate the original datastructure" isn't a > solution. There's a reason we have immutable types: To enforce immutability. > Otherwise, why aren't you proposing getting rid of the tuple type entirely? > > --- Original Message --- > On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. > wrote: > >> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas >> wrote: >> >>>> why haven't you used a list >>> 2. I don't want to modify the original sequence. >> >> There's a really easy solution for you that will even be more perfomant. >> >> Use a list and DON'T modify the original! >> >> This is ABSOLUTELY an XY-problem which fact was difficult to wrestle out >> of you. >> >>>>> stuff1 = [a, b, c, d] >>>>> stuff2 = stuff1[:] >>>>> stuff2[2] = e___ 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/KJ3NTNIRWXHECCVA6BP3BEG644B7WMKD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
So do you propose getting rid of the tuple type entirely or not? Do you see why it's useful to have immutability? --- Original Message --- On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. wrote: > Yes. To be clear, immutability isn't a use case, it's a particular technique > that can be useful for solving some problems. > > This is probably a clear enough example of the XY-problem as to be worth > adding to the Wikipedia article on that topic. > > We sometimes see other similar proposals to e.g. "solve" the "problem" that > Python isn't statically typed. That is, folks who want Python to be some > different language. > > On Fri, Mar 11, 2022, 4:42 PM wfdc wrote: > >> (To be clear, I'm saying David Mertz's proposal fails the immutability >> criterion, not Christopher Barker's.) >> >> --- Original Message --- >> On Friday, March 11th, 2022 at 4:39 PM, wfdc wrote: >> >>> Don't yell. >>> >>> You just effectively re-implemented Christopher Barker's solution (which >>> was also present in the StackOverflow thread), with the downside that it >>> fails the immutability criterion. >>> >>> Saying "just be careful not to mutate the original datastructure" isn't a >>> solution. There's a reason we have immutable types: To enforce >>> immutability. Otherwise, why aren't you proposing getting rid of the tuple >>> type entirely? >>> >>> --- Original Message --- >>> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. >>> wrote: >>> >>>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas >>>> wrote: >>>> >>>>>> why haven't you used a list >>>>> 2. I don't want to modify the original sequence. >>>> >>>> There's a really easy solution for you that will even be more perfomant. >>>> >>>> Use a list and DON'T modify the original! >>>> >>>> This is ABSOLUTELY an XY-problem which fact was difficult to wrestle >>>> out of you. >>>> >>>>>>> stuff1 = [a, b, c, d] >>>>>>> stuff2 = stuff1[:] >>>>>>> stuff2[2] = e___ 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/K3CWHSBWAA5PANVV44CVQPDVEAIYAJ7N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
Please. If we're now talking about specific exceptions, my replace isn't a one-liner either. I was clearly referring to actual functionality. If you want that specific exception, 2 lines are sufficient. --- Original Message --- On Friday, March 11th, 2022 at 4:45 PM, Rob Cliffe wrote: > On 11/03/2022 21:33, wfdc wrote: > >> How about something like >> >> def index(self, x): >> return next(i for i, a in enumerate(self) if a == x) >> >> Including start and end: >> >> def index(self, x, start=0, end=-1): >> return next(i for i, a in tuple(enumerate(self))[start:end] if a == x) > > No cigar. If the element is not found it raises StopIteration. It should > raise ValueError. > Rob Cliffe > >> > >> --- Original Message --- >> On Friday, March 11th, 2022 at 4:02 PM, Rob Cliffe >> [](mailto:rob.cli...@btinternet.com) wrote: >> >>> On 11/03/2022 19:30, wfdc wrote: >>> >>>>> I could (I believe) write "count" as an (inefficient) 1-liner, but not >>>>> "index". I suggest it's harder than you think. (Try it!) >>>> >>>> How much harder? Can you post your candidate? >>> >>> It was you that said it could be a 1-liner. The burden of proof is on you, >>> if you still want to argue the point. >>> 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/HWJYYAOUO5AV7W22DIHGEPAKGVYLOWBE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> they may have to spend time patiently arguing for it, answering objections,
> demonstrating use cases, covering corner cases, discussing
> alternatives/variations etc.
That's what I'm doing.
A direct writing style does not mean "belligerent".
> But it seems to me that something you can implement as a 1-liner in your own
> code is hardly a pressing need.
1. As Christopher Barker and Marco Sulla pointed out, it's not the most
efficient implementation. The latter may be more elaborate. It's worth
exploring further.
2. Regardless of whether it's a 1-liner (like the existing count method), if a
function is used frequently, it's worth considering as an addition to the
standard library. This saves users from having to reimplement the same utility
function again and again across projects, possibly making errors in the process.
> I wasn't aware of namedtuple's _.replace method. But as far as I can see, the
> API is not the same as your proposed method either.
I raised it as an example of modifying an immutable type.
The exact API of the proposed method is open to discussion.
> That, it seems to me, is a pretty insulting thing to say
Not at all. It's appropriate given the tone and content of the post it's
addressed to.
> to someone who, I would guess, has been using Python for decade(s) longer
> than you have.
1. On what basis? You don't know who I am.
2. How long they've been using Python is irrelevant. It's also strange to bring
up the Python-age of participants after protesting appeal to authority.
> Likewise this which you wrote in another post: "Do you see why it's useful to
> have immutability?"
That's not insulting at all. It's a perfectly valid question to address to a
post that seems to be contesting the purpose of immutable types in the first
place.
--- Original Message ---
On Friday, March 11th, 2022 at 5:38 PM, Rob Cliffe
wrote:
> This is a common scenario on python-list or python-ideas:
> Someone has an idea that they think is the greatest thing since sliced bread.
> They propose it, and feel hurt / rejected when they get pushback instead of
> everyone jumping up and down and saying how brilliant it is.
> Sometimes they are downright rude.
> I wouldn't say you've quite crossed that line, but your tone certainly comes
> across (to me at least) as belligerent. It won't help your cause to put
> people's backs up. I apologise if that's not how you meant it.
> Of course occasionally someone comes up with a really good idea. But most
> proposals fail to gain traction because they are actually not a very good
> idea, or there is not enough support for them, or simply because no-one is
> prepared to put in the effort (e.g. to write a PEP and/or make a reference
> implementation, etc.) The default position is "status quo wins" because there
> is a cost for every feature added. It has to be implemented. Tests have to be
> written for it. It has to be maintained. The online documentation has to be
> updated. Many books on Python become out of date until/unless the authors (if
> still alive) can update them. It's one more thing that people (may) have to
> learn when they learn Python. Net result: quite a high bar for changes (even
> small ones).
>
> Even on the (few) occasions when someone has a really good, new idea, they
> may have to spend time patiently arguing for it, answering objections,
> demonstrating use cases, covering corner cases, discussing
> alternatives/variations etc. before their idea gains support.
>
> My opinion on it's own counts for nothing. I'm not even saying your proposal
> is a bad idea. But it seems to me that something you can implement as a
> 1-liner in your own code is hardly a pressing need.
>
> I wasn't aware of namedtuple's _.replace method. But as far as I can see, the
> API is not the same as your proposed method either. Quoting from
> https://stackoverflow.com/questions/2166147/namedtuple-replace-doesnt-work-as-described-in-the-documentation
> :
>>>> from collections import namedtuple
>>>> Point = namedtuple('Point', 'x,y')
>>>>
>>>> p = Point(x=11, y=22)
>>>>
>>>> p._replace(x=33)
> Point(x=33, y=22)
>
> There is no index (0, 1, 2 ...), instead there is a name.
>
> On 11/03/2022 21:43, wfdc via Python-ideas wrote:
>
>> Wrong.
>>
>> If you're not willing to make substantive contributions to this thread, I
>> suggest you refrain from posting further.
>
> That, it seems to me, is a pretty insulting thing to say to someone who, I
> would guess, has been using Python for decade(s)
[Python-ideas] Re: Add a replace method to tuples
Now read what you said earlier: > So it appears the "problem" this is intended to solve is "Python isn't > Haskell." > But Haskell exists, and this is a non-problem looking for a solution. A bizarre incongruence, right? --- Original Message --- On Friday, March 11th, 2022 at 6:26 PM, David Mertz, Ph.D. wrote: > On Fri, Mar 11, 2022, 6:19 PM wfdc wrote: > >>> Likewise this which you wrote in another post: "Do you see why it's useful >>> to have immutability?" >> >> That's not insulting at all. It's a perfectly valid question to address to a >> post that seems to be contesting the purpose of immutable types in the first >> place. > > Gosh, I had no idea immutability could be useful! :-) > > https://openlibra.com/en/book/functional-programming-in-python_______ 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/ACK3RHWYPSTXERAWSXVRN4NHZCCIPCY2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See the following Sourcegraph query for examples of use of this pattern: https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp Regex: \[\s*:\s*(i|j|k|ind|index)\s*\]\s*\+\s*\(.*\,\)\s*\+\s*[\w\.]+\[\s*(i|j|k|ind|index)\s*\+\s*1\s*:\s*\] --- Original Message --- On Wednesday, March 9th, 2022 at 10:42 PM, wfdc wrote: > Add a "replace" method to tuples that returns a new tuple with the element at > a given index replaced with a given value. Example implementation: > > def replace(self, index, value): > return self[:index] + (value,) + self[index + 1:] > > See > https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple > for more context. > > Currently, tuples have 2 public methods: index and count. replace would be > similarly easy to implement and similarly useful. > > Furthermore, it would be a natural counterpart to nametuple's _replace method.___ 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/AJ6HIDCV7JDSVFHUDU5444ZZ5KVR7SNI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp and https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp --- Original Message --- On Sunday, March 13th, 2022 at 1:55 AM, Stephen J. Turnbull wrote: > Game theorist here. > > wfdc via Python-ideas writes: > > > Do you see why it's useful to have immutability? > > Sure, it's potentially hashable. But I can't recall ever finding that > > useful in working with matrix games (loosely speaking, I mean games > > with a finite set of players, each with a finite strategy space). > > I've used (subclasses of) tuple for strategy profiles, but I always > > wanted more additional attributes than just 'replace' (thus > > subclasses), and I call it "deviate" (usually) or "disturbance" (when > > computing perfect or proper equilibria; of course those implicate the > > mixed extension, which complicates thing, and also they involve > > changing all the non-interior strategies simultaneously). Really > > curious to hear enough about your use case to understand why adding > > this method to tuple is so much preferable to using a list (which is > > what I do when calculating best replies in an abstract matrix game, eg > > toy examples for introductory classes) or some class based on dict, > > list, or tuple (when the game is a model of some social phenomenon and > > I want to access various summaries of performance "at" a profile). > > > > This could cause confusion because str.replace() has a completely > > > > different API. > > > We're talking about tuples here, not strings. > > You are, and you have every right to. I want to talk about immutable > > sequences, and that's fine, too. > > The point is that str and tuples are both immutable sequences, and > > both "replace at index" and "replace value" make sense for all > > sequences. Of course mutable sequences already have the usual > > indexing and slicing APIs for replacement, so this would be immutables > > only. BTW, bytes.replace has the same signature as str.replace. > > It's true that namedtuple has a replace method with a different > > signature, but that signature relates to namedtuple as a (general) > > mapping, not as a sequence (which, although it's a special case of > > mapping, is sufficiently important to have two builtin > > implementations). > > > Saying that a method's API differs for a completely different type, > > > especially when such a difference would be expected given the > > > difference in types, is not a valid objection. > > True. I wouldn't expect the replace method on ints to be the same as > > the replace method on tuples. I would expect the replace method on > > immutable sequences to be consistent across subtypes. I don't yet see > > a reason why "replace value" wouldn't be at least as useful "replace > > at index". And in fact "replace value" is plausible for list, as > > well, with that signature. > > Based on the precedent set by other immutable sequences, I'm firmly -1 > > on the name "replace" for "replace at". I'm -1 on adding it to tuple > > with any name, but I could be convinced otherwise based on systematic > > evidence that it's broadly useful, such as a survey of the stdlib. > > 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/IJ2NBULRFTVCFQWU2ZE6KC5MWWB3ZYOM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See also the following Sourcegraph query for examples of use of the second approach: https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp Regex: =\s*list\([\w\.]+\)\s*\w+\[\w+\]\s*=\s*[\w\.]+\s*[\w\.]+\s*=\s*tuple\(\w+\) --- Original Message --- On Friday, March 11th, 2022 at 7:36 PM, wfdc wrote: > See the following Sourcegraph query for examples of use of this pattern: > > https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp > > Regex: > \[\s*:\s*(i|j|k|ind|index)\s*\]\s*\+\s*\(.*\,\)\s*\+\s*[\w\.]+\[\s*(i|j|k|ind|index)\s*\+\s*1\s*:\s*\] > > --- Original Message --- > On Wednesday, March 9th, 2022 at 10:42 PM, wfdc wrote: > >> Add a "replace" method to tuples that returns a new tuple with the element >> at a given index replaced with a given value. Example implementation: >> >> def replace(self, index, value): >> return self[:index] + (value,) + self[index + 1:] >> >> See >> https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple >> for more context. >> >> Currently, tuples have 2 public methods: index and count. replace would be >> similarly easy to implement and similarly useful. >> >> Furthermore, it would be a natural counterpart to nametuple's _replace >> method.___ 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/VZGYZE5NLITFLRWQMLHWBBXYGJN5IMTN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
Just to add, the following Sourcegraph queries provide good evidence of widespread use of this functionality: https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp --- Original Message --- On Saturday, March 12th, 2022 at 1:41 AM, Christopher Barker wrote: > Wow! > > Does anyone else see the irony in the fact that just a couple days ago, Chris > A lamented that Python-ideas seemed to > Immediately reject any new idea out of hand? And yes, Chris, you have joined > in the piling on in this case. > > I didn’t think it was that bad, but this thread has been pretty painful. > > I’m pretty surprised that folks seem to be denying that this proposal has any > use at all. > > Is this a major need? Obviously not, > > As for “not every one line function..” I demonstrated quite clearly that its > not a one liner, it’s not obvious, and as Marco pointed out, it literally has > to be a built in to get top performance. > > Is the SC likely to think it’s worth adding a new method to a core built in > for? Probably not. > > But not rising to the very high standard that changes to core Python need is > not the same as a pointless or bad idea. > > Thanks Paul for laying out what would have to be done honestly. > > To rest of you Debbie Downers -. Really? > > -CHB > > On Fri, Mar 11, 2022 at 1:51 PM wfdc via Python-ideas > wrote: > >> So do you propose getting rid of the tuple type entirely or not? >> >> Do you see why it's useful to have immutability? >> >> --- Original Message --- >> >> On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D. >> wrote: >> >>> Yes. To be clear, immutability isn't a use case, it's a particular >>> technique that can be useful for solving some problems. >>> >>> This is probably a clear enough example of the XY-problem as to be worth >>> adding to the Wikipedia article on that topic. >>> >>> We sometimes see other similar proposals to e.g. "solve" the "problem" that >>> Python isn't statically typed. That is, folks who want Python to be some >>> different language. >>> >>> On Fri, Mar 11, 2022, 4:42 PM wfdc wrote: >>> >>>> (To be clear, I'm saying David Mertz's proposal fails the immutability >>>> criterion, not Christopher Barker's.) >>>> >>>> --- Original Message --- >>>> On Friday, March 11th, 2022 at 4:39 PM, wfdc wrote: >>>> >>>>> Don't yell. >>>>> >>>>> You just effectively re-implemented Christopher Barker's solution (which >>>>> was also present in the StackOverflow thread), with the downside that it >>>>> fails the immutability criterion. >>>>> >>>>> Saying "just be careful not to mutate the original datastructure" isn't a >>>>> solution. There's a reason we have immutable types: To enforce >>>>> immutability. Otherwise, why aren't you proposing getting rid of the >>>>> tuple type entirely? >>>>> >>>>> --- Original Message --- >>>>> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. >>>>> wrote: >>>>> >>>>>> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas >>>>>> wrote: >>>>>> >>>>>>>> why haven't you used a list >>>>>>> 2. I don't want to modify the original sequence. >>>>>> >>>>>> There's a really easy solution for you that will even be more perfomant. >>>>>> >>>>>> Use a list and DON'T modify the original! >>>>>> >>>>>> This is ABSOLUTELY an XY-problem which fact was difficult to wrestle >>>>>> out of you. >>>>>> >>>>>>>>> stuff1 = [a, b, c, d] >>>>>>>>> stuff2 = stuff1[:] >>>>>>>>> stuff2[2] = e >> >> ___ >> 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/K3CWHSBWAA5PANVV44CVQPDVEAIYAJ7N/ >> 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/HWTH4PCAF7NX75QJ3AYMKYGTOZ456Z3T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp and https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp > Yes, and dataclasses and namedtuples support this concept very nicely. You > still haven't shown why neither works. 1. They're less efficient, as Christopher pointed out long ago. 2. They're not sequences, so conceptually the wrong tool for the job. > it definitely seems like a good use-case for a dataclass. See above. > Repeatedly stating that it has to be immutable, has to not be a namedtuple, > has to not be a dataclass, and has to have a replace method, doesn't make it > true. See above. --- Original Message --- On Monday, March 14th, 2022 at 8:30 AM, Chris Angelico wrote: > On Sat, 12 Mar 2022 at 07:38, wfdc w...@protonmail.com wrote: > > > > you haven't shown us what your use-case actually is > > > > Any use-case where you'd want to modify an entry of an immutable sequence. > > That doesn't answer the question any more than your original code > > does. You're still starting with the assumption that you want to use a > > tuple, and using that as proof that you need to use a tuple. > > Show us your ACTUAL use case, your actual code, and why you can't use > > either a list or a namedtuple. Stop assuming that you are correct > > before you begin, because we don't agree that a tuple is necessary. > > You have not shown us any code, only made this repeated assertion and > > then wondered why we don't believe you. > > > Modifying an immutable datastructure is not a contradictory statement. In > > fact, there's a whole literature on it. See > > > > https://en.wikipedia.org/wiki/Purely_functional_data_structure > > > > https://en.wikipedia.org/wiki/Persistent_data_structure > > Yes, and dataclasses and namedtuples support this concept very nicely. > > You still haven't shown why neither works. > > > As Marco Sulla pointed, out, "Performance apart, this will allow you to > > code in functional style more easily." > > > > namedtuple's ._replace method is an existing example (as is record updating > > in Haskell, which is a purely functional language, with the attending > > benefits of immutability). > > > > For me specifically, my latest use-case is in a game-theoretic setting > > where the tuple represents a strategy profile. But the details of that > > would take us far beyond the scope of the discussion. > > I don't understand how a strategy profile has to be a tuple. In fact, > > particularly since you're wanting to replace one part of it, it > > definitely seems like a good use-case for a dataclass. > > > > whether it would actually be more appropriate for a list instead > > > > Lists are not immutable, so they fail the criteria. > > Why? > > Do you see how you are still failing to show any actual code, and thus > > any actual demonstration of why a tuple is necessary? > > Repeatedly stating that it has to be immutable, has to not be a > > namedtuple, has to not be a dataclass, and has to have a replace > > method, doesn't make it true. > > 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/6MZTLI4I42ZEDJATKM5WDYHMSNEOW6IH/ > > 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/VKCBA6CM3YTW4F6PPJIPEALIZI6FZUGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
You may not, but others do. See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp and https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:31 AM, Chris Angelico wrote: > On Sat, 12 Mar 2022 at 08:53, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > So do you propose getting rid of the tuple type entirely or not? > > > > Do you see why it's useful to have immutability? > > Immutability is extremely useful. I use tuples VERY frequently. But I > > don't then need to replace one element in them. > > 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/Q7OP5GSX5QZRCFVKDMUR6Q54KVGAOEEV/ > > 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/CTDIISRREQNS74FVKGLEA5Q3624H322Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> I would think that at least is obvious: the top voted Python question on > StackOverflow currently has 11891 votes. This is two orders of magnitude less. Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% of Python questions by vote count. That's not "a low number of votes" no matter how you try to spin it. > Popularity on StackOverflow is just a vague indication of popularity, not a > sign of need or usefulness. Then see https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp for plenty more examples. > Is this part of the tuple class alone? > Or part of the Sequence ABC? Why or why not? Tuple alone, but I'm open to the latter. > What arguments does it take (index, slice, tuple of indicies)? Index, as specified in the OP. (Again, open to discussion.) > Any error conditions, what exceptions will be raised? I suggest raising an IndexError when the index is out of range. > Can we use it to delete an item (replace it with nothing at all)? No. > justification for why a simple one-line function isn't sufficient. See Christopher Barker's response. (Yes, efficiency is important.) See also the "batteries included" point that was made ages ago. (If users find themselves re-implementing the same utility function over and over again across different projects, it's a good sign that such a function should be part of the standard library.) Your other questions are frankly not necessary to answer and feel like goalpost-moving. The two proposals you held up as examples don't even satisfy them. --- Original Message --- On Monday, March 14th, 2022 at 8:32 AM, Steven D'Aprano wrote: > On Fri, Mar 11, 2022 at 07:12:49PM +, wfdc via Python-ideas wrote: > > > > one Stack Overflow question, with a low number of votes > > > > Mind explaining why you say 159 is a "low number of votes" for a > > > > StackOverflow question on Python? > > I would think that at least is obvious: the top voted Python question on > > StackOverflow currently has 11891 votes. This is two orders of magnitude > > less. > > It is certainly true that there are over a million Python questions that > > have received even fewer votes, but 159 votes is still low. > > In any case, number of votes on StackOverflow is not a good way of > > judging the worth of a proposal. Votes can be given for many reasons, > > not just "this proposal should be a built-in function or method". For > > example, the highest voted question is a request for an explanation, > > "What does the yield keyword do?". > > Popularity on StackOverflow is just a vague indication of popularity, > > not a sign of need or usefulness. > > > > And yet you haven't demonstrated that this is the case for your > > > > > > proposal > > > > What kind of evidence would satisfy you? And how did previous > > > > proposals you supported obtain such evidence? > > Excellent question! > > Unfortunately, I think this is a non-trivial change that will require > > a PEP. > > (The boundary between trivial and non-trivial is subjective, and others > > may disagree, but here I feel confident that the core devs will agree > > that regardless of how trivial the implementation, a change to the API > > of a core builtin type like tuple will require a PEP.) > > Yes, this is a lot of trouble to go through, but Python is a 30+ year > > old mature language. Even though this change alone is not breaking > > backwards compatibility, it still has consequences. Every change has to > > justify itself, every feature has costs: > > - extra code in the interpreter > > - more things that can break > > - extra tests > > - more documentation > > - more for users to learn > > - more to remember > > What may be my essential feature may be your bloat. > > If the benefits don't outweigh the costs for the majority of people, > > then the proposal is unlikely to be accepted. > > You should start by looking at similar successful PEPs, e.g.: > > Dict union: https://peps.python.org/pep-0584/ > > String methods to remove prefixes and suffixes: > > https://peps.python.org/pep-0616/ > > an
[Python-ideas] Re: Add a replace method to tuples
> wfdc (should we call you something which is not a random-looking string of > consonants?) wfdc is fine. > it might help if you could give examples of this functionality from other > languages or classes. What do they call the method? https://clojuredocs.org/clojure.core/assoc https://immutable-js.com/docs/v4.0.0/set()/ http://swannodette.github.io/mori/#assoc https://hackage.haskell.org/package/lens-5.1/docs/Control-Lens-Operators.html#v:.-126- https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Sequence.html#update What about 'update' or 'set'? > what if index assignment was an expression? [...] Now that I have seen this > syntax, I want it!!! Interesting idea. Perhaps we can discuss it further. --- Original Message --- On Monday, March 14th, 2022 at 8:38 AM, Steven D'Aprano wrote: > On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote: > > > This could cause confusion because str.replace() has a completely > > > > different API. > > The old "painter.draw()" versus "gun_slinger.draw()" problem. > > It does exist, but it's not generally a major problem. > > > And indeed if a replace method were added to tuples, a fair case could > > > > be made for it having the same API, viz. > > > > replace(old, new, count=-1) > > A reasonable suggestion. Does replace change items according to their > > position, or their value? > > Perhaps a better name would help. > > wfdc (should we call you something which is not a random-looking string > > of consonants?) it might help if you could give examples of this > > functionality from other languages or classes. What do they call the > > method? > > It would be nice to have a better API for this function. I have used it > > many times, for strings, lists and tuples, it is really a generate > > sequence operation: > > * make a copy of the sequence, replacing the item at position p with a > > new value; > > We can do it with type-specific expressions: > > seq[:p] + [value] + seq[p+1:] > > seq[:p] + (value,) + seq[p+1:] > > string[:p] + "c" + string[p+1:] > > but there is no good, type-agnostic way to easily do it. > > Wacky thought: what if index assignment was an expression? > > function(arg, seq[p]=value, another_arg) > > would pass a copy of seq with the item at p replaced by value. That > > would work with slices as well: > > seq[a:b] = values > > Now that I have seen this syntax, I want it!!! > > (It is not clear to me if this would be compatible to the existing > > `setitem API.) > > > Whereas your suggestion can be written as a simple 1-liner, as you > > > > demonstrate. So there is no strong need for a new method for it. > > Sure, not all one-liners need to be built-in. But some do. > > -- > > 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/HKYHO35W5M3LKUGUZ6MRYVVEIKUQ5XHC/ > > 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/R3GVWUZFQEMDY45FDKL536IXI7WX4A34/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:39 AM, Brendan Barnwell wrote: > On 2022-03-11 12:03, wfdc via Python-ideas wrote: > > > > I've used Python for 23+ years now. I've had occasion where I'd use this > > > methods maybe in the low-tens of times. > > > > > > I'd call the purpose rare at best. > > > > This comment is useless without a base rate. What's the base rate for > > > > comparable methods that are part of the standard library, like index > > > > and count? > > You seem to be implicitly suggesting that we should implement all > > methods that are at least as useful (or frequently needed, or whatever) > > as existing methods. I have some sympathy with this view, but you seem > > to be taking it to an unrealistic level. There are many things that > > have been added to Python over time that are now less useful than other > > things, for various reasons. We can't just draw a line and say "because > > .some_method() already exists and has a usefulness score of X, anything > > that is more useful must now be added" (even if it were possible to > > define such a usefulness score). Moreover, to do so would only lead to > > a spiral of madness, since by this logic someone else could come along > > and say "well, we added .replace() to tuples and I never need that, so > > there's no reason not to add this other new method most people won't > > care about or use." > > As far as I can see, you don't seem to be providing many substantive > > arguments in favor of your proposal. All you are saying is that > > sometimes it might be useful, and that there are other existing methods > > that aren't super useful, so why not add this one too? To me that is > > sort of like suggesting that it would be good to add a coffee machine > > and a swimming pool to my car, because my car already has a cigarette > > lighter and a little storage flap on the sun visor and I don't use > > those, so there's no reason not to add other random stuff as well. > > That isn't a very convincing argument. In deciding whether to add some > > feature to a car, what's relevant is not what other features my car > > already has that I'm not using, but how much it will cost (in time, > > money, user confusion, etc.) to add the feature relative to how much > > benefit it will bring. > > Similarly, what you are not providing is any consideration of the > > costs of adding this feature relative to the benefit. These costs > > include implementation and maintenance, increased API surface area for > > users to familiarize themselves with, and cluttering the type's > > namespace with yet another method name (even though you seem to > > acknowledge that it's already cluttered with methods that aren't very > > useful). Against that we have the benefit of being able to effectively > > "assign" to a tuple element, which is not zero but also not exactly a > > burning need. I don't think you're going to get much traction on this > > suggestion unless you at least engage with this idea of cost and > > benefits of your proposed feature itself, rather than just focusing on > > what you perceive as the low utility of things that are already part of > > Python. > > -- > > 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/EKWLL4RYWP7YFW4MEO7ANRQ6CNPX25DF/ > > 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/V73PRCK54RF2OI4PFBCRK7URHHH376ZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> there has STILL been no answer to the questions of "why not use namedtuple" > and "why not use a dataclass" Christopher addressed that a long time ago. > no sample code provided See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp --- Original Message --- On Monday, March 14th, 2022 at 8:56 AM, Chris Angelico wrote: > On Mon, 14 Mar 2022 at 23:54, Christopher Barker python...@gmail.com wrote: > > > Wow! > > > > Does anyone else see the irony in the fact that just a couple days ago, > > Chris A lamented that Python-ideas seemed to > > > > Immediately reject any new idea out of hand? And yes, Chris, you have > > joined in the piling on in this case. > > There definitely is a problem when my post, which was asking for more > > details, can be seen as merely piling on the criticism. It indicates > > that there is so much criticism that everything starts to look like > > it. > > In this particular thread, the OP certainly isn't helping to solve the > > issue, as there has STILL been no answer to the questions of "why not > > use namedtuple" and "why not use a dataclass", and no sample code > > provided. But yes, when the dogpile gets so big that every post looks > > like more dogpiling, there is a bit of a problem. > > So no, I don't see it as ironic. The only difference is that, here, I > > wouldn't lament the thread just dying. > > 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/MAQMGRBZWFIWENTVOH6SHM6VD6XHSVDQ/ > > 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/CZ3AVWNJIUMQ6735MT4LA4CT6CKEE3RX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> You're going to have to work harder than that to convince me. It's not clear > how many of those examples are unique, and most are concise and idiomatic. Ridiculous goalpost-moving. I literally just gave you 1000+ examples of this functionality being used, which is what you asked for, including by several important repositories and organizations: - pytorch - pandas - apache - numpy - jax - sympy - cupy - tensorflow - pyqtgraph - aws - dask - deepmind - h5py - cloudflare - facebook research and so on. At this point, it seems like you're just trying to save face. --- Original Message --- On Monday, March 14th, 2022 at 9:47 AM, Stephen J. Turnbull wrote: > Hi, > > You are clearly not making progress, and this list is no longer useful > > to you for this idea -- you know what you want, it's easy enough to > > implement, and you don't need our advice for that I assume. > > I suggest you give up on this list, write the code, make sure it's > > well-documented, and submit a merge request. If you don't get a timely > > response (ie, after a decent interval for the relevant folks to pick > > up the merge request) ping python-dev directly for a decision. If > > you're worried about coding style or exactly how the submission process > > works, core-mentors...@python.org will give you help on that with a > > minimum of backseat driving. > > wfdc via Python-ideas writes: > > > https://sourcegraph.com/search?q=context:global+lang:python+\[\s*:\s*(i|j|k|ind|index)\s*\]\s*\%2B\s*\(.%5C%2C%5C%29%5Cs%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs1%5Cs:%5Cs*%5C%5D&patternType=regexp > > You're going to have to work harder than that to convince me. It's > > not clear how many of those examples are unique, and most are concise > > and idiomatic. > > Good luck! > > 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/FSEDT4RS3BLH3SCPDUPTZHPXBVDK5QPE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> A namedtuple IS a sequence. It is a tuple. They are deliberately designed to > be drop-in replacements for tuples. I meant that they're not meant to be addressed as sequences. That's the whole point of namedtuple: to avoid doing that. And the first point still applies. --- Original Message --- On Monday, March 14th, 2022 at 12:19 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 03:16, wfdc w...@protonmail.com wrote: > > > > Yes, and dataclasses and namedtuples support this concept very nicely. > > > You still haven't shown why neither works. > > > > 1. They're less efficient, as Christopher pointed out long ago. > > > > 2. They're not sequences, so conceptually the wrong tool for the job. > > A namedtuple IS a sequence. It is a tuple. They are deliberately > > designed to be drop-in replacements for tuples. > > 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/OYMJH6445PZ2P4LE5SGLH3QKXV2FHNH5/ > > 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/HPTTY7SIR6C7MFQID7WE65KDTXMFCTFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
The whole *point* is that namedtuples let you use *named fields* rather than indices. That's the point. That's the purpose. What are the named fields supposed to be if the datastructure is being treated as a sequence? Indices again? Then what's the point of using namedtuple rather than tuple in the first place? Again, I direct you to Christopher's comment on the matter. --- Original Message --- On Monday, March 14th, 2022 at 1:07 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 04:02, wfdc w...@protonmail.com wrote: > > > > A namedtuple IS a sequence. It is a tuple. They are deliberately designed > > > to be drop-in replacements for tuples. > > > > I meant that they're not meant to be addressed as sequences. That's the > > whole point of namedtuple: to avoid doing that. > > The whole point is that they are both sequences and structures. > > https://docs.python.org/3/library/collections.html#collections.namedtuple > > 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/5QBJGA4UB3JJ34IULQSFHTBEZGBEFV7U/ > > 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/CB5P5W7I2IID2AUMF72F3HKSD3V52UGA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
And, by the way, field names must be valid identifiers. So again, what are the field names supposed to be if the datastructure is being treated as a sequence, of possibly arbitrary length? --- Original Message --- On Monday, March 14th, 2022 at 1:07 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 04:02, wfdc w...@protonmail.com wrote: > > > > A namedtuple IS a sequence. It is a tuple. They are deliberately designed > > > to be drop-in replacements for tuples. > > > > I meant that they're not meant to be addressed as sequences. That's the > > whole point of namedtuple: to avoid doing that. > > The whole point is that they are both sequences and structures. > > https://docs.python.org/3/library/collections.html#collections.namedtuple > > 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/5QBJGA4UB3JJ34IULQSFHTBEZGBEFV7U/ > > 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/6V7WSM76RTHKOPHKVNHKROSJ63EKXRW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
jax is another example that uses the name 'set' for this functionality: https://jax.readthedocs.io/en/latest/jax.numpy.html On second thought, perhaps it wouldn't be a bad idea to extend this proposal to built-in sequence types in general (list, str, tuple, and bytes). Examples of this functionality being used on those other types: https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B.*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp If extended beyond tuples, we would have to address the name collision with the existing 'replace' methods of str and bytes. In that case, something like 'set' or 'update' might work. (I prefer the former for its conciseness.) --- Original Message --- On Monday, March 14th, 2022 at 12:47 PM, wfdc wrote: > > wfdc (should we call you something which is not a random-looking string of > > consonants?) > > wfdc is fine. > > > it might help if you could give examples of this functionality from other > > languages or classes. What do they call the method? > > https://clojuredocs.org/clojure.core/assoc > > https://immutable-js.com/docs/v4.0.0/set()/ > > http://swannodette.github.io/mori/#assoc > > https://hackage.haskell.org/package/lens-5.1/docs/Control-Lens-Operators.html#v:.-126- > > https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Sequence.html#update > > What about 'update' or 'set'? > > > what if index assignment was an expression? [...] Now that I have seen this > > syntax, I want it!!! > > Interesting idea. Perhaps we can discuss it further. > > --- Original Message --- > > On Monday, March 14th, 2022 at 8:38 AM, Steven D'Aprano st...@pearwood.info > wrote: > > > On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote: > > > > > This could cause confusion because str.replace() has a completely > > > > > > different API. > > > > The old "painter.draw()" versus "gun_slinger.draw()" problem. > > > > It does exist, but it's not generally a major problem. > > > > > And indeed if a replace method were added to tuples, a fair case could > > > > > > be made for it having the same API, viz. > > > > > > replace(old, new, count=-1) > > > > A reasonable suggestion. Does replace change items according to their > > > > position, or their value? > > > > Perhaps a better name would help. > > > > wfdc (should we call you something which is not a random-looking string > > > > of consonants?) it might help if you could give examples of this > > > > functionality from other languages or classes. What do they call the > > > > method? > > > > It would be nice to have a better API for this function. I have used it > > > > many times, for strings, lists and tuples, it is really a generate > > > > sequence operation: > > > > * make a copy of the sequence, replacing the item at position p with a > > > > new value; > > > > We can do it with type-specific expressions: > > > > seq[:p] + [value] + seq[p+1:] > > > > seq[:p] + (value,) + seq[p+1:] > > > > string[:p] + "c" + string[p+1:] > > > > but there is no good, type-agnostic way to easily do it. > > > > Wacky thought: what if index assignment was an expression? > > > > function(arg, seq[p]=value, another_arg) > > > > would pass a copy of seq with the item at p replaced by value. That > > > > would work with slices as well: > > > > seq[a:b] = values > > > > Now that I have seen this syntax, I want it!!! > > > > (It is not clear to me if this would be compatible to the existing > > > > `setitem API.) > > > > > Whereas your suggestion can be written as a simple 1-liner, as you > > > > > > demonstrate. So there is no strong need for a new method for it. > > > > Sure, not all one-liners need to be built-in. But some do. > > > > -- > > > > 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/HKYHO35W5M3LKUGUZ6MRYVVEIKUQ5XHC/ > > > > 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/32V2TGUAVGJZQJ2NOYYJHNYYUTXXR545/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
See my previous response to Chris: > What are the named fields supposed to be if the datastructure is being > treated as a sequence? Indices again? Then what's the point of using > namedtuple rather than tuple in the first place? > And, by the way, field names must be valid identifiers. > So again, what are the field names supposed to be if the datastructure is > being treated as a sequence, of possibly arbitrary length? --- Original Message --- On Monday, March 14th, 2022 at 6:19 PM, Greg Ewing wrote: > On 15/03/22 6:14 am, wfdc via Python-ideas wrote: > > > The whole point is that namedtuples let you use named fields rather than > > indices. That's the point. That's the purpose. > > I would say the point of namedtuple is to let you use either field > > names or indices, whichever makes the most sense for what you're > > doing at the time. Otherwise why not just use a regular class? > > -- > > Greg > > ___ > > 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/6Z3SGL4AJEBS2W4URZ5D4UH4KKPC6IAX/ > > 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/BDSIDWEQO3KFWQBN2EFSSWMHOJJS6OGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> the OP has only had arguments like "namedtuples aren't sequences", which are > not what I'd call compelling. Why don't you answer the question I asked you? --- Original Message --- On Monday, March 14th, 2022 at 4:12 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 05:37, Christopher Barker python...@gmail.com wrote: > > > > there has STILL been no answer to the questions of "why not > > > > > > use namedtuple" and "why not use a dataclass", > > > > The OP may not have, but I at least answered why not namedtuple? very early > > in the thread > > > > Chris A: sorry to call you out, you weren't particularly harsh, but I had > > expected that you, of all people, might try extra hard to keep a positive > > tone in responses to proposals like this. > > > > > and no sample code provided. > > > > Yeah, real genuine use cases would be good. > > My apologies. The thread has gotten VERY noisy, and I did miss the > > fact that you'd said this; partly because the OP has only had > > arguments like "namedtuples aren't sequences", which are not what I'd > > call compelling. I still stand by the sentiment that sample code from > > the OP is more important than someone else's explanation of why > > namedtuple might not be suitable, but perhaps the OP sees it as an > > answered question. > > I've been keeping the tone as positive as possible, but honestly, I > > don't think this thread has much hope of being productive at this > > point, and if you hadn't called me out specifically, I would not have > > responded. > > 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/HBNI5IEQQ5X4EGKNG5ZSAFBEVGGK4QVQ/ > > 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/NUO64EVTMDG7CFDRCLBGVY5QMKA2ER67/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
Again, you neglected to answer the question: > what are the field names supposed to be if the datastructure is being treated > as a sequence, of possibly arbitrary length? > Since a namedtuple is supposed to be both a sequence and a record, the names > are part of the record interface, and the sequence is still part of that. The point is that I *don't* want to treat it as a record, and I have no reason to. That's precisely the point I'm making! > the field names don't have to be valid identifiers Yes, they do. > if it's a sequence of arbitrary length, then why is it a tuple at all? Why wouldn't it be? A tuple is a sequence. And a sequence can be of arbitrary length. > You assume that it has to be a tuple but not a namedtuple, but a namedtuple > IS a tuple. See my first question. > Do you see why we've been asking you to SHOW YOUR CODE? I already provided *plenty* of examples through the Sourcegraph queries. There's no reason for me to give you my specific code, nor does it help this discussion in any way, since I already gave you plenty of examples. --- Original Message --- On Monday, March 14th, 2022 at 7:04 PM, Chris Angelico wrote: > On Tue, 15 Mar 2022 at 10:02, wfdc via Python-ideas > > python-ideas@python.org wrote: > > > See my previous response to Chris: > > > > > What are the named fields supposed to be if the datastructure is being > > > treated as a sequence? Indices again? Then what's the point of using > > > namedtuple rather than tuple in the first place? > > > > > And, by the way, field names must be valid identifiers. > > > > > So again, what are the field names supposed to be if the datastructure is > > > being treated as a sequence, of possibly arbitrary length? > > It's very hard to answer a question that is fundamentally based on a > > misunderstanding of namedtuples. Since a namedtuple is supposed to > > be both a sequence and a record, the names are part of the record > > interface, and the sequence is still part of that. Also, the field > > names don't have to be valid identifiers (although they usually will). > > But if it's a sequence of arbitrary length, then why is it a tuple at > > all? You assume that it has to be a tuple but not a namedtuple, but a > > namedtuple IS a tuple. > > Do you see why we've been asking you to SHOW YOUR CODE? > > I am done. I'm not going to further respond in this thread until there > > is some actual code to discuss. > > 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/SAHYE2XVOAFBJ7UO5ZTECH4GVTEA5XKC/ > > 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/MY2EWIXDDU7CCO3ZLUCG4XFK3FNFO653/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a replace method to tuples
> I got "No results matched your query" on the second URL, at which point I > didn't bother with the first. Check again in case it's an error. https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp I get 500+ results for each query, including code from several prominent repositories and organizations, such as: - pytorch - pandas - apache - numpy - jax - sympy - cupy - tensorflow - pyqtgraph - aws - dask - deepmind - h5py - cloudflare - facebook research and so on. > My perspective is that replacement of an item in a tuple is so simple that it > isn't even worth a utility function unless it is generalised. I don't oppose the latter. > Just build a new tuple using slicing and concatenation expressions. Not every > expression is worth an actual named function. I feel that this proposal is > too small to bother with a function, let alone adding it to the tuple as a > builtin method. See Christopher's comments on performance as a builtin. --- Original Message --- On Monday, March 14th, 2022 at 7:51 PM, Steven D'Aprano wrote: > On Mon, Mar 14, 2022 at 04:38:48PM +, wfdc wrote: > > > > I would think that at least is obvious: the top voted Python > > > > > > question on StackOverflow currently has 11891 votes. This is two > > > > > > orders of magnitude less. > > > > Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% > > > > of Python questions by vote count. > > > > That's not "a low number of votes" no matter how you try to spin it. > > It doesn't matter whether it is the top 0.159% or the top 0.0001%, > > 160 votes or so is an objectively low number compared to the top ranking > > questions, with almost 100 times as many votes. > > Not that it matters. Even if the question had a trillion votes, that > > alone is not sufficient to justify the proposal. > > > > Popularity on StackOverflow is just a vague indication of > > > > > > popularity, not a sign of need or usefulness. > > > > Then see > > > > https://sourcegraph.com/search?q=context:global+lang:python+\[\s*:\s*(i|j|k|ind|index)\s*\]\s*\%2B\s*\(.%5C%2C%5C%29%5Cs%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs1%5Cs:%5Cs*%5C%5D&patternType=regexp > > > > https://sourcegraph.com/search?q=context:global+lang:python+%3D\slist%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp > > > > for plenty more examples. > > I got "No results matched your query" on the second URL, at which point > > I didn't bother with the first. > > Thank you for providing some search terms, but you misunderstand the > > process of proposing new functionality to the builtins and stdlib. The > > onus is not on us to do the work, but for those making the proposal. > > If we ask for examples, we expect you to do the work of curating some > > good examples, not just to dump a regex in our laps and tell us to > > search for them ourselves. > > The bottom line here is that we don't have to justify why the proposal > > isn't accepted. New feature requests are not Default Accept. All we need > > to do is nothing at all and the proposal doesn't go ahead. > > At this point, I don't think this discussion on Python-Ideas is going > > anywhere, which is a shame because I actually do like it. > > Those who are opposed to changes (whether for good reasons or bad) are > > dominating the discussion. You aren't going to change their mind. Those > > who are neutral or in favour have had their voices drowned out. We've > > already had the mailing list put into Emergency Moderation once, > > presumably because tempers are getting frayed. > > I think that your strategies here could include: > > (1) Give this up as a lost cause. > > (2) Ignore the negative feedback here and raise it as an enhancement > > request on the bug tracker, or a PR on the repo. > > You will probably have it rejected and be told to discuss it on > > Python-Ideas, but you might be lucky and get the in
