> 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 rea
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 t
> 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
> '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.
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 w
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 Rossu
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
>
-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
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:
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 documentati
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 socke
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
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%
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 the
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
> motivat
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
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
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
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 o
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 Py
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 thr
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
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
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 me
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 de
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 h
-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
-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 m
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,
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
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 b
>>> 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/onlin
>>> * 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/TE
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 no
> 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
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
> 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 u
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 triage
>> 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 16, 2008, at 10:48 AM, Martin v. Lwis 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 month
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.
>
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 cate
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
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 b
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)
> sugg
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 man
> > 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.)
(FWI
> 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/lis
> > * 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/TEX
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 her
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
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.
>
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.
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
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-
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
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 coul
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 sav
[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 thin
60 matches
Mail list logo
