Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?
On 28 October 2015 at 20:05, Alexander Walters wrote: > Have you ever used a command line application that --accepted --Boolean > --flags? Have you ever found one that required the flags to be in order? > You remember how much you hated that application for being so arbitrary > about the input? Given that "f" is standing for a runtime transformation (unlike the purely declarative "b" and "r"), it makes sense to me to mentally translate it as "magic_format_call_that_needs_compiler_assistance()", so requiring the "f" to be first isn't arbitrary, it's slotting in where the function name would be for a call to a builtin. I'd also like to leave the door open to i-strings in the future, so my answer to Eric's "What would the docs say?" question is that string prefixes can contain imperative runtime flags (which appear first, are mutually exclusive, are always lowercase, and cause a runtime transformation by changing the actual code generated at compile time) and declarative compile time flags (which can appear in any order after the imperative flag, may be in upper or lower case, and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime) Currently the only imperative prefix we have is "f", while "b", "u", and "r" are available as declarative prefixes. "i" has been proposed as a second imperative prefix, but is currently deferred until 3.7 at the earliest (after we have a release worth's of experience with "f"). It's only a mild preference, but the main benefit I see is reining in the combinatorial explosion of possible string prefixes before it even has a chance to start getting out of hand. > one of the few undeniably good choices made in python 3. There's no need here for passive aggressive snark directed at the designers providing you with a free programming language. Folks have the entire internet to complain about how much they dislike our work (where we can pick and choose whose feedback we want to listen to), so we don't need to accept it here. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?
On 10/31/2015 8:48 PM, Nick Coghlan wrote: Given that "f" is standing for a runtime transformation (unlike the purely declarative "b" and "r"), it makes sense to me to mentally translate it as "magic_format_call_that_needs_compiler_assistance()", so requiring the "f" to be first isn't arbitrary, it's slotting in where the function name would be for a call to a builtin. I'd also like to leave the door open to i-strings in the future, so my answer to Eric's "What would the docs say?" question is that string prefixes can contain imperative runtime flags (which appear first, are mutually exclusive, are always lowercase, and cause a runtime transformation by changing the actual code generated at compile time) and declarative compile time flags (which can appear in any order after the imperative flag, may be in upper or lower case, I think either order for b|u versus r is ok, even though a nuisance to specify in a grammer that assumes order significance. But given that Python is case-sensitive, I think the exception here was a mistake that need not be copied. > and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime) It makes sense to me that f should be kept logically distinct from the other two. Currently the only imperative prefix we have is "f", while "b", "u", and "r" are available as declarative prefixes. "i" has been proposed as a second imperative prefix, but is currently deferred until 3.7 at the earliest (after we have a release worth's of experience with "f"). -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?
Eh. I don't see the point of arguing about the order. String literals may have one or more character prefixes that modify the meaning. Some of those prefixes may be combined; others may not. Given that we allow combining the r and b prefixes in either order, and we allow combining r and f, I don't think we should be picky about the order in which those can appear. Saying that f must come first because it has a different kind of effect (call it "runtime") doesn't make sense to me. On Sat, Oct 31, 2015 at 7:32 PM, Terry Reedy wrote: > On 10/31/2015 8:48 PM, Nick Coghlan wrote: > > Given that "f" is standing for a runtime transformation (unlike the >> purely declarative "b" and "r"), it makes sense to me to mentally >> translate it as >> "magic_format_call_that_needs_compiler_assistance(> literal>)", so requiring the "f" to be first isn't arbitrary, it's >> slotting in where the function name would be for a call to a builtin. >> >> I'd also like to leave the door open to i-strings in the future, so my >> answer to Eric's "What would the docs say?" question is that string >> prefixes can contain imperative runtime flags (which appear first, are >> mutually exclusive, are always lowercase, and cause a runtime >> transformation by changing the actual code generated at compile time) >> and declarative compile time flags (which can appear in any order >> after the imperative flag, may be in upper or lower case, >> > > I think either order for b|u versus r is ok, even though a nuisance to > specify in a grammer that assumes order significance. But given that > Python is case-sensitive, I think the exception here was a mistake that > need not be copied. > > > and only > >> cause a compile time transformation in the stored constant without >> changing the code to load that constant at runtime) >> > > It makes sense to me that f should be kept logically distinct from the > other two. > > Currently the only imperative prefix we have is "f", while "b", "u", >> and "r" are available as declarative prefixes. "i" has been proposed >> as a second imperative prefix, but is currently deferred until 3.7 at >> the earliest (after we have a release worth's of experience with "f"). >> > > -- > Terry Jan Reedy > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen
CC'ing Python-Ideas. Follow-ups to Python-Ideas please. On Thu, Oct 29, 2015 at 09:22:15PM -0400, Terry Reedy wrote: > Leaving IDLE aside, the reason '' is added to sys.path is so that people > can import their own modules. This is very useful. Shadowing is the > result of putting it at the front. I have long thought this a dubious > choice. If '' were instead appended, people could still import modules > that did not duplicate stdlib names. Anyone who wanted shadowing could > move '' to the front. But then shadowing would be intentional, not an > accident. Terry is right. Shadowing should be possible, and it should require a deliberate decision on the part of the programmer. Consider the shell, say, bash or similar. My understanding is that the shell PATH deliberately excludes the current directory because of the possibility of malicious software shadowing usual commands in /bin etc. If you want to run an executable in the current directory, you have to explicitly provide the path to it: ./myscript rather than just myscript. Now Python isn't exactly the shell, and so I'm not proposing that Python does the same thing. But surely we can agree on the following? - Shadowing explicitly installed packages, including the stdlib, is *occasionally* useful. - But when shadowing occurs, it is *nearly always* accidental. - Such accidental shadowing often causes problems. - And further more, debugging shadowing problems is sometimes tricky even for experienced coders, and almost impossible for beginners. (It's not until you've been burned once or thrice by shadowing that you recognise the symptoms, at which point it is then usually easy to debug.) - Hence, we should put the onus on those who want to shadow installed packages) to do so *explicitly*, or at least make it easier to avoid accidental shadowing. I propose the following two changes: (1) Beginning with Python 3.6, the default is that the current directory is put at the end of sys.path rather than the beginning. Instead of: >>> print(sys.path) ['', '/this', '/that', '/another'] we will have this instead: >>> print(sys.path) ['/this', '/that', '/another', ''] Those who don't shadow installed packages won't notice any difference. Scripts which deliberately or unintentionally shadow installed packages will break from this change. I don't have a problem with this. You can't fix harmful behaviour without breaking code that depends on that harmful behaviour. Additionally, I expect that those who rely on the current behaviour will be in a small minority, much fewer than those who will be bitten by accidental shadowing into the indefinite future. And if you want the old behaviour back, it is easy to do so, by changing the path before doing your imports: import sys if sys.path[-1] == "": sys.path = [""] + sys.path[:-1] or equivalent. I do not belive that it is onerous for those who want shadowing to have to take steps to do so explicitly. That can be added to your scripts on a case-by-case basis, or your PYTHONSTARTUP file, by modifying your site.py, or (I think) by putting the code into the sitecustomize or usercustomize modules. (2) IDLE doesn't need to wait for Python 3.6 to make this change. I believe that IDLE is permitted to make backwards incompatible changes in minor releases, so there is no reason why it can't change the path effective immediately. That's a simpler fix than scanning the entire path, raising warnings (which beginners won't understand and will either ignore or panic over) or other complex solutions. It may not prevent *every* shadowing incident, but it will improve the situation immeasurably. Thoughts? -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unable to submit a patch to the tracker
I'm unable to submit any file to any issue, neither via web-form nor via e-mail. Checked with different browsers from different computers. Meta-tracker doesn't work too. http://psf.upfronthosting.co.za/roundup/meta/issue575 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
