Re: [Python-Dev] AST manipulation and source code generation
On 5/24/05, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > Would there be any interest in extending the compiler package with tools > for AST transformations and for emitting Python source code from ASTs? Sure. Eventually, we'll have to figure out how to unify the compiler package AST and the ast-branch AST, but don't let that delay you now. > I was experimenting with possible translations for exception chaining > and wanted to run some automated tests, so i started playing around > with the compiler package to do source-to-source transformations. > Then i started working on a way to do template-based substitution of > ASTs and a way to spit source code back out, and i'm wondering if > that might be good for experimenting with future Python features. > > (If there's already stuff out there for doing this, let me know -- > i don't intend to duplicate existing work.) I don't know of any existing work, but it certainly sounds useful. Jeremy ___ 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] Localized Type Inference of Atomic Types in Python
My thesis, "Localized Type Inference of Atomic Types in Python", was successfully defended today for my MS in Computer Science at the California Polytechnic State University, San Luis Obispo. With that stamp of approval I am releasing it to the world. You can grab a copy at http://www.drifty.org/thesis.pdf . For those of you who attended my talk at PyCon 2005 this is the thesis that stemmed from the presented data. As of this exact moment I am not planning to release the source code mainly because it's a mess, I am not in the mood to pull the patches together, and the last thing I want happening is people finding mistakes in the code. =) But if enough people request the source I will take the time to generate a tar.bz2 file of patches against the 2.3.4 source release and put them up somewhere. Below is the abstract culled directly from the thesis itself. -Brett C. - ABSTRACT Types serve multiple purposes in programming. One such purpose is in providing information to allow for improved performance. Unfortunately, specifying the types of all variables in a program does not always fit within the design of a programming language. Python is a language where specifying types does not fit within the language design. An open source, dynamic programming language, Python does not support type specifications of variables. This limits the opportunities in Python for performance optimizations based on type information compared to languages that do allow or require the specification of types. Type inference is a way to derive the needed type information for optimizations based on types without requiring type specifications in the source code of a program. By inferring the types of variables based on flow control and other hints in a program, the type information can be derived and used in a constructive manner. This thesis is an exploration of implementing a type inference algorithm for Python without changing the semantics of the language. It also explores the benefit of adding type annotations to method calls in order to garner more type information. ___ 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] Localized Type Inference of Atomic Types in Python
"Brett C." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > My thesis, "Localized Type Inference of Atomic Types in Python", was > successfully defended today for my MS in Computer Science at the > California > Polytechnic State University, San Luis Obispo. Woo hoo. Congratulations. Terry J. Reedy ___ 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] Decimal FAQ
On 5/22/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Some of the private email I've received indicates a need for a decimal
> FAQ that would shorten the module's learning curve.
Nice FAQ, but where we should put it? It's kinda for advanced Decimal users...
> A. Some users prefer to abbreviate the constructor to just a single
> letter:
>
> >>> D = decimal.Decimal
> >>> D('1.23') + D('3.45')
> Decimal("4.68")
I'd add something like "However you'll note that this kind of use is
in examples, not in everyday code".
> >>> TWOPLACES = Decimal(10) ** -2
I always wrote it Decimal("0.01"), I think it's more clear.
> A more versatile approach is to create a separate class with Decimal
> objects as attributes (working in a "has-a" capacity rather than an
> "is-a" capacity) and then delegating the arithmetic to the Decimal
> class.
Currency will use the "has-a" method, ;)
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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
