[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
On 2/6/21, Christopher Barker wrote: > On Sat, Feb 6, 2021 at 11:47 AM Eryk Sun wrote: > >> Relative to the installation, "python.cfg" should only be found in the >> same directory as the base executable, not its parent directory. > > OK, my mistake — I thought that was already the case with pyvenv.cfg. > Though I don’t get why it matters. Chiefly, I don't want to overload "pyvenv.cfg" with new behavior that's unrelated to virtual environments. I also dislike the way this file is found. If the parent directory is "C:\Program Files", then I'm not worried about finding "C:\Program Files\pyvenv.cfg" when the interpreter tries to open it. But this pattern is not safe in general when installed to an arbitrary directory, or with a portable distribution. The presence of a "._pth" file (Windows only) beside the DLL or executable bypasses the search for "pyvenv.cfg", among other things. The embedded distribution includes a ._pth that locks it down. This is another reason to use a different file to configure defaults for -X settings such as "utf8", a file that's guaranteed to always be read. >> Add an option in the installed "python.cfg" to set the name of the >> organization and application. > > That would work for, e.g. pyinstaller (which I hope already ignores these > kinds if configuration. > > But not for, e.g. web applications that expect to use virtual environments > to isolate themselves. The idea to use the profile data directories %ProgramData% and %LocalAppData% was for symmetry with how this could be supported in POSIX, which doesn't use the application directory as Windows does. The application "python.cfg" (in the directory of the executable, including a virtual environment) can support a setting to isolate it from system and user "python.cfg" files. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T42D2VDMQ7JY7WYP2W3ALFHZGUYXLPZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional with statements
Hello, On Sat, 6 Feb 2021 19:57:33 -0500 Jonathan Crall wrote: > I ran into another case where I wish I had some sort of conditional > if. Right, conditional "if" is exactly what we miss in Python. Yes, it's a typo, but it's proverbial Freudian slip, shows what stays behind such proposals - un[spell]checked desire to add some tautology to the language. > Wasting that horizontal space is not an option Reading things like this, it seems that some people just can't get at peace with Python's indentation-based syntax, and would jump in no time to an alternative syntax which allows to smack indentation. It was also said many times, that it you want some trivial variety on the existing language, pick up your favorite macro package and go ahead, coding trivial macros in trivial. -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J2AG2JN6HORTXE3KJUS7LDIFHVVPOKZU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional with statements
El dom, 7 feb 2021 a las 3:08, MRAB () escribió: > On 2021-02-07 00:57, Jonathan Crall wrote: > > > [snip] > > > > To be clear, in the proposed syntax: > > > > if [condition] with [obj]: > > [code] > > > > Would behave exactly as: > > > > if [condition]: > > with [obj]: > > [code] > > > > Is there any chance that this conditional context manager syntax might be > > considered? Does anyone but myself think this might be a good idea? > > > -1. It's not that much shorter. You wouldn't be saving much typing or > space. > TL;DR: -1 for other reasons Space saved is similar to (really not necesary, but very convenient) `elif`: 4 spaces by line. My doubts are not by space saved, instead are for convenience. Nested ifs are very common contruction and there are not much to thing about. I doubt than `with` after `if` and with same scope that `if` isn't a very improbable structure. Other thing strange about proposal is: why only with after if? What about `else` (in `if`, `for`, `while`), `elif`, `for`, `while`? And in `try`, `except`, `else`, `finally`? When is coherent an mixed `with` and when not? As programmer I wan't think too much about language, so I need consistence to get focused in resolve problems with it. If I see uncommon `with` after `if` with same scope to be convenient, the other constructions needed to coherence and consistence in language seems very very strange to need (or even think in) syntactic sugar. regards, Javi ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HLUEFZ45UN7WLGAARGWYCN7CITBGM2FX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional with statements
On 2021-02-07 00:57, Jonathan Crall wrote: [snip] To be clear, in the proposed syntax: if [condition] with [obj]: [code] Would behave exactly as: if [condition]: with [obj]: [code] Is there any chance that this conditional context manager syntax might be considered? Does anyone but myself think this might be a good idea? -1. It's not that much shorter. You wouldn't be saving much typing or space. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ASHN4HGPRJD2QEQJSCWSH7CKJKANNVX3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional with statements
I ran into another case where I wish I had some sort of conditional if.
I was writing code to cache autogenerated demodata.
import ubelt as ub
from os.path import join
import json
kwargs = {'example': 'config'}
dpath = ub.ensure_app_cache_dir('my_modname', 'demodata')
fpath = join(dpath, 'data.json')
stamp = ub.CacheStamp('demodata', depends=kwargs, dpath=dpath)
if stamp.expired():
data = {
'complicated': 'data',
'key1': 'val1',
'key2': 'val2',
'keyN': 'valN',
}
with open(fpath, 'w') as file:
json.dump(data, file)
stamp.renew()
else:
with open(fpath, 'r') as file:
data = json.load(file)
I really wish I didn't have to have that stamp.renew() at the end of the if
block. It unnecessary boilerplate --- the caching logic would all be in a
contiguous block if not for the need for this. It wastes a little bit of
vertical, which while not critical, is a consideration.
I want to focus on the context:
stamp = ub.CacheStamp('demodata', depends=kwargs, dpath=dpath)
if stamp.expired():
[code]
stamp.renew()
I could make `CacheStamp` a context manager and tell it to do it in its
`__exit__` clause, as such:
stamp = ub.CacheStamp('demodata', depends=kwargs, dpath=dpath)
if stamp.expired():
with stamp:
[code]
This removes the need for the `stamp.renew`, makes the logic contiguous,
has the same vertical space, however, it adds a TON of horizontal space
depending on the complexity of the logic. It's often beneficial to minimize
nesting and try restricting it 2 or 3 levels.
BUT if we had just a tiny bit of new syntax rules we could write something
like this:
stamp = ub.CacheStamp('demodata', depends=kwargs, dpath=dpath)
if stamp.expired() with stamp:
[code]
There are even more conservative changes, like requiring a colon before
the `with`: `if stamp.expired(): with stamp:`
I know this is just saving a line. But I use this pattern with
`ubelt.CacheStamp` and `ubelt.Cacher` frequently, and I always feel a
strong want for this syntactic sugar as I'm writing it. Wasting that
horizontal space is not an option, and I really would like the caching
logic to be contiguous.
To be clear, in the proposed syntax:
if [condition] with [obj]:
[code]
Would behave exactly as:
if [condition]:
with [obj]:
[code]
Is there any chance that this conditional context manager syntax might be
considered? Does anyone but myself think this might be a good idea?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TR2JBOMPXBCAZOKJUB67OIU27Z6FTK6G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
On 2/6/21, Christopher Barker wrote: > On Fri, Feb 5, 2021 at 12:59 PM Eryk Sun wrote: > > But why limit it to that? If there are more things to configure in an > environment-specific way — why not put it in this existing location? I'd rather not limit the capability to just virtual environments. > I'd prefer a new configuration file that sets the default values for >> -X implementation-specific options. The mechanism for finding this >> file can support virtual environments. > > Then wouldn’t that simply be two configuration files that will be treated > the same way? Relative to the installation, "python.cfg" should only be found in the same directory as the base executable, not its parent directory. If "pyvenv.cfg" is found, then it's a virtual environment, and "python.cfg" will also be looked for in the directory of "pyvenv.cfg", and supersedes settings in the base installation. > I’m still convinced that It is a bad idea to have User-wide Python > configuration like this. The fact is that different Python apps (may) need > different configurations, and environments are the way to support that. Add an option in the installed "python.cfg" to set the name of the organization and application. If not set, the organization and application respectively default to "Python" and "Python[-32]". Looking for system and user configuration would be parameterized using that name, i.e. "%ProgramData%\\\python.cfg" and "%LocalAppData%\\\python.cfg". ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TXKCDQL3JNCUG52M265LU5O7USBWO7D6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
On Fri, Feb 5, 2021 at 12:59 PM Eryk Sun wrote: > I don't like extending "pyvenv.cfg" with generic settings. This is a > file to configure a virtual environment Yes indeed. in terms of finding the > standard library and packages. But why limit it to that? If there are more things to configure in an environment-specific way — why not put it in this existing location? I'd prefer a new configuration file that sets the default values for > -X implementation-specific options. The mechanism for finding this > file can support virtual environments. Then wouldn’t that simply be two configuration files that will be treated the same way? > This is the problem that I was thinking about when I proposed using > > a py.ini like solution where the file is looked for in the users config > > folder. I think that is the %LOCALAPPDATA% folder for py.exe. I’m still convinced that It is a bad idea to have User-wide Python configuration like this. The fact is that different Python apps (may) need different configurations, and environments are the way to support that. Yes, not everyone uses virtual environments, but I see that as some people use only one environment— rather than not using environments at all. So it would be really good to have a single environment be configured the same way as multiple environments. This would also work better with conda environments, which work at a “higher” level: there could be any number of instances of, say, Python 3.9.6 - and each could potentially need a different configuration: having them all reference the same place in %LOCALAPPDATA% folder would be a mess. I know it seems like I’m advocating breaking from the standards already established outside of Python, but we need to remember that Python is not an application, it is a run-time environment that may support multiple applications. If there are standards for configuration of similar things, then we should look at those. Final point for emphasis: It would be really great if the chosen solution supported conda (and maybe other) environments well. -Chris B -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/33SZTKKHEHNFZCU57CIK7DET6SZAMDJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
If it's for the REPL, it's already there, you simply need to start the async REPL. $ python -m asyncio asyncio REPL 3.8.5 | packaged by conda-forge | (default, Sep 16 2020, 17:43:11) [Clang 10.0.1 ] on darwin Use "await" directly instead of "asyncio.run()". Type "help", "copyright", "credits" or "license" for more information. >>> import asyncio >>> await asyncio.sleep(1) >>> compile and exec have a mode to allow top-level async as well if you want it programmatically, then you can `await` your code object. -- Ma On Sat, 6 Feb 2021 at 07:43, Guido van Rossum wrote: > > The proposal is to add a default event loop that is always active. > > On Sat, Feb 6, 2021 at 06:41 wrote: >> >> I mean to be able to do something like this: >> ```python >> import asyncio >> >> await asyncio.sleep(1); >> ``` > > >> > -- > --Guido (mobile) > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ATXEJR7GYY2E3B6WGC7Y2G7NL6WWZ33L/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HWO5WJJ5HAOQC7DBLOBRE3VBRXPZL2GG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
The proposal is to add a default event loop that is always active. On Sat, Feb 6, 2021 at 06:41 wrote: > I mean to be able to do something like this: > ```python > import asyncio > > await asyncio.sleep(1); > ``` > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ATXEJR7GYY2E3B6WGC7Y2G7NL6WWZ33L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
I mean to be able to do something like this: ```python import asyncio await asyncio.sleep(1); ``` ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ED75ZXM5WSLZMIW6SXGLWBUIFJRINNQ2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Top Level Await in Python like in Deno
On Sat, Feb 06, 2021 at 10:26:23AM -, redrad...@gmail.com wrote: > Deno is JavaScript runtime that has very nice feature like Top Level > Await, I think it would be also nice to have such feature in Python, > it will make using async/await more convenient > > What do you think ? Share your ideas lets discuss ... I don't know what to think because I don't know what "top level await" means to you. Can you show an example of what it would look like, how you would use it, and *why* you would use it? Can you show a simple example of a task that would be better with top level await, and why it is better? -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LPNTX3V2HWVCYPJOGMLD7PQRQUMUGMJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Top Level Await in Python like in Deno
Hi all, Deno is JavaScript runtime that has very nice feature like Top Level Await, I think it would be also nice to have such feature in Python, it will make using async/await more convenient What do you think ? Share your ideas lets discuss ... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N2GA3CIY75TZNQ5RGKDMH7DDZNWLJNSH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: What's up with assignment expression and tuples?
On Sat, Feb 6, 2021 at 8:54 PM Paul Sokolovsky wrote: > > Hello, > > On Sat, 6 Feb 2021 17:26:00 +1100 > Chris Angelico wrote: > > > On Sat, Feb 6, 2021 at 5:21 PM Random832 > > wrote: > > > > > > While we're on the subject of assignment expression limitations, > > > I've occasionally wanted to write something like > > > > > > try: > > > return a_dict[key] > > > except KeyError: > > > return (a_dict[key] := expression to construct value) > > > > That's what the __missing__ method is for. > > That's true, but that would be an argument against PEP572 ;-). PEP 572 was never meant to replace all other ways of doing things, and __missing__ is exactly the tool for this job :) > But we live in a world where PEP572 is a reality, and people start to > look how to get the most juice out of it. Why? Just because it's there? > While triaging the issue with parallel assignments, I saw there's > already pretty long trail of elaboration of ":=" for various cases where > original implementation forced parens, which were looking weird to > human eye, e.g.: > > https://bugs.python.org/issue42316 > https://bugs.python.org/issue42374 > https://bugs.python.org/issue42381 > > My proposal is to file parallel assignment case into the same "inital > omission" department like the above. And just like the above, it seems > it would be a trivial grammar fix (I didn't run the whole testsuite on > the result yet though ;-) ). The omission was intentional, and so far, I'm not seeing a justification for reversing that decision :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UJ2GKZUS7FBYR3KDWCLC6ENVHSWGW6XZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
On 2/6/21, Inada Naoki wrote: > > If adding option to pyvenv.cfg is not make sense, we can add > `python.ini` to same place pyvenv.cfg. i.e., directory containing > python.exe, or one above directory. I'd rather look for "python.cfg" in the directory of the base executable (e.g. "C:\Program Files\Python310") and then in the directory of "pyvenv.cfg", if the latter is found. I wouldn't want it to check for "python.cfg" in the parent directory of the base executable. > And no need for all installations, and per-user setting. > Environment variable is that already. A configuration file in a profile data directory can target a particular version, such as "%LocalAppData%\Python\Python310-32\python.cfg". This is more flexible for the user to override a system installation, compared to setting PYTHONUTF8. However, it's not a major issue if you don't want to support the extra flexibility. That said, supporting %ProgramData% and %LocalAppData% data directories is more consistent with how this feature would be implemented in POSIX, such as "/etc/python3.10/python.cfg" and "$HOME/.config/python310/python.cfg". I think that matters because this file would be a good place to set defaults for all -X options (e.g. "utf8", "pycache_prefix", "faulthandler"). ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3QGOQTRJTHQPQ5MQ2URCKKYBKASMAEH2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: What's up with assignment expression and tuples?
Hello, On Sat, 6 Feb 2021 17:26:00 +1100 Chris Angelico wrote: > On Sat, Feb 6, 2021 at 5:21 PM Random832 > wrote: > > > > While we're on the subject of assignment expression limitations, > > I've occasionally wanted to write something like > > > > try: > > return a_dict[key] > > except KeyError: > > return (a_dict[key] := expression to construct value) > > That's what the __missing__ method is for. That's true, but that would be an argument against PEP572 ;-). But we live in a world where PEP572 is a reality, and people start to look how to get the most juice out of it. While triaging the issue with parallel assignments, I saw there's already pretty long trail of elaboration of ":=" for various cases where original implementation forced parens, which were looking weird to human eye, e.g.: https://bugs.python.org/issue42316 https://bugs.python.org/issue42374 https://bugs.python.org/issue42381 My proposal is to file parallel assignment case into the same "inital omission" department like the above. And just like the above, it seems it would be a trivial grammar fix (I didn't run the whole testsuite on the result yet though ;-) ). An orthogonal case brought up in the above quoted message, of allowing Attribute/Subscript on LHS of the walrus, also seems legit to me, but I'm not sure about impl effort (but my guess it's again would be trivial or small, as apparently codegeneration paths are shared for "=" and ":="). > ChrisA -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JUPKPUI3GASLU3FVIHMDCSUBLTYCDF2O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: What's up with assignment expression and tuples?
Hello, On Sat, 6 Feb 2021 10:46:54 +0200 Serhiy Storchaka wrote: > 05.02.21 09:51, Paul Sokolovsky пише: > > a0 = 0 > > b0 = 10 > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > > a2 = a1 + 1 > > b2 = b1 + 1 > > Such code quickly becomes unreadable. Especially if in real code > function has additional arguments and names are longer that 2-3 > characters. But at least it fully corresponds to the original statements and control flow of the program, that's the point! > The following code is not much larger but more clear and extensible: > > a0 = 0 > b0 = 10 > while True: > a1, b1 := phi([a0, a2], [b0, b2])) > if b1 >= 5: > break > a2 = a1 + 1 > b2 = b1 + 1 As I mentioned in other replies, that's what I've been doing. But that does *NOT* correspond to the original program, or SSA conversion of it. Instead, it's SSA + random munging. And when debugging SSA, you may argue what's worse: to look at 3-stories phi's, or to look at the code structure which doesn't correspond to the input code. But that's not the point. I now in https://bugs.python.org/issue43143 gave more down to earth example: For as long as you agree that following is acceptable: func(a := val) , then I'd say it really doesn't make much sense to argue that following should not be acceptable: min((b, a) := (a, b)) -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GBEIWEZGULUXJMSNILMNUF2WGOZQA46N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: What's up with assignment expression and tuples?
Hello, On Sat, 6 Feb 2021 06:17:08 +1100 Chris Angelico wrote: > On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky > wrote: > > And looking back now, that seems like intentionally added accidental > > gap in the language (https://en.wikipedia.org/wiki/Accidental_gap). > > Similar to artificially limiting decorator syntax, which was already > > un-limited. But seems, there're no "lessons learned", and there's > > now need to wait a decade again before fixing that? > > Lesson learned: Early limitations ARE easily lifted, so it's still a > good idea to limit them until we've seen how they get used in > practice. :) Well, I wish there was also a bit of "try to make things consistent from the beginning", because "easily lifted" is a bit optimistic characterization. That said, that's meta-level thought, down to earth case is that I indeed would like to start talks on actually extending walrus syntax to accept tuple/list on LHS. I've now triaged https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid=file%3Acontent&%40search_text=walrus=search=-1%2C1%2C2%2C3 and see that the only case it was mention is https://bugs.python.org/issue42295 , which was a case of walrus precedence confusion. I thus submitted https://bugs.python.org/issue43143 for future reference. > > > The principal a.e. use in conditional expressions is testing for > > > non-nullness. Your > > > > > > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > > > >a2 = a1 + 1 > > > >b2 = b1 + 1 > > > > > > is an unusual and very specific use. > > > > Well, many people were thinking (and I bet still think) that ":=" > > itself is very unusual case. But if it's in, why not make it > > consistent with the assignment statement and unleash the full power > > of it? > > TBH I don't think I'm understanding the use-case here, I hope we understand that we go into rabbit hole of discussing a specific case, whereas I reported a general limitation, and tried to back it with more or less general example (i.e. not a once-off case, with the "SSA conversion" usecase, each and every while would be affected). With that in mind, I guess it's fine for python-ideas to discuss that particular usecase in detail. > because it > looks like it'd work just fine with fewer variables and a cleaner > rendition: > > while a1 < 5: > a1, b1 = phi([a0, a1], [b0, b1]) > a1 += 1 > b1 += 1 Let's first note that you omitted the initialization of a0 and b0 which was in my example. And with that in mind, you'll immediately see what's wrong with your code: it tries to access uninitialized a1. That's on first loop iteration. On next, it will test *old* value of a1, whereas it should test already updated value. That's why it really has to assign new values in the loop's condition expression: while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: (of course, if you're careful, you'll notice that a2, b2 are initialized on 1st iter, so assume there're initialized as: a2 = b2 = __undef__ Where __undef__ causes exception on any operation with it. ) > > Right, but I started my original email with "I finally found a > > usecase where *not* using assignment expression is *much* worse > > than using it." > > "Much worse" doesn't fit with what I would write that code as, so I > must have misunderstood your code somewhere. *My* motivation is "SSA is already pretty complex conversion, so it would be nice to avoid *additional* Python source transformations not related to SSA per se, especially if Python generic syntax now allows that". But, again, it's just an example case. I use it to illustrate an apparent gap in ":=" functionality comparing to "=", and propose to lift that restriction. > > ChrisA [] -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DQWTDLBMJH2MPY3A57XXMWJUL7IWKVKE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make UTF-8 mode more accessible for Windows users.
On Sat, Feb 6, 2021 at 5:59 AM Eryk Sun wrote: > > > I would have preferred for the py launcher to read and merge settings > for all existing configuration files in the order of > "%ProgramData%\Python\py.ini" (all installations), > "%__AppDir__%\py.ini" (particular installation), and > "%LocalAppData%\Python\py.ini" (user). Note that this is setting of python, not of py launcher. And no need for all installations, and per-user setting. Environment variable is that already. I don't want to add many way to configure one option without strong need. Currently, a per-install setting is not possible. So it is the only problem. If adding option to pyvenv.cfg is not make sense, we can add `python.ini` to same place pyvenv.cfg. i.e., directory containing python.exe, or one above directory. -- Inada Naoki ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DUM6PJDNVBCZSNHLSAVYMEUDMWVTWV5T/ Code of Conduct: http://python.org/psf/codeofconduct/
