[Python-ideas] Re: Python with braces formal proposal?
Hello, On Wed, 6 Jan 2021 11:47:08 +1100 Steven D'Aprano wrote: [] > You know Paul, as an advocate for braces, you're doing a great job of > convincing me that they aren't necessary. I'm an advocate for braces in as much as I'm an advocate for 2+2=4. Braces exist, and used by people who need them. What to advocate here? > Have you considered that rather than a new dialect of Python all you > need is a source code pre-processor or transformation? ROFL. Not just me, everyone else considered that, and has been implementing it like that for decades. I just noticed that people who implement it, don't seem to describe well what they are doing, and make hilarious mistakes. As I have only limited view of such projects, I asked here whether there was ever someone who articulated well enough what they wanted to achieve. I got my answer from you, Steven, and I trust it, because I know that you're an old-timer here, and thorough participant of the discussions. (And I appreciate that!) And I'm happy about discussion bikeshedding/scope-creeping we all had here, but there's little else to it. (I.e. as there's no such a proposal, I just put writing such in my TODO list, that's all.) [] -- 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/JRM63IQWNQR7OOC3ZOSACNIWRYBCIZLY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
Hello, On Tue, 5 Jan 2021 14:29:03 +0100 Ronald Oussoren wrote: [] > > In this regard, braces aren't worse than average other stuff posted > > here. Actually, it might be a bit more interesting, as it clearly > > moved people throughout the years. > > That’s questionable. The primary reason I’ve seen so far is folks > that dislike significant whitespace or mis the braces in they had in > other languages (to put it bluntly). And I've seen the primary reason to be able to write complex one-liners and multi-statement lambdas. Talk about the difference in perception, everyone sees what they want to see! > But as Chris has noticed there’s about 0 chance that any proposal for > adding braces as an optional feature will be accepted. A lot of > other proposals also have little chance of being accepted, but they > do inform development of either the language or some library. That's exactly the case for "python with braces" - "to inform". > In some sense reading about problems folks run into with the language > are in general more interesting than full formed ideas because most > of us aren’t very good language designers (and I count myself in that > category). Exactly the case for bringing up "python with braces". [] > > There were good reasons to not have string interpolation in the core > > language for decades then - KABOOM - there's string interpolation. > > You see a pattern yet? No? Oh, let's just keep watching. > > I don’t agree, in hindsight there’s a clear path to the introduction > of f-strings. That's right the problem with that stuff. If Python suddenly gets alternative braces syntax, people like yourself will immediately start to sing dithyrambs to the wiseness of great helmsman who enabled Python to compete with braces languages, and how it always has been a clear path to that. That's the bravery of hindsight/a posteriori thinking. Can you make similarly brave foresight predictions of what Python *should* get? [] > > For everyone else who misses the point: the talk is about > > *alternative* (second) syntax. Nothing happens to the main > > indent-based syntax. Only people who need braces syntax would use > > it, just as they have been doing for decades. > > They can continue to use a 3th-party project for that. Did anybody talked about anything else on this thread? I didn't notice. Myself, I posed very specific question: was there a more or less formal proposal for braces syntax ever posted? I got my answer (only one person in the discussion bothered to answer to the actual topic of discussion, not just something related). > Having an > formal alternative syntax at the very least sends out the signal that > the language designers think that this is a good idea, and from what > I’ve read in the past that’s not going to happen. Reading that, it seems that when you read "formal proposal", you picture some old wise men in extravagant attires and headdresses, who got an exclusive and irrevocable license to write formal proposals. And "formal proposal police" which will seek and destroy anyone who goes for the heresy of writing a formal proposal themselves. That's totally not the case. "Formal" is nothing but an antonym to "informal". And informal process is what you do when you got a vague idea, and a second later already thrash on the keyboard, coding. A formal process is when you resist the urge, think it out well, and even write it down. So for example, not only you can develop something from it, but soneone else too. Or someone else can verify that what you developed is faithful enough implementation of the original idea. It's that simple, really. And the question was exactly about that, and not about anything else, like why braces are needed or not needed. [] -- 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/74YD5HL7MIDQSTENMP3MSWW3PC75CGDC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.
On Wed, Jan 06, 2021 at 07:07:30AM +0300, Mikhail V wrote: > I'd like to have an option to force the path separator for the > "os.path.join()" method. > E.g. if I run the script on Windows, but I generate, say, an URL, I'd > find it convenient > to use the same method, but with an explicit flag to "join" with the > forward slash (because URLs use it). "I don't care about correctness, I want to add arbitrary functionality to unrelated functions because it's convenient." *wink* The whole point of using os.path.join is that you don't care what the separator is, so long as it is correct *for the OS at runtime*. But for URLs, the separator never depends on the runtime OS. It is either fixed, or at worst will depend on the protocol. URLs are also a lot more complicated than file paths, so you should be using urllib to assemble the parts: https://docs.python.org/3/library/urllib.parse.html If you can't be bothered (and let's be honest, we've all been there) there's nothing wrong with assembling URL path components with pure string operations. All you need is a one-liner: def join(*parts, sep='/'): return sep.join([part.strip(sep) for part in parts]) -- 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/5LHVWVNAXJWCLKPYHUHA25TMXWB6L2XG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.
On 2021-01-05 20:07, Mikhail V wrote:
I'd like to have an option to force the path separator for the
"os.path.join()" method.
The urljoin method was made for the URL use case:
from urllib.parse import urljoin
urljoin('http://www.cwi.nl/%7Eguido/Python.html', 'FAQ.html')
'http://www.cwi.nl/%7Eguido/FAQ.html'
From: https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urljoin
-Mike
___
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/QNAXE4H6QIET5YFWABGRSTM4OO5NLURK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.
On 06Jan2021 07:07, Mikhail V wrote:
>I'd like to have an option to force the path separator for the
>"os.path.join()" method.
>E.g. if I run the script on Windows, but I generate, say, an URL, I'd
>find it convenient
>to use the same method, but with an explicit flag to "join" with the
>forward slash (because URLs use it).
>Currently I simply use an f-string to combine a path, like e.g.:
>
>path = f"{root}/{dir}"
>
>but it will insert extra "/" if there if "root" already has "/" on the end.
>But the "join" method will not, which is a pro for the method vs
>"manual" string construct.
There's also:
'/'.join(url-path-things-here...)
>I know there is the "pathlib" module with all conversion methods, but
>it's overkill for many tasks.
I suspect given pathlib's existence, that raises the bar for wanting to
extend os.path.join since there are so many other ways to do that.
Also, os.path.join is supposed to be for the local OS, like most other
os.* things. Making it _not_ act like the local OS feels antithetical to
me.
I was going to suggest:
https://docs.python.org/3/library/urllib.parse.html#module-urllib.parse
since your use case is URLs, but it doesn't really parse the "path"
part.
Cheers,
Cameron Simpson
___
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/KTWRI3RT35XDO2XQ2L5IBSIWWPHCLG4L/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.
On 05Jan2021 22:41, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: >That said, AIUI, there's nothing stopping a web server from using >whatever separators it wants. Everything after the domain name is up to >the web server to interpret; it just happens that most early web servers >ran on Unix/Posix/Linux boxes and mapped URLs fairly directly to parts >of the file system, and "/" was more natural than anything else. Well, not really. On the server side something has to map the URL local part to a file path or some handler, and that could use whatever separators it likes. However, HTML relative URLs rely on '/' as a separator to resolve correctly. You can't change that without breaking the text web because relative URLs are resolved by browsers, not servers. Cheers, Cameron Simpson ___ 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/G53HY2NDDGS4MJT3QDSEAL5YIP5YYD3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.
On 2021-01-06 at 07:07:30 +0300,
Mikhail V wrote:
> I'd like to have an option to force the path separator for the
> "os.path.join()" method.
> E.g. if I run the script on Windows, but I generate, say, an URL, I'd
> find it convenient
> to use the same method, but with an explicit flag to "join" with the
> forward slash (because URLs use it).
> Currently I simply use an f-string to combine a path, like e.g.:
>
> path = f"{root}/{dir}"
>
> but it will insert extra "/" if there if "root" already has "/" on the end.
> But the "join" method will not, which is a pro for the method vs
> "manual" string construct.
>
> I know there is the "pathlib" module with all conversion methods, but
> it's overkill for many
> tasks. So I'd rather like to have an option to write for example:
>
> path = os.path.join (root, dir, sep = "posix")
>
> So that it joins with the forward slash even if run on Windows.
> Also it seems that e.g. "os.path.split()" already supports both
> separators, so I think this addition won't bring inconsistency into
> the module and its usage.
I'm not sure whether a method in the os module should understand URLs
(are URLs part of the OS, or part of something else?), but in any case,
in your example, it would make more sense to have a "URL" separator and
not use "posix" as a simple synonym for forward slash. IMO, using "/"
itself is clearer.
That said, AIUI, there's nothing stopping a web server from using
whatever separators it wants. Everything after the domain name is up to
the web server to interpret; it just happens that most early web servers
ran on Unix/Posix/Linux boxes and mapped URLs fairly directly to parts
of the file system, and "/" was more natural than anything else.
___
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/5KGGSYF4NLE5MCZXS7D5F2PR6E6RLSNY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] An option to force the path separator for the "os.path.join()" method.
I'd like to have an option to force the path separator for the
"os.path.join()" method.
E.g. if I run the script on Windows, but I generate, say, an URL, I'd
find it convenient
to use the same method, but with an explicit flag to "join" with the
forward slash (because URLs use it).
Currently I simply use an f-string to combine a path, like e.g.:
path = f"{root}/{dir}"
but it will insert extra "/" if there if "root" already has "/" on the end.
But the "join" method will not, which is a pro for the method vs
"manual" string construct.
I know there is the "pathlib" module with all conversion methods, but
it's overkill for many
tasks. So I'd rather like to have an option to write for example:
path = os.path.join (root, dir, sep = "posix")
So that it joins with the forward slash even if run on Windows.
Also it seems that e.g. "os.path.split()" already supports both
separators, so I think this addition won't bring inconsistency into
the module and its usage.
___
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/MPGMGAZRKJ4OKTQQT7K4ZMM2TBUUTZUZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Tue, Jan 05, 2021 at 02:35:05AM +0300, Paul Sokolovsky wrote: > But links were already posted: > https://github.com/search?o=desc=python+braces=updated=Repositories . > That's even sorted by last updated. Not every project in that list is > about "python braces", but there're enough. That's a very unimpressive collection of "Python-with-braces" projects. The most popular of them is Bython, as you say: > That said, https://github.com/mathialo/bython collected 255 stars and > has 2 contributors, like you wish. I've heard of bython. But before you get too excited over an entire 255 stars and two contributors, you should compare it to a project like Coconut: https://github.com/evhub/coconut with 3.1K stars and 20 contributors. I would be the first to acknowledge that Coconut is a niche part of the Python ecosystem, but it is more than 10 times bigger than Bython based on this simplistic measure of popularity. But here's another: https://trends.google.com.au/trends/explore?q=bython,coconut%20language > This one: https://github.com/umlet/pwk has only 94 stars, but even 3 > contribs. More importantly, it got the motivational part right: > > >> We love Python. We love them bash one-liners. We want to do > >> one-liners in Python. Who is "we" here? People who don't care about readability, maintainability or correctness of their code? One liners hurt all three of those. > The most vivid real-world example of that I know is Frida the > reverse-engineering framework (https://frida.re). The issue is so > prominent that they admit it on the first page of the docs > (https://frida.re/docs/home/): > > >> Why a Python API, but JavaScript debugging logic? > > What they write under that title is now marketing blah-blahing, but I > remember when it leaked the sad truth: "We use JavaScript because its > syntax more suitable for one-liners and small code snippets". If there > was a generally accepted alternative syntax for Python, situation might > have been different. So the jewel in your crown, the most important, vital, convincing example of why Python needs braces that you could find, the killer use-case that you hoped would convince us of the value of braces, comes from a project that doesn't actually mention one-liners or braces. "Trust me, it *totally* used to say that!!!" I believe you. But perhaps rather than leaking the sad truth, the project maintainers decided that your quote was inaccurate or unnecessary. You know Paul, as an advocate for braces, you're doing a great job of convincing me that they aren't necessary. Have you considered that rather than a new dialect of Python all you need is a source code pre-processor or transformation? -- 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/WPP3QAUXTKR4NLBMUE5T2PIIRPRK3UNV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python JIT Compilation Thoughts
you really want to look at other Python JIT methods, including ones based on LLVM: numba: https://numba.pydata.org/ and the old unladen swallow project: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html and of course, not LLVM based, but PyPy is worth a look. In short: a lot of very smart people have put a lot of work into these efforts -- "m not saying you don't have good ideas, but it's clearly a very hard problem. -CHB On Mon, Jan 4, 2021 at 10:24 AM wrote: > For me it easier to do with C++, I know C, but with C++ it is more > maintainable and easier to add new feature and also easier to refactor ... > > I am not sure if CPython maintainers team will appropriate that I add C++ > in code base ... > > But I can try, I will try to find time to create small proof of concept in > C++ > ___ > 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/B6UM6566HMUP4O3WKXCP3GMT4RDPHCJJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- 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/QBKA2XGFY3W3HLKK4XHDAMTM4IHT4VQH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Wed, Jan 6, 2021 at 9:17 AM lasizoillo wrote:
>
> Sorry, but if I'm understanting the point is to make one-liners. For example,
> if I want to do something like:
>
> $ env | grep "^XDG"
>
> In one python one liner like
>
> $ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value in
> os.environ.items() if key.startswith("XDG
> ")]))'
>
> I can, but If I have things that require indentation I must change it to
> something like:
>
> $ python << EOF
I don't know about inferior shells, but with Bourne-compatible shells
(tested in bash and dash, but probably pretty much anything), you can
simply open a quote and proceed to create a multi-line command.
$ python3 -c 'for n in range(1, 10):
> if n % 3:
> print("Not a multiple of three:", n)
> '
Not a multiple of three: 1
Not a multiple of three: 2
Not a multiple of three: 4
Not a multiple of three: 5
Not a multiple of three: 7
Not a multiple of three: 8
$
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/XKVO5LZRJEZRGKZTDOJOMOEVPTS5MSV6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
Hi!
El mar, 5 ene 2021 a las 0:35, Paul Sokolovsky ()
escribió:
> Hello,
>
> On Tue, 5 Jan 2021 08:52:54 +1100
> Steven D'Aprano wrote:
>
>
> >> We love Python. We love them bash one-liners. We want to do
> >> one-liners in Python.
>
>
> The most vivid real-world example of that I know is Frida the
> reverse-engineering framework (https://frida.re). The issue is so
> prominent that they admit it on the first page of the docs
> (https://frida.re/docs/home/):
>
> >> Why a Python API, but JavaScript debugging logic?
>
> What they write under that title is now marketing blah-blahing, but I
> remember when it leaked the sad truth: "We use JavaScript because its
> syntax more suitable for one-liners and small code snippets". If there
> was a generally accepted alternative syntax for Python, situation might
> have been different.
>
>
>
Sorry, but if I'm understanting the point is to make one-liners. For
example, if I want to do something like:
$ env | grep "^XDG"
In one python one liner like
$ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value in
os.environ.items() if key.startswith("XDG
")]))'
I can, but If I have things that require indentation I must change it to
something like:
$ python << EOF
import os
for key, value in os.environ.items():
if key.startswith("XDG"):
print(f"{key}:{value}")
EOF
and although it can be embedded in a shell script or written in command
line it has more than one line.
Really is better add braces to python that write some docs explaining how
to use it in command line? What are the issues with multi-line command line
executions?
Maybe I have missed some point. But this is the best reason I've read and I
don't understand why is useful.
regards,
Javi
PD: Python not only can be used in console, Python can be the console
https://ipython.org/ipython-doc/stable/interactive/shell.html
___
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/T6D76VCFO5DTKSKLWGI7AUQ4DFDVPTNW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Tue, Jan 5, 2021 at 10:04 AM Chris Angelico wrote: > So my question to you is: Why raise all these threads on python-ideas > that have approximately zero chance of being accepted into the core > language? "Approximately zero" overstates the likelihood. "Strictly equal to zero" is a more accurate description. ___ 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/XF3PLLJAMKXG4OG4J5FMNRXXFD6R7AWX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Wed, Jan 6, 2021 at 12:01 AM Paul Sokolovsky wrote: > Anyway, this went offtopic wrt to the original subject. > [chomp loads of drivel] Yep, nothing more in this thread. Time to let it die a quiet death. 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/J5WLHNCYSY3QVGMDSFQROS26QJEIQVNI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
> On 5 Jan 2021, at 11:38, Paul Sokolovsky wrote: > > Hello, > > On Tue, 5 Jan 2021 21:03:06 +1100 > Chris Angelico mailto:ros...@gmail.com>> wrote: > >> On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky >> wrote: >>> And you seem to have 2nd level miss about this miss. I'm not the 1st >>> asking about braces in Python, hundreds of people embraced braces >>> (sorry for the pun) in Python for decades (references are in other >>> messages of this thread). Apparently, they forgot to ask for >>> "acceptance", and accepted it themselves. >>> >>> The problem? There's high duplication of effort in that area, and >>> the same implementation bugs are repeated again and again. So the >>> question is whether someone who did it, tried to spec out what they >>> did, what is the test process, etc. >>> >> >> So my question to you is: Why raise all these threads on python-ideas >> that have approximately zero chance of being accepted into the core >> language? > > Simple question, simple answer: majority of stuff posted on > python-ideas has approximately zero chance of being accepted into the > core language. > > In this regard, braces aren't worse than average other stuff posted > here. Actually, it might be a bit more interesting, as it clearly moved > people throughout the years. That’s questionable. The primary reason I’ve seen so far is folks that dislike significant whitespace or mis the braces in they had in other languages (to put it bluntly). But as Chris has noticed there’s about 0 chance that any proposal for adding braces as an optional feature will be accepted. A lot of other proposals also have little chance of being accepted, but they do inform development of either the language or some library. In some sense reading about problems folks run into with the language are in general more interesting than full formed ideas because most of us aren’t very good language designers (and I count myself in that category). > >> Why not create a new community of Bracey Python people, and >> build a language and an ecosystem around that? >> >> Is it because you think that you wouldn't get enough people? >> Because... that would be a good reason not to do it, and a good reason >> for the core language to continue to not do it. > > There were good reasons to not have string interpolation in the core > language for decades then - KABOOM - there's string interpolation. You > see a pattern yet? No? Oh, let's just keep watching. I don’t agree, in hindsight there’s a clear path to the introduction of f-strings. There’s also loads of features that have been proposed for a long while and never were added to the language, and never will for one reason or another. Anyways… That some unrelated feature was accepted is not an argument in favour of this feature. > > For everyone else who misses the point: the talk is about *alternative* > (second) syntax. Nothing happens to the main indent-based syntax. Only > people who need braces syntax would use it, just as they have been > doing for decades. They can continue to use a 3th-party project for that. Having an formal alternative syntax at the very least sends out the signal that the language designers think that this is a good idea, and from what I’ve read in the past that’s not going to happen. > > Whether a particular implementation (it's a common joke on the Python > lists to mistake a language and a particular implementation) supports > alternative syntax out of the box is irrelevant. It's no more different > to having a separate typechecker or a separate script to run venv in a > subshell (a recent case brought up here on the list). That folks are mistaken about the distinction between the language and an implementation is to be expected, that happens with formally standardised languages as well (my code works with compiler X and not with compiler Y, therefore compiler Y is broken). Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ 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/5KJ2VE3G72VLUKSPHHM6J5MAMB657LOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
Hello, On Tue, 5 Jan 2021 23:22:03 +1100 Chris Angelico wrote: > On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky > wrote: > > There were good reasons to not have string interpolation in the core > > language for decades then - KABOOM - there's string interpolation. > > You see a pattern yet? No? Oh, let's just keep watching. > > Do you have evidence from the language itself, or from the BDFL, that > string interpolation was out of the question? If not, then that's why > I'm not seeing the pattern or correlation. Yes, most people came to Python from other languages like Perl and PHP, which had string interpolation "forever". Request for such in Python were also around forever, I remember them since 1.5.1, when I chose Python as my language of choice. Nothing could prevent them being implemented in 1.5.2, but they were rejected exactly as not fitting Python's model of "explicit is better than implicit" (i.e. if you want to format, do format, do abuse normally looking strings with formatting magicity) and "there's one way to do it" (Python has the way to format strings - % operator, use it). Then, suddenly... Anyway, this went offtopic wrt to the original subject. In attempt to bring it back to topic, let me risk telling a fable. A fable about my friend-by-correspondence Chris (more like mind opponent). As a prelude though, scientific studies show that every programmer has a need for some braces in their life. If they don't receive a doze of braces for a while, it may bulge and break down. Most programmers receive enough doze from C/C++, younger generation from JavaScript. My friend Chris, he's more interesting. He self-describes as "Python and [censored] tutor, [irrelevant] addict, and Pike fanatic." That Pike, I immediately recognize it. Remember that choosing-a-language-of-choice event described above, culminated with selecting Python as of 1.5.1? Well, Pike was among the contenders too. Glad to hear it's alive and well. So, what can we tell to Chris? I guess "We're glad for you, that your braces needs are covered by Pike, but why are you so cruel to Python fanatics, who want braces right in Python? And just don't tell that braces from dict literals should be enough, we want more, we want one-liners with a bunch of if's and while's, we want multi-statement lambdas, we want it all." I hope you found the fable enjoyable, and not devoid of some moral. -- 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/LPK5CP74V2KMYZX6SOH7ZOMXGD5TQQ4X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky wrote: > There were good reasons to not have string interpolation in the core > language for decades then - KABOOM - there's string interpolation. You > see a pattern yet? No? Oh, let's just keep watching. Do you have evidence from the language itself, or from the BDFL, that string interpolation was out of the question? If not, then that's why I'm not seeing the pattern or correlation. 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/NH4RMYTKMJLNJ4AKY6SD2PNTFUIWZMHJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
Hello, On Tue, 5 Jan 2021 21:03:06 +1100 Chris Angelico wrote: > On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky > wrote: > > And you seem to have 2nd level miss about this miss. I'm not the 1st > > asking about braces in Python, hundreds of people embraced braces > > (sorry for the pun) in Python for decades (references are in other > > messages of this thread). Apparently, they forgot to ask for > > "acceptance", and accepted it themselves. > > > > The problem? There's high duplication of effort in that area, and > > the same implementation bugs are repeated again and again. So the > > question is whether someone who did it, tried to spec out what they > > did, what is the test process, etc. > > > > So my question to you is: Why raise all these threads on python-ideas > that have approximately zero chance of being accepted into the core > language? Simple question, simple answer: majority of stuff posted on python-ideas has approximately zero chance of being accepted into the core language. In this regard, braces aren't worse than average other stuff posted here. Actually, it might be a bit more interesting, as it clearly moved people throughout the years. > Why not create a new community of Bracey Python people, and > build a language and an ecosystem around that? > > Is it because you think that you wouldn't get enough people? > Because... that would be a good reason not to do it, and a good reason > for the core language to continue to not do it. There were good reasons to not have string interpolation in the core language for decades then - KABOOM - there's string interpolation. You see a pattern yet? No? Oh, let's just keep watching. For everyone else who misses the point: the talk is about *alternative* (second) syntax. Nothing happens to the main indent-based syntax. Only people who need braces syntax would use it, just as they have been doing for decades. Whether a particular implementation (it's a common joke on the Python lists to mistake a language and a particular implementation) supports alternative syntax out of the box is irrelevant. It's no more different to having a separate typechecker or a separate script to run venv in a subshell (a recent case brought up here on the list). > > 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/KV6EDFA26FMOS4Y6VIT4GBIEFFHHJJ3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky wrote: > And you seem to have 2nd level miss about this miss. I'm not the 1st > asking about braces in Python, hundreds of people embraced braces > (sorry for the pun) in Python for decades (references are in other > messages of this thread). Apparently, they forgot to ask for > "acceptance", and accepted it themselves. > > The problem? There's high duplication of effort in that area, and the > same implementation bugs are repeated again and again. So the question > is whether someone who did it, tried to spec out what they did, what is > the test process, etc. > So my question to you is: Why raise all these threads on python-ideas that have approximately zero chance of being accepted into the core language? Why not create a new community of Bracey Python people, and build a language and an ecosystem around that? Is it because you think that you wouldn't get enough people? Because... that would be a good reason not to do it, and a good reason for the core language to continue to not do it. 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/TWR2ZRJVFKX2JQNJPYGPM6SMLZEQQKE6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
Hello, On Tue, 5 Jan 2021 10:07:45 +0100 Ronald Oussoren wrote: > > On 4 Jan 2021, at 12:29, Paul Sokolovsky wrote: > > > > Hello, > > > > On Mon, 4 Jan 2021 21:47:26 +1100 > > Chris Angelico mailto:ros...@gmail.com>> wrote: > > > >> On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky > >> wrote: > >>> > >>> Hello, > >>> > >>> There're tons of projects which introduce alternative braces > >>> (i.e. C-like) syntax for Python. Most of them are however not > >>> properly documented, and definitely not spec'ed for what they do. > >>> > >>> I wonder, does anyone here remember more or less formal proposal > >>> for braces syntax? A "minimum viable product" criteria would be > >>> support for lossless indent -> braces -> indent syntax > >>> roundtripping. > >> > > from __future__ import braces > >> File "", line 1 > >> SyntaxError: not a chance > > > > Old, sour, buggy implementation from previous century. > > This is more a signal that you are far from the first person asking > about braces in Python, and what the general opinion from the > language designers is about this. > > IMHO it is highly unlikely that any proposal about adding braces to > Python would be accepted. And you seem to have 2nd level miss about this miss. I'm not the 1st asking about braces in Python, hundreds of people embraced braces (sorry for the pun) in Python for decades (references are in other messages of this thread). Apparently, they forgot to ask for "acceptance", and accepted it themselves. The problem? There's high duplication of effort in that area, and the same implementation bugs are repeated again and again. So the question is whether someone who did it, tried to spec out what they did, what is the test process, etc. -- 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/5QJ2OQJMTDRP7TB4TZ6QEPZ7AK7UQKNL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python with braces formal proposal?
> On 4 Jan 2021, at 12:29, Paul Sokolovsky wrote: > > Hello, > > On Mon, 4 Jan 2021 21:47:26 +1100 > Chris Angelico mailto:ros...@gmail.com>> wrote: > >> On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky >> wrote: >>> >>> Hello, >>> >>> There're tons of projects which introduce alternative braces >>> (i.e. C-like) syntax for Python. Most of them are however not >>> properly documented, and definitely not spec'ed for what they do. >>> >>> I wonder, does anyone here remember more or less formal proposal for >>> braces syntax? A "minimum viable product" criteria would be >>> support for lossless indent -> braces -> indent syntax >>> roundtripping. >> > from __future__ import braces >> File "", line 1 >> SyntaxError: not a chance > > Old, sour, buggy implementation from previous century. This is more a signal that you are far from the first person asking about braces in Python, and what the general opinion from the language designers is about this. IMHO it is highly unlikely that any proposal about adding braces to Python would be accepted. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ 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/G7I3GINHQZGZ2WH6LNYIT6CJ3UIOMT7I/ Code of Conduct: http://python.org/psf/codeofconduct/
