Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu
Antoine Pitrou wrote: > > >> Even if their servers won't run ubuntu 11.04+ (or something with the > > >> same library paths), their development environments will. > > > > > >They can also patch the Python releases themselves, or use Ubuntu > > >packages that someone else made for them (they can probably just install > > >the old 2.4 packages just fine). > > > > The Python 2.6, 2.7, and 3.2 packages in Ubuntu 11.04 already have > > essentially > > the same patch that I posted, so folks using Python 2.6 from the operating > > system will not have a problem. Without this patch in our repository, folks > > building Python 2.6 from source will have to be aware of it. > > So let them use Python 2.6 from Ubuntu. Case closed! It isn't that simple. For example, I have automated scripts that test cdecimal against decimal.py for *every* release from r25 to r32. This is also the reason why I was unhappy that r25 did not build from Mercurial initially. There has been a lot of churn lately for module authors, starting with __pycache__, cpython-32m.so suffixes and ending in the mercurial transition. In this case, it's clearly Ubuntu who is going to break things. Still, the proposed patch could make life a lot easier for many people. Stefan Krah ___ 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] Python 3.3 release schedule posted
On Wed, Mar 23, 2011 at 9:56 PM, Georg Brandl wrote: > I've posted a very preliminary Python 3.3 release schedule as PEP 398. > The final release is set to be about 18 months after 3.2 final, which > is in August 2012. Why this isn't being added to Release Calendar on the front page? Do you have an estimate of Python 3.2.1 release? ___ 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] Unicode module names (Was: Python 3.3 release schedule posted)
On Thu, Mar 24, 2011 at 2:41 AM, Victor Stinner wrote: > > I am still working on the import machinery to fix last bugs related to > Unicode. So it will be possible to do an useless "import café" in Python > 3.3, on any platform. But it is not really an huge change (for the user, > but an huge change in the code ;-)). I don't like the idea of reading the code with some kind of Chinese variable names in them. I'd prefer that I and l confusion will be the only I should care about in valid Python syntax. ___ 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] Decisions about workflow
On Sat, Mar 26, 2011 at 5:54 PM, wrote: > > Antoine> Take a look at: > Antoine> http://docs.python.org/devguide/committing.html > > What form should directed graphs be in for inclusion? Pictures. But so far I haven't seen any Graphviz-like tools in pure Python. http://code.google.com/p/rainforce/issues/detail?id=4 ___ 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] Unicode module names (Was: Python 3.3 release schedule posted)
Am 02.04.2011 15:06, schrieb anatoly techtonik: > On Thu, Mar 24, 2011 at 2:41 AM, Victor Stinner > wrote: >> >> I am still working on the import machinery to fix last bugs related to >> Unicode. So it will be possible to do an useless "import café" in Python >> 3.3, on any platform. But it is not really an huge change (for the user, >> but an huge change in the code ;-)). > > I don't like the idea of reading the code with some kind of Chinese > variable names in them. I'd prefer that I and l confusion will be the > only I should care about in valid Python syntax. Sorry, that ship sailed long ago, and Unicode identifiers are allowed since Python 3.0. Victor's work is just to extend this to importable module names. Georg ___ 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] Decisions about workflow
>> Antoine> Take a look at: >> Antoine> http://docs.python.org/devguide/committing.html >> >> What form should directed graphs be in for inclusion? anatoly> Pictures. anatoly> But so far I haven't seen any Graphviz-like tools in pure Python. anatoly> http://code.google.com/p/rainforce/issues/detail?id=4 Yeah, I sort of figured that. :-) I meant JPEG? PNG? ASCII art? Some sort of graph notation (like Graphviz)? MoinMoin .draw notation? Does ReST support any sort of embedded images or diagrams? Skip ___ 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] Decisions about workflow
On Sun, Apr 3, 2011 at 1:36 AM, wrote: > Yeah, I sort of figured that. :-) I meant JPEG? PNG? ASCII art? Some sort > of graph notation (like Graphviz)? MoinMoin .draw notation? Does ReST > support any sort of embedded images or diagrams? Taking PEP 1 as the precedent, I would suggest going with PNG (looking at the PEP 1 source also shows how to embed an image in the ReST file, too). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Decisions about workflow
In a message of Sat, 02 Apr 2011 10:36:01 CDT, s...@pobox.com writes: >>> =A0 =A0Antoine> Take a look at: >>> =A0 =A0Antoine> http://docs.python.org/devguide/committing.html >>> = > >>> What form should directed graphs be in for inclusion? > >anatoly> Pictures. > >anatoly> But so far I haven't seen any Graphviz-like tools in pure Py >th= >on. >anatoly> http://code.google.com/p/rainforce/issues/detail?id=3D4 > >Yeah, I sort of figured that. :-) I meant JPEG? PNG? ASCII art? Some so >rt >of graph notation (like Graphviz)? MoinMoin .draw notation? Does ReST >support any sort of embedded images or diagrams? > >Skip Sphinx lets you embed graphviz. http://sphinx.pocoo.org/ext/graphviz.html?highlight=image Laura ___ 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] not possible to install python 3.2
I order to install Python as python3 on Linux, i did: ./configure make make test sudo make install However, when i typed "make test", i got two error messages: "test test_distutils failed -- multiple errors occurred; run in verbose mode for details" "sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='ANSI_X3.4-1968'> make: *** [test] Error 1" The Result? When I type python on Linux, i get the older version 2.7.1 instead of the version that i just installed (python 3.2). Could you help me? Thank you, Laura ___ 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] The path module PEP
Hello BJörn, Like you I've used the Path module one time or another. It is an excellent concept to refactor the confusing collection of file handling methods. I have not used it consistently, mainly because the module has not been maintained and it is not in the standard library as it should be. I have found a proposal on PEP from a while ago. I wonder what is the status of it? http://mail.python.org/pipermail/python-dev/2006-January/060026.html Are you still actively using Python and the Path module? I have a couple of ideas that might improve it further. I hope to find enough fans of it polished it. Cheer, Wai Yip ___ 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] not possible to install python 3.2
You should ask python-list instead of here. 2011/3/29 Laura : > I order to install Python as python3 on Linux, i did: > > > ./configure > make > make test > sudo make install > > > However, when i typed "make test", i got two error messages: > > "test test_distutils failed -- multiple errors occurred; run in verbose mode > for details" > > "sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' > mode='a' encoding='ANSI_X3.4-1968'> > make: *** [test] Error 1" > > The Result? When I type python on Linux, i get the older version 2.7.1 > instead of the version that i just installed (python 3.2). Actually, it's because Python 3 is installed as python3. -- Regards, Benjamin ___ 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] Decisions about workflow
Laura> Sphinx lets you embed graphviz. Laura> http://sphinx.pocoo.org/ext/graphviz.html?highlight=image Cool, thanks. I'm going to try to reproduce Nick's setup as he described it. That would certainly be a whole lot easy for me to understand, hopefully for others as well. Skip ___ 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] Decisions about workflow
In a message of Sat, 02 Apr 2011 12:56:13 CDT, s...@pobox.com writes: > >Laura> Sphinx lets you embed graphviz. >Laura> http://sphinx.pocoo.org/ext/graphviz.html?highlight=image > >Cool, thanks. I'm going to try to reproduce Nick's setup as he described >it. That would certainly be a whole lot easy for me to understand, >hopefully for others as well. > >Skip *DEFINITELY* for me too! Laura ___ 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] Policy for making changes to the AST
Hello, While working on a rewrite of peephole optimizer that works on AST (http://bugs.python.org/issue11549) I had to make a few changes to the structure of AST. The changes are described in the issue. This raises the question -- what is the policy for making changes to the AST? Documentation for ast module does not warn about possible changes, but obviously changes can occur, for example, when new constructs are introduced. What about other changes? Is there a policy for what's acceptable and how this should be handled? Assuming we do want to make changes (not just extensions for new language features), I see 3 options for handling them: 1. Do nothing. This will break code that currently uses AST, but doesn't add any complexity to cpython. 2. Write a pure-Python compatibility layer. This will convert AST between old and new formats, so that old code continues working. To do this a) Introduce ast.compile function (similar to ast.parse), which should be the recommended way of compiling to AST. b) Add ast_version argument to ast.parse and ast.compile defaulting to 1. c) Preserve old AST node classes and attributes in Python. d) If ast_version specified is not the latest, ast.parse and ast.compile would convert from/to latest version in Python using ast.NodeTransformer. This is not fully backward compatible, but allows to do all staging in Python. 3. Full backward compatibility (with Python code). This means conversion is done in compile(). It can either call Python conversion code from ast module, or actually implement conversion in C using AST visitors. Using my visitors generator this should not be very hard. Downsides here are a lot of C code and no clear separation of deprecated AST nodes (they will remain in Python.asdl). Otherwise it's similar to 2, with ast_version argument added to compile() and ast.parse. For 2 and 3 we can add a PendingDeprecationWarning when ast_version 1 is used. In any case, C extensions that manipulate AST will be broken, but 3 provides a simple way to update them -- insert calls to C conversion functions. Eugene ___ 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] Policy for making changes to the AST
2011/4/2 Eugene Toder : > Hello, > > While working on a rewrite of peephole optimizer that works on AST > (http://bugs.python.org/issue11549) I had to make a few changes to the > structure of AST. The changes are described in the issue. This raises the > question -- what is the policy for making changes to the AST? Documentation > for ast module does not warn about possible changes, but obviously changes > can occur, for example, when new constructs are introduced. What about other > changes? Is there a policy for what's acceptable and how this should be > handled? > > Assuming we do want to make changes (not just extensions for new language > features), I see 3 options for handling them: > > 1. Do nothing. This will break code that currently uses AST, but doesn't add > any complexity to cpython. I must say I prefer this option. I don't know how many people are depending on AST, but I think they can expect it be broken occasionally. AST analyzing code can expect to be broken anyway every version new semantics are added. Maintaining versioned asts and converting between them is just clunky. There are some AST cleanups I'd like to happen, too, such as unifying TryExcept and TryFinally into a single node. -- Regards, Benjamin ___ 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] not possible to install python 3.2
On Wed, Mar 30, 2011 at 8:48 AM, Laura wrote: > The Result? When I type python on Linux, i get the older version 2.7.1 > instead of the version that i just installed (python 3.2). > > Could you help me? As Benjamin noted, this is a question about using (/building) a released version of Python, and hence more appropriate for python-list. python-dev is for discussing the development of *future* versions of Python. Regards, Nick. P.S. However, also note that, due to the fact that it cannot run many current Python 2.x scripts, the default installation process for Python 3.x creates a "python3" command, rather than a "python" command. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Decisions about workflow
On Sun, Apr 3, 2011 at 4:25 AM, Laura Creighton wrote: > In a message of Sat, 02 Apr 2011 12:56:13 CDT, s...@pobox.com writes: >> >> Laura> Sphinx lets you embed graphviz. >> Laura> http://sphinx.pocoo.org/ext/graphviz.html?highlight=image >> >>Cool, thanks. I'm going to try to reproduce Nick's setup as he described >>it. That would certainly be a whole lot easy for me to understand, >>hopefully for others as well. >> >>Skip > > *DEFINITELY* for me too! I'll reproduce it in dodgy ASCII art here, but a real diagram would definitely help in making the flow of changes clearer: public sandbox (hg.python.org/sandbox/ncoghlan) <=> (push and pull) local sandbox <= (pull only) main repository (hg.python.org/cpython) <=> local py3k <=> local python27 <=> local python32 <=> local python31 Once python31 drops into security-fixes-only mode after the next maintenance release, I'll likely ditch that local repository. In the sandbox, I try to leave the default branch as a clean copy of cpython#default (and ditto for the maintenance branches), with anything I am working on off in a named branch (usually branched from default, but I could also branch from an older maintenance branch, such as 2.7, if the situation called for it). Having the separate sandbox also allows me to defer the decision on how far back to apply a change until such time as I am actually committing the patch to the official repositories. To commit a fix that applies to 2.7, 3.1 and all subsequent branches is a matter of doing: cd python27 hg import --no-commit patch-for-27.diff (I'm still trying to get in the habit of using this over patch, though) # build and test hg commit -m "Fix #123456789: Feed the half a bee" hg push cd ../python31 hg import --no-commit patch-for-31.diff # build and test hg commit -m "Fix #123456789: Feed the half a bee" hg push cd ../python32 hg merge 3.1 # build and quick test hg commit -m "Merge from 3.1. Fix #123456789" hg push cd ../py3k hg merge 3.2 # build and quick test hg commit -m "Merge from 3.2. Fix #123456789" hg push The final push uploads the whole thing to hg.python.org/cpython as a single consistent block - no temporary unmerged heads are created on the maintenance branches. If someone else has committed changes in the meantime, then I need to hg pull and merge the changes all the way back down the chain. (This is somewhat annoying for a full 4-branch commit like the one shown, but most commits aren't that bad. New features are only on default, and a lot of other changes are 3.2+default only) If using the "share" extension, you could drop all of the "hg push" commands except the last one (since there is only one local repository in that case, there aren't any push/pull commands needed to synchronise things). The other thing I like about this setup is that you can use it as a basis to explain other possible approaches to managing your local workflow: - Using "mq" is essentially an alternative to having a separate local sandbox - Using "share" means that python27/32/31 become additional working copies attached to the py3k repository rather than local repositories in their own right - You can leave out python27/32/31 entirely, and just do a lot more switching and rebuilding in the py3k directory Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Policy for making changes to the AST
On Sun, Apr 3, 2011 at 12:07 PM, Benjamin Peterson wrote: >> Assuming we do want to make changes (not just extensions for new language >> features), I see 3 options for handling them: >> >> 1. Do nothing. This will break code that currently uses AST, but doesn't add >> any complexity to cpython. > > I must say I prefer this option. I don't know how many people are > depending on AST, but I think they can expect it be broken > occasionally. AST analyzing code can expect to be broken anyway every > version new semantics are added. > > Maintaining versioned asts and converting between them is just clunky. This is my preference as well, but I wanted to give *consumers* of the AST a chance to scream at us before we break their world. The compatibility problem doesn't go away if we ignore it - it just devolves to the people doing the AST manipulation to invent their own way of handling any cross-version compatibility dramas that arise. However, I'm not sure we *can* do a general-purpose AST transformation that handles both new nodes and changes to existing nodes correctly for all applications. What changes are needed and/or acceptable will likely be very heavily dependent on the specifics of what people are doing with the AST. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Decisions about workflow
Skip> I'm going to try to reproduce Nick's setup as he described it. Skip> That would certainly be a whole lot easy for me to understand, Skip> hopefully for others as well. Laura> *DEFINITELY* for me too! Nick> I'll reproduce it in dodgy ASCII art here, but a real diagram Nick> would definitely help in making the flow of changes clearer: ... This isn't exactly Nick's setup, and I've never used graphviz/dot before, so I don't yet know how to lay things out, but, here's a first crack at it: http://www.smontanaro.net/hgpython.png http://www.smontanaro.net/hgpython.gv Skip ___ 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] Decisions about workflow
On Sun, Apr 3, 2011 at 1:23 PM, wrote: > This isn't exactly Nick's setup, and I've never used graphviz/dot before, so > I don't yet know how to lay things out, but, here's a first crack at it: > > http://www.smontanaro.net/hgpython.png > http://www.smontanaro.net/hgpython.gv I don't think you can easily push changes between 2 remote repositories like that. It's also somewhat painful to have local changes that you *don't* want to push - you have to be selective about what gets sent to the remote repository, so a simple "hg push" doesn't work any more. I forgot to mention the other advantage of having a local sandbox that corresponds to your public sandbox - it makes it easy to keep your work area in sync across multiple machines. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Policy for making changes to the AST
> However, I'm not sure we *can* do a general-purpose AST transformation > that handles both new nodes and changes to existing nodes correctly > for all applications. As long as both versions contain the same information we can write a transformation that does a near-perfect job. E.g. for my changes I can write a convertor that produces AST in almost the same form as the current one, the only change being the new 'docstring' attribute set to None. (That's for converting AST before optimizations, after optimizations it can contain nodes that couldn't be represented before). I believe it's similar for Try change that Benjamin mentioned above. Also, if written in Python, conversion can at least serve as a template even if it doesn't work out of the box. Eugene ___ 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] Policy for making changes to the AST
On Sun, Apr 3, 2011 at 2:24 PM, Eugene Toder wrote: >> However, I'm not sure we *can* do a general-purpose AST transformation >> that handles both new nodes and changes to existing nodes correctly >> for all applications. > > As long as both versions contain the same information we can write a > transformation that does a near-perfect job. > E.g. for my changes I can write a convertor that produces AST in > almost the same form as the current one, the only change being the new > 'docstring' attribute set to None. (That's for converting AST before > optimizations, after optimizations it can contain nodes that couldn't > be represented before). I believe it's similar for Try change that > Benjamin mentioned above. > > Also, if written in Python, conversion can at least serve as a > template even if it doesn't work out of the box. If it's do-able, your option 2 is probably the way to go. Out of the box, it may just need to raise an exception if asked to down-convert code that uses new constructs that can't readily be expressed using the old AST (I'm specifically thinking of the challenge of converting PEP 380's yield-from). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Policy for making changes to the AST
> If it's do-able, your option 2 is probably the way to go. Out of the > box, it may just need to raise an exception if asked to down-convert > code that uses new constructs that can't readily be expressed using > the old AST (I'm specifically thinking of the challenge of converting > PEP 380's yield-from). I was talking only about changes in AST for existing constructs. New language features is another dimension. For example, we can leave them even in "old" trees, so that they can be supported in existing code with minimal changes. Or we can throw, forcing everyone who wants to process them to catch up with all other AST changes. I realized I overlooked one problem with supporting multiple versions of AST. Functions from ast module might need to know which AST version they've got. For example, ast.get_docstring will need to know whether docstring was populated or it needs to look in the body. This can be solved by attaching ast_version to affected nodes when converting. Eugene ___ 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] Python 3.3 release schedule posted
Am 02.04.2011 15:00, schrieb anatoly techtonik: > On Wed, Mar 23, 2011 at 9:56 PM, Georg Brandl wrote: >> I've posted a very preliminary Python 3.3 release schedule as PEP 398. >> The final release is set to be about 18 months after 3.2 final, which >> is in August 2012. > > Why this isn't being added to Release Calendar on the front page? It is. > Do you have an estimate of Python 3.2.1 release? Not yet. Georg ___ 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] Policy for making changes to the AST
On Sun, Apr 3, 2011 at 3:42 PM, Eugene Toder wrote: >> If it's do-able, your option 2 is probably the way to go. Out of the >> box, it may just need to raise an exception if asked to down-convert >> code that uses new constructs that can't readily be expressed using >> the old AST (I'm specifically thinking of the challenge of converting >> PEP 380's yield-from). > > I was talking only about changes in AST for existing constructs. New > language features is another dimension. For example, we can leave them > even in "old" trees, so that they can be supported in existing code > with minimal changes. Or we can throw, forcing everyone who wants to > process them to catch up with all other AST changes. I wonder if there's any existing research on the topic - we can't be the first people to confront these kinds of problems. > I realized I overlooked one problem with supporting multiple versions > of AST. Functions from ast module might need to know which AST version > they've got. For example, ast.get_docstring will need to know whether > docstring was populated or it needs to look in the body. This can be > solved by attaching ast_version to affected nodes when converting. Or just have a top level version node. If it isn't there, then it's version 1. (Although that could make working on subsections of the AST a little trickier) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Policy for making changes to the AST
> 1. Do nothing. This will break code that currently uses AST, but doesn't add > any complexity to cpython. I'm in favor of this approach as well. Notice that there is ast.__version__ precisely so that applications can support multiple AST versions. 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
