Re: [Python-Dev] [Python-checkins] r61403 - python/trunk/Misc/NEWS

[Nick Coghlan]

[EMAIL PROTECTED] wrote:
> Well, %u is already in use by at least some implementations of strftime.
>>From the Solaris 10 man page:
> 
>  %u   Weekday  as  a  decimal  number   [1,7],   with   1
>   representing Monday. See NOTES below.
> 
> I see the same on my Mac.
> 
> I think it's better to use the same format code for both parsing and
> formatting if possible.

Yep - %u already being used for something else in some contexts is the 
kind of reason I was looking for. Given that, then %f for fractions of a 
second sounds fine.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

Python 3.0 and 2.6 are coming along really nice. I am optimistic that
we can make the projected August date for the final releases of 2.6
and 3.0. As you may remember, Barry (the new release manager for both)
suggested that we synchronize releases of 2.6 and 3.0. Not only could
this potentially save the release manager and his assistants some
time, doing the final releases together sends a clear signal to the
community that both versions will receive equal support.

However, looking at the calendar, I think we need to do a little more
planning and management than we've typically done for Python releases.
A final release in August means that we should plan to release a first
beta in June and a second one in July. That means we have time for
only two more alpha releases (April and May). I'm thinking of 1-2
release candidates 1-2 weeks ahead of the final release. Barry can
make up a more detailed timetable. I'm fine with some slippage
(especially if planned ahead) of individual releases due to
availability of release personnel; but I don't want to be held up by
features or bugs unless they are of absolutely dramatic show-stopping
nature.

In order to make such a tight release schedule we should try to come
up with a list of tasks that need to be done, and prioritize them.
This should include documentation, and supporting tools like 2to3. It
should include features, backports of features, cleanup, bugs, and
whatever else needs to be done (e.g. bugbot maintenance).

In the past we've used shared spreadsheets in Google for this purpose,
but seeing that these haven't been updated in ages, I'm skeptical that
they are a sufficient tool. In my day job at Google we've started to
do all task management for our project in the bug tracker (but that
tracker has some features that make it particularly easy). Does anyone
have a suggestion for an online open shared task management system
that we cold adopt? Or should we bite the bullet and put everything in
the bug tracker? Other suggestions? Anything's better than just
email...

PS. I realize that I've been rather absent from the day to day
activities in the Python 3000 world lately. This is a temporary
condition due to an important impending launch in my day job; I expect
to have much more time for Python again starting in April.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Facundo Batista]

2008/3/16, Guido van Rossum <[EMAIL PROTECTED]>:

>  they are a sufficient tool. In my day job at Google we've started to
>  do all task management for our project in the bug tracker (but that
>  tracker has some features that make it particularly easy). Does anyone

Like which? Something that could be added to our tracker in a short time?

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

On Sun, Mar 16, 2008 at 9:01 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/3/16, Guido van Rossum <[EMAIL PROTECTED]>:
>  >  they are a sufficient tool. In my day job at Google we've started to
>  >  do all task management for our project in the bug tracker (but that
>  >  tracker has some features that make it particularly easy). Does anyone
>
>  Like which? Something that could be added to our tracker in a short time?

It has a much more detailed set of categories, organized as a tree.
Our project alone probably has 20-30 different bug categories. New
bugs in those categories are automatically CC'ed to our group's
mailing list (which isn't the same as auto-assignment).

There are also more "bug states" you can use to track progress of a
bug through the system: unassigned, assigned, accepted (meaning the
assignee is actually working on it). (There are also a whole bunch
that I don't find so useful, and severam that roundup already
supports.)

But perhaps the best feature is "hot lists" -- arbitrary, ordered,
groupings of selected bugs. Each bug can be assigned to as many hot
lists as you want. Seeing the list of all bugs in a particular hot
list is one click away. We use this for overlaying project management
categories and priorities, such as "code", "documentation",
"configuration" as well as "next internal release", "must have", "post
launch" etc.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[skip]

Guido> It has a much more detailed set of categories, organized as a
Guido> tree.  Our project alone probably has 20-30 different bug
Guido> categories. New bugs in those categories are automatically CC'ed
Guido> to our group's mailing list (which isn't the same as
Guido> auto-assignment).

Adding categories should be easy.  Organized in trees?  Not so sure.

Guido> There are also more "bug states" you can use to track progress of
Guido> a bug through the system: unassigned, assigned, accepted (meaning
Guido> the assignee is actually working on it). (There are also a whole
Guido> bunch that I don't find so useful, and severam that roundup
Guido> already supports.)

Again, I think this should be easy.

Guido> But perhaps the best feature is "hot lists" -- arbitrary,
Guido> ordered, groupings of selected bugs. Each bug can be assigned to
Guido> as many hot lists as you want. Seeing the list of all bugs in a
Guido> particular hot list is one click away. We use this for overlaying
Guido> project management categories and priorities, such as "code",
Guido> "documentation", "configuration" as well as "next internal
Guido> release", "must have", "post launch" etc.

A hot list sounds like a saved search, which Roundup already supports.  It
also supports making these saved searches public.  I suspect you could
define one or more saved public searches which correspond to desired hot
lists.

Aside: Today's my last day here.  I'd like to say hi sometime today.  Free
for lunch?  Maybe this would be a good lunchtime discussion.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Christian Heimes]

Guido van Rossum wrote:
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).

I did a quick brainstorming with me, myself and I. I came up with a list
of (IMHO) important tasks.

* Stabilize the C API of Python 3.0. I like to rename several prefixes
to reduce the confusing: PyBytes -> PyByteArray, PyString -> PyBytes ...

* Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
and he said he is trying to get it done during the PyCon sprint. Maybe
somebody can assist him?
When the new buffer protocol is available in 2.6 we can start back
porting bytesarray and the new IO framework.

* Replace Windows API calls with wide versions to support unicode for
file names, environment etc.

* Get the stdlib reorg done and add the fixers to 2to3

* Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
but it may be too late when we plan to ship out 3.0 in August.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management

[Gregor Lingl]

Hi everyone,

with this posting I refer to a paragraph in PEP 361, which says:

"""Each non-trivial feature listed here that is not a PEP must be discussed on 
python-dev.  Other enhancements include:

   - ...
   - turtle.py replacement or enhancements
"""

Some time ago I had offered my xturtle.py as a replacement of or 
supplement to turtle.py. The discussion that followed is here:

http://www.python.org/dev/summary/2006-06-16_2006-06-30/

At Europython 2006 I gave a talk on xturtle and there and since then I 
had quite positive feedback including encouragement to offer it again to 
include it in the python standard distribution by quite a few people 
including Guido van Rossum.

During the last few weeks I did some enhancements to xturtle and put the 
current version on the xturtle website for download in order to get same 
feedback about the API as well as possible bug reports. This version 
still needs some code polishing.

http://www.rg16.at/~python/xturtle/download.html

So I'm interested to know if this is still an issue for you. If so there 
should be initiated some procedure to decide that.

If this decision were negative, things were done (- and I'd continue to 
develop xturtle elsewhere.)

If the decision were positive, I'd be able to prepare two equivalent 
versions for Python2.6 and Python3000 within two or three weeks. (The 
port to Python3000 is nearly ready.) These could include say 85% of the 
documentation, albeit still not in the correct format.

I think these had to be examined my some reviewer(s) and also a 
discussion about features to include or not include would be useful. I'd 
like to intensivly take part in this discussion and development.

After a possible decision to include xturtle into Python, which 
certainly should take place before the first beta release, there would 
be enough time to polish the documentation and to fix bugs. For their 
discovery it would certainly be an advantage to put it in some 
prerelease as early as possible.

Of course I know that xturtle is only a side issue in the current 
development efforts. Unfortunately I'm not familiar with the procedures 
needed to get a new module into Python, so I kindly ask you for your 
advice how to proceed, at the same time offering my cooperation.

With best regards

Gregor Lingl

Guido van Rossum schrieb:
> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
>   
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

Moving this to a new subject to keep the discussion of tasks and the
discussion of task tracking tools separate.

On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>  I did a quick brainstorming with me, myself and I. I came up with a list
>  of (IMHO) important tasks.
>
>  * Stabilize the C API of Python 3.0. I like to rename several prefixes
>  to reduce the confusing: PyBytes -> PyByteArray,

+1 (also +1 to backporting this to 2.6)

> PyString -> PyBytes ...

-1. This will make merging code from 2.6 harder, and causes more work
for porting C extensions.

