Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> What is the hope of an EOL extension which meets our requirements coming
> directly out of the hg community?  If that hope is small, where does
> that leave us?

As before. I'll repost my request for help, and we stay with subversion
meanwhile.

Perhaps I'll post it to some mercurial list as well.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Paul Moore 
2009/9/5 "Martin v. Löwis" :
>> What is the hope of an EOL extension which meets our requirements coming
>> directly out of the hg community?  If that hope is small, where does
>> that leave us?
>
> As before. I'll repost my request for help, and we stay with subversion
> meanwhile.
>
> Perhaps I'll post it to some mercurial list as well.

Can anyone (re-) post the specification of the proposed extension, to
the level that it is currently defined? I'm willing to make an attempt
to put together an extension, on the assumption that it'll be easier
to refine an implementation than continue discussing possibilities...

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Antoine Pitrou 
Mark Hammond  gmail.com> writes:
> 
> What is the hope of an EOL extension which meets our requirements coming 
> directly out of the hg community?  If that hope is small, where does 
> that leave us?

I'm starting to wonder what the problem really is that makes it so
Python-specific. If I understood correctly, it's about a couple of files which
must be stored using non-Unix line endings, right? (in the PC and PCbuild
directories?)

These files are hardly modified often and by many people (and even more rarely
by non-Windows people), so why not just put a verification hook on the server
and let the offending committer repair his mistake manually, if it ever happens?
(we can even provide a script to help repairing the EOL mistake, like
Tools/reindent.py does for indentation mistakes)


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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> I'm starting to wonder what the problem really is that makes it so
> Python-specific. If I understood correctly, it's about a couple of files which
> must be stored using non-Unix line endings, right? (in the PC and PCbuild
> directories?)

No. It's about files that must, when checked out on Windows, have CRLF
endings, and, when checked out on Unix, have LF endings - i.e. all the
.py, .c, .h, and .rst files, plus a couple of others which don't require
specific treatment.

IOW, it's about the default behavior, and the majority of new files.

> These files are hardly modified often and by many people (and even more rarely
> by non-Windows people), so why not just put a verification hook on the server
> and let the offending committer repair his mistake manually, if it ever 
> happens?
> (we can even provide a script to help repairing the EOL mistake, like
> Tools/reindent.py does for indentation mistakes)

This was Dirkjan's original proposal, and it is the proposal that brings
so much heat into the discussion, claiming that it is a problem of
minorities (I do understand that you were unaware that "the problem"
is really with the many files, not with the few).

In addition, a DVCS brings in another problem dimension: when people
push their changes, they have *already* committed them - and perhaps not
even they, but a contributor from which they had been pulling changes.
The bogus change may have been weeks ago, so the subversion solution
(of rejecting the commit to happen) doesn't quite work that well for
a DVCS.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Antoine Pitrou 
Le samedi 05 septembre 2009 à 15:19 +0200, "Martin v. Löwis" a écrit :
> No. It's about files that must, when checked out on Windows, have CRLF
> endings, and, when checked out on Unix, have LF endings - i.e. all the
> ..py, .c, .h, and .rst files, plus a couple of others which don't require
> specific treatment.
> 
> IOW, it's about the default behavior, and the majority of new files.

Ok, sorry for the misunderstanding and the lost bandwidth.

> In addition, a DVCS brings in another problem dimension: when people
> push their changes, they have *already* committed them - and perhaps not
> even they, but a contributor from which they had been pulling changes.
> The bogus change may have been weeks ago, so the subversion solution
> (of rejecting the commit to happen) doesn't quite work that well for
> a DVCS.

I don't think this problem is really serious.
If the push fails, you can just commit (locally) a new changeset that
repairs the EOL or indentation problems, and push the whole bunch of
changesets again (I assume the server-side hook will not examine
changesets individually, but only the last of them?).


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

[Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-05 Thread Martin v. Löwis 
> Can anyone (re-) post the specification of the proposed extension, to
> the level that it is currently defined?

For reference, here are the original specification, mine and Martin
Geisler's:

http://mail.python.org/pipermail/python-dev/2009-August/090984.html
http://mail.python.org/pipermail/python-dev/2009-August/091453.html

Here is my attempt at summarizing it:

- name of versioned configuration file (in root of tree): .hgeol
- names of conversion modes: native, LF, CRLF
In the configuration file, there is a section [patterns] which
maps file name patterns to conversion modes, e.g.

[patterns]
**.txt = native
**.py = native
**.dsp = CRLF
**.bat = CRLF
Tools/bgen/README = native
Lib/email/test/data/msg_26.txt = CRLF

- Martin Geisler also proposes that there is a section
[repository]
native = 
I personally feel YAGNI; it should only support LF (adding such
a feature later may be considered)

Open issues:
- name of extension
- what should happen if the file on disk doesn't have the "expected"
line endings, or mixed line endings? E.g. a file declared as native
"should" have CRLF on Windows - what if it doesn't, on commit?
My proposal: do what svn does (whatever that is).

That's it, AFAICT. Martin Geisler also discussed something that
I read as an implementation strategy, by mapping the patterns to
into the (apparently existing) encode/decode configuration setting.

HTH,
Martin

P.S. If you decide that you will or will not work on it, please let
us know.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Stephen J. Turnbull 
Antoine Pitrou writes:

 > > In addition, a DVCS brings in another problem dimension: when people
 > > push their changes, they have *already* committed them - and perhaps not
 > > even they, but a contributor from which they had been pulling changes.
 > > The bogus change may have been weeks ago, so the subversion solution
 > > (of rejecting the commit to happen) doesn't quite work that well for
 > > a DVCS.

git has a nice filter-branch command, which would allow you to
automatically repair the problem (it works basically by checking out
each changeset and rerecording it with the appropriate commands).  I
know bzr is growing something similar, so presumably it is or will
soon be available in hg.

 > I don't think this problem is really serious.
 > If the push fails, you can just commit (locally) a new changeset that
 > repairs the EOL or indentation problems, and push the whole bunch of
 > changesets again (I assume the server-side hook will not examine
 > changesets individually, but only the last of them?).

That's not a very good solution.  Especially with typical Mercurial
workflows[1], it's quite possible that you'll have a number of bogus
changesets interleaved with good one.  I don't think recording a
repair is satisfactory.

Footnotes: 
[1]  Note that DVCS means you do *not* have to follow Python workflows
in your private branches.


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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Terry Reedy 

Martin v. Löwis wrote:

I'm starting to wonder what the problem really is that makes it so
Python-specific. If I understood correctly, it's about a couple of files which
must be stored using non-Unix line endings, right? (in the PC and PCbuild
directories?)


No. It's about files that must, when checked out on Windows, have CRLF
endings, and, when checked out on Unix, have LF endings - i.e. all the
.py, .c, .h, and .rst files, plus a couple of others which don't require
specific treatment.

IOW, it's about the default behavior, and the majority of new files.


FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad 
requires /r/n, but do IDLE and other editors (on Windows) that people 
would actually use to create/edit such files? I would personally be 
willing to install a notepad replacement if needed to quickview such files.


If essentially all text files need fixed line endings on Windows, then 
hg really needs this built in. Has it really not been used much on Windows?


tjr

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin Geisler 
Antoine Pitrou  writes:

> Le samedi 05 septembre 2009 à 15:19 +0200, "Martin v. Löwis" a écrit :
>
>> In addition, a DVCS brings in another problem dimension: when people
>> push their changes, they have *already* committed them - and perhaps
>> not even they, but a contributor from which they had been pulling
>> changes. The bogus change may have been weeks ago, so the subversion
>> solution (of rejecting the commit to happen) doesn't quite work that
>> well for a DVCS.
>
> I don't think this problem is really serious. If the push fails, you
> can just commit (locally) a new changeset that repairs the EOL or
> indentation problems, and push the whole bunch of changesets again (I
> assume the server-side hook will not examine changesets individually,
> but only the last of them?).

Yes, the server-side hook will have to work like this in order for
people to fix mistakes like you just described.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgpJVx1LcPK63.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Antoine Pitrou 
Terry Reedy  udel.edu> writes:
> 
> If essentially all text files need fixed line endings on Windows, then 
> hg really needs this built in. Has it really not been used much on Windows?

Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox developers are Windows-based). I wonder
whether they have written their own extension, or if they simply rely on their
text editors to do the right thing.



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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin (gzlist) 
On 05/09/2009, Antoine Pitrou  wrote:
> Terry Reedy  udel.edu> writes:
>>
>> If essentially all text files need fixed line endings on Windows, then
>> hg really needs this built in. Has it really not been used much on
>> Windows?
>
> Mercurial is used by e.g. Mozilla, which is not really known for poor
> Windows
> support (chances are many Firefox developers are Windows-based). I wonder
> whether they have written their own extension, or if they simply rely on
> their
> text editors to do the right thing.

Actually, most Firefox developers are mac based.

Mozilla isn't a great example of windows integration, they install
half-a-unix-system in order to just build under windows, including
msys, python 2.5, mercurial, and xemacs. See:


Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Dirkjan Ochtman 

On 05/09/2009 17:09, Antoine Pitrou wrote:

Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox developers are Windows-based). I wonder
whether they have written their own extension, or if they simply rely on their
text editors to do the right thing.


