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
-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
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
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
[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
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
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
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
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
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
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
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
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
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,
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?)
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
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
17 matches
Mail list logo