>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
>  and he said he is trying to get it done during the PyCon sprint. Maybe
>  somebody can assist him?

Does he need assistance?

>  When the new buffer protocol is available in 2.6 we can start back
>  porting bytesarray and the new IO framework.

Are these really so closely tied that they have to wait before they
can be backported?

>  * Replace Windows API calls with wide versions to support unicode for
>  file names, environment etc.

+1. This should be broken into separate tasks for each API.

>  * Get the stdlib reorg done

+1. But again, I think this is many small tasks.

> and add the fixers to 2to3

+1. I think quite a few changes have not had a fixer added. Again, I
think we should maintain a specific list of needed fixers; fixers can
easily be developed independently.

>  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
>  but it may be too late when we plan to ship out 3.0 in August.

While I know that some people are expecting to use a development model
that invokes 2to3 very frequently, I think this is at best a
nice-to-have. (I also don't see how it could be done, but maybe I'm
blind for the obvious, as the original author.)

I have some other tasks to add:

- getargs.c (Georg posted about this; his post actually inspired my post.)

- Tweak structseq to be more like namedtuple. Maybe they could have a
common ABC. I also think we should get rid of the concept of "hidden"
fields (that are accessible by name but not through the tuple API).

- Devise a way to handle str instances pickled in 2.6 and unpickled in
3.0, and also bytes instances pickled in 3.0 and unpickled in 2.6.

- Someone should go over
  https://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg
and extract more tasks.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 3.0 buildbots all red

[Trent Nelson]

http://www.python.org/dev/buildbot/3.0/

New sprint idea: getting all (inc. trunk) the buildbots green by Thursday.  
Anyone interested?


Trent.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] xturtle and 3.0

[Guido van Rossum]

I'm changing the subject to keep this separate from the project
management tools discussion.

On Sun, Mar 16, 2008 at 10:13 AM, Gregor Lingl <[EMAIL PROTECTED]> wrote:
>
>  Hi everyone,
>
>  with this posting I refer to a paragraph in PEP 361, which says:
>
>  """Each non-trivial feature listed here that is not a PEP must be discussed 
> on python-dev.  Other enhancements include:
>
>- ...
>- turtle.py replacement or enhancements
>  """
>
>  Some time ago I had offered my xturtle.py as a replacement of or
>  supplement to turtle.py. The discussion that followed is here:
>
>  http://www.python.org/dev/summary/2006-06-16_2006-06-30/
>
>  At Europython 2006 I gave a talk on xturtle and there and since then I
>  had quite positive feedback including encouragement to offer it again to
>  include it in the python standard distribution by quite a few people
>  including Guido van Rossum.
>
>  During the last few weeks I did some enhancements to xturtle and put the
>  current version on the xturtle website for download in order to get same
>  feedback about the API as well as possible bug reports. This version
>  still needs some code polishing.
>
>  http://www.rg16.at/~python/xturtle/download.html
>
>  So I'm interested to know if this is still an issue for you. If so there
>  should be initiated some procedure to decide that.

I think that for 3.0, replacing turtle with xturtle is great, *IF*
xturtle doesn't add any additional dependencies *AND* it works well on
Mac OSX, Linux and Windows.

>  If this decision were negative, things were done (- and I'd continue to
>  develop xturtle elsewhere.)
>
>  If the decision were positive, I'd be able to prepare two equivalent
>  versions for Python2.6 and Python3000 within two or three weeks. (The
>  port to Python3000 is nearly ready.) These could include say 85% of the
>  documentation, albeit still not in the correct format.

That sounds cool. In 2.6 I'm reluctant to replace the existing turtle
module; xturtle can be added as xturtle.

>  I think these had to be examined my some reviewer(s) and also a
>  discussion about features to include or not include would be useful. I'd
>  like to intensivly take part in this discussion and development.
>
>  After a possible decision to include xturtle into Python, which
>  certainly should take place before the first beta release, there would
>  be enough time to polish the documentation and to fix bugs. For their
>  discovery it would certainly be an advantage to put it in some
>  prerelease as early as possible.
>
>  Of course I know that xturtle is only a side issue in the current
>  development efforts. Unfortunately I'm not familiar with the procedures
>  needed to get a new module into Python, so I kindly ask you for your
>  advice how to proceed, at the same time offering my cooperation.

I think that for a library module like this, an email like you've sent
is just fine. Maybe Brett has a suggestion on whether it would remain
a toplevel module or could be placed in some umbrella package (is
Tkinter being moved around?).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Trent Nelson]

> >  * Replace Windows API calls with wide versions to support unicode
> >for file names, environment etc.
>
> +1. This should be broken into separate tasks for each API.

What are we referring to here?  Calling the W versions explicitly and using 
wchar_t for everything, or using the TCHAR/TEXT() approach and keeping the API 
calls the same, letting the #define UNICODE do the work behind the scenes?

Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Martin v. Lšwis]

> 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.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Trent Nelson]

> > 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 connected/online.)

(FWIW, I've got the x64 Windows build green on my dev server, tcl/tk and bsddb 
required patching, so did some tests, and so did some C code -- I'm in the 
process of filtering the efforts back into the tracker.)

Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Georg Brandl]

Guido van Rossum schrieb:

> But perhaps the best feature is "hot lists" -- arbitrary, ordered,
> groupings of selected bugs. Each bug can be assigned to as many hot
> lists as you want. Seeing the list of all bugs in a particular hot
> list is one click away. We use this for overlaying project management
> categories and priorities, such as "code", "documentation",
> "configuration" as well as "next internal release", "must have", "post
> launch" etc.

Doesn't this match Roundup's keywords?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 8:51 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...

I don't like the idea of task like items in the main bug tracker. I do,
however, like the bug tracker interface for this sort of thing. Could we
start a new instance of the the tracker just for internal development tasks?
We could change the statuses around to "Work in progress", "Completed",
"Incomplete", and such. It'd be easy to search for tasks that have to be
accomplished for a given release.

>
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
>
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> >  I did a quick brainstorming with me, myself and I. I came up with a
> list
> >  of (IMHO) important tasks.
> >
> >  * Stabilize the C API of Python 3.0. I like to rename several prefixes
> >  to reduce the confusing: PyBytes -> PyByteArray,
>
> +1 (also +1 to backporting this to 2.6)
>
> > PyString -> PyBytes ...
>
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.

There was a thread about this a few weeks ago:
http://mail.python.org/pipermail/python-dev/2008-March/077339.html
We can still do the renaming, but alias PyString to PyBytes.

>
>
> >  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
> >  and he said he is trying to get it done during the PyCon sprint. Maybe
> >  somebody can assist him?
>
> Does he need assistance?
>
> >  When the new buffer protocol is available in 2.6 we can start back
> >  porting bytesarray and the new IO framework.
>
> Are these really so closely tied that they have to wait before they
> can be backported?
>
> >  * Replace Windows API calls with wide versions to support unicode for
> >  file names, environment etc.
>
> +1. This should be broken into separate tasks for each API.
>
> >  * Get the stdlib reorg done
>
> +1. But again, I think this is many small tasks.
>
> > and add the fixers to 2to3
>
> +1. I think quite a few changes have not had a fixer added. Again, I
> think we should maintain a specific list of needed fixers; fixers can
> easily be developed independently.
>
> >  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
> >  but it may be too late when we plan to ship out 3.0 in August.
>
> While I know that some people are expecting to use a development model
> that invokes 2to3 very frequently, I think this is at best a
> nice-to-have. (I also don't see how it could be done, but maybe I'm
> blind for the obvious, as the original author.)
>
> I have some other tasks to add:
>
> - getargs.c (Georg posted about this; his post actually inspired my post.)
>
> - Tweak structseq to be more like namedtuple. Maybe they could have a
> common ABC. I also think we should get rid of the concept of "hidden"
> fields (that are accessible by name but not through the tuple API).
>
> - Devise a way to handle str instances pickled in 2.6 and unpickled in
> 3.0, and also bytes instances pickled in 3.0 and unpickled in 2.6.
>
> - Someone should go over
>  https://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg
> and extract more tasks.
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> I don't like the idea of task like items in the main bug tracker.

Why not? Bugs are also tasks, and need to be managed and triaged in
the same way. It might be convenient to have everything in one
tracker. What's your objection? It should be easy enough to search for
tasks or bugs etc.

> I do, however, like the bug tracker interface for this sort of thing. Could we
> start a new instance of the the tracker just for internal development tasks?