I'm pretty sure they don't have a specific extension for it. I don't 
know if many of their developers use the win32text extension, but I 
would guess not (I have been somewhat involved in Mozilla's migration).


Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Dirkjan Ochtman 

On 05/09/2009 16:59, Stephen J. Turnbull wrote:

git has a nice filter-branch command, which would allow you to
automatically repair the problem (it works basically by checking out
each changeset and rerecording it with the appropriate commands).  I
know bzr is growing something similar, so presumably it is or will
soon be available in hg.


That means you change hashes on the server side, without human feedback. 
Let's try not to subvert the immutability design that Mercurial tries to 
encourage.


Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> I don't think this problem is really serious.
> If the push fails, you can just commit (locally) a new changeset that
> repairs the EOL or indentation problems

I would find that unfortunate. It's a fairly irrelevant change, yet
it may manage to corrupt the history (hg blame).

> and push the whole bunch of
> changesets again (I assume the server-side hook will not examine
> changesets individually, but only the last of them?).

That is for us to decide. I can see arguments either way.

But it shouldn't happen often that the server refuses a push;
all errors should already be caught on the clients.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
>> I don't think this problem is really serious. If the push fails, you
>> can just commit (locally) a new changeset that repairs the EOL or
>> indentation problems, and push the whole bunch of changesets again (I
>> assume the server-side hook will not examine changesets individually,
>> but only the last of them?).
> 
> Yes, the server-side hook will have to work like this in order for
> people to fix mistakes like you just described.

Not necessarily. People could also be required to go back and replay
all changes.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Dirkjan Ochtman 
On Sat, Sep 5, 2009 at 18:18, "Martin v. Löwis" wrote:
> But it shouldn't happen often that the server refuses a push;
> all errors should already be caught on the clients.

We could just mandate the same hook code as a commit hook.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad
> requires /r/n, but do IDLE and other editors (on Windows) that people
> would actually use to create/edit such files? I would personally be
> willing to install a notepad replacement if needed to quickview such files.

Visual Studio will create files with CRLF endings. Please don't talk
people out of using Visual Studio for development. More generally:
please accept that it is consensus that this *has* to be fixed, and
that it *is* a problem on Windows.

> If essentially all text files need fixed line endings on Windows, then
> hg really needs this built in. Has it really not been used much on Windows?

I think that's the case. It's pretty much a Unix-only tool, like most of
the other DVCS implementations.

FWIW, I tried to check out Mozilla (which is in hg), and the check out
would always abort with a timeout. Then I downloaded a bundle that they
had produced, and try to unbundle it. It took all night, but was
complete the other morning. Trying to update the checkout would again
make me run into http timeouts. I tried the same on Linux, and it
completed within a few minutes. So I conclude that, from a certain
project size on, hg is unusable on Windows, atleast on my office
machine, running Windows 7.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
>> But it shouldn't happen often that the server refuses a push;
>> all errors should already be caught on the clients.
> 
> We could just mandate the same hook code as a commit hook.

I would be in favor (although, IIUC, "mandate" here would be a
social thing, not a technical one).

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Dirkjan Ochtman 

On 05/09/2009 18:28, "Martin v. Löwis" wrote:

I would be in favor (although, IIUC, "mandate" here would be a
social thing, not a technical one).


Right, but that would be the same for the extension.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Georg Brandl 
Martin v. Löwis schrieb:
>> I don't think this problem is really serious.
>> If the push fails, you can just commit (locally) a new changeset that
>> repairs the EOL or indentation problems
> 
> I would find that unfortunate. It's a fairly irrelevant change, yet
> it may manage to corrupt the history (hg blame).

I'm for a per-changeset check as well.  In the common case, the client will
have the "required" extension, and errors will be caught there.

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Dirkjan Ochtman 
On Sat, Sep 5, 2009 at 18:25, "Martin v. Löwis" wrote:
> I think that's the case. It's pretty much a Unix-only tool, like most of
> the other DVCS implementations.

I know a lot of projects use Mercurial on Windows as well, I'm not
aware of any big problems with it.

> FWIW, I tried to check out Mozilla (which is in hg), and the check out
> would always abort with a timeout. Then I downloaded a bundle that they
> had produced, and try to unbundle it. It took all night, but was
> complete the other morning. Trying to update the checkout would again
> make me run into http timeouts. I tried the same on Linux, and it
> completed within a few minutes. So I conclude that, from a certain
> project size on, hg is unusable on Windows, atleast on my office
> machine, running Windows 7.

That sounds pretty bad. By check out, do you mean the clone (getting
data over the wire) or the actual check out (setting up a working
directory)? I think I've heard of problems with the clone part before,
for them. We're actually working on improving clone size, though it
also seems to have to do with network reliability.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Paul Moore 
2009/9/5 "Martin v. Löwis" :
>> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad
>> requires /r/n, but do IDLE and other editors (on Windows) that people
>> would actually use to create/edit such files? I would personally be
>> willing to install a notepad replacement if needed to quickview such files.
>
> Visual Studio will create files with CRLF endings. Please don't talk
> people out of using Visual Studio for development. More generally:
> please accept that it is consensus that this *has* to be fixed, and
> that it *is* a problem on Windows.

(Disclaimer: I have no problem with accepting that the extension is
needed - the following is for clarity, in particular to help me
understand how the hook will be used)

There are 2 separate questions - (1) what is held in the repository,
and (2) what is in the user's workspace. The two clearly interact.

Taking (2) first, there are *some* files (very few, I believe) that
require specific line endings (CRLF - Visual Studio build files, is my
understanding). There are also tools that require fixed line endings
for input (notepad, Visual Studio). Finally, tools create new files
with certain line endings by default (pretty much guaranteed to be
platform-native, I'd expect). The result is that user workspaces *may*
(quite probably, will) contain files with a mixture of line endings if
care is not taken.

As regards (1), I assume that for "text" files, a consistent EOL
convention (assumed LF) should be used in the repository. It's not
clear to me what should be held in the repo for the files requiring
specific line endings - my instinct is that they should be treated as
"binary" and stored in the repo with the mandated line endings, and
checked out unchanged.

So we have the following situation:

- Some "binary" files which should never be converted
- Some "text" files, which must be held in LF form in the repo

My view is that how I store text files in my workspace is entirely up
to me (and the capabilities of my tools). So, how files get checked
out should not be centrally mandated. (Hmm, that may complicate
matters). How files are checked in is crucial, so a setting is
required which ensures that each file so marked is converted to LF
format on checking - effectively working like universal newline mode.

So, the issues:

1. Given that the "problematic" tools (notepad and Visual Studio) are
Windows tools, we seem to be back to the idea that this extension is
only needed by Windows developers. As I understood the consensus to be
that the extension should be for all users, I suspect I've missed
something.
2. Allowing text files to be checked out in whatever form the user
prefers seems complicated. The alternative would likely be to say test
files are checked out in "native" form. That works, but would irritate
me as I work on Windows, but prefer strongly to use LF line endings
(yes, I realise that makes me an oddball...) I'd put up with it if it
was the consensus to do this, of course.
3. Is there a realistic possibility that a user could edit one of the
CRLF-requiring files with a tool that converts it to LF? If so, is
there a need to trap that programmatically (as opposed to simply
accepting that this equates to the individual accidentally breaking
the build, no worse or better than checking in a C file with a syntax
error)?

Is this a fair summary?

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> I know a lot of projects use Mercurial on Windows as well, I'm not
> aware of any big problems with it.

I trust that indeed, there are no big problems for most users. I
also trust that the hg developers are, in general, open to incorporating
improvements on Windows.

I'm still skeptical though whether Mercurial is really usable on
Windows. Your statement is a somewhat self-fulfilling prophecy:
people who run into big problems early likely aren't going to use
it. So lack of reports doesn't really mean there aren't any problems.

>> FWIW, I tried to check out Mozilla (which is in hg), and the check out
>> would always abort with a timeout. Then I downloaded a bundle that they
>> had produced, and try to unbundle it. It took all night, but was
>> complete the other morning. Trying to update the checkout would again
>> make me run into http timeouts. I tried the same on Linux, and it
>> completed within a few minutes. So I conclude that, from a certain
>> project size on, hg is unusable on Windows, atleast on my office
>> machine, running Windows 7.
> 
> That sounds pretty bad. By check out, do you mean the clone (getting
> data over the wire) or the actual check out (setting up a working
> directory)?

Creating the clone. ISTM that it leaves the http connection open while
doing stuff locally (or creates multiple of them, and one times out).

It starts cloning, and then, after an hour or so, it reports ABORT,
and rolls back, for no apparent reason.

> I think I've heard of problems with the clone part before,
> for them. We're actually working on improving clone size, though it
> also seems to have to do with network reliability.

Our institute has generally a really good internet connection;
I think hg.mozilla.org does as well. Plus, it worked when doing
it on the very same machine on Linux.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
> There are 2 separate questions - (1) what is held in the repository,
> and (2) what is in the user's workspace. The two clearly interact.
[...]
> As regards (1), I assume that for "text" files, a consistent EOL
> convention (assumed LF) should be used in the repository.

Correct. I believe Martin (the other one) proposed to make it
configurable. I agree that using LF in the repository is sensible.

Wrt. "should": there is the debate whether intermediate revisions
can deviate from that requirement.

> It's not
> clear to me what should be held in the repo for the files requiring
> specific line endings - my instinct is that they should be treated as
> "binary" and stored in the repo with the mandated line endings, and
> checked out unchanged.

I would say so, yes. One consequence of that is that if you change
your mind in hgeols, you need to commit all files that now fail to
conform. This is what happens with svn, and it may be tricky to
implement as you need to commit files that didn't change on disk
(say you switch from native to CRLF on a Windows checkout).

OTOH, even if you do store all text files in LF in the repo, then
you would still have the problem for files that go from unspecified
eol-style to a specified one. So changing hgeols is tricky, period.

> - Some "binary" files which should never be converted
> - Some "text" files, which must be held in LF form in the repo
> 
> My view is that how I store text files in my workspace is entirely up
> to me (and the capabilities of my tools). So, how files get checked
> out should not be centrally mandated.

Not by technical means, no. In the developer FAQ, there will be clear
directions, and you better follow them - or need to accept the blame
if you made a mistake because you ignored them.

> So, the issues:
> 
> 1. Given that the "problematic" tools (notepad and Visual Studio) are
> Windows tools, we seem to be back to the idea that this extension is
> only needed by Windows developers. As I understood the consensus to be
> that the extension should be for all users, I suspect I've missed
> something.

Technically, yes, it is only needed on Windows. The desire to have
all users use them come from the wish that problems with the setup
will be detected earlier. E.g. if the extension stops working with
a new Mercurial version, and all users use them, there is a larger
motivation to fix them for all users.

Things that the extension can do for you on Unix:
- check that the syntax of .hgeols is correct; this may affect
  Unix users which try to edit it
- check that all text files have consistent line endings, and
  refuse checkin if they don't. This may become relevant if
  a Unix text editor tries to edit a CRLF file, and doesn't
  quite detect that.

> 2. Allowing text files to be checked out in whatever form the user
> prefers seems complicated. The alternative would likely be to say test
> files are checked out in "native" form. That works, but would irritate
> me as I work on Windows, but prefer strongly to use LF line endings
> (yes, I realise that makes me an oddball...) I'd put up with it if it
> was the consensus to do this, of course.

It's consensus, and it's also what subversion does, and CVS did.

> 3. Is there a realistic possibility that a user could edit one of the
> CRLF-requiring files with a tool that converts it to LF? If so, is
> there a need to trap that programmatically (as opposed to simply
> accepting that this equates to the individual accidentally breaking
> the build, no worse or better than checking in a C file with a syntax
> error)?

I think everything you can imagine is also realistic. For the
less-realistic cases, it may be better if the commit is refused rather
than silently fixing it, since the user operated the system in a
surprising way - so he may actually have meant to do it that way.

One specific case is recent autoconf, which put a CR character
into configure, completely breaking svn's eol handling.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin v. Löwis 
>> 2. Allowing text files to be checked out in whatever form the user
>> prefers seems complicated. The alternative would likely be to say test
>> files are checked out in "native" form. That works, but would irritate
>> me as I work on Windows, but prefer strongly to use LF line endings
>> (yes, I realise that makes me an oddball...) I'd put up with it if it
>> was the consensus to do this, of course.
> 
> It's consensus, and it's also what subversion does, and CVS did.

Following up to myself: you might want to make it a feature that
"native" is configurable, per user or per repo. It should default
to CRLF on Windows, but you might want to set it to LF on your
system. In that case, the extension would have just its checking
functionality.

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin (gzlist) 
On 05/09/2009, "Martin v. Löwis"  wrote:
>
> Creating the clone. ISTM that it leaves the http connection open while
> doing stuff locally (or creates multiple of them, and one times out).
>
> It starts cloning, and then, after an hour or so, it reports ABORT,
> and rolls back, for no apparent reason.

I have been tracking mozilla-central, and believe this is a problem
with the repo, that started some time after Aug 04 - which is the last
log entry I have in my clone. I presumed it was just a problem my end
so hadn't got round trying to debug it yet. If it
is a general problem, the fact it's been around for about a month
without being addressed might indicate how well tested most DVCSes are
under windows.

Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Martin Geisler 
"Martin v. Löwis"  writes:

>>> I don't think this problem is really serious. If the push fails, you
>>> can just commit (locally) a new changeset that repairs the EOL or
>>> indentation problems, and push the whole bunch of changesets again
>>> (I assume the server-side hook will not examine changesets
>>> individually, but only the last of them?).
>> 
>> Yes, the server-side hook will have to work like this in order for
>> people to fix mistakes like you just described.
>
> Not necessarily. People could also be required to go back and replay
> all changes.

Replaying changes, i.e., editing history is quite easy as long as you
have done no merges. So people can indeed fix their mistakes by cleaning
up history as long as they have a linear history. Both mq and histedit
are available for this:

  http://mercurial.selenic.com/wiki/MqExtension
  http://mercurial.selenic.com/wiki/HisteditExtension

The problem comes if a small group have been working together on a new
feature and have merged changes in from the mainline while doing so.
They will then no longer be able to edit past the most recent merge.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgpaLCBp1jBUE.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-05 Thread Brett Cannon 
On Sat, Sep 5, 2009 at 07:18, "Martin v. Löwis" wrote:
>> Can anyone (re-) post the specification of the proposed extension, to
>> the level that it is currently defined?
>
> For reference, here are the original specification, mine and Martin
> Geisler's:
>
> http://mail.python.org/pipermail/python-dev/2009-August/090984.html
> http://mail.python.org/pipermail/python-dev/2009-August/091453.html
>
> Here is my attempt at summarizing it:
>
> - name of versioned configuration file (in root of tree): .hgeol
> - names of conversion modes: native, LF, CRLF
> In the configuration file, there is a section [patterns] which
> maps file name patterns to conversion modes, e.g.
>
> [patterns]
> **.txt = native
> **.py = native
> **.dsp = CRLF
> **.bat = CRLF
> Tools/bgen/README = native
> Lib/email/test/data/msg_26.txt = CRLF
>
> - Martin Geisler also proposes that there is a section
> [repository]
> native = 
> I personally feel YAGNI; it should only support LF (adding such
> a feature later may be considered)

Do you mean what native is in the repo or what it should be considered
on the user's machine? If it's the former then I actually like it as
it means a clone doesn't need to do anything special when 'native'
matches what is expected in the repo while a commit still does its EOL
validation. I still think we need to have a server-side block which
rejects commits that messes up the line-endings so people can fix
them. Shouldn't mess up 'blame' as the messed up line-endings should
only be from their edits. Otherwise it's just like when Tim used to
run reindent.py over the entire repo on occasion.

And as mentioned in another email by Paul, it would be nice to let the
user specify what they want 'native' to be on their machine if they
happen to be a Windows user who prefers LF.

>
> Open issues:
> - name of extension

StupidLineEndings =)

> - what should happen if the file on disk doesn't have the "expected"
> line endings, or mixed line endings? E.g. a file declared as native
> "should" have CRLF on Windows - what if it doesn't, on commit?
> My proposal: do what svn does (whatever that is).

Or refuse the commit with a message and tell the user to fix it (if
svn doesn't happen to do that).

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

[Python-Dev] Problems with hex-conversion functions

2009-09-05 Thread Ender Wiggin 
Hello everyone.

I see several problems with the two hex-conversion function pairs that
Python offers:
1. binascii.hexlify and binascii.unhexlify
2. bytes.fromhex and bytes.hex

Problem #1:
bytes.hex is not implemented, although it was specified in PEP 358.
This means there is no symmetrical function to accompany bytes.fromhex.

Problem #2:
Both pairs perform the same function, although The Zen Of Python suggests
that
"There should be one-- and preferably only one --obvious way to do it."
I do not understand why PEP 358 specified the bytes function pair although
it mentioned the binascii pair...

Problem #3:
bytes.fromhex may receive spaces in the input string, although
binascii.unhexlify may not.
I see no good reason for these two functions to have different features.

Problem #4:
binascii.unhexlify may receive both input types: strings or bytes, whereas
bytes.fromhex raises an exception when given a bytes parameter.
Again there is no reason for these functions to be different.

Problem #5:
binascii.hexlify returns a bytes type - although ideally, converting to hex
should
always return string types and converting from hex should always return
bytes.
IMO there is no meaning of bytes as an output of hexlify, since the output
is a
representation of other bytes.
This is also the suggested behavior of bytes.hex in PEP 358


Problems #4 and #5 call for a decision about the input and output of the
functions being discussed:

Option A : Strict input and output
unhexlify (and bytes.fromhex) may only receives string and may only return
bytes
hexlify (and bytes.hex) may only receives bytes and may only return strings

Option B : Robust input and strict output
unhexlify (and bytes.fromhex) may receive bytes and strings and may only
return bytes
hexlify (and bytes.hex) may receive bytes or strings and may only return
strings

Of course we may also consider a third option, which will allow the return
type of
all functions to be robust (perhaps specified in a keyword argument), but as
I wrote in
the description of problem #5, I see no sense in that.

Note that PEP 3137 describes: "... the more strict definitions of encoding
and decoding in
Python 3000: encoding always takes a Unicode string and returns a bytes
sequence, and decoding
always takes a bytes sequence and returns a Unicode string." - suggesting
option A.

To repeat problems #4 and #5, the current behavior does not match any
option:
* The return type of binascii.hexlify should be string, and this is not the
current behavior.
As for the input:
* Option A is not the current behavior because binascii.unhexlify may
receive both input types.
* Option B is not the current behavior because bytes.fromhex does not allow
bytes as input.


To fix these issues, three changes should be applied:
1. Deprecate bytes.fromhex. This fixes the following problems:
   #4 (go with option B and remove the function that does not allow bytes
input)
   #2 (the binascii functions will be the only way to "do it")
   #1 (bytes.hex should not be implemented)
2. In order to keep the functionality that bytes.fromhex has over unhexlify,
   the latter function should be able to handle spaces in its input (fix #3)
3. binascii.hexlify should return string as its return type (fix #5)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-05 Thread Martin v. Löwis 
>> - Martin Geisler also proposes that there is a section
>> [repository]
>> native = 
>> I personally feel YAGNI; it should only support LF (adding such
>> a feature later may be considered)
> 
> Do you mean what native is in the repo or what it should be considered
> on the user's machine? 

The former.

> If it's the former then I actually like it as
> it means a clone doesn't need to do anything special when 'native'
> matches what is expected in the repo while a commit still does its EOL
> validation.

But the same would be true if the repo format would be always LF:
when "native" matches (which would then be on Unix), the extension
would *still* have to do nothing but validation.

> I still think we need to have a server-side block which
> rejects commits that messes up the line-endings so people can fix
> them.

Certainly.

> Shouldn't mess up 'blame' as the messed up line-endings should
> only be from their edits.

It could be that they had a number of commits that eventually lead
to the version that they push; this will also push the intermediate
versions. So when you then do a blame, it will tell you that the
revision was logged as "fix whitespace", rather than "resolve issue
#9743".

You are mostly right that the committer name would be the same
(except when the committer was pushing some changes pulled from
the actual contributor), however, I still see these whitespace-only
changes as a complication.

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

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-05 Thread Brett Cannon 
On Sat, Sep 5, 2009 at 15:06, "Martin v. Löwis" wrote:
>>> - Martin Geisler also proposes that there is a section
>>> [repository]
>>> native = 
>>> I personally feel YAGNI; it should only support LF (adding such
>>> a feature later may be considered)
>>
>> Do you mean what native is in the repo or what it should be considered
>> on the user's machine?
>
> The former.
>
>> If it's the former then I actually like it as
>> it means a clone doesn't need to do anything special when 'native'
>> matches what is expected in the repo while a commit still does its EOL
>> validation.
>
> But the same would be true if the repo format would be always LF:
> when "native" matches (which would then be on Unix), the extension
> would *still* have to do nothing but validation.

Right, but I am just thinking about how we specify in .hgeols what the
repository is expected to be as this extension might work out nicely
for other projects who prefer CLRF as their repo-native line ending.

>
>> I still think we need to have a server-side block which
>> rejects commits that messes up the line-endings so people can fix
>> them.
>
> Certainly.
>
>> Shouldn't mess up 'blame' as the messed up line-endings should
>> only be from their edits.
>
> It could be that they had a number of commits that eventually lead
> to the version that they push; this will also push the intermediate
> versions. So when you then do a blame, it will tell you that the
> revision was logged as "fix whitespace", rather than "resolve issue
> #9743".
>

Yep.

> You are mostly right that the committer name would be the same
> (except when the committer was pushing some changes pulled from
> the actual contributor), however, I still see these whitespace-only
> changes as a complication.

It's unfortunate, but I see it as a rare occurrence as it would only
happen if someone got sloppy. And it should typically get caught
client-side before the commit ever occurs, minimizing the
whitespace-only commits even more.

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

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

2009-09-05 Thread Martin v. Löwis 
> Right, but I am just thinking about how we specify in .hgeols what the
> repository is expected to be as this extension might work out nicely
> for other projects who prefer CLRF as their repo-native line ending.

This is what I refer to as YAGNI. Subversion has LF as the internal
storage, and, IIRC, so does CVS. I don't think there is any precedence
for wanting something else - and frankly, I can't see how repository
storage would matter.

>> You are mostly right that the committer name would be the same
>> (except when the committer was pushing some changes pulled from
>> the actual contributor), however, I still see these whitespace-only
>> changes as a complication.
> 
> It's unfortunate, but I see it as a rare occurrence as it would only
> happen if someone got sloppy. And it should typically get caught
> client-side before the commit ever occurs, minimizing the
> whitespace-only commits even more.

It would, of course, be possible to ban them altogether, at the expense
of users having to replay changes.

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

Re: [Python-Dev] Problems with hex-conversion functions

2009-09-05 Thread Brett Cannon 
On Sat, Sep 5, 2009 at 14:26, Ender Wiggin wrote:
> Hello everyone.
>
> I see several problems with the two hex-conversion function pairs that
> Python offers:
> 1. binascii.hexlify and binascii.unhexlify
> 2. bytes.fromhex and bytes.hex
>
> Problem #1:
> bytes.hex is not implemented, although it was specified in PEP 358.

Probably an oversight.

> This means there is no symmetrical function to accompany bytes.fromhex.
>
> Problem #2:
> Both pairs perform the same function, although The Zen Of Python suggests
> that
> "There should be one-- and preferably only one --obvious way to do it."
> I do not understand why PEP 358 specified the bytes function pair although
> it mentioned the binascii pair...
>

It's nicer to have this kind of functionality on the built-ins than in
the standard library. "Practicality beats purity".

> Problem #3:
> bytes.fromhex may receive spaces in the input string, although
> binascii.unhexlify may not.
> I see no good reason for these two functions to have different features.
>

Well, one allows for sloppy input while the other does not. Usually
accepting sloppy input but giving strict input is better.

> Problem #4:
> binascii.unhexlify may receive both input types: strings or bytes, whereas
> bytes.fromhex raises an exception when given a bytes parameter.
> Again there is no reason for these functions to be different.

Well, giving bytes back into bytes seems somewhat silly. That's an
error in mixing your strings and bytes.

>
> Problem #5:
> binascii.hexlify returns a bytes type - although ideally, converting to hex
> should
> always return string types and converting from hex should always return
> bytes.
> IMO there is no meaning of bytes as an output of hexlify, since the output
> is a
> representation of other bytes.
> This is also the suggested behavior of bytes.hex in PEP 358
>
> Problems #4 and #5 call for a decision about the input and output of the
> functions being discussed:
>
> Option A : Strict input and output
> unhexlify (and bytes.fromhex) may only receives string and may only return
> bytes
> hexlify (and bytes.hex) may only receives bytes and may only return strings
>
> Option B : Robust input and strict output
> unhexlify (and bytes.fromhex) may receive bytes and strings and may only
> return bytes
> hexlify (and bytes.hex) may receive bytes or strings and may only return
> strings
>
> Of course we may also consider a third option, which will allow the return
> type of
> all functions to be robust (perhaps specified in a keyword argument), but as
> I wrote in
> the description of problem #5, I see no sense in that.
>
> Note that PEP 3137 describes: "... the more strict definitions of encoding
> and decoding in
> Python 3000: encoding always takes a Unicode string and returns a bytes
> sequence, and decoding
> always takes a bytes sequence and returns a Unicode string." - suggesting
> option A.
>
> To repeat problems #4 and #5, the current behavior does not match any
> option:
> * The return type of binascii.hexlify should be string, and this is not the
> current behavior.
> As for the input:
> * Option A is not the current behavior because binascii.unhexlify may
> receive both input types.
> * Option B is not the current behavior because bytes.fromhex does not allow
> bytes as input.
>
> To fix these issues, three changes should be applied:
> 1. Deprecate bytes.fromhex. This fixes the following problems:
>    #4 (go with option B and remove the function that does not allow bytes
> input)
>    #2 (the binascii functions will be the only way to "do it")
>    #1 (bytes.hex should not be implemented)
> 2. In order to keep the functionality that bytes.fromhex has over unhexlify,
>    the latter function should be able to handle spaces in its input (fix #3)
> 3. binascii.hexlify should return string as its return type (fix #5)

Or we fix bytes.fromhex(), add bytes.hex() and deprecate binascii.(un)hexlify().

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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Neil Hodgson 
Dirkjan Ochtman:

> I know a lot of projects use Mercurial on Windows as well, I'm not
> aware of any big problems with it.

   If you have a Windows-only project with CRLF files using Mercurial
then there is no line end problem as Mercurial preserves the CRLFs for
you. Line end problems occur on mixed projects where both Windows and
Unix tools are used.

   Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Neil Hodgson 
Paul Moore:

> 1. Given that the "problematic" tools (notepad and Visual Studio) are
> Windows tools, we seem to be back to the idea that this extension is
> only needed by Windows developers. As I understood the consensus to be
> that the extension should be for all users, I suspect I've missed
> something.

   Some of the problems come from users on Unix checking in files with
CRLF line ends that they have received using some other mechanism such
as sharing a disk between Windows and Linux. I was going to point to a
bad revision in a bzr housed project I work on but launchpad isn't
working currently. What happened was that an OS X user committed a set
of changes but with all the files having a different line ending to
the repository. The result is that it is no longer easy to track
changes before that revision. It also makes a check out larger.

   It would help in such cases for the commit command on Unix to
either automatically change any CRLF line ends to LF for text files
(but not files with an explicitly specified line end) or to display a
warning.

   Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hgeol extension

2009-09-05 Thread Martin Geisler 
"Martin v. Löwis"  writes:

>> Can anyone (re-) post the specification of the proposed extension, to
>> the level that it is currently defined?
>
> For reference, here are the original specification, mine and Martin
> Geisler's:
>
> http://mail.python.org/pipermail/python-dev/2009-August/090984.html
> http://mail.python.org/pipermail/python-dev/2009-August/091453.html
>
> Here is my attempt at summarizing it:
>
> - name of versioned configuration file (in root of tree): .hgeol
> - names of conversion modes: native, LF, CRLF
> In the configuration file, there is a section [patterns] which
> maps file name patterns to conversion modes, e.g.
>
> [patterns]
> **.txt = native
> **.py = native
> **.dsp = CRLF
> **.bat = CRLF
> Tools/bgen/README = native
> Lib/email/test/data/msg_26.txt = CRLF
>
> - Martin Geisler also proposes that there is a section
> [repository]
> native = 
> I personally feel YAGNI; it should only support LF (adding such
> a feature later may be considered)

I don't think it's a good idea to store everything in LF in the
repository. Unlike Subversion, you cannot expect all interactions to
take place through the "eol-filter" we're implementing. Letting people
checkout a useful unfiltered clone would be possible if we know the
repository native format and convert back to that.

Anyway, it's a minor detail. More importantly, I've posted a simple,
rough extension that does this here:

  http://markmail.org/message/yj4so736t4cfdulv

I figured it would be better to discuss the design and implementation on
mercurial-devel since there are more Mercurial hackers there. I've CC'ed
a bunch of people from this thread to "seed" the discussion -- the rest
of you on python-devel are hereby invited to join :-)

  http://selenic.com/mailman/listinfo/mercurial-devel

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgpgBUTv4WZGB.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Problems with hex-conversion functions

2009-09-05 Thread Nick Coghlan 
Brett Cannon wrote:
>> To fix these issues, three changes should be applied:
>> 1. Deprecate bytes.fromhex. This fixes the following problems:
>>#4 (go with option B and remove the function that does not allow bytes
>> input)
>>#2 (the binascii functions will be the only way to "do it")
>>#1 (bytes.hex should not be implemented)
>> 2. In order to keep the functionality that bytes.fromhex has over unhexlify,
>>the latter function should be able to handle spaces in its input (fix #3)
>> 3. binascii.hexlify should return string as its return type (fix #5)
> 
> Or we fix bytes.fromhex(), add bytes.hex() and deprecate 
> binascii.(un)hexlify().

binascii is the legacy approach here, so if anything was to go, those
functions would be it. I'm not sure getting rid of them is worth the
hassle though (especially in 2.x).

Regarding bytes.hex(), it may be better to modify the builtin hex()
function to accept bytes as an input type.

Cheers,
Nick.

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