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> 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
Ron Adam wrote:
> The following inconsistency still bothers me, but I suppose it's an edge
> case that doesn't cause problems.
>
> >>> print r"hello world\"
>File "", line 1
> print r"hello world\"
> ^
> SyntaxError: EOL while scanning single-quoted string
> In
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 r"hello world\"
>>File "", line 1
>> print r"hello world\"
>> ^
>> SyntaxError: EOL while scanning
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 r"hello world\"
>>>File "", line 1
>>> print r"hello world\"
>>> ^
>>> Sy
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.
-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
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 in
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 a
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 over
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 test.test_support.MAX_
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 real
-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 oth
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 t
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 mo
> 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
22 matches
Mail list logo
