Patch / Bug Summary
___
Patches : 386 open ( +4) / 3089 closed (+10) / 3475 total (+14)
Bugs: 889 open ( +9) / 5636 closed (+12) / 6525 total (+21)
RFE : 212 open ( +1) / 201 closed ( +0) / 413 total ( +1)
New / Reopened Patches
__
db4.4
Morel Xavier wrote:
Steve Holden wrote:
Contrast with the bleeding obvious:
level = 0
if absolute_import in self.futures:
level = -1
regards
Steve
The issue that spawned the necessity of a ternary operator in the first
place was that this syntax is not usable at
On 3/9/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Steven Elliott wrote:
I'm interested in how builtins could be more efficient. I've read over
some of the PEPs having to do with making global variables more
efficient (search for global):
http://www.python.org/doc/essays/pepparade.html
Guido van Rossum wrote:
We seem to have a consensus. Is anybody working on a patch yet?
http://python.org/sf/1446372
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, 2006-03-09 at 12:00 +, Paul Moore wrote:
On 3/9/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Steven Elliott wrote:
I'm interested in how builtins could be more efficient. I've read over
some of the PEPs having to do with making global variables more
efficient (search for
At 08:50 AM 3/9/2006 -0600, Steven Elliott wrote:
I believe that currently mod.str = my_str alters the module's global
hash table (f-f_globals in the code). One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of
ctypes is in SVN now, and the buildbot is green, after I disabled a test that
dumped core
on sparc solaris. The crash was apparently caused
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and
the _ctypes_test.pyd
extension needed for testing. IIRC, Martin promised
Thomas Heller [EMAIL PROTECTED] wrote:
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension
and the _ctypes_test.pyd extension needed for testing. IIRC, Martin
promised to create them - is this offer still valid? I could do that
myself, but only for x86, while other .pyd
Giovanni Bajo wrote:
Thomas Heller [EMAIL PROTECTED] wrote:
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension
and the _ctypes_test.pyd extension needed for testing. IIRC, Martin
promised to create them - is this offer still valid? I could do that
myself, but only
Thomas Heller [EMAIL PROTECTED] wrote:
I discussed with Martin a bit about the opportunity of generating .vcproj
files with a script-driven tool. I'm going to try and setup something as
soon as I find some spare time.
Ideally this would be integrated with distutils because the setup-script
[Steven Elliott]
As you probably know each access of a builtin requires two hash table
lookups. First, the builtin is not found in the list of globals. It is
then found in the list of builtins.
If someone really cared about the double lookup, they could flatten a level by
starting their
Giovanni Bajo wrote:
Thomas Heller [EMAIL PROTECTED] wrote:
I discussed with Martin a bit about the opportunity of generating
.vcproj files with a script-driven tool. I'm going to try and
setup something as soon as I find some spare time.
Ideally this would be integrated with distutils
Thomas Heller [EMAIL PROTECTED] wrote:
Ideally this would be integrated with distutils because the
setup-script has most of the information that's needed.
OTOH, extensions could be built with distutils even for core
Python, and even on Windows. For extensions that are *not* builtin
or not
Steven Elliott [EMAIL PROTECTED] wrote:
I'm interested in how builtins could be more efficient. I've read over
some of the PEPs having to do with making global variables more
efficient (search for global):
http://www.python.org/doc/essays/pepparade.html
But I think the problem can be
* Paul Moore wrote:
If it *is* possible, I'd say it's worth implementing at least a
warning sooner rather than later - the practice seems questionable at
best, and any progress towards outlawing it would help in work on
optimising builtins.
/lurk
FWIW, this practice is very handy for unit
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
ctypes is in SVN now, and the buildbot is green,Well, only by accident; Neal's amd64 machine has been offline, or you would have seen yellow blocks for warnings: ctypes has yet to be Py_ssize_t'ed. Do you want to do that yourself, or do you want me
At 08:51 AM 3/9/2006 -0800, Raymond Hettinger wrote:
Perhaps what I'm suggesting isn't feasible for reasons that have already
been discussed. But it seems like it should be possible to make while
True as efficient as while 1.
That is going to be difficult as long as it is legal to write:
Phillip J. Eby wrote:
I think this is a reasonable implementation limit on dynamicity,
Absolutely.
although to be conservative I think we should only do this with -O in
Python 2.5, if we do it at all.
Or with a __future__ directive?
Just
___
[Tim Peters]
Added:
python/trunk/Tools/scripts/svneol.py (contents, props changed)
Log:
Simple utility to add svn:eol-style to text files under
SVN control. Like reindent.py, I expect to run this
mindlessly from time to time, checking in whatever it
happens to do ;-)
[Thomas Heller]
Tim Peters wrote:
[Tim Peters]
Added:
python/trunk/Tools/scripts/svneol.py (contents, props changed)
Log:
Simple utility to add svn:eol-style to text files under
SVN control. Like reindent.py, I expect to run this
mindlessly from time to time, checking in whatever it
happens to do
[Thomas Heller]
...
And I never had tried it before on a sparc machine - all the intel and ppc
processors
seem to have no problems with it.
Pentiums don't enforce natural alignment restrictions, but run much
slower on unaligned access (varying by specific chip model, and
generally more
[Thomas Heller]
...
I could do that myself, but only for x86, while other .pyd files also have
build
settings for Itanium and x86_64. (I find it always very painful to click
through
the settings dialog in MSVC - isn't there any other way to create these
files?)
Under VC 6 I generally
Tim Peters wrote:
[Thomas Heller]
...
And I never had tried it before on a sparc machine - all the intel and ppc
processors
seem to have no problems with it.
Pentiums don't enforce natural alignment restrictions, but run much
slower on unaligned access (varying by specific chip model,
Tim Peters wrote:
[Thomas Heller]
...
I could do that myself, but only for x86, while other .pyd files also have
build
settings for Itanium and x86_64. (I find it always very painful to click
through
the settings dialog in MSVC - isn't there any other way to create these
files?)
[Thomas Heller]
...
The Linux-head is the release manager, prepaing the release on
a unixish platform, in combination with the windows guy who downloads
the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem, then. Since
a
Tim Peters wrote:
[Thomas Heller]
...
The Linux-head is the release manager, prepaing the release on
a unixish platform, in combination with the windows guy who downloads
the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem,
Thomas Heller wrote:
ctypes is in SVN now, and the buildbot is green, after I disabled a test that
dumped core
on sparc solaris. The crash was apparently caused
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and
the _ctypes_test.pyd
extension needed for
Tim Peters wrote:
Should 'sln' and 'vcproj' be added to the extensions list? I think these are
text-files too. Although PCBuild\pcbuild.sln has a binary mime-type property,
so the script would not change that.
I don't know whether they're text files in the SVN eol-style native
sense.
Grant Olson wrote:
I’m finishing up a patch for bug 1441408. I had to change the asdl
definitions
which in turn caused a failure in test_ast.py. A comment in the file
indicates
that EVERYTHING BELOW IS GENERATED # and has a definition for Slice()
that is no longer valid. Can
[Martin v. Löwis]
Last I tried, VS 2003 would tolerate \n line endings in vcproj files
(these being plain XML files). I don't remember whether it would
tolerate them in .sln files (as these are *not* XML files); this is
why the .sln file is set to binary.
FYI, I tried changing pcbuild.sln to
Steven Elliott wrote:
One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of the default builtins. If it is,
then the module's indexed array of builtins is assigned to.
As long as you're going to all that
Raymond Hettinger wrote:
That is going to be difficult as long as it is legal to write:
True = 0
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
Greg
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
Thomas Wouters wrote: On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote: ctypes is in SVN now, and the buildbot is green, Well, only by accident; Neal's amd64 machine has been offline, or you would
have seen yellow blocks for warnings: ctypes has
On 3/9/06, Greg Ewing [EMAIL PROTECTED] wrote:
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
I don't think we should make any of these keywords.
--
--Guido van Rossum (home page:
At 12:46 PM 3/10/2006 +1300, Greg Ewing wrote:
Steven Elliott wrote:
One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of the default builtins. If it is,
then the module's indexed array of builtins is
Compiling...
unicodedata.c
\Code\python\Modules\unicodedata.c(74) : error C2133:
'unicodedata_functions' : unknown size
It's griping about this:
/* Forward declaration */
static PyMethodDef unicodedata_functions[];
___
Python-Dev mailing list
Thomas Wouters wrote:
(about ctypes and Py_ssize_t)
you want to do that yourself, or do you want me to submit a patch? (Or I
could just check it in ;)
You can do it faster then me, I assume - so go ahead and check it in.
I'll backport it to the upstream ctypes CVS repository.
I'm not sure
[CC to python-dev again]
Hye-Shik Chang wrote:
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
I've now committed ctypes 0.9.9.4 into SVN. It seems to build, at least
on the buildbots
that are online.
Good work!
38 matches
Mail list logo