I'm not sure how easy it would be to start a new instance, but I
expect setting up the database, configuration etc. would require a
fairly significant amount of work. I'd much rather use existing
infrastructure.

> We could change the statuses around to "Work in progress", "Completed",
> "Incomplete", and such. It'd be easy to search for tasks that have to be
> accomplished for a given release.

That would be good for bugs too, actually.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: 2.6 and 3.0 project management

[Guido van Rossum]

Sorry, forgot to CC this to the list.

On Sun, Mar 16, 2008 at 9:31 AM,  <[EMAIL PROTECTED]> wrote:
 >
 > Guido> It has a much more detailed set of categories, organized as a
 > Guido> tree.  Our project alone probably has 20-30 different bug
 > Guido> categories. New bugs in those categories are automatically CC'ed
 > Guido> to our group's mailing list (which isn't the same as
 > Guido> auto-assignment).
 >
 >  Adding categories should be easy.  Organized in trees?  Not so sure.

 The tree is really useful because it means that end users can assign
 bugs to the top-level node for a project and the project members can
 move it to the correct subnode. This can even happen in two triage
 stages for large projects.


 > Guido> There are also more "bug states" you can use to track progress of
 > Guido> a bug through the system: unassigned, assigned, accepted (meaning
 > Guido> the assignee is actually working on it). (There are also a whole
 > Guido> bunch that I don't find so useful, and severam that roundup
 > Guido> already supports.)
 >
 >  Again, I think this should be easy.

 It's also the least important one on my list.


 > Guido> But perhaps the best feature is "hot lists" -- arbitrary,
 > Guido> ordered, groupings of selected bugs. Each bug can be assigned to
 > Guido> as many hot lists as you want. Seeing the list of all bugs in a
 > Guido> particular hot list is one click away. We use this for overlaying
 > Guido> project management categories and priorities, such as "code",
 > Guido> "documentation", "configuration" as well as "next internal
 > Guido> release", "must have", "post launch" etc.
 >
 >  A hot list sounds like a saved search, which Roundup already supports.  It
 >  also supports making these saved searches public.  I suspect you could
 >  define one or more saved public searches which correspond to desired hot
 >  lists.

 Not quite. Items don't automatically end up on a hot list; they must
 explicitly be put on one. I'm not sure how you'd simulate this via
 saved searches. Maybe a combination of a custom keyword *and* a saved
 search would help. However this doesn't scale so well, because
 keywords show up in everybody's UI. Hot lists are only visible to
 users who care to subscribe to them.

[Georg, in a later post]
> Doesn't this match Roundup's keywords?

See above answer.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > PyString -> PyBytes ...
> >
> > -1. This will make merging code from 2.6 harder, and causes more work
> > for porting C extensions.

> There was a thread about this a few weeks ago:
> http://mail.python.org/pipermail/python-dev/2008-March/077339.html
>  We can still do the renaming, but alias PyString to PyBytes.

That's a rather long thread. Was any conclusion reached? I'm not sure
how introducing a set of aliases will help merging 2.6 code to 3.0.
Can you or Christian describe the proposed approach in more detail?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 16, 2008, at 10:48 AM, Martin v. Lšwis 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.

How broken do you want the next monthly alphas to be? :)

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR91OWHEjvBPtnXfVAQIL/gP/T5TqGLt6Z7LD3/vEKt/0qjZErkOQmmFH
BciuGOs6CCud//N4fsSev2CBmeAQ/RspHhjLSSKBd6H4rimZWv5ePo0gMC2N7nGY
1wpUvixaZpYol4zywjBQRO+bjlnZtdt4WG09DdMrn0MsYHNpVFaAPTWx4X3BFHm+
k0QLzsJ7T2o=
=7czp
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Collin Winter]

On Sun, Mar 16, 2008 at 8:23 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>  On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
..
>  > and add the fixers to 2to3
>
>  +1. I think quite a few changes have not had a fixer added. Again, I
>  think we should maintain a specific list of needed fixers; fixers can
>  easily be developed independently.

Neal and I are coming up with a list to feed tasks to interested PyCon
sprinters.

>  >  * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3
>  >  but it may be too late when we plan to ship out 3.0 in August.
>
>  While I know that some people are expecting to use a development model
>  that invokes 2to3 very frequently, I think this is at best a
>  nice-to-have. (I also don't see how it could be done, but maybe I'm
>  blind for the obvious, as the original author.)

The biggest win in terms of performance would be to reimplement the
pattern matching engine used by the fixers.: it by far dominates the
running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
for example. The current design is a heavily-recursive system, and as
such bombs out when it encounters, e.g., files with a thousand
assignment statements in a row. I'd also like something more
expressive: the current DSL can't express recursive patterns.

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[skip]

>> I don't like the idea of task like items in the main bug tracker.

Guido> Why not? Bugs are also tasks, and need to be managed and triaged
Guido> in the same way.

Agreed.  Both bugs and tasks would be "issues" in Roundup parlance, along
with patches.

A further reason to keep this in Roundup if possible is that people like
Martin have already committed to help maintain the tracker.  We already have
a separate Trac instance for the website, which I would like to see folded
into the Roundup tracker, freeing up limited (human) resources used to
maintain that tracker so they can either spend more time with their families
or work on other things that need doing.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 11:37 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > I don't like the idea of task like items in the main bug tracker.
>
> Why not? Bugs are also tasks, and need to be managed and triaged in
> the same way. It might be convenient to have everything in one
> tracker. What's your objection? It should be easy enough to search for
> tasks or bugs etc.

It's just depends on how you see the tracker. It's not just to "bug" tracker
anymore, is it? On other projects I've worked with, we had separate areas
for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
keep organized. However, if this is Python's way, I'm not going to stand in
it.

>
>
> > I do, however, like the bug tracker interface for this sort of thing.
> Could we
> > start a new instance of the the tracker just for internal development
> tasks?
>
> I'm not sure how easy it would be to start a new instance, but I
> expect setting up the database, configuration etc. would require a
> fairly significant amount of work. I'd much rather use existing
> infrastructure.

I'm now fine with that.

>
>
> > We could change the statuses around to "Work in progress", "Completed",
> > "Incomplete", and such. It'd be easy to search for tasks that have to be
> > accomplished for a given release.
>
> That would be good for bugs too, actually.

Well, I'm glad to help somehow! :P

>
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Fwd: 2.6 and 3.0 project management

[Martin v. Lšwis]

>  Not quite. Items don't automatically end up on a hot list; they must
>  explicitly be put on one. I'm not sure how you'd simulate this via
>  saved searches. Maybe a combination of a custom keyword *and* a saved
>  search would help. However this doesn't scale so well, because
>  keywords show up in everybody's UI. Hot lists are only visible to
>  users who care to subscribe to them.

It would be relatively easy to implement this directly in roundup.
IIUC, there should be a hotlist object, and either
a) an issue has a multilink to multiple hotlists, or
b) a hotlist has a multilink to multiple issues.

I cannot envision the "add to hotlist" user interface, though.
It should be possible to add an issue to a hotlist from the issue's
page, right? So would a comma-separated list be reasonable? (with
a popup menu to checkmark hotlists)

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 11:44 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Sun, Mar 16, 2008 at 11:26 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 16, 2008 at 10:23 AM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> > > > PyString -> PyBytes ...
> > >
> > > -1. This will make merging code from 2.6 harder, and causes more work
> > > for porting C extensions.
>
> > There was a thread about this a few weeks ago:
> > http://mail.python.org/pipermail/python-dev/2008-March/077339.html
> >  We can still do the renaming, but alias PyString to PyBytes.
>
> That's a rather long thread. Was any conclusion reached? I'm not sure
> how introducing a set of aliases will help merging 2.6 code to 3.0.
> Can you or Christian describe the proposed approach in more detail?

As far as I can see, no objections were raised in that thread.
Christian explained the probable approach:
http://mail.python.org/pipermail/python-dev/2008-March/077362.html

>
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management

[Martin v. Lšwis]

> It's just depends on how you see the tracker. It's not just to "bug" 
> tracker anymore, is it? On other projects I've worked with, we had 
> separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I 
> found it easier to keep organized. However, if this is Python's way, I'm 
> not going to stand in it.

Actually, one of the main complaints about the SF tracker is that it
splits into several ones.

Something starts out as a bug, but then becomes a patch as soon as
somebody attaches a patch. So on SF, people had to open a *separate*
issue to provide a patch, and leave a message in the original bug
report pointing to the patch. They hated it, and insisted that
the new tracker should have a single list of issues.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] xturtle and 3.0

