M.-A. Lemburg mal at egenix.com writes:
IMHO, it would be a lot better to add full Unicode support
for line breaks to the io layer. Given that the code for the
complicated handling of the CRLF combination is already there,
it's not difficult to add support for the remaing line break
This is simply false AFAICS. There was little participation on this
particular issue during PEP 374 that I can recall. Now that it is
clearly an issue after all, it's still early in the PEP 385 process.
Martin has already picked up the ball on EOL support, and has carried
informal design
Martin v. Löwis writes:
This is simply false AFAICS. There was little participation on this
particular issue during PEP 374 that I can recall. Now that it is
clearly an issue after all, it's still early in the PEP 385 process.
Martin has already picked up the ball on EOL support, and
Neil Hodgson wrote:
Glenn Linderman:
and perhaps other things (and
are there new Unicode control characters that could be used for line
endings?),
Unicode includes Line Separator U+2028 and Paragraph Separator
U+2029 but they are rarely supported and very rarely used. They are a
pain
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been designed from the start to only recognize the
standard line break
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been designed from the start to only recognize the
Nick Coghlan wrote:
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been designed from the start to
M.-A. Lemburg wrote:
Nick Coghlan wrote:
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been
M.-A. Lemburg mal at egenix.com writes:
What I don't understand is why the io layer tries to reinvent
the wheel here instead of just using the codec's .readline()
method - which *does* use .splitlines() and has full support
for all Unicode line break characters (including the CRLF
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
What I don't understand is why the io layer tries to reinvent
the wheel here instead of just using the codec's .readline()
method - which *does* use .splitlines() and has full support
for all Unicode line break characters
M.-A. Lemburg mal at egenix.com writes:
Sure, but the code for line splitting is not really all that
complicated (see PyUnicode_Splitlines()), so could easily
be adapted to work on buffers directly.
Certainly indeed. It all comes down to compatibility with the original
implementation.
(PEP
M.-A. Lemburg:
... and because of this, the feature is already available if
you use codecs.open() instead of the built-in open():
So should I not add an issue for the basic open because codecs.open
should be used for this case?
Neil
___
On Tue, Aug 4, 2009 at 5:43 PM, Mark Hammondmhamm...@skippinet.com.au wrote:
I'm more than willing to help on this; I haven't resurrected my stale patch
because I find win32text only 1/2 a solution that doesn't work in practice.
Therefore that patch is as stale for me as it is anyone. However,
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammondmhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced bad line
Mark Hammond skippy.hamm...@gmail.com writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammondmhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of
I haven't commented on this issue before because I can't really be
helpful. I just don't understand why hg is being considered before
it's Windows support is roughly equivalent to svn and cvs.
Is it really that you don't *understand*? It's fairly easy: there was
a PEP which offered a number
On 5/08/2009 4:50 PM, Ben Finney wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammondmhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to
If things were different, they'd be different. However, we live with the
legacy of that stupid set of decisions and have no real option to
resolve it permanently short of deprecating entire vistas of tools (or
even entire operating systems).
I think you missed the solution to the problem that
On 5/08/2009 5:35 PM, Martin v. Löwis wrote:
Now, the specific outcome of the process means that more work needs to
be done. So we have a *second* PEP, and we have a lack of volunteers
that help implementing it. The second PEP hasn't been approved yet
(as it isn't complete, yet), so migration
Mark Hammond skippy.hamm...@gmail.com writes:
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are* centralised. Using a distributed VCS means the
On 5/08/2009 6:00 PM, Ben Finney wrote:
Mark Hammondskippy.hamm...@gmail.com writes:
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are*
Now, the specific outcome of the process means that more work needs to
be done. So we have a *second* PEP, and we have a lack of volunteers
that help implementing it. The second PEP hasn't been approved yet
(as it isn't complete, yet), so migration to hg is stalled.
The primary volunteer
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are* centralised. Using a distributed VCS means the
same capability doesn't apply.
Why do you
Martin v. Löwis:
Is it really that you don't *understand*? It's fairly easy: there was
a PEP ...
The PEP process is straightforward. However, a PEP may produce an
outcome that proves after more experience to be wrong. ISTM a
prerequisite to choosing a DVCS is that it should support the full
On Wed, Aug 5, 2009 at 01:43, Mark Hammondmhamm...@skippinet.com.au wrote:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and unhelpful, and I'm trying to stay on the former
The PEP process is straightforward. However, a PEP may produce an
outcome that proves after more experience to be wrong. ISTM a
prerequisite to choosing a DVCS is that it should support the full
range of development platforms and thus the PEP was accepted
prematurely.
To be as blunt as
- we're a distributed system, there's fairly little we can assume about
clients
Not as Mercurial, no. As Python, we can certainly expect that all of our
contributors have read the developer FAQ, and set up their systems
accordingly. If all else fails, we can revoke commit access (or is
it push
On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammondmhamm...@skippinet.com.au wrote:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and
On Wed, Aug 5, 2009 at 10:51, Martin v. Löwismar...@v.loewis.de wrote:
Not as Mercurial, no. As Python, we can certainly expect that all of our
contributors have read the developer FAQ, and set up their systems
accordingly. If all else fails, we can revoke commit access (or is
it push access?)
Martin v. Löwis:
Or don't you understand why that single unresolved item didn't manage
to revert the decision? Well, there are many unresolved items in
the Mercurial conversion, some much more stressful than the eol issue
(e.g. the branching discussion).
Then these issues should have been
On Wed, Aug 5, 2009 at 11:02, Mark Hammondskippy.hamm...@gmail.com wrote:
In general I agree - although I think we can enforce a social contract
which puts requirements on people who commit to the Python repository - and
therefore we can consider the server-side hooks a secondary defense. IOW,
Not as Mercurial, no. As Python, we can certainly expect that all of our
contributors have read the developer FAQ, and set up their systems
accordingly. If all else fails, we can revoke commit access (or is
it push access?) if some committer doesn't get the configuration
right. We would, of
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
This is all fairly hypothetical - if hg grew a .hgeols file, it would
be good if it supported
On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
I see two practical outcomes of such a mandate:
Martin v. Löwis mar...@v.loewis.de writes:
You seem to think that the problem has an obvious solution, which is
not true;
But is *has* an obvious solution. See the implementation from Dj
Gilcrease, or the spec that I just posted.
Two different solutions are both obvious? There are other
2009/8/5 Martin v. Löwis mar...@v.loewis.de:
My personal favorite outcome would be this:
- most files have svn's native eol style; they get stored in LF
in the repository; the hook will convert them on Windows, and check
on Unix.
- some files have windows eol style; they get stored in CRLF.
On Wed, Aug 5, 2009 at 12:04, Paul Moorep.f.mo...@gmail.com wrote:
Given that my preference is to use Unix-style EOL for text files on
Windows, as every text editor I use (barring notepad!) understands LF
format, it seems to me that this proposal also means that the hook
would be optional for
On 5/08/2009 8:04 PM, Paul Moore wrote:
2009/8/5 Martin v. Löwismar...@v.loewis.de:
With such a setup, using the hook would be truly optional on Unix,
as it only ever checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to
On 5/08/2009 8:14 PM, Dirkjan Ochtman wrote:
endings. Typically, in my case, that was either Notepad2 (an awesomely
light-weight Notepad replacement) or Komodo (Edit). That solved all of
my issues, so I haven't had a need for win32text so far.
FWIW, I use komodo and scite as my primary
On Wed, Aug 5, 2009 at 13:19, Mark Hammondmhamm...@skippinet.com.au wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a versioned file in the repo.
Even if we do that, enabling hg extensions will still need to be done
locally --
On 5/08/2009 9:28 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 13:19, Mark Hammondmhamm...@skippinet.com.au wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a versioned file in the repo.
Even if we do that, enabling hg
Mark Hammond wrote:
On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
I see two practical
Nick Coghlan wrote:
Mark Hammond wrote:
On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
I see
On Wed, Aug 5, 2009 at 15:35, MRABpyt...@mrabarnett.plus.com wrote:
Instead of just talking about line endings, could each file have a
specific 'filetype'? This would define what kind of data it contains,
how it's stored in the repository, and what actions to perform for
fetching and
On Wed, Aug 05, 2009 at 02:35:02PM +0100, MRAB wrote:
Instead of just talking about line endings, could each file have a
specific 'filetype'?
EOL-conversion, MIME type and encoding (charset) are three different
concepts. Yes, all of them must be supported, but not necessary in one
Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 15:35, MRABpyt...@mrabarnett.plus.com wrote:
Instead of just talking about line endings, could each file have a
specific 'filetype'? This would define what kind of data it contains,
how it's stored in the repository, and what actions to perform for
Mark Hammond writes:
I'm not sure what point you are trying to make, but I believe it *is*
possible for a solution to be found here which will keep Windows users
happy. I'm guessing you haven't had much practical experience with this
problem, so probably don't see this is clearly as
Mark Hammond wrote:
On 5/08/2009 8:14 PM, Dirkjan Ochtman wrote:
endings. Typically, in my case, that was either Notepad2 (an awesomely
light-weight Notepad replacement) or Komodo (Edit). That solved all of
my issues, so I haven't had a need for win32text so far.
FWIW, I use komodo and
2009/8/5 Mark Hammond mhamm...@skippinet.com.au:
Most tools that I use will tend to not mix EOL styles in a single file, but
will tend to create \r\n line endings for new files I create. Most hg repos
I come across don't have mixed line endings within individual files, so I
can only guess
On approximately 8/5/2009 4:28 AM, came the following characters from
the keyboard of Dirkjan Ochtman:
On Wed, Aug 5, 2009 at 13:19, Mark Hammondmhamm...@skippinet.com.au wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a
Given that my preference is to use Unix-style EOL for text files on
Windows, as every text editor I use (barring notepad!) understands LF
format, it seems to me that this proposal also means that the hook
would be optional for me. That suits me fine - I'd prefer to avoid
having hooks that are
Neil Hodgson schrieb:
Martin v. Löwis:
Or don't you understand why that single unresolved item didn't manage
to revert the decision? Well, there are many unresolved items in
the Mercurial conversion, some much more stressful than the eol issue
(e.g. the branching discussion).
Then
I'm not aware of any other unresolved items; they may exist, but the fact
that they're not discussed on this list in detail means that they are
largely unimportant.
There is a long list of things that still need to be done; each one
potentially creating new problems. In particular:
- the
Glenn Linderman:
and perhaps other things (and
are there new Unicode control characters that could be used for line
endings?),
Unicode includes Line Separator U+2028 and Paragraph Separator
U+2029 but they are rarely supported and very rarely used. They are a
pain to work with since they
On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
Mark Hammond writes:
I'm not sure what point you are trying to make, but I believe it *is*
possible for a solution to be found here which will keep Windows users
happy. I'm guessing you haven't had much practical experience with
Mark Hammond writes:
On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
I think the implication is obvious. There will be no good solution
until Windows users develop it. I don't see a good reason to wait for
that.
My conclusion is different. I'm not sure of the history of
Dirkjan Ochtman wrote:
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
You seem to advocate a two-step approach: enforce line endings through
win32text, catch any errors that slipped through in a hook
On 4/08/2009 7:20 PM, Nick Coghlan wrote:
Dirkjan Ochtman wrote:
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
You seem to advocate a two-step approach: enforce line endings through
win32text, catch any
Mark Hammond:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and unhelpful, and I'm trying to stay on the former side :)
I haven't commented on this issue before because I
Mark Hammond mhamm...@skippinet.com.au writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced bad line
endings. I'm guessing I would be forced
60 matches
Mail list logo
