Skip Montanaro wrote:
> Why not just skip the specifics except to say < 80 characters for all
> lines? Don't mention 72, 79 or any other number than 80:
I often run "svn diff" in a console limited to 80 characters.
Because of the leading "+", lines longer than 78 wrap, and the output
is more dif
And this is then compounded if you then proceed to diff those diff outputs.
Maybe we should just use vertical spacing?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Amaury Forgeot d'Arc
> Sent: Friday, February 22, 2008 08:01
> To: Skip Montanaro
Vladimir Marangozov wrote:
> May I chime in? :-)
Please do!
> Gents, the current implementation of Python's memory management
> is really fine and most problems it used to have in the past
> have been fixed in recent years (at least the ones I know of).
>
> Probably the only one left, indeed, is
Gregory P. Smith wrote:
> I'm always faced with a tiny quandry when closing a fixed bug that had a
> patch to fix it attached because both seem to apply. ;-)
I try to use 'fixed' for those, with my closure comment indicating
whether the fix used the attached patch (or a variant thereof) or
som
2008/2/21, Brett Cannon <[EMAIL PROTECTED]>:
> Something like "handle" or "resolved". An issue is an issue and we
> wanting a single way to say the issue was closed because what is was
> about was handled seems reasonable.
+1 to resolved.
--
.Facundo
Blog: http://www.taniquetil.com.ar/pl
2008/2/21, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> It's possible to "retire" objects in Roundup: certain resolution values
> would still be present and referenced by issues that use it, but they
> would not appear anymore in the drop-down list.
We can go one step further: If we change "fixed"
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Combining 'fixed' and 'accepted' into something generic like 'resolved'
> is no good, since 'not a bug' is also a resolution from our point of
> view, even if the original author of the issue may not particularly like
> the answer :)
First two de
Facundo Batista wrote:
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
It only tells you that a resolution was reached, not what that
resolution was.
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Now, dropping 'later', 'postponed' and 'remind' from the list of
> available resolutions is something I could wholeheartedly support. If we
> want to postpone something to a later release, we should put an
> appropriate entry in the version list.
Hello,
I have prepared a request for enhancement for distutils, together with its
patch that also adds more tests for the package.
This was discussed in catalog-sig, and explained here :
http://wiki.python.org/moin/EnhancedPyPI (see pypirc section). I have
followed Brett Cannon's slides to make
Nick Coghlan schrieb:
> Facundo Batista wrote:
>> First two definitions of "resolve" from the American Heritage dict:
>>
>> 1. To make a firm decision about.
>> 2. To cause (a person) to reach a decision.
>>
>> I think it applies quite well.
>
> It only tells you that a resolution was reache
>> Why not just skip the specifics except to say < 80 characters for all
>> lines? Don't mention 72, 79 or any other number than 80:
Amaury> I often run "svn diff" in a console limited to 80 characters.
Amaury> Because of the leading "+", lines longer than 78 wrap, and the
Am
On Fri, Feb 22, 2008 at 10:12:16AM -0600, [EMAIL PROTECTED] wrote:
> I use "svn
> annotate" from time-to-time which adds an even wider margin to the left.
> In those situations I either grin and bear it or stretch my window enough to
> view it without wrapping.
svn blame | less -S
Oleg.
--
On Thu, Feb 21, 2008 at 6:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Eric Smith]
>
> > Speaking for myself, these features are generally useful,
> > and are so even without the new integer literal syntax.
>
> I'm curious how these are useful to you in Py2.6 where
> they are not inver
On Fri, Feb 22, 2008, Andrew MacIntyre wrote:
> Vladimir Marangozov wrote:
>>
>> And, of course, if the int/float freelist scheme was a real issue
>> we would have probably heard of it by now in a very sound way.
>
> Not much noise has been made here, but I've come across 2 separate
> complaints
On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote:
>
>
> >> Why not just skip the specifics except to say < 80 characters for all
> >> lines? Don't mention 72, 79 or any other number than 80:
>
> Amaury> I often run "svn diff" in a console limited to 80 characters.
> Amaury> Because
On Fri, Feb 22, 2008 at 8:20 AM, Aahz <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote:
> >
> >
> > >> Why not just skip the specifics except to say < 80 characters for
> all
> > >> lines? Don't mention 72, 79 or any other number than 80:
> >
> > Amaury
[GvR]
>. After
> all we already have lots of places where Python 2.x supports an old
> and a new way (e.g. string exceptions up to 2.5, classic classes, old
> and rich comparisons).
I thought the whole point of 3.0 was a recognition that all that
doubling-up was a bad thing and to be rid of it.
ACTIVITY SUMMARY (02/15/08 - 02/22/08)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1732 open (+27) / 12258 closed (+11) / 13990 total (+38)
Open issues with patches: 456
Average durati
On Fri, Feb 22, 2008 at 4:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
># Feature request resolutions
>accepted - feature request accepted (possibly via attached patch)
>rejected - feature request rejected
Can we make the names a little longer? "feature accepted" and
"feature reject
On Fri, Feb 22, 2008 at 9:06 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
>
> >. After
> > all we already have lots of places where Python 2.x supports an old
> > and a new way (e.g. string exceptions up to 2.5, classic classes, old
> > and rich comparisons).
>
> I thought the whole
Raymond Hettinger wrote:
> [GvR]
>> . After
>> all we already have lots of places where Python 2.x supports an old
>> and a new way (e.g. string exceptions up to 2.5, classic classes, old
>> and rich comparisons).
>
> I thought the whole point of 3.0 was a recognition that all that
> doubling-up
On 2/16/08, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> * New float methods: is_finite, is_inf, is_integer and is_nan.
Just a question... is_integer or is_integral?
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo T
> And, of course, if the int/float freelist scheme was a real issue
> we would have probably heard of it by now in a very sound way.
As Aahz says: people run into this problem frequently, and then report it.
Regards,
Martin
___
Python-Dev mailing list
P
> We can go one step further: If we change "fixed" and "accepted" as
> "resolved" (for example), we can change all the values directly in the
> database, so they all appear as "resolved" now.
>
> I don't want to propose anything specific regarding words, I'm just
> saying that having eleven option
Raymond Hettinger wrote:
> I thought the whole point of 3.0 was a recognition that all that
> doubling-up was a bad thing and to be rid of it. Why make the
> situation worse? ISTM that we need two versions of oct() like
> we need a hole in the head. Heck, there's potentially a case to be
> made
> Can we make the names a little longer?
Somebody really needs to take lead here. I won't change
anything unless somebody tells me precisely what to do,
so I can blame somebody. Messages like this (which I
picked just arbitrarily) I will ignore wrt. specific
action. Of course I *can* make the name
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
That's why the entire field is called "Resolution". "duplicate",
"invalid", "out of date", "wont fix" a
This message has been popping up in the buildbot mails for several days:
> Conflict detected in commontex/boilerplate.tex. Doc build skipped.
I have no idea what it means. I don't see it within the core distribution.
Can someone take a look at this?
Skip
___
Robert Brewer wrote:
> Raymond Hettinger wrote:
>> I thought the whole point of 3.0 was a recognition that all that
>> doubling-up was a bad thing and to be rid of it. Why make the
>> situation worse? ISTM that we need two versions of oct() like
>> we need a hole in the head. Heck, there's poten
[EMAIL PROTECTED] schrieb:
> This message has been popping up in the buildbot mails for several days:
>
> > Conflict detected in commontex/boilerplate.tex. Doc build skipped.
>
> I have no idea what it means. I don't see it within the core distribution.
> Can someone take a look at this?
N
Guido van Rossum wrote:
> I wonder if, in order to change the behavior of various built-in
> functions, it wouldn't be easier to be able to write
>
> from future_builtins import oct, hex # and who knows what else
This makes sense to me, especially if we have a 2to3 fixer which removes
this line
Raymond Hettinger wrote:
> ISTM that we need two versions of oct() like
> we need a hole in the head.
I don't know about oct(), but I found hex() to be quite useful
the other day when I was using the interactive interpreter to
to some hex calculations. It would have been quite tedious
having to sa
I provided a patch for adding TLS support to ftplib:
http://bugs.python.org/issue2054
Bill, could you please take a look at it?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
It's on my list.
Bill
___
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
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (FINAL).
This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and p
> On behalf of the Python development team and the Python community, I'm
> happy to announce the release of Python 2.5.2 (FINAL).
As a bug day is upcoming, I'm now thawing the 2.5 branch.
2.5.3 should be released in ca. 6 month, or shortly after
2.6 final (whatever happens earlier); if it follows
Eric Smith wrote:
> Robert Brewer wrote:
> > Raymond Hettinger wrote:
> >> I thought the whole point of 3.0 was a recognition that all that
> >> doubling-up was a bad thing and to be rid of it. Why make the
> >> situation worse? ISTM that we need two versions of oct() like
> >> we need a hole in
On Fri, Feb 22, 2008 at 10:01 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Can we make the names a little longer?
>
> Somebody really needs to take lead here. I won't change
> anything unless somebody tells me precisely what to do,
> so I can blame somebody. Messages like this (which I
>
Greg Ewing <[EMAIL PROTECTED]> writes:
> I don't know about oct(), but I found hex() to be quite useful
> the other day when I was using the interactive interpreter to
> to some hex calculations. It would have been quite tedious
> having to say "%x".format(_) or some such all the time to
> see the
On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.
Are we, as a development commu
On Fri, Feb 22, 2008 at 1:21 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/2/22, Brett Cannon <[EMAIL PROTECTED]>:
>
>
> > I think Martin is right that someone needs to take the lead and do a
> > complete review of how issues are handled. That way we can do a change
> > in one big batc
On Fri, Feb 22, 2008 at 1:28 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
> > I think Martin is right that someone needs to take the lead and do a
> > complete review of how issues are handled. That way we can do a change
> > in one
Robert Brewer wrote:
> Eric Smith wrote:
>> Robert Brewer wrote:
>>> Postgres bytea coercion is a frequent use case for oct() in my
> world.
>>> But I agree we don't need two versions.
>> Unless you're trying to write code to work with both 2.6 and 3.0.
>
> Who would try that when PEP 3000 says (i
2008/2/22, Brett Cannon <[EMAIL PROTECTED]>:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.
+1
What about a couple of hours in the Pyth
I've uncovered what seems to me to a problem with python Unicode
string objects passed to extension modules. Or perhaps it's revealing
a misunderstanding on my part :-) So I would like to get some
clarification.
Extension modules written in C receive strings from python via the
PyArg_ParseTuple fa
"Martin v. Löwis" writes:
> That's why the entire field is called "Resolution". "duplicate",
> "invalid", "out of date", "wont fix" and "works for me" are also
> firm decisions.
>
> ("later", "postponed", and "remind" might not be firm decisions -
> they were just inherited from SF).
These
On Fri, Feb 22, 2008 at 11:15 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
>
> > This message has been popping up in the buildbot mails for several days:
> >
> > > Conflict detected in commontex/boilerplate.tex. Doc build skipped.
> >
> > I have no idea what it
> I've uncovered what seems to me to a problem with python Unicode
> string objects passed to extension modules. Or perhaps it's revealing
> a misunderstanding on my part :-) So I would like to get some
> clarification.
It seems to me that there is indeed one or more misunderstandings
on your part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've volunteered to be the release manager for Python 2.6 and 3.0.
It's been several years since I've RM'd a Python release, and I'm
happy to do it again (he says while the medication is still
working :). I would like to get the n
On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote:
> Python programs which use Unicode string objects for their i18n and
> which "link" to C libraries expecting UTF-8 but which have a CPython
> binding which only uses 's' or 's#' formats programs seem to often
> fail with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 22, 2008, at 11:28 AM, Guido van Rossum wrote:
> On Fri, Feb 22, 2008 at 8:20 AM, Aahz <[EMAIL PROTECTED]> wrote:
>> On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote:
>>>
>>>
> Why not just skip the specifics except to say < 80 characters
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 22, 2008, at 11:20 AM, Aahz wrote:
> On Fri, Feb 22, 2008, [EMAIL PROTECTED] wrote:
>>
>>
Why not just skip the specifics except to say < 80 characters for
all
lines? Don't mention 72, 79 or any other number than 80:
>>
>>
On 2008-02-23 00:46, Colin Walters wrote:
> On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote:
>
>> Python programs which use Unicode string objects for their i18n and
>> which "link" to C libraries expecting UTF-8 but which have a CPython
>> binding which only uses 's' or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 21, 2008, at 12:30 PM, Guido van Rossum wrote:
> On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <[EMAIL PROTECTED]>
> wrote:
>> Why should docstrings and comments be limited to 72 characters when
>> code is limited to 79 characters? I ask bec
On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everyone,
>
> I've volunteered to be the release manager for Python 2.6 and 3.0.
> It's been several years since I've RM'd a Python release, and I'm
> happy to do i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
> Barry Warsaw wrote:
>
>> Why should docstrings and comments be limited to 72 characters when
>> code is limited to 79 characters? I ask because there is an ongoing
>> debate at my company about this.
>
[Barry]
> I'd also like for us to consider doing regular monthly releases.
+1
___
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%40
Colin Walters wrote:
> On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <[EMAIL PROTECTED]> wrote:
>
>> Python programs which use Unicode string objects for their i18n and
>> which "link" to C libraries expecting UTF-8 but which have a CPython
>> binding which only uses 's' or 's#' formats programs
A.M. Kuchling wrote:
> Are we, as a development community, really running into problems with
> how we handle bugs? There are certainly small cleanups possible, such
> as dropping the 'postponed' and 'later' resolutions that we don't seem
> to use very much, but the flow seems reasonably efficient
On Fri, Feb 22, 2008 at 4:55 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
I don't think so. I think it's a sign of healthy software. Now, i
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
>
>> Barry Warsaw wrote:
>>
>>> Why should docstrings and comments be limited to 72 characters when
>>> code is limited to 79 characters? I ask because there is an ongoing
>>
On Sat, Feb 23, 2008 at 01:55:06AM +0100, Christian Heimes wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
Sure, but is that because the bug life cycle is sub-optimal, or
because we d
With the PyCon sprint approaching I would like all attendees to be
signed up on the wiki page for the sprint:
http://wiki.python.org/moin/PyCon2008/SprintSignups/Python . I am
going to be using that list to send out an email about what is exactly
expected of people in terms of setup ahead of time,
I've attached a proposed revision of PEP 3 below. Feedback would be
appreciated, and once we have a reasonable consensus that it accurately
describes our current processes I can check it in and Martin can update
the tracker to reflect any changes.
It is intentional that the current non-resolut
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| *invalid*
| the reported bug was either not described clearly enough to be
reproduced,
| or is actually the intended behaviour
|
| *works for me*
| the reported bug could not be replicated by the developers
This str
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
As a historical record: people said the same thing when there were 500
and 1000 open issues. 5 years from now, when we have 5000 open issues,
> One question I did have is whether or not access to 'security' type
> issues is automatically limited to a small subset of the developers.
No. Reports requiring privacy should be sent to [EMAIL PROTECTED]
Regards,
Martin
___
Python-Dev mailing list
P
Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | *invalid*
> | the reported bug was either not described clearly enough to be
> reproduced,
> | or is actually the intended behaviour
> |
> | *works for me*
> | the reported bug could not be re
69 matches
Mail list logo
