[issue44322] Document SyntaxError args and interpretation for f-string fields

Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44322] Document SyntaxError args and interpretation for f-string fields

Terry J. Reedy added the comment: New changeset d5f8bd60e1203a41996b3ee370d6f09389070627 by Terry Jan Reedy in branch '3.9': [3.9] bpo-44322: Document more SyntaxError details. (GH-26562) https://github.com/python/cpython/commit/d5f8bd60e1203a41996b3ee370d6f09389070627 --

[issue44322] Document SyntaxError args and interpretation for f-string fields

Terry J. Reedy added the comment: New changeset 2af690fdb26d0312de056b54ddb113d3c44dee8c by Miss Islington (bot) in branch '3.10': bpo-44322: Document more SyntaxError details. (GH-26562) https://github.com/python/cpython/commit/2af690fdb26d0312de056b54ddb113d3c44dee8c --

[issue44322] Document SyntaxError args and interpretation for f-string fields

Change by Terry J. Reedy : -- pull_requests: +25160 pull_request: https://github.com/python/cpython/pull/26570 ___ Python tracker ___

[issue44322] Document SyntaxError args and interpretation for f-string fields

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +25159 pull_request: https://github.com/python/cpython/pull/26569 ___ Python tracker

[issue44322] Document SyntaxError args and interpretation for f-string fields

Terry J. Reedy added the comment: New changeset 67dfa6f2a508c325715625fe442f2ce20270a8b3 by Terry Jan Reedy in branch 'main': bpo-44322: Document more SyntaxError details. (GH-26562) https://github.com/python/cpython/commit/67dfa6f2a508c325715625fe442f2ce20270a8b3 --

[issue44322] Document SyntaxError args and interpretation for f-string fields

Change by Terry J. Reedy : -- keywords: +patch pull_requests: +25151 pull_request: https://github.com/python/cpython/pull/26562 ___ Python tracker ___

[issue44322] Document SyntaxError args and interpretation for f-string fields

--- assignee: docs@python components: Documentation messages: 395208 nosy: ammar2, docs@python, pablogsal, terry.reedy priority: normal severity: normal stage: patch review status: open title: Document SyntaxError args and interpretation for f-string fields versio

Re: Interpretation

On Sat, 26 Mar 2016 03:33 am, Dennis Ngeno wrote: > My programs have never combile, they keep telling me , systax error even > after copy pasting Dennis, if Python is complaining that you have a SyntaxError, it means you have written something which the interpreter cannot understand. We cannot

Re: Interpretation

On Sun, 27 Mar 2016 02:22 pm, Mario R. Osorio wrote: > OTOH, python code is not supposed to be compiled. Technically, Python code is compiled, to byte-code rather than machine-code, but still compiled. That's what is inside the .pyc files you will often see after importing modules. And Python

Re: Interpretation

"Mario R. Osorio" writes: > On Saturday, March 26, 2016 at 5:59:04 AM UTC-4, Dennis Ngeno wrote: > > My programs have never combile, they keep telling me , systax error even > > after copy pasting > > No pun intended, but I hope you are not typing your code like you > typed

Re: Interpretation

On Saturday, March 26, 2016 at 5:59:04 AM UTC-4, Dennis Ngeno wrote: > My programs have never combile, they keep telling me , systax error even > after copy pasting No pun intended, but I hope you are not typing your code like you typed your message. OTOH, python code is not supposed to be

Re: Interpretation

On 25/03/2016 16:33, Dennis Ngeno wrote: My programs have never combile, they keep telling me , systax error even after copy pasting Please show us your code and the exact syntax error. What Python version and OS are you using? -- My fellow Pythonistas, ask not what our language can do

Interpretation

My programs have never combile, they keep telling me , systax error even after copy pasting -- https://mail.python.org/mailman/listinfo/python-list

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

On 2013-09-26, Chris Angelico ros...@gmail.com wrote: On Thu, Sep 26, 2013 at 2:23 PM, Nils Bunger nilsbun...@gmail.com wrote: Yes, it's email.mime.MIMEApplication. I've pasted a snippet with the imports below. I'm trying to use this to build a multi-part MIME message, with this as one part.

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

