Re: [Python-Dev] Survey on DVCS usage and experience
On 28-May-09, at 9:35 PM, Senthil Kumaran wrote: On Wed, May 27, 2009 at 06:02:57PM -0600, Brian de Alwis wrote: With Python having recently chosen to switch to Mercurial, I hoped that any developers who've used a DVCS (and who are over 18 years old) might like to participate in our survey and share your Just curious. Why is this age restriction? You might miss out few key developers... It's a restriction required to obtain approval from our research ethics board -- people under 18 are considered to be minors in Canada and thus require the consent of their guardian to participate. Trying to obtain such permission for an anonymous survey is a bit difficult! Although we could work around this guardian-consent issue in theory, doing so would require jumping through several additional hoops in the ethics process and would take significantly more time. Brian. ___ 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] Possibility of binary configuration mismatch
2009/5/29 David Abrahams : > http://allmydata.org/trac/tahoe/ticket/704#comment:7 describes a > situation where my macports-installed python25 had a pyOpenSSL egg > installed in it by something other than macports (possibly by > easy_install-2.5?) that was not compatible with the Python build. My > hunch is that the pyOpenSSL had binaries compiled against a UCS4 Python, > but I don't know for sure. Whatever did the installation of the bad egg > was almost certainly being executed by the macports python25 because > macports is installed in /opt/local, and nothing is likely to have > installed it under that prefix by chance. In other words, this egg > probably couldn't have been left over from some non-macports python > installation. In fact, I haven't had any other version of Python2.5 > installed on this machine. Very odd. > > I wonder if it makes sense to enhance the extension module system to > record this kind of information so the problem can be diagnosed by the > system? I have a feeling that this has been discussed before, in the context of easy_install/setuptools' approach to encoding the build details for a binary package in the filename, not covering UCS4 vs UCS2. You may find it useful to search on the distutils-sig archives for further information. Paul. ___ 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] Survey on DVCS usage and experience
Brian de Alwis usask.ca> writes: > > It's a restriction required to obtain approval from our research > ethics board -- people under 18 are considered to be minors in Canada > and thus require the consent of their guardian to participate. Trying > to obtain such permission for an anonymous survey is a bit difficult! But since your survey is anonymous, you can't be sure all the responders are over 18. Actually, they might even not be human beings! (hint: I'm not) Regards Antoine. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (05/22/09 - 05/29/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2201 open (+36) / 15764 closed (+18) / 17965 total (+54) Open issues with patches: 866 Average duration of open issues: 652 days. Median duration of open issues: 400 days. Open Issues Breakdown open 2175 (+36) pending26 ( +0) Issues Created Or Reopened (55) ___ improved allocation of PyUnicode objects 05/24/09 http://bugs.python.org/issue1943reopened pitrou patch str.format raises SystemError05/22/09 CLOSED http://bugs.python.org/issue6089created eggy zipfile DeprecationWarning Python 2.6.2 05/22/09 http://bugs.python.org/issue6090created ivb Curses segfaulting in FreeBSD/amd64 05/23/09 http://bugs.python.org/issue6091created themoken Changed Shortcuts don't show up in menu 05/23/09 http://bugs.python.org/issue6092created jamesie Ambiguous locale.strxfrm 05/23/09 CLOSED http://bugs.python.org/issue6093created tuves Python fails to build with Subversion 1.705/23/09 CLOSED http://bugs.python.org/issue6094created Arfrever patch os.curdir as the default argument for os.listdir 05/23/09 http://bugs.python.org/issue6095created tarek SimpleXMLRPCServer not suitable for HTTP/1.1 keep-alive 05/24/09 http://bugs.python.org/issue6096created krisvale patch, patch, easy, needs review Encoded surrogate characters on command line not escaped in sys. 05/24/09 http://bugs.python.org/issue6097created baikie patch xml.dom.minidom incorrectly claims DOM Level 3 conformance 05/24/09 http://bugs.python.org/issue6098created phihag patch HTTP/1.1 with keep-alive support for xmlrpclib.ServerProxy 05/24/09 http://bugs.python.org/issue6099created krisvale patch, patch, needs review Expanding arrays inside other arrays 05/24/09 http://bugs.python.org/issue6100created marek_sp SETUP_WITH 05/24/09 CLOSED http://bugs.python.org/issue6101created benjamin.peterson patch When the package has non-ascii path and .pyc file, we cannot imp 05/25/09 http://bugs.python.org/issue6102created Suzumizaki Static library (libpythonX.Y.a) installed in incorrect location 05/25/09 http://bugs.python.org/issue6103created Arfrever patch OSX framework builds fail after r72861 move of _locale into core 05/25/09 CLOSED http://bugs.python.org/issue6104created nad json.dumps doesn't respect OrderedDict's iteration order 05/25/09 http://bugs.python.org/issue6105created wangchun read_until 05/25/09 http://bugs.python.org/issue6106created ps
[Python-Dev] Indentation oddness...
Consider the code:
code = "def Foo():\n\npass\n\n "
This code is malformed in that the final indentation (2 spaces) does not agree
with the previous indentation of the pass statement (4 spaces). Or maybe it's
just fine if you take the blank lines should be ignored statement from the docs
to be true. So let's look at different ways I can consume this code.
If I use compile to compile this:
compile(code, 'foo', 'single')
I get an IndentationError: unindent does not match any outer indentation level
But if I put this in a file:
f= file('indenttest.py', 'w')
f.write(code)
f.close()
import indenttest
It imports just fine.
If I run it through the tokenize module it also tokenizes just fine:
>>> import tokenize
>>> from cStringIO import StringIO
>>> tokenize.tokenize(StringIO(code).readline)
1,0-1,3:NAME'def'
1,5-1,8:NAME'Foo'
1,8-1,9:OP '('
1,9-1,10: OP ')'
1,10-1,11: OP ':'
1,11-1,12: NEWLINE '\n'
2,0-2,1:NL '\n'
3,0-3,4:INDENT ''
3,4-3,8:NAME'pass'
3,8-3,9:NEWLINE '\n'
4,0-4,1:NL '\n'
5,0-5,0:DEDENT ''
5,0-5,0:ENDMARKER ''
And if it fails anywhere it would seem tokenization is where it should fail -
especially given that tokenize.py seems to report this error on other occasions.
And stranger still if I add a new line then it will even compile fine:
compile(code + '\n', 'foo', 'single')
Which seems strange because in either case all of the trailing lines are blank
lines and as such should basically be ignored according to the documentation.
Is there some strange reason why compile rejects what everything else agrees is
perfectly valid code?
___
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] Indentation oddness...
Consider the code:
code = "def Foo():\n\npass\n\n "
This code is malformed in that the final indentation (2 spaces) does not agree
with the previous indentation of the pass statement (4 spaces). Or maybe it's
just fine if you take the blank lines should be ignored statement from the docs
to be true. So let's look at different ways I can consume this code.
If I use compile to compile this:
compile(code, 'foo', 'single')
I get an IndentationError: unindent does not match any outer indentation level
But if I put this in a file:
f= file('indenttest.py', 'w')
f.write(code)
f.close()
import indenttest
It imports just fine.
If I run it through the tokenize module it also tokenizes just fine:
>>> import tokenize
>>> from cStringIO import StringIO
>>> tokenize.tokenize(StringIO(code).readline)
1,0-1,3:NAME'def'
1,5-1,8:NAME'Foo'
1,8-1,9:OP '('
1,9-1,10: OP ')'
1,10-1,11: OP ':'
1,11-1,12: NEWLINE '\n'
2,0-2,1:NL '\n'
3,0-3,4:INDENT ''
3,4-3,8:NAME'pass'
3,8-3,9:NEWLINE '\n'
4,0-4,1:NL '\n'
5,0-5,0:DEDENT ''
5,0-5,0:ENDMARKER ''
And if it fails anywhere it would seem tokenization is where it should fail -
especially given that tokenize.py seems to report this error on other occasions.
And stranger still if I add a new line then it will even compile fine:
compile(code + '\n', 'foo', 'single')
Which seems strange because in either case all of the trailing lines are blank
lines and as such should basically be ignored according to the documentation.
Is there some strange reason why compile rejects what everything else agrees is
perfectly valid code?
___
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] Indentation oddness...
On 2009-05-29 19:08, Dino Viehland wrote:
Consider the code:
code = "def Foo():\n\npass\n\n "
This code is malformed in that the final indentation (2 spaces) does not agree
with the previous indentation of the pass statement (4 spaces). Or maybe it's
just fine if you take the blank lines should be ignored statement from the docs
to be true. So let's look at different ways I can consume this code.
If I use compile to compile this:
compile(code, 'foo', 'single')
I get an IndentationError: unindent does not match any outer indentation level
But if I put this in a file:
f= file('indenttest.py', 'w')
f.write(code)
f.close()
import indenttest
It imports just fine.
The 'single' mode, which is used for the REPL, is a bit different than 'exec',
which is used for modules. This difference lets you insert "blank" lines of
whitespace into a function definition without exiting the definition. Ending
with a truly empty line does not cause the IndentationError, so the REPL can
successfully compile the code, signaling that the user has finished typing the
function.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
___
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] Indentation oddness...
> The 'single' mode, which is used for the REPL, is a bit different than > 'exec', > which is used for modules. This difference lets you insert "blank" > lines of > whitespace into a function definition without exiting the definition. > Ending > with a truly empty line does not cause the IndentationError, so the > REPL can > successfully compile the code, signaling that the user has finished > typing the > function. Sorry, I probably should have mentioned this but it repros w/ compile(..., "exec") as well: >>> code = "def Foo():\n\npass\n\n " >>> compile(code, 'foo', 'exec') Traceback (most recent call last): File "", line 1, in File "foo", line 5 IndentationError: unindent does not match any outer indentation level It also repros when passing in PyCF_DONT_IMPLY_DEDENT for flags under single and exec. ___ 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] Indentation oddness...
I usually append some extra newlines before passing a string to compile(). That's the usual work-around. There's probably a subtle bug in the tokenizer when reading from a string -- if you find it, please upload a patch to the tracker! --Guido On Fri, May 29, 2009 at 5:52 PM, Dino Viehland wrote: >> The 'single' mode, which is used for the REPL, is a bit different than >> 'exec', >> which is used for modules. This difference lets you insert "blank" >> lines of >> whitespace into a function definition without exiting the definition. >> Ending >> with a truly empty line does not cause the IndentationError, so the >> REPL can >> successfully compile the code, signaling that the user has finished >> typing the >> function. > > Sorry, I probably should have mentioned this but it repros w/ > compile(..., "exec") as well: > code = "def Foo():\n\n pass\n\n " compile(code, 'foo', 'exec') > Traceback (most recent call last): > File "", line 1, in > File "foo", line 5 > > IndentationError: unindent does not match any outer indentation level > > It also repros when passing in PyCF_DONT_IMPLY_DEDENT for flags under > single and exec. > ___ > 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/guido%40python.org > -- --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
