Benjamin Peterson schrieb:
svnmerge is written in Python, so wouldn't it be possible to add
support for maintaining such renaming to that tool ?
svnmerge.py is mostly a wrapper over svn merge, and svn merge can't
handle it, so I don't think is easily possible.
I don't think that an administr
On Mon, May 19, 2008 at 12:26 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemburg
On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemb
On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
d
On 2008-05-19 21:26, Brett Cannon wrote:
It is possible to make pickle aware of the module renames, but
that doesn't solve problems with other forms of serialization
or use of the .__module__ attribute in general.
Why can't we just provide a "from __future__ import renamed_modules"
which then pr
On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
d
On Mon, May 19, 2008 at 9:22 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> Nick writes:
M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to
On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Nick writes:
>>>
>>> M.-A. Lemburg wrote:
>>> > I don't think that an administrative problem such as forward-
>>> > porting patches to 3.x warrants breakage in the 2.x branch.
>>> >
>>> > After all, the renaming was ap
On Mon, May 19, 2008 at 2:08 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Why can't we just provide a "from __future__ import renamed_modules"
> which then provides all the new name to old name mappings in
> some form (e.g. module proxies or whatever) and leave the
> existing modules in 2.x untou
Nick writes:
M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.
>
> After all, the renaming was approached for Python 3.0 and not
> 2.6 *because* it introduces major breakage.
>
> AFAIR, the discussion
Nick writes:
> M.-A. Lemburg wrote:
> > I don't think that an administrative problem such as forward-
> > porting patches to 3.x warrants breakage in the 2.x branch.
> >
> > After all, the renaming was approached for Python 3.0 and not
> > 2.6 *because* it introduces major breakage.
> >
> > AFAIR,
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| M.-A. Lemburg wrote:
| > I don't think that an administrative problem such as forward-
| > porting patches to 3.x warrants breakage in the 2.x branch.
| >
| > After all, the renaming was approached for Python 3.0 and not
M.-A. Lemburg wrote:
I don't think that an administrative problem such as forward-
porting patches to 3.x warrants breakage in the 2.x branch.
After all, the renaming was approached for Python 3.0 and not
2.6 *because* it introduces major breakage.
AFAIR, the discussion on the stdlib-sig also d
On 2008-05-18 22:24, Brett Cannon wrote:
On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
doing the renaming in the 2.x branch, but it appears that
the only reason is to get used to the new na
On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>>
>> Perhaps I have a misunderstanding of the reasoning behind
>> doing the renaming in the 2.x branch, but it appears that
>> the only reason is to get used to the new names. That's a
>> rather low pri
M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
doing the renaming in the 2.x branch, but it appears that
the only reason is to get used to the new names. That's a
rather low priority argument in comparison to the breakage
the renaming will cause in the 2.x branch.
On 2008-05-17 16:59, Alexandre Vassalotti wrote:
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
I'd like to bring a potential problem to attention that is caused
by the recent module renaming approach:
Object serialization protocols like e.g. pickle usually store the
On 10:22 pm, [EMAIL PROTECTED] wrote:
When I brought this up earlier, various people assured
me that it wasn't a problem in practice. I think we're
seeing one situation here where it *is* a problem.
Just my two cents here - experience has taught me that it's definitely a
problem in practice.
Alexandre Vassalotti wrote:
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.
The opposite problem exists for Python 3.0, too.
This is
On Sat, May 17, 2008 at 7:59 AM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> Another solution would be to write a 2to3 pickle converter using the
> pickletools module. It is surely not the most elegant or robust
> solution, but I could work.
This could be done even for 2.x <--> 2.6 to be tr
Errata:
On Sat, May 17, 2008 at 10:59 AM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> And, one solution to this is to use Python 2.6 to regenerate pickle
> stream.
... to regenerate *the* pickle *streams*.
> It is surely not the most elegant or robust solution, but I could work.
... but
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'd like to bring a potential problem to attention that is caused
> by the recent module renaming approach:
>
> Object serialization protocols like e.g. pickle usually store the
> complete module path to the object class to
I'd like to bring a potential problem to attention that is caused
by the recent module renaming approach:
Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.
They access this module path by looking at the __module__
23 matches
Mail list logo