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")
>>
"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.htm
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
>
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 m
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 w
> 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, I
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
>> - 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
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 functi
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
"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 chang
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 reaso
>> 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
> 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
> 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 w
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 need
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 Mo
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 histo
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
Python-
>> 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,
Marti
> 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.
Visu
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
___
>> 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
> 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 who
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 presum
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
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
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
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
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 c
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,
> 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/pyt
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
> spec
> 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 Wind
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 understo
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'l
> 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
37 matches
Mail list logo
