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 sup
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 s
With parentheses, we can use "if cond then val1 else val2" form
without the burden of hacking the parser, although the cost of the
keyword "then" is still there.
so, some possible forms that prompts in my mind are
level = (if "absolute_import" in self.future then 0 else -1)
level = (if "ab
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
> But I think the problem can be simplified by f
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/pe
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:
http://mail.
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 (se
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 o
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 to
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
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,
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
[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 m
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
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*
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 c
* 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.
FWIW, this practice is very handy for unit tes
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 m
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
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 yet to be Py_ssize_t'ed. Do
Do comp
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
___
Py
[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 ;-)
[Th
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
[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 gener
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 c
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
>>
[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 re
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
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"
> s
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. C
[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
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: ct
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: http://www.p
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 built
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
Python-De
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
[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 o
41 matches
Mail list logo
