Re: [Python-Dev] Modifying Grammar/grammar and other foul acts
Am 09.03.2010 14:42, schrieb Jeremy Hylton:
> On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind wrote:
>> Python-devs,
>>
>> I'm writing to you for some help in understanding the Python grammar. As an
>> excuse to deep dive into Python's tokenizer / grammar, I decided (as a
>> hideous, hideous joke) to want to allow braces where colons are allowed (as
>> flow control).
>>
>> Starting from PEP 306 (and branch r311), I hacked on Grammar/Grammer
>>
>> As a first example:
>>
>> funcdef: ('def' NAME parameters ['->' test] ':' suite |
>> 'def' NAME parameters ['->' test] '{' suite '}' )
>>
>> I reran Parser/pgen and the dfa changes, but python (3.1) when recompiled,
>> throws errors on things like:
>>
>> def a() { None }
>>
>> Strangely enough:
>>
>> lambdef: ( 'lambda' [varargslist] ':' test |
>>'lambda' [varargslist] '{' test '}' )
>>
>> works fine! I this simplely some difference between "test" and "suite".
>>
>> I have tried tackling this with gdb, looking at err_input clearly isn't
>> enough.
>>
>> (gdb) break err_input
>> (gdb) break PyParser_ASTFromString
>> import sys
>> b = compile("def a() {pass}","sys.stdout","single")
>> # yet a simple grammar fix is enough for this!
>> c = compile("lambda x {None}","sys.stdout","single")
>>
>> I'm in over my head!
>
> You don't say what errors occur when you try to compile strings in
> your new language. You may have changed the Grammar, which allows you
> to tokenize the input. That isn't enough to get the input to compile.
> You also need to change the compiler to understand the new tokens.
In particular, many AST creation functions check for specific counts of
children on many nodes. I haven't checked, but in the case of the
"funcdef" rule, it may check for either 7 or 5 children to determine
whether the optional return annotation ['->' test] is present.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
Peter Portante wrote: > http://code.google.com/p/re2/ > > On 3/11/10 8:52 PM, "Neal Becker" wrote: > >> http://swtch.com/~rsc/regexp/regexp1.html Both interesting links. I'll add another one to the list: http://google-opensource.blogspot.com/2010/03/re2-principled-approach-to-regular.html To bring this on-topic for python-dev by considering how it could apply to Python's default re engine, I think the key issue is that any updates to the default engine would need to remain backwards compatible with all of the tricks that re2 doesn't support. There are major practical problems associated with making such a leap directly (Google's re2 engine is in C++ rather than C and we'd have to keep the existing implementation around regardless to handle the features that re2 doesn't support). I would say it is better to let re2 bake for a while and see if anyone is motivated to come up with Python bindings for it and release them on PyPI. Once that happens (and assuming the bindings earn a good reputation), the first step towards integration would be to include a "See Also" in the re module documentation to point people towards the more limited (but more robust) regex engine implementation. The next step would probably be a hybrid third party library that exploits the NFA approach when it can, but resorts to backtracking when it has to in order to handle full regex functionality. (Although developers would need to be able to disable the backtracking support in order to restore re2's guarantees of linear time execution) Only once such a hybrid library had been proven in practice could the default re module be considered for possible update. Basically, I see some interesting ideas there, but I don't see anything that will impact the Python core or standard library in the short term. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: > Peter Portante wrote: >> http://code.google.com/p/re2/ >> >> On 3/11/10 8:52 PM, "Neal Becker" wrote: >> >>> http://swtch.com/~rsc/regexp/regexp1.html > > Both interesting links. I'll add another one to the list: > http://google-opensource.blogspot.com/2010/03/re2-principled-approach-to-regular.html > > To bring this on-topic for python-dev by considering how it could apply > to Python's default re engine, I think the key issue is that any updates > to the default engine would need to remain backwards compatible with all > of the tricks that re2 doesn't support. > > There are major practical problems associated with making such a leap > directly (Google's re2 engine is in C++ rather than C and we'd have to > keep the existing implementation around regardless to handle the > features that re2 doesn't support). > > I would say it is better to let re2 bake for a while and see if anyone > is motivated to come up with Python bindings for it and release them on > PyPI. Once that happens (and assuming the bindings earn a good > reputation), the first step towards integration would be to include a > "See Also" in the re module documentation to point people towards the > more limited (but more robust) regex engine implementation. > > The next step would probably be a hybrid third party library that > exploits the NFA approach when it can, but resorts to backtracking when > it has to in order to handle full regex functionality. (Although > developers would need to be able to disable the backtracking support in > order to restore re2's guarantees of linear time execution) > > Only once such a hybrid library had been proven in practice could the > default re module be considered for possible update. > > Basically, I see some interesting ideas there, but I don't see anything > that will impact the Python core or standard library in the short term. Agreed on the whole. However, it might be interesting to explore the "hybrid mode" using some of the older, C-based libraries referenced by the original (Russ Cox) article, e.g. Rob Pike's Unicode-aware 1992 implmentation, as ported for Unix: http://swtch.com/plan9port/unix/ Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuac7AACgkQ+gerLs4ltQ6t3wCgxQPsnpbyE1N9BEGg7nHqcBVP q04AnA6RMJw83+uc5u6Oyud89SXEoP5C =+0aL -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
I have some regex-intensive Python that might benefit from this, but I don't think I have enough skill to do a set of Python bindings. An ideal first cut would be to enable this: import re2 as re I live in hope... Brent L ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyPy 1.2, JIT included
== PyPy 1.2: Just-in-Time Compilation == PyPy 1.2 has been released. The highlight of this release is to be the first that ships with a Just-in-Time compiler that is known to be faster than CPython (and unladen swallow) on some real-world applications (or the best benchmarks we could get for them). The main theme for the 1.2 release is speed. Main site: http://pypy.org/ The JIT is stable and we don't observe crashes. Nevertheless we would recommend you to treat it as beta software and as a way to try out the JIT to see how it works for you. Highlights of This Release == * The JIT compiler. * Various interpreter optimizations that improve performance as well as help save memory. * Introducing a new PyPy website at http://pypy.org/ , made by tav and improved by the PyPy team. * Introducing http://speed.pypy.org/ , a new service that monitors our performance nightly, made by Miquel Torres. * There will be ubuntu packages on "PyPy's PPA" made by Bartosz Skowron; however various troubles prevented us from having them as of now. Known JIT problems (or why you should consider this beta software): * The only supported platform is 32bit x86 for now, we're looking for help with other platforms. * It is still memory-hungry. There is no limit on the amount of RAM that the assembler can consume; it is thus possible (although unlikely) that the assembler ends up using unreasonable amounts of memory. If you want to try PyPy, go to the "download page" on our excellent new site at http://pypy.org/download.html and find the binary for your platform. If the binary does not work (e.g. on Linux, because of different versions of external .so dependencies), or if your platform is not supported, you can try building from the source. What is PyPy? = Technically, PyPy is both a Python interpreter implementation and an advanced compiler, or more precisely a framework for implementing dynamic languages and generating virtual machines for them. The focus of this release is the introduction of a new transformation, the JIT Compiler Generator, and its application to the Python interpreter. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far as it has without the coding, feedback and general support from numerous people. The PyPy release team, Armin Rigo, Maciej Fijalkowski and Amaury Forgeot d'Arc Together with Antonio Cuni, Carl Friedrich Bolz, Holger Krekel and Samuele Pedroni and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
On Fri, Mar 12, 2010 at 8:12 AM, Nick Coghlan wrote: [snip] > To bring this on-topic for python-dev by considering how it could apply > to Python's default re engine, I think the key issue is that any updates > to the default engine would need to remain backwards compatible with all > of the tricks that re2 doesn't support. > > There are major practical problems associated with making such a leap > directly (Google's re2 engine is in C++ rather than C and we'd have to > keep the existing implementation around regardless to handle the > features that re2 doesn't support). I don't see why C++ would be a deal-breaker in this case, since it would be restricted to an extension module. > I would say it is better to let re2 bake for a while and see if anyone > is motivated to come up with Python bindings for it and release them on > PyPI. FWIW, re2 is heavily, heavily used in production at Google. Stabilizing any proposed Python bindings would be a good idea, but I'm not sure how much more "baking" re2's core functionality needs. > Once that happens (and assuming the bindings earn a good > reputation), the first step towards integration would be to include a > "See Also" in the re module documentation to point people towards the > more limited (but more robust) regex engine implementation. > > The next step would probably be a hybrid third party library that > exploits the NFA approach when it can, but resorts to backtracking when > it has to in order to handle full regex functionality. (Although > developers would need to be able to disable the backtracking support in > order to restore re2's guarantees of linear time execution) We considered such a hybrid approach for Unladen Swallow, but rejected it on the advice of the V8 team [1]: you end up maintaining two totally separate, incompatible regex engines; the hybrid system comes with interesting, possibly unintuitive performance/correctness issues when bailing from one implementation to another; performance is unstable as small changes are made to the regexes; and it's not obvious that enough Python regexes would benefit from re2's performance/restrictions tradeoff to make such a hybrid system worthwhile in the long term. (There is no representative corpus of real-world Python regexes weighted for dynamic execution frequency to use in assessing such tradeoffs empirically like there is for JavaScript.) re2 is very useful when you want to run user-provided regexes and want to protect your backends against pathological/malicious regex input, but I'm not sure how applicable it is to Python. I think there are more promising strategies to improve regex performance, such as reusing the new JIT infrastructure to JIT-compile regular expressions to machine code (along the lines of V8's irregexp). Some work has already been done in this direction, and I'd be thrilled to mentor any GSoC students interested in working on such a project this summer. Lastly, anyone interested in working on Python regex performance should take a look at the regex benchmarks in the standard benchmark suite [2]. Thanks, Collin Winter [1] - http://blog.chromium.org/2009/02/irregexp-google-chromes-new-regexp.html#c4843826268005492354 [2] - http://hg.python.org/benchmarks/file/5b8fe389710b/performance ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
>> There are major practical problems associated with making such a leap >> directly (Google's re2 engine is in C++ rather than C and we'd have >> to keep the existing implementation around regardless to handle the >> features that re2 doesn't support). Collin> I don't see why C++ would be a deal-breaker in this case, since Collin> it would be restricted to an extension module. Traditionally Python has run on some (minority) platforms where C++ was unavailable. While the re module is a dynamically linked extension module and thus could be considered "optional", I doubt anybody thinks of it as optional nowadays. It's used in the regression test suite anyway. It would be tough to run unit tests on such minority platforms without it. You'd have to maintain both the current sre implementation and the new re2 implementation for a long while into the future. As I was reading the code I thought, "Great! This stuff is so simple. It's even all written in C." Then I looked at the re2 page. :-( Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote: >The remaining open question to my mind is whether or not there should be >a -X option to control the bytecode generation. E.g.: > >-Xcache_bytecode=no (don't write bytecode files at all) -B and $PYTHONDONTWRITEBYTECODE will still be supported and serve this use case. >-Xcache_bytecode=file (write a classic "foo.pyc" file) >-Xcache_bytecode=dir (write to the "__pycache__" directory) > >With cache_bytecode=dir being the default for future releases. I believe we've decided /not/ to support creation of bytecode-only distributions out of the box. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
On Fri, Mar 12, 2010 at 11:29 AM, wrote: > > >> There are major practical problems associated with making such a leap > >> directly (Google's re2 engine is in C++ rather than C and we'd have > >> to keep the existing implementation around regardless to handle the > >> features that re2 doesn't support). > > Collin> I don't see why C++ would be a deal-breaker in this case, since > Collin> it would be restricted to an extension module. > > Traditionally Python has run on some (minority) platforms where C++ was > unavailable. While the re module is a dynamically linked extension module > and thus could be considered "optional", I doubt anybody thinks of it as > optional nowadays. It's used in the regression test suite anyway. It would > be tough to run unit tests on such minority platforms without it. You'd > have to maintain both the current sre implementation and the new re2 > implementation for a long while into the future. re2 is not a full replacement for Python's current regex semantics: it would only serve as an accelerator for a subset of the current regex language. Given that, it makes perfect sense that it would be optional on such minority platforms (much like the incoming JIT). Collin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C++
Le Fri, 12 Mar 2010 13:29:09 -0600, [email protected] a écrit : > > Traditionally Python has run on some (minority) platforms where C++ > was unavailable. Is this concern still valid? We are in the 2010s now. I'm not saying I want us to put some C++ in the core interpreter, but the portability argument sounds a little old... Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
On Mar 12, 2010, at 05:03 PM, Antoine Pitrou wrote: >Le Fri, 12 Mar 2010 13:29:09 -0600, >[email protected] a écrit : >> >> Traditionally Python has run on some (minority) platforms where C++ >> was unavailable. > >Is this concern still valid? Certainly not if Unladen Swallow blazes the trail. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
Antoine Pitrou: > Is this concern still valid? We are in the 2010s now. > I'm not saying I want us to put some C++ in the core interpreter, but > the portability argument sounds a little old... There are still viable platforms which only support subsets of C++. IIRC, Android does not support exceptions in C++. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On 12/03/2010 19:53, Barry Warsaw wrote: On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote: The remaining open question to my mind is whether or not there should be a -X option to control the bytecode generation. E.g.: -Xcache_bytecode=no (don't write bytecode files at all) -B and $PYTHONDONTWRITEBYTECODE will still be supported and serve this use case. -Xcache_bytecode=file (write a classic "foo.pyc" file) -Xcache_bytecode=dir (write to the "__pycache__" directory) With cache_bytecode=dir being the default for future releases. I believe we've decided /not/ to support creation of bytecode-only distributions out of the box. I thought Guido said on this topic [1]: " FWIW, I started at -1 and am still -1. I think the PEP is overreaching in this aspect; it does not serve the stated purpose of the PEP to make life easier for distros that share code between Python versions." Has something changed since then? Michael [1] http://mail.python.org/pipermail/python-dev/2010-March/098098.html -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On 12/03/2010 22:48, Michael Foord wrote: On 12/03/2010 19:53, Barry Warsaw wrote: On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote: The remaining open question to my mind is whether or not there should be a -X option to control the bytecode generation. E.g.: -Xcache_bytecode=no (don't write bytecode files at all) -B and $PYTHONDONTWRITEBYTECODE will still be supported and serve this use case. -Xcache_bytecode=file (write a classic "foo.pyc" file) -Xcache_bytecode=dir (write to the "__pycache__" directory) With cache_bytecode=dir being the default for future releases. I believe we've decided /not/ to support creation of bytecode-only distributions out of the box. I thought Guido said on this topic [1]: Ok - so oops, I misunderstood. I'll go back into my corner now. :-) All the best, Michael " FWIW, I started at -1 and am still -1. I think the PEP is overreaching in this aspect; it does not serve the stated purpose of the PEP to make life easier for distros that share code between Python versions." Has something changed since then? Michael [1] http://mail.python.org/pipermail/python-dev/2010-March/098098.html -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On Mar 12, 2010, at 10:48 PM, Michael Foord wrote: >On 12/03/2010 19:53, Barry Warsaw wrote: >> I believe we've decided /not/ to support creation of bytecode-only >> distributions out of the box. >> > >I thought Guido said on this topic [1]: > >" FWIW, I started at -1 and am still -1. I think the PEP is overreaching >in this aspect; it does not serve the stated purpose of the PEP to >make life easier for distros that share code between Python versions." > >Has something changed since then? Nope, sorry I should have been clearer. *creation* is the key here. As per BDFL pronouncement, we'll support reading pyc-only modules just like we do today. This is in PEP 3147. We won't support creating them though. BTW, I'm actually starting to work on the implementation now, so if you want to play along: % bzr branch lp:~barry/python/pep3147 -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
On Fri, Mar 12, 2010 at 2:18 PM, Neil Hodgson wrote: > Antoine Pitrou: > >> Is this concern still valid? We are in the 2010s now. >> I'm not saying I want us to put some C++ in the core interpreter, but >> the portability argument sounds a little old... > > There are still viable platforms which only support subsets of C++. > IIRC, Android does not support exceptions in C++. Looks like they'll be getting exceptions "soon": http://groups.google.com/group/android-ndk/browse_thread/thread/89db67ed1fbf6450/4de3dd6105eb26ce?#4de3dd6105eb26ce But yeah, thanks for the concrete example, and I'd agree that Python should compile with -fno-exceptions, for a couple more years at least. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
Am 12.03.2010 20:29, schrieb [email protected]: > > >> There are major practical problems associated with making such a leap > >> directly (Google's re2 engine is in C++ rather than C and we'd have > >> to keep the existing implementation around regardless to handle the > >> features that re2 doesn't support). > > Collin> I don't see why C++ would be a deal-breaker in this case, since > Collin> it would be restricted to an extension module. > > Traditionally Python has run on some (minority) platforms where C++ was > unavailable. While the re module is a dynamically linked extension module > and thus could be considered "optional", I doubt anybody thinks of it as > optional nowadays. Actually, _sre is a builtin module by default since at least Python 2.5. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
Collin> re2 is not a full replacement for Python's current regex Collin> semantics: it would only serve as an accelerator for a subset of Collin> the current regex language. Given that, it makes perfect sense Collin> that it would be optional on such minority platforms (much like Collin> the incoming JIT). Sure, but over the years Python has supported at least four different regular expression modules that I'm aware of (regex, regexp, and the current re module with different extension modules underneath it, perhaps there were others). During some of that time more than one module was distributed with Python proper. I think the desire today would be that only one regular expression module be distributed with Python (that would be my vote anyway). Getting people to move off the older libraries was difficult. If re2 can't replace sre under the covers than I think it belongs in PyPI, not the Python distribution. That said, that suggests to me that a different NFA or DFA implementation written in C would replace sre, one not written in C++. Hopefully that provides some context for my earlier response. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] interesting article on regex performance
On 12 Mar 2010, at 15:22, [email protected] wrote: > > Collin> re2 is not a full replacement for Python's current regex > Collin> semantics: it would only serve as an accelerator for a subset of > Collin> the current regex language. Given that, it makes perfect sense > Collin> that it would be optional on such minority platforms (much like > Collin> the incoming JIT). > > Sure, but over the years Python has supported at least four different > regular expression modules that I'm aware of (regex, regexp, and the current > re module with different extension modules underneath it, perhaps there were > others). During some of that time more than one module was distributed with > Python proper. I think the desire today would be that only one regular > expression module be distributed with Python (that would be my vote anyway). > Getting people to move off the older libraries was difficult. If re2 can't > replace sre under the covers than I think it belongs in PyPI, not the Python > distribution. That said, that suggests to me that a different NFA or DFA > implementation written in C would replace sre, one not written in C++. re2 would be a supplement to re -- it is not a replacement, and Python would run fine if it's not present on some platforms. It's like a floating-point processor: you can do all math you need with just an integer processor. But if you have an FPU present, then it makes sense to use it for the FP operations. Jared ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
On Fri, Mar 12, 2010 at 4:03 PM, Antoine Pitrou wrote: > Le Fri, 12 Mar 2010 13:29:09 -0600, > [email protected] a écrit : > > > > Traditionally Python has run on some (minority) platforms where C++ > > was unavailable. > > Is this concern still valid? We are in the 2010s now. > I'm not saying I want us to put some C++ in the core interpreter, but > the portability argument sounds a little old... > One area where this _may_ be a problem is with embedded systems. I believe there are some instances where folks have built Python into an embedded system (with an RTOS say VxWorks, Symbian, QNX Neutrino, Nucleus, etc...) where C++ is not always the easiest to develop in. Admittedly, though, these types of systems are by far a minority with respect to Python. Just thought I would mention it anyhow. -- Meador ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
Antoine> [email protected] a écrit : >> >> Traditionally Python has run on some (minority) platforms where C++ >> was unavailable. Antoine> Is this concern still valid? We are in the 2010s now. Like I said, *minority* platforms. Here are some which come to mind as quite possibly not supporting C++ well, if at all, yet all have some dialect of Python available: Windows CE: http://sourceforge.net/projects/pythonce/ Palm: http://pippy.sourceforge.net/ iPod: http://ciberjacobo.com/python-ipod OS/2: http://www.andymac.org/ QNX: http://sourceforge.net/projects/pyqnx/ If all you care about are mainstream Windows, Unix/Linux and Mac OSX environments then C++ is no problem. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++
On Fri, Mar 12, 2010 at 7:54 PM, wrote: > Antoine> [email protected] a écrit : > >> > >> Traditionally Python has run on some (minority) platforms where C++ > >> was unavailable. > > Antoine> Is this concern still valid? We are in the 2010s now. > > Like I said, *minority* platforms. Here are some which come to mind as > quite possibly not supporting C++ well, if at all, yet all have some dialect > of Python available: > > Windows CE: http://sourceforge.net/projects/pythonce/ http://www.wirelessdevnet.com/channels/pda/training/vcce.html > Palm: http://pippy.sourceforge.net/ http://prc-tools.sourceforge.net/ > iPod: http://ciberjacobo.com/python-ipod http://ipodlinux.org/wiki/Toolchain > OS/2: http://www.andymac.org/ I can't find a modern c++ compiler for OS/2. Then again, your link only provides python 2.4. > QNX: http://sourceforge.net/projects/pyqnx/ http://www.qnx.com/products/tools/ > If all you care about are mainstream Windows, Unix/Linux and Mac OSX > environments then C++ is no problem. If you care about any of these minority platforms except OS/2, C++ is also available, as a google search for " C++" quickly finds. OS/2 might be available too; I just didn't look for very long. If you know of platforms that don't support particular features of C++, please link to documentation of that like Neil Hodgson did. If not, please stop spreading FUD. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
