Re: [Python-Dev] [Python-3000] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
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> where cities.city like %s
>>Raymond> and events.active = 1
>>Raymond> and venues.address = addresses.id
>>Raymond> and addresses.city = cities.id
>>Raymond> and events.venue = venues.id
>>Raymond> ''',
>>Raymond> (city,))
>
> [Skip]
>> Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
>> that caused me to start doing things this way (I've been doing my embedded
>> SQL statements this way for several years now), but 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. When I use individual strings the
>> parameters line up where I want them to (the way I lined things up in my
>> example). At any rate, it's what I'm used to now.
>
>
> I completely understand. Almost any simplification or feature elimination
> proposal is going to bump-up against, "what we're used to now".
> Py3k may be our last chance to simplify the language. We have so many
> special little rules that even advanced users can't keep them
> all in their head. Certainly, every feature has someone who uses it.
> But, there is some value to reducing the number of rules, especially
> if those rules are non-essential (i.e. implicit string concatenation has
> simple, clear alternatives with multi-line strings or with the plus-operator).
>
> 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 -- arguing
> against language bloat and noting that we already have triple-quoted
> strings, raw-strings, a verbose flag for regexs, backslashes inside multiline
> strings, the explicit plus-operator, and multi-line expressions delimited
> by parentheses or brackets. Collectively, that is A LOT of ways to do it.
>
> I'm asking this group to give up a minor habit so that we can achieve
> at least a few simplifications on the way to Py3.0 -- basically, our last
> chance.
>
> Similar thoughts apply to the octal literal PEP. I'm -1 on introducing
> yet another way to write the literal (and a non-standard one at that).
> My proposal was simply to eliminate it. The use cases are few and
> far between (translating C headers and setting unix file permissions).
> In either case, writing int('0777', 8) suffices. In the latter case, we've
> already provided clear symbolic alternatives. This simplification of the
> language would be a freebie (impacting very little code, simplifying the
> lexer, eliminating a special rule, and eliminating a source of confusion
> for the young amoung us who do not know about such things).
My counter argument is that these simplifications aren't simplifying
much - that is, the removals don't cascade and cause other
simplifications. The grammar file, for example, won't look dramatically
different if these changes are made. The simplification argument seems
weak to me because the change in overall language complexity is very
small, whereas the inconvenience caused, while not huge, is at least
significant.
That being said, line continuation is the only one I really care about.
And I would happily give up backslashes in exchange for a more sane
method of continuing lines. Either way avoids "spurious" grouping
operators which IMHO don't make for easier-to-read code.
-- Talin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
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 it wasn't there. I'm used to it from other languages, and it would seem like a gratuitous incompatability if it wasn't supported. I'm definitely against this proposal in its entirety. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
> "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 certainly hasn't been there from the beginning. Misc/HISTORY suggests this feature was added in 1.0.2 (May 1994). Apologies for my bad memory. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 the first case, it's treated as a continuation character even though > it's not at the end of a physical line. So it gives an error. No, that is unrelated to line continuation. The \" is an escape sequence, therefore there is no double-quote to end the string literal. -- Benji York http://benjiyork.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 single-quoted string > >> In the first case, it's treated as a continuation character even though >> it's not at the end of a physical line. So it gives an error. > > No, that is unrelated to line continuation. The \" is an escape > sequence, therefore there is no double-quote to end the string literal. Are you sure? >>> print r'\"' \" It's just a '\' here. These are raw strings if you didn't notice. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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\" >>> ^ >>> SyntaxError: EOL while scanning single-quoted string >> >>> In the first case, it's treated as a continuation character even though >>> it's not at the end of a physical line. So it gives an error. >> >> No, that is unrelated to line continuation. The \" is an escape >> sequence, therefore there is no double-quote to end the string literal. > > Are you sure? > > > >>> print r'\"' > \" > > It's just a '\' here. > > 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. 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
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 tools like
xgettext do fail, however. Translating the above to
# The problem is that
gettext("some string"
" and more of it")
# is not the same as
gettext("some string" +
" and more of it")
and invoking "xgettext --force-po --language=Python test.py" gives
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <[EMAIL PROTECTED]>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-05-03 23:32+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n"
"Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"
#: test.py:3
msgid "some string and more of it"
msgstr ""
#: test.py:8
msgid "some string"
msgstr ""
BTW, it doesn't work for the C equivalent, either.
> You would either have to teach pygettext and maybe gettext about
> this construct, or you'd have to use something different.
Teaching Python-based extraction tools about it isn't hard, just make
sure that you slurp in the whole argument, and eval it. If what you
get isn't a string, throw an exception. xgettext will be harder,
since apparently does not do it, nor does it even know enough to error
or warn on syntax it doesn't handle within gettext()'s argument.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
-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 translators? The gettext functions themselves
> will just see the result of the operation. The extraction tools like
> xgettext do fail, however.
Yep, sorry, it is the extraction tools I'm worried about.
> Teaching Python-based extraction tools about it isn't hard, just make
> sure that you slurp in the whole argument, and eval it. If what you
> get isn't a string, throw an exception. xgettext will be harder,
> since apparently does not do it, nor does it even know enough to error
> or warn on syntax it doesn't handle within gettext()'s argument.
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.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjoBI3EjvBPtnXfVAQLg0AP/Y1ncqie1NgzRFzuZpnZapMs/+oo+5BCK
1MYqsJwucnDJnOqrUcU34Vq3SB7X7VsSDv3TuoTNnheinX6senorIFQKRAj4abKT
f2Y63t6BT97mSOAITFZvVSj0YSG+zkD/HMGeDj4dOJFLj1tYxgKpVprlhMbELzG1
AIKe+wsYjcs=
=+oFV
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyInt_AsSsize_t on x64
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 into trouble here:
intobject.c:210
if ((nb = op->ob_type->tp_as_number) == NULL ||
(nb->nb_int == NULL && nb->nb_long == 0)) {
PyErr_SetString(PyExc_TypeError, "an integer is required");
return -1;
}
if (nb->nb_long != 0) {
io = (PyIntObject*) (*nb->nb_long) (op);
} else {
io = (PyIntObject*) (*nb->nb_int) (op);
}
trouble here
The trouble is that nb->nb_long is non zero, but when called, it returns an
attribute error, since __long__ is missing.
nb_long points to instance_long.
Now, how to fix this? Should the code in intobject.c catch the AttributeError,
maybe, and continue to the nb_int?
Cheers,
Kristján
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
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 legal Python, and xgettext is already broken for it.
Arguably, xgettext's implementation of -L Python should be
execve ("pygettext", argv, environ);
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] x64 and the testsuite
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: Should we add something like sys.maxsize to keep these overflow tests valid? Also, some tests just kill the computer when given large values, that are expected to overflow. Sometimes it would be good to test for a 64 bit machine with virtually infinite ram. Is there a better way than the "64 bit" in sys.version test? Should we have something like sys.bits? Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
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 strings (and other strings in other known/expected locations), and then formatting using docutils. Eval'ing the file isn't always going to work due to imports relying on libraries that may need to be installed. (This is especially the case with Kamaelia because we tend to wrap libraries for usage as components in a convenient way) We've also specifically moved away from importing the file or eval'ing things because of this issue. It makes it easier to have docs built on a random machine with not too much installed on it. You could special case "12345" + "67890" as a compile timeconstructor and jiggle things such that by the time it came out the parser that looked like "1234567890", but I don't see what that has to gain over the current form. (which doesn't look like an expression) I also think that's a rather nasty version. On the flip side if we're eval'ing an expression to get a docstring, there would be great temptation to extend that to be a doc-object - eg using dictionaries, etc as well for more specific docs. Is that wise? I don't know :) Michael. -- Kamaelia project lead http://kamaelia.sourceforge.net/Home ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x64 and the testsuite
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, quite some tests fail
with MemoryError.
The tests pass on 64-bit linux machines, though.
> At the moment, I am disabling these tests with
> if "64 bit" not in sys.version:
>
> So, two questions: Should we add something like sys.maxsize to keep these
> overflow tests valid?
>
> Also, some tests just kill the computer when given large values, that are
> expected to overflow. Sometimes
> it would be good to test for a 64 bit machine with virtually infinite ram.
> Is there a better way
> than the "64 bit" in sys.version test? Should we have something like
> sys.bits?
You can use 'struct.calcsize("P")' to find out the pointer size.
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x64 and the testsuite
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Thomas Heller > Sent: Thursday, May 03, 2007 17:04 > To: [email protected] > Subject: Re: [Python-Dev] x64 and the testsuite > > 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, quite some > tests fail with MemoryError. > The tests pass on 64-bit linux machines, though. I haven't got memory error yet. Many tests allocate some 4GB, and the OS happily enters paging mode. They then succeed eventually. As for linux, many of the range overflow tests rely on sys.maxint. Presumably, this is 1<<63 on those machines? 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 Py_int and so on. Ok, b) is not a real suggestion, then. > > than the "64 bit" in sys.version test? Should we have something like > sys.bits? > > You can use 'struct.calcsize("P")' to find out the pointer size. Hm, I could do that I suppose. maxsize = (1L<<(struct.calcsize("P")*8-1))-1 minsize = maxsize-1 And use those in the testsuite... K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x64 and the testsuite
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_Py_ssize_t instead of sys.maxint. Regards, Ziga ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
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 lost > You could special case "12345" + "67890" as a compile timeconstructor and > jiggle things such that by the time it came out the parser that looked like > "1234567890", but I don't see what that has to gain over the current form. I'm not arguing it's a gain, simply that it's a case that *should* be handled by extractors of translatable strings anyway, and if it were, there would not be an I18N issue in this PEP. It *should* be handled because this is just constant folding. Any half-witted compiler does it, and programmers expect their compilers to do it. pygettext and xgettext are (very special) compilers. I don't see why that expectation should be violated just because the constants in question are translatable strings. I recognize that for xgettext implementing that in C for languages as disparate as Lisp, Python, and Perl (all of which have string concatenation operators) is hard, and to the extent that xgettext is recommended by 9 out of 10 translators, we need to worry about how long it's going to take for xgettext to get fixed (because it *is* broken in this respect, at least for Python). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
-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 projects may be using such tools.
>
> But
>
> _("some string" +
> " and more of it")
>
> is already legal Python, and xgettext is already broken for it.
Yep, but the idiom that *gettext accepts is used far more often. If
that's outlawed then the tools /have/ to be taught the alternative.
> Arguably, xgettext's implementation of -L Python should be
>
> execve ("pygettext", argv, environ);
>
>
Ouch. :)
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjohUXEjvBPtnXfVAQLHhAQAmKNyjbPpIMIlz7zObvb09wdw7jyC2bBa
2w+rDilRgxicUXWqH/L6AeHHl3HiVOO+tELU6upTxOWBMlJG8xcY70rde/32I0gb
Wm0ylLlvDU/bAlSMyUscs77BVt82UQsBEqXyQ2+PRfQj7aOkpqgT8P3dwCYrtPaH
L4W4JzvoK1M=
=9pgu
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 so as to be easy to implement. It was designed this way because the overwhelming use case is regular expressions, where one needs to be able to escape single and double quotes -- the re module unescapes \" and \' when it encounters them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.6, x64 and PGO
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 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 build, setting up a buildbot, etc. I can probably convince management at CCP to arrange for one. We could also think about a way to have the 64 bit and 32 bit versions coexist on the same machine. Cheers, Kristjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x64 and the testsuite
> 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 Py_int and so on. > Ok, b) is not a real suggestion, then. Also, in Py3k, the int type will go away, along with this entire problem. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6, x64 and PGO
> 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 build, setting up a buildbot, etc. I > can probably convince management at CCP to arrange for one. When you are ready to operate a buildbot, just let me know. > We could also think about a way to have the 64 bit and 32 bit > versions coexist on the same machine. Please, no. This will complicate things very much for everybody, for the sake of a few elitist users who think they have a use case. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