Hi Neil, Thanks for looking at this. I'm trying to create a multipart MIME for an HTTP POST request, not an email. This is for a third-party API that requires a multipart POST with a binary file, so I don't have the option to just use a different encoding. Multipart HTTP is standardized

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

Hi all, I was able to workaround this problem by encoding a unique 'marker' in the binary part, then replacing the marker with the actual binary content after generating the MIME message. See my answer on Stack Overflow http://stackoverflow.com/a/19033750/526098 for the code. Thanks, your

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

Nils Bunger nilsbun...@gmail.com writes: Hi Neil, Thanks for looking at this. I'm trying to create a multipart MIME for an HTTP POST request, not an email. This is for a third-party API that requires a multipart POST with a binary file, so I don't have the option to just use a different

Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

Hi, I'm having trouble encoding a MIME message with a binary file. Newline characters are being interpreted even though the content is supposed to be binary. This is using Python 3.3.2 Small test case: app = MIMEApplication(b'Q\x0dQ', _encoder=encode_noop) b = io.BytesIO() g =

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

On Thu, Sep 26, 2013 at 2:38 AM, nilsbun...@gmail.com wrote: app = MIMEApplication(b'Q\x0dQ', _encoder=encode_noop) What is MIMEApplication? It's not a builtin, so your test case is missing an import, at least. Is this email.mime.MIMEApplication? ChrisA --

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

Chris, Thanks for answering. Yes, it's email.mime.MIMEApplication. I've pasted a snippet with the imports below. I'm trying to use this to build a multi-part MIME message, with this as one part. I really can't figure out any way to attach a binary part like this to a multi-part MIME

Re: Newline interpretation issue with MIMEApplication with binary data, Python 3.3.2

On Thu, Sep 26, 2013 at 2:23 PM, Nils Bunger nilsbun...@gmail.com wrote: Yes, it's email.mime.MIMEApplication. I've pasted a snippet with the imports below. I'm trying to use this to build a multi-part MIME message, with this as one part. I really can't figure out any way to attach a

Re: Unicode literals and byte string interpretation.

On Oct 28, 3:06 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Oct 2011 20:05:13 -0700, Fletcher Johnson wrote: If I create a newUnicodeobject u'\x82\xb1\x82\xea\x82\xcd' how does this creation process interpret the bytes in the byte string? It doesn't, because

Re: Unicode literals and byte string interpretation.

On Thu, 27 Oct 2011 20:05:13 -0700, Fletcher Johnson wrote: If I create a new Unicode object u'\x82\xb1\x82\xea\x82\xcd' how does this creation process interpret the bytes in the byte string? It doesn't, because there is no byte-string. You have created a Unicode object from a literal string

Unicode literals and byte string interpretation.

If I create a new Unicode object u'\x82\xb1\x82\xea\x82\xcd' how does this creation process interpret the bytes in the byte string? Does it assume the string represents a utf-16 encoding, at utf-8 encoding, etc...? For reference the string is これは in the 'shift-jis' encoding. --

Re: Unicode literals and byte string interpretation.

On Oct 27, 2011, at 11:05 PM, Fletcher Johnson wrote: If I create a new Unicode object u'\x82\xb1\x82\xea\x82\xcd' how does this creation process interpret the bytes in the byte string? Does it assume the string represents a utf-16 encoding, at utf-8 encoding, etc...? For reference the

Re: Unicode literals and byte string interpretation.

On Fri, Oct 28, 2011 at 2:05 PM, Fletcher Johnson flt.john...@gmail.com wrote: If I create a new Unicode object u'\x82\xb1\x82\xea\x82\xcd' how does this creation process interpret the bytes in the byte string? Does it assume the string represents a utf-16 encoding, at utf-8 encoding, etc...?

[issue4603] 3.0 document tab interpretation change

Georg Brandl ge...@python.org added the comment: Thanks, fixed in r67786. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4603 ___

[issue4603] 3.0 document tab interpretation change

: georg.brandl components: Documentation messages: 77360 nosy: georg.brandl, tjreedy severity: normal status: open title: 3.0 document tab interpretation change versions: Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4603

