Georg Brandl wrote:
FWIW, I'm -1 on both proposals too. I like implicit string literal
concatenation
and I really can't see what we gain from backslash continuation removal.
Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end with
Raymond I find that style hard to maintain. What is the advantage over
Raymond multi-line strings?
Raymond rows = self.executesql('''
Raymond select cities.city, state, country
Raymond from cities, venues, events, addresses
Raymond where cities.city like %s
[EMAIL PROTECTED] wrote:
when I hit LF in an open
multiline string a newline is inserted and the cursor is lined up under the
r of rows, not under the opening quote of the multiline string, and not
where you chose to indent your example.
Seems to me that Python actually benefits from an
Raymond Hettinger wrote:
Raymond I find that style hard to maintain. What is the advantage over
Raymond multi-line strings?
Raymond rows = self.executesql('''
Raymond select cities.city, state, country
Raymond from cities, venues, events, addresses
Raymond
Raymond Another way to look at it is to ask whether we would consider
Raymond adding implicit string concatenation if we didn't already have
Raymond it.
As I recall it was a relatively recent addition. Maybe 2.0 or 2.1? It
certainly hasn't been there from the beginning.
Skip
On Wed, May 02, 2007 at 10:23:39PM -0700, Raymond Hettinger wrote:
Another way to look at it is to ask whether we would consider
adding implicit string concatenation if we didn't already have it.
I think there would be a chorus of emails against it
Personally, I would have been irritated if
skip == skip [EMAIL PROTECTED] writes:
Raymond Another way to look at it is to ask whether we would consider
Raymond adding implicit string concatenation if we didn't already have
Raymond it.
skip As I recall it was a relatively recent addition. Maybe 2.0 or
skip 2.1? It
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning single-quoted string
In the first
Benji York wrote:
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning single-quoted
Ron Adam schrieb:
Benji York wrote:
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning
Barry Warsaw writes:
The problem is that
_(some string
and more of it)
is not the same as
_(some string +
and more of it)
Are you worried about translators? The gettext functions themselves
will just see the result of the operation. The extraction
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 3, 2007, at 10:40 AM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
The problem is that
_(some string
and more of it)
is not the same as
_(some string +
and more of it)
Are you worried about
Hello there.
I'm working on getting the 64 bit build of the trunk pass the testsuite.
Here is one snag, that you could help me fix.
In test_getargs2(), there is at line 190: self.failUnlessEqual(99,
getargs_n(Long()))
Now, the Long class has a __int__ method which returns 99L.
However, we run
Barry Warsaw writes:
IMO, this is a problem. We can make the Python extraction tool work,
but we should still be very careful about breaking 3rd party tools
like xgettext, since other projects may be using such tools.
But
_(some string +
and more of it)
is already
Hello again.
A lot of overflow tests fail in the testsuite, by expecting overflow using
sys.maxint.
for example this line, 196, in test_index.py:
self.assertEqual(x[self.neg:self.pos], (-1, maxint))
At the moment, I am disabling these tests with
if 64 bit not in sys.version:
So, two questions:
On Thursday 03 May 2007 15:40, Stephen J. Turnbull wrote:
Teaching Python-based extraction tools about it isn't hard, just make
sure that you slurp in the whole argument, and eval it.
We generate our component documentation based on going through the AST
generated by compiler.ast, finding doc
Kristján Valur Jónsson schrieb:
Hello again.
A lot of overflow tests fail in the testsuite, by expecting overflow using
sys.maxint.
for example this line, 196, in test_index.py:
self.assertEqual(x[self.neg:self.pos], (-1, maxint))
On my (virtual) win64-machine, which has less than 1GB,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Thomas Heller
Sent: Thursday, May 03, 2007 17:04
To: python-dev@python.org
Subject: Re: [Python-Dev] x64 and the testsuite
Kristján Valur Jónsson schrieb:
Hello again.
A lot of overflow tests
Kristján Valur Jónsson wrote:
Hello again.
A lot of overflow tests fail in the testsuite, by expecting overflow using
sys.maxint.
for example this line, 196, in test_index.py:
self.assertEqual(x[self.neg:self.pos], (-1, maxint))
Those tests should be fixed to use
Michael Sparks writes:
We generate our component documentation based on going through the AST
generated by compiler.ast, finding doc strings (and other strings in
other known/expected locations), and then formatting using docutils.
Are you talking about I18N and gettext? If so, I'm really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 3, 2007, at 12:41 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
IMO, this is a problem. We can make the Python extraction tool work,
but we should still be very careful about breaking 3rd party tools
like xgettext, since other
On 5/3/07, Georg Brandl [EMAIL PROTECTED] wrote:
These are raw strings if you didn't notice.
It's all in the implementation. The tokenizer takes it as an escape sequence
-- it doesn't specialcase raw strings -- the AST builder (parsestr() in ast.c)
doesn't.
FWIW, it wasn't designed this way
Well, I have checked in the fixes to the trunk to make an x64 build run the
testsuite.
It works pretty well. I did a quick test and found the x64Release to run 51000
pystones vs. 44000 for the win32Release version, a difference of some 10%.
And the x64PGO version ran some 61000 pystones.
Some
If that is the case, I have two suggestions:
a) Propagate the Windows idiom of sizeof(size_t) != sizeof(long) by keeping
some sys.maxsize for list length, indices, etc.
b) Elevate int to 64 bits on windows too!
B is probably a huge change. Not only change PyIntObject but probably create
Some more extensive testing is of course required, but it would seem
that gains can be had from both going 64 bit and using PGO. I
encourage you to take a look at the PGO build process. It is much
simpler than before. I also think we ought to find out if we could
start producing a proper vc8
25 matches
Mail list logo
