[Python-Dev] Oddity in AST for 3-argument slices
I've discovered a slightly surprising thing about the way
AST objects for slices are constructed. According to
Python.asdl, all three parts of a slice are optional:
slice = Slice(expr? lower, expr? upper, expr? step)
But that's not quite the way the parser sees things:
Python 3.1.2 (r312:79147, Aug 19 2010, 20:26:20)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> t = ast.parse("x[::]", mode='eval')
>>> ast.dump(t)
"Expression(body=Subscript(value=Name(id='x', ctx=Load()),
slice=Slice(lower=None, upper=None, step=Name(id='None', ctx=Load())), ctx=Load()))"
In other words,
x[::]
is being parsed as though it had been written
x[::None]
Is there a good reason for an omitted third slice
argument being treated differently from the others?
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity in AST for 3-argument slices
On Thu, Aug 19, 2010 at 6:36 PM, Greg Ewing wrote:
> In other words,
>
> x[::]
>
> is being parsed as though it had been written
>
> x[::None]
>
> Is there a good reason for an omitted third slice
> argument being treated differently from the others?
Probably so it looks different from the AST for x[:]
>>> ast.dump(ast.parse("x[:]", mode='eval'))
"Expression(body=Subscript(value=Name(id='x', ctx=Load()),
slice=Slice(lower=None, upper=None, step=None), ctx=Load()))"
>>> ast.dump(ast.parse("x[::]", mode='eval'))
"Expression(body=Subscript(value=Name(id='x', ctx=Load()),
slice=Slice(lower=None, upper=None, step=Name(id='None', ctx=Load())),
ctx=Load()))"
Or else it's just an accident of implementation, since the AST doesn't
actually *need* to distinguish those two cases.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, Aug 19, 2010 at 12:47 AM, Éric Araujo wrote: > Let’s turn one error into an occasion for learning: > >> Log: >> Manually merge r84187 > > I was bad with numbers and actually ran svnmerge merge -r 81417, which > did nothing. Since I have manually merged now, do I have to update the > bookkeeping information manually? My understanding of the dev FAQ is: > svnmerge block -r 84187. Is that right? What I do is : 4 cd /the/right/branch/or/trunk $ svn ci -m 'comment' you get a revision number $ cd py3k $ svn up $ svnmerge.py merge -r revision $ run the tests $ svn ci -F svn (there's a svn*.txt file generated by the svnmerge tool, don't do a manual comment) Then I apply the same in all branches. Notice that if you merge something to py3k, the merge to the 3.x release branch is done with the revision number of the py3k commit, not the original one. And I use "svnmerge block -r revision" for branches where the commit should not be applied, don't forget to do this. (same revision number cascading applies) Let me know if you have any other issue Cheers arek > > Thank you. > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
Le jeudi 19 août 2010 12:07:36, Tarek Ziadé a écrit : > What I do is : > > 4 cd /the/right/branch/or/trunk > $ svn ci -m 'comment' > you get a revision number > > $ cd py3k > $ svn up > $ svnmerge.py merge -r revision > (...) Wrong. trunk branch is dead, py3k is the new main branch ;-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, Aug 19, 2010 at 12:17 PM, Victor Stinner wrote: > Le jeudi 19 août 2010 12:07:36, Tarek Ziadé a écrit : >> What I do is : >> >> 4 cd /the/right/branch/or/trunk >> $ svn ci -m 'comment' >> you get a revision number >> >> $ cd py3k >> $ svn up >> $ svnmerge.py merge -r revision >> (...) > > Wrong. trunk branch is dead, py3k is the new main branch ;-) s/trunk/2.7 branch/ > > -- > Victor Stinner > http://www.haypocalc.com/ > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity in AST for 3-argument slices
Nick Coghlan wrote: Or else it's just an accident of implementation, since the AST doesn't actually *need* to distinguish those two cases. It doesn't seem to be an accident, because ast_for_slice() goes out of its way to manufacture a Name node for the missing argument. It doesn't seem to significantly simplify the compiler either, because compiler_slice() could just as easily treat it the same way as the other slice arguments and emit an instruction to load None if it's missing. So it's a mystery. Perhaps it made life easier for some earlier version of the compiler. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
Thanks for the replies. The dev FAQ is clear about regular use, it tells about the svnmerge-commit-message too, and people in #python-dev have told me that the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I committed r84190 in 3.1 manually, but it should have been an svnmerge of r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? > And I use "svnmerge block -r revision" for branches where the commit > should not be applied, don't forget to do this. Oh, this has to be done for every commit? I have for example fixed typos in 3.x that don’t apply to 2.7, so I have to block them? Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On 8/19/2010 7:55 AM, Éric Araujo wrote: Thanks for the replies. The dev FAQ is clear about regular use, it tells about the svnmerge-commit-message too, and people in #python-dev have told me that the merge order is py3k> 3.1, py3k> 2.7. My problem here is that I committed r84190 in 3.1 manually, but it should have been an svnmerge of r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? Yes, you should do that. And I use "svnmerge block -r revision" for branches where the commit should not be applied, don't forget to do this. Oh, this has to be done for every commit? I have for example fixed typos in 3.x that don’t apply to 2.7, so I have to block them? I don't know that this matters, since I don't think anyone's doing mass merges in this direction. I tend to do it just for my own bookkeeping purposes, though. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, Aug 19, 2010 at 2:00 PM, Eric Smith wrote: > On 8/19/2010 7:55 AM, Éric Araujo wrote: >> >> Thanks for the replies. >> >> The dev FAQ is clear about regular use, it tells about the >> svnmerge-commit-message too, and people in #python-dev have told me that >> the merge order is py3k> 3.1, py3k> 2.7. My problem here is that I >> committed r84190 in 3.1 manually, but it should have been an svnmerge of >> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? > > Yes, you should do that. > >>> And I use "svnmerge block -r revision" for branches where the commit >>> should not be applied, don't forget to do this. >> >> Oh, this has to be done for every commit? I have for example fixed typos >> in 3.x that don’t apply to 2.7, so I have to block them? > > I don't know that this matters, since I don't think anyone's doing mass > merges in this direction. I tend to do it just for my own bookkeeping > purposes, though. I do it every time myself, AFAIK it reduces the workload of people that are making sure all pending patches were applied. Not doing a block right away for me means: I need to merge it to that branch, but I can't do it now (lack of time, or imminent release) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity in AST for 3-argument slices
On Thu, Aug 19, 2010 at 8:35 PM, Greg Ewing wrote: > Nick Coghlan wrote: > >> Or else it's just an accident of implementation, since the AST doesn't >> actually *need* to distinguish those two cases. > > It doesn't seem to be an accident, because ast_for_slice() > goes out of its way to manufacture a Name node for the > missing argument. > > It doesn't seem to significantly simplify the compiler > either, because compiler_slice() could just as easily > treat it the same way as the other slice arguments and > emit an instruction to load None if it's missing. > > So it's a mystery. Perhaps it made life easier for some > earlier version of the compiler. Ah, it's a 2.x-ism. The old compiler needed to know whether or not to try __get/set/delslice__ (yes for x[:], no for x[::]). With those magic methods gone, that would make it obsolete in 3.x, so x[::] should probably just be changed to generate the same AST as x[:] now. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, Aug 19, 2010 at 9:55 PM, Éric Araujo wrote: > Thanks for the replies. > > The dev FAQ is clear about regular use, it tells about the > svnmerge-commit-message too, and people in #python-dev have told me that > the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I > committed r84190 in 3.1 manually, but it should have been an svnmerge of > r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? Better to do "svnmerge merge --record-only -r84187". (I have another request for the dev FAQ - could we get an FAQ entry about how to update the FAQ itself? I usually just post here in the hopes that someone will fix it, but we should be able to do better than that. People have told me many times in the past how it actually gets updated, but it never sticks in my memory). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, Aug 19, 2010 at 10:00 PM, Eric Smith wrote: >> Oh, this has to be done for every commit? I have for example fixed typos >> in 3.x that don’t apply to 2.7, so I have to block them? > > I don't know that this matters, since I don't think anyone's doing mass > merges in this direction. I tend to do it just for my own bookkeeping > purposes, though. This is probably a self-fulfilling prophecy. I know my last few feature commits, I've moved on to the next feature I wanted to implement rather than blocking the feature from 2.7 and 3.1. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
Am 19.08.2010 15:32, schrieb Nick Coghlan: > On Thu, Aug 19, 2010 at 9:55 PM, Éric Araujo wrote: >> Thanks for the replies. >> >> The dev FAQ is clear about regular use, it tells about the >> svnmerge-commit-message too, and people in #python-dev have told me that >> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I >> committed r84190 in 3.1 manually, but it should have been an svnmerge of >> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? > > Better to do "svnmerge merge --record-only -r84187". > > (I have another request for the dev FAQ - could we get an FAQ entry > about how to update the FAQ itself? I usually just post here in the > hopes that someone will fix it, but we should be able to do better > than that. People have told me many times in the past how it actually > gets updated, but it never sticks in my memory). Once we switch to SVN, the FAQ will get moved to its own repository and be independent of the rest of the python.org website. Until then, you need pydotorg commit privs and update it like other pages on python.org Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug in randint when importing pylab?
I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box. If I run the following: [code] from pylab import randint for s in range(100): print randint(0,1) [/code] I get 100 zeroes. If I import randint from random instead, I get the expected behavior of a random distribution of 1s and 0s. I found this by importing * from pylab after importing randint from random. What is going on? Is pylab's randint function broken somehow? Could this be due to installing scipy into a 2.6 environment when it was designed for the 2.5 environment? cinead ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in randint when importing pylab?
Hi, 2010/8/19 Timothy Kinney : > I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box. This mailing list is for development *of* python, not about development *with* python. Your question should be directed to the comp.lang.python newsgroup, or the python-list mailing list. In any case, reading the documentation of both functions should answer your question. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in randint when importing pylab?
On Fri, Aug 20, 2010 at 1:02 AM, Amaury Forgeot d'Arc wrote: > Hi, > > 2010/8/19 Timothy Kinney : >> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box. > > This mailing list is for development *of* python, not about > development *with* python. > Your question should be directed to the comp.lang.python newsgroup, or > the python-list mailing list. actually, the numpy and/or matplotlib ML would be even better in that case :) David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
On Thu, 19 Aug 2010 17:28:19 +0200 Georg Brandl wrote: > Am 19.08.2010 15:32, schrieb Nick Coghlan: > > On Thu, Aug 19, 2010 at 9:55 PM, Éric Araujo wrote: > >> Thanks for the replies. > >> > >> The dev FAQ is clear about regular use, it tells about the > >> svnmerge-commit-message too, and people in #python-dev have told me that > >> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I > >> committed r84190 in 3.1 manually, but it should have been an svnmerge of > >> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? > > > > Better to do "svnmerge merge --record-only -r84187". > > > > (I have another request for the dev FAQ - could we get an FAQ entry > > about how to update the FAQ itself? I usually just post here in the > > hopes that someone will fix it, but we should be able to do better > > than that. People have told me many times in the past how it actually > > gets updated, but it never sticks in my memory). > > Once we switch to SVN, You mean switch to Mercurial? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84204 - in python/branches/py3k/Lib: os.py test/test_os.py
On Thu, 19 Aug 2010 19:10:19 +0200 (CEST) victor.stinner wrote: > Author: victor.stinner > Date: Thu Aug 19 19:10:18 2010 > New Revision: 84204 > > Log: > Fix os.get_exec_path() (code and tests) for python -bb > > Catch BytesWarning exceptions. You should not catch warnings, but silence them using constructs provided by the warnings module: with warnings.catch_warnings(): warnings.simplefilter(ignore, BytesWarning) # the rest of your code Otherwise you'll get buggy behaviour where e.g. env[b'PATH'] raises BytesWarning because of an unicode key, but it would have succeeded otherwise. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
2010/8/19 Georg Brandl : > Am 19.08.2010 15:32, schrieb Nick Coghlan: >> On Thu, Aug 19, 2010 at 9:55 PM, Éric Araujo wrote: >>> Thanks for the replies. >>> >>> The dev FAQ is clear about regular use, it tells about the >>> svnmerge-commit-message too, and people in #python-dev have told me that >>> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I >>> committed r84190 in 3.1 manually, but it should have been an svnmerge of >>> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1? >> >> Better to do "svnmerge merge --record-only -r84187". >> >> (I have another request for the dev FAQ - could we get an FAQ entry >> about how to update the FAQ itself? I usually just post here in the >> hopes that someone will fix it, but we should be able to do better >> than that. People have told me many times in the past how it actually >> gets updated, but it never sticks in my memory). > > Once we switch to SVN Oh, good. I was really starting to hate CVS. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in randint when importing pylab?
On Thu, Aug 19, 2010 at 7:11 AM, Timothy Kinney wrote: > I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box. > > If I run the following: > > [code] > from pylab import randint > > for s in range(100): > print randint(0,1) > [/code] > > I get 100 zeroes. > > If I import randint from random instead, I get the expected behavior > of a random distribution of 1s and 0s. > > I found this by importing * from pylab after importing randint from random. > > What is going on? Is pylab's randint function broken somehow? Could > this be due to installing scipy into a 2.6 environment when it was > designed for the 2.5 environment? No; this is by design. The docstring for pylab's randint says: randint(low, high=None, size=None) Return random integers from `low` (inclusive) to `high` (exclusive). IOW, it's similar to random.randrange in the stdlib. In contrast, random.randint *includes* both endpoints. It's perhaps unfortunate that random.randint and pylab.randint use different conventions, but it's not a bug. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84209 - python/branches/py3k/Python/ast.c
Le jeudi 19 août 2010 19:43:15, amaury.forgeotdarc a écrit : > Author: amaury.forgeotdarc > Date: Thu Aug 19 19:43:15 2010 > New Revision: 84209 > > Log: > Check the return values for all functions returning an ast node. > Failure to do it may result in strange error messages or even crashes, > in admittedly convoluted cases that are normally syntax errors, like: > def f(*xx, __debug__): pass Would it be possible to write tests for this change? -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
> (I have another request for the dev FAQ - could we get an FAQ entry > about how to update the FAQ itself? I usually just post here in the > hopes that someone will fix it, but we should be able to do better > than that. People have told me many times in the past how it actually > gets updated, but it never sticks in my memory). If you really *want* to update the FAQ yourself, I recommend you do a pydotorg checkout _now_. Ever since I did, I never forgot how to get it - simply because I just kept the sandbox. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
> I do it every time myself, AFAIK it reduces the workload of people > that are making sure all pending patches were applied. Do we really have any such people still? I thought they have all given up long ago. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst
Thanks Eric for the reply and Nick for mentioning --record-only, this was what I needed. Tarek: I find the bug tracker simpler than svnmerge to keep track of merges to be done. Of course, when there is no report, as for the typo fixes I made, this doesn’t help. Oh well. I’m going to do some Mercurial merges to feel better. In case the PSU wants me to svnmerge block/record the few changes I committed without using svnmerge afterward, tell them I won’t be far. Regards, and thanks for helpi ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
