Re: [Python-Dev] Two spaces or one?
Talin schrieb: In PEP 9 there's a requirement that PEPs must follow the emacs convention of 2 spaces after a period. (I didn't know this was an emacs convention, I thought it was a convention of people who used typewriters.) It's an Emacs convention in the sense that its auto-filling function expects that; it will not break lines after a period which is followed by a single space only. (These are the default settings, this being Emacs you can customize it.) 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 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] Two spaces or one?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 23, 2007, at 10:18 PM, Talin wrote: In PEP 9 there's a requirement that PEPs must follow the emacs convention of 2 spaces after a period. (I didn't know this was an emacs convention, I thought it was a convention of people who used typewriters.) [...] So if we're not going to enforce the rule consistently (and it seems as if we're not), can we then just remove it from PEP 9? I'm not saying that we should change the rule to one space, I'm suggesting that we just drop the requirement and let people use whatever they prefer. As an emacs dinosaur, I'd prefer to keep the recommendation, but I also acknowledge that the smaller mammals nipping at my heals will eventually take over the world. I've recently had similar discussions in another community and I was actually kind of amazed to learn that auto-refilling of paragraphs itself was somewhat of an anachronism. Emacs will probably go the way of the vinyl record (though the latter is seeing a resurgence lately :). Changing must to should in PEP 9 would encourage but not enforce consistency, and I think that would be fine. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqXs7nEjvBPtnXfVAQLZWAP/UGGslCnGukFXJOvXoOyQE34baFAxKEyY NmXmZnpGfnhNOgASG1zxpAzPd6PtHQUMzwk0FXwlHVHpwg9Lb+IxFGZlRAgY2Tya KspvunDYlRFGAlG13Zg+GsQZI6cOOLqjKqwPsAcNXe9NIQhTA8hJ6vYcGSbE/I3q 73INGJg5uU4= =keXE -END PGP SIGNATURE- ___ 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] Two spaces or one?
I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, whether invoked explicitly via M-q or implicitly via auto-wrap mode, distinguishes the usage of periods based on the number of spaces following them. Two or more spaces are used to separate sentences. One space (for example, G. D. Montanaro) following a period is considered a non-breakable space. 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] Two spaces or one?
On Tue, Jul 24, 2007, [EMAIL PROTECTED] wrote: I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, whether invoked explicitly via M-q or implicitly via auto-wrap mode, distinguishes the usage of periods based on the number of spaces following them. Two or more spaces are used to separate sentences. One space (for example, G. D. Montanaro) following a period is considered a non-breakable space. There's no need to invoke Emacs to argue for the superiority of two spaces after each sentence, according to this vi user. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. ___ 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] Two spaces or one?
[EMAIL PROTECTED] wrote: I'm with Barry. I still use Emacs. Emacs's paragraph filling algorithm, whether invoked explicitly via M-q or implicitly via auto-wrap mode, distinguishes the usage of periods based on the number of spaces following them. Two or more spaces are used to separate sentences. One space (for example, G. D. Montanaro) following a period is considered a non-breakable space. How very twentieth-century :-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ 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] -z, -i and -m, maybe bug in runpy?
Nick Coghlan wrote: Phillip J. Eby wrote: While trying to get my -z replacement patch to work, I stumbled across a bug in the -m implementation (and in runpy). It seems that when you run the code of a -m module, it is *not* run in the __main__ module namespace! So even though __name__=='__main__', globals() is not sys.modules['__main__'].__dict__. This seems wrong to me. Does anybody know why runpy doesn't actually run the code in the target module? After implementing the runpy explicit relative import tests over the last couple of days, it actually occurred to me earlier today that I didn't have a test for this scenario. When I thought of the test, I was also pretty sure it would fail - it appears I was right :) OK, I've now had a closer look, and the problem isn't what I initially thought when I read your message (the test which I expected to fail actually passed without changing the current implementation). It turns out that while the module is actually executing it does the right thing - the problem only arises when the run_module function attempts to clean up after itself by reverting some of the changes it makes to the sys module. The specific problem is this sentence from the run_module docs: Both sys.argv[0] and sys.modules[__name__] are restored to their original values before the function returns. It looks like those semantics are a mistake - the changes to the sys module should persist after the function terminates, leaving it to the calling code to decide whether or not it wants to restore the original state. One consequence of this is that the -i option is much less useful when you use -m, because the script's globals have disappeared before you get to the interpreter prompt. See above - the problem is that the function is cleaning up after itself and deleting things that may still be of interest when -i is also specified. At this point, I've successfully gotten a -z replacement patch, except that it inherits this apparent bug from -m, which for a while led me to believe my patch was broken (when in fact it works fine, apart from inheriting the -m behavior). Does anybody know if this behavior is intended, and if so, why? And what are the consequences of changing/fixing it? It was intended enough to be documented that way, but I don't recall putting any significant thought into that aspect of the implementation, and nor do I remember anyone else questioning it. The fact that it completely breaks the -i switch seems more than enough reason to consider it a bug, though. I've changed the behaviour in r56520 to simply leave the alterations to sys in place when the function terminates. While this is a definite change to the interface (and hence not a candidate for direct backporting), I think the difference is small enough for the 2.5 to 2.6 transition. If enough people prefer, I can switch the code to an approach which fixes -m while leaving the semantics of runpy.run_module alone. This would involve renaming the version of run_module I just checked into SVN have -m invoke that version directly. run_module would be changed to wrap the function used by -m in the necessary code to restore the sys module to something more closely resembling its original state. That would also be the approach to take if we decided we wanted to backport this fix to the 2.5 maintenance branch. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Calling back into python from C
I realise I'm going to get slapped for asking a userish question here - sorry in advance. I'm looking for an explanation for why things are the way they are, the doco and py source aren't providing the missing info, and it looks like I'm bumping into an old Python bug (fixed in r38830 by mwh on 2005-04-18). I'm working on an C extension that needs to call back into python. Generally the GIL has been released when I need to do the callback, but I can't be sure. So I need to save the GIL state, get the lock, then restore it at the end. As far as I can tell from the doco, the recommended way to do this is to use PyGILState_Ensure() and PyGILState_Release(), but prior to r38830, PyGILState_Release incorrectly used PyEval_ReleaseThread when it should have been using PyEval_SaveThread() (I think), and the result is SEGV. This poses a problem, as I need to support Python versions back to 2.3. Am I correct in using PyGILState_Ensure() and PyGILState_Release()? If so, how do I support back to Py 2.3? Copy the current fixed PyGILState_Release() into my code (ick)? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ 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] Failure on assorted buildbots - Address already in use
A lot of the buildbots are red at the moment, which makes it harder to tell if a checkin broke anything new on other platforms. I've checked in a change to test_resource that should hopefully make some of the Debian buildbots happier, but several of the other buildbots are reporting a variety of Address already in use errors in the subthreads created by test_urllib2. Anyone have any ideas? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Py3k: error byte-compiling with distutils
I'm porting some of my code to py3k, and I started from the C size. After this, all extensions compiled fine, but after a 'setup.py install', I got the following: File /usr/local/python/3.0/lib/python3.0/distutils/util.py, line 498, in byte_compile compile(file, cfile, dfile) File /usr/local/python/3.0/lib/python3.0/py_compile.py, line 127, in compile py_exc = PyCompileError(err.__class__,err.args,dfile or file) File /usr/local/python/3.0/lib/python3.0/py_compile.py, line 48, in __init__ tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value)) File /usr/local/python/3.0/lib/python3.0/traceback.py, line 196, in format_exception_only lines.append(%s: %s\n % (stype, str(msg))) UnboundLocalError: local variable 'msg' referenced before assignment At this point, I had not updated my python code, so it surelly had some py3k-invalid things. Looking at 'traceback.py', it seems there is something wrong in 'format_exception_only', so this error. -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] Two spaces or one?
Emacs will probably go the way of the vinyl record (though the latter is seeing a resurgence lately :). Doubt it. Even as we speak, there's probably a student planning to implement Python 3 in ELisp as a SOC project... Bill ___ 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] Py3k: error byte-compiling with distutils
On 7/24/07, Lisandro Dalcin [EMAIL PROTECTED] wrote: I'm porting some of my code to py3k, and I started from the C size. After this, all extensions compiled fine, but after a 'setup.py install', I got the following: File /usr/local/python/3.0/lib/python3.0/distutils/util.py, line 498, in byte_compile compile(file, cfile, dfile) File /usr/local/python/3.0/lib/python3.0/py_compile.py, line 127, in compile py_exc = PyCompileError(err.__class__,err.args,dfile or file) File /usr/local/python/3.0/lib/python3.0/py_compile.py, line 48, in __init__ tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value)) File /usr/local/python/3.0/lib/python3.0/traceback.py, line 196, in format_exception_only lines.append(%s: %s\n % (stype, str(msg))) UnboundLocalError: local variable 'msg' referenced before assignment At this point, I had not updated my python code, so it surelly had some py3k-invalid things. Looking at 'traceback.py', it seems there is something wrong in 'format_exception_only', so this error. Try again -- I think this bug was introduced a few days ago. Kurt Kaiser promised to roll it bck, but it hasn't happened yet it seems. -- --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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/24/07, David Gowers [EMAIL PROTECTED] wrote:
On 7/24/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.
Instead of requiring a -z flag, why not have the interpreter peak at
the file to see if it starts with one of the ZIP magic numbers?
That way it Just Works.
I guess you wouldn't recognize a zip file if it hits you in the face.
Literally. :-)
Zip files don't start with a magic number.
ZIP files *do* start with a magic number; either PK\03\04 (non-empty
archive) or PK\05\06 (empty archive). This is rather easy to notice,
as I did in the bad old days of DOS, and i recently doubly verified it
('zip'+'khexedit', and
http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
infozip website too, but it seems to be down.)
You can believe that, but it's not the whole story. You can *prepend*
arbitrary data and the zip tools can still read the archive.
--
--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
Re: [Python-Dev] -z, -i and -m, maybe bug in runpy?
At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote: I've changed the behaviour in r56520 to simply leave the alterations to sys in place when the function terminates. While this is a definite change to the interface (and hence not a candidate for direct backporting), I think the difference is small enough for the 2.5 to 2.6 transition. Your fix is a definite improvement for me, my run any importable patch is looking a lot better. There's just one problem left, which is that runpy is overwriting sys.argv[0] even if it doesn't need to. So, when running from a zipfile, sys.argv[0] ends up None, which is wrong. However, if I ask runpy not to mess with sys, it creates a new module namespace to run the code in, bringing me right back to square one (i.e., not being run in __main__). Any thoughts? My fallback at this point would be to add an option to run_module() to request that sys.argv[0] be used in place of calling _get_filename(). It seems ugly to do that, though, if only because there are already so many arguments to that function. ___ 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] Py3k: 'range' fail
I did a fresh checkout as below (is p3yk the right branch?) $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k after building and installing, I get $ python3.0 Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type help, copyright, credits or license for more information. range(0,10,2) Traceback (most recent call last): File stdin, line 1, in module SystemError: NULL result without error in PyObject_Call -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] Py3k: 'range' fail
Yes, range() on the p3yk branch seems broken. However, this bug has been fixed in the py3k-struni, the branch where most the development for Python 3000 is taking place. -- Alexandre On 7/24/07, Lisandro Dalcin [EMAIL PROTECTED] wrote: I did a fresh checkout as below (is p3yk the right branch?) $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k after building and installing, I get $ python3.0 Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type help, copyright, credits or license for more information. range(0,10,2) Traceback (most recent call last): File stdin, line 1, in module SystemError: NULL result without error in PyObject_Call ___ 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] Py3k: error during 'make install' in py3k-struni ?
Yeah, that particular test is not yet working. (Fixes are welcome --
see http://wiki.python.org/moin/Py3kStrUniTests for how to help.)
I believe I rigged make install to continue after this error -- did
the rest of the install complete?
FWIW, a better place to discuss Py3k bleeding edge stuff is
[EMAIL PROTECTED] Sign up at the usual place. (I've CC'ed that
list now -- please remove python-dev from followups.)
--Guido
On 7/24/07, Lisandro Dalcin [EMAIL PROTECTED] wrote:
Afther checking out the py3k-struni branch, 'make install' issued this:
Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
*** SyntaxError: ('expected string, bytes found',
('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
None))
If this is expected to fail, please forget this.
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
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
Re: [Python-Dev] Two spaces or one?
Bill Janssen wrote: Someone wrote: Emacs will probably go the way of the vinyl record (though the latter is seeing a resurgence lately :). Doubt it. Even as we speak, there's probably a student planning to implement Python 3 in ELisp as a SOC project... And run it on a computer built out of valves. (You get much better sound out of your MP3s on a valve computer, you know...:-) -- Greg ___ 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