[Brett Cannon]

On Sun, Mar 16, 2008 at 10:32 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm changing the subject to keep this separate from the project
>  management tools discussion.
>
>
>  >  Of course I know that xturtle is only a side issue in the current
>  >  development efforts. Unfortunately I'm not familiar with the procedures
>  >  needed to get a new module into Python, so I kindly ask you for your
>  >  advice how to proceed, at the same time offering my cooperation.
>
>  I think that for a library module like this, an email like you've sent
>  is just fine. Maybe Brett has a suggestion on whether it would remain
>  a toplevel module or could be placed in some umbrella package (is
>  Tkinter being moved around?).

The current plan is to introduce a tk package and turtle was to become
tk.turtle. xturtle, if picked up, can just take the place of the
current turtle at that location.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Martin v. Lšwis]

>>> * Replace Windows API calls with wide versions to support unicode
>>>  for file names, environment etc.
>> +1. This should be broken into separate tasks for each API.
> 
> What are we referring to here?  Calling the W versions explicitly and
> using wchar_t for everything, or using the TCHAR/TEXT() approach and
> keeping the API calls the same, letting the #define UNICODE do the
> work behind the scenes?

Not sure whose being attributed here, but I think "breaking down"
should be done by "information source": command line, environment,
registry, file names, sys.path, module names, etc.

I have a patch on SF to resolve the command line issue.

I don't think we should use Microsoft's Unicode programming model
around TCHAR/TEXT. It would allow for two different builds, and
given that we don't need to support W9X anymore, an "ANSI" build
is pointless, IMO.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Martin v. Löwis]

>>> 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 connected/online.)

Even with that restriction: I'll happily buy you a beer if you
manage to get all the online ones pass all tests consistently.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Christian Heimes]

Guido van Rossum wrote:
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.

I'm happy to pay the price for the sake of a clean and easy-to-recall C
API.

The for the C extension problem I already proposed a solution in the
thread Benjamin mentioned before.

#include "Python.h"
#if PY_VERSION_HEX > 0x0300
  #include "python2_compat.h"
#endif

Where python2_compat provides aliases for PyInt and PyString:

#define PyInt_Spam PyLong_Spam
...
#define PyString_Egg PyBytes_Egg

>>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
>>  and he said he is trying to get it done during the PyCon sprint. Maybe
>>  somebody can assist him?
> 
> Does he need assistance?

I don't know.
> 
>>  When the new buffer protocol is available in 2.6 we can start back
>>  porting bytesarray and the new IO framework.
> 
> Are these really so closely tied that they have to wait before they
> can be backported?

Bytesarray depends on the buffer protocol and the new io framework is
much easier to back port when both the buffer protocol and bytesarray is
available.

> While I know that some people are expecting to use a development model
> that invokes 2to3 very frequently, I think this is at best a
> nice-to-have. (I also don't see how it could be done, but maybe I'm
> blind for the obvious, as the original author.)

I'm not sure if and how 2to3 can be speed up. Maybe some profiling and
some C code can increase the speed. It's worth a shot.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

On Sun, Mar 16, 2008 at 11:51 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> It's just depends on how you see the tracker. It's not just to "bug" tracker
> anymore, is it? On other projects I've worked with, we had separate areas
> for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
> keep organized. However, if this is Python's way, I'm not going to stand in
> it.

Ah, sourceforge. I am so glad we're not using that any more. The
random separation between patches and bugs was more a distraction
rather than a feature; often bugs turn into patches or patches turn
out to be useless except for the fact that they highlight a bug...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Christian Heimes]

Collin Winter wrote:
> The biggest win in terms of performance would be to reimplement the
> pattern matching engine used by the fixers.: it by far dominates the
> running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
> for example. The current design is a heavily-recursive system, and as
> such bombs out when it encounters, e.g., files with a thousand
> assignment statements in a row. I'd also like something more
> expressive: the current DSL can't express recursive patterns.

Do you have time to mentor a GSoC project? Or can you mentor a mentor
...? :)

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:

> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.

I mentioned this to Guido and got a positive response, so let me state  
my preference for your feedback.  I plan on holding up the final  
releases until both versions are ready to go.  I think this will help  
motivate us to give Python 2.6 the love it needs if it's lagging  
behind 3.0, and I completely agree with Guido that this let's our  
community know that both versions are equally important to us.

The other thing is that I'd really like is a "show stoppers" Roundup  
search.  The idea is that if our core buildbots look good and the  
"show stoppers" search turns up no items, then I know I can cut a  
release (at least for alphas, betas, and rcs).  If there are "show  
stoppers" then I have something that I can triage (and maybe re-assign  
severity) or start publicly harassing people into fixing.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR91XxHEjvBPtnXfVAQIINwQAsaJ8uWb0FXqD9wZV8AuE7CxG2RLEZl42
vz2EUbAs7n/txV/lWs3N4syZvfS7g0Q3rgd65LvpUCi4+r6M3MpKcl9VFxGfheUD
mHf5LajS/wEEXyFpxG9+dGfhPpD7JFx21PKyOpHKnq3LP0fCt3yenOi/nEF5zfHr
Ogc6JOapRiM=
=0f9G
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:

> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.

Oh yeah, I'd like to hash a more detailed timeline out at the sprint.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR91YCXEjvBPtnXfVAQJsxQP9FgyAn2JOl/+SShBNgTqlxWBwGAbrjSlS
ySbm/55PKs6bnjx1lkyvptzHFdsfh1LlBVrC5rxQzQIjSX00x8fAPAoseQZ/hDm0
cnVSvPhJhBLsZCmsSRfvDYPdZXnanDd5ff69uV3jd+NLasuJBNrQ5d+eQGiQOTZm
BTgsjt+YKpQ=
=L9yF
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Neal Norwitz]

On Sun, Mar 16, 2008 at 12:07 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 connected/online.)
>
>  Even with that restriction: I'll happily buy you a beer if you
>  manage to get all the online ones pass all tests consistently.

I think this is possible, though considerable work.  Probably the
biggest win will be creating a mock for socket and using mock sockets
in the tests for asyn{core,chat}, smtplib, xmlrpc, etc. That will fix
about 75% of the problems on 2.6.  The remaining problems are:

 * test_asyn{chat,core} might not be meaningful with mock sockets and are flaky
 * the alpha fails test_signal/socket for weird alarm conditions.
this might be hard to debug/fix (I have access to this box though)
 * test_sqlite is broken on x86 with an old sqlite (I have access to this box)
 * test_bsddb may be flaky, I'm not sure
 * probably a few platform specific problems

3.0 will get most of the improvements as the fixes are ported.  3.0
has a different problem on the x86 box dealing with signals.  There
are probably some other 3.0 specific problems. Although, using a mock
socket could address this too.  I can help on fixing these issues
during the sprints.  It will be happy to work with Trent to try to fix
the problems.  I'm sure we can greatly improve the situation.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
[Guido]
> > That's a rather long thread. Was any conclusion reached? I'm not sure
> > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > Can you or Christian describe the proposed approach in more detail?

> As far as I can see, no objections were raised in that thread.

Hm. I had wanted to register a complaint, but I guess I was too busy.

> Christian explained the probable approach:
> http://mail.python.org/pipermail/python-dev/2008-March/077362.html

That's not much of a plan. It doesn't discuss any of the effects of
the proposed change on merging code from the 2.6 trunk to the py3k
branch.

On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>  > -1. This will make merging code from 2.6 harder, and causes more work
>  > for porting C extensions.
>
>  I'm happy to pay the price for the sake of a clean and easy-to-recall C
>  API.
>
>  The for the C extension problem I already proposed a solution in the
>  thread Benjamin mentioned before.
>
>  #include "Python.h"
>  #if PY_VERSION_HEX > 0x0300
>   #include "python2_compat.h"
>  #endif
>
>  Where python2_compat provides aliases for PyInt and PyString:
>
>  #define PyInt_Spam PyLong_Spam
>  ...
>  #define PyString_Egg PyBytes_Egg

