> I can see how "svn resolved ." gets it right (now that I understand how
> the conflict is being produced and then fixed automatically by svnmerge,
> but not actually marked as resolved).
>
> I still don't understand how "svn revert ." can avoid losing the
> metadata changes unless svnmerge is to
Martin v. Löwis wrote:
> See above. You claim that doing things the way I recommend will lose
> metadata; I believe this claim is false.
I can see how "svn resolved ." gets it right (now that I understand how
the conflict is being produced and then fixed automatically by svnmerge,
but not actually
The O'Reilly Open Source Convention has opened up the Call For
Participation -- deadline for proposals is Tuesday Feb 3.
OSCON will be held July 20-24 in San Jose, California.
For more information, see
http://conferences.oreilly.com/oscon
http://en.oreilly.com/oscon2009/public/cfp/57
--
Aahz (a.
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou wrote:
..
> If one writes X = partial.skip, it looks quite nice:
>
> split_one = partial(str.split, X, 1)
Or even
_ = partial.skip
split_one = partial(str.split, _, 1)
___
Python-Dev mailing list
Python-D
> Serious question: does anybody know how to get better communication
> from the user base? My impression is that it's pretty hard to find out
> who is actually using 3.0, and get any feedback from them.
I think the bug tracker is a way in which users communicate with
developers. There have been 2
> (I believe that svnmerge actually does get that case right, but I
> haven't checked it extensively - since if it does get it right, I don't
> understand why it leaves the conflict in place instead of automatically
> marking it as resolved).
I think this is a plain bug. It invokes "svn merge", wh
Calvin Spealman gmail.com> writes:
>
> I am just replying to the end of this thread to throw in a reminder
> about my partial.skip patch, which allows the following usage:
>
> split_one = partial(str.split, partial.skip, 1)
>
> Not looking to say "mine is better", but if the idea is being given
>> Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
>> It's ok (Nick says it isn't exactly ok, but I don't understand why)
>
> Doing "svn revert ." before making the commit will lose the metadata
> changes that svnmerge uses for its bookkeeping (i.e. if this practice is
> used regul
I am just replying to the end of this thread to throw in a reminder
about my partial.skip patch, which allows the following usage:
split_one = partial(str.split, partial.skip, 1)
Not looking to say "mine is better", but if the idea is being given
merit, I like the skipping arguments method better
Paul Moore wrote:
Serious question: does anybody know how to get better communication
from the user base?
One of the nice things about Python is that the downloads are truly free
-- no required 'registration'. On the other hand, there is no option
to give feedback either.
If PSF/devs wan
Christopher Barker wrote:
I tried to post this to the bug tracker, but my attempt to create an
account failed -- do I need to be pre-approved or something?
No. If you do not get a response from the above, and a retry does not
work, you could email webmas...@python.org with details on what yo
On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote:
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas
wrote:
And yet, python isn't confined to mathematical notation. *, ** are
both overloaded for use in argument lists to no-one's peril, AFAICT.
Certainly, but there is no danger of confusion them
On Fri, Jan 30, 2009 at 12:07, Benjamin Peterson wrote:
> On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon wrote:
>> Great! Then should we start planning for 3.0.1 in terms of release
>> dates and what to have in the release so we can get this out the door
>> quickly?
>
> I think considering there's
On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon wrote:
> Great! Then should we start planning for 3.0.1 in terms of release
> dates and what to have in the release so we can get this out the door
> quickly?
I think considering there's only two release blockers we should plan
for about a week or two
On Fri, Jan 30, 2009 at 08:03, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote:
>
>>> 1. Barry, who is the release manager for 3.0.1, does not like the idea
>>> of the cruft that is being proposed removed from 3.0.1.
>>
Hi,
> [ Potential new "functools.partial_right", e.g.,
>
>split_comma = partial_right(str.split, '.')
> ]
Thanks for the feedback. Apologies if (as was suggested) this should
have gone to python-ideas; I thought as a fairly small extension to
existing functionality it would be OK here. I'l
s...@pobox.com wrote:
Christopher> 1) It would be nice if the gzip module (and the zip lib
Christopher>module) supported Universal newlines -- you could read a
Christopher>compressed text file with "wrong" newlines, and have
Christopher>them handled properly. However,
On Thu, Jan 29, 2009 at 8:25 PM, Raymond Hettinger wrote:
>
> [Guido van Rossum]
>>
>> Sorry, not convinced.
>
> No worries. Py3.1 is not far off.
>
> Just so I'm clear. Are you thinking that 3.0.x will never have
> fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
> external deploymen
s...@blueyonder.co.uk wrote:
Hi all,
On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote:
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version.
-1
For me, the main objection to a partial that places
its stored positional arguments
On Fri, 30 Jan 2009 18:06:48 +0100 (CET), Python tracker
wrote:
[snip]
Average duration of open issues: 697 days.
Median duration of open issues: 6 days.
It seems there's a bug in the summary tool. I thought it odd a few
weeks ago when I noticed the median duration of open issues was one
ACTIVITY SUMMARY (01/23/09 - 01/30/09)
Python 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.
2352 open (+54) / 14582 closed (+20) / 16934 total (+74)
Open issues with patches: 788
Average
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw wrote:
> To clarify: cruft that should have been removed 3.0 is fine to remove for
> 3.0.1, for some definition of "should have been".
Just to double check, can I take this as a green light to continue
with the cmp removal (http://bugs.python.org/issu
> Paul Moore wrote:
>
> Serious question: does anybody know how to get better communication
> from the user base? My impression is that it's pretty hard to find out
> who is actually using 3.0, and get any feedback from them. I suppose a
> general query on clp might get some feedback, but otherwi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote:
1. Barry, who is the release manager for 3.0.1, does not like the
idea
of the cruft that is being proposed removed from 3.0.1.
I don't think he actually said that (in fact, I think he said the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 10:59 PM, Brett Cannon wrote:
1. Barry, who is the release manager for 3.0.1, does not like the idea
of the cruft that is being proposed removed from 3.0.1. Personally I
say we continue to peer pressure him as I think a new major
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 8:34 PM, Stephen J. Turnbull wrote:
I think that the important question is "can the 3.0.x series be made
'viable' in less than the time frame for 3.1?" If not, I really have
to think it's DOA from the point of view of folks who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 7:43 PM, Raymond Hettinger wrote:
We should have insisted that bsddb not be taken out until a
replacement
was put in. The process was broken with the RM insisting on feature
freeze early in the game but letting tools like bsd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:40 PM, Guido van Rossum wrote:
On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger
wrote:
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after feature freeze), the bsddb code
was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 6:27 PM, Raymond Hettinger wrote:
The problem is that the obvious candidate for doing the vetting is
the
Release Manager, and Barry doesn't like this approach. The vetting
does
need to be handled by a core committer IMO -- MA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 5:09 PM, Aahz wrote:
The problem is that the obvious candidate for doing the vetting is the
Release Manager, and Barry doesn't like this approach. The vetting
does
need to be handled by a core committer IMO -- MAL, are you
v
Hi all,
> On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote:
>> Hi,
>>
>> I find 'functools.partial' useful, but occasionally I'm unable to use it
>> because it lacks a 'from the right' version.
>
-1
For me, the main objection to a partial that places
its stored positional arguments from the rig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2009, at 1:13 PM, Guido van Rossum wrote:
I'd like to find a middle ground. We can all agree that the users of
3.0 are a small minority compared to the 2.x users. Therefore I think
we can bend the rules more than we have done for the rece
Paul Moore wrote:
> [...]
> In all honesty, I think pkgutil.simplegeneric should be documented,
> exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
> [...]
Servus,
Walter
___
Python-Dev mailing list
Python-De
2009/1/30 Walter Dörwald :
> Paul Moore wrote:
>
>> [...]
>> In all honesty, I think pkgutil.simplegeneric should be documented,
>> exposed, and moved to a library of its own[1].
>
> http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that. I assume that the barrier to getting this
in
2009/1/30 Steve Holden :
> Most consistently missing from this picture has been effective
> communications (in both directions) with the user base.
Serious question: does anybody know how to get better communication
from the user base? My impression is that it's pretty hard to find out
who is actu
Christopher> 1) It would be nice if the gzip module (and the zip lib
Christopher>module) supported Universal newlines -- you could read a
Christopher>compressed text file with "wrong" newlines, and have
Christopher>them handled properly. However, that may be hard to do,
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> Doing "svn resolved ." assumes that you did everything else correctly,
>> and even then I don't see how svnmerge could both backport the py3k
>> changes to the metadata and make its own changes and still get the
>> metadata to a sane state
Nick Coghlan gmail.com> writes:
>
> Doing "svn resolved ." assumes that you did everything else correctly,
> and even then I don't see how svnmerge could both backport the py3k
> changes to the metadata and make its own changes and still get the
> metadata to a sane state.
The metadata are discr
Martin v. Löwis wrote:
>> There are potential problems with doing it that way [1]. The safer
>> option is to do:
>>
>> svn revert .
>> svnmerge merge -M -F
>
> I still don't see the potential problem. If you do svnmerge, svn commit,
> all is fine, right?
Sort of. svnmerge still gets confused by
Steven D'Aprano wrote:
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would
be no need for the pprint module.
On Fri, 30 Jan 2009 07:03:03 -0500, Steve Holden
wrote:
> Antoine Pitrou wrote:
>> Raymond Hettinger rcn.com> writes:
>>> * If you're thinking that shelves have very few users and that
>>> 3.0.0 has had few adopters, doesn't that mitigate the effects
>>> of making a better format available in
Martin v. Löwis wrote:
>> svn up
>> svnmerge
>> ... conflicts
>> svn revert -R .
>> svn up
>> svnmerge
>> ... same conflicts
>
> Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
> It's ok (Nick says it isn't exactly ok, but I don't understand why)
Doing "svn revert ." before making
2009/1/30 Steven D'Aprano :
>> But that's beside the
>>
>> point, I don't like __pprint__ in any event. Too special.
>
> I'm not sure what you mean by "too special". It's no more special than any
> other special method. Do you mean the use-case is not common enough? I would
> find this useful. Whet
Antoine Pitrou wrote:
> Raymond Hettinger rcn.com> writes:
>> * If you're thinking that shelves have very few users and that
>> 3.0.0 has had few adopters, doesn't that mitigate the effects
>> of making a better format available in 3.0.1? Wouldn't this
>> be the time to do it?
>
> There wa
On 2009-01-30 11:40, Antoine Pitrou wrote:
> Aahz pythoncraft.com> writes:
>> There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
>> You're probably right that what Raymond wants to is best not done for
>> 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
>> pr
Hi Neal,
The last post in the thread was:
http://mail.python.org/pipermail/python-dev/1999-August/000793.html
referencing a download at
http://sirac.inrialpes.fr/~marangoz/python/lineno/
Cheers,
Andrew
This e-mail is confidential and may be privileged. It may be read, copied and
used only by
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I w
Aahz pythoncraft.com> writes:
>
> There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
> You're probably right that what Raymond wants to is best not done for
> 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
> production release of Python for PEP6 purposes,
48 matches
Mail list logo
