Mailman 3 April 2021 - Python-ideas

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Bringing the print statement back
by Guido van Rossum March 2, 2022

March 2, 2022

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using … [View More]dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> [View Less]

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 18, 2022

Feb. 18, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Allow syntax "func(arg=x if condition)"
by Peter O'Connor Jan. 19, 2022

Jan. 19, 2022

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to … [View More]

6 9

Barrier Object in asyncio lib
by Yves Duprat May 11, 2021

May 11, 2021

Hi,the list, I'm wondering why Barrier object does not exist in the synchronization primitives of the asyncio lib while it is present in threading and multiprocessing libs ? This may not be the right place to ask this question, but I never found an answer on the web. Thanks for your help. Yves

6 13

Changing The Theme of Python Docs Site
by Abdur-Rahmaan Janhangeer May 9, 2021

May 9, 2021

Greetings, A proposal to change the theme of the Python docs. Great softwares are not distinguished by docs crankiness and unpleasantness. Though what's more important is the content, nevertheless it can be made more enjoyable to read. The Masonite docs for example is quite nice: https://docs.masoniteproject.com/ Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

12 27

String comprehension
by David Álvarez Lombardi May 6, 2021

May 6, 2021

I propose a syntax for constructing/filtering strings analogous to the one available for all other builtin iterables. It could look something like this. >>> dirty = "f8sjGe7" >>> clean = c"char for char in dirty if char in string.ascii_letters" >>> clean 'fsjGe' Currently, the best way to do this (in the general case) seems to be the following. >>> clean = "".join(char for char in dirty if char in string.ascii_letters) But I think the proposed syntax would … [View More]

16 42

Support more conversions in format string
by Serhiy Storchaka May 6, 2021

May 6, 2021

Currently format strings (and f-string expressions) support three conversions: !s -- str, !r -- repr and !a for ascii. I propose to add support of additional conversions: for int, float and operator.index. It will help to convert automatically printf-like format strings to f-string expressions: %d, %i, %u -- use int, %f -- use float, %o, %x -- use operator.index. For float the conversion letter is obvious -- !f. But I am not sure for what !i should be used, for int or operator.index. If make … [View More]

8 20

TACE16 text encoding for Tamil language
by பா. மு. செல்வக்குமார் May 2, 2021

May 2, 2021

Hi, I want to use this encoding <https://github.com/vanangamudi/tace16-utf8-converter/blob/master/tace16.py>[1] for Tamil language text because it is more consistent with the language's nature, and Unicode encoding severely damages(read more here[2] <https://en.wikipedia.org/wiki/Tamil_All_Character_Encoding>) the intrinsic features of the fusion of alphabets. a specific example would be when dealing with regex. *'^[சிகு]'* is the intended expression for lines that starts with … [View More]

3 4

Accepting a function argument of a particular type specified by the user
by Shreyan Avigyan April 26, 2021

April 26, 2021

Think it like this. We have this code in Python :- def add(a, b): return a + b Here we are taking two arguments a, b and then returning a + b. But we can pass in instance of any class like str, int, float, dict, user-defined class, etc. But we only want to add int here. Here we can modify it to be, def add(a, b): if type(a) == int and type(b) == int: return a +b raise Exception("Error") In this example it's pretty easy to check if the arguments are int. But in real world … [View More]

5 9

On function signature mismatch, include candidate function in traceback
by Pol Welter April 22, 2021

April 22, 2021