So this doesn't address merges at all. Suppose we have some C code
that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
the gzip codec). It currently uses PyString on both branches, so any
changes to the trunk merge smoothly into the py3k branch. But if you
change PyString -> PyBytes in the py3k branch, every change you make
in the 2.6 code will cause a merge conflict. Is that really what you
want? I worry that it will effectively separate the trunk and the py3k
branch, losing the advantage of doing development that effects both at
once.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > That's a rather long thread. Was any conclusion reached? I'm not sure
> > > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > > Can you or Christian describe the proposed approach in more detail?
>
> > As far as I can see, no objections were raised in that thread.
>
> Hm. I had wanted to register a complaint, but I guess I was too busy.
>
> > Christian explained the probable approach:
> > http://mail.python.org/pipermail/python-dev/2008-March/077362.html
>
> That's not much of a plan. It doesn't discuss any of the effects of
> the proposed change on merging code from the 2.6 trunk to the py3k
> branch.
>
> On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> > Guido van Rossum wrote:
> >  > -1. This will make merging code from 2.6 harder, and causes more work
> >  > for porting C extensions.
> >
> >  I'm happy to pay the price for the sake of a clean and easy-to-recall C
> >  API.
> >
> >  The for the C extension problem I already proposed a solution in the
> >  thread Benjamin mentioned before.
> >
> >  #include "Python.h"
> >  #if PY_VERSION_HEX > 0x0300
> >   #include "python2_compat.h"
> >  #endif
> >
> >  Where python2_compat provides aliases for PyInt and PyString:
> >
> >  #define PyInt_Spam PyLong_Spam
> >  ...
> >  #define PyString_Egg PyBytes_Egg
>
> So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But if you
> change PyString -> PyBytes in the py3k branch, every change you make
> in the 2.6 code will cause a merge conflict. Is that really what you
> want? I worry that it will effectively separate the trunk and the py3k
> branch, losing the advantage of doing development that effects both at
> once.

We could backport the python2_compact header.

>
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Travis Oliphant]

Guido van Rossum wrote:
> Moving this to a new subject to keep the discussion of tasks and the
> discussion of task tracking tools separate.
> 
> On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>>  I did a quick brainstorming with me, myself and I. I came up with a list
>>  of (IMHO) important tasks.
>>
>>  * Stabilize the C API of Python 3.0. I like to rename several prefixes
>>  to reduce the confusing: PyBytes -> PyByteArray,
> 
> +1 (also +1 to backporting this to 2.6)
> 
>> PyString -> PyBytes ...
> 
> -1. This will make merging code from 2.6 harder, and causes more work
> for porting C extensions.
> 
>>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
>>  and he said he is trying to get it done during the PyCon sprint. Maybe
>>  somebody can assist him?
> 
> Does he need assistance?

I don't really need help with back-porting the protocol.   However, I do 
need help with the struct module changes.  This is a standard-library 
that I'm hoping to get help with.

-Travis


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Christian Heimes]

Guido van Rossum wrote:
 > So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But if you
> change PyString -> PyBytes in the py3k branch, every change you make
> in the 2.6 code will cause a merge conflict. Is that really what you
> want? I worry that it will effectively separate the trunk and the py3k
> branch, losing the advantage of doing development that effects both at
> once.

I'm fully aware of the extra burden. The removal of the PyInt_*
functions is already causing merge conflicts and compile errors. Nearly
every C code merge contains at least one place that requires manual
intervention. The PyInt merge conflicts are trivial to fix - so would
errors caused PyString -> PyBytes rename.

I'm not worried about the extra work since it's usually trivial and fast
to fix. I'm more worried about the API names. Do you *really* want to
drag down dead bodies along the road for the next ten years? The dead
bodies are going to rot and stink sooner than later. By Python 3.2
everybody surely regrets the confusing names. ;)

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 1:01 PM, Benjamin Peterson <
[EMAIL PROTECTED]> wrote:

>
>
> On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
> > On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> > <[EMAIL PROTECTED]> wrote:
> > [Guido]
> > > > That's a rather long thread. Was any conclusion reached? I'm not
> > sure
> > > > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > > > Can you or Christian describe the proposed approach in more detail?
> >
> > > As far as I can see, no objections were raised in that thread.
> >
> > Hm. I had wanted to register a complaint, but I guess I was too busy.
> >
> > > Christian explained the probable approach:
> > > http://mail.python.org/pipermail/python-dev/2008-March/077362.html
> >
> > That's not much of a plan. It doesn't discuss any of the effects of
> > the proposed change on merging code from the 2.6 trunk to the py3k
> > branch.
> >
> > On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <[EMAIL PROTECTED]>
> > wrote:
> > > Guido van Rossum wrote:
> > >  > -1. This will make merging code from 2.6 harder, and causes more
> > work
> > >  > for porting C extensions.
> > >
> > >  I'm happy to pay the price for the sake of a clean and easy-to-recall
> > C
> > >  API.
> > >
> > >  The for the C extension problem I already proposed a solution in the
> > >  thread Benjamin mentioned before.
> > >
> > >  #include "Python.h"
> > >  #if PY_VERSION_HEX > 0x0300
> > >   #include "python2_compat.h"
> > >  #endif
> > >
> > >  Where python2_compat provides aliases for PyInt and PyString:
> > >
> > >  #define PyInt_Spam PyLong_Spam
> > >  ...
> > >  #define PyString_Egg PyBytes_Egg
> >
> > So this doesn't address merges at all. Suppose we have some C code
> > that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> > the gzip codec). It currently uses PyString on both branches, so any
> > changes to the trunk merge smoothly into the py3k branch. But if you
> > change PyString -> PyBytes in the py3k branch, every change you make
> > in the 2.6 code will cause a merge conflict. Is that really what you
> > want? I worry that it will effectively separate the trunk and the py3k
> > branch, losing the advantage of doing development that effects both at
> > once.
>
> We could backport the python2_compact header.
>
Sorry, that needs some explanation. We could do the opposite that we do for
Py3K: Add a header file aliasing PyBytes to PyString.

>
>
> >
> > --
> > --Guido van Rossum (home page: 
> > http://www.python.org/~guido/
> > )
> >
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Christian Heimes]

Benjamin Peterson wrote:
> It's just depends on how you see the tracker. It's not just to "bug" tracker
> anymore, is it? On other projects I've worked with, we had separate areas
> for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
> keep organized. However, if this is Python's way, I'm not going to stand in
> it.

Despite the url bugs.python.org it's an issue tracker and not a bug
tracker. We track patches, feature requests, ideas and bugs in the same
tracker.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

On Sun, Mar 16, 2008 at 1:04 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>   > So this doesn't address merges at all. Suppose we have some C code
>  > that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
>  > the gzip codec). It currently uses PyString on both branches, so any
>  > changes to the trunk merge smoothly into the py3k branch. But if you
>  > change PyString -> PyBytes in the py3k branch, every change you make
>  > in the 2.6 code will cause a merge conflict. Is that really what you
>  > want? I worry that it will effectively separate the trunk and the py3k
>  > branch, losing the advantage of doing development that effects both at
>  > once.
>
>  I'm fully aware of the extra burden. The removal of the PyInt_*
>  functions is already causing merge conflicts and compile errors.

Even though the more popular PyInt_ APIs are still available (even if
only as macros).

>  Nearly every C code merge contains at least one place that requires manual
>  intervention. The PyInt merge conflicts are trivial to fix - so would
>  errors caused PyString -> PyBytes rename.

I disagree. Bad merges are already a frequent cause of instability in
3.0. This could easily double the problems. And while I want to reduce
the instability (I really wish you would no commit until all unittests
pass), I also don't want the merges to cost more of your time!

>  I'm not worried about the extra work since it's usually trivial and fast
>  to fix. I'm more worried about the API names. Do you *really* want to
>  drag down dead bodies along the road for the next ten years? The dead
>  bodies are going to rot and stink sooner than later. By Python 3.2
>  everybody surely regrets the confusing names. ;)

It doesn't have to be so black and white. Using the macro approach you
propose we can fix the situation at any time later.

We could also make the changes in 2.6, so that the 2.6 code looks the
same as 3.0. (However for binary compatibility I think it would be
better if in 2.6 the linker sees PyString where in 3.0 it sees
PyBytes.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Collin Winter]

On Sun, Mar 16, 2008 at 10:17 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
>  > The biggest win in terms of performance would be to reimplement the
>  > pattern matching engine used by the fixers.: it by far dominates the
>  > running time, taking 99+% of the runtime when I ran 2to3 over Twisted,
>  > for example. The current design is a heavily-recursive system, and as
>  > such bombs out when it encounters, e.g., files with a thousand
>  > assignment statements in a row. I'd also like something more
>  > expressive: the current DSL can't express recursive patterns.
>
>  Do you have time to mentor a GSoC project? Or can you mentor a mentor
>  ...? :)

