We can't backport the __prepare__ syntax without requiring metaclass
definition on the 'class' line. Because the __metaclass__ definition
can be at the end of the class in 2.6 we can't find it until after we
execute the class and that is too late to use a custom dictionary.
I wish I had thought o
Neal Norwitz wrote:
> [changing to: and subject: ]
>
> On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
> > <[EMAIL PROTECTED]> wrote:
> > > Get this test to pass (UserList/UserDict no longer exist and caused a
> > s
On Tue, Mar 18, 2008 at 10:07 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Now that we're aggressively adding Py3k warnings to the trunk, I think it's
> a good time to get this straightened out. The docs [1] say PyErr_Warn is
> deprecated in favor of PyErr_WarnEx. However, I have seen both in
I've been double checking the PEP 3127 implementation in py3k and the
backport I did to 2.6. The PEP says this about the % operator:
"The string (and unicode in 2.6) % operator will have 'b' format
specifier added for binary, and the alternate syntax of the 'o' option
will need to be updated t
Now that we're aggressively adding Py3k warnings to the trunk, I think it's
a good time to get this straightened out. The docs [1] say PyErr_Warn is
deprecated in favor of PyErr_WarnEx. However, I have seen both in recent
checkins. What is preferred?
[1] http://docs.python.org/dev/c-api/exceptions
I see the problem. Without -ucompiler, test_compiler doesn't compile
everything. I'll fix the breakage shortly.
Apologies.
Eric Smith wrote:
> Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac
> OS X boxes. I'm trying to duplicate the problem. I'm going to try it
> on
Neal Norwitz wrote:
> Part of this is done, but very differently in that all strings used in
> code objects are interned (stored in a dictionary
And since two interned strings can be compared
by pointer identity, I don't see how this differs
significantly from the "unique integer" idea.
If the in
Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac
OS X boxes. I'm trying to duplicate the problem. I'm going to try it
on my Windows box when I get home in about an hour. I'll fix it tonight.
I realize there's a beer riding on the buildbots being green!
Eric.
Trent Nel
> > Sounds like a challenge if ever I've heard one -- care to wager a beer on
> > it?
> > (Only applies to buildbots that are connected/online.)
> Make sure you get a screen shot for OnYourDesktop if/when they *do* go
> green!
Screenshot? I'm going to buy a pack of iron-on transfers and sell t-
We should probably move this off of Python-Dev, as we're getting into
deep details now...
At 07:27 PM 3/18/2008 -0500, Dave Peterson wrote:
>If you really wanted to do a full-tree intersection, it seems to me
>that the problem is detecting all the dependencies without having to
>spend significa
This change breaks all the trunk buildbots:
==
ERROR: testCompileLibrary (test.test_compiler.CompilerTest)
--
Traceback (most recent call last):
File
"S:\build
Phillip J. Eby wrote:
At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote:
1. Many felt the existing dependency resolver was not correct. They wanted a
full tree traversal resulting in an intersection of all restrictions,
instead of a first-acceptable-solution approach taking now, which ca
I don't think this is bike-shedding.
The debate about "AMD64" vs. "amd64" vs. "x86_64" reminded me that
I've been bit more and more frequently by bits of platform-specific
knowledge scattered around the standard library. The latest is the
code in distutils.unixccompiler that tries to figure out w
On Wed, Mar 5, 2008 at 4:27 PM, Henrik Vendelbo <[EMAIL PROTECTED]> wrote:
> It appears to me that if you can make mapping mechanisms faster in
> Python you can make significant
> overall speed improvements. I also think the proposed concept could
> add flexibility to persistence formats
> and
On Mon, Mar 10, 2008, George Fazekas wrote:
>
> I'm working on embedding Python in a multi threaded application but
> found mostly old or confusing info on this. Can anyone point me to the
> right direction or send some working examples?
You should ask on comp.lang.python or the capi-sig list. p
I think (repeatedly) testing an app through IDLE is a reasonable use case.
Would it be reasonable for shutdown to remove logging from
sys.modules, so that a rerun has some chance of succeeding via its own
import?
-jJ
On 3/16/08, vinay.sajip <[EMAIL PROTECTED]> wrote:
> Author: vinay.sajip
> Dat
On Tue, Mar 18, 2008 at 4:43 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> The tabs/spaces checker that is run before doing a svn ci on the python
> repository spits out an error message about which files have problems.
>
> Could someone please update this error message to say something to the
At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote:
>Only very few people would care about writing a setup
>script that works with this bootstrap module; basically only package
>manager implementers.
That's true today, sure, but as soon as it is widely available,
others are sure to want to use i
On 18-Mar-08, at 6:01 PM, Benjamin Peterson wrote:
Couldn't you just import imap as map?
What do you mean? Import imap as map in future_builtins.c?
Like the Python:
import itertools
map = intertools.map
type(map(lambda x: x, range(3))) == map # True
Ah, that's a much better idea :P
I'll do t
On Mon, Mar 3, 2008 at 8:00 AM, Greg Kochanski <[EMAIL PROTECTED]>
wrote:
> If we have a hierarchy of classes, and we use
> __getstate__/__setstate__, the wrong version
> of __setstate__ gets called.
>
> Possibly, this is a documentation problem, but here goes:
>
No, it's a typo error :)
>
> Ta
The tabs/spaces checker that is run before doing a svn ci on the python
repository spits out an error message about which files have problems.
Could someone please update this error message to say something to the
effect of
"run Tools/scripts/reindent.py on every file listed above and rerun your
Folks:
(By the way, it was a pleasure to meet many of you in Real Life for
the first time at Pycon.)
Here is what I want:
1. The standard Python build tools by default produce machine-
parseable package metadata, which can include package dependency
information with reasonably well-defined
Hi all,
I'm working on embedding Python in a multi threaded application
but found mostly old or confusing info on this. Can anyone point me to
the
right direction or send some working examples?
Detail:
Python 2.5.1, MacOSX Leopard 10.5.1, using Pytohn/C API
The application initializes Python
It appears to me that if you can make mapping mechanisms faster in
Python you can make significant
overall speed improvements. I also think the proposed concept could
add flexibility to persistence formats
and RMI interfaces.
My basic idea is to have a constant string type with an interpreter
If we have a hierarchy of classes, and we use
__getstate__/__setstate__, the wrong version
of __setstate__ gets called.
Possibly, this is a documentation problem, but here goes:
Take two classes, A and B, where B is the child of A.
Construct a B. Pickle it. Unpickle it, and you find
that the
On 2 Mar 2008, at 02:00, Alex Martelli wrote:
> On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw <[EMAIL PROTECTED]>
> wrote:
> ...
>>> I also propose translations of the shorter text to important
>>> languages
>>> like French, German, Japanese, Portuguese and Spanish. I'm willing
>>> to
>>>
I've added your comments to a wiki page
(http://wiki.python.org/moin/PackagingBOF) I was working on to summarize
some of what went on during these BoF meeting, at least from the
Enthought point-of-view. Unfortunately, I wasn't at the first night's
event and don't yet have Travis Oliphant's not
On Tue, Mar 18, 2008 at 4:09 PM, Isaac Morland <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Mar 2008, Brett Cannon wrote:
>
> > Lastly, I would like to have it strip trailing whitespace in C files.
> > The only problem is that I don't know if removing trailing whitespace
> > could possibly cause a pr
On 18-Mar-08, at 5:10 PM, Guido van Rossum wrote:
> On Tue, Mar 18, 2008 at 3:54 PM, David Wolever
> <[EMAIL PROTECTED]> wrote:
> type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch
>>
> type(map(lambda x: x, [1, 2, 3])) == map
>> False
> Doesn't strike me as a terrible prob
[changing to: and subject: ]
On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
> <[EMAIL PROTECTED]> wrote:
> > Get this test to pass (UserList/UserDict no longer exist and caused a
> skip).
>
> I think the automatic s
Trent Nelson wrote:
>>> New sprint idea: getting all (inc. trunk) the buildbots green by
>> Thursday. Anyone interested?
>>
>> I think the chance to achieve that is close to zero.
>
> Sounds like a challenge if ever I've heard one -- care to wager a beer on it?
> (Only applies to buildbots that
On Tue, Mar 18, 2008 at 3:54 PM, David Wolever <[EMAIL PROTECTED]> wrote:
> I'm working on #2171 -- putting map, filter, zip in 2.6's
> future_builtins.
> It has been suggested that it would be simplest to just return
> itertools.(imap, izip, ifilter), which is what py3k/Python/
> bltinmodule.c
On Tue, 18 Mar 2008, Brett Cannon wrote:
> Lastly, I would like to have it strip trailing whitespace in C files.
> The only problem is that I don't know if removing trailing whitespace
> could possibly cause a problem or not. Anyone know?
I would be worried about the sequence backslash-space-newl
On Tue, Mar 18, 2008 at 11:43 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <[EMAIL PROTECTED]> wrote:
> > > Possible features for 2.6
> > > New modules in the standard library:
> > > - JSON implementation
> > >
> > Have there bee
I'm working on #2171 -- putting map, filter, zip in 2.6's
future_builtins.
It has been suggested that it would be simplest to just return
itertools.(imap, izip, ifilter), which is what py3k/Python/
bltinmodule.c, revision 61356 did.
The advantage of this is that it's really easy and the behav
s/Brent/Brett (sorry Brett. We still love you.)
On Tue, Mar 18, 2008 at 3:00 PM, Jerry Seutter <[EMAIL PROTECTED]> wrote:
> I have added a bugtracker issue that adds unit test coverage statistics.
> Issue 2403:
>
> http://bugs.python.org/issue2403
>
> Directions are on the issue page.
>
> Titus:
There seems to be a misunderstanding about what I am proposing we do
instead. The boostrap installer should only be powerful enough to
allow it to be used to install a real package manager like setuptools.
Maybe my use of Django as an example was confusing; I didn't actually
mean that it should be
On Tue, Mar 18, 2008 at 11:23 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote:
> >I am hoping that someone will create a simpler bootstrap module that
> >is able to download a file of pure Python code and install it, perhaps
> >by running its s
Guido van Rossum writes:
> I am hoping that someone will create a simpler bootstrap module
FWIW (I've never tried to implement one of these things) I agree with
Phillip. This is not possible in the sense you are advocating.
Anything "simpler" is simply an invitation to an unending stream of
iss
Marius Gedminas wrote:
> On Mon, Mar 17, 2008 at 08:37:30PM -0400, Phillip J. Eby wrote:
>> At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote:
>>> People also want a greater variety of file_finders to be included with
>>> setuptools. Instead of just CVS and SVN, they want it to comprehend
>>>
I have added a bugtracker issue that adds unit test coverage statistics.
Issue 2403:
http://bugs.python.org/issue2403
Directions are on the issue page.
Titus: Brent suggested I bug you to review this.
Test, complain, flame. Feedback welcome.
Jerry Seutter
_
After having one too many commits be rejected by having trailing
whitespace, I wrote a script that runs reindent.py over all .py files
that are to be checked in. But since there are other things that one
should be aware of when creating a patch I let people know if they
edited anything in the Doc d
On Wed, Mar 19, 2008 at 02:05:37AM +0900, [EMAIL PROTECTED] wrote:
> So, at the risk of painting a bike-shed, I'd like to propose that we adopt
> 'AMD64' in distutils (needs a change), platform.py (needs a change to use
> sys.getwindowsversion() in preference to pywin32, if possible, anyway),
> and
On Tue, Mar 18, 2008 at 10:51 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The key goal here (well, mine in any case :-)
> is to manage developers, not to get releases out at all cost. Even
> though the release schedule is set in stone, I think we should send
> out a variety of reminders a
+1 for avoiding a bikeshed, so +1 to AMD64.
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Christian Heimes [EMAIL
PROTECTED]
Sent: 18 March 2008 13:54
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; python-dev@python.org
Subject: Re: [Python-Dev] Con
> Martin, you've changed externals/bsddb-4.4.20 with regards to x64
> builds recently -- have you been able to get things working in your
> x64 environments?
I changed the project files so that it will use the x64 compilers
even if no environment variables were set - the original bsddb files
expec
> The other query I had was whether or not I should try a later version
> of BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0
> or is it worth investigating newer versions? Martin/Jesus, any
> thoughts on this?
As Greg says: 4.5.x should work fine.
Importing a new version into th
[EMAIL PROTECTED] schrieb:
> So, at the risk of painting a bike-shed, I'd like to propose that we adopt
> 'AMD64' in distutils (needs a change), platform.py (needs a change to use
> sys.getwindowsversion() in preference to pywin32, if possible, anyway),
> and the Python banner (which already uses A
I'm reviving a very old thread based on discussions with Martin at pycon.
> Sent: Monday, 23 July 2007 5:12 PM
> Subject: Re: [Distutils] distutils.util.get_platform() for Windows
Rather than forcing everyone to read the context, allow me to summarize:
On 64bit Windows versions, we need a "string
I keep forgetting to reply to the list:
This is great news. I was getting ready to submit a patch to fix the
Unicode handling in simplejson (which I will probably do anyway), but
I'm interested in making sure whichever lib will hit the standard
library has a correct implementation.
Doug
O
On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <[EMAIL PROTECTED]> wrote:
> > Possible features for 2.6
> > New modules in the standard library:
> > - JSON implementation
> >
> Have there been any plans made for which one? All of the
No. This was something I added as a nice to ha
At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote:
>I am hoping that someone will create a simpler bootstrap module that
>is able to download a file of pure Python code and install it, perhaps
>by running its setup.py, assuming that it only depends on distutils
>(or other things previously instal
Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>>
>> Hey Barry,
>>
>> Thanks for putting this PEP together. This is really helpful.
>
> Hi Travis... thanks!
>
>> I didn't see discussion of PEP 3118 and it's feature
> Possible features for 2.6
> New modules in the standard library:
> - JSON implementation
>
Have there been any plans made for which one? All of the
implementations I'm aware of (cjson, simplejson, jsonlib, demjson,
python-json) have serious issues that in my opinion should be fixed
be
On Tue, Mar 18, 2008 at 9:25 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > About two months ago I fixed the most critical bugs but the unicode free
> > build is treated like a poor cousin at best. It's neither actively
> > developed nor tested in regular intervals. IMO it's a deprecation c
On Tue, Mar 18, 2008 at 8:39 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mar 18, 2008, at 12:11 AM, Guido van Rossum wrote:
> > Hm... This feels a bit like inflation of priorities to me; there would
> > be lots of critical bugs and quite a few release blockers... The
> > highest priority ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
>
> Hey Barry,
>
> Thanks for putting this PEP together. This is really helpful.
Hi Travis... thanks!
> I didn't see discussion of PEP 3118 and it's features back-ported to
> Python 2.6. I've alre
> That shouldn't be hard - I'll set up a Windows virtual machine with no
> additional software on it and can use that for testing. If you want me
> to try anything out, let me know and I can do so in a guaranteed clean
> environment.
I think I've a spare license of XP Home around somewhere. I'm g
> About two months ago I fixed the most critical bugs but the unicode free
> build is treated like a poor cousin at best. It's neither actively
> developed nor tested in regular intervals. IMO it's a deprecation candiate.
In the sense that 3k won't support it anymore - certainly.
In the sense t
> That shouldn't be hard - I'll set up a Windows virtual machine with no
> additional software on it and can use that for testing. If you want me
> to try anything out, let me know and I can do so in a guaranteed clean
> environment.
That should be a reasonable setup. Try moving the manifest files
On 18/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Martin, can you comment? It looks like the 3.0 installer uses 2 copies
> > of msvcr90.dll, where the 2.6 one doesn't. I would have thought that
> > only one is necessary, but Gregor's experiments seem to demonstrate
> > otherwise.
>
>
Martin v. Löwis schrieb:
> It's still intended that you can build Python 2.6 without Unicode
> support, and that the test suite "mostly" works.
>
> If it doesn't, it's up to users who care about that feature to provide
> fixes, but you should not actively break it.
About two months ago I fixed th
> The test_support unit has this have_unicode. Do we need the Python's
> test unit to be *that* backward compatible? Is there still an
> implementation of Python that doesn't support unicode? If there is,
> should the test suite care?
It's still intended that you can build Python 2.6 without Unico
> We are still having problems to integrate the MS Merge module into our
> MSI. Martin is working on the problem. In the mean time you can work
> around the problem by installing the MSVCRT 9.0 Redist.
While this is a work-around for the people trying to run the alpha
releases, it effectively pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2008, at 12:11 AM, Guido van Rossum wrote:
> Hm... This feels a bit like inflation of priorities to me; there would
> be lots of critical bugs and quite a few release blockers... The
> highest priority just pertains to the upcoming release
> That's odd. In theory, having msvcr90.dll in C:\Python26 should be
> sufficient, as once python.exe is loaded, its directory is added to
> the DLL search path. Maybe it's something to do with the "side by side
> manifest installation" stuff (or whatever it's called).
Yes, with VS 2008, the DLL s
On Tue, Mar 18, 2008 at 8:18 AM, Virgil Dupras <[EMAIL PROTECTED]> wrote:
> The test_support unit has this have_unicode. Do we need the Python's
> test unit to be *that* backward compatible? Is there still an
> implementation of Python that doesn't support unicode? If there is,
> should the test s
The test_support unit has this have_unicode. Do we need the Python's
test unit to be *that* backward compatible? Is there still an
implementation of Python that doesn't support unicode? If there is,
should the test suite care?
As a side question. Considering that I'm not sure whether have_unicode
Paul Moore schrieb:
> That's odd. In theory, having msvcr90.dll in C:\Python26 should be
> sufficient, as once python.exe is loaded, its directory is added to
> the DLL search path. Maybe it's something to do with the "side by side
> manifest installation" stuff (or whatever it's called).
>
> Mart
Guido van Rossum wrote:
On Mon, Mar 17, 2008 at 11:49 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
We should not release the finals until there are no release blockers
or criticals. Either the critical gets moved to high and ignored, or
it gets moved to release blocker and gets fixed.
Hm...
On 17/03/2008, Gregor Lingl <[EMAIL PROTECTED]> wrote:
> > Another thought - do you have any copies of msvcr90.dll on your PATH?
> > I don't think it'll make a difference, but if you do can you try
> > renaming them?
> >
> >
> No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs.
-On [20080318 01:52], Barry Warsaw ([EMAIL PROTECTED]) wrote:
>This schedule gives everybody plenty of advanced notice, so you should be
>able to get your code in on time.
In particular the memory related fixes over the last weeks, please. :)
--
Jeroen Ruigrok van der Werven / asmodai
Barry Warsaw wrote:
> Greetings from Pycon 2008!
>
> Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0,
> which will be released in lockstep. We will be following a monthly
> release schedule, with releases to occur on the first Wednesday of the
> month. We'll move to a 2
73 matches
Mail list logo
