[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On 20/07/2020 06:11, Ricky Teachey wrote: On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote: One use case that comes up in xarray and pandas is support for indicating indexing "modes". For example, when indexing with floating point numbers it's convenient to be able to opt-in to approximate indexing, e.g., something like: array.loc[longitude, latitude, method='nearest', tolerance=0.001] Thanks to those who pointed out that using kwargs to specify modes of key management is an obvious use case. Ironically that example pushes me back to -1. It may look a lot like xarray and pandas working, but that just means it should be in xarray and/or pandas. It doesn't feel at all right for regular Python to be muddling indices and modal parameters to something that isn't a function call like that. -- Rhodri James *-* Kynesim Ltd ___ 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/Q6ZF746AJLZURKSLUGTIXWEQLUDMEQ2D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On 17/07/2020 21:11, Todd wrote: On Fri, Jul 17, 2020 at 12:19 PM David Mertz wrote: Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be useful for xarray, but I'm not sure now what that would look like. If someone had an example, I could easily be moved. Here is what it currently looks like to assign values to indices in xarray (adapted from a tutorial): ds["empty"].loc[dict(lon=5, lat=6)] = 10 This could be changed to: ds["empty"][lon=5, lat=6] = 10 This becomes even a bigger advantage if we include slicing, which I think we should: ds["empty"].loc[dict(lon=slice(1, 5), lat=slice(3, None))] = 10 to ds["empty"][lon=1:5, lat=6:] = 10 Thanks for posting this. I had been really struggling to see a use case that made any kind of sense to me, possibly because I am not a data scientist and have no interest in becoming one. This helped a lot. I particularly like the slice notation, there is a clear win there. -- Rhodri James *-* Kynesim Ltd ___ 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/4M6DCHAEPFXDLDULALZQZCHOFL2ILDJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thoughts about Fast Python Engine and Python EveryWhere
On 16/07/2020 17:59, redrad...@gmail.com wrote: Recently I have been thinking about why `JavaScript` with it's horrible type system and lots of edge cases has supported so many platform and is very fast ... First answer is simple, because big companies such as Google, Facebook and so on evolve this language and run-time for it ... But it is only part of story, all this platforms would not be possible without some good architecture that was done by this companies Um. I think you should go and read up a bit more about the history of Javascript. And then the history of PHP. What is this architecture decision ? It is a splitting run-time and infrastructure V8 is JavaScript engine that could very fast execute JavaScript and that is all !! It has a reach API using which you can embed this run-time almost every where ... What if we in Python will accomplish the same solution ? You can embed Python right now. The API to do it exists, and a number of programs out in the world do exactly that. -- Rhodri James *-* Kynesim Ltd ___ 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/EXYHJ2NAYNSBGCPWMAED3EH3PKP3STQ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On 01/07/2020 11:24, Steven D'Aprano wrote: On Tue, Jun 30, 2020 at 07:40:23PM +0100, Rhodri James wrote: Don't get me wrong, if it's not going to cause performance issues I think being able to index views would be great What are your use-cases for indexing set-like views of a dict? Personally none, but that's because I still don't treat dicts as being ordered and arrange my data structures accordingly. I seem to remember the OP having a use case, and I can imagine people who have ordering ingrained in their style rather harder than me could find uses. -- Rhodri James *-* Kynesim Ltd ___ 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/NCB7UGLAU4HX27QMTPTPP35IR335QVUY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On 30/06/2020 18:31, Christopher Barker wrote: The first improvement on that was the iter* methods, and then (inspired by JAVA) it was determined that we could have view objects that could provide efficient iterators, and also set-like behavior. But I don't see any comments in the PEP about why indexing was rejected, but it's implicit in the fact that dicts were explicitly unordered at the time that PEP was written. I'm sorry, I don't think that logic holds water. Dicts at the time were explicitly unordered (and I still mostly find it more useful to think of them as unordered), but iterators are explicitly ordered. You probably couldn't rely on that order being consistent if you fiddled with the dict between iterations, but that's not behaviour we encourage with list-handling either. Don't get me wrong, if it's not going to cause performance issues I think being able to index views would be great, but I don't think this is the right way to justify it. If anyone who knows could comment on the feasibility, that would be great too :-) -- Rhodri James *-* Kynesim Ltd ___ 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/5ZZ2MNP3YEJDXBCSJVTPJN4KTA64HKAO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On 29/06/2020 18:42, Stestagg wrote: Several times now, I've had the need to 'just get any key/value' from a large dictionary. I usually try first to run `var.keys()[0]` only to be told that I'm not allowed to do this, and instead have to ask python to make a copy of this datastructure with a different type, just so I can perform the index operation. This is possible, but seems redundant, and reinforces bad practices around creating copies of potentially large structures. You can do >>> first_key = next(iter(my_dict.keys())) but I agree, it's not a particularly obvious way to proceed. -- Rhodri James *-* Kynesim Ltd ___ 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/NVLX4W4CUN3M2GY256VCAPPNNDKIH2MF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")
On 23/06/2020 15:12, Ricky Teachey wrote: On Tue, Jun 23, 2020 at 9:08 AM Mathew Elman wrote: Well there you go, good point. I didn't really like it being an operator myself. But I can see having a math.tolerance class being useful. On Tue, 23 Jun 2020 at 13:53, Jonathan Goble wrote: On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman wrote: Perhaps a more versatile operator would be to introduce a +- operator that would return an object with an __eq__ method that checks for equality in the tolerance i.e a == b +- 0.5 This is already valid syntax, because unary minus is a thing. So this is currently parsed as "a == b + (-0.5)". Reversing it to use -+ won't work because unary plus is also a thing. A little bit out of the box, but what about: a == b +/- 0.5 ...or even: a == b +or- 0.5 Is "math.isclose(a, b, abs_tol=0.5)" really so hard to use? -- Rhodri James *-* Kynesim Ltd ___ 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/JGOUZFELQYLIPGCOEVXNFSUUULQXQN6O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extend the range functionality to allow infinite ranges
On 19/06/2020 17:11, ke...@edinburghacademy.org.uk wrote: Reason: It's pretty common to see people do things where they increment a count within a while True loop, and it would be nice to have something easily available for people to use to replace this. Sorry, but I'm failing to see the use case here. Could you supply some examples? -- Rhodri James *-* Kynesim Ltd ___ 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/4EDBXQEENJKVZNRAZIET3QX6U5PODVB5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "return if "
On 17/06/2020 10:42, artem6191 wrote: So yeah, we can "if : return", but why not? Because without a decent reason otherwise, status quo ante wins. When I was writing a lot of Perl, I used the " if ;" form quite a lot to start with. Partly that was the novelty of it, part was that it reads naturally in English, and part was that I was used to writing ARM assembler (and I do mean ARM, not Thumb) so applying condition codes to every line was a natural if misdirected thing to me. Once the novelty wore off, I found I only used that form when the statement needed serious thought (usually because of a regex) and the condition was an afterthought. For anything I actually cared about, I wanted the visible structuring with line breaks and all. -- Rhodri James *-* Kynesim Ltd ___ 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/C3ZE4P6X2YF5UPD7WTEF4Q3MZQZDFLKH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: EVENTFD(2) support
On 16/06/2020 06:56, doods...@gmail.com wrote: Can we implement eventfd(2) as documented here <https://man7.org/linux/man-pages/man2/eventfd.2.html>? EventFD is available on PyPI: https://pypi.org/project/eventfd/ -- Rhodri James *-* Kynesim Ltd ___ 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/FB6VRIWQUZASNFNWD5GXYWTPDQSDRRTP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Modularize Python library
On 16/06/2020 10:23, redrad...@gmail.com wrote: I think it would be desired to modularize Python library and then to provide part of standard library through PyPi It will add possibility to evolve separately run-time and standard library Uh, aren't the runtime and standard library already separate creatures? I think standard library should be as small as needed and all other functionality should be provided through PyPi It will be similar as `Rust` did ... they have pretty small `standard library` and `core library` This is absolutely contrary to Python's "batteries included" philosophy, so you are going to have to work to justify it. If Python would have small `standard library` and `core library` it would be add standardization for basic functional that should have some Python implementation ... I would have expected (and your examples show) *less* standardization, not more. -- Rhodri James *-* Kynesim Ltd ___ 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/ADNUZDDIILZ4QX4FDCTEETJHXCWCVLOV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
On 10/06/2020 16:38, Atsuo Ishimoto wrote:
Hi
Thank you for comments
2020年6月10日(水) 0:11 Rhodri James :
Python is not Perl. By that I mean Python in general tends not to use
non-alphanumeric symbols unless they already have a well established
meaning (such as quote marks, arithmetic operators and so on).
Yeah, I don't think '${...}' is appearing, too. As I wrote, it was chosen for
implementation reasons. I'm open for other syntax options.
I'm curious what you think about another way to construct dictionaries.
Personally I just accept the repetition. It doesn't generally happen
often to me, and I'd much rather be explicit.
--
Rhodri James *-* Kynesim Ltd
___
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/AOMGP7GFRYQREJVVF7ZIQCEALN2JH6MZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
On 10/06/2020 01:06, Guido van Rossum wrote: print 2+2 4 print "hello world" hello world Bearing in mind that I'm a reactionary old curmudgeon who hates change, this gets a tepid -0.5 from me. It put me in mind of Tcl. Now I don't use Tcl a lot, and mostly that's in convoluted environments driving test equipment, but I find it gets really hard to read surprisingly quickly. -- Rhodri James *-* Kynesim Ltd ___ 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/CDHCDQIYD4YQDMGMNFHDZURIQ2UL7OOS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes
On 09/06/2020 19:04, Vinay Sharma wrote: The main reason why I requested this enhancement was to ensure that multiple processes can read/write a shared memory segment without corrupting that data in it. To ensure the same shared semaphores came to mind. Each shared memory segment, can have a corresponding shared semaphore. Yes, that's a perfectly good plan. I don't think using named pipes would be a good way to ensure the same. Although, if you think otherwise please suggest so. I understand, I was asking people in general if separately from your particular use case we might want to consider other shared primatives. I can think of other use cases where cross-process pipes, mutexes and so on could be useful. -- Rhodri James *-* Kynesim Ltd ___ 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/CAYNZSQ5X52O4TZYX5DYXRJCNJNUMHK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes
On 09/06/2020 17:16, Vinay Sharma wrote: Hi, I posted this here because a core Developer (Tal Einat), asked me to, although I am not sure what is the protocol from here. Does this enhancement request look reasonable ? If yes, I would love to open a PR. If not, any suggestions, feedback is very welcome. I've been thinking about this for a couple of days now, and I think for what little it's worth my answer is mostly yes. You're basically asking for Named Semaphores, which are a perfectly sensible thing to want for inter-program communications. I hesitate only because I'm more used to thinking about these things in terms of message-passing protocols, but that's no reason to reject your request. My only bit of bikeshedding is that they ought to be a different class to the basic Semaphore to make it clear they have a different scope. Is it worth broadening out the discussion to other sorts of named objects? Named Pipes particularly spring to my mind... -- Rhodri James *-* Kynesim Ltd ___ 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/FGOSCCHMCL6W5REF7JARMLOI44D4ULQI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
Hi there!
This request is a close cousin of the recent discussion about optional
keywords arguments, which you can find in the archives at
https://mail.python.org/archives/list/python-ideas@python.org/thread/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/
A lot of the same comments for and against apply here. I'll just
cherry-pick a specific point:
On 09/06/2020 14:45, Atsuo Ishimoto wrote:
How about adding similar syntax to Python? Like raw strings, we can
add prefix letters such as '$' to the opening curly brace for the
purpose.
d = ${first, last, addr1, addr2, tel='123-456-789'}
Python is not Perl. By that I mean Python in general tends not to use
non-alphanumeric symbols unless they already have a well established
meaning (such as quote marks, arithmetic operators and so on). "${...}"
definitely does not have such a meaning; a newcomer looking at the above
would not have a lot of guidance as to what might be going on, and could
be forgiven for thinking they were looking at some weird form of set.
--
Rhodri James *-* Kynesim Ltd
___
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/YY7LF6WND7VENMVNNU7GC4OTICPJDYKH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes
On 05/06/2020 18:56, Jonathan Fine wrote: Hi Rhodri wrote: Again, these are statements. I can take a guess at what Vinay wants, but since that involves a rather large worm can I'd rather they actually stated it outright. I'm puzzled. Reading https://bugs.python.org/issue38035, to me it seems that Ned Deily, Ido Michael and Tal Einat all understood Vinay's request well enough to suggest a way forward, a way to provide what Vinay wants. However Rhodri is able only to guess what Vinay wants. I suggest Rhodri and I bow out of this discussion for now, and allow Vinay to clarify, and others to contribute, if they wish. Since what I have asked for is for Vinay to clarify what is wanted, that involves no effort on my part :-) -- Rhodri James *-* Kynesim Ltd ___ 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/JLOTRRJ4R5TMM4ZAJYNVCRMZFXTRX6BV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes
On 05/06/2020 17:47, Jonathan Fine wrote: Hi Rhodri wrote: These are very nice statements. What is you actually want? Good question. Vinay provide a link to the issue he opened. In his opening message he wrote: This behaviour works well when the file descriptors of these semaphores can be shared with children processes. But, it doesn't work when an unrelated process which needs access to shared semaphore tries to open it. Again, these are statements. I can take a guess at what Vinay wants, but since that involves a rather large worm can I'd rather they actually stated it outright. -- Rhodri James *-* Kynesim Ltd ___ 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/RKAYECAYMITBPFR3LJEFLBXTOWIWAYO6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes
On 05/06/2020 16:18, Vinay Sharma via Python-ideas wrote: Python has integrated shared memory into standard library starting from 3.8 (https://docs.python.org/3/library/multiprocessing.shared_memory.html <https://docs.python.org/3/library/multiprocessing.shared_memory.html>), which provides a user friendly API to access shared memory across unrelated processes using names. But, there are no synchronisation mechanisms present in the standard library to prevent race conditions when shared memory is accessed across unrelated processes. I had earlier created an enhancement issue <https://bugs.python.org/issue38035> at bugs.python.org <http://bug.python.org/>, which contains more detailed discussion on the same. I am posting this here after a suggestion from a Python contributor. These are very nice statements. What is you actually want? -- Rhodri James *-* Kynesim Ltd ___ 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/3W55CNZVIYSPUDVXE46WU4Y6LAVCW6Q4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 29/05/2020 18:02, David Mertz wrote: I think this is a perfect example of where my desired "delayed" (or "deferred") construct would be great. There are lots of behaviors that I have not thought through, and do not specify here. But for example: def foo(a=17, b=42,, x=delayed randint(0,9), y=delayed randrange(1,100)): if something: # The simple case is realizing a direct delayed val = concretize x elif something_else: # This line creates a call graph, not a computation z = ((y + 3) * x)**10 # Still call graph land w = a / z # Only now do computation (and decide randoms) val = concretize w - b I do not find this particularly ugly, and I think the intent is pretty clear. I chose two relatively long words, but some sort of shorter punctuation would be possible, but less intuitive to my mind. Presumably "delayed" is something that would be automatically applied to the actual parameter given, otherwise your call graphs might or might not actually be call graphs depending on how the function was called. What happens if I call "foo(y=0)" for instance? There's some risk that this will introduce a brand new gotcha, "You forgot to concretize your delayed parameter". I'm not agin it per se, but I'd need to understand the value of it better I think. Also, I'm pretty sure the average programmer will find the current if x is None: x = randint(0,9) a lot easier to understand. -- Rhodri James *-* Kynesim Ltd ___ 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/WEAF5BHXHSO55V55ES2C4KWF6UO3T3FJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python __main__ function
On 28/05/2020 21:05, tritium-l...@sdamon.com wrote: People write main entry points that are not exactly this? If __name__ == '__main__': sys.exit(main(sys.argv[1:])) Mostly I don't write main entry points at all. If I do the dance, it's more likely to be: if __name__ == '__main__': test_this_module_to_destruction() ...though personally I prefer separate scripts for testing. For the main program, I'm generally using argparse so there's no need to mess with sys.argv directly, and why on earth would I add complexity and indentation with an entirely unnecessary function wrapper? -- Rhodri James *-* Kynesim Ltd ___ 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/3ZY6X3GKGXGCQQMYMNOPRAMV5CWIBPMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python GIL Thoughts
On 26/05/2020 02:42, Steven D'Aprano wrote: On Mon, May 25, 2020 at 11:11:14AM -,redrad...@gmail.com wrote: We just need to provide two APIs: 1) Synchronized: `run`, `run_string`, that will wait until thread notify with setting `atomic variable` in true that it finished 2) Asynchronized (based on async): `run_async`, `run_string_async`, event_loop will wait on `atomic variable` reading it periodically Whenever somebody says "we just need", the word "just" can hide a huge amount of work. Oh dear Lord yes! As a consultant programmer, I am forever pointing out to clients that the answer to any question beginning "Can you just...?" is "No." It is never "just". Never. -- Rhodri James *-* Kynesim Ltd ___ 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/TB6WI5YPTIPPC2MBDIZBQXBUPRQWDQMI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 22/05/2020 20:40, Steven D'Aprano wrote: Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, sPAm. Or worse, SPΑM, SPАM and SPAM. Randall is way ahead of you. https://xkcd.com/2309/ :-) -- Rhodri James *-* Kynesim Ltd ___ 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/RD26H7FMPTKUAYZWG6DJRLVG2SIMNJEU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 22/05/2020 18:21, Mike Miller wrote: More importantly, does it help readability? I think it does, however not strongly. I'm perhaps +0.5 on a few of these characters. Word processors do upgrades to hyphens, for example, to make the resulting doc more readable. Is that kind of thing useful for Python? Generally speaking, no. Editors that do things for you behind your back are an open invitation to bugs. I find that for most word processing that I do, I have to turn off the automatic translation/correction/whatever to prevent them from incorrectly rewriting my input. Prettifying code so that it no longer runs when you cut and paste is one example; more often I find they mangle the capitalisation of company names, product ID and so forth. I would hate to find an editor starting to do similar things for me. Sometimes even basic things like "electric modes" (auto-indentation after you hit RETURN) can make more work for you! -- Rhodri James *-* Kynesim Ltd ___ 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/SICQPMANE6YBDRAHVYGIWF4KXQZ7U4ZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 22/05/2020 02:10, Tiago Illipronti Girardi wrote: Is `?=` an operator? One could define `a ?= b` as `if a is None: a = b` (which is similar to make's operator, for example). PEP 505 (https://www.python.org/dev/peps/pep-0505/) prefers "??=". That's a discussion that comes back now and again, but doesn't seem to get much traction one way or another. -- Rhodri James *-* Kynesim Ltd ___ 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/3DPYXLZ7HOZMEWN6WBOENBQSFZDUPHJN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 21/05/2020 22:11, Mike Miller wrote: The only thing I've seen recently that doesn't is the Linux console, which I use rarely for admin tasks. (Oddly enough, it does handle right arrow properly.) Guess what I use. In conjunction with Emacs, of course :-/ -- Rhodri James *-* Kynesim Ltd ___ 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/NLU7RE4TX5CIFHTVA54LVE6QZCCAHU5I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 21/05/2020 15:29, Thierry Parmentelat wrote:
On 21/05/2020 15:09, Thierry Parmentelat wrote:
clearly the experienced Python programmers are not the main target here
our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and
this is Europe, not China, so...
You say that, but it is a source of endless annoyance to me that the Linux UK
Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my
colleague François quite a pain :-/
Yeah well, if the whole english-speaking keyboard industry shares the feelings
expressed on this thread, it’s no wonder ;-)
I suggest you take a look at the US-international (not sure there is a
UK-international) input method,
that I think is available on all 3 OSes in one form or another, and that is
cool for that sort of things
(the keyboard I am using right now is a regular qwerty keyboard with no alt-gr
modifier)
and the other way around I can assure you that coding with a regular French
keyboard - the infamous AZERTY thingy - is something you don’t want to have to
do; you’d need alt-gr to enter a mere { - and digits come through shift- !
Oh, I have had to use AZERTY, while I was on holiday in Quebec. I quite
agree!
--
Rhodri James *-* Kynesim Ltd
___
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/ZSXRVR46BEZFWQVEKRPYRGJ6IFIAO25N/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 21/05/2020 15:09, Thierry Parmentelat wrote: clearly the experienced Python programmers are not the main target here our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and this is Europe, not China, so... You say that, but it is a source of endless annoyance to me that the Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla. It makes addressing my colleague François quite a pain :-/ -- Rhodri James *-* Kynesim Ltd ___ 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/OG7NLD4NRUMRZGEV7RBJEZ4GFL4M7B2F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 21/05/2020 13:24, Chris Angelico wrote: On Thu, May 21, 2020 at 9:58 PM Rhodri James wrote: On 20/05/2020 23:20, James Lu wrote: There's a thirty year tradition of doing that because there's no terser way to do it. Terser does not mean better. In my experience, terser code is often harder to comprehend, particularly when you are talking about squashing a couple of lines together like this. Except when it's more expressive. Imagine if Python didn't have ANY argument defaults, merely permitted you to make arguments optional: def int(x, ?base): if base is UNSET: base = 10 ... Would you agree that simply writing "base=10" is better? You're right that terser does not ALWAYS mean better, but "more expressive" often compasses both better and terser. Terser definitely does not mean worse. True, and I was careful to say "often" rather than "always". My point is that James' argument appears to be solely that what he proposes is terser. -- Rhodri James *-* Kynesim Ltd ___ 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/4Q6WIPN6B54Q4VAZJXDMM4FXS767MYNE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 20/05/2020 23:20, James Lu wrote: There's a thirty year tradition of doing that because there's no terser way to do it. Terser does not mean better. In my experience, terser code is often harder to comprehend, particularly when you are talking about squashing a couple of lines together like this. -- Rhodri James *-* Kynesim Ltd ___ 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/EK4RCKXJMFS7JCBCHKUAJGTAQ5VHHY3X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 20/05/2020 02:13, James Lu wrote: The "if arg is None: arg = " pattern occurs in the standard library eighty-five (85) times. You say that like it's a bad thing. Given that it's completely clear what's going on -- you don't need to understand or guess at the syntax -- I'm really not seeing the problem here. -- Rhodri James *-* Kynesim Ltd ___ 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/QHW6ZYGV2PC2ENM77RDRU3ERNSYBLEXB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 17/05/2020 19:43, David Mertz wrote: I believe boolean mode switches are usually a bad design for Python. Not always, there are exceptions like open(). Actually, open() is a really bad example. It does have a flag, "closefd" which if False and a file descriptor was passed in rather than a filename leaves the file descriptor open when the file object is closed. The mode parameter than most people will be thinking about really is a mode parameter, not a flag; it folds together four basic opening modes (read, write, exclusive, append), an update flag and a text/binary flag. The former universal newlines flag got separated out to be a mode parameter all its own when it turned out not to be a simple flag after all. I seem to remember that separation being somewhat painful... -- Rhodri James *-* Kynesim Ltd ___ 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/ML7BU75U6R36Y2MKDD3B4UYZWRZHAIFT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 16/05/2020 17:14, Guido van Rossum wrote: On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano wrote: * zip(strict=True) +1 * zip(mode='strict') -0 * itertools.zip_strict() -0.5 * zip.strict() -1 (but really, I'd like to make this -1e10) I spent a significant amount of time and mental energy explaining in detail why a boolean flag is a poor API and is objectively the wrong interface here. This is not just a matter of personal taste: there are reasons why a flag is wrong here. Clearly it is not the objective truth, otherwise you would have an easier way convincing everyone.:-) OK, let's put some numbers on this. We only have 9 votes in, but aside from Brandt (whose position is fairly obvious from the PEP) that includes most of the people who have expressed strong opinions one way or another. Ignoring the nuances of +/-0, we end up with: itertools.zip_strict(): +5.5 zip(strict=True): +1 zip.strict(): -1.9 zip(mode='strict'): -4 (I bet Steven is wishing he hadn't been so generous to the "strict=True" option now :-) Now I'm not fool enough to mistake a public vote for an objective truth (::looks pointedly around world politics::) but there are some interesting conclusions here. 1) Nobody (aside from Steven) wants a "mode" keyword. I suspect this is because both of the two main camps (zip(strict=True) and zip_strict()) have solid reasons against it; for the first, it's an unnecessary distraction, and for the second the existence of zip_longest() argues against it. 2) People don't hate zip.strict() as much as I had expected. 3) The PEP needs to come up with an actual argument against itertools.zip_strict(). The current dismissal ain't going to cut it. -- Rhodri James *-* Kynesim Ltd ___ 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/N4QLALMOLUWHYFSLKEONJ7UYF2YBQY4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding slice Iterator to Sequences
On 14/05/2020 19:56, Andrew Barnert wrote: On May 14, 2020, at 10:45, Rhodri James wrote: On 14/05/2020 17:47, Andrew Barnert via Python-ideas wrote: Which is exactly why Christopher said from the start of this thread, and everyone else has agreed at every step of the way, that we can’t change the default behavior of slicing, we have to instead add some new way to specifically ask for something different. Erm, did someone actually ask for something different? As far as I can tell the original thread OP was asking for islice-maker objects, which don't require the behaviour of slicing to change at all. Quite where the demand for slice views has come from I'm not at all clear. That doesn’t make any difference here. If you want slicing sequences to return iterators rather than copies, that would break way too much code, so it’s not going to happen. A different method/property/class/function that gives you iterators would be fine. We already have such. It's called itertools.islice(). I'm sorry, but you're missing the point here. You and Christopher seem to be having fun discussing this at great length, and that's fine. However at this point I've not grasped the proposal and I've lost the will to even contemplate the details. What I have grasped is that no one else has offered much opinion, so saying that "everyone else has agreed at every step of the way" doesn't actually have the weight it pretends to. -- Rhodri James *-* Kynesim Ltd ___ 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/M4NU47MCXQSNZPDP24VLTMLEWOVO3ULX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)
On 14/05/2020 17:47, Andrew Barnert via Python-ideas wrote: Which is exactly why Christopher said from the start of this thread, and everyone else has agreed at every step of the way, that we can’t change the default behavior of slicing, we have to instead add some new way to specifically ask for something different. Erm, did someone actually ask for something different? As far as I can tell the original thread OP was asking for islice-maker objects, which don't require the behaviour of slicing to change at all. Quite where the demand for slice views has come from I'm not at all clear. -- Rhodri James *-* Kynesim Ltd ___ 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/JHBSBYVEF27GANMTQWIARUUTOASNNPUU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making asserts non-recoverable.
On 14/05/2020 03:54, Greg Ewing wrote: On 14/05/20 8:55 am, Richard Damon wrote: On 5/13/20 2:03 PM, Rhodri James wrote: I'm sorry, but I think the correct response is to give them a spanking in code review. I certainly wouldn't pass any code that actually relied on assert doing anything. My thought was he just needs to add that case to the unit tests. This person seems to be a new team member who doesn't have the power to force the others to do anything against their will. So suggestions like this aren't going to help him. Actually I have failed things on review having only been employed by a company for two weeks, one of which was pre-booked holiday. That wasn't a case of trying to bust a bad coding standard, to be fair. -- Rhodri James *-* Kynesim Ltd ___ 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/GTOT7UMNY7SQSBZ2NPDLW4DTG2OUT5OJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making asserts non-recoverable.
On 13/05/2020 17:20, chris.the.develope...@gmail.com wrote: I'm working with developers that have decided to use asserts every time they want to throw an exception. I feel that their should be something that dissuades this behavior in the language design. I'm sorry, but I think the correct response is to give them a spanking in code review. I certainly wouldn't pass any code that actually relied on assert doing anything. -- Rhodri James *-* Kynesim Ltd ___ 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/GAXWCH5P4A4GP725L55BTVXGKZV4KLHL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Making asserts non-recoverable.
On 13/05/2020 15:22, chris.the.develope...@gmail.com wrote: How adverse would you guys feel about a change to the way asserts are handled so that they are not recoverable? Asserts could latch on to the first failed assert and always throw an AssertionError on subsequent assert statements. Another way would be for subsequent asserts to turn off after the first failure. As long as developers keep the contract that asserts should never fail, they wont notice this change; and it blocks developers from writing code that is dependent on asserts. I'm sorry, I don't see the use case. Unless by "writing code that is dependent on asserts" you mean something I'm going to disapprove of strongly :-) -- Rhodri James *-* Kynesim Ltd ___ 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/SPATIIQ3UUKNWFZKNCLLBCYHLMQAMKLA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 07/05/2020 10:11, Steven D'Aprano wrote: On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote: Currently, when comparing a list of items to an array of the same items for equality (==) it returns False, I'm thinking that it would make sense to return True in that context, as we're comparing item values and we have the same way of indexing both collections, so we can compare item values. I'm going to throw out a wild idea (actually not that wild :-) that I'm sure people will hate for reasons I shall mention afterwards. Perhaps we ought to add a second "equals" operator? The biggest argument against a second "equals" operator, however it is spelt, is confusion. Which of these two operators do I want to use for this subtly different question of equality? Even where we have quite distinct concepts like "==" and "is", people still get muddled. If we have "==" and "=OMG=" or whatever, that would just be an accident waiting to happen. Cheers, Rhodri -- Rhodri James *-* Kynesim Ltd ___ 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/A2WS4OAVFIROJ5T5WPVCS2XK2IZEWEVU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 21:03, Christopher Barker wrote: "If its builtin people will be more likely to use it, so we need to make it builtin." This argument will apply to **literally** every function and class in the standard library. But we are not talking adding a new builtin. Well, actually we are. As Steven pointed out further down the post, adding a flag to a function that is pretty much always going to be set at compile time is equivalent to (and IMHO would be better expressed as) a new function. -- Rhodri James *-* Kynesim Ltd ___ 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/YU3TQ7XP5YM2NSUDWV2MUPJY7VLA3OVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 17:26, Henk-Jaap Wagenaar wrote: This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools. It is not about breaking backwards compatibility (presumably by making it the default behaviour of zip). Except that that's part of the thinking involved in choosing a flag instead of the usual new function. No one (I think) is claiming that we should break backwards compatibility and default to strict=True, but having the flag is a strong statement that length-checking is an intrinsic part of zipping. I don't believe that's true, and in consequence I think adding a flag is a mistake. -- Rhodri James *-* Kynesim Ltd ___ 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/5GURR7YTHRY43KSM5LW7U665KGR24MUA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: Brandt's example with ast in the stdlib I think is a pretty good example of this. On Tue, 5 May 2020 at 13:27, Rhodri James wrote: On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true. I'm sorry, I don't buy it. This isn't an edge case, it's all about whether you care about what your input is. In that sense, it's exactly like the relationship between zip and zip_longest. Interesting, because I'd call it a counterexample to your point. The bug's authors should have cared about their input, but didn't. -- Rhodri James *-* Kynesim Ltd ___ 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/OBJAU2776PJ5MAYUPNNHP6ZAVV53BC7E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true. I'm sorry, I don't buy it. This isn't an edge case, it's all about whether you care about what your input is. In that sense, it's exactly like the relationship between zip and zip_longest. -- Rhodri James *-* Kynesim Ltd ___ 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/U47NZNW5DIZLW34UTNEFYQ3ZCRW57EMU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip
On 04/05/2020 15:02, Alex Hall wrote: ...top-posted stuff in response to jdve...@gmail.com, who had bottom posted. Guys, I know I'm not going to persuade either of you of the fundamental truth that posting interleaved replies is best, but if you're going to post at opposite ends of the chain of argument could you at least trim the middle out? -- Rhodri James *-* Kynesim Ltd ___ 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/L7PAIX4DOGCW6EL52F4GGPRAKS7SWTG5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip
On 01/05/2020 19:10, Brandt Bucher wrote: I have pushed a first draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP! Not sure whether you class this as new, but I think your Rationale section misses the point. The rest of the document appears to divide uses of zip into those playing with infinite iterators, for which the current behaviour of zip() is just fine and "strict=True" would be an error, those where the program logic expects the finite inputs to be the same length for which "strict=True" is protection against meddling :-), and a relatively small number of cases that don't care for which "strict=True" may not even be a useful debugging tool. In other words, from context the programmer should always know whether he always wants "strict=True" or "strict=False". That functionality switch is the smell, and I don't think you convincingly deal with it. -- Rhodri James *-* Kynesim Ltd ___ 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/MHY5OAY2RXSDYO5RX36LF6F67GRUAK57/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Introduce 100 more built-in exceptions
On 01/05/2020 07:48, Ram Rachum wrote: There are 2 reasons I want this: 1. When I'm writing a try..except clause, I want to catch a specific exception like MissingArgumentsError rather than ValueError or TypeError. They're too ubiquitous. I don't want some other unexpected failure producing the same ValueError and triggering my except clause. If you want to catch MissingArgumentsError, you're doing something really weird. I'm trying to think of a realistic example and failing. 2. When I get an error, especially from some shitty corporate system that truncates the traceback, I want to get as many hints as possible about what went wrong. Then you should read the exception reason. You're still going to have to think about what your program logic error is, and a separate exception is going to be less use than an explanatory text string. -- Rhodri James *-* Kynesim Ltd ___ 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/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: deque: Allow efficient operations
On 29/04/2020 20:54, Andrew Barnert via Python-ideas wrote: On Apr 29, 2020, at 12:03, Christopher Barker wrote: Isn't much demand for a*generic* linked list. It would probably be a good recipe though -- so users could have a starting point for their custom version. I think what would be really handy would be a HOWTO on linked lists that showed the different options and tradeoffs and how to implement and use at least a few different ones, and showed why they’re useful with examples. (And also showed why the Sequence/Iterable API can be helpful but also why it’s not sufficient.) Isn't the point that you should be approaching a datastructure in Python thinking about what you want it to do, not how it's implemented underneath? That sort of micromanagement smacks of premature optimisation. -- Rhodri James *-* Kynesim Ltd ___ 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/X4FQMNUQLVVHPCCA7VGACO4NA4YZLLXJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
On 28/04/2020 23:58, Andrew Barnert via Python-ideas wrote: Really, we either need descriptors that can somehow work for globals and class attributes (which is probably not solveable), or some brand new language semantics that aren’t built on what’s already there. The latter sounds like probably way more work than this feature deserves, but maybe the experience of Swift argues otherwise. Or you can do it up front, once you have the information to do it with. There aren't that many occasions when lazy evaluation actually wins you anything much; basically when you have moderately expensive information that you may not need at all but will use a lot if you do need it. -- Rhodri James *-* Kynesim Ltd ___ 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/3ATLHCE557B4UA2OUXBAZZSZ5SCJFCY5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 28/04/2020 15:46, Brandt Bucher wrote: Thanks for weighing in, everybody. Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP. With that in mind, I've started drafting one summarizing the discussion that took place here, and arguing for the addition of a boolean flag to the `zip` constructor. Antoine Pitrou has agreed to sponsor, and I've chatted with another core developer who shares my view that such a flag wouldn't violate Python's existing design philosophies. I'll be watching this thread, and should have a draft posted to the list for feedback this week. -1 on the flag. I'd be happy to have a separate zip_strict() (however you spell it), but behaviour switches just smell wrong. -- Rhodri James *-* Kynesim Ltd ___ 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/BZUJUTAVOHJEUZ6QEIRZWZHKCRXE6AAS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 27/04/2020 21:39, Christopher Barker wrote: To me, having a zip_equal that iterates through the inputs on demand, and checks when one is exhausted, rather than pre-determining the lengths ahead of time will solve almost all (or all? I can't think of an example where it wouldn't) use cases Except for those cases where either the whole dataset needs to be processed or none of it, which is what people were thinking might be behind some of the desire for zip_equal(). That you can't do it in the general case would be a later "well, bugger" stage of the design :-) -- Rhodri James *-* Kynesim Ltd ___ 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/GWU3KENHAM6BAU3W6ARNM5UZQTX2JZLA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 21/04/2020 15:29, Chris Angelico wrote: On Wed, Apr 22, 2020 at 12:06 AM Eric V. Smith wrote: That's a good example, Chris. Thanks. I also don't see that a namespace object would buy you much, if anything. Going with the tersest proposal (twitter=twitter becomes twitter=), we'd save something like 40 characters in the function call in the return statement. I think making a change isn't worth adding more to the language, but of course reasonable people can disagree. Thanks. But it's really not about terseness. I've already typed more in this thread than I'll probably save over a lifetime of shorthanding. If I wanted shorthands, I'd just use shorter variable names. Removing duplication removes the possibility of desynchronization. Now here's the heart of things. We're actually talking about synchronization, which in this case happens to be done by using the same name in different contexts. Sometimes this is a good thing, sometimes not; calling it an anti-pattern is harsh, but it does channel your thinking into tramlines that are not always a good thing. The number of times I've changed "handle=handle" to "handle=medium_handle" as projects have crept... -- Rhodri James *-* Kynesim Ltd ___ 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/PKYEYO4R375FAORMWQMZQWPSULT2BMHE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: list.append(x) could return x
On 20/04/2020 16:57, Christopher Barker wrote: It is a standard convention in Python that mutating methods return None. While that does make chaining operations harder (impossible), it is a consistent convention that makes it much harder to get confused about whether a method mutates or not. It is not going to change. See previous threads about a “fluent” interface for discussion about the concept. I think you may have made the same mistake I initially did. The OP isn't asking for the mutated list to be returned, they are asking for the object added. Which pretty much proves my point about it being really unexpected ;-) On Mon, Apr 20, 2020 at 8:42 AM J. Pic wrote: Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example: something = mylist.append(Something()) What do you think ? Thanks in advance for your replies -- ∞ -- Rhodri James *-* Kynesim Ltd ___ 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/MSUVIKEZQMQQWBDVW7CEVT43V5CVQ65G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: list.append(x) could return x
On 20/04/2020 16:25, J. Pic wrote: Hi all, Currently, list.append(x) mutates the list and returns None. It would be a little syntactic sugar to return x, for example: something = mylist.append(Something()) What do you think ? I'm generally opposed to trying to do too many things on one line; the more you pile in, the more chance it will be misunderstood. In this case, why would the average naive user expect that your new Something is what's going to be returned? The usual request is to have (the mutated) `mylist` returned (which we don't do for reasons), and that's what people are going to expect. -- Rhodri James *-* Kynesim Ltd ___ 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/GUU6CJI6M642HKLVF5Y7ZTBQV5QRCHMR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 19/04/2020 17:06, Alex Hall wrote: function(*, dunder, invert, private, meta, ignorecase) No reader will ever have to think about the difference. They will simply see the second version and know which arguments are being passed. I seem to be immune to this magical knowledge. Sorry, what? How is there any doubt that the arguments being passed are dunder, invert, private, meta, and ignorecase? They're right there. Oh, so that's what you meant. But how is this different from function(dunder, invert, private, meta, ignorecase) if you trust yourself to get the argument order right, or function(dunder=dunder, invert=invert, private=private, meta=meta, ignorecase=ignorecase) if you don't? I still don't get why you think that last form is a problem. Now, which parameters those arguments are bound to is less obvious, but: 1. When you read the function call, you're thinking about the arguments, not the parameters. You can see which information goes into the function, and the first question you should ask yourself is 'is that the right information?'. Bitter experience has taught me to think about both the arguments and the parameters. You can't answer the question "is that the right information?" until you know what the right information is. 2. Even if you have no idea what the parameters of the function are, you can already reasonably guess that they match the argument names, and that guess is correct! If you have some idea what the parameter names are, you can be more confident in that guess. Or, if you didn't know the parameter names, but you know what the `**` separator means, now you know the names. All I can say is that I doubt I would make that association. I certainly don't when similar things come up in function definitions. 3. You probably only start to think about parameter binding when you open up the function definition, and when you do that, binding is still probably not the first thing you look at. You're probably thinking about what the function does in the body. Well, no, that's not how I work at all. 4. If there are just a few arguments, you're less likely to miss or ignore the `**`. True. But on the other hand, you have less excuse not to be explicit about which names are bound to which. 5. If there are many arguments, you're less likely to notice any mismatch between argument and parameter positions that might falsely make you think something is wrong. That is, you're less likely to either remember the parameter order or to go through the trouble of inspecting and comparing the orders. In my experience, the more arguments there are, the more likely it is that something has been got wrong, so I'm actually more likely to go to the trouble of inspecting and comparing the orders. Maybe I'm paranoid, but I've caught enough bugs that way to feel justified in my paranoia. 6. If you're thinking about parameter binding and argument order, you're inspecting the arguments at least somewhat closely, and will almost certainly notice that the `**` is present. If you know what it means, problem solved. If you don't, you're at least likely to think about it and try looking it up or ask someone. It takes a very specific kind of skepticism/suspicion to think "the previous programmer messed up the argument order so these parameters are definitely bound wrong, and also that weird `**` that I don't know the meaning of has no bearing on that, and I'm not going to check with a print() or a debugger". If I have to go away and look some syntax up, that syntax has slowed me down. This doesn't seem like a win to me. -- Rhodri James *-* Kynesim Ltd ___ 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/ZHP2YUFULMD53GAWN2D4QRNXPEAUQH33/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 17/04/2020 19:21, Andrew Barnert via Python-ideas wrote:
On Apr 17, 2020, at 01:58, Steven D'Aprano wrote:
On Thu, Apr 16, 2020 at 09:21:05PM -0700, Andrew Barnert via Python-ideas
wrote:
But I don’t see why that rules out the “bare colon” form that I and
someone else apparently both proposed in separate sub threads of this
thread:
{ :a, "b": x, :c }
as shorthand for:
{ "a": a, "b": x, "c": c }
I did a double-take reading that, because I visually parsed it as:
{ :a,
"b":
x, :c
}
and couldn't work out what was going on.
After saving this draft, closing the email, then reopening it, I read
the proposed dict the same way. So I don't think it was just a momentary
glitch.
I honestly think, as you suggested at the end, that this may be just you.
You’ve had similar reactions to other syntax that nobody else replicated, and I
think that’s happening again here.
It's not just Steven. After dusting my monitor to remove flyspecs, I
still couldn't find a natural way of reading that example. I didn't
visually parse it quite the same, but the excess of punctuation still
encourage me to completely miss the '"b": x' part being a unit.
--
Rhodri James *-* Kynesim Ltd
___
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/7UU4MDSHLYFZ6UEDJBEZU4POL6QGGY45/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 17/04/2020 11:37, Alex Hall wrote:
On Fri, Apr 17, 2020 at 11:57 AM Steven D'Aprano
wrote:
On Fri, Apr 17, 2020 at 11:25:15AM +0200, Alex Hall wrote:
You look at the function call and you can see a bunch of
names being passed to self.do_something. If the function call has
'keyword=keyword' in it instead of just 'keyword', that's not adding much
information.
Of course it adds important information! It is adding the critical
information: which parameter gets assigned the specified value.
Of course it's adding some information, but it's not information a reader
usually has to think about.
Uh, it's information that as a reader I consider critical.
Readers don't generally have to compare two similar looking pieces of code.
If they do, it's generally in a conversation with someone
(e.g. when reviewing a PR) and they can ask that person what the asterisk
means.
So "What's the difference between these two calls?" is not usually a
relevant question.
Actually if the difference is only a couple of characters, it is
relevant. In another thread, it was pointed out that having both
get_default() and get_defaults() methods on a class was asking for
comedy moments (well, comedy from everyone else's point of view).
Similarly, if you look at "f(*, x)", don't understand the star or
otherwise slide over it and consequently make mistaken assumptions about
what x is, well, it matters quite a lot.
The technical details of how an argument is being passed are
usually not important to readers.
I don't care about the argument passing implementation. I care about the
meaning of the code. Here is a real-world case:
open('example.txt', encoding, newline, errors, mode)
open('example.txt', *, encoding, newline, errors, mode)
Would you agree that the two of those have *radically* different
meanings? The first will, if you are lucky, fail immediately; the second
may succeed. But to the poor unfortunate reader who doesn't know what
the star does, the difference is puzzling.
This holds even more strongly if the various parameters take the same
type:
# a real signature from one of my functions
def function(
meta:bool,
dunder:bool,
private:bool,
ignorecase:bool,
invert:bool)
function(dunder, invert, private, meta, ignorecase)
function(*, dunder, invert, private, meta, ignorecase)
No reader will ever have to think about the difference. They will simply
see the second version and know which arguments are being passed.
I seem to be immune to this magical knowledge.
Also, your examples are clearly demonstrating that using the shortcut makes
it easier to avoid mistakes.
It shows that using positional parameters makes it easier to make
mistakes, but that's not news.
--
Rhodri James *-* Kynesim Ltd
___
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/Q7WMBFTRF5QY6UEAGSM73KLEEY5JNQTJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 17/04/2020 04:04, Steven D'Aprano wrote: I know what it means in function definitions, but somehow we seem to have (accidentally?) flipped from talking about Rhodi's dislike of the `*` in function *definitions* to an (imaginary? proposed?) use of `*` in function *calls*. Have I missed something? Someone was proposing using '*' to mean "the following are keyword parameters, take their values from variables of the same name", citing the use of '*' in function definitions as looking nice and being obvious in meaning. I was disputing both points. We do seem to have got off-track somewhat ;-) -- Rhodri James *-* Kynesim Ltd ___ 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/JH7T4JHSD2AVWQPUPQAB224KWRLKWJOP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 16/04/2020 17:57, oliveira.rodrig...@gmail.com wrote: @StevenDAprano and this goes for @RhodriJames , thank you for sharing your point of view. Indeed the proposed syntax is obscure and would not be that readable for beginners. Couldn't we work around this so? The concept is still good for me just the syntax that is obscure, maybe something like this would work: ```python # '*' character delimits that subsequent passed parameters will be passed # as keyword arguments with the same name of the variables used self.do_something(positional, *, keyword) # this would be equivalent to: self.do_something(positional, keyword=keyword) ``` I believe this is readable even if you don't know Python: `positional` and `keyword` are being passed as parameters, the `*` character is mysterious at first but so it is in `def foo(a, *, b)` and it doesn't get into the way of basic readability. I beg to differ. I do find "def foo(a, *, b)" gets in the way of readability. -- Rhodri James *-* Kynesim Ltd ___ 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/7R2G2377ANMGPFOSF75PUTB535LNRAE6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Keyword arguments self-assignment
On 16/04/2020 16:23, oliveira.rodrig...@gmail.com wrote: I'm opening this thread to discuss and collect feedback on a language change to support keyword arguments to be self-assigned using variables names. Proposal Taking the syntax from [bpo-36817](https://bugs.python.org/issue36817) which just [made it to Python 3.8](https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging) the `=` syntax would be valid and have the the same effect as `=`, so these two statements would be equivalent: ```python foo(bar=bar, qux=qux) foo(bar=, qux=) ``` I wasn't in favour of the original proposal, and that at least had the excuse of just being for debugging. Imagine how much less I am enthused by this. Explicit is better than implicit. -- Rhodri James *-* Kynesim Ltd ___ 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/RCTOW4XFIUI2TYNIELMTIZG73F5WAUP7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Range of Indexes
On 10/04/2020 20:31, Chamoun Saoma wrote: This will be a simple to use and very readable way of creating ranges of indexes. I hope for this to become a new pythogenic way of writing code, especially because using range(leng(x)) is so essential when implementing various algorithms. Since the introduction of enumerate() lo! these many moons ago, I find I almost never write range(len(x)) as a loop iterable. -- Rhodri James *-* Kynesim Ltd ___ 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/KJYTJEKKWHVPBYRTWF43YOUDZQKY2NCL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Exception spaces
On 10/04/2020 12:43, Soni L. wrote: it's actually fairly common to deal with KeyError instead of using dict.get or w/e. KeyError is also raised when your code has a bug and your assumptions got broken. it's fairly easy to get the two different KeyErrors mixed up, at least. So don't do that, then. -- Rhodri James *-* Kynesim Ltd ___ 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/GQFXZECN6ZTQLIPHB3RPNWVUP3V4BRCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternative to iterator unpacking that wraps iterator-produced ValueError
[Muchly snipped] On 09/04/2020 12:27, Soni L. wrote: To put it simple, unpacking raises ValueError: But if the iterator raises ValueError, there's no way to tell it apart from the unpacking: I don't see how this is any different from any other case when you get the same exception for different errors. If for some reason you really care, subclass ValueError to make a finer-grained exception. And the workaround for this is a bit ugly. We already convert e.g. StopIteration into RuntimeError in many cases, why can't we do so here too? Surely the correct "workaround" is not to do the thing that raises the exception? -- Rhodri James *-* Kynesim Ltd ___ 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/JIOFUZPUDWZJRLNXIYVAWVHT4XDXQMAF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)
On 02/04/2020 22:24, Paul Sokolovsky wrote: Hello, On Wed, 1 Apr 2020 21:25:46 -0400 Kyle Stanley wrote: Paul Sokolovsky wrote: Roughly speaking, the answer would be about the same in idea as answers to the following questions: [snip] I would say the difference between this proposal so far and the ones listed are that they emphasized concrete, real-world examples from Well, but those are "done" changes which were backed by official PEPs (except for unary+ which hopefully was there forever). While I kinda tried to flex my arms in what it would make to write a PEP-like text, it certainly nowhere there after me spending a couple of hours on it, and collecting more evidence would take more time. I think you may misunderstand. Before they were "done" changes, the changes you listed (aside from unary +) justified being done by reference to concrete, real-world examples that would be improved by them. That's been lacking to the extent that it sounds like what you're really saying is "I want to program $LANGUAGE in Python." Since that's almost always a mistake, you've actually driven me from +0 to -0.5 on the subject! -- Rhodri James *-* Kynesim Ltd ___ 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/ETFKOTYNQZ26NT2EO236PUX73YISQE7T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language
On 01/04/2020 19:07, MRAB wrote: On 2020-04-01 18:20, Andrew Barnert via Python-ideas wrote: On Mar 31, 2020, at 20:03, Greg Ewing wrote: On 1/04/20 7:08 am, Serhiy Storchaka wrote: 31.03.20 20:52, Antoine Pitrou пише: Your search is incomplete, for example you failed to account for occurrences of "cheese" and "milkshake". Should we deprecate the word "wheel" as well, since it's a reference to cheese? If the Cheese Shop doesn’t actually have any cheese in stock, is it actually offensive to cows? You're assuming that cheese can be made only from cow's milk. It can also be made from goat's milk. Typical pro-bovine/anti-caprid bias! :-) Ewe are forgetting to separate your sheep from your goats. -- Rhodri James *-* Kynesim Ltd ___ 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/C3QCQXXQGWMQVKGGKZHPOCQIKPGOXVMD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: About python3 on windows
On 24/03/2020 01:13, Oleg Broytman wrote: On Tue, Mar 24, 2020 at 11:30:38AM +1100, Steven D'Aprano wrote: Fred is explicitly asking about the problem with having to sometimes use python and sometimes python3, and your answer is to tell him to sometimes use python and sometimes use python3? Once for every venv created, not once for every script being run. I'm afraid the terseness of your answer didn't make it at all clear how creating venvs would solve Fred's problems. It still isn't obvious to me! Fred is discussing the problems he is having with distribution and deployment, not development. IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users. For most circumstances, that is not a practical answer. Creating wheels or frozen binaries are subjects that most Python programmers know little about and care less about. Expecting someone to learn how to wield the packaging system just to do internal distribution is unrealistic. Also, where is it said that distributing wheels or frozen binaries is best practice? I wasn't aware of any such statement, and indeed have seen frozen binaries discouraged in the past. -- Rhodri James *-* Kynesim Ltd ___ 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/BCNNWCBU4VXGDEDU3HL5QGOAUHX5XRP4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: prefix/suffix for bytes
On 11/03/2020 18:45, Stephen J. Turnbull wrote: Rhodri James writes: > We've headed off down the rabbit-hole of filenames for > justification here, but surely pathlib is the correct tool if you > are going to be chopping up filenames and path names? This isn't obvious to me. The majority of people (among those for whom my respect is "very high" or better) who hate Python 3 are people who spend much of their effort on byteslinging applications (Twisted and Mercurial come immediately to mind). I don't know if *they* think these APIs would be more useful than pathlib for them, but it's not obvious to me the APIs are *not* useful. I'm thinking of things like RFC 822-like headers, URI schemes, REST endpoints, yada yada yada. We should ask *them*. (By "we" I mean the proponents of the new APIs.) That's fair. I don't deal with bytes in a way that prefixing or suffixing is any use for. I think even in the cgi module all the hairy parsing gets done elsewhere. I'm more concerned with how the original discussion seems to have obsessed about wanting prefix/suffix trimming to deal with filenames without seeming to have considered whether it's actually the right answer. > It already gives us OS-specific behaviour and the sort of > partitioning of name elements that seem to be 90% of what people > are asking for. I tend to agree, but I don't know what the byteslingers want/need, because I'm a text-oriented kinda guy. Maybe you know better, if you're a byteslinger, I'll take your word for it. I still think we should ask some of the folks I mentioned above. I'm not that sort of byteslinger, but I'm completely prepared to believe they exist in numbers! -- Rhodri James *-* Kynesim Ltd ___ 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/6XNHB23LJXM4JQQVYNKIK764SHOIYG4P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: prefix/suffix for bytes
On 10/03/2020 20:18, Christopher Barker wrote: ...much about file naming in theory and practice under Unix, concluding with: But bytes has a pretty full set of "string like" methods now, so I suppose it makes sense to add a couple new ones that are related to ones that are already there. I disagree. We've headed off down the rabbit-hole of filenames for justification here, but surely pathlib is the correct tool if you are going to be chopping up filenames and path names? It already gives us OS-specific behaviour and the sort of partitioning of name elements that seem to be 90% of what people are asking for. -- Rhodri James *-* Kynesim Ltd ___ 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/23S7XXR4BXOLTBFSBRS7274G6BJEMZ3C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: prefix/suffix for bytes
On 10/03/2020 14:58, David Mertz wrote: Most real-world UNIX systems only support ASCII-compatible encodings. There's no reason not to solve the problem on such systems by using os.fsdecode(). Huh?! Is my Ubuntu derivative not "real world"? 666-tmp % uname -a Linux popkdm 5.3.0-7629-generic #31~1581628825~19.10~f90b7d5-Ubuntu SMP Fri Feb 14 19:56:45 UTC x86_64 x86_64 x86_64 GNU/Linux 667-tmp % touch ✗—Not-ASCII 668-tmp % ls ✗* ✗—Not-ASCII 672-tmp % ls ✗* | hexdump -C e2 9c 97 e2 80 94 4e 6f 74 2d 41 53 43 49 49 0a |..Not-ASCII.| 0010 Yes, but it is ASCII-compatible; ASCII characters are encoded as their 7-bit ASCII values. I'm not sure this is a particularly useful observation, mind you. -- Rhodri James *-* Kynesim Ltd ___ 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/CXUW4IJHLPLSKBVCSXE6MCYUHYTOIW5I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Non-blocking concurrent.futures ThreadPoolExecutor
On 09/03/2020 17:50, Remy NOEL wrote: I ran into a problem which, according to a google search is not that uncommon: concurrent.futures ThreadPoolExecutor, installs an exit handler preventing program exit if any of the jobs it is running is blocked. (Which might be a surprising behaviour to someone using those). It is possible to workaround this problem by either unregistering the exit handler concurrent.futures.thread._python_exit or by subclassing the threadpoolExecutor and overriding the _adjust_thread_count method with one that does not register its threads queues. Both seems kinda ugly though. Well, yes. The non-ugly thing would be to make sure your threads are well behaved ;-) -- Rhodri James *-* Kynesim Ltd ___ 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/375RETCU5EG37VFO5GL6CHTYFWFRXYTR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
On 24/02/2020 21:07, Alex Hall wrote: This response honestly seems to ignore most of the paragraph that it's responding to. It being a sharp distinction doesn't matter because consistency isn't axiomatically valuable. Actually I think it is. Or more precisely, I think inconsistency is axiomatically has negative value. An inconsistency breaks your expectation of how a language works. Each inconsistency creates a special case that you simply have to learn in order to use the language. The more inconsistencies you have, the more of those exceptions you have to know, and the harder the language is to learn. Just consider how hard English is to learn as an adult, and notice just how much of the language is inconsistency after inconsistency. -- Rhodri James *-* Kynesim Ltd ___ 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/5ZIK4ESPNPX2YL4MNGGMNIFE56YIHCAP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
On 23/02/2020 18:33, Steve Jorgensen wrote: In many ways, a string is more useful to treat as a scalar than a collection, so drilling down into collections and ending up iterating individual characters as the leaves is often 1 step too far. I think the key word here should be "sometimes". A lot of the time I do treat strings as scalars (or more often, string.split() as a sequence of scalars), but sometimes a string absolutely is a sequence of characters, and I want to be able to treat it as such. I have to admit that most of the time that I end up in trouble because of unexpectedly iterating through a string, it's my own stupid fault. Almost always I have been doing something over simplistic or wrong-headed, usually returning a string from a function when I meant to return a list of (one) string(s) instead. -- Rhodri James *-* Kynesim Ltd ___ 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/QHL5C4BE24XSPINP5WUMDBT432K3IQQY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Communication on mailing lists [was: Add a __valid_getitem_requests__ protocol]
As the instigator here, I think it's my duty to clarify my intent on a few things. On 24/02/2020 08:49, Ethan Furman wrote: On 02/23/2020 03:01 PM, Steven D'Aprano wrote: But I am part of this community, and if I'm too scared to state my opinions for fear of retaliation, then I'm not really part of the community, the supposed community values of being open and welcoming is a sham, and it's best if I find out now. I have no problems at all with you stating your mind about this, Steven. Just in case that was relevant to anyone else :-) That's pretty much what you said then. Have you not returned to that mailing list because you no longer feel like part of the community? I seem to remember saying at the time that if I'd received the message for Steven as it was stated in public, I would not show up on bended knee as a supplicant as it appeared to demand. Rhodri James wrote: -- Language, sunshine. Steven D'Aprano wrote: - What about it? Just for the record, I had no issues with Soni's language, but I do object to attempts to shame him for it. Ethan Furman wrote: -- Since when is simply drawing one's attention to something shaming? Steven explains: --- Of course drawing attention to something can often be shaming and a disguised attack: "You're fat. He's filthy. She's promiscuous. Your language is unacceptable and bad (and by implication, so are you)." Having attention drawn to your social transgression is shaming. That's why we do it: to stop people from transgressing again. To me, "shaming" also requires a certain amount of meanness or cruelty (the "attack" part), often suggested by the tone or body language of the person commenting. Hopefully we are all aware that tone is hard to achieve in the written word, especially across continents and language barriers; body language is, of course, completely absent. I did not intend meanness. I absolutely did intend rebuke; at the time Soni was one poorly worded post away from my killfile, and I had seriously considered reporting several previous posts for CoC violations. The only reason I didn't was that I was under the impression that the list admins had seen those posts and chosen not to react to them in public. To be honest, I probably wouldn't have cared about the language had Soni not been on such thin ice with me already. As Steven correctly picked up, "Sunshine", "Sunny Jim" and the like are unfriendly "polite" nicknames in British English usage. Sorry, but it didn't even occur to me that I needed to explain that. My bad. "Evening, sunshine," is the sort of thing you expect a police constable to see just ahead of "You're nicked." It does not denote any goodwill towards the subject whatsoever. Think of the US Deep South; when the "Bless your heart"s come out, you know the speaker is really angry. In fact, when I first read Rhodri's post I thought it meant something along the lines of: programming language -> pie in the sky perfection. Hence, it is possible to be too terse. Yes, definitely my bad. Sorry about that. If not, Soni's language shouldn't even be an issue and Rhodri's rebuke was unnecessary. We'll have to agree to disagree on whether Rhodri's post was a rebuke or a reminder. It was a rebuke. I felt (and still feel) that Soni's behaviour needed rebuking quite hard. This merely happened to be the point at which I could join the conversation. Compared to what I believe was deserved this was a mild rebuke, but it was definitely a rebuke. -- Rhodri James *-* Kynesim Ltd ___ 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/SJFSHFT7MIM4GATAUWGBLOR5I7J3VJMS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
On 24/02/2020 00:59, Brendan Barnwell wrote: On 2020-02-23 16:32, Guido van Rossum wrote: > Assuming that the reader is familiar with the example `Lottery ~ > Literacy + Wealth + Region` is *not* going to work. I have literally no > idea from what field that is taken or what the purpose of the example > is. Please don't expect that I can just Google it: I did, found > https://www.statsmodels.org/stable/example_formulas.html, and I still > have no idea what it's about. Sorry, perhaps I should have given a bit more explanation. As I said, "~" means "depends on". So in R, you do something like: model = some_statistical_model_function(Lottery ~ Literacy + Wealth + Region, some_data_table) [snippety snip] It's also worth noting that the tilde here isn't notation for any of the work that the statistical model does. It's just a way of writing a "formula" that relates the independent and dependent variables, but you still have to pass that formula to some function that actually runs the model. All that said, given that we can already achieve the desired precedence with parentheses, I'll reiterate that I don't think the tilde is a real blocker to doing this kind of model specification with Python expressions, so I don't think I'm in favor of this proposal as it is. This seems a lot like trying to shoehorn something in so one can write idiomatic R in Python. That on the whole sounds like a bad idea; a friend of mine use to say he could write FORTRAN in any language but no one else could read it. Wouldn't it be more pythonic (or more accurately anything-other-than-R-ic) to use an interface that was more like model = model_fn(prediction, seq_of_predictors, data_table) -- Rhodri James *-* Kynesim Ltd ___ 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/QJ4ITW6Y6UJWBB63SS2ENARGLRCBXVE5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 19/02/2020 16:55, Soni L. wrote: On 2020-02-18 5:33 p.m., Soni L. wrote: Similar to len(). Just a shitty wrapper for __valid_getitem_requests__. Correction: Just a simple wrapper for __valid_getitem_requests__. Thank you! :-) -- Rhodri James *-* Kynesim Ltd ___ 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/YDV5Q2M4Q73NCMROHMAPB45QWH3OBSF5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 19/02/2020 00:26, Steven D'Aprano wrote: On Tue, Feb 18, 2020 at 08:44:07PM +, Rhodri James wrote: Language, sunshine. What about it? Just for the record, I had no issues with Soni's language, but I do object to attempts to shame him for it. This isn't the Disney Chanel, it's been over 100 years since Victoria was Queen of England, and we're all adults here. Actually we aren't all adults here, I happen to know, but never mind. I still thought Soni's language was inappropriate and just cautioning them was appropriate. If I thought "shitty wrapper" was unacceptable, I wouldn't have bothered cautioning them and just reported the CoC breach. -- Rhodri James *-* Kynesim Ltd ___ 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/VC2ROZN7FOIOBMQJUNZDGVM3GYRR36J2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 18/02/2020 20:33, Soni L. wrote: On 2020-02-18 5:08 p.m., Rhodri James wrote: On 18/02/2020 19:43, Soni L. wrote: It'd be nice to have a __valid_getitem_requests__ protocol that, if present, yields pairs such that: for key, value in items(obj): assert obj[key] == value for any obj. OK, I'll bite. What is this "items()" function you apply to the arbitrary object? Similar to len(). Just a shitty wrapper for __valid_getitem_requests__. Language, sunshine. Do you have a use case for this, or is it just theoretically nice to have? I have to say it isn't nice enough for me to actually want it, and I say that as someone who regularly forgets that iterating over a dict gets you its keys. -- Rhodri James *-* Kynesim Ltd ___ 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/3W4UBUL6QTONUZN2XFSVAPVKZTHO62PU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 18/02/2020 19:43, Soni L. wrote: It'd be nice to have a __valid_getitem_requests__ protocol that, if present, yields pairs such that: for key, value in items(obj): assert obj[key] == value for any obj. OK, I'll bite. What is this "items()" function you apply to the arbitrary object? -- Rhodri James *-* Kynesim Ltd ___ 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/XFDXBFSDQC6BELVFHKPLQEZ5ERBRO545/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: CSV Dictwriter - Handling escape characters
On 12/02/2020 08:15, allu.matikai...@hotmail.com wrote: Hi, I would like if the DictWriter would be able to write escape characters (\n and \r and their combinations such as \n\n\n and \r\n) as literal characters. At the moment, DictWriter writes \n:s as new lines (shown in notepad or Excel) and I would like it to just write "\n" characters in my csv file. I asked a question about this on Stack Overflow but have had no good answers yet. My question also has an example of the data and its form. https://stackoverflow.com/questions/60073809/python-how-to-write-literal-n-and-r-characters-to-a-csv-file-with-dictwriter I think my advice would be a variation on "Don't do that!" If you can massage your data into the right format before you try writing it, that would be preferable to having DictWriter mangle your strings in what is essentially an arbitrary way. -- Rhodri James *-* Kynesim Ltd ___ 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/WPQ3EFCD4N7ZO5ZU54WN5W6JK7VM2VTS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: addition of "nameof" operator
On 22/01/2020 12:03, Anders Hovmöller wrote: He was pretty clear in saying he wanted the same thing as in C#. That no one in this thread seems to have looked that up is really not his fault in my opinion. Oh, plenty of people have looked it up. The problem is that it relies on part of the nature of C# (variables are lvalues) that simply isn't true in Python, which I don't think the OP realised. -- Rhodri James *-* Kynesim Ltd ___ 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/YA6THD7VW7CP64IPDB4AVH3YUE5YYG4X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing Zipapp
On 08/01/2020 18:08, many people wrote lots of stuff... Folks, could we pick one list and have the discussion there, rather than on both python-list and python-ideas? Getting *four* copies of Andrew's emails is a tad distracting :-) -- Rhodri James *-* Kynesim Ltd ___ 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/KX7WDNYX347NOCNYQXQFRPCQ3OX3XCWN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Archiving Threads / Closing Threads
On 04/12/2019 12:44, Abdur-Rahmaan Janhangeer wrote: Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Wed, 4 Dec 2019, 15:16 Rhodri James, wrote: Which is a problem because...? -- Rhodri James *-* Kynesim Ltd An advantage. If the topic goes round several times, the mods closing the topic freezes the thread so that the thread does not gets filled with unnecessary details. Python threads are bit like a plane from Paris bound for London via direct flight but which sometimes detours through Tokyo and Manilla. In fact you might ask yourself HOW in the world are you in São Paulo. I'm sorry, I misunderstood what you said. I thought that you were complaining that its too easy to dig threads (and misunderstood what "digging threads" meant to you). You're actually complaining about the opposite; that it's too hard to mine threads for information. Sorry, but that's true of any conversation. If you want information out of a thread, you are going to have to put in the work of reading and comprehending it. The only way around that is to get a technical PA to read and comprehend it for you and produce a summary. Sometimes someone is inspired to do that, and a FAQ appears. Mostly you're on your own. Closing down threads isn't going to help. It may reduce the clutter that the solitary piece of information you are interested in is buried under, but it also increases the chance that the information isn't there at all. More to the point, it isn't going to make the thread any less convoluted. Another advantage of the proposed idea might be to make programmers more responsible by writing what is necessary and as in depth as possible. Um. I've sat on and chaired a lot of committees in my time, with a lot of different rules of engagement. I have not seen any approach to discussion that has made anyone be more responsible, succinct or accurate. Attempting to curtail discussion usually has the opposite effect, and puts everyone in a bad mood for the next item as well. -- Rhodri James *-* Kynesim Ltd ___ 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/XYNEDB2JP4QK3AYUA6ML2Q44P5DJ2AHA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Archiving Threads / Closing Threads
On 04/12/2019 03:50, Abdur-Rahmaan Janhangeer wrote: Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Wed, 4 Dec 2019, 07:38 Steven D'Aprano, wrote: What problem are you trying to solve? Are we suffering under a burden of pople resurrecting old threads from ten years ago, or even a year ago? Easy digging of threads. Which is a problem because...? -- Rhodri James *-* Kynesim Ltd ___ 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/YQPZ6E6NQ4MZPRQ7FUTH2ZAHNM3USB36/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Renaming json.load()
On 29/11/2019 10:45, Abdur-Rahmaan Janhangeer wrote: One of them can maybe be deprectated json.load() for file: json.load(file=) Ew ew ew ew ew! No thanks, I'd like my string parser to remain *clearly different* from my file parser. json.loads() is just fine, please don't mess with it. -- Rhodri James *-* Kynesim Ltd ___ 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/VFSJXHABH25A23OVTNDSPMYY2YIQ3P2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Renaming json.load()
On 29/11/2019 13:36, Abdur-Rahmaan Janhangeer wrote: >> = Chris Angelico -1 on renaming. -1 on deprecating. -1 on creating an unnecessary alias. Maybe if the change's a breaking one, we might wait for a breaking event to sneak this one in. Or we could accept that it is what it is. I'm with Chris: -1 on making life complicated. -- Rhodri James *-* Kynesim Ltd ___ 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/R47ZCGD2UXVCE4F72XVD6FF5UGAKTEN2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 20/11/2019 15:28, Richard Damon wrote: On Nov 20, 2019, at 7:50 AM, Rhodri James wrote: As context managers, yes, lazy managers make chaining them easier because there's no mess to clean up if the chain breaks while you are creating it. On the other hand, eager managers like open() can be used outside a "with" statement and still manage resources perfectly well for a lot of cases. It a matter of fitness for different purposes, so even "preferable" is a relative term here. >> To my mind, eager context managers nest just fine, if you put each into their own context. What it seems the lazy managers let you do is squish multiple context managers into a single context, but then you get the question of which of them actually is providing the context that you are in? This is just semantics. Other people have meant by "nest" what you and I meant by "squish" and "chain" respectively. Once squished, all of the context managers are providing/contributing to the context you are in, which is a new and different context all its own. We could write an explicit squisher class now, but syntactical help for an implicit squisher would be nice. -- Rhodri James *-* Kynesim Ltd ___ 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/LD5FWIITE4GRWTQW26CMRKEBDYYVQCMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 20/11/2019 01:57, Oscar Benjamin wrote: On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote: On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin wrote: If I was to propose anything here it would not be to disallow anything that you can currently do with context managers. Rather the suggestion would be to: 1. Clearly define what a well-behaved context manager is. 2. Add convenient utilities for working with well behaved context managers. 3. Add well-behaved alternatives for open and maybe others. 4. Add Random832's utility for adapting misbehaving context managers. That sounds reasonable, with one proviso. I would *strongly* object to calling context managers that conform to the new expectations "well behaved", and by contrast implying that those that don't are somehow "misbehaving". File objects have been considered as perfectly acceptable context managers since the first introduction of context managers (so have locks, and zipfile objects, which might also fall foul of the new requirements). Suddenly deeming them as "misbehaving" is unreasonable. Perhaps a less emotive way of distinguishing these classes of context managers would be as "eager" vs "lazy". An eager context manager jumps the gun and does whatever needs undoing or following up before its __enter__ method is called. A lazy context manager waits until __enter__ is called before committing itself. I don't really want to give a sense of equality between eager and lazy though. To me it is clear that lazy context managers are preferable. As context managers, yes, lazy managers make chaining them easier because there's no mess to clean up if the chain breaks while you are creating it. On the other hand, eager managers like open() can be used outside a "with" statement and still manage resources perfectly well for a lot of cases. It a matter of fitness for different purposes, so even "preferable" is a relative term here. -- Rhodri James *-* Kynesim Ltd ___ 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/32AJYVUDU4WCTDKDX46OSQZLER3MCXFK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type
On 20/11/2019 08:25, Stephen J. Turnbull wrote: Rob Cliffe via Python-ideas writes: > I (and no doubt others) am less likely to engage with a thread if I > have to spend more time than necessary trying to understand it. You write as if that's a bad thing.;-) I consider that I often make the largest contribution to this list by reading more posts and stifling the impulse to reply to any of them.:-) YMMV, of course. You used YMMV with malice aforethought, didn't you? :-) -- Rhodri James *-* Kynesim Ltd ___ 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/Y7RB24XVJAQTTF3R6G7JSJGXI4XSVO2T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 19/11/2019 17:57, Andrew Barnert wrote:
On Nov 19, 2019, at 09:40, Rhodri James wrote:
How about using Paths as file context managers? Just an idle thought.
Then how do you open a Path for writing, or in binary mode, etc.?
With additional parameters and/or methods, obviously.
Adding a Path.opening method that returns an file-on-enter context manager
instead of a file would probably work.
Yes, that might work better. Something like:
p1 = pathlib.Path("foo/bar/wombat.baz")
with p1.opened_as("wb") as outfile:
do_stuff(outfile)
But is that better than an opening function that takes a Path (or any of the
other valid arguments to open) as its first argument?
To-may-to, to-mah-to. Personally I think it is better, because users
won't be so quick to think "oh, that's a file" and try to use it
directly. And no, I don't think that trying to open the file on the
first attempt to read or write would be at all a good idea!
--
Rhodri James *-* Kynesim Ltd
___
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/Z2LE2MIVL22EKK3BZOKHIGAOSG7YTQQS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 19/11/2019 17:50, Soni L. wrote:
On 2019-11-19 3:37 p.m., Rhodri James wrote:
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my
packages, stdio-mgr (https://github.com/bskinn/stdio-mgr), with a
dramatically expanded API and capabilities.
Context managers feature heavily in the planned design; part of the
design plan is to allow instantiation of a StdioManager object prior
to entering a context, so that the user can tweak settings on the
resulting object beforehand:
cm = StdioManager()
cm.setting = True
cm.other_setting = False
with cm:
{do stuff with stdio managed}
If this paradigm holds, we will *specifically* be exploiting the
distinction between __init__ and __enter__.
-42 to abolishing __enter__.
I concur. Logically the problem that people are complaining about is
that we use open() as the context manager rather than a class that
defers the actual file open to __enter__(). That's fixable by writing
your own wrapper class, but having a builtin file context manager that
deferred resource-consuming actions would be a Good Thing™
How about using Paths as file context managers? Just an idle thought.
I still feel like opening the file but delaying the exception would be
more beneficial and have better semantics. It allows cd, mv, rm, etc to
happen without any surprising semantics, and fits the model you want it
to fit.
It really doesn't.
In my experience, lying to the user (or the compiler, or whatever) is
very rarely a good idea. Either the file is open or it isn't, and
finding out half a mile of text away from where the error actually
occurred that it isn't doesn't give you much opportunity to fix things.
As to the expected semantics of cd, mv, rm etc, I wouldn't expect those
to work on an open file at all, and I wouldn't be sure what happened if
they did.
--
Rhodri James *-* Kynesim Ltd
___
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/VULBH5OKWCXI74KT5PDQ26MPY7XTDNDV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my packages,
stdio-mgr (https://github.com/bskinn/stdio-mgr), with a dramatically expanded
API and capabilities.
Context managers feature heavily in the planned design; part of the design plan
is to allow instantiation of a StdioManager object prior to entering a context,
so that the user can tweak settings on the resulting object beforehand:
cm = StdioManager()
cm.setting = True
cm.other_setting = False
with cm:
{do stuff with stdio managed}
If this paradigm holds, we will *specifically* be exploiting the distinction
between __init__ and __enter__.
-42 to abolishing __enter__.
I concur. Logically the problem that people are complaining about is
that we use open() as the context manager rather than a class that
defers the actual file open to __enter__(). That's fixable by writing
your own wrapper class, but having a builtin file context manager that
deferred resource-consuming actions would be a Good Thing™
How about using Paths as file context managers? Just an idle thought.
--
Rhodri James *-* Kynesim Ltd
___
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/BJYEZRVTFDYAHROFY3ULSPFRXBII7IGH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make itertools recipes license easier
On 29/10/2019 22:47, Guido van Rossum wrote: On Tue, Oct 29, 2019 at 3:37 PM Todd wrote: I think you might be mixing up two different things. First is the text of the Pytjon-2.0 license. I don't want to change that, or the text of any other license. Second is the LICENSE file. That file includes the text of the Python-2.0 license, the text of every other license used in the project, the history licenses, and some other brief information. This is what I am suggesting we edit. That may be how it's used in other projects, but in Python, even that file is carefully crafted by lawyers whom I don't want to wake up, despite it being nearly 20 years later. Numquam titillandum advocatus dormiens? -- Rhodri James *-* Kynesim Ltd ___ 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/UW5GLBJ3CB6EFUUTVECNBTGUE7N6I5Q7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On 24/10/2019 11:33, Steven D'Aprano wrote: On Wed, Oct 23, 2019 at 06:01:06PM +0100, Rhodri James wrote: The proposed: %w[red green blue] says that this is something, good luck figuring out what. You don't need *luck* to figure out what it does, you need five seconds in the REPL. One of the most annoying tendencies on this mailing list is for people who dislike a feature to play dumb. Sigh. You may have noticed that I was being slightly flip in all my descriptions, mostly to point up the different levels of cognitive load imposed by them. The fact is, %w[...] doesn't look like anything else Python does, and it's seeking to replace an absolutely bog-standard literal. I prefer to let my editor do the work, actually. [...] and then write a quick editor macro to add the quotes and comma Great. And how about those who cannot just "write a quick editor macro" which works perfectly first time? If writing out a list of words in Python source code is so painful that you prefer to write a macro, that's a fantastic argument in favour of this new syntax! Honestly, it's not that painful. You were the one contending that it was painful, I was demonstrating a method of avoiding the pain (that I use more out of laziness) that didn't put the load on the compiler every single time I run the script. People who can't just write editor macros have a few choices. Obviously they can learn how to write macros for their editor (and honestly, Emacs keyboard macros are pretty literally "monkey see, monkey do"). They can write the quotes and commas themselves, which isn't much more boring that writing the text in between the quotes. Or they can write a long string escaping any spaces perfectly first time, and split it. I think the strongest argument against both this proposal and the habit of using split() is that everyone looking at your example string of colours, including you and me, missed "forest green" the first time round. -- Rhodri James *-* Kynesim Ltd ___ 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/SBJWF6HWHNNDPK276X5QRBCJNJ2V4VLC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On 23/10/2019 16:16, Steven D'Aprano wrote: On Wed, Oct 23, 2019 at 03:16:51PM +0100, Rhodri James wrote: I'm seriously not getting the issue people have with colours1 = ["red", "green", "blue"] which has the advantage of saying what it means. As opposed to the alternatives, which say something different from what they mean? Well, yes. ["red", "green", "blue"] says that this is a list of strings. End of. "red green blue".split() says that this is a string that is now -- ta dah! -- a list of strings. Nothing up my sleeves. No, don't clap, just throw money. It's only a little bit of extra cognitive load in this case, but then you start meeting corner cases like wanting spaces in your strings and it stops being nearly so little. The proposed: %w[red green blue] says that this is something, good luck figuring out what. If you know, it's only a little more cognitive load, but again gets messier as you get into the corner cases, as you've been demonstrating. If you don't know, looking it up is not going to be easy. Wherever possible, we should let the interpreter or compiler do the repetitive stuff. I prefer to let my editor do the work, actually. When I have had to do long lists of strings (or anything, really) like this, I mostly type it in as: NOTIONAL_CONSTANT = [ red blue green burnt umber burnt cake really long name with lots of spaces in it and so on and so on ] and then write a quick editor macro to add the quotes and comma and tab into a more beautiful (and syntactically correct) form. Not much more trouble than typing it all in as an escaped string, and no extra runtime loading either. The result is immediately readable source, which I consider a major win. -- Rhodri James *-* Kynesim Ltd ___ 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/2UJPTFEJLLUPLC552BOH7PBXQ7FXNVMY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On 23/10/2019 15:09, David Mertz wrote: One big problem with the current obvious way would be shared by the proposal. This hits me fairly often. colors1 = "red green blue".split() # happy Later colors2 = "cyan forest green burnt umber".split() # oops, not what I wanted, quote each separately I'm seriously not getting the issue people have with colours1 = ["red", "green", "blue"] which has the advantage of saying what it means. -- Rhodri James *-* Kynesim Ltd ___ 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/SHGLAOIVC32AR5F2TWKNHNI7WGLTNME7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 23/10/2019 05:41, Steven D'Aprano wrote: On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote: On 2019-10-18 10:23, Ricky Teachey wrote: but i'm -0 because i am very concerned it will not be obvious to new learners, without constantly looking it up, whether adding two mappings together would either: The big trade off I'm gathering from this mega-thread is that the |, |= operators are more accurate, but less obvious to newcomers, who will first try +, += instead. I'm surprised by that description. I don't think it is just newcomers who either suggest or prefer plus over pipe, and I don't think that pipe is "more accurate". +1 (as one of the non-newcomers who prefers plus) -- Rhodri James *-* Kynesim Ltd ___ 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/KTZTMR3YM2YPFHXZ64N66WVZ6ZF4ARCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On 22/10/2019 20:53, Steve Jorgensen wrote:
See
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
for what Ruby offers.
For me, the arrays are the most useful aspect.
%w{one two three}
=> ["one", "two", "three"]
This smells like Perl's quoting operators. I wasn't a big fan of them
even when I was a Perlmonger. Given the choice of "glyph doing
something" and "glyph doing something I understand", I'll take the
latter every time.
--
Rhodri James *-* Kynesim Ltd
___
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/LI6YD57LQIHVLHWOVUH6VR4HLB6LJAUM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 21/10/2019 14:54, David Mertz wrote:
On Mon, Oct 21, 2019, 9:14 AM Rhodri James
The plus operation on two dictionaries feels far more natural as
a vectorised merge, were it to mean anything. E.g., I'd expect
{'a': 5, 'b': 4} + {'a': 3, 'b': 1}
{'a': 8, 'b': 5}
That's only a natural expectation if you also expect the values in your
dict to be addable (in the sense of doing something useful with a "+"
operator). It never occurs to me to make that assumption because a fair
amount of the time it isn't true in my code.
I'm not arguing that we SHOULD make '+' mean recursive addition. I'm just
saying that if I never read this discussion, then later read `dict1 +
dict2` in code, that's what I'd expect.
And I'm just explaining why that's not what I expect. My code at the
moment looks more like
lookup_dict[remote_id] = RemoteObject(stuff)
so the idea of adding dict values simply doesn't come to me.
--
Rhodri James *-* Kynesim Ltd
___
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/J33SQQSU7RZFZZZCZFVIRTNURJLVMLMW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 19/10/2019 19:02, David Mertz wrote:
I am strong -1 on the proposal.
The plus operation on two dictionaries feels far more natural as a
vectorised merge, were it to mean anything. E.g., I'd expect
{'a': 5, 'b': 4} + {'a': 3, 'b': 1}
{'a': 8, 'b': 5}
That's only a natural expectation if you also expect the values in your
dict to be addable (in the sense of doing something useful with a "+"
operator). It never occurs to me to make that assumption because a fair
amount of the time it isn't true in my code.
--
Rhodri James *-* Kynesim Ltd
___
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/ACOFRBPMCUQ42LXR6SZ24P6Q5ALI4FPE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 20/10/2019 05:52, Inada Naoki wrote: I think this PEP doesn't include one big disadvantage of the + operator. If we use + for dict merging, set doesn't support + looks strange and inconsistent. As I've said before, set already looks strange and inconsistent to me. I have some hopes that after this discussion I will remember that set union is spelt "|", but thus far I've had to look it up every time. -- Rhodri James *-* Kynesim Ltd ___ 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/QKURVXOECCII4KDTJCLNLLS5J5SNIHSY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 18/10/2019 15:43, Anders Hovmöller wrote:
On 18 Oct 2019, at 15:58, Brandt Bucher wrote:
Basically the whole bottom quarter of the PEP!
https://www.python.org/dev/peps/pep-0584/#examples-of-candidates-for-the-dict-merging-operator
The examples would make more sense if the "before" picture was using modern
syntax fully. The alternative to
c = a + b
isn't the old
c = {}
c.update(a)
c.update(b)
but in fact:
c = {**a, **b}
I agree that the proposed + overload is nicer to read but the PEP isn't being
fair to the current syntax imo.
Since I think the {**a, **b} syntax is *horrible*, I think the PEP is
being more than fair! a + b is much easier to read and intuit than
{**a, **b}. The sequence of methods is clearer in meaning but more
cumbersome. All in all I think the operator is useful enough to justify
adding it.
--
Rhodri James *-* Kynesim Ltd
___
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/RXUZNXCEBHZTDDMSRUSMTOCHCN664LCB/
Code of Conduct: http://python.org/psf/codeofconduct/