I think I'd have time to mentor a GSoC project. Let's talk off-list about that.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Gregory P. Smith]

On 3/16/08, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Moving this to a new subject to keep the discussion of tasks and the
> > discussion of task tracking tools separate.
> >
> > On Sun, Mar 16, 2008 at 9:42 AM, Christian Heimes <[EMAIL PROTECTED]>
> wrote:
> >>  I did a quick brainstorming with me, myself and I. I came up with a
> list
> >>  of (IMHO) important tasks.
> >>
> >>  * Stabilize the C API of Python 3.0. I like to rename several prefixes
> >>  to reduce the confusing: PyBytes -> PyByteArray,
> >
> > +1 (also +1 to backporting this to 2.6)
> >
> >> PyString -> PyBytes ...
> >
> > -1. This will make merging code from 2.6 harder, and causes more work
> > for porting C extensions.
> >
> >>  * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday
> >>  and he said he is trying to get it done during the PyCon sprint. Maybe
> >>  somebody can assist him?
> >
> > Does he need assistance?
>
>
> I don't really need help with back-porting the protocol.   However, I do
> need help with the struct module changes.  This is a standard-library
> that I'm hoping to get help with.
>
> -Travis


I'm happy to help with this stuff during the sprint.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

I don't see a lot of objections left against using the bug tracker. I
just talked to Neal and he's going to transfer all tasks from the 2.6
spreadsheet to the bug tracker.

I'll also be adding various other tasks., as I think of them.

We'll have to think about which keywords to use. We'll probably pick
the initial set of keywords at the sprint tomorrow morning.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Guido van Rossum]

On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>  I mentioned this to Guido and got a positive response, so let me state
>  my preference for your feedback.  I plan on holding up the final
>  releases until both versions are ready to go.  I think this will help
>  motivate us to give Python 2.6 the love it needs if it's lagging
>  behind 3.0, and I completely agree with Guido that this let's our
>  community know that both versions are equally important to us.

It's a deal.

>  The other thing is that I'd really like is a "show stoppers" Roundup
>  search.  The idea is that if our core buildbots look good and the
>  "show stoppers" search turns up no items, then I know I can cut a
>  release (at least for alphas, betas, and rcs).  If there are "show
>  stoppers" then I have something that I can triage (and maybe re-assign
>  severity) or start publicly harassing people into fixing.

How about using the "critical" Severity for show stoppers?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management

[Gregory P. Smith]

On 3/16/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I don't see a lot of objections left against using the bug tracker. I
> just talked to Neal and he's going to transfer all tasks from the 2.6
> spreadsheet to the bug tracker.
>
> I'll also be adding various other tasks., as I think of them.


yay, thanks Neal!

We'll have to think about which keywords to use. We'll probably pick
> the initial set of keywords at the sprint tomorrow morning.
>
> --
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
> ___
> Python-3000 mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Mark Dickinson]

On Sun, Mar 16, 2008 at 1:32 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> I think this is possible, though considerable work.  Probably the
> biggest win will be creating a mock for socket and using mock sockets
> in the tests for asyn{core,chat}, smtplib, xmlrpc, etc. That will fix
> about 75% of the problems on 2.6.  The remaining problems are:
>
>  * test_asyn{chat,core} might not be meaningful with mock sockets and are 
> flaky
>  * the alpha fails test_signal/socket for weird alarm conditions.
> this might be hard to debug/fix (I have access to this box though)
>  * test_sqlite is broken on x86 with an old sqlite (I have access to this box)
>  * test_bsddb may be flaky, I'm not sure
>  * probably a few platform specific problems
>

test_tokenize is also currently (sometimes) failing on many of the bots.
I've been looking into it, but I'm struggling to find the problem.  The
traceback e.g. for the amd64 gentoo buildbot ends with

 File "/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py",
line 1081, in decode
 output = self.decoder.decode(input, final=final)
 File "/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/codecs.py",
line 291, in decode
 (result, consumed) = self._buffer_decode(data, self.errors, final)
 UnicodeDecodeError: 'utf8' codec can't decode bytes in position
12-15: invalid data

On my own machine (SuSE 9.3/i686) I'm seeing this test pass about 80%
of the time and fail the other 20% with something like the above,
the position of the reported invalid data changing from run to run.  It
looks like data are getting corrupted somewhere along the line.

Anyone have any ideas?

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management

[Stephen J. Turnbull]

Benjamin Peterson writes:

 > It's just depends on how you see the tracker. It's not just to "bug" tracker
 > anymore, is it? On other projects I've worked with, we had separate areas
 > for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to
 > keep organized. However, if this is Python's way, I'm not going to stand in
 > it.

You (as an ordinary user) can have it both ways in the same instance.

If Martin adds a "task" issue type (which is easy to do in Roundup),
then you personally can create and save queries for "task", "bug",
"feature", etc.  Your view of the database will then be more like
sourceforge.

On the other hand, cross-referencing and creating dependencies across
issue types becomes a lot easier if they're in the same database.
That's important for some issues.

 > > > We could change the statuses around to "Work in progress", "Completed",
 > > > "Incomplete", and such. It'd be easy to search for tasks that have to be
 > > > accomplished for a given release.

I've done this for XEmacs's tracker.  It's definitely feasible.  I'm
subscribed to tracker-discuss, so I'll not go into detail here.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Neal Norwitz]

On Sun, Mar 16, 2008 at 5:13 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 1:32 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>  >
>
> > I think this is possible, though considerable work.  Probably the
>  > biggest win will be creating a mock for socket and using mock sockets
>  > in the tests for asyn{core,chat}, smtplib, xmlrpc, etc. That will fix
>  > about 75% of the problems on 2.6.  The remaining problems are:
>  >
>  >  * test_asyn{chat,core} might not be meaningful with mock sockets and are 
> flaky
>  >  * the alpha fails test_signal/socket for weird alarm conditions.
>  > this might be hard to debug/fix (I have access to this box though)
>  >  * test_sqlite is broken on x86 with an old sqlite (I have access to this 
> box)
>  >  * test_bsddb may be flaky, I'm not sure
>  >  * probably a few platform specific problems
>  >
>
>
> test_tokenize is also currently (sometimes) failing on many of the bots.
>  I've been looking into it, but I'm struggling to find the problem.  The
>  traceback e.g. for the amd64 gentoo buildbot ends with
>
>   File "/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py",
>  line 1081, in decode
>   output = self.decoder.decode(input, final=final)
>   File "/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/codecs.py",
>  line 291, in decode
>   (result, consumed) = self._buffer_decode(data, self.errors, final)
>   UnicodeDecodeError: 'utf8' codec can't decode bytes in position
>  12-15: invalid data
>
>  On my own machine (SuSE 9.3/i686) I'm seeing this test pass about 80%
>  of the time and fail the other 20% with something like the above,
>  the position of the reported invalid data changing from run to run.  It
>  looks like data are getting corrupted somewhere along the line.
>
>  Anyone have any ideas?

Yeah, sounds like a memory issue.  Did you try running with valgrind
or purify?  I haven't done so for a long time, perhaps never on 3k
branch.  It would be a good thing to run a tool soon.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 365 (Adding the pkg_resources module)

[Guido van Rossum]

Phillip asked me to give an opinion on his pkg_resources PEP. While
the PEP is short and sweet, the pkg_resources module itself is huge
(1800 non-blank lines; 16 classes plus 5 exceptions; it exports 67
names in total according to __all__). And pkg_resources.txt is another
1700 lines of documentation. I find that hard to swallow. Is there
anyone besides Phillip who can claim he understands this module?

If its inclusion is really meant just as a bootstrap to simplify
installing other package management solutions, as the PEP claims, I
would prefer to see something with a much smaller footprint. Surely
there is no need for example to have support for C extensions inside
zip files *as part of the bootstrap module*?

Unless I find someone besides Phillip who is interested in having this
included and is willing to help maintain it, I don't really think it
would be wise to accept this into the standard library.

Phillip, in the PEP you mention that there are several other package
management tools that also like to use pkg_resources. Maybe you can
get some folks from those tools to speak up and explain what
pkg_resources means to them, and maybe even volunteer to co-own it
once it's in the standard library?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Trent Nelson]

Yeah test_tokenize is weird, I've been looking into it as well.  Here's a 
sample failure from a Windows buildbot:

