Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
Barry Scott wrote: I recursive grep'ed and missed this ref. However I did read this in README.TXT: > Building on non-UNIX systems > > For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 6.0, the > project files are in PCbuild, the workspace is pcbuild.dsw. See > PCbuild\readme.txt for detailed instructions. Which says that PCbuild/readme.txt is about VC++ 6.0 I see. This is now corrected in CVS. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Website documentation - link to descriptor information
On Thu, Dec 23, 2004 at 09:41:20PM +1000, Nick Coghlan wrote: > I just spent 10 minutes hunting through the Python website for this link: > http://www.python.org/doc/newstyle.html > > I knew it was there somewhere, I just couldn't find the darn thing. > > It turns out the major mistake I made was to start from "docs.python.org" > instead of "www.python.org/doc". It's on docs.python.org now. Cheers, Johannes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
Barry Scott <[EMAIL PROTECTED]> writes: > I recursive grep'ed and missed this ref. However I did read this in > README.TXT: The top-level README file is hilariously out-of-date, in some ways. I meant to do something about this before 2.4 final, but didn't get around to it... Cheers, mwh -- speak of the devil exarkun: froor not you -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
Hi, On Fri, Dec 24, 2004 at 12:17:49AM +, Barry Scott wrote: > I recursive grep'ed and missed this ref. However I did read this in > README.TXT: The "extending and embedding" tutorial is similarily out-of-date. Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
Armin Rigo <[EMAIL PROTECTED]> writes: > Hi, > > On Fri, Dec 24, 2004 at 12:17:49AM +, Barry Scott wrote: >> I recursive grep'ed and missed this ref. However I did read this in >> README.TXT: > > The "extending and embedding" tutorial is similarily out-of-date. Well, I've half re-written that (the entire thing, see doc-sig passim) but this hasn't attracted a great deal of interest. I've just uploaded my most recent version to: http://starship.python.net/crew/mwh/toext/ I haven't done any substantial work on it in a while, and probably won't have time to do any for some time. It would still be nice to have it ready in the 2.5 timeframe. Cheers, mwh -- A difference which makes no difference is no difference at all. -- William James (I think. Reference anyone?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Merry Christmas and a Happy New Year to all Python developers!
I'm about to travel to a place where I don't expect to have internet access for over a week, so this is my last message in 2004. I'll have more time next year for Python that I had this year, so I'm looking forward to working again with this great community. I wish everyone happy celebrations of the dark season, and I hope to see many of you at the upcoming PyCon conference. Cheers! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] proto-pep: How to change Python's bytecode
After implementing over 10 new opcodes for my thesis I figured I should write down the basic steps in an info PEP so that there is enough guidelines with this PEP and PEP 306 to cover the bases on changes to the language itself. To go along with this I also plan to write some benchmarks for individual opcodes that could possibly lead to a testing suite for the opcodes themselves (will probably do this piece-meal and put it up on SF initially since there are a lot of opcodes). Anyway, let me know if I seem to be missing anything or have something to add. After a reasonable time of non-response to this I will request a PEP number (assuming people don't think this PEP is stupid). -- PEP: XXX Title: How to change Python's bytecode Version: $Revision: 1.4 $ Last-Modified: $Date: 2003/09/22 04:51:50 $ Author: Brett Cannoon <[EMAIL PROTECTED]> Status: Draft Type: Informational Content-Type: text/x-rst Created: XX-XXX- Post-History: XX-XXX- Abstract Python source code is compiled down to something called bytecode. This bytecode (which can be viewed as sequences of opcodes) defines what Python is capable of. As such, knowing how to add, remove, or change the bytecode is important to do properly when changing the abilities of the Python language. Rationale = While changing Python's bytecode is not a frequent occurence, it still happens. Having the required steps documented in a single location should make experimentation with the bytecode easier since it is not necessarily obvious what the steps are to change the bytecode. This PEP, paired with PEP 306 [#PEP-306]_, should provide enough basic guidelines for handling any changes performed to the Python language itself in terms of syntactic changes that introduce new semantics. Checklist = This is a rough checklist of what files need to change and how they are involved with the bytecode. All paths are given from the viewpoint of ``/cvsroot/python/dist/src`` from CVS). This list should not be considered exhaustive nor to cover all possible situations. - ``Include/opcode.h`` This include file lists all known opcodes and associates each opcode name with a unique number. When adding a new opcode it is important to take note of the ``HAVE_ARGUMENT`` value. This ``#define``'s value specifies the value at which all opcodes that have a value greater than ``HAVE_ARGUMENT`` are expected to take an argument to the opcode. - ``Lib/opcode.py`` Lists all of the opcodes and their associated value. Used by the dis module [#dis]_ to map bytecode values to their names. - ``Python/ceval.c`` Contains the main interpreter loop. Code to handle the evalution of an opcode here. - ``Python/compile.c`` To make sure an opcode is actually used, this file must be altered. The emitting of all bytecode occurs here. - ``Lib/compiler/pyassem.py``, ``Lib/compiler/pycodegen.py`` The 'compiler' package [#compiler]_ needs to be altered to also reflect any changes to the bytecode. - ``Doc/lib/libdis.tex`` The documentation [#dis-docs] for the dis module contains a complete list of all the opcodes. - ``Python/import.c`` Defines the magic word (named ``MAGIC``) used in .pyc files to detect if the bytecode used matches the one used by the version of Python running. This number needs to be changed to make sure that the running interpreter does not try to execute bytecode that it does not know about. Suggestions for bytecode development A few things can be done to make sure that development goes smoothly when experimenting with Python's bytecode. One is to delete all .py(c|o|w) files after each semantic change to Python/compile.c . That way all files will use any bytecode changes. Make sure to run the entire testing suite [#test-suite]_. Since the ``regrtest.py`` driver recompiles all source code before a test is run it acts a good test to make sure that no existing semantics are broken. Running parrotbench [#parrotbench]_ is also a good way to make sure existing semantics are not broken; this benchmark is practically a compliance test. References == .. [#PEP-306] PEP 306, How to Change Python's Grammar, Hudson (http://www.python.org/peps/pep-0306.html) .. [#dis] XXX .. [#test-suite] XXX .. [#parrotbench] XXX .. [#dis-docs] XXX Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: proto-pep: How to change Python's bytecode
Brett C. wrote: A few things can be done to make sure that development goes smoothly when experimenting with Python's bytecode. One is to delete all .py(c|o|w) Don't you mean ".pyc or .pyo (remember such files in zips as well)" .pyw is normal python source. -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: proto-pep: How to change Python's bytecode
"Brett C." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] At to the title, bytecodes are a property of the CPython implementation, not of Python itself. Since I think the distinction is quite important to maintain, I would insert the missing 'C' and everywhere else as appropriate. > After implementing over 10 new opcodes for my thesis I figured I should > write down the basic steps in an info PEP so that there is enough > guidelines with this PEP and PEP 306 to cover the bases on changes to the > language itself. Over the last several years, various people have reported experimenting with CPython's bytecodes. I wonder if it would be helpful to have a respository of the results, in one place, for new experimenters and curious people to peruse. > Anyway, let me know if I seem to be missing anything or have something to > add. As I said, the importanct 'C' qualifier. > PEP: XXX > Title: How to change Python's bytecode /P/CP/ > Python source code is compiled down to something called bytecode. Suggested replacements in quotes: "CPython compiles Python source code to something called bytecode." > This bytecode (which can be viewed as sequences of opcodes) > defines what Python is capable of. This is backwards. "The language, as defined in the Reference Manual, determines what bytecodes are needed (collectively, not one by one) for a bytecode implementation." > As such, knowing how to add, remove, or change the bytecode is > important to do properly when changing the abilities of the Python > language. "Therefore, changes in the language may require changes in the set of bytecodes. In addition, changing the bytecode set for a given definition may result in desireable changes in the interpreter behavior. This document describes how to do so for either reason." > Rationale > = > > While changing Python's bytecode is not a frequent occurence, it still > happens. /P/CP/ Experiments are much more frequent than committed changes -- all of which start as experiments. ... Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
