[Python-Dev] Re: PEP 572 TargetScopeError

08.08.19 20:00, Barry Warsaw пише: Rather than just a vote, if you have a rationale for one over the other, I’d love to hear it. Feel free to weigh in here or on the issue. I do not have arguments for SyntaxError but the rationale for TargetScopeError does not look strong to me. IndentationE

[Python-Dev] Re: What to do about invalid escape sequences

Steve Holden writes: > This whole thread would be an excellent justification for following 3.9 > with 4.0. It's as near as we ever want to get to a breaking change, and a > major version number would indicate the need to review. If increasing > strictness of escape code interpretation in strin

[Python-Dev] Re: PEP 572 TargetScopeError

On 8/8/2019 7:28 PM, Barry Warsaw wrote: On Aug 8, 2019, at 14:58, Steven D'Aprano wrote: It's not a syntax error. There's nothing wrong with the syntax per-say: we still have ``target := expression``. There's a problem with the *semantics* not the syntax. I’m not sure that distinction is me

[Python-Dev] Re: PEP 572 TargetScopeError

On 08/08/2019 22:58:15, Steven D'Aprano wrote: On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote: "The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same signature).” The PEP doesn’t really go into the rationale for why a new except

[Python-Dev] Re: PEP 572 TargetScopeError

On Aug 8, 2019, at 14:58, Steven D'Aprano wrote: > It's not a syntax error. There's nothing wrong with the syntax per-say: > we still have ``target := expression``. There's a problem with the > *semantics* not the syntax. I’m not sure that distinction is meaningful though. What you wrote is di

[Python-Dev] Re: PEP 572 TargetScopeError

Barry Warsaw wrote: Subclassing SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also de facto means "CompilationError” Perhaps there should be a CompilationError tghat SyntaxError and TargetScopeError are subclasses of? -- Greg

[Python-Dev] Re: PEP 572 TargetScopeError

On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote: > "The two invalid cases listed above raise TargetScopeError, a new > subclass of SyntaxError (with the same signature).” > > The PEP doesn’t really go into the rationale for why a new exception > is being defined, and in the issue I

[Python-Dev] Re: What to do about invalid escape sequences

FWIW, the web archive https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/ does not seem to display the problems ... apparently the individual messages are not included in view source, and are cleaned up for chrome's inspect. I'm not sure whether

[Python-Dev] Re: PEP 572 TargetScopeError

Barry Warsaw wrote: > The PEP doesn’t really go into the rationale for why a new exception is being > defined, > and in the issue I’ve argued that we should just raise SyntaxError in those > cases. To me, > “TargetScopeError” is pretty obscure and doesn’t give users an obvious clue > as to what

[Python-Dev] Re: PEP 572 TargetScopeError

I agree that it should be a SyntaxError as it's a semantic issue regarded to syntax. For instance, we already use SyntaxError for when a `return` statement is outside of a function and I view this as the same sort of error. And I think with an appropriately descriptive message like Ivan pointed

[Python-Dev] Re: PEP 572 TargetScopeError

