On Tuesday, July 1, 2014 1:05 PM, Terry Reedy tjreedy@udel.edu wrote:
On 7/1/2014 6:51 AM, Andrew Barnert wrote:
I think Terry Reedy actually had a better answer: just tell people to implement it, polish it up, put it on PyPI, and come back to us when they're ready to show off their tons of users who can't live
without
it. Random objected that wasn't possible,
'Random' said something quite different. He only noted that if '∅' were translated to 'set()', then the resulting CPython-specific bytecode would continue to be "LOAD_GLOBAL (set), CALL_FUNCTION 0" rather than the 'optimized' "BUILD_SET 0". He also noted (objected) that there is no python code that CPython currently compiles as "BUILD_SET 0"
You're reading a lot into a 2-line message, but your take is that he interpreted the problem as needing to compile "BUILD_SET 0", and pointed out that there is no way to do that with a source preprocessor.
You can insist that they're two separate problems to be solved (or, maybe, not solved), and I think you're right. You just have to make that point—as you, I, and half a dozen others have done since his original post.
But meanwhile, Chris Angelico offered a solution to the problem that answers his complaint, and I offered another solution that doesn't even require bytecode hacking. That shows that even if you accept the objection, it still doesn't block anyone.
Well, its unfortunate that {} is not available. If it were, there would be no issue, to me anyway, of using '∅'. However, optimizing CPython bytecode, and compiler hooks, are completely different issues from translating unisym python to standard python that could run on any implementation of Python.
First, as others have pointed out, it's not just, or even primarily, an optimization, it's also a semantic difference.
If we thought the bytecode difference was
important (which most do not), we could have a peephole optimizer to 'fix' it, completely independently of the existence of '∅' or any idea of using it in python code.
But you can't make semantic changes in a peephole optimizer. You'd have to first change the language to document that set() may (or may not!) return an empty set even if the name set resolves to something different. While this isn't entirely unique in Python history (e.g., back when you could redefine False through various kinds of trickery, the compiler was still allowed to optimize out if False: code), but it's very unusual. And nobody's going to do that for a minor optimization (if False:, besides being a potentially huge optimization, also _fixes_ a semantic problem, rather than causing one, since False was supposed to be un-redefinable, but wasn't because of various holes).
in which case Terry's idea is more of a dismissal than a helpful
suggestion,
My post was a dismissal of the idea of changing python itself *and* a suggestion of how to proceed without involving pydev.
My point is that _if_ you take Random's objection as being critical, _then_ your post dismisses the idea, even though it wasn't intended to. You can follow up in two ways: challenge his objection, or answer his objection; there were replies doing both, and if either of the two succeeds, the idea is still alive for people to take further if they want.
https://github.com/abarnert/emptyset proves that it is possible, and even pretty easy.
I consider producing (or at least being able to produce) a standard .py file that can be published outside the specialized group run on and debugged on standard interpreters to be essential to any sensible idea
My approach is made up of nothing but standard .py files. Those files can be published outside a specialized group, and run and debugged on CPython 3.4+. They can also be edited by people outside that specialized group, without needing a specialized build process involving a preprocessor, just a standard Python module that they already have.
Sure, it only works on CPython, but Python 3.4, scipy, etc. also currently only work on CPython, and that doesn't prevent a large community of users from making using of them, publishing code outside a specialized group, and—most importantly for the topic at hand—coming up with suggestions that are germane to Python as a whole and taken seriously. For example, nobody suggested that PEP 465 wasn't a sensible idea because all of the sample code presented only runs on CPython; the idea itself is clearly portable, the community using such code is gigantic and mature, and that's all that matters.
Finally, I don't think anyone actually needs this feature, but I was able to whip up a proof of concept in an hour that provides it. Anyone who seriously wants to pursue it doesn't have to use my approach, much less my code; it still serves as an existence proof that what they want to do can be done, meaning they should go do it.