Re: How to implement Varient/Tagged Unions/Pattern Matching in Python?
BTW, Please don't ask Why do you want to do like this No, I don't ask although it would be the interesting aspect for me ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: What does Guido want in a GUI toolkit for Python?
On 27 Jun., 23:06, Martin v. Löwis mar...@v.loewis.de wrote: I sorta' wish he'd just come out and say, This is what I think would be suitable for a GUI toolkit for Python: He is not in the business of designing GUI toolkits, but in the business of designing programming languages. So he abstains from specifying (or even recommending) a GUI library. ... which isn't all that different today. One might just take a look at JavaFX and how gracefully it handles declarative data flow a.k.a. data binding. The evolution of programming languages goes on, with or rather without Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0.1 and mingw
On 24 Jun., 00:59, smartmobili v.richo...@gmail.com wrote: I wanted to know if you have some patch to compile python 3.x on mingw platform because I found some but doesn't work very well : make gcc -o python.exe \ Modules/python.o \ libpython3.0.a-lm Could not find platform independent libraries prefix Could not find platform dependent libraries exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] Fatal Python error: Py_Initialize: can't initialize sys standard streams ImportError: No module named encodings.utf_8 I have some questions about posixmodule.c, config.c and makesetup, I can see in posixmodule that you define a INITFUNC like this : #if (defined(_MSC_VER) || defined(__WATCOMC__) || defined (__BORLANDC__)) !defined(__QNX__) #define INITFUNC PyInit_nt #define MODNAME nt #elif defined(PYOS_OS2) #define INITFUNC PyInit_os2 #define MODNAME os2 #else #define INITFUNC PyInit_posix #define MODNAME posix #endif So first I tried to add || defined(MINGW32) to declare a PyInit_nt but after config.c was still using PyInit_posix. How does makesetup choose to include one function or another ? So finally python is using PyInit_posix... and after any idea why I got the compilation error ? Why on earth do you want to compile Python 3.0.1? -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. and to a programming language that supports it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 20 Jun., 17:28, Stefan Behnel stefan...@behnel.de wrote: Kay Schluehr wrote: You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. and to a programming language that supports it. Maybe, yes. But many different concurrency models are supported by a larger number of programming languages in one way or another, so the choice of an appropriate library is often sufficient - and usually a lot easier than using the 'most appropriate' programming language. Matter of available skills, mostly. There's usually a lot less code to be written that deals with concurrency than code that implements what the person paying you makes money with, so learning a new library may be worth it, while learning a new language may not. Stefan This implies that people stay defensive concerning concurrency ( like me right now ) and do not embrace it like e.g. Erlang does. Sometimes there is a radical change in the way we design applications and a language is the appropriate medium to express it succinctly. Concurrency is one example, writing GUIs and event driven programs in a declarative style ( Flex, WPF, JavaFX ) is another one. In particular the latter group shows that new skills are adopted rather quickly. I don't see that a concurrency oriented language has really peaked though yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: unladen swallow: python and llvm
On 8 Jun., 00:31, bearophileh...@lycos.com wrote: ShedSkin (SS) is a beast almost totally different from CPython, SS compiles an implicitly static subset of Python to C++. So it breaks most real Python programs, and it doesn't use the Python std lib (it rebuilds one in C++ or compiled Python), and so on. SS may be useful for people that don't want to mess with the intricacies of Cython (ex-Pyrex) and its tricky reference count, to create compiled python extensions. Don't understand your Cython compliant. The only tricky part of Cython is the doublethink regarding Python types and C types. I attempted once to write a ShedSkin like code transformer from Python to Cython based on type recordings but never found the time for this because I have to work on EasyExtend on all fronts at the same time. Maybe next year or when Unladen Swallow becomes a success - never. The advantage of this approach over ShedSkin was that every valid Cython program is also a Python extension module, so one can advance the translator in small increments and still make continuous progress on the execution speed front. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On 3 Jun., 11:13, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message ad634d5d-
c0e4-479a-85ed-91c26d3bf...@c36g2000yqn.googlegroups.com, Kay Schluehr
wrote:
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern
C clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies
madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL?
What does the STL offer that Python doesn't already do more flexibly and
more simply?
I do not quite understand your concern? Wasn't the whole point of
Josephs post that he intended to create C++ bindings effectively s.t.
ctypes can be used?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On 3 Jun., 05:51, Lawrence D'Oliveiro l...@geek-
central.gen.new_zealand wrote:
In message h04bjd$n9...@hoshi.visyn.net, Sebastian Wiesner wrote:
Nick Craig-Wood – Mittwoch, 3. Juni 2009 00:29
That said I've used C++ with ctypes loads of times, but I always wrap
the exported stuff in extern C { } blocks.
No wonder, you have never actually used C++ with C types. An extern C
clause tells the compiler to generate C functions (more precisely,
functions that conform to the C ABI conventions), so effectively you're
calling into C, not into C++.
Seems like the only sane way to do it. In all other directions lies madness.
Yes but creating C stubs is also hard in presence of everything that
is not basic C++. How would you wrap the STL? I suspect one ends up in
creating a variant of SWIG and I wonder if it's not a good idea to
just use SWIG then.
--
http://mail.python.org/mailman/listinfo/python-list
Re: I need help building a data structure for a state diagram
On 24 Mai, 20:16, Matthew Wilson m...@tplus1.com wrote: I'm working on a really simple workflow for my bug tracker. I want filed bugs to start in an UNSTARTED status. From there, they can go to STARTED. From STARTED, bugs can go to FINISHED or ABANDONED. I know I can easily hard-code this stuff into some if-clauses, but I expect to need to add a lot more statuses over time and a lot more relationships. This seems like a crude state diagram. So, has anyone on this list done similar work? How should I design this so that users can add arbitrary new statuses and then define how to get to and from those statuses? TIA MAtt General answer: you can encode finite state machines as grammars. States as non-terminals and transition labels as terminals: UNSTARTED: 'start' STARTED STARTED: 'ok' FINISHED | 'cancel' ABANDONED ABANDONED: 'done' FINISHED: 'done' In some sense each state-machine is also a little language. -- http://mail.python.org/mailman/listinfo/python-list
Re: I need help building a data structure for a state diagram
On 25 Mai, 01:46, Matthew Wilson m...@tplus1.com wrote:
On Sun 24 May 2009 03:42:01 PM EDT, Kay Schluehr wrote:
General answer: you can encode finite state machines as grammars.
States as non-terminals and transition labels as terminals:
UNSTARTED: 'start' STARTED
STARTED: 'ok' FINISHED | 'cancel' ABANDONED
ABANDONED: 'done'
FINISHED: 'done'
In some sense each state-machine is also a little language.
I've never formally studied grammars, but I've worked through trivial
stuff that uses BNF to express ideas like
postal-address ::= name-part street-address zip-part
I don't really understand how to apply that notion to this statement:
UNSTARTED: 'start' STARTED
That doesn't seem to be BNF, and that's all I know about grammar stuff.
Some comments
1) The separator is arbitrary. You can use ':' or '-' or '::=' etc.
2) A full EBNF grammar can be described in itself:
GRAMMAR: RULE+
RULE: NAME ':' RHS
RHS: ALT ( '|' ALT )*
ALT: ITEM+
ITEM: '[' RHS ']' | ATOM [ '*' | '+' ]
ATOM: '(' RHS ')' | NAME | STRING
STRING: '' any* ''
NAME: char (digit | char)*
[A] zero or one repetition
A*zero or more repetitions
A+one or more repetitions
A|B A or B
A B first A next B
(A ..) parentheses for separation
A keyword A
In some sense all the words 'start', 'done', 'ok' etc. are keywords of
the language. If I actually attempted to use the grammar for parsing
it could parse a few sentences like:
'start ok done' or 'start cancel done'
and create parse trees [UNSTARTED, start, [STARTED, ok, [FINSIHED,
done]]] etc.
One can however use the Finite State Machine generated from the
grammar for totally different purposes: interpret each rule as a state
and the keywords as events that cause state transitions.
UNSTARTED -- start -- STARTED
STARTED -- ok -- FINISHED
STARTED -- cancel -- ABANDONED
FINISHED -- done -- .
ABANDONED -- done -- .
That's basically the same formal language with a different, more
intuitive notation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to get path.py ? http://www.jorendorff.com/ is down
On 21 Mai, 21:43, Jorge Vargas jorge.var...@gmail.com wrote: Hello. Anyone knows what is the problem with this package? apparently the author's site is down which prevents pip from installing it. I can download the zip and go from there but It seems most of the docs are gone with the site. The code comments shall be sufficient. It is a single not very complex module that basically unifies several stdlib APIs as methods of a string subclass. -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing Strings in Enclosed in Curly Braces
Since when is a list a number? Perhaps the help needs clarification, in line with the docs. Everyone is supposed to use reduce() here ;) Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: complementary lists?
On 29 Apr., 05:41, Ross ross.j...@gmail.com wrote: If I have a list x = [1,2,3,4,5,6,7,8,9] and another list that is a subset of x: y = [1,4,7] , is there a quick way that I could return the complementary subset to y z=[2,3,5,6,8,9] ? The reason I ask is because I have a generator function that generates a list of tuples and I would like to divide this list into complementary lists. z = [u for u in x if u not in y] or z = [u for u in x if u not in set(y)] Since you are dealing with tuples and a natural order might not be that relevant you can also set objects in the first place: z = x - y -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
Start to like blogging about your ideas, results and findings. Writing is a process of clarification of the mind. It doesn't matter much whether you design upfront, or mix coding and writing in an incremental process. If I could I'd just write specs, draft my ideas in Python in order to verify that I really know what I'm talking about and let others work out the details. Of course I'm not in the splendid position of a university professor or an intellectual capitalist. -- http://mail.python.org/mailman/listinfo/python-list
Re: compiler package vs parser
I realize that I probably ought to be trying this out with the newer ast stuff, but currently I am supporting code back to 2.3 and there's not much hope of doing it right there without using the compiler package. You might consider using the *builtin* parser module and forget about the compiler package if it is broken ( I take your word that it is ) or modern ast representations which aren't really necessary for Python anyway. import parser tree = parser.suite(def foo():\n print 42}\n) code = tree.compile() exec code foo() 42 This is also not 100% reliable ( at least not for all statements in all Python versions ) but it uses the internal parser/compiler and not a standard library compiler package that might not be that well maintained. -- http://mail.python.org/mailman/listinfo/python-list
Re: Domain Driven Design and Python
On 16 Apr., 19:44, José María josemariar...@gmail.com wrote: Hi, I've been searching for information about the application of DDD principles in Python and I did'nt found anything! Is DDD obvious in Python or is DDD inherent to static languages like Java or C#? If you couldn't find anything I conclude that no one in the Python community takes much care about mapping concepts like layers, entities, aggregates, value objects etc. onto Python or even feels that this improves the state of the art. I'm pretty sure though that DDD is not bound to a particular type system. -- http://mail.python.org/mailman/listinfo/python-list
Re: setuptools catch 22
On 16 Apr., 17:39, Mac bob.u...@gmail.com wrote: We've got ActiveState Python 2.6 installed on a Windows XP box, and I pulled down the latest archgenxml package (2.2) in order to get it running under this installation of Python. I unpacked the tarball for the package and tried running `python setup.py build' but got an ImportError exception: no module named setuptools. So back to Google, where I findhttp://pypi.python.org/pypi/setuptools, which says [For Windows] install setuptools using the provided .exe installer. I go down to the bottom of the page and I see that there is no .exe installer for Python 2.6. All there is for that version of Python is setuptools-0.6c9-py2.6.egg. I get the impression from the references to Python Eggs on the setuptools page that setuptools is a utility for installing Python Eggs. So we're supposed to use a utility that isn't installed yet to install that utility? Does anyone else understand how lame this is? Yes, but there is a known workaround: just download the mantioned setuptools egg and unpack it - it's basically just a zipped python package - and place it at your PYTHONPATH. Then it will also be found by every tool that imports setuptools. -- http://mail.python.org/mailman/listinfo/python-list
Re: compiler package vs parser
On 16 Apr., 11:41, Robin Becker ro...@reportlab.com wrote: Is the compiler package actually supposed to be equivalent to the parser module? No. The parser module creates a concrete parse tree ( CST ) whereas the compiler package transforms this CST into an AST for subsequent computations. In more recent versions those CST - AST transformations are performed by the runtime and the Python compiler uses those internally produced ASTs. The Python 2.6 API to ASTs is the ast module. -- http://mail.python.org/mailman/listinfo/python-list
Re: design question, metaclasses?
On 11 Apr., 20:15, Darren Dale dsdal...@gmail.com wrote: I am working on a project that provides a high level interface to hdf5 files by implementing a thin wrapper around h5py. I would like to generalize the project so the same API can be used with other formats, like netcdf or ascii files. The format specific code exists in File, Group and Dataset classes, which I could reimplement for each format. But there are other classes deriving from Group and Dataset which do not contain any format-specific code, and I would like to find a way to implement the functionality once and apply uniformly across supported formats. Seems like you are doing it wrong. The classical OO approach is to add more details / refining classes in subclasses instead of doing it the other way round and derive the less specific classes from the more specific ones. -- http://mail.python.org/mailman/listinfo/python-list
nonlocal in Python 2.6
I always wondered about the decision to omit the nonlocal statement from the Python 2.X series because it seems to be orthogonal to Python 2.5. Are there any chances for it to be back ported? -- http://mail.python.org/mailman/listinfo/python-list
Re: Painful?: Using the ast module for metaprogramming
-It would be nice if decorators were passed a function's AST instead of a function object. As it is I have to use inspect.getsource to retrieve the source for the function in question, and then use ast.parse, which is a bit inefficient because the cpython parser has to already have done this once before. It doesn't matter that much though because the Python parser is very efficient and the decorator is applied only once. The PyGPU project used this approach when I remember it correctly: http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Generators/iterators, Pythonicity, and primes
On 5 Apr., 17:14, John Posner jjpos...@snet.net wrote: Kay Schluehr said: g = (lambda primes = []: (n for n in count(2) \ if (lambda n, primes: (n in primes if primes and n=primes[-1] \ else (primes.append(n) or True \ if all(n%p for p in primes if p = sqrt(n)) \ else False)))(n, primes)))() Um ... did you say easy? :-) This is prodigious, and it's definitely a solution to the generator-expression-only challenge I laid down. That's because it is *one* expression. The avoidance of named functions makes it look obfuscated or prodigious. Once it is properly dissected it doesn't look that amazing anymore. Start with: (n for n in count(2) if is_prime(n, primes)) The is_prime function has following implementation: def is_prime(n, primes): if primes and n=primes[-1]: return n in primes else: if all(n%p for p in primes if p = sqrt(n)): primes.append(n) return True else: return False But we need a lambda-fied function expression instead of the function definition. This yields: is_prime = lambda n, primes: (n in primes \ if primes and n=primes[-1] \ else (primes.append(n) or True \ if all(n%p for p in primes if p = sqrt(n)) \ else False)) Finally the trick with primes definition within an expression by means of an optional argument in the lambda is applied. But I think this is a case in which using a generator expression causes a loss in Pythonicity, rather than a gain. Many, many thanks for this! I think so too. The solution with the simple generator expression and the fully defined is_prime function may be just adequate. -- http://mail.python.org/mailman/listinfo/python-list
Re: Generators/iterators, Pythonicity, and primes
On 5 Apr., 18:47, John Posner jjpos...@snet.net wrote: Kay Schluehr wrote: That's because it is *one* expression. The avoidance of named functions makes it look obfuscated or prodigious. Once it is properly dissected it doesn't look that amazing anymore. Start with: (n for n in count(2) if is_prime(n, primes)) The is_prime function has following implementation: def is_prime(n, primes): if primes and n=primes[-1]: return n in primes else: if all(n%p for p in primes if p = sqrt(n)): primes.append(n) return True else: return False Your explication is excellent, Kay! In the is_prime() function, can't we omit the first three lines (if ... else), because it will *always* be the case that n exceeds all the primes we've gathered so far. Yes, sure. I developed is_prime as a standalone function with the primes list as a cache and just lambda-fied it. I've tested the code with these lines omitted -- both with the separate is_prime() function and with the generator-expression-only implementation. It seems to work fine. Ex: --- from itertools import count from math import sqrt g = (lambda primes = []: (n for n in count(2) if (lambda x, primes: (primes.append(x) or True if all(x%p for p in primes if p = sqrt(x)) else False) )(n, primes) ) )() This is of course much more accessible and doesn't even look weird. Regards -- http://mail.python.org/mailman/listinfo/python-list
Re: Generators/iterators, Pythonicity, and primes
Question: Is there a way to implement this algorithm using generator expressions only -- no yield statements allowed? Yes. Avoiding the yield statement is easy but one might eventually end up with two statements because one has to produce a side effect on the primes list. However we can use default parameters in lambdas and finally get a single expression which is a generator expression: g = (lambda primes = []: (n for n in count(2) \ if (lambda n, primes: (n in primes if primes and n=primes [-1] \ else (primes.append(n) or True \ if all(n%p for p in primes if p = sqrt(n)) \ else False)))(n, primes)))() assert g.next() == 2 assert g.next() == 3 assert g.next() == 5 assert g.next() == 7 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Goes Mercurial
On 1 Apr., 07:56, Lawrence D'Oliveiro l...@geek- central.gen.new_zealand wrote: In message 35d429fa-5d13-4703- a443-6a95c740c...@o6g2000yql.googlegroups.com, John Yeung wrote: Here's one that clearly expresses strong antipathy: http://mail.python.org/pipermail/python-dev/2009-March/087971.html There are lots of GUI- and Web-based front ends to Git. And look at on-line services like GitHub and Gitorious. The level of support for it is huge. Ironically Mercurials most popular UI frontend Tortoise is going to crash Python tools ( like Wing-IDE ) on Windows. That's a known issue for about a year and more and the developers are not inclined to fix it. This doesn't really increase my trust that Mercurials UI tools are of a higher quality than Git's no matter which platform is used. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Goes Mercurial
On 2 Apr., 15:05, David Smith d...@cornell.edu wrote: Kay Schluehr wrote: On 1 Apr., 07:56, Lawrence D'Oliveiro l...@geek- central.gen.new_zealand wrote: In message 35d429fa-5d13-4703- a443-6a95c740c...@o6g2000yql.googlegroups.com, John Yeung wrote: Here's one that clearly expresses strong antipathy: http://mail.python.org/pipermail/python-dev/2009-March/087971.html There are lots of GUI- and Web-based front ends to Git. And look at on-line services like GitHub and Gitorious. The level of support for it is huge. Ironically Mercurials most popular UI frontend Tortoise is going to crash Python tools ( like Wing-IDE ) on Windows. That's a known issue for about a year and more and the developers are not inclined to fix it. This doesn't really increase my trust that Mercurials UI tools are of a higher quality than Git's no matter which platform is used. The conflict between TortoiseHg and Wing IDE can be fixed by simply uninstalling the Tortoise Overlays. You loose the graphic overlay on folders, but otherwise everything works. --David Good to know. Uninstalling a major feature that enhances usability just to make it usable isn't much less ironic though. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 382: Namespace Packages
On 2 Apr., 17:32, Martin v. Löwis mar...@v.loewis.de wrote: I propose the following PEP for inclusion to Python 3.1. Please comment. Regards, Martin Abstract Namespace packages are a mechanism for splitting a single Python package across multiple directories on disk. In current Python versions, an algorithm to compute the packages __path__ must be formulated. With the enhancement proposed here, the import machinery itself will construct the list of directories that make up the package. Terminology === Within this PEP, the term package refers to Python packages as defined by Python's import statement. The term distribution refers to separately installable sets of Python modules as stored in the Python package index, and installed by distutils or setuptools. The term vendor package refers to groups of files installed by an operating system's packaging mechanism (e.g. Debian or Redhat packages install on Linux systems). The term portion refers to a set of files in a single directory (possibly stored in a zip file) that contribute to a namespace package. Namespace packages today Python currently provides the pkgutil.extend_path to denote a package as a namespace package. The recommended way of using it is to put:: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) int the package's ``__init__.py``. Every distribution needs to provide the same contents in its ``__init__.py``, so that extend_path is invoked independent of which portion of the package gets imported first. As a consequence, the package's ``__init__.py`` cannot practically define any names as it depends on the order of the package fragments on sys.path which portion is imported first. As a special feature, extend_path reads files named ``*.pkg`` which allow to declare additional portions. setuptools provides a similar function pkg_resources.declare_namespace that is used in the form:: import pkg_resources pkg_resources.declare_namespace(__name__) In the portion's __init__.py, no assignment to __path__ is necessary, as declare_namespace modifies the package __path__ through sys.modules. As a special feature, declare_namespace also supports zip files, and registers the package name internally so that future additions to sys.path by setuptools can properly add additional portions to each package. setuptools allows declaring namespace packages in a distribution's setup.py, so that distribution developers don't need to put the magic __path__ modification into __init__.py themselves. Rationale = The current imperative approach to namespace packages has lead to multiple slightly-incompatible mechanisms for providing namespace packages. For example, pkgutil supports ``*.pkg`` files; setuptools doesn't. Likewise, setuptools supports inspecting zip files, and supports adding portions to its _namespace_packages variable, whereas pkgutil doesn't. In addition, the current approach causes problems for system vendors. Vendor packages typically must not provide overlapping files, and an attempt to install a vendor package that has a file already on disk will fail or cause unpredictable behavior. As vendors might chose to package distributions such that they will end up all in a single directory for the namespace package, all portions would contribute conflicting __init__.py files. Specification = Rather than using an imperative mechanism for importing packages, a declarative approach is proposed here, as an extension to the existing ``*.pkg`` mechanism. The import statement is extended so that it directly considers ``*.pkg`` files during import; a directory is considered a package if it either contains a file named __init__.py, or a file whose name ends with .pkg. In addition, the format of the ``*.pkg`` file is extended: a line with the single character ``*`` indicates that the entire sys.path will be searched for portions of the namespace package at the time the namespace packages is imported. Importing a package will immediately compute the package's __path__; the ``*.pkg`` files are not considered anymore after the initial import. If a ``*.pkg`` package contains an asterisk, this asterisk is prepended to the package's __path__ to indicate that the package is a namespace package (and that thus further extensions to sys.path might also want to extend __path__). At most one such asterisk gets prepended to the path. extend_path will be extended to recognize namespace packages according to this PEP, and avoid adding directories twice to __path__. No other change to the importing mechanism is made; searching modules (including __init__.py) will continue to stop at the first module encountered. Discussion == With the addition of ``*.pkg`` files to the import mechanism, namespace packages can stop filling out the namespace package's
Re: Python Goes Mercurial
Meh. Use the command line like God intended. I'm sorry to say this Rhodri but there is probably no god ;) The reason I like overlays is that they are data displays that highlight changes without letting me do any action. The VCS works for me before I'm doing any work with it and that's a good thing because I'm *always* lazy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on language-level configuration support?
Discoverable, as in built-in tools that let you have the following conversation: Program, tell me all the things I can configure about you - Okay, here they all are. No digging through the source required. But this doesn't have any particular meaning. If I run a dir(obj) command all attributes of obj will be returned and I can be sure these are all. In C# I can reflect on attributes of an assembly which is a well defined entity. Program is not an entity. It's kind of a user interface name in StarTreck ( which prefers computer for this purpose though ). This way we cannot design systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Beazley on Generators
On 1 Apr., 07:03, Terry Reedy tjre...@udel.edu wrote: At PyCon2008, David Beazley presented an excellent talk on generators. Generator Tricks for Systems Programmershttp://www.dabeaz.com/generators/index.html At PyCon2009, he followed up with another talk on more advanced generator usage, which Guido commended on the python-ideas list: A Curious Course on Coroutines and Concurrencyhttp://dabeaz.com/coroutines/ I have just started (this one will take more than one sitting ;-) but it looks just as good. tjr There is just one thing I find disappointing. Since the talk is almost a compendium of advanced uses of generators I'm missing a reference to Peter Thatchers implementation of monads: http://www.valuedlessons.com/2008/01/monads-in-python-with-nice-syntax.html Peters implementation can be simplified but it already contains all relevant ideas. -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative Imports, why the hell is it so hard?
On 31 Mrz., 04:55, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: En Mon, 30 Mar 2009 21:15:59 -0300, Aahz a...@pythoncraft.com escribió: In article mailman.2591.1237922208.11746.python-l...@python.org, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: I'd recommend the oposite - use relative (intra-package) imports when possible. Explicit is better than implicit - and starting with 2.7 -when absolute import semantics will be enabled by default- you'll *have* to use relative imports inside a package, or fail. Really? I thought you would still be able to use absolute imports; you just won't be able to use implied relative imports instead of explicit relative imports. You're right, I put it wrongly. To make things clear, inside a package foo accessible thru sys.path, containing a.py and b.py: site-packages/ foo/ a.py b.py __init__.py Currently, the a module can import b this way: from foo import b import foo.b from . import b import b When implicit relative imports are disabled (from __future__ import absolute_import, or after 2.7 supposedly) the last one won't find b.py anymore. (I hope I put it right this time). -- Gabriel Genellina So it even breaks more code which is great ;) Do you know of any near or far past attempts to re-design the import system from the ground up? I do not mean a rather faithful and accessible reconstruction such as Brett Cannons work but a radical re- design which starts with a domain model and does not end with Loaders, Importers and Finders which are actually services that pretend to be objects. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on language-level configuration support?
On 30 Mrz., 15:40, jfager jfa...@gmail.com wrote: I've written a short post on including support for configuration down at the language level, including a small preliminary half-functional example of what this might look like in Python, available athttp://jasonfager.com/?p=440. The basic idea is that a language could offer syntactic support for declaring configurable points in the program. The language system would then offer an api to allow the end user to discover a programs configuration service, as well as a general api for providing configuration values. The included example implements the first bit and hints at the third, defining a function that looks up what variable its output will be assigned to and tries to find a corresponding value from a configuration source. It's very preliminary, but I hope it gives a flavor of the general idea. Any thoughts or feedback would be greatly appreciated. The problem with your idea is that those declared declaration points can be overlooked no matter how much syntactical support is added. Lets say a resource file is loaded and there are a few of the config- properties declared in modules you have written. Now an object wants to access a resource defined in the file and fails because the resource providing property could not be found since the property defining module wasn't loaded yet and the property couldn't register itself. That's why things are centralized as in optparse and the workflow is designed upfront or things are implemented locally and individual units have to take care of their own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative Imports, why the hell is it so hard?
On 31 Mrz., 18:48, s4g rafals...@gmail.com wrote: Hi, I was looking for a nice idiom for interpackage imports as I found this thread. Here come a couple of solutions I came up with. Any discussion is welcome. I assume the same file structure \ App | main.py +--\subpack1 | | __init__.py | | module1.py | +--\subpack2 | | __init__.py | | module2.py When you run main.py all imports relative to \App work fine, so the only problem is running a module from within a subpackage as a script. I therefore assume we want to run module1.py as a script, which wants to import module2. I hope the following solutions are self-evident = solution 1 -- in module1.py import sys, os if __name__ == '__main__': sys.path.append(os.path.normpath(__file__+'/../..')) import subpack2.module2 = solution 2 -- in subpack1/__init__.py import sys, os _top_package_level = 1 # with current package being level 0 _top_package = os.path.normpath(__file__ + '/..'*(_top_package_level +1)) if _top_package not in sys.path: sys.path.append(_top_package) -- in module1 or any module in the package, which requires import relative to the package top import __init__ import subpack2.module2 = solution 3 -- in package_import.py, somewhere on the PYTHONPATH ( perhaps in standard lib ;) def set_top_package(module, level): _top_package = os.path.normpath(module + '/..'*(level+1)) if _top_package not in sys.path: sys.path.append(_top_package) class absolute_import(object): def __init__(self, module, level): self.level = level self.module = module def __enter__(self): sys.path.insert( 0, os.path.normpath(self.module + '/..'*(self.level+1)) ) def __exit__(self, exc_type, exc_val, exc_tb): del sys.path[0] -- in module1 import package_import package_import.set_top_package(__file__, 1) import subpack2.module2 -- or in module1 import package_import with package_import.absolute_import(__file__, 1): import subpack2.module2 ... This and similar solutions ( see Istvan Alberts ) point me to a fundamental problem of the current import architecture. Suppose you really want to run a module as a script without a prior import from a module path: ...A\B\C python my_module.py then the current working directory C is added to sys.path which means that the module finder searches in C but C isn't a known package. There is no C package in sys.modules even if the C directory is declared as a package by placing an __init__.py file in it. Same goes of course with B and A. Although the ceremony has been performed basically correct the interpreter god is not pacified and doesn't respond. But why not? Because it looks up for *living* imported packages in the module cache ( in sys.modules ). I don't think there is any particular design idea behind it. The module cache is just a simple flat dictionary; a no-brainer to implement and efficient for look ups. But it counteracts a domain model. All you are left with is those Finders, Loaders and Importers in Brett Cannons importlib. Everything remains deeply mysterious and I don't wonder that it took long for him to work this out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative Imports, why the hell is it so hard?
On 31 Mrz., 20:50, Terry Reedy tjre...@udel.edu wrote: Nothing is added to sys.modules, except the __main__ module, unless imported (which so are on startup). Yes. The startup process is opaque but at least user defined modules are not accidentally imported. Although the ceremony has been performed basically correct the interpreter god is not pacified and doesn't respond. But the import 'ceremony' has not been performed. There is no import ceremony. Imports are just stated in the source. There is a package ceremony for whatever reasons. But why not? Because it looks up for *living* imported packages in the module cache ( in sys.modules ). I don't think there is any particular design idea behind it. The module cache is just a simple flat dictionary; a no-brainer to implement and efficient for look ups. This all dates to the time before packages and imports from zip files and such. But it counteracts a domain model. What is that? Object oriented programming. All you are left with is those Finders, Loaders and Importers in Brett Cannons importlib. Everything remains deeply mysterious and I don't wonder that it took long for him to work this out. And your proposal is? I have still more questions than answers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative Imports, why the hell is it so hard?
On 1 Apr., 00:38, Carl Banks pavlovevide...@gmail.com wrote: On Mar 31, 12:08 pm, Kay Schluehr kay.schlu...@gmx.net wrote: And your proposal is? I have still more questions than answers. That's obvious. Perhaps you should also refrain from making sweeping negative judgments about a system you have more questions than answers about. (Feel free to make sweeping negative judgments once you have the answers, though.) Carl Banks Diagnosing a problem means having a detailed cure? Wow, that's critical thinking I guess. O.K. I have got some ideas for a new import system and I'm going to blog about them within the next days. If I have some results I'll leave a notice in this thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative Imports, why the hell is it so hard?
On 25 Mrz., 05:56, Carl Banks pavlovevide...@gmail.com wrote: On Mar 24, 8:32 pm, Istvan Albert istvan.alb...@gmail.com wrote: On Mar 24, 9:35 pm, Maxim Khitrov mkhit...@gmail.com wrote: Works perfectly fine with relative imports. This only demonstrates that you are not aware of what the problem actually is. Try using relative imports so that it works when you import the module itself. Now run the module as a program. The same module that worked fine when you imported it will raise the exception: PEP 366 addresses this issue. Not the best solution, one that still involves boilerplate, but it is much less of a hack than your version, and at least it has the blessing of the language designers so it won't unceremoniously break at some point. Carl Banks A workaround that is hardly acceptable when we are working with / debugging 3rd party packages. Python was simpler without relative imports and occasional ambiguity resolutions by means of absolute imports. Unfortunately Brett Cannons reconstruction of import semantics comes a little late for Python 3 and I suppose we have to live with the current mess. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another form of dynamic import
On 25 Mrz., 15:23, Marco Nawijn naw...@gmail.com wrote: Hello, In short I would like to know if somebody knows if it is possible to re-execute a statement that raised an exception? I will explain the reason by providing a small introduction on why this might be nice in my case and some example code. I am using the python bindings to a *very* large C++ library. About 5000 classes divided over approx. 450 different packages are exposed through the Python interface. To reduce the number of import statements that need to be inserted and to limit the number of wildcard imports it would be very helpful if class names could be automatically imported from the proper module. There is no problem in finding out the proper module given a (valid) class name. As an example, look at the following statement aPoint = gp_Pnt(1.0, 0.0, 0.0) # Oops, this will raise a NameError, since # gp_Pnt class is unknown NameError: name 'gp_Pnt' is not defined As indicated, this will raise a NameError exception. What I would like to do is something like the following (pseudo-code): try: aPoint = gp_Pnt(1.0, 0.0, 0.0)[1] except NameError, e: name = e.args[0].split[1] if isValid(name): doImport(name) === Can I go back to statement [1] from this point? else: raise e There is no problem in catching the exception, finding out which name is unknown to python and check if this is a valid name for my library. My question is, is there any possibility of going back to the statement that raised the error, re-execute the statement and continue? Thanks for any thoughts and suggestions. Marco There is no call/cc continuation in Python when you are asking for such a thing. I wonder however why you don't try lazy attribute access? Instead of making a raw function call like that to gp_Pnt, one can thread all calls to the C++ system through an object that implements __getattr__ and loads new names incrementally if one is missing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python have certificate?
On 24 Mrz., 05:30, Steve Holden st...@holdenweb.com wrote: No, there is no certification for Python. Maybe in the future... O'Reilly School of Technology have plans to offer a Python certification. But I have to write the courses first :) If you're done with it I'd additionally suggest the honory title of a VIPP: Very Important Python Programmer. VIPPs receive a sticker with a Python logo and are immediately spotted this way by their numerous fans. Regards -- http://mail.python.org/mailman/listinfo/python-list
Re: what features would you like to see in 2to3?
On 22 Mrz., 20:39, Benjamin Peterson benja...@python.org wrote: It's GSoC time again, and I've had lots of interested students asking about doing on project on improving 2to3. What kinds of improvements and features would you like to see in it which student programmers could accomplish? It would suffice to write some proper 2to3 tutorial level documentation that explains how to extend 2to3 i.e. how to write some new fixers. Most of the stuff I came along was rather special and cheap student labor is hardly ever available or just in time. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to interface with C# without IronPython
On 16 Mrz., 23:06, Mudcat mnati...@gmail.com wrote: On Mar 13, 8:37 pm, Christian Heimes li...@cheimes.de wrote: Chris Rebert wrote: Haven't used it, butPythonfor .NET sounds like it might be what you want:http://pythonnet.sourceforge.net/ I've done some development for and with PythonDotNET. It's definitely the right thing. It works with .NET, Mono andPython2.4 to 2.6. Christian That looks exactly like what I'm searching for. I'll give it a shot. One question, the last update for that is back in '07. Do you know if it's still in active development? Thanks Don't think it's maintained right now. But be aware that it runs well for the current CLR 2.0. For using .NET 3.5 features you just have to add c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\ to your Python path and add assemblies with clr.AddReference as convenient. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to interface with C# without IronPython
On 17 Mrz., 16:22, Mudcat mnati...@gmail.com wrote: On Mar 17, 6:39 am, Kay Schluehr kay.schlu...@gmx.net wrote: On 16 Mrz., 23:06, Mudcat mnati...@gmail.com wrote: On Mar 13, 8:37 pm, Christian Heimes li...@cheimes.de wrote: Chris Rebert wrote: Haven't used it, butPythonfor .NET sounds like it might be what you want:http://pythonnet.sourceforge.net/ I've done some development for and with PythonDotNET. It's definitely the right thing. It works with .NET, Mono andPython2.4 to 2.6. Christian That looks exactly like what I'm searching for. I'll give it a shot. One question, the last update for that is back in '07. Do you know if it's still in active development? Thanks Don't think it's maintained right now. But be aware that it runs well for the current CLR 2.0. For using .NET 3.5 features you just have to add c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\ to your Python path and add assemblies with clr.AddReference as convenient. Based on the archived emails I know that it can work on Python 2.6, but it's not clear what modifications are necessary. I downloaded the source files to run independently, and that was capable of running with installs of Python 2.4 and 2.5. If I download the installer will it automatically recognize 2.6, or will I need to change paths and possibly re-compile? Thanks You'll have to change the BUILD option in the project settings of the Python.Runtime assembly. There is already a conditional compilation switch for Python 2.6 available in the source. So after this has been done it will build pythonnet for Python 2.6. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
On 6 Mrz., 02:53, bearophileh...@lycos.com wrote: This is an interesting post, it shows me that fitness plateau where design of Python syntax lives is really small, you can't design something just similar: http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort... Living on a small fitness plateau isn't good, even if it's very high, because it's evolutionary unstable :-( Indentation-wise Haskell syntax seems one of the very few local maxima that is close enough to the little fitness plateau where Python is. Bye, bearophile Here is a somewhat longer comment: http://fiber-space.de/wordpress/?p=121 Take it with a grain of salt and have much fun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
On 6 Mrz., 02:53, bearophileh...@lycos.com wrote: This is an interesting post, it shows me that fitness plateau where design of Python syntax lives is really small, you can't design something just similar: http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort... Living on a small fitness plateau isn't good, even if it's very high, because it's evolutionary unstable :-( Indentation-wise Haskell syntax seems one of the very few local maxima that is close enough to the little fitness plateau where Python is. Bye, bearophile This is all derived from a blog post about a language no one cares about? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python parser
On 2 Mrz., 23:14, Clarendon jine...@hotmail.com wrote: Thank you, Lie and Andrew for your help. I have studied NLTK quite closely but its parsers seem to be only for demo. It has a very limited grammar set, and even a parser that is supposed to be large does not have enough grammar to cover common words like I. I need to parse a large amount of texts collected from the web (around a couple hundred sentences at a time) very quickly, so I need a parser with a broad scope of grammar, enough to cover all these texts. This is what I mean by 'random'. An advanced programmer has advised me that Python is rather slow in processing large data, and so there are not many parsers written in Python. He recommends that I use Jython to use parsers written in Java. What are your views about this? Thank you very much. You'll most likely need a GLR parser. There is http://www.lava.net/~newsham/pyggy/ which I tried once and found it to be broken. Then there is the Spark toolkit http://pages.cpsc.ucalgary.ca/~aycock/spark/ I checked it out years ago and found it was very slow. Then there is bison which can be used with a %glr-parser declaration and PyBison bindings http://www.freenet.org.nz/python/pybison/ Bison might be solid and fast. I can't say anything about the quality of the bindings though. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On 29 Jan., 11:21, Gary Herron gher...@islandtraining.com wrote: Python *is* object-oriented, but it is not (as your definition suggests) object-fascist. I'd put it more mildly. Python is object oriented. The orientation is there but the fanatism is gone. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Dynamic methods and lambda functions
On 26 Jan., 15:13, Steve Holden st...@holdenweb.com wrote: Mark Wooding wrote: unine...@gmail.com writes: [...] * Assignment stores a new (reference to a) value in the variable. * Binding modifies the mapping between names and variables. I realise I have omitted what was doubtless intended to be explanatory detail, but I am having trouble reconciling those sentences. Would you mind explaining in vacuuo what you see as the difference between assignment and binding? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Assignment is binding values to names whereas binding is binding names to scopes. Marks terminology is a bit more standard than Pythons in this respect. As you know, Python avoids the idea of variables as if those were storage cells having a fixed logical address. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dynamic methods and lambda functions
On 23 Jan., 13:28, unine...@gmail.com wrote: Hi, I want to add some properties dynamically to a class, and then add the corresponding getter methods. Something resulting in this: class Person: def Getname(self): return self.__name def Getage(self): return self.__age I've implemented the next code, creating the properties from a list: props = [ (name, peter), (age, 31), (wife, mary) ] class Person: def __init__(self): for prop in props: setattr(self, __ + prop[0], prop[1]) setattr(Person, Get + prop[0], lambda self: getattr (self, __ + prop[0])) if __name__ == __main__: person = Person() print person.__name print person.__age print person.__wife print print person.Getname() print person.Getage() print person.Getwife() And the resulting execution of this program is: peter 31 mary mary mary mary The attributes are right, but the getter are not working. The problem is that the lambda function always execute the last parameter passed for all instances of the methods. How could it be done the right way? Thanks in advance The standard trick is to de-closure the lambda using a keyword argument. So instead of writing lambda self: getattr(self, __ + prop[0])) you might write lambda self, prop = prop: getattr(self, __ + prop[0])) Now prop is local to the lambda and the lambda doesn't look up prop in the enclosing environment which certainly stores its last value. -- http://mail.python.org/mailman/listinfo/python-list
Re: Two import questions in Python 3.0
On 24 Jan., 09:21, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: If you run A.py as a script, it does not know it lives inside a package. You must *import* A for it to become aware of the package. Also, the directory containing the script comes earlier than PYTHONPATH entries in sys.path -- so watch for that case too. Thanks, yes. I always make the same error thinking that a directory with the ritual __init__ file is actually a package ( as some kind of platonic entity ), something that is more obvious to me than it is to the runtime. The relative import semantics introduced with Python 2.5 has made the error just visible that was hidden to me for about a decade. Shit. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the business with the asterisk?
On 24 Jan., 13:31, mk mrk...@gmail.com wrote: Hello everyone, From time to time I spot an asterisk (*) used in the Python code _outside_ the usual *args or **kwargs application. E.g. here:http://www.norvig.com/python-lisp.html def transpose (m): return zip(*m) transpose([[1,2,3], [4,5,6]]) [(1, 4), (2, 5), (3, 6)] What does *m mean in this example and how does it do the magic here? Regards, mk If zip is specified as def zip(*args): ... one can pass zero or more arguments into zip. In the zip body one has access to the argument tuple args. So zip(a, b, c) yields args = (a, b, c). Now suppose you want to pass the tuple t = (a, b, c) to zip. If you call zip(t) then args = ((a, b, c),). When calling zip(*t) instead the tuple is passed as variable arguments just like they are specified in the signature of zip. So args = (a, b, c). Same holds for def foo(**kwd): ... and foo(**kwd) versus foo(kwd). -- http://mail.python.org/mailman/listinfo/python-list
Re: Two import questions in Python 3.0
On 24 Jan., 18:51, Scott David Daniels scott.dani...@acm.org wrote: Kay Schluehr wrote: On 24 Jan., 09:21, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: If you run A.py as a script, it does not know it lives inside a package. You must *import* A for it to become aware of the package. Also, the directory containing the script comes earlier than PYTHONPATH entries in sys.path -- so watch for that case too. Thanks, yes. I always make the same error thinking that a directory with the ritual __init__ file is actually a package ( as some kind of platonic entity ), something that is more obvious to me than it is to the runtime. The relative import semantics introduced with Python 2.5 has made the error just visible that was hidden to me for about a decade. Shit. Temper the language a bit. You lose your effectiveness by some people reading the color of your words, rather than their meaning in code. Sigh, yes... sorry. I'm just too frustrated. Actually I don't even know why the import machinery is such a mess and I don't want to spend a huge amount of time ( like Brett Cannon ) to figure it out. I'll spent a few hours of time writing a script that turns all relative paths into absolute ones without changing the source otherwise. Then I'm at least done with that and won't ever see the relative import in non-packages exceptions anymore in any code I touch ( I can also ignore __package__, -m and all the other workarounds ). It's not the first time Python is in my way but this time it hurts. -- http://mail.python.org/mailman/listinfo/python-list
Re: The First Law Of comp.lang.python Dynamics
On 23 Jan., 08:13, Philip Semanchuk phi...@semanchuk.com wrote: On Jan 23, 2009, at 12:39 AM, Kay Schluehr wrote: Whatever sufficiently sophisticated topic was initially discussed it ends all up in a request for removing reference counting and the GIL. Is this a variant of Godwin's Law for Python? Definitely. It's a stable fixed point attractor. No matter how often it was discussed to dead in the past months the likelihood that someone mentions the GIL or ref-counting approaches 1. This is particularly remarkable because it is inverse proportional to the observable activity in this domain so there are really no news. Other similarly strange phenomena: whenever Xah Lee posts one of his infamous rants it attracts at least a dozen of newsgroup readers that try to persuade each other not to respond which will inevitably grow his thread and keep it alive for a long time. -- http://mail.python.org/mailman/listinfo/python-list
Two import questions in Python 3.0
1. I'd expected that absolute imports are used in Python 3.0 by default. I may be wrong. I've written two versions of a module sucks.py sucks.py - print (import from lib.sucks) sucks.py - print (import from package.sucks) The first is placed in the lib directory that is globally visible by means of PYTHONPATH. The second one is placed in a package package/ __init__.py sucks.py A.py The package also contains a module A.py defined by A.py -- import sucks Running A yields import from package.sucks which means unconditional relative import. It shadows the globally visible sucks.py module. I've expected it the other way round. 2. This is kind of a change request. In a former life I used to call test-scripts as test-scripts. The dumb idea was to point e.g. to lib/tests and run python test_ast.py test_nodeclasses (__main__.AST_Tests) ... ok test_parse (__main__.ASTHelpers_Test) ... ok -- Ran 12 tests in 0.219s OK The new style is implemented rather in lib2to3. If I point to lib/ lib2to3/tests and run python test_parser.py Traceback (most recent call last): File test_parser.py, line 12, in module from . import support ValueError: Attempted relative import in non-package The standard error of the years to come that makes working with Python harder and reminds me that it is not a scripting language anymore because you can't run anything as a script not even a test. For pedagogical reasons the behavior of test_ast.py and other standard library tests shall show uniform behavior when called from the command line i.e. they shall all fail with this import error message. What do you think? -- http://mail.python.org/mailman/listinfo/python-list
The First Law Of comp.lang.python Dynamics
Whatever sufficiently sophisticated topic was the initially discussed it ends all up in a request for removing reference counting and the GIL. -- http://mail.python.org/mailman/listinfo/python-list
Re: what's the point of rpython?
On 17 Jan., 01:37, Brendan Miller catph...@catphive.net wrote: Is this going anywhere or is this just architecture astronautics? The RPython project seems kind of interseting to me and I'd like to see more python implementations, but looking at the project I can't help but think that they haven't really explained *why* they are doing the things they are doing. Remember that the original objective of PyPy was to improve the JIT. Psyco is limited by the fact that the whole runtime is implemented in C. The infamous faster than C actually refers to work on program specializers on C code i.e. treating C as a language that is JIT compiled on a fine grained level ( block structure - whole function JIT compilation wouldn't obviously yield any advantages ). So it is not just the application level Python code that shall run through the JIT but also the interpreter level code. So why not equate them and think about interpreter level code as Python as well? This might be the idea. But then the problem of bootstrapping comes up: there is no interpreter level code with the required properties. Hence RPython that can serve as a foundation. I'm also not sure I like the approach. Rather than designing a whole new runtime for having a fully reflective system I'd model C in Python ( call it CiPy ) and create a bijection between CiPy code and C code. Once this has been established one can study other translations of CiPy or Python into CiPy ( not unlike Pyrex/Cython ) doing systematic refactorings on CiPy code in Python, study properties using runtime reflection, experiment with macro systems etc. All of this is done in PyPy as well but sometimes it seems the team has created more new problems than they solved. Anyway, I can tell this is the sort of question that some people will interpret as rude. Asking hard questions is never polite, but it is always necessary :) I think it is a good question. -- http://mail.python.org/mailman/listinfo/python-list
Re: English-like Python
On 16 Jan., 02:02, The Music Guy music...@alphaios.net wrote: Just out of curiousity, have there been any attempts to make a version of Python that looks like actual English text? No, but I've once written a Python dialect that uses German text. Just look at how amazing this result is !!! But be warned it requires knowledge of the German language. http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm I mean, so much of Python is already based on the English language that it seems like the next natural step would be to make a programming language which is actually a spoken one. As you know Python 3.0 has full unicode support. Python 4.0 will be surely written in Mandarin or Hindi. For example, the following code... import os def list_files(dirname): for p in os.listdir(dirname): print p list_files(some_dir) foo bar etc ...might be translated as... Import the operating system module. Define a new function as list files which accepts a path and does the following: For every item in the list returned by the operating system's directory listing of the given path, do the following: Print the item. List files from some_dir. foo bar etc Obviously, creating a parser capable of handling such code would require a very good understanding not only of the English language but also of how ideas expressed in spoken languages are represented in terms that a computer can understand. Yep. Resolving ambiguities in natural languages is actually an open research topic. Moving from Python to a language that is more context dependent than Larry Wall ever dreamed about and launch an interpreter on the Enterprise is actually a worthwhile project for future generations. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: import relative (with a directory)
On 11 Jan., 03:27, Chris Rebert c...@rebertia.com wrote: You should probably check out the relative import syntax introduced in PEP 328:http://www.python.org/dev/peps/pep-0328/ It should be able to do exactly what you want. This should exactly lead to exceptions in all of his demo code because the modules are not scripts anymore but modules in a package - a semantical difference I wasn't even aware of until relative imports were introduced in Python 2.5. I'd rather avoid the sour grapes and use absolute imports. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for tips on how to implement ruby-style Domain Specific Language in Python
On 8 Jan., 16:25, J Kenneth King ja...@agentultra.com wrote: As another poster mentioned, eventually PyPy will be done and then you'll get more of an in-Python DSL. May I ask why you consider it as important that the interpreter is written in Python? I see no connection between PyPy and syntactical Python extensions and the latter isn't an objective of PyPy. You can write Python extensions with virtually any Python aware parser. M.A.Lemburg already mentioned PLY and PLY is used for Cython. Then there is ANTLR which provides a Python grammar. I also know about two other Python aware parsers. One of them was written by myself. -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for tips on how to implement ruby-style Domain Specific Language in Python
O.K. Mark. Since you seem to accept the basic requirement to build an
*external* DSL I can provide some help. I'm the author of EasyExtend
( EE ) which is a system to build external DSLs for Python.
http://www.fiber-space.de/EasyExtend/doc/EE.html
EE is very much work in progress and in the last year I was more
engaged with increasing power than enhance accessibility for
beginners. So be warned.
A DSL in EE is called a *langlet*. Download the EE package and import
it in a Python shell. A langlet can then be built this way:
import EasyExtend
EasyExtend.new_langlet(my_langlet, prompt = myl , source_ext = .dsl)
This creates a bunch of files in a directory
site-packages-path/EasyExtend/langlets/my_langlet
Among them is run_my_langet.py and langlet.py. You can cd to the
directory and apply
$python run_my_langlet.py
which opens a console with prompt 'myl'. Each langlet is immediatly
interactive. A user can also run a langlet specific module like
$python run_my_langlet.py mod.dsl
with the suffix .dsl defined in the langlet builder function. Each
module xxx.dsl can be imported from other modules of the my_langlet
langlet. EE provides a generic import hook for user defined suffixes.
In order to do anything meaningful one has to implement langlet
transformations in the langlet.py module. The main transformations are
defined in a class called LangletTransformer. It defines a set of
visitor methods that are marked by a decorator called @trans. Each
@trans method is named like a terminal/non-terminal in a grammar file
and responds to a terminal or non-terminal node of the parse tree
which is traversed. The structure of the parse tree is the same as
those you'd get from Pythons builtin parser. It is entirely determined
by 4 files:
- Grammar which is precisely the Python grammar found in the Python
source distribution.
- Grammar.ext which defines new non-terminals and overwrites old
ones.
- Token which defines Pythons token.
- Token.ext which is the analog of Grammar.ext for token definitions.
The Grammar.ext file is in the directory my_langlet/parsedef. There is
also an analog lexdef directory for Token.ext.
A possible Grammar.ext extension of the Python grammar that overwrites
two non-terminals of looks like this:
Grammar.ext
---
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | NAME |
NUMBER | STRING
atom: ('(' [yield_expr|testlist_gexp] ')' |
'[' [listmaker] ']' |
'{' [dictmaker] '}' |
'`' testlist1 '`' |
NAME | NUMBER | STRING)
---
Once this has been defined you can start a new my_langlet session and
type
myl navigate_to 'www.openstreetmap.org' website
Traceback (most recent call last):
File C:\lang\Python25\lib\site-packages\EasyExtend\eeconsole.py,
line 270, in compile_cst
_code = compile(src,input,single, COMPILER_FLAGS)
File input, line 1
navigate_to 'www.openstreetmap.org' website
^
SyntaxError: invalid syntax
myl
It will raise a SyntaxError but notice that this error stems from the
*compiler*, not the parser. The parser perfectly accepts the modified
non-terminals and produces a parse tree. This parse tree has to be
transformed into a valid Python parse tree that can be accepted by
Pythons bytecode compiler.
I'm not going into detail here but recommend to read the tutorial
http://www.fiber-space.de/EasyExtend/doc/tutorial/EETutorial.html
that walks through a complete example that defines a few terminals,
non-terminals and the transformations accordingly. It also shows how
to use command line options to display parse tree properties, unparse
parse trees back into source code ( you can eliminate DSL code from
the code base entirely and replace it by equivalent Python code ), do
some validation on transformed parse trees etc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: looking for tips on how to implement ruby-style Domain Specific Language in Python
On 7 Jan., 16:50, J Kenneth King ja...@agentultra.com wrote: Python expressions are not data types either and hence no macros -- I can't write a python function that generates python code at compile time. Have you ever considered there are languages providing macros other than Lisp? Macros have nothing to do with homoiconcity. I can only write a python program that parses some other string and generates code that can be run by another interpreter. No, it is the same interpreter and it is also possible to modify python parsers on the fly. This is just not possible with Pythons builtin parser. Consider: for i in range(0, 100): do_something_interesting(i) That's a pretty straight forward Python expression, but I can't do anything with it -- it's not a unit of data, it's a string. The distinction is not subtle by any means. -- http://mail.python.org/mailman/listinfo/python-list
Re: If your were going to program a game...
On 1 Jan., 12:37, Tokyo Dan huff...@tokyo.email.ne.jp wrote: If your were going to program a game in python what technologies would you use? The game is a board game with some piece animations, but no movement animation...think of a chess king exploding. The game runs in a browser in a window of a social site built around the game. The social site has login, chat, player stats, list of active games, etc. AND there is also be a desktop client that accesses the game server via the same communication mechanism (like an AIR-based desktop client/ app) as the browser-based version - I guess using JSON/RPC. There is no solution to this problem from a Python perspective. Do what everyone does right now: use Flash for the game and manage your site with Python if you like the language. -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for tips on how to implement ruby-style Domain Specific Language in Python
How would one approach this in Python? Do I need to build a custom loader which compiles *.dsl files to *.pyc files? Is it possible to switch between the custom DSL and the standard Python interpreter? Sure, but there is no way to avoid extending the Python parser and then your DSL becomes external. I remember having had a similar discussion a while ago with Kevin Dangoor the original TurboGears developer who has also written Paver [1]. In the end DSL syntax wasn't worth the hassle and Kevin developed Paver entirely in Python. Kay [1] http://www.blueskyonmars.com/projects/paver/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Code coverage to Python code
On 4 Jan., 12:35, Hussein B hubaghd...@gmail.com wrote: Hey, What is the best code coverage tool available for Python? Thanks. It depends. What are your requirements? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On 20 Dez., 02:54, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Debated by who? The entire Python-using community? Every single Python programmer? Or just the small proportion of Python developers who are also core developers? If I'd asked people what they wanted, they would have asked for a better horse. Henry Ford -- http://mail.python.org/mailman/listinfo/python-list
Re: Relative imports in Python 3.0
On 17 Dez., 11:01, Nicholas nicholas.c...@gmail.com wrote: I am sure I am not the first to run into this issue, but what is the solution? When you use 2to3 just uncomment or delete the file fix_import.py in lib2to3/fixes/ . -- http://mail.python.org/mailman/listinfo/python-list
Re: ActivePython 2.6.1.1 and 3.0.0.0 released!
On 13 Dez., 00:16, Trent Mick tre...@activestate.com wrote: Note that currently PyWin32 is not included in ActivePython 3.0. Is there any activity in this direction? -- http://mail.python.org/mailman/listinfo/python-list
[issue4647] Builtin parser module fails to parse relative imports
New submission from Kay Schluehr k...@fiber-space.de: I've added the following test method: test_parser.py -- class RoundtripLegalSyntaxTestCase(unittest.TestCase): def test_relative_import_statement(self): self.check_suite(from . import sys) The test fails raising the message: Traceback (most recent call last): File test_parser.py, line 182, in test_relative_import_statement self.check_suite(from . import sys) File test_parser.py, line 29, in check_suite self.roundtrip(parser.suite, s) File test_parser.py, line 20, in roundtrip self.fail(could not roundtrip %r: %s % (s, why)) AssertionError: could not roundtrip 'from . import sys': Expected node type 1, got 23. Apparently the parser expects a NAME token and gets a DOT token. This behaviour affects Python 2.5 and Python 2.6. Unchecked for Python 3.0. -- components: Interpreter Core messages: 77690 nosy: schluehk severity: normal status: open title: Builtin parser module fails to parse relative imports type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: python3.0 - any hope it will get faster?
On 9 Dez., 11:51, Helmut Jarausch [EMAIL PROTECTED] wrote: Hi, I was somewhat surprised when I ran pystones with python-2.5.2 and with python-3.0 On my old/slow machine I get python-2.5.2 from test import pystone pystone.pystones() gives (2.73, 18315.018315018315) python-3.0 from test import pystone pystone.pystones() gives (4.2705, 11709.601873536298) That's a drop of 36% ! I know that processing unicode is inherently slower, but still I was surprised that it's so much slower. On my WinXP notebook python-3.0 from test import pystone pystone.pystones() (1.1734318188484849, 42610.059823557647) python-2.5.1 from test import pystone pystone.pystones() (1.2927221197107452, 38678.072601703308) -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido's new method definition idea
On 6 Dez., 03:21, Daniel Fetchinson [EMAIL PROTECTED] wrote: Hi folks, The story of the explicit self in method definitions has been discussed to death and we all know it will stay. However, Guido himself acknowledged that an alternative syntax makes perfect sense and having both (old and new) in a future version of python is a possibility since it maintains backward compatibility. The alternative syntax will be syntactic sugar for the old one. This blog post of his is what I'm talking about: http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay... The proposal is to allow this: class C: def self.method( arg ): self.value = arg return self.value instead of this: class C: def method( self, arg ): self.value = arg return self.value I.e. explicit self stays only the syntax is slightly different and may seem attractive to some. As pointed out by Guido classmethods would work similarly: class C: @classmethod def cls.method( arg ): cls.val = arg return cls.val The fact that Guido says, Now, I'm not saying that I like this better than the status quo. But I like it a lot better than [...] but it has the great advantage that it is backward compatible, and can be evolved into a PEP with a reference implementation without too much effort. shows that the proposal is viable. So both forms are dual to each other ( backwards compatibility ) and can be used both? I'm -0 on this although I think the proposition fits better with the method call syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting to 3.0, test coverage
On 4 Dez., 23:40, Paul Hildebrandt [EMAIL PROTECTED] wrote: I was just reading what's new with Python 3.0http://docs.python.org/dev/3.0/whatsnew/3.0.html I like this prerequisite to porting: Start with excellent test coverage May I suggest looking into Pythoscope for those looking to boost test coverage. http://pythoscope.org Paul This is surely interesting but occasionally it would be just too nice if *someone else* would advertise ones own projects ;) Here is more stuff http://www.pycheesecake.org/wiki/PythonTestingToolsTaxonomy -- http://mail.python.org/mailman/listinfo/python-list
Re: Debugging a Python Program that Hangs
On 2 Dez., 17:19, Kevin D. Smith [EMAIL PROTECTED] wrote: I have a fairly large python program that, when a certain combination of options is used, hangs. I have no idea where it is hanging, so simply putting in print statements to locate the spot would be quite difficult. Unfortunately, ctrl-C'ing the program doesn't print a traceback either. Looking through the python debugger documentation, I don't see how to run a python program and interactively stopping it while it is running. Is there a way to stop within a running python program to see where it is getting hung up? -- Kevin D. Smith You might approximate the critical location using exceptions instead of prints. That's more costly of course because the program has to be restarted more often but it will serve the same purpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python+Pyjamas+V8=ftw
On 2 Dez., 14:57, lkcl [EMAIL PROTECTED] wrote: as a general-purpose plugin replacement for /usr/bin/python, however, it's not quite there. and, given that javascript cheerfully goes about its way with the undefined concept, it's always going to be a _bit_ tricky to provide absolutely _every_ language feature, faithfully. For some reasons I'd do it the other way round and model JS entirely in Python first. This is rather gratefully supported by two facts 1) Python is far more powerful than JS and supports lots of metaprogramming facilities. For example providing a Python type that has JS prototype semantics isn't really a big deal. 2) JS is standardized and the standard is very well documented. When JS has been mapped onto a dedicated Python framework one can open the backchannel and translate the Python framework code to JS. Ideally the mapping P_JS - P_PyJS - P'_JS is an identity. PyJS is unambiguously fixed by this mapping. Now people may define mappings from Python types to PyJS types and all the checks and tests are performed as usual checks in Python code by API functions of the PyJS framework. The compiler hasn't anything to do with it anymore and can be somewhat liberated from hard work. This roundtrip breaks with the GWT scheme of one way translation for an obvious reasons: Python is not Java. Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
[issue4468] Restore chapter enumeration in Python docs
New submission from Kay Schluehr [EMAIL PROTECTED]: Request for restoring chapter enumeration in the Python docs for Python 2.6 and newer releases. In the new style Sphinx documentation for Python the enumeration of sections and subsections has been dropped. This is highly unusual for a technical documentation and in particular for a body of documents that represent a de-facto standard. An easy access to content is required even in communication being not web based where URLs can be copied and sent. Even right now the chm documents provided in the Windows distribution of Python 2.6 are of reduced value. Given that there are chapters with pretty generic titles like How it works the lack of enumeration causes disorientation. -- assignee: georg.brandl components: Documentation messages: 76634 nosy: georg.brandl, schluehk severity: normal status: open title: Restore chapter enumeration in Python docs type: feature request versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Python docs and enumeration of sections
Is there a reason why enumeration of sections and subsections has been dropped after the switch to the Sphinx documentation tool? It doesn't really make quoting library sections easier or do you know what I mean when I refer to How It Works? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python docs and enumeration of sections
On 29 Nov., 09:47, Robert Kern [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Is there a reason why enumeration of sections and subsections has been dropped after the switch to the Sphinx documentation tool? It doesn't really make quoting library sections easier or do you know what I mean when I refer to How It Works? If you hover the mouse over the area just to the right of a section title, you will see a paragraph mark which will be a link to the section. You can copy-and-paste that URL. The URL is more convenient answer than a section number. http://docs.python.org/library/pdb.html#how-it-works I disagree. This might be adequate for web communication like this which is bound to HTML but nothing else. No one who uses e.g. the python26.chm document or a derived PDF can easily find what we are talking about. I also wonder about convenience? Not a single RFC, public spec, standards document or any other important reference omits chapter enumerations. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting in to metaprogramming
On 27 Nov., 06:11, Rafe [EMAIL PROTECTED] wrote: On Nov 27, 11:41 am, Hendrik van Rooyen [EMAIL PROTECTED] wrote: Steven D'Aprano steau wrote: Well, I don't know about any problem. And it's not so much about whether metaprograms can solve problems that can't be solved by anything else, as whether metaprograms can solve problems more effectively than other techniques. If you include factory functions, class factories, the builder design pattern, metaclasses, etc. as metaprogramming, then I use it all the time, and find it an excellent technique to use. But if you mean using a Python program to generate Python source code, then I can't think of any time I used it. Which doesn't mean that others don't find it helpful, only that I haven't yet. I am using the term in the restricted sense of Python writing Python source. Given that, can anybody think of an example that you could not do with a class? (excepting the stored procedure aspect) Or can I claim a new a new meta - rule - I would call it van Rooyen's folly... Thinking further back, when I was young and programming in Apple's Hypercard 4GL, I used to frequently use Hypercard scripts to generate new Hypercard scripts. That was to work around the limitations of the scripting language. What sort of stuff did you do, and would having had simple OO available have rendered it unnecessary? I don't think metaprogramming in the limited sense (programs to output source code) is a bad idea, but I do think that there are probably better alternatives in a language like Python. True. No argument here - I was just wondering if the relationship holds. - Hendrik Given that, can anybody think of an example that you could not do with a class? Generating a template for a specific script application. For example, a script with pre-defined callbacks that only require the addition of the contents. I was really interested in exploring the idea of using python output, instead of XML, to record something a user did in a GUI. I have seen it done and it is really advantageous in the 3D industry because it means the script files can be edited directly, in a pinch, to generate something slightly different. For example, say we have code which generates a cube by plotting it's points. A user then changes a point position in the GUI. The change is saved by outputting the function call to a file with new arguments (the new point location). If I wanted to make 100s of copies of the cube, but with a slightly different point position, I could edit the custom cube's python code and hand it back for creation without using the GUI. I could do this with XML, but it can be harder to work with in a text editor (though I have seen some XML editors that make it a bit easier.) In fact, in most 3D applications, the app prints everything the user does to a log. Sometimes in a choice of languages, so I guess I am looking to do the same thing with my own custom tools. In a real situation the generated code file can build some pretty complex 3D object hierarchies. It moves beyond simple storage of data and becomes a real script that can be hacked as necessary. It is nice to have everything as python scripts because we always have a blend of GUI users and developers to get a job done. - Rafe A rather advanced approach to deal with writing XML in Python and generating Python from XML has been chosen in P4D: http://pypi.python.org/pypi/P4D%20Langlet/1.2.4 It is of course a cultural mismatch to do such stuff because it targets a proper superset of Python but I don't think it's worse than what has been done in a plethora of template languages ( P4D is none of them though ), YAML or related approaches. I did it mostly because I wanted to learn Adobe Flex and I wanted to use it as a scripting language, not as something I had to edit in a particular editor like FlexBuilder. -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting in to metaprogramming
On 25 Nov., 11:08, Rafe [EMAIL PROTECTED] wrote: Hi, In the name of self-education can anyone share some pointers, links, modules, etc that I might use to begin learning how to do some metaprogramming. That is, using code to write code (right?) Cheers, - Rafe http://www.letmegooglethatforyou.com/?q=python+metaprogramming -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting in to metaprogramming
On 27 Nov., 05:41, Hendrik van Rooyen [EMAIL PROTECTED] wrote: Given that, can anybody think of an example that you could not do with a class? (excepting the stored procedure aspect) I just noticed that corepy 1.0 [1] has been released. Corepy is an embedded DSL for synthesizing machine code from chaining Python commands. This means it provides objects and exploits control structures used to create machine code that can finally be executed interactively. Let's say you have an ordinary Python function that computes a CRC 32. Now you could attempt to translate the function into other Python code that expresses a corepy routine. You could create a decorator that works as follows 1) reads the source of the decorated function 2) transforms the source into corepy source and compiles it or 3) if 2) fails it just returns the passed code object. Kay [1] http://www.corepy.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: regular expressions ... slow
On 18 Nov., 18:47, Stefan Behnel [EMAIL PROTECTED] wrote: Kay Schluehr wrote: All of this is prototyped in Python and it is still work in progress. As long as development has not reached a stable state I refuse to rebuild the system in an optimized C version. And rightfully so: 1) the approach is algorithmically better, so it may even beat the current C implementation by design. 2) switching languages before finishing and benchmarking the prototype is a premature optimisation. It wouldn't be the first prototype going into production. 3) even before considering a reimplementation, you should throw it into Cython to translate it into C code, and then benchmark that. Stefan I fully agree and in fact the Trail parser generator contains a single extension module called cyTrail which is written in Cython - it's not just a trivial recompilation of Python in Cython but it uses all kinds of cdefs. There is just a difference between optimizing existing code using the best techniques available and writing code from scratch for speed. I consider this as a different, subsequent project ( call it cTrail ) and I want to have more fine control than being possible with Cython - actually I do want to understand the code in a simple language as C. I have to idea what the code does, generated by Cython. There are entire layers that can be stripped off when not dealing with Python types and dynamic memory allocation. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: regular expressions ... slow
On 17 Nov., 22:37, Uwe Schmitt [EMAIL PROTECTED] wrote: Hi, Is anobody aware of this post: http://swtch.com/~rsc/regexp/regexp1.html ? Are there any plans to speed up Pythons regular expression module ? Or is the example in this artricle too far from reality ??? Greetings, Uwe Some remarks. The basic idea outlined in the article is something that is re- discovered from time to time. Last year I started working on a parse tree validator which is a tool that checks whether a parse tree P on which transformative actions were performed belongs to a language described by a grammar G. To check this G was initially transformed into a set of NFAs representing grammars rules. The checker is a tracing tool that selects nodes in a parse tree in order to step through the transitions described in the NFA. If it can't select a state the validation fails. Generally there are rules which are non left factored well just like R: a b c | a b d The NFA transition table accordingly looks roughly like R: (R,0) - (a,1), (a,2) (a,1) - (b,1) (b,1) - (c,1) (c,1) - (None,'-') (a,2) - (b,2) (b,2) - (d,2) (d,1) - (None,'-') A valid parse tree P which corresponds to rule R has one of two forms: P1 = [R, a, b, c] or P2 = [R, a, b, d] Suppose we want to validate P1 by our NFA. First we select the NFA R using root node-id R. R corresponds to the start state (R,0). Next we select the follow states which are [(a,1), (a,2)]. The projection on the first argument yields a. Obviously we can shift to a in P1 and match the follow states (a,1) and (a,2) in R: P1 = [R, a, b, c] ^ Next we shift to b P1 = [R, a, b, c] ^ Now we have two traces in R we can follow. The one that is assigned by (a,1) and the other one by (a,2). Since we can't decide which one we *both at the same time*. This yields follow states (b,1) and (b,2) which can be projected on b. Next we shift to c P1 = [R, a, b, c] ^ Again we follow both traces and get (c,1) and (d,1). (c,1) fits well. Now we have to check that termination of P in this state is at least an option. The follow state of (c,1) in R is (None,'-') which is the EXIT symbol of the NFA. The validation was successful. The same NFAs used to validate parse trees can be used within a top- down parser generator as input tables. Such a parser generator automatically handles left-factoring right and is LL(*). It is also O (n) where n is the length of the input token stream. Unlike parser generators such as ANTLR it achieves LL(*) without any advanced lookahead scheme. Instead it produces traces of NFA states and cancels unused traces ( e.g. there are two initial traces in our example ((R,0) (a,1)(b,1)) and ((R,0)(a,2)(b,2)). The first one is canceled once d is selected. Otherwise the second one gets canceled when c gets selected ). A full parser generator for CFGs is more complex in many respects than a regular-expression matcher and AFAIK the one I've built over the last year is unique in its category. It is also simpler in a few aspects because full regexp matchers are also deal with lots of context sensitive issues not being expressed in a CFG. I used the same parsing scheme to produce a lexer. There is considerable overhead though because it produces one parse-tree per character and I intend to avoid this by using a hybrid lexer in the future that contains some very fast and some slower components. The reason why I used the parser generator in the lexer is that it has one signficant advantage over classic regexp parsing schemes: it avoids dependence on order. Whether you write R = ab|abc or R=abc|ab is insignificant. Longest match is always preferred unless otherwise stated. This makes extending the grammar of the lexer very simple. All of this is prototyped in Python and it is still work in progress. As long as development has not reached a stable state I refuse to rebuild the system in an optimized C version. Otherwise if someone e.g. a student intends to write his master thesis about a next generation regexp engine built on that stuff or even intends to contribute to the mentioned lexer I would of course cooperate. Kay www.fiber-space.de [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: best python unit testing framwork
On 11 Nov., 23:59, Brendan Miller [EMAIL PROTECTED] wrote: What would heavy python unit testers say is the best framework? I've seen a few mentions that maybe the built in unittest framework isn't that great. The UT frameworks follow the same principles and are all alike more or less. Of course doctest makes a difference and implies another approach to testing but whether you use unittest, nosetest or py.test is mostly a matter of taste. Of course taste matters a lot for various people and when they have to use CamelCased method names like setUp or assertEqual in Python they feel alienated and reminded that Java is out there. Personally I use unittest.py for a pretty obvious reason: other people can simply run the test scripts without prior installation of a testframework. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On 9 Nov., 09:26, Rhamphoryncus [EMAIL PROTECTED] wrote: On Nov 8, 10:14 pm, Kay Schluehr [EMAIL PROTECTED] wrote: I guess building a multiset is a little more expensive than just O(n). It is rather like building a dict from a list which is O(k*n) with a constant but small factor k. The comparison is of the same order. To enable the same behavior as the applied sorted() a multiset must permit unhashable elements. dicts don't do the job. Although it has a runtime of k*n, it is still O(n). big-O notation ignores constant factors, dealing only with scalability. You are right. I remembered this short after my posting was sent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On 9 Nov., 17:49, Terry Reedy [EMAIL PROTECTED] wrote: I was asking the OP ;-) Thank you for the discussion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is psyco available for python 2.6?
On 9 Nov., 20:44, Fuzzyman [EMAIL PROTECTED] wrote: On Nov 9, 2:18 pm, Anton Vredegoor [EMAIL PROTECTED] wrote: On Thu, 30 Oct 2008 17:45:40 +0100 Gerhard Häring [EMAIL PROTECTED] wrote: psyco seems to just work on Linux with Python 2.6. So it is probably only a matter of compiling it on Windows for Python 2.6. Yes. I compiled it using wp setup.py build --compiler=mingw32 with cygwin, where wp was an alias for my windows xp python executable. For the OP and other people interested in windows binaries: I am in no way connected to or involved in the psyco development process -- except that I downloaded and compiled it -- but I have put a zip file on line for people who have a lot of trust in me and little patience for waiting for the official distribution. Just unpack it and put it in your site-packages directory. http://members.home.nl/anton.vredegoor/psyco/ A. I've built a Windows installer if anyone is interested: http://www.voidspace.org.uk/python/modules.shtml Michael --http://www.ironpythoninaction.com/ Thanks. You guys rock! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On 9 Nov., 05:04, Terry Reedy [EMAIL PROTECTED] wrote: Have you written any Python code where you really wanted the old, unpredictable behavior? Sure: if len(L1) == len(L2): return sorted(L1) == sorted(L2) # check whether two lists contain the same elements else: return False It doesn't really matter here what the result of the sorts actually is as long as the algorithm leads to the same result for all permutations on L1 ( and L2 ). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On 9 Nov., 05:49, Alex_Gaynor [EMAIL PROTECTED] wrote: On Nov 8, 11:36 pm, Kay Schluehr [EMAIL PROTECTED] wrote: On 9 Nov., 05:04, Terry Reedy [EMAIL PROTECTED] wrote: Have you written any Python code where you really wanted the old, unpredictable behavior? Sure: if len(L1) == len(L2): return sorted(L1) == sorted(L2) # check whether two lists contain the same elements else: return False It doesn't really matter here what the result of the sorts actually is as long as the algorithm leads to the same result for all permutations on L1 ( and L2 ). that same thing could be done with a multiset type, which would also have better performance(O(n) vs. O(nlogn)). I guess building a multiset is a little more expensive than just O(n). It is rather like building a dict from a list which is O(k*n) with a constant but small factor k. The comparison is of the same order. To enable the same behavior as the applied sorted() a multiset must permit unhashable elements. dicts don't do the job. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On 9 Nov., 07:06, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sat, 08 Nov 2008 20:36:59 -0800, Kay Schluehr wrote: On 9 Nov., 05:04, Terry Reedy [EMAIL PROTECTED] wrote: Have you written any Python code where you really wanted the old, unpredictable behavior? Sure: if len(L1) == len(L2): return sorted(L1) == sorted(L2) # check whether two lists contain the same elements else: return False It doesn't really matter here what the result of the sorts actually is as long as the algorithm leads to the same result for all permutations on L1 ( and L2 ). How often do you care about equality ignoring order for lists containing arbitrary, heterogeneous types? A few times. Why do you care, Steven? In any case, the above doesn't work now, since either L1 or L2 might contain complex numbers. The sorted() trick only works because you're making an assumption about the kinds of things in the lists. If you want to be completely general, the above solution isn't guaranteed to work. You are right. I never used complex numbers in Python so problems were not visible. Otherwise the following comp function in Python 2.X does the job: def comp(x1, x2): try: if x1x2: return -1 else: return 1 except TypeError: if str(x1)str(x2): return -1 else: return 1 Not sure how to transform it into a search key that is efficient and reliable. [...] Here is a way to solve the problem assuming only that the items support equality: def unordered_equals2(L1, L2): if len(L1) != len(L2): return False for item in L1: if L1.count(item) != L2.count(item): return False return True Which is O(n**2) as you might have noted. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to make money with Python!
On 31 Okt., 15:30, Duncan Booth [EMAIL PROTECTED] wrote: If that subject line didn't trip everyone's killfiles, see http://pythonide.blogspot.com/2008/10/how-to-make-money-with-free-sof... for a fantastic story involving Python. -- Duncan Boothhttp://kupuguy.blogspot.com Masterpiece. I dare to say it's much better than SPE ... -- http://mail.python.org/mailman/listinfo/python-list
Re: beutifulsoup
On 29 Okt., 17:45, luca72 [EMAIL PROTECTED] wrote:
Hello
I try to use beautifulsoup
i have this:
sito = urllib.urlopen('http://www.prova.com/')
esamino = BeautifulSoup(sito)
luca = esamino.findAll('tr', align='center')
print luca[0]
tr align=centerth width=5%a onclick=t('Only|G|BoT|05','#1');
href=##1/a/thtd width=10%44.4MB/tdtd width=90%
align=leftfont color=orange Pc-prova.rar /font/td/tr
I need to get the following information:
1)Only|G|BoT|05
2)#1
3)44.4MB
4)Pc-prova.rar
with: print luca[0].a.stringi get #1
with print luca[0].td.stringi get 44.4MB
can you explain me how to get the others two value
Thanks
Luca
The same way you got `luca`
1,2) luca.find(a)[onclick].split(') and search through the
result list
3) luca.find(td).string
4) luca.find(font).string
--
http://mail.python.org/mailman/listinfo/python-list
Re: beutifulsoup
On 30 Okt., 18:28, luca72 [EMAIL PROTECTED] wrote:
hello
Another stupit question instead of use
sito = urllib.urlopen('http://www.prova.com/')
esamino = BeautifulSoup(sito)
i do
sito = urllib.urlopen('http://onlygame.helloweb.eu/')
file_sito = open('sito.html', 'wb')
for line in sito :
file_sito.write(line)
file_sito.close()
how can i pass the file sito.html to beautifulsoup?
Regards
Luca
download = urllib.urlopen(http://www.fiber-space.de/downloads/
downloads.html)
BeautifulSoup(download.read())
Ciao
--
http://mail.python.org/mailman/listinfo/python-list
Re: parsing MS word docs -- tutorial request
On 28 Okt., 15:25, [EMAIL PROTECTED] wrote: All, I am trying to write a script that will parse and extract data from a MS Word document. Can / would anyone refer me to a tutorial on how to do that? (perhaps from tables). I am aware of, and have downloaded the pywin32 extensions, but am unsure of how to proceed -- I'm not familiar with the COM API for word, so help for that would also be welcome. Any help would be appreciated. Thanks for your attention and patience. ::bp:: One can convert MS-Word documents into some class of XML documents called MHTML. If I remember correctly those documents had an .mht extension. The result is a huge amount of ( nevertheless structured ) markup gibberish together with text. If one spends time and attention one can find pattern in the markup ( we have XML and it's human readable ). A few years ago I used this conversion to implement roughly following thing algorithm: 1. I manually highlighted one or more sections in a Word doc using a background colour marker. 2. I searched for the colour marked section and determined the structure. The structure information was fed into a state machine. 3. With this state machine I searched for all sections that were equally structured. 4. I applied a href link to the text that was surrounded by the structure and removed the colour marker. 5. In another document I searched for the same text and set an anchor. This way I could link two documents ( those were public specifications being originally disconnected ). Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 11 Okt., 09:56, lkcl [EMAIL PROTECTED] wrote: The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM,V8etc. pyv8 -http://advogato.org/article/985.html pyjs.py - standalone python-to-javascript compiler, seehttp://pyjs.org. O.K. you got me all. I give up! I've already imlemented some small Flex supporting functionality in the P4D Langlet [1] and I'll also checkout pyjamas ( didn't worn them for long ) and if they are fine I work out a bridge the next days. Then only style sheets are left :) [1] http://pypi.python.org/pypi/P4D Langlet/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Linux.com: Python 3 makes a big break
On 18 Okt., 22:01, Jean-Paul Calderone [EMAIL PROTECTED] wrote: Perhaps it also omitted the fact that nothing prevents you from defining a function to write things to stdout (or elsewhere) in Python 2.5, making the Python 3.x change largely a non-feature. ;) Jean-Paul Even more. If someone had solved the hard problem of finding a less cumbersome way of writing sys.stdout.write(...) the request for multiline lambdas ( multi expression lambdas actually ) could have been decreased about 75-80%. -- http://mail.python.org/mailman/listinfo/python-list
Re: Overloading operators
On 15 Okt., 14:34, Mr.SpOOn [EMAIL PROTECTED] wrote: Hi, in a project I'm overloading a lot of comparison and arithmetic operators to make them working with more complex classes that I defined. Sometimes I need a different behavior of the operator depending on the argument. For example, if I compare a object with an int, I get a result, but if I compare the same object with a string, or another object, I get another result. What is the best way to do this? Shall I use a lot of if...elif statements inside the overloaded operator? Or is there a more pythonic and dynamic way? I can't see anything wrong about it. Sometimes I try to avoid isinstance() though because it is a rather slow operation. If the majority of operations is single-typed one can also use a try-stmt: def __add__(self, other): try: return self._val + other except TypeError: return self.__add__(SomeWrapper(other)) and compare performance using a profiler. Notice that also if type(obj) == T: BLOCK is much faster than isinstance() but it's not OO-ish and very rigid. -- http://mail.python.org/mailman/listinfo/python-list
Re: type-checking support in Python?
On 6 Okt., 16:19, Joe Strout [EMAIL PROTECTED] wrote: I'm just re-learning Python after nearly a decade away. I've learned a good healthy paranoia about my code in that time, and so one thing I'd like to add to my Python habits is a way to both (a) make intended types clear to the human reader of the code, in a uniform manner; and (b) catch any type errors as early and automatically as possible. I found the typecheck module (http://oakwinter.com/code/typecheck/), but I notice that it hasn't been updated since 2006, and it's not included with the Python distribution. Are there other modules providing similar functionality that I should consider instead? Incidentally I started to use the typecheck package just yesterday. It's not that I'm using it in a typical application but I'm working on a mapping of a statically typed language onto a Python framework that emerges in parallel. So I have to rebuild the type semantics of the original language in Python but defer typechecks until runtime. My impressions so far have been mixed. I stumbled across some strange failures that required uncommenting source code in the typecheck package which might cause failures elsewhere. I also hit a barrier when working with methods instead of functions. I also noticed that passing two strings to a funtcion: @accepts(Number, Number) def add(x,y): return x+y is acceptable behaviour. From all those experiences I'd rate the package alpha and I'm sad noticing that it is apparently abandonware. I'll continue to use it nevertheless. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3: sorting with a comparison function
On 9 Okt., 22:36, [EMAIL PROTECTED] wrote: Yes, that's a wonderful thing, because from the code I see around 99.9% of people see the cmp and just use it, totally ignoring the presence of the 'key' argument, that allows better and shorter solutions of the sorting problem. Me too because I don't get this: key specifies a function of one argument that is used to extract a comparison key from each list element: key=str.lower. The default value is None. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3: sorting with a comparison function
On 10 Okt., 19:22, [EMAIL PROTECTED] wrote: On Oct 10, 8:35 am, Kay Schluehr [EMAIL PROTECTED] wrote: On 9 Okt., 22:36, [EMAIL PROTECTED] wrote: Yes, that's a wonderful thing, because from the code I see around 99.9% of people see the cmp and just use it, totally ignoring the presence of the 'key' argument, that allows better and shorter solutions of the sorting problem. Me too because I don't get this: key specifies a function of one argument that is used to extract a comparison key from each list element: key=str.lower. The default value is None. Kay Don't know if further explanation is needed, but here is the deal: cmp is a function that receives two values and you return -1, 0 or 1 depending if the first is smaller, equal or bigger. 99% of the time you will do some operation on the values that come in and then do a if statement with or and return -1,0,1. key is a function that receives one value and you return the value that you would normally compare against. Let me show an example: data=[(4,'v'),(2,'x'),(1,'a')] sorted(data) [(1, 'a'), (2, 'x'), (4, 'v')] OK, we sorted the data, but What if we want to sort by the letter instead of the number? Let's use cmp: def comp(x, y): key_of_x=x[1] key_of_y=y[1] if key_of_x key_of_y: return -1 elif key_of_x key_of_y: return 1 else: return 0 #key_of_x == key_of_y sorted(data,cmp=comp) [(1, 'a'), (4, 'v'), (2, 'x')] Very well, so how do we do this using key? def keyfunc(x): key_of_x=x[1] return key_of_x sorted(data,key=keyfunc) [(1, 'a'), (4, 'v'), (2, 'x')] Same output. Very good. (Of course a smart python developer would use the operator module so he doesn't even have to write keyfunc but this was just an example) In summary to transform most cmp functions to a key function you just take the code that calculates the first value to be compared and leave out the rest of the logic. Hope that was helpful. Yes, thanks a lot. In essence the key is a function that maps each list element onto a value of a type for which a known order is defined e.g. an integer. Applying sorted() sorts the list elements according to the list of those values. Sometimes it helps when people just make clear how they use technical terms instead of invoking vague associations. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3: sorting with a comparison function
On 10 Okt., 20:38, [EMAIL PROTECTED] wrote: Kay Schluehr: Sometimes it helps when people just make clear how they use technical terms instead of invoking vague associations. And generally Python docs can enjoy growing few thousands examples... Cleaning up and extending documentation is a large community effort that requires an informational PEP for guidelines and management support by the python-dev leads. The official documentation is ad hoc and just about better than nothing. A Python documentation guideline might also have positive impact on 3rd party package authors like us. Generally Python has become a very well managed project. I hope the docs as well as the stdlib will become the major concerns of Python 3.1. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3: sorting with a comparison function
On 10 Okt., 23:04, Terry Reedy [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Me too because I don't get this: key specifies a function of one argument that is used to extract a comparison key from each list element: key=str.lower. The default value is None. I am not sure what you do not get, but it should say 'for example, key=str.lower. None is the default value of key. See the discussion above. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to read a jpg bytearray from a Flash AS3 file
On 26 Sep., 08:47, [EMAIL PROTECTED] wrote: I'm trying to save an image from a Flash AS3 to my server as a jpg file. I found some PHP code to do this, but I want to do this in Python. I'd expect you use AS3 to save the image file ( just looking at Adobes AS3 docs on how this works ) and load it with PIL if you want to post- process it in Python: http://www.pythonware.com/products/pil/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Does anybody use this web framework ?
On 24 Sep., 09:26, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Phil Cataldo a écrit : Hi, I just found this new? python web framework (http://pypi.python.org/pypi/nagare/0.1.0). Does anybody know or use it ? First time I hear of it, but it looks interesting (note : Stackless continuation-based framework). Thanks for the link. Dito! -- http://mail.python.org/mailman/listinfo/python-list