Consider the following snippet: ``` def foo(a, b): pass foo(1, 2, 3) ``` We all know what will happen. ``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ``` Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'. There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to … [View More]

5 6

: str() vs format(): trivia question
by Stephen J. Turnbull April 22, 2021

April 22, 2021

@serhiy Moving my speculative discussion to python-ideas. CC as courtesy, comment from you is welcome but not necessarily expected. Serhiy Storchaka writes: > format() without format specifier and str() should return the same > value in general, otherwise it will confuse users. I think this is a good rule of thumb because it's a very plausible default for format(), and easy to explain. But then what is the purpose of format()? Why not just give str() the functionality of format(), … [View More]

3 2

allow initial comma
by roland.puntaier＠chello.at April 16, 2021

April 16, 2021

I had posted this as https://github.com/python/peps/issues/1867 The discussion so far is below. Please make some arguments. The major point to me is, that the symmetry is broken, which leads to extra editing actions, like removing the comma in the first line. I guess, this was the reason to allow the comma after the last line/entry: `[1,2,]`. ``[,1,2]`` should also be allowed, too. The best argument is one that says: less or more effort in this or that situation. For example, with `[1,2,]`, … [View More]in line-wise formatting, one can do without special action at the last line (removing the comma there). All code from previous versions of Python would still work after a `[,1,2]` syntax allowance were introduced. ================================================================================= rpuntaie wrote: ================================================================================= Allow initial comma =================== Final comma works: t = ( 1, 2, ) x = [ 1, 2, ] y = { 1, 2, } z = { 1:11, 2:22, } def fun( a, b, ): pass Initial comma does not work: t = ( , 1 , 2 ) x = [ , 1 , 2 ] y = { , 1 , 2 } z = { , 1:11 , 2:22 } def fun( , a , b ): pass To make the syntax symmetric in this regard\ gives more freedom to format the code. I occasionally found the restriction an unnecessary nuisance. Before writing a PEP, I would like to discuss, - whether something like that has been proposed already? - what counter-arguments there could be? ================================================================================= pxeger wrote: ================================================================================= This is not the appropriate place to propose language changes. Try the [python-ideas](https://mail.python.org/mailman3/lists/python-ideas.python.or… mailing list. However, I don't think you'll get anyone to agree. What kind of code style are you using where you want to put commas at the start of the line? That is totally non-standard (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and confusing. Arbitrary symmetry is not a good reason for changing the language. We don't have a `tnirp` function just for the sake of symmetry with `print` because it would be pointless and add extra complication ================================================================================= rpuntaie wrote: ================================================================================= I surely agree, that not ignoring the sequence is essential. Else one would loose identifier space and thus information. I would never have the idea to make all permutations of `p.r.i.n.t` point to the same function. Therefore you just made a bad example. But the comma is just a separator. Why did they allow to have the comma before a closing bracket/parenthesis/brace? Because of symmetry between lines, is my guess. Occasionally one sees many spaces just the have the final comma aligned vertically. That could be avoided by placing the comma at the beginning. I personally also have a macro in the editor that evaluates a line in the parameter list, but drops an initial comma before doing that. Therefore this is my preferred formatting. I don't think that [PEP](https://www.python.org/dev/peps/pep-0008) is wrong. I just don't want to be restricted by unnecessary rules. Rules need to have a reason beyond someone dictating them. If that is the case, I follow them, because I see the reason, but not because someone dictates them. I'll go to [Python Ide as](https://mail.python.org/mailman3/lists/python-ideas.python.org/), then. Thanks. [View Less]

19 27

Iterable scalar values returning itself ones?
by Hans Ginzel April 16, 2021

April 16, 2021

Are there any reasons not to make scalar types iterable returning the value ones? Should each function check if it has got one value or a list/tuple before iteration over the argument? What is wrong on scalars for iteration, please? There is even legal to iterate over an empty set – an empty cycle. Python 3.8.5 (default, Jan 27 2021, 15:41:15) >>> def chain(*iterables): ... for iterable in iterables: ... yield from iterable ... >>> a = 5 >>> b = range(3) >&… [View More]

8 10

Top Level Await in Python like in Deno
by redradist＠gmail.com April 15, 2021

April 15, 2021

Hi all, Deno is JavaScript runtime that has very nice feature like Top Level Await, I think it would be also nice to have such feature in Python, it will make using async/await more convenient What do you think ? Share your ideas lets discuss ...

5 8

Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?
by Shreyan Avigyan April 15, 2021

April 15, 2021

After going through the https://github.com/python/cpython/blob/master/Include/object.h it seems that Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL. This if statement could be directly implemented in Py_DECREF right? Therefore is it really required to have Py_XDECREF? Why not use a DeprecationWarning for now and plan to deprecate Py_XDECREF in the near future? How about implementing an if statement in Py_DECREF to make it work like Py_XDECREF? Thanking you, With Regards

3 3

Revive: PEP 396 -- Module Version Numbers ?
by Christopher Barker April 14, 2021

April 14, 2021

Over the years, I've seen __version__ used very broadly but not *quite* in all packages. I've always known it was a convention, not a requirement. But it turns out it's not even a "official" convention. But it really would be nice if there was a consistent way that I could count on to get the version of a package at run time. Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago! https://www.python.org/dev/peps/pep-0396/ In the status note, it says: """ Further … [View More]

4 8

Add an export keyword to better manage __all__
by Theia Vogel April 13, 2021

April 13, 2021

Hi, I was refactoring some code today and ran into an issue that always bugs me with Python modules. It bugged me enough this time that I spent an hour banging out this potential proposal to add a new contextual keyword. Let me know what you think! Theia -------------------------------------------------------------------------------- A typical pattern for a python module is to have an __init__.py that looks something like: from .foo import ( A, B, C, ) from .bar import ( D,… [View More] E, ) def baz(): pass __all__ = [ "A", "B", "C", "D", "E", "baz", ] This is annoying for a few reasons: 1. It requires name duplication a. It's easy for the top-level imports to get out of sync with __all__, meaning that __all__, instead of being useful for documentation, is actively misleading b. This encourages people to do `from .bar import *`, which screws up many linting tools like flake8, since they can't introspect the names, and also potentially allows definitions that have been deleted to accidentally persist in __all__. 2. Many symbol-renaming tools won't pick up on the names in __all__, as they're strings. Prior art: ================================================================================ # Rust Rust distinguishes between "use", which is a private import, "pub use", which is a globally public import, and "pub(crate) use", which is a library-internal import ("crate" is Rust's word for library) # Javascript In Javascript modules, there's an "export" keyword: export function foo() { ... } And there's a pattern called the "barrel export" that looks similar to a Python import, but additionally exports the imported names: export * from "./foo"; // re-exports all of foo's definitions Additionally, a module can be gathered and exported by name, but not in one line: import * as foo from "./foo"; export { foo }; # Python decorators People have written utility Python decorators that allow exporting a single function, such as this SO answer: https://stackoverflow.com/a/35710527/1159735 import sys def export(fn): mod = sys.modules[fn.__module__] if hasattr(mod, '__all__'): mod.__all__.append(fn.__name__) else: mod.__all__ = [fn.__name__] return fn , which allows you to write: @export def foo(): pass # __all__ == ["foo"] , but this doesn't allow re-exporting imported values. # Python implicit behavior Python already has a rule that, if __all__ isn't declared, all non-underscore-prefixed names are automatically exported. This is /ok/, but it's not very explicit (Zen) -- it's easy to accidentally "import sys" instead of "import sys as _sys" -- it makes doing the wrong thing the default state. Proposal: ================================================================================ Add a contextual keyword "export" that has meaning in three places: 1. Preceding an "import" statement, which directs all names imported by that statement to be added to __all__: import sys export import .foo export import ( A, B, C, D ) from .bar # __all__ == ["foo", "A", "B", "C", "D"] 2. Preceding a "def", "async def", or "class" keyword, directing that function or class's name to be added to __all__: def private(): pass export def foo(): pass export async def async_foo(): pass export class Foo: pass # __all__ == ["foo", "async_foo", "Foo"] 3. Preceding a bare name at top-level, directing that name to be added to __all__: x = 1 y = 2 export y # __all__ == ["y"] # Big Caveat For this scheme to work, __all__ needs to not be auto-populated with names. While the behavior is possibly suprising, I think the best way to handle this is to have __all__ not auto-populate if an "export" keyword appears in the file. While this is somewhat-implicit behavior, it seems reasonable to me to expect that if a user uses "export", they are opting in to the new way of managing __all__. Likewise, I think manually assigning __all__ when using "export" should raise an error, as it would overwrite all previous exports and be very confusing. [View Less]

15 28

Python Idea - extension of 'with'
by anthony.flury April 10, 2021

April 10, 2021

We are all familiar with the `with` statement for context managers, so that the resources are correctly finalized/closed in case of an exception either in terms of the resources being allocated of the processing. It is very common though to wrap the `with block` in an outer `try` block, since although we know that the resource has been closed, at an 'application' level it is still neccessary to deal with the exception - an example might be : try: with open('… [View More]config.cfg', 'r') as cfg: # Process the open file config = load_config(cfg) except FileNotFound: logging.info('Config file not found - using default configuration') except PermissionError: logging.warning('Cannot open config .cfg - using default configuration') config = default_config() else: logging.info('Using config from config.cfg') It struck me that this is probably quite a common idiom, and we have the main processing (of the opened resources) indented twice just to accommodate the outer try block. I was wondering whether a worthwhile extension might be to allow the `with` statement to have an `except` and `else` clauses which would have the same semantics as wrapping the `with` block with a try - for example the above would now look like: with open('config.cfg', 'r') as cfg: # Process the open file config = load_config(cfg) except FileNotFound: logging.info('Config file not found - using default configuration') except PermissionError: logging.warning('Cannot open config .cfg - using default configuration') config = default_config() else: logging.info('Using config from config.cfg') Treating the 'with' as an implied `try` would reduce the march to the right - now the key processing of the resource is now indented only one level - and the association of the exception from the `with` block is syntactically clear. I am not good enough with core development to put together a working prototype, but I can imagine that this simple extension would be worth while, but I would be more than happy to author a PEP for this if it gets some initial positive feedback. Open questions - that I have - should we allow `except`, `else` and `finally` clauses (or just `except` and `else` - do we need `finally` here). -- Anthony Flury *Moble*: +44 07743 282707 *Home*: +44 (0)1206 391294 *email*: anthony.flury(a)btinternet.com <mailto:anthony.flury@btinternet.com> [View Less]

11 18

Adding syntax for the empty set
by ucodery＠gmail.com April 10, 2021

April 10, 2021

Hello, I would like to propose adding literal syntax to allow creation of an empty set without the need to call the type constructor. I believe the best choice for such a literal, and one that has been proposed before, is `{,}`. I know this idea has surfaced a few times before, but I cannot find any serious consideration since the 3K ideas chain with the closest to a pronouncement here https://mail.python.org/pipermail/python-3000/2006-May/001599.html. In that thread the idea of a new syntax … [View More]for the empty set did not seem to be rejected outright, but more that the idea of set literals at all was still in question and as empty sets were not implemented for 2.7 they were ultimately still left out of 3k, intentionally or unintentionally. Within cpython itself `set()` is used just over 200 times to assign a variable the value of an empty set. As a comparison `dict()` is used only 15 times, and all but one of those are within the test module, mostly for testing dict. On the other hand, `{}` is used for assignment a little over 1300 times; I think there is a clear preference for using literal over type construction when possible. I have a working implementation of this new syntax at https://github.com/ucodery/cpython/tree/empty-set which includes a few changes. Python from this branch allows `{,} == set()` but also `[,] == list()` and `(,) == tuple`. Partly this was because the grammar changes were easier to do all three but also because I personally liked keeping some symmetry between these collection literals. The main point of starting this thread is to gather opinions on adding `{,}` to the language, but I would like to discuss the other two as well. As a secondary point, I do think that this new tuple syntax would make teaching python easier. Those new to python often believe that parentheses are what make a tuple and only later, if ever, realize that it is only value(s) followed by a comma that construct a tuple and that parentheses are places around it mainly for readability. This misunderstanding often leads to a bug like `iter((4))`, assuming the programmer meant `iter((4,))`. I believe this confusion about whether it is the parentheses or the commas that construct a tuple is deepened because two parentheses surrounding nothing _does_ specifically create the empty tuple but `empty = ,` is a SyntaxError. With this literal tuple change, those new to the language can be told that parentheses containing at least one comma always creates a tuple (at least anywhere is is grammatically valid to have a tuple). Jeremy [View Less]

14 20

Re: Non-blocking concurrent.futures ThreadPoolExecutor
by Brunoais April 10, 2021

April 10, 2021

(I know this has some time but I think it makes sense in context) That is much easier said than done in real life when the whole project is doing by a team and you are stuck with whatever you all do in the group. Even then, I prefer making my own programs with a mix of daemon and non-daemon threads to do the word. Daemon threads do work that can be interrupted at any time for any reason. Non-daemon threads are more well behaved and focus on doing their short job with hard IO. In my case, the … [View More]

1 0

Greek alphabet in built-in`string` module
by mitchell.negus.57＠gmail.com April 9, 2021

April 9, 2021

I was wondering if it might be reasonable to consider adding a set of Greek letters to the constants in the `string` module. In my mind, the format would follow the existing convention—constants for both `greek_lowercase` and `greek_uppercase`, as well as a combined constant `greek_letters`. Judging by how these constants are defined in the module, this seems like it might be an almost trivially easy addition (with minimal future maintenance required), and could provide a neat little … [View More]

4 4

Allow Annotated annotation in dataclass
by brianmarroq＠gmail.com April 5, 2021

April 5, 2021

typing.Annotated could be used to build dataclasses. Using Annotated will allow libraries to add functionality to a dataclass without having to change dataclass creation or behavior. The example below shows how a dataclass could be implemented. It continues the example of struct2 shown in pep593. From a dataclass point of view, the Sample and AnnotatedSample would be equivalent. ```python @dataclass class Sample: a: int b: int c: int = field(default=5) d: int = 10 e: int = … [View More]