On 08.08.2019 20:54, Barry Warsaw wrote: On Aug 8, 2019, at 10:41, Tim Peters wrote: Whereas SyntaxError would give no clue whatsoever, and nothing useful to search for. In contrast, a search for TargetScopeError would presumably find a precisely relevant explanation as the top hit (indeed, i

[Python-Dev] Re: Can someone please finish merging GH-13482?

Tim Peters wrote: > [Brett Cannon br...@python.org] > > We probably need to update https://devguide.python.org/committing/ > > to > > have a step-by-step list of how to make a merge works and how to > > handle backports instead of the wall of text that we have. (It's already > > outdated anyway, e.

[Python-Dev] Re: PEP 572 TargetScopeError

On Fri, Aug 9, 2019 at 4:00 AM Barry Warsaw wrote: > > On Aug 8, 2019, at 10:41, Tim Peters wrote: > > > Whereas SyntaxError would give no clue whatsoever, and nothing useful > > to search for. In contrast, a search for TargetScopeError would > > presumably find a precisely relevant explanation

[Python-Dev] Re: PEP 572 TargetScopeError

On Aug 8, 2019, at 10:41, Tim Peters wrote: > Whereas SyntaxError would give no clue whatsoever, and nothing useful > to search for. In contrast, a search for TargetScopeError would > presumably find a precisely relevant explanation as the top hit > (indeed, it already does today). > > I don't

[Python-Dev] Re: PEP 572 TargetScopeError

[Barry Warsaw ] > bpo-37757: https://bugs.python.org/issue37757 Really couldn't care less whether it's TargetScopeError or SyntaxError, but don't understand the only rationale given here for preferring the latter: > To me, “TargetScopeError” is pretty obscure and doesn’t give users an > obvious c

[Python-Dev] PEP 572 TargetScopeError

bpo-37757: https://bugs.python.org/issue37757 This issue describes some corner cases in PEP 572 (assignment expressions) syntax that haven’t been implemented yet. The PEP currently says: "The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same si

[Python-Dev] Re: typing: how to use names in result-tuples?

Yes, that's what I mean. Probably retval or whatever people prefer would be adequate, with a special rule if that name is taken. I think btw. that using StructSequence(somename=sometype, ..., ) that does a dict lookup is quite appealing. It returns a class like stat_result, but the function call s

[Python-Dev] Re: typing: how to use names in result-tuples?

On 08.08.19 17:20, Ronald Oussoren via Python-Dev wrote: > > >> On 8 Aug 2019, at 17:12, Christian Tismer > > wrote: >> >> Hi Ronald, >> >> sure, the tuple is usually not very interesting; people look it up >> once and use that info in the code. >> >> But I think thin

[Python-Dev] Re: typing: how to use names in result-tuples?

OK, yes, having a convention for naming the anonymous field sounds like the way to go. But presuming people will want to use it, and probably know it from the C++ API, why not name it 'return_value' or 'result' or 'retval' or something like that? On Thu, Aug 8, 2019 at 1:43 AM Christian Tismer wr

[Python-Dev] Re: typing: how to use names in result-tuples?

> On 8 Aug 2019, at 17:12, Christian Tismer wrote: > > Hi Ronald, > > sure, the tuple is usually not very interesting; people look it up > once and use that info in the code. > > But I think things can be made quite efficient and pretty at the > same time. Such a return tuple could be hidden

[Python-Dev] Re: typing: how to use names in result-tuples?

Hi Ronald, sure, the tuple is usually not very interesting; people look it up once and use that info in the code. But I think things can be made quite efficient and pretty at the same time. Such a return tuple could be hidden like the stat_result example that Guido mentioned: https://github.com/

[Python-Dev] Re: What to do about invalid escape sequences

On 8/5/2019 4:30 PM, raymond.hettin...@gmail.com wrote: Thanks for weighing in. I think this is an important usability discussion. IMO it is the number one issue affecting the end user experience with this release. If we could get more people to actively use the beta release, the issue wo

[Python-Dev] Re: What to do about invalid escape sequences

> When you take a text string and create a string literal to represent > it, sometimes you have to modify it to become syntactically valid. Even simpler: use r""" instead of """ The only case where that won't work is when you need actual escape sequences. But I find this very rare in practice for

[Python-Dev] Re: typing: how to use names in result-tuples?

Chrisian, How would these namedtuple/structseq values be used? I have a similar design with PyObjC: pass-by-reference “return” values are returned in a tuple, e.g.: void getpoint(pointclass* v, int* x, int *y)=>def get point(v: pointless) -> (int, int) BOOL getvalue(someclass* v

[Python-Dev] Re: What to do about invalid escape sequences

Hey friends, This is IMHO a great idea. If a package claims to be Python 3.8 compatible, then it has to be correct concerning invalid escapes. A new pip version could perhaps even refuse packages with such literals when it claims to be supporting Python 3.8 . But how can it actually happen that

[Python-Dev] Re: What to do about invalid escape sequences

These two ought to be converted to raw strings, shouldn't they? On Thu, 8 Aug 2019 at 08:04, wrote: > > For me, these warnings are continuing to arise almost daily. See two recent > examples below. In both cases, the code previously had always worked without > complaint. > > - Example fro

[Python-Dev] Re: What to do about invalid escape sequences

I feel this is one of the cases, where we're expecting early adopters to proactively post pull requests against affected libraries. Failing that opening issues against affected libraries. I was ready to do just that, but alas didn't even have to! Matt's analysis shows that it's now too hard. What

[Python-Dev] Re: typing: how to use names in result-tuples?

Hi Guido, If a C++ function already has a return value, plus some primitive pointer variables that need to be moved into the result in Python, then we have the case with a first, single unnamed field. Only one such field can exist. I'm not sure if that case exists in the ~25000 Qt5 functions, but