File "S:\buildbots\python\3.0.nelson-windows\build\lib\test\test_tokenize.py", 
line ?, in test.test_tokenize.__test__.doctests
Failed example:
for testfile in testfiles:
if not roundtrip(open(testfile)): break
else: True
Exception raised:
Traceback (most recent call last):
  File "S:\buildbots\python\3.0.nelson-windows\build\lib\doctest.py", line 
1227, in __run
compileflags, 1), test.globs)
  File "", line 2, in 

if not roundtrip(open(testfile)): break
  File "", line 3, in 
roundtrip
token_list = list(generate_tokens(f.readline))
  File "S:\buildbots\python\3.0.nelson-windows\build\lib\tokenize.py", line 
264, in generate_tokens
line = readline()
  File "S:\buildbots\python\3.0.nelson-windows\build\lib\io.py", line 1467, 
in readline
readahead, pending = self._read_chunk()
  File "S:\buildbots\python\3.0.nelson-windows\build\lib\io.py", line 1278, 
in _read_chunk
pending = self._decoder.decode(readahead, not readahead)
  File "S:\buildbots\python\3.0.nelson-windows\build\lib\io.py", line 1081, 
in decode
output = self.decoder.decode(input, final=final)
  File 
"S:\buildbots\python\3.0.nelson-windows\build\lib\encodings\cp1252.py", line 
23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 17: 
character maps to 

The following is at the end of the doctests in test_tokenize:

>>> tempdir = os.path.dirname(f) or os.curdir
>>> testfiles = glob.glob(os.path.join(tempdir, "test*.py"))
>>> if not test_support.is_resource_enabled("compiler"):
... testfiles = random.sample(testfiles, 10)
...
>>> for testfile in testfiles:
... if not roundtrip(open(testfile)): break
... else: True
True

On that first line, 'f' is lib/test/tokenize_tests.txt, so basically, it's 
grabbing ten random test*.py files in lib/test and running 
untokenize(generate_tokens(f.readline)) on each one.  In order to figure out 
which file it's dying on, I added the following to test_tokenize.py:

def test_tokenize_all():
import glob
import os
tempdir = os.path.dirname(__file__) or os.curdir
testfiles = glob.glob(os.path.join(tempdir, "test*.py"))
for file in testfiles:
print("processing file: " + file)
print("roundtrip(open(file)): " + roundtrip(open(file)))

This results in different results:
Python 3.0a3+ (py3k, Mar 16 2008, 10:41:45) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import test_tokenize
[50808 refs]
>>> test_tokenize.test_tokenize_all()
processing file: 
s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\test\testcodec.py
Traceback (most recent call last):
  File "", line 1, in 
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\test\test_tokenize.py",
 line 565, in test_tokenize_all
print("roundtrip(open(file)): " + roundtrip(open(file)))
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\test\test_tokenize.py",
 line 514, in roundtrip
source = untokenize(generate_tokens(f.readline))
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\tokenize.py", line 
238, in untokenize
return ut.untokenize(iterable)
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\tokenize.py", line 
183, in untokenize
self.add_whitespace(start)
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\tokenize.py", line 
172, in add_whitespace
assert row <= self.prev_row
AssertionError
[52668 refs]

Yay.  And to make this even more interesting:
s:\src\svn\svn.python.org\projects\python\branches\py3k\PCbuild>python_d 
..\Lib\test\test_tokenize.py
doctest (test.test_tokenize) ... 62 tests with zero failures
[61919 refs]

Oh, and while we're here:
s:\src\svn\svn.python.org\projects\python\branches\py3k\PCbuild>python_d 
..\lib\test\regrtest.py -q -uall -rw test_tokenize
**
File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\test\test_tokenize.py",
 line ?, in test.test_tokenize.__test__.doc
tests
Failed example:
for testfile in testfiles:
if not roundtrip(open(testfile)): break
else: True
Exception raised:
Traceback (most recent call last):
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\doctest.py", line 
1227, in __run
compileflags, 1), test.globs)
  File "", line 2, in 

if not roundtrip(open(testfile)): break
  File "", line 3, in 
roundtrip
token_list = list(generate_tokens(f.readline))
  File 
"s:\src\svn\svn.python.org\projects\python\branches\py3k\lib\tokenize.py", line 
264, in generate_tokens
  

Re: [Python-Dev] 2.6 and 3.0 project management

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 16, 2008, at 3:56 PM, Guido van Rossum wrote:

> On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <[EMAIL PROTECTED]>  
> wrote:
>> I mentioned this to Guido and got a positive response, so let me  
>> state
>> my preference for your feedback.  I plan on holding up the final
>> releases until both versions are ready to go.  I think this will help
>> motivate us to give Python 2.6 the love it needs if it's lagging
>> behind 3.0, and I completely agree with Guido that this let's our
>> community know that both versions are equally important to us.
>
> It's a deal.

Excellent.

>> The other thing is that I'd really like is a "show stoppers" Roundup
>> search.  The idea is that if our core buildbots look good and the
>> "show stoppers" search turns up no items, then I know I can cut a
>> release (at least for alphas, betas, and rcs).  If there are "show
>> stoppers" then I have something that I can triage (and maybe re- 
>> assign
>> severity) or start publicly harassing people into fixing.
>
> How about using the "critical" Severity for show stoppers?

'critical' is fine (or 'immediate').  My problem before was that I  
couldn't do one query that gave me all the critical issues for both  
2.6 and 3.0.  That certainly could have been pebkac though.  Neal  
mentioned that that kind of query should be possible, if it's not  
already there.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR92xb3EjvBPtnXfVAQLZGQP+O+FQwlXDXAT5lz+DKPer7+5n9ivy/YmD
94RYUnHEsVLA5aWpZB0O23/wVavS5FdUfJxuCvMOwHhZ6i58GHF4i6gfrtWDefX7
BWSfm82rIOAw/UX10JiUpkPp7vRlqfPdPOteqzFq0yo0vM49HOqFOL5fIU02MbRj
unVdo8uYJ5c=
=SB9I
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Mark Dickinson]

On Sun, Mar 16, 2008 at 7:19 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Yeah test_tokenize is weird, I've been looking into it as well.  Here's a 
> sample failure from a Windows buildbot:
> [failure log snipped...]
>  On that first line, 'f' is lib/test/tokenize_tests.txt, so basically, it's 
> grabbing ten random test*.py files in lib/test and running 
> untokenize(generate_tokens(f.readline)) on each one.  In order to figure out 
> which file it's dying on, I added the following to test_tokenize.py:

Aha.  This is very helpful!  It explains the randomness of the
failures, at least.
So it's probably not a C-level data corruption bug after all.
test_shlex seems to be one of the problem files.  Investigations are continuing.

Trent, thanks for your help!  I'll take further discussions off line and spare
python-dev the gory details...

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Phillip J. Eby]

Quick summary of the below: I'm definitely fine with doing a simpler, 
pure-bootstrap module, if there's some consensus on what should go in 
it.  I just wish we could've had this discussion last year, when OSAF 
was still able to fund the work...  ;-)


At 06:13 PM 3/16/2008 -0500, Guido van Rossum wrote:
>Phillip asked me to give an opinion on his pkg_resources PEP. While
>the PEP is short and sweet, the pkg_resources module itself is huge
>(1800 non-blank lines; 16 classes plus 5 exceptions; it exports 67
>names in total according to __all__). And pkg_resources.txt is another
>1700 lines of documentation. I find that hard to swallow. Is there
>anyone besides Phillip who can claim he understands this module?

Bob Ippolito actually wrote the very first version of 
pkg_resources.  Others, such as Philip Jenvey of the Jython project, 
have provided patches.  From previous discussions on the 
distutils-sig, I know that Jim Fulton has in-depth knowledge of both 
pkg_resources and easy_install.

Of course, that's not the same as any of these guys volunteering to 
be maintainers.  :)


>If its inclusion is really meant just as a bootstrap to simplify
>installing other package management solutions, as the PEP claims, I
>would prefer to see something with a much smaller footprint.

Actually, the PEP says:

"pkg_resources is a module used to find and manage Python 
package/version dependencies and access bundled files and resources, 
including those inside of zipped .egg files. Currently, pkg_resources 
is only available through installing the entire setuptools 
distribution, but it does not depend on any other part of setuptools; 
in effect, it comprises the entire runtime support library for Python 
Eggs, and is independently useful."

This kind of glosses over the part where this is also for runtime 
support of projects that use eggs.  Which, these days, is, well, 
almost any large Python project, from Chandler to Enthought to Zope.


