[Python-Dev] Re: Inline links in Misc/NEWS entries
I suggest slightly expanding the part about NEWS formatting in the dev guide, and specifically have the example include appropriate uses of roles, and a link to the list of available roles. https://devguide.python.org/committing/#what-s-new-and-news-entries On Thu, Aug 15, 2019 at 3:39 AM Kyle Stanley wrote: > > Also, for IDLE, news entries to idlelib/NEWS.txt > > where markup, as opposed to unicode, is noise. > > Interesting, I actually wasn't aware of the distinction for idlelib/NEWS. > I can imagine that Sphinx constructs such as :func:, :meth:, and :class: > would not be nearly as useful there. However, I can imagine reST being > occasionally useful. > > Based on a recent feature that was added to the IDLE, I could imagine > explicit inline reST links being somewhat useful for something like this: > > Add support for displaying line numbers. See `IDLE Options menu < > https://docs.python.org/3/library/idle.html#options-menu-shell-and-editor > >`_. > > The inline link would appear to readers as "IDLE Options menu" and allow > them to click on it to navigate to the corresponding documentation for more > information on the feature. > > > Bottom line: I would rather a knowledgeable editor prettify the blurbs > > in a consistent manner after I am done with them. To me, this is a > > place where specializations pays. > > I completely agree. I was mainly addressing situations where PR authors > were rejecting or disregarding suggestions to add the markup in the news > entry from those who are knowledgeable of the Sphinx constructs/roles. It > wouldn't be reasonable to expect all PR authors to be able to properly > utilize every supported markup feature. > > This is a rare occurrence, but I've had it happen a couple of times > recently. Based on the responses so far, it likely occurred due to some > developers not being aware that Misc/NEWS supported Sphinx roles and some > of the basic features of reST. That's completely understandable if it's a > newer feature. > > Hopefully this discussion and any potential updates to the devguide will > improve awareness of the feature, and provide instructions on when it's > appropriate to utilize. > > Thanks, > Kyle Stanley > > On Wed, Aug 14, 2019 at 3:31 AM Terry Reedy wrote: > >> On 8/13/2019 6:31 PM, Kyle Stanley wrote: >> >> > The primary purpose of me creating this topic was because there seems >> to >> > be some sentiment that it's perfectly fine to exclusively use plaintext >> > in the news entries. Especially in cases where authors have rejected >> > suggestions to adding the Sphinx markup in their PRs. There seems to be >> > some sentiment that it's perfectly fine to exclusively use plaintext in >> > every news entry. Personally, I think it's a bit more nuanced, and that >> > the links can sometimes be very helpful for readers. >> >> Beyond what Ned said, (news markup is relatively new), people may be >> uncertain what is allowed and when appropriate. Also, there is some >> situation for me where markup seems to be a nuisance and looks like it >> is introducing an error. So I have changed unicode quotes and removed >> some rst markup. Also, for IDLE, news entries to idlelib/NEWS.txt. >> where markup, as opposed to unicode, is noise. >> >> Bottom line: I would rather a knowledgeable editor prettify the blurbs >> in a consistent manner after I am done with them. To me, this is a >> place where specializations pays. >> >> -- >> Terry Jan Reedy >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/53QDMBQHW2S6F7JI4YSGAYYKJOVOIFQF/ >> > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/K5TXWQ7ARKDV73MNEIED35PZDAL6T2L2/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DZSQL4MYVHFQENLGQK2QLNNZKSYF33CJ/
[Python-Dev] Re: What to do about invalid escape sequences
If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DO6CH72RHRZLE2M6ILAEYFLZ3FD6D5KN/
[Python-Dev] Re: What to do about invalid escape sequences
On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw string"; let s = r#"Here's a raw string with "quotes" in it"#; let s = r##"Here's r#"the raw string syntax"# in raw string"##; let s = r###"and here's a '##"' as well"###; ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AB565Z6Z6VVUQR74VWLRCA6R2J6NZGAP/
[Python-Dev] It all works - wheels for AIX - up to a point
Spent some hours - experimenting... So - short story - it works. There remains a big chance for failure though as the current tag ignores differences in TL level, build_date, etc.. Also, a source for failure, is no recognition for 32-bit or 64-bit. However, focusing on the good news - the wheels install - without a compiler being called. Looking Forward!! AIX has a long history of letting binaries from the past be reused: See: https://www.ibm.com/support/knowledgecenter/ssw_aix_72/install/binary_compatability.html ++ The gritty details, for the curious/interested After having used devpi (client) to upload to a test devpi-server I pointed my pip at the devpi-server to download the packages. Note: using default pipy "source" I would get two .gz files. The initial upload is from an AIX 6.1 server, the download here is to an AIX 7.1 server. (testpi) devpi@x064:[/home/devpi/testpi]pip download -i http://x064:8441/aixtools/dev cffi Looking in indexes: http://x064:8441/aixtools/dev Collecting cffi Downloading http://x064:8441/aixtools/dev/%2Bf/504/244e6fc36188b/cffi-1.12.3.tar.gz (452kB) || 460kB 28.7MB/s Saved ./cffi-1.12.3.tar.gz Collecting pycparser (from cffi) Downloading http://x064:8441/aixtools/dev/%2Bf/d9d/f2f3597ea75ab/pycparser-2.19-py2.py3-none-any.whl (111kB) || 112kB 28.4MB/s Saved ./pycparser-2.19-py2.py3-none-any.whl Successfully downloaded cffi pycparser So, a wheel (for pycparser) and a .gz (for cffi). Phase 2: repeat the upload of cffi, but now from an AIX 7.1 server. Preview: (piserv) devpi@x064:[/home/devpi/testpi/cffi-1.12.3]devpi list pycparser http://x064:8441/aixtools/dev/+f/d9d/f2f3597ea75ab/pycparser-2.19-py2.py3-none-any.whl http://x064:8441/aixtools/dev/+f/2a8/90514e40f6d1c/pycparser-2.19.tar.gz (piserv) devpi@x064:[/home/devpi/testpi/cffi-1.12.3]devpi list cffi http://x064:8441/aixtools/dev/+f/53d/50f8d231592dc/cffi-1.12.3-cp37-cp37m-aix_6_1.whl http://x064:8441/aixtools/dev/+f/504/244e6fc36188b/cffi-1.12.3.tar.gz http://x064:8441/aixtools/dev/+f/4d2/0d8ee28c40fe7/cffi-1.12.3-cp37-cp37m-aix_7_1.whl (testpi) devpi@x064:[/home/devpi/xyz]pip download -i http://x064:8441/aixtools/dev cffi Looking in indexes: http://x064:8441/aixtools/dev Collecting cffi Downloading http://x064:8441/aixtools/dev/%2Bf/4d2/0d8ee28c40fe7/cffi-1.12.3-cp37-cp37m-aix_7_1.whl (197kB) || 204kB 20.7MB/s Saved ./cffi-1.12.3-cp37-cp37m-aix_7_1.whl Collecting pycparser (from cffi) Downloading http://x064:8441/aixtools/dev/%2Bf/d9d/f2f3597ea75ab/pycparser-2.19-py2.py3-none-any.whl (111kB) || 112kB 23.3MB/s Saved ./pycparser-2.19-py2.py3-none-any.whl Successfully downloaded cffi pycparser Regards, Michael signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LABQ2YBCN2CN6FLHLTZYXV5Y2HXHK37B/
[Python-Dev] Re: What to do about invalid escape sequences
On 8/15/2019 4:17 AM, Petr Viktorin wrote:
On 8/15/19 10:40 AM, Greg Ewing wrote:
If we want a truly raw string format that allows all characters,
including any kind of quote, we could take a tip from Fortran:
s = 31HThis is a "totally raw" string!
Or from Rust:
let s = r"Here's a raw string";
let s = r#"Here's a raw string with "quotes" in it"#;
let s = r##"Here's r#"the raw string syntax"# in raw string"##;
let s = r###"and here's a '##"' as well"###;
Indeed, Fortran has raw strings, but comes with the disadvantage of
having to count characters. This is poor form when edits want to change
the length of the string, although it might be advantageous if the
string must fit into a certain fixed-width on a line printer. Let's not
go there.
Without reading the Rust spec, but from your examples, it seems that
Rust has borrowed concepts from Perl's q and qq operators, both of which
allowed specification of any non-alphanumeric character as the
delimiter. Not sure if that included Unicode characters (certainly not
in the early days before Unicode support was added), but it did have a
special case for paired characters such as <> [] {} to allow those pairs
to be used as delimiters, and still allow properly nested instances of
themselves inside the string.
It looks like Rust might only allow #, but any number of them, to
delimit raw strings. This is sufficient, but for overly complex raw
strings containing lots of # character sequences, it could get
cumbersome, and starts to border on the problems of the Fortran
solution, where character counting is an issue, whereas the choice of an
alternative character or character sequence would result in a simpler
syntax.
I don't know if Rust permits implicit string concatenation, but a quick
search convinces me it doesn't.
The combination of Python's triple-quote string literal, together with
implicit concatenation, is a powerful way to deal with extremely complex
string literals, although it does require breaking them into pieces
occasionally, mostly when including a string describing the triple-quote
syntax. Note that regex searching for triple-quotes can use "{3} or '{3}
to avoid the need to embed triple-quotes in the regex.
Perl's "choice of delimiter" syntax is maybe a bit more convenient
sometimes, but makes parsing of long strings mentally exhausting
(although it is quick for the interpreter), due to needing to remember
what character is being used as the delimiter.
My proposal isn't intended to change the overall flavor of Python's
string syntax, just to regularize and simplify it, while allowing
additional escapes and other extensions to be added in the future,
without backward-compatibility issues.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/PUY3DUQKAPQEQLPRZCZX2NAD4Z2KPIJW/
[Python-Dev] Re: What to do about invalid escape sequences
On 15/08/2019 12:17:36, Petr Viktorin wrote: On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw string"; let s = r#"Here's a raw string with "quotes" in it"#; let s = r##"Here's r#"the raw string syntax"# in raw string"##; let s = r###"and here's a '##"' as well"###; ___ I rather like the idea! (Even though it would add to the proliferation of string types.) Obviously Python can't use # as the special character since that introduces a comment, and a lot of other possibilities are excluded because they would lead to ambiguous syntax. Say for the sake of argument we used "!" (exclamation mark). Possible variations include: (1) Like Rust: s = r"Here's a raw string"; s = r!"Here's a raw string with "quotes" in it"!; s = r!!"Here's r!"the raw string syntax"! in raw string"!!; s = r!!!"and here's a '!!"' as well"!!!; (2) Same, but omit the leading 'r' when using !: s = r"Here's a raw string"; s = !"Here's a raw string with "quotes" in it"!; s = !!"Here's a raw string with "quotes" and !exclamation marks! in it"!!; s = !!!"and here's a '!!"' as well"!!!; # Cons: Would conflict with adding ! as an operator (or at minimum, as a unary operator) for some other purpose in future. # Makes it less obvious that a !string! is a raw string. (3) Allow the user to specify his own delimiting character: s = r!|This raw string can't contain a "bar".| (4) As above, but the "!" is not required: s = r|This raw string can't contain a "bar".| # In this case the delimiter ought not to be a letter # (it might conflict with current or future string prefixes); # this could be forbidden. (5) Similar, but allow the user to specify his own delimiting *string* (specified between "!"s) (as long as it doesn't contain !): let s = r!?@!Could this string could contain almost anything? Yes!?@ # The text in this string is: # Could this string could contain almost anything? Yes! (6) Same except the first "!" is not required. In this case the first character of the delimiting string should not be a letter: let s = r?@!Could this string could contain almost anything? Yes!?@ # The text in this string is: # Could this string could contain almost anything? Yes! I can dream ... A point about the current syntax: It is not true that a raw string can't end in a backslash, as https://en.wikipedia.org/wiki/String_literal points out. It can't end in an *odd number* of backslashes. 42 is fine, 43 is no good. Which makes it seem even more of a language wart (think of program-generated art). Rob Cliffe ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AZVQBRODB64WAP22J4VSVOBAIEKLUMB5/
[Python-Dev] Re: Inline links in Misc/NEWS entries
> I suggest slightly expanding the part about NEWS formatting in the dev guide, and specifically have the example include appropriate uses of roles, and a link to the list of available roles. Yeah definitely, it was my intention to mention this in the devguide, particularly with adding an example of the Sphinx roles being used and explaining appropriate usage. I hadn't thought of linking to the list of roles (https://devguide.python.org/documenting/#id4), but that's definitely a good idea to include. I was just waiting for everyone to get a chance to provide feedback on the topic before expanding the devguide. After the devguide is updated, I was also planning on adding the markup to 3.8's Misc/NEWS entries (in the appropriate branch, as Ned recommended), and then work on the 3.9. I'll probably split it into several smaller PRs so it's easier to review. On Thu, Aug 15, 2019 at 3:10 AM Tal Einat wrote: > I suggest slightly expanding the part about NEWS formatting in the dev > guide, and specifically have the example include appropriate uses of roles, > and a link to the list of available roles. > > https://devguide.python.org/committing/#what-s-new-and-news-entries > > On Thu, Aug 15, 2019 at 3:39 AM Kyle Stanley wrote: > >> > Also, for IDLE, news entries to idlelib/NEWS.txt >> > where markup, as opposed to unicode, is noise. >> >> Interesting, I actually wasn't aware of the distinction for idlelib/NEWS. >> I can imagine that Sphinx constructs such as :func:, :meth:, and :class: >> would not be nearly as useful there. However, I can imagine reST being >> occasionally useful. >> >> Based on a recent feature that was added to the IDLE, I could imagine >> explicit inline reST links being somewhat useful for something like this: >> >> Add support for displaying line numbers. See `IDLE Options menu < >> https://docs.python.org/3/library/idle.html#options-menu-shell-and-editor >> >`_. >> >> The inline link would appear to readers as "IDLE Options menu" and allow >> them to click on it to navigate to the corresponding documentation for more >> information on the feature. >> >> > Bottom line: I would rather a knowledgeable editor prettify the blurbs >> > in a consistent manner after I am done with them. To me, this is a >> > place where specializations pays. >> >> I completely agree. I was mainly addressing situations where PR authors >> were rejecting or disregarding suggestions to add the markup in the news >> entry from those who are knowledgeable of the Sphinx constructs/roles. It >> wouldn't be reasonable to expect all PR authors to be able to properly >> utilize every supported markup feature. >> >> This is a rare occurrence, but I've had it happen a couple of times >> recently. Based on the responses so far, it likely occurred due to some >> developers not being aware that Misc/NEWS supported Sphinx roles and some >> of the basic features of reST. That's completely understandable if it's a >> newer feature. >> >> Hopefully this discussion and any potential updates to the devguide will >> improve awareness of the feature, and provide instructions on when it's >> appropriate to utilize. >> >> Thanks, >> Kyle Stanley >> >> On Wed, Aug 14, 2019 at 3:31 AM Terry Reedy wrote: >> >>> On 8/13/2019 6:31 PM, Kyle Stanley wrote: >>> >>> > The primary purpose of me creating this topic was because there seems >>> to >>> > be some sentiment that it's perfectly fine to exclusively use >>> plaintext >>> > in the news entries. Especially in cases where authors have rejected >>> > suggestions to adding the Sphinx markup in their PRs. There seems to >>> be >>> > some sentiment that it's perfectly fine to exclusively use plaintext >>> in >>> > every news entry. Personally, I think it's a bit more nuanced, and >>> that >>> > the links can sometimes be very helpful for readers. >>> >>> Beyond what Ned said, (news markup is relatively new), people may be >>> uncertain what is allowed and when appropriate. Also, there is some >>> situation for me where markup seems to be a nuisance and looks like it >>> is introducing an error. So I have changed unicode quotes and removed >>> some rst markup. Also, for IDLE, news entries to idlelib/NEWS.txt. >>> where markup, as opposed to unicode, is noise. >>> >>> Bottom line: I would rather a knowledgeable editor prettify the blurbs >>> in a consistent manner after I am done with them. To me, this is a >>> place where specializations pays. >>> >>> -- >>> Terry Jan Reedy >>> ___ >>> Python-Dev mailing list -- python-dev@python.org >>> To unsubscribe send an email to python-dev-le...@python.org >>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-dev@python.org/message/53QDMBQHW2S6F7JI4YSGAYYKJOVOIFQF/ >>> >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...
