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 week
-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.
Strange
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).
Martin, can
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 suite
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 search
-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
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 Unicode
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 the most
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.
I haven'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
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
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
-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 already
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 just
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 candiate.
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
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 features back-ported to
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
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 have for
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
[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
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 the
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
+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]
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 ahead
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
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
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 setup.py,
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: Brent
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
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 been any plans made
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
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 are
[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 skip on
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 'itertools.imap'
type(map(lambda x: x, [1, 2, 3])) == map
False
Doesn't strike me as a terrible
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 problem or
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
help with the
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
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
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 :)
Take two
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
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 it
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
Date:
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.
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 RMI
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 what
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
This change breaks all the trunk buildbots:
==
ERROR: testCompileLibrary (test.test_compiler.CompilerTest)
--
Traceback (most recent call last):
File
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 significant
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-shirts
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
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
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]
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
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
skip).
I
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
72 matches
Mail list logo