Re: interpretation of special characters in Python

TP [EMAIL PROTECTED] writes: Peter Pearson wrote: When you tell python print '\033[30;44m foo \033[0m', python interprets the \033 as a single character. So, the python print command *can* interpret these 4-character as a single character. Not interpret, no. It's more accurate to say

Re: interpretation of special characters in Python

TP wrote: So, the python print command *can* interpret these 4-character as a single character. It would be odd if there were no possibility to do the same thing when the characters are (i) stored in a python variable Sorry, it works when using variables. Try for example: col=[0;31m esc=\033

Re: interpretation of special characters in Python

escape character. One of this group's regular participants can (I hope) tell us three breathtakingly elegant ways to do that. I'm sorry I can't. When you run echo, it recognizes the 4-character esc as a convention for representing a single character, and performs the re-interpretation

Re: interpretation of special characters in Python

Peter Otten wrote: esc = os.environ[esc].decode(string-escape) esc '\x1b' print %s[30;44malles so schoen bunt hier%s[0m % (esc, esc) alles so schoen bunt hier Thanks a lot for your help. It works perfectly. Indeed, one can read in the documentation concerning encodings: Produce a string

Re: interpretation of special characters in Python

, it works when using variables. Try for example: col=[0;31m esc=\033 colreset=[0m print esc + col + foobar + esc + colreset I don't understand exactly what you mean by Sorry, but let me direct your attention to the fact that the interpretation step about which we're talking happens during

Re: interpretation of special characters in Python

Peter Pearson wrote: I don't understand exactly what you mean by Sorry I means: please forgive me for having said that it does not work with variables, because it is completely false. Thanks one more time Julien -- TP (Tribulations Parallèles) Allez, Monsieur, allez, et la foi vous

interpretation of special characters in Python

ColorBlackOnDarkblue=[30;44m $ export ColorReset=[0m When I execute the Python script, I do not obtain any special character interpretation in Python: $ python color.py \033[30;44m foo \033[0m Why? What is the problem? Is there any solution? I really want to get my shell color variables. Thanks a lot

Re: interpretation of special characters in Python

regular participants can (I hope) tell us three breathtakingly elegant ways to do that. I'm sorry I can't. When you run echo, it recognizes the 4-character esc as a convention for representing a single character, and performs the re-interpretation for you. When you tell python print '\033[30;44m

Re: interpretation of special characters in Python

Dennis Lee Bieber wrote: Off-hand, I'd probably try first with: csi = \033[ and then define your colorblackondarkblue = $csi30;44m Thanks for your answer. I have tried this slight modification, but it does not change anything on my terminal. -- TP (Tribulations Parallèles) Allez,

Re: interpretation of special characters in Python

Peter Pearson wrote: Thanks for your answer. When you run echo, it recognizes the 4-character esc as a convention for representing a single character, and performs the re-interpretation for you. When you tell python print '\033[30;44m foo \033[0m', python interprets the \033 as a single

yield expression programmized-formal interpretation. (interpretation of yield expression.)

What if I say oath= yield or other= yield ? Does yield evaluate without parenthes? (Eth.) -- http://mail.python.org/mailman/listinfo/python-list

Re: yield expression programmized-formal interpretation. (interpretation of yield expression.)

En Mon, 21 Apr 2008 15:03:05 -0300, [EMAIL PROTECTED] escribió: What if I say oath= yield or other= yield ? Does yield evaluate without parenthes? (Eth.) You can't use yield except in a generator function. From http://docs.python.org/ref/yieldexpr.html and the grammar definition

Re: urllib interpretation of URL with ..

Gabriel Genellina wrote: En Tue, 26 Jun 2007 17:26:06 -0300, sergio [EMAIL PROTECTED] escribió: John Nagle wrote: In Python, of course, urlparse.urlparse, which is the main function used to disassemble a URL, has no idea whether it's being used by a client or a server, so it, reasonably

Re: urllib interpretation of URL with ..

John Nagle wrote: In Python, of course, urlparse.urlparse, which is the main function used to disassemble a URL, has no idea whether it's being used by a client or a server, so it, reasonably enough, takes option 1. import urlparse base=http://somesite.com/level1/; path=../page.html

Re: urllib interpretation of URL with ..

En Tue, 26 Jun 2007 17:26:06 -0300, sergio [EMAIL PROTECTED] escribió: John Nagle wrote: In Python, of course, urlparse.urlparse, which is the main function used to disassemble a URL, has no idea whether it's being used by a client or a server, so it, reasonably enough, takes option

Re: urllib interpretation of URL with ..

Martin v. Löwis [EMAIL PROTECTED] wrote: Is urllib wrong? I can't see how. HTTP 1.1 says that the parameter to the GET request should be an abs_path; RFC 2396 says that /../acatalog/shop.html is indeed an abs_path, as .. is a valid segment. That RFC also has a section on relative

Re: urllib interpretation of URL with ..

Duncan Booth wrote: Martin v. Löwis [EMAIL PROTECTED] wrote: Is urllib wrong? Section 5.2 is also relevant here. In particular: g) If the resulting buffer string still begins with one or more complete path segments of .., then the reference is considered to be in

Re: urllib interpretation of URL with ..

John Nagle [EMAIL PROTECTED] writes: Duncan Booth wrote: Martin v. Löwis [EMAIL PROTECTED] wrote: Is urllib wrong? Section 5.2 is also relevant here. In particular: g) If the resulting buffer string still begins with one or more complete path segments of .., then the

urllib interpretation of URL with ..

Here's a URL, found in a link, which gives us trouble when we try to follow the link: http://sportsbra.co.uk/../acatalog/shop.html Browsers immediately turn this into http://sportsbra.co.uk/acatalog/shop.html and go from there, but urllib tries to open it explicitly, which

Re: urllib interpretation of URL with ..

John Nagle schrieb: Here's a URL, found in a link, which gives us trouble when we try to follow the link: http://sportsbra.co.uk/../acatalog/shop.html Browsers immediately turn this into http://sportsbra.co.uk/acatalog/shop.html and go from there, but urllib tries to open it

Re: urllib interpretation of URL with ..

a de-facto standard in browsers that any number of ../ sequences at the beginning of the path part of a URL have no effect. Even Google seems to use that interpretation; not only does it follow that link, it lists it in Google without the ... John Nagle

[ python-Bugs-1518406 ] re '\' char interpretation problem

interpretation problem Initial Comment: I've run across 2 problems having to do with '\' character problems with the re module. Problem 1 does not match the re when it should have. Problem 2 matches, when it should not have. There is a short snippet of code attached that shows the problems I'm having

[ python-Bugs-1518406 ] re '\' char interpretation problem

thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ollie oldham (ooldham) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re '\' char interpretation

[ python-Bugs-1518406 ] re '\' char interpretation problem

thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ollie oldham (ooldham) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re '\' char interpretation

Interpretation of UnhandledException.rpt

Hi, in a windows server python application I receive once a week suddenly and not reproducible the following error. UnhandledException.rpt file: file //=== Exception code: C090

Re: Python Unicode decimal interpretation

as a character like '?'? Can someone either give me definitive why not or (preferably) give me a test case that shows where that interpretation does not hold. In the ignore case, no output is produced at all, for the unencodable character; this is the same way that '?' would be treated (it is also

Re: Python Unicode decimal interpretation

Martin v. Löwis wrote: Scott David Daniels wrote: In reading over the source for CPython's PyUnicode_EncodeDecimal, I see a dance to handle characters which are neither dec-equiv nor in Latin-1. Does anyone know about the intent of such a conversion? To support this:

Re: Python Unicode decimal interpretation

Scott David Daniels wrote: int(u\N{DEVANAGARI DIGIT SEVEN}) 7 OK, That much I have handled. I am fiddling with direct-to-number conversions and wondering about cases like int(u\N{DEVANAGARI DIGIT SEVEN} + XXX + u\N{DEVANAGARI DIGIT SEVEN}) int() passes NULL as error

Python Unicode decimal interpretation

a test case that shows where that interpretation does not hold. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list