3 2

Change the exception type and message raised when _curses is not found
by Shreyan Avigyan April 5, 2021

April 5, 2021

When importing the curses module, be it on Windows or Darwin or UNIX-based OS or any other platform, if the _curses module is not found then just a ModuleNotFoundError is raised. But this error is not very informational in case of _curses module. Since the curses module is packaged with the Python interpreter itself at first it may seem, to beginners especially, that the Python interpreter was not installed correctly and then they would go searching for an answer for about 4-5 days. We know … [View More]

5 9

Reverse polish notation
by John April 3, 2021

April 3, 2021

It occurs to me it's a syntax error everywhere to put two potentially-calculable terms in a row with nothing between them, e.g.: ```python a = b c mylist = [x 6 for x in y if "a" in x] ``` Unless I'm missing something, this makes it relatively easy (from a syntax perspective; writing a parser r hard) to detect such: ```python a = b c 6 ** + 5 / mylist = [x 6 + for x in y if "a" in x] ``` This is a bit less ambiguous and simpler to write (and easier to read, caveat you have … [View More]to know *how* to read it) when dealing with complicated expressions with a lot of parenthesis—a use case I automatically want to dismiss despite always running into this immediately. ```python # tl counts from sleep_us() print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" % (i,c,1000/(tl/(1000*i)) if tl > 0 else 0)) # RPN print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" % (i,c, 1000 tl 1000 i * / / if tl > 0 else 0)) ``` I took the following steps in writing this: * 1000 / * 1000 tl / / * 1000 tl 1000 i * / / The first is the incomplete operation 1000 / <something> The second adds the divisor between the term (1000) and the operator (/), which is again going to be tl / <something>. The third adds the divisor there, 1000 * i, between tl and its operator. Reading it back is easy enough: scan until finding an operator and take the two terms to the left, e.g. u=(1000*i), then v=tl/u, then w=1000/v. You could also read "1000 tl 1000 i * / / gettime() +" by further doing x=w+gettime() ... it's read directly in sequence. From my perspective, one of these is harder to read than the other, and no amount of carefully-placed white spaces is going to replace a piece of scrap paper to untangle the order of operations. You can break it down to intermediate steps, but that can make it difficult to follow a complex calculation. Downsides: * Have to actually implement it in the parser * If almost nobody uses it, still have to maintain it until the end of time for compatibility * While it takes all of 30 seconds to learn, it's not obvious what in the heck you're looking at if you've never seen it * While it's easier to revise complex calculations and at times more readable, infix exists for a reason. RPN is built from the outside in for nested computations (although often that also involves going back and forth to add extra parenthesis while writing infix, rather than simply typing it out left to right in one go) Things to not do: * Mix-and-match single expressions e.g. 6 2 (3 * 4) + *, 6 * 2 3 4 * + While the first looks innocent enough, without the parentheses it becomes 6*(2*3 + 4). The second is just unreadable. * Reverse polish function calls e.g. 3 4 + str() no, just no * Prohibit infix in a call e.g. 3 4 getdata(n + 2) + * This isn't ambiguous, nor is it more difficult to read or parse Thoughts? [View Less]

12 31