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
-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
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.
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...
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
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
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
> 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
-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
> 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
> 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
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
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.
>
>
> 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
> 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.
I think I've a spare license of XP Home around somewhere. I'm g
-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
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
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
> 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
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
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
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
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
[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
> 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
> 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
+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
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
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
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
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
_
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
>>>
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
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
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
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:
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
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
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 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
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
[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
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
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
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 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
>>>
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
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
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
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
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
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
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
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 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
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 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
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
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
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
This change breaks all the trunk buildbots:
==
ERROR: testCompileLibrary (test.test_compiler.CompilerTest)
--
Traceback (most recent call last):
File
"S:\build
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
> > 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-
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
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
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
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'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
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
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
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
73 matches
Mail list logo
