Re: [Python-ideas] parser in stdlib
Hence the quote. First thing I said was, "...it might not be advisable either, subject to abuse, per GvR...." But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module? Do I take the powers that be to have said, "No, that would open too many doors and give the programmers too much freedom?" If so, that's straight-forward and honest, and presents the next problem for solutions. Can we expose that and still keep programs up to standard?
On 5/10/07, Aaron Brady <castironpi@comcast.net> wrote:
There is no universally accepted answer to this question. Each language positions itself (deliberately or by accident) somewhere in the spectrum between total bondage and total freedom. Static typing proponents find that dynamic typing is already "too much freedom", let alone programmable syntax. Those that don't believe there is such a thing as "too much freedom" tend to climb their way up in the language ecosystem, until they discover Lisp and reach nirvana. Python keeps a happy medium by accepting that programmers are neither clueless drones that need a static compiler to babysit them all the time, nor omnipotent gods; they are just humans. George -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys."
You mean static like ML? Python's very acceptable. It's why I continue to choose it (and Logix does!). Free form yet structured. It strikes very good balances. The problem is, white-space doesn't mean anything. I addressed M. Santagada about it. I was trying to, but hit the absence of parser. So what do we make it mean? Can't do this: if exists fname... Because of that: loptosize self.graphic They must both map to: if fname.exists() #wrong and self.graphic.loptosize() -or- if exists( fname ) and loptosize( self.graphic ) #wrong instead I'm shooting for: if exists( fname ) and self.graphic.loptosize() Can't have both. Possibilities, silliest first: - Rule that functions that end in `s' are predicates not imperatives (-is- this not -do- this). No. - Rule that functions in Boolean expressions are the former form, and otherwise the latter. It sort of works, but unfortunately, loptosize() might return a value, and you get: if loptosize self.graphic: -mapping to- if loptosize( self.graphic ), which is not what you mean. - Only permit mapping on one, not both. if fname exists: -map to- if exists( fname ): -or- loptosize self.graphic -map to- self.graphic.loptosize() In other words, take whitespace to mean -either- membership retrievals -or- global function references; and don't permit the other. Last but not least, - Actively check which interpretation is "valid," and if uniquely determined, use that. This takes us well past the realm of syntax, however, into semantics. (Language does too, after all.) In the case where fname has an exists() attribute -and- the user does `from os.path import exist', raise an AmbiguityException at run-time. The fully-qualified call is still available to writer; this is an optional change of scenery, good for the eyes and fingers. Don't use it if it's ambiguous. Don't use it if you have too much to keep track of, either. Even still, we need not delay evaluation until run-time completely. Rather, parse to AmbiguousStmt( Tok1, Tok2 ), check for colliding tokens later, and have both FuncCall objects ready in bytecode. While languages move away from ambiguity [1], let's meet them half way and begin to accomodate it. It's what we speak. acb [1] The Lojban language. http://www.lojban.org/tiki/tiki-index.php?page=Home+Page&bl
Aaron Brady schrieb:
If you tell us what you mean with "expose"... the module is written in C and is not much more than a wrapper around Python's own parser, which is written in C too. If you are looking for a Python parser written in Python, you may want to look at the PyPy project's implementation. Georg
On Fri, May 11, 2007 at 09:29:22AM +0200, Georg Brandl wrote:
Hi, I see: def parsesuite(self, text): """Return a modified parse tree for the given suite text.""" return self.transform(parser.suite(text)) in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/compiler/transformer .py?revision=39456&view=markup and ...future.py 39456 misc.py 39456 pyassem.py 39456 pycodegen.py 39456... in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/compiler/ as well as os.py 39456 os2emxpath.py 39456 pdb.doc 39456 pdb.py 39456 in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/ . Where, exactly?
Aaron Brady wrote:
First of all, stop top posting, it makes it hard to reply to you. Second of all, I doubt this will at all aide you in whatever quest you are on, but the place you are looking for is: /pypy/interpreter/pyparser/pythonparse.py I think the link to EasyExtend was the most logical one.. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
Aaron Brady wrote:
But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module?
I can understand there being reluctance to expose what are currently internal details of this module, thereby effectively freezing them. -- Greg
I didn't realize they were changing so dynamically. But then, plenty of the modules have parallel Python and C implementations. I suspect the true reason lies more with Sakkis' post [5/10 23:26 us central]. A mimetic structure such as Python will sit somewhere between restriction and liberty. Best to be deliberate in choosing a place on the continuum. But where, exactly? Discouraging customized syntax is one thing. Prohibiting it altogether is another extreme. The current positioning lies with the latter. Put `parser' in to encourage the adventurous explorer, -while- keeping native dynamic constructs disabled in order to keep up unity. I do not hold that we lift all restrictions. Rather, merely -reduce- the number of hoops you must jump through to get at Python internals. If you think that everybody will jump-to and create their own Python the very first day you let a second ray of light shine in, you've underestimated Python. For one thing, we -want- to stick together, and will on our own. Present the option, and you'll only get better suggestions, thenceforth. The current state is too restrictive.
On 5/11/07, Aaron Brady <castironpi@comcast.net> wrote:
What on earth is a "mimetic structure"? Please keep the jargon understandable for the rest of us, at least if you want to be heard.
Depends on which internals you're talking about. Most internals are very close to the surface. Syntax happens to be hermetic though. Perhaps you need to find a different language for what you want?
That's easy for you to say. Have you tried (*seriously* tried) to specify such a thing? (For Python, maintaining full backwards compatibility.) In this community, code talks. Good understandable specs are sometimes allowed to speak. Wild ideas, especially if they involve "let others figure out how to design and implement my idea, but I need it now" are shown the door. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
What on earth is a "mimetic structure"? Please keep the jargon
Any kind of framework. Policies, axioms, etc. A bit of a stretch.
Good understandable specs are sometimes allowed to speak.
Here is the potential seed of compromise.
The ASTVisitor raises a SyntaxError prior to execution.
On 5/10/07, Aaron Brady <castironpi@comcast.net> wrote:
There is no universally accepted answer to this question. Each language positions itself (deliberately or by accident) somewhere in the spectrum between total bondage and total freedom. Static typing proponents find that dynamic typing is already "too much freedom", let alone programmable syntax. Those that don't believe there is such a thing as "too much freedom" tend to climb their way up in the language ecosystem, until they discover Lisp and reach nirvana. Python keeps a happy medium by accepting that programmers are neither clueless drones that need a static compiler to babysit them all the time, nor omnipotent gods; they are just humans. George -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys."
You mean static like ML? Python's very acceptable. It's why I continue to choose it (and Logix does!). Free form yet structured. It strikes very good balances. The problem is, white-space doesn't mean anything. I addressed M. Santagada about it. I was trying to, but hit the absence of parser. So what do we make it mean? Can't do this: if exists fname... Because of that: loptosize self.graphic They must both map to: if fname.exists() #wrong and self.graphic.loptosize() -or- if exists( fname ) and loptosize( self.graphic ) #wrong instead I'm shooting for: if exists( fname ) and self.graphic.loptosize() Can't have both. Possibilities, silliest first: - Rule that functions that end in `s' are predicates not imperatives (-is- this not -do- this). No. - Rule that functions in Boolean expressions are the former form, and otherwise the latter. It sort of works, but unfortunately, loptosize() might return a value, and you get: if loptosize self.graphic: -mapping to- if loptosize( self.graphic ), which is not what you mean. - Only permit mapping on one, not both. if fname exists: -map to- if exists( fname ): -or- loptosize self.graphic -map to- self.graphic.loptosize() In other words, take whitespace to mean -either- membership retrievals -or- global function references; and don't permit the other. Last but not least, - Actively check which interpretation is "valid," and if uniquely determined, use that. This takes us well past the realm of syntax, however, into semantics. (Language does too, after all.) In the case where fname has an exists() attribute -and- the user does `from os.path import exist', raise an AmbiguityException at run-time. The fully-qualified call is still available to writer; this is an optional change of scenery, good for the eyes and fingers. Don't use it if it's ambiguous. Don't use it if you have too much to keep track of, either. Even still, we need not delay evaluation until run-time completely. Rather, parse to AmbiguousStmt( Tok1, Tok2 ), check for colliding tokens later, and have both FuncCall objects ready in bytecode. While languages move away from ambiguity [1], let's meet them half way and begin to accomodate it. It's what we speak. acb [1] The Lojban language. http://www.lojban.org/tiki/tiki-index.php?page=Home+Page&bl
Aaron Brady schrieb:
If you tell us what you mean with "expose"... the module is written in C and is not much more than a wrapper around Python's own parser, which is written in C too. If you are looking for a Python parser written in Python, you may want to look at the PyPy project's implementation. Georg
On Fri, May 11, 2007 at 09:29:22AM +0200, Georg Brandl wrote:
Hi, I see: def parsesuite(self, text): """Return a modified parse tree for the given suite text.""" return self.transform(parser.suite(text)) in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/compiler/transformer .py?revision=39456&view=markup and ...future.py 39456 misc.py 39456 pyassem.py 39456 pycodegen.py 39456... in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/compiler/ as well as os.py 39456 os2emxpath.py 39456 pdb.doc 39456 pdb.py 39456 in https://codespeak.net/viewvc/pypy/dist/lib-python/2.4.1/ . Where, exactly?
Aaron Brady wrote:
First of all, stop top posting, it makes it hard to reply to you. Second of all, I doubt this will at all aide you in whatever quest you are on, but the place you are looking for is: /pypy/interpreter/pyparser/pythonparse.py I think the link to EasyExtend was the most logical one.. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
Aaron Brady wrote:
But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module?
I can understand there being reluctance to expose what are currently internal details of this module, thereby effectively freezing them. -- Greg
I didn't realize they were changing so dynamically. But then, plenty of the modules have parallel Python and C implementations. I suspect the true reason lies more with Sakkis' post [5/10 23:26 us central]. A mimetic structure such as Python will sit somewhere between restriction and liberty. Best to be deliberate in choosing a place on the continuum. But where, exactly? Discouraging customized syntax is one thing. Prohibiting it altogether is another extreme. The current positioning lies with the latter. Put `parser' in to encourage the adventurous explorer, -while- keeping native dynamic constructs disabled in order to keep up unity. I do not hold that we lift all restrictions. Rather, merely -reduce- the number of hoops you must jump through to get at Python internals. If you think that everybody will jump-to and create their own Python the very first day you let a second ray of light shine in, you've underestimated Python. For one thing, we -want- to stick together, and will on our own. Present the option, and you'll only get better suggestions, thenceforth. The current state is too restrictive.
On 5/11/07, Aaron Brady <castironpi@comcast.net> wrote:
What on earth is a "mimetic structure"? Please keep the jargon understandable for the rest of us, at least if you want to be heard.
Depends on which internals you're talking about. Most internals are very close to the surface. Syntax happens to be hermetic though. Perhaps you need to find a different language for what you want?
That's easy for you to say. Have you tried (*seriously* tried) to specify such a thing? (For Python, maintaining full backwards compatibility.) In this community, code talks. Good understandable specs are sometimes allowed to speak. Wild ideas, especially if they involve "let others figure out how to design and implement my idea, but I need it now" are shown the door. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
What on earth is a "mimetic structure"? Please keep the jargon
Any kind of framework. Policies, axioms, etc. A bit of a stretch.
Good understandable specs are sometimes allowed to speak.
Here is the potential seed of compromise.
The ASTVisitor raises a SyntaxError prior to execution.
participants (7)
-
Aaron Brady -
Aurélien Campéas -
Georg Brandl -
George Sakkis -
Greg Ewing -
Guido van Rossum -
Scott Dial