Also get rid of forced newlines?

[d33tah]

I was trying to use bython for newliners. I found that in addition to #33, there's another problem. Consider the following program:

m=0; for line in __import__("sys").stdin { m = m if m > int(line.strip()) else int(line.strip())} ; print(m)

This only works if m=0 has its own line. Could this limitation be lifted?

[xXCrash2BomberXx]

Maybe mine would work better, if you're still interested
My Build of Bython

[martindorey]

I'm interested... but executables checked in, multiple ones, differing only in case and where's the source and if it's a derived work, then shouldn't it link to this as the parent and, if it's not a derived work, then shouldn't it have a different name? I see it's four years younger.

[xXCrash2BomberXx]

@martindorey The multiple executables where the result of a renaming issue when I pushed the last update and I just made a fix to correct that. The source code for the transpiler is in string.py. It is not a derived work as it was built completely from scratch with nothing taken from this project. The name "bython" has actually been thrown around in the Python community for a while meaning "Braced-Python" so giving it a different name would be pointless as the project is open source and not a product aimed at profit.

[martindorey]

The source code for the transpiler is in string.py.

It often turns out that the bulk of the work is somewhere a little unexpected, but "string.py" seems rather too generic and innocuous, where transpiler.py or bython.py wouldn't arouse such suspicion.

giving it a different name would be pointless as the project is open source and not a product aimed at profit

I'm no expert but https://packaging.python.org/en/latest/tutorials/packaging-projects/ says:

Choose a memorable and unique name for your package. You don’t have to append your username as you did in the tutorial, but you can’t use an existing name.

[xXCrash2BomberXx]

I do agree string.py was a bad naming choice to begin with, but there's also no point to rename it now since it doesn't effect actual usage.
I have no intentions of making it into a python package so I'm still not concerned with naming of packages either to be honest nor naming anywhere in the project since this isn't something you would use in another script for names to matter given this isn't related to code execution as its main purpose since it really is just an intense formatter (that the efficiency of is something I still groan at to this day).
Those looking to use it purely for the functionality can use the .exe and not be bothered by naming while those looking for a more customized experience or even wanting to modify the code to change the parsing themselves will likely already be doing naming on their own for their changes where it wouldn't matter what I do. The extent of changes I plan to make to the project are bug fixes and maybe small feature additions at the request of users if I feel motivated enough.