>  Surely
>there is no need for example to have support for C extensions inside
>zip files *as part of the bootstrap module*?

It's a runtime; the PEP actually merely proposes that a further 
addition to be made to support bootstrapping, *also*.  Otherwise, the 
PEP would be even shorter.  :)

The reason I proposed it this way was for simplicity -- and politics.

Currently, people using setuptools in their setup.py have to include 
a similar bootstrap module to download setuptools if it's not 
available, and pkg_resources already has version checking logic and 
everything needed to find dependencies and download them.  (Plus, I 
figured it'd be easier to just use what was already there and stable, 
rather than creating something different.)

That was the simplicity part.  The politics part was that:

1. I thought it would be less controversial to include the "runtime 
for eggs" than to include something that's just a bootstrapper for 
setuptools.  However, MvL surprised me by actually being in *favor* 
of including a setuptools bootstrapper.

2. I thought that it would have broader acceptance if it was oriented 
towards bootstrapping *any* package, not just setuptools.

So, if the consensus is that it would be better to have a module that 
only does bootstrap installs of pure-Python eggs from PyPI, I'm 
totally fine with that.


>Unless I find someone besides Phillip who is interested in having this
>included and is willing to help maintain it, I don't really think it
>would be wise to accept this into the standard library.
>
>Phillip, in the PEP you mention that there are several other package
>management tools that also like to use pkg_resources. Maybe you can
>get some folks from those tools to speak up and explain what
>pkg_resources means to them, and maybe even volunteer to co-own it
>once it's in the standard library?

The distutils-sig is the de facto place for discussions regarding 
those tools, so I've cc'd this there.  Hopefully, one or more 
volunteers will step up if they want this.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Daniel Krech]

On Mar 16, 2008, at 8:06 PM, Phillip J. Eby wrote:

> Quick summary of the below: I'm definitely fine with doing a simpler,
> pure-bootstrap module, if there's some consensus on what should go in
> it.  I just wish we could've had this discussion last year, when OSAF
> was still able to fund the work...  ;-)
>
>
> At 06:13 PM 3/16/2008 -0500, Guido van Rossum wrote:
>> Phillip asked me to give an opinion on his pkg_resources PEP. While
>> the PEP is short and sweet, the pkg_resources module itself is huge
>> (1800 non-blank lines; 16 classes plus 5 exceptions; it exports 67
>> names in total according to __all__). And pkg_resources.txt is  
>> another
>> 1700 lines of documentation. I find that hard to swallow. Is there
>> anyone besides Phillip who can claim he understands this module?
>
> Bob Ippolito actually wrote the very first version of
> pkg_resources.  Others, such as Philip Jenvey of the Jython project,
> have provided patches.  From previous discussions on the
> distutils-sig, I know that Jim Fulton has in-depth knowledge of both
> pkg_resources and easy_install.
>
> Of course, that's not the same as any of these guys volunteering to
> be maintainers.  :)
>
>
>> If its inclusion is really meant just as a bootstrap to simplify
>> installing other package management solutions, as the PEP claims, I
>> would prefer to see something with a much smaller footprint.
>
> Actually, the PEP says:
>
> "pkg_resources is a module used to find and manage Python
> package/version dependencies and access bundled files and resources,
> including those inside of zipped .egg files. Currently, pkg_resources
> is only available through installing the entire setuptools
> distribution, but it does not depend on any other part of setuptools;
> in effect, it comprises the entire runtime support library for Python
> Eggs, and is independently useful."
>
> This kind of glosses over the part where this is also for runtime
> support of projects that use eggs.  Which, these days, is, well,
> almost any large Python project, from Chandler to Enthought to Zope.
>
>
>> Surely
>> there is no need for example to have support for C extensions inside
>> zip files *as part of the bootstrap module*?
>
> It's a runtime; the PEP actually merely proposes that a further
> addition to be made to support bootstrapping, *also*.  Otherwise, the
> PEP would be even shorter.  :)
>
> The reason I proposed it this way was for simplicity -- and politics.
>
> Currently, people using setuptools in their setup.py have to include
> a similar bootstrap module to download setuptools if it's not
> available, and pkg_resources already has version checking logic and
> everything needed to find dependencies and download them.  (Plus, I
> figured it'd be easier to just use what was already there and stable,
> rather than creating something different.)
>
> That was the simplicity part.  The politics part was that:
>
> 1. I thought it would be less controversial to include the "runtime
> for eggs" than to include something that's just a bootstrapper for
> setuptools.  However, MvL surprised me by actually being in *favor*
> of including a setuptools bootstrapper.
>
> 2. I thought that it would have broader acceptance if it was oriented
> towards bootstrapping *any* package, not just setuptools.
>
> So, if the consensus is that it would be better to have a module that
> only does bootstrap installs of pure-Python eggs from PyPI, I'm
> totally fine with that.
>
>
>> Unless I find someone besides Phillip who is interested in having  
>> this
>> included and is willing to help maintain it, I don't really think it
>> would be wise to accept this into the standard library.
>>
>> Phillip, in the PEP you mention that there are several other package
>> management tools that also like to use pkg_resources. Maybe you can
>> get some folks from those tools to speak up and explain what
>> pkg_resources means to them, and maybe even volunteer to co-own it
>> once it's in the standard library?
>
> The distutils-sig is the de facto place for discussions regarding
> those tools, so I've cc'd this there.  Hopefully, one or more
> volunteers will step up if they want this.

I'd like to see it in and am willing to help maintain it. Especially  
if it only does the bootstrap installs of pure-Python egg bit. I've  
dug into pkg_resource some, but can't claim to understand it all.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Martin v. Löwis]

> 'critical' is fine (or 'immediate').  My problem before was that I  
> couldn't do one query that gave me all the critical issues for both  
> 2.6 and 3.0.  That certainly could have been pebkac though.  Neal  
> mentioned that that kind of query should be possible, if it's not  
> already there.

I just created a "Showstoppers" public query (go to Your Queries/*edit*,
and set it to "leave in").

This *just* searches for critical open issues, all versions. Given
that there are currently really no critical issues, that semantically
is the same as further restricting it to 2.6 and 3.0.

Creating a query that searches for multiple versions is possible
through URL editing, but not the form (currently). I'm not sure
whether that would search for issues which are marked both 2.6
and 3.0, or for issues that are either marked 2.6 *or* 3.0.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[ocean]

> Yeah, sounds like a memory issue.  Did you try running with valgrind
> or purify?  I haven't done so for a long time, perhaps never on 3k
> branch.  It would be a good thing to run a tool soon.

Maybe is this related?

[Potential overflows due to incorrect usage of PyUnicode_AsString]
http://bugs.python.org/issue1950

Thank you.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Trent Nelson]

As it turns out, it's not memory related, but has to do with tokenize not 
supporting coding cookies in files.  Mark picked up on this and linked it to an 
issue already in roundup that was raised way back in 2003: 
http://bugs.python.org/issue71988.

I've just finished patching test_tokenizer.py to better represent this test 
case -- the current implementation doesn't lend itself very well to being 
debugged when things go wrong (I think Mark and I both felt like we were on a 
bit of a wild goose chase).  I've fixed that and have a bunch of text files 
with various utf-8/bom sig permutations that are now used to test tokenizer's 
compliance with PEP 0263.  I'll upload that now then move on to actually 
patching tokenizer.py.

Trent "wishes-there-was-somewhere-to-get-some-food-after-11pm-at-pycon" 
Nelson.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of ocean [EMAIL PROTECTED]
Sent: 17 March 2008 01:34
To: Neal Norwitz; Mark Dickinson
Cc: Python Dev
Subject: Re: [Python-Dev] 3.0 buildbots all red

> Yeah, sounds like a memory issue.  Did you try running with valgrind
> or purify?  I haven't done so for a long time, perhaps never on 3k
> branch.  It would be a good thing to run a tool soon.

Maybe is this related?

[Potential overflows due to incorrect usage of PyUnicode_AsString]
http://bugs.python.org/issue1950

Thank you.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.0 buildbots all red

[Trent Nelson]

> As it turns out, it's not memory related, but has to do with
> tokenize not supporting coding cookies in files.
> Mark picked up on this and linked it to an issue already
> in roundup that was raised way back in 2003:
> http://bugs.python.org/issue71988.

Oops, left off an 8.  That's meant to read http://bugs.python.org/issue719888.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com