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
This is a repost from a month ago. It didn't get much feedback last
time. I have now two items.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
The first item is build identification. If
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
Janzert wrote:
Eric Pruitt wrote:
Sounds good enough to me but I was wondering if it might be a good
idea to add a function like pidinuse to subprocess as a whole that
would determine if a process ID was being used and return a simple
boolean value. I came across a number of people searching
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
On Wed, Aug 05, 2009 at 05:50:03PM +0400, Oleg Broytmann wrote:
Subversion handles these issues by providing ...
svn:mime-type (handles both MIME type and charset)
file-by-file basis.
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8,
On Wed, Aug 5, 2009 at 15:57, Oleg Broytmannp...@phd.pp.ru wrote:
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8, another in koi8-r, and the third in cp1251
encoding - I certainly don't want to convert them back and force, but I
want hg
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
On Wed, Aug 05, 2009 at 04:04:24PM +0200, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 15:57, Oleg Broytmannp...@phd.pp.ru wrote:
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8, another in koi8-r, and the third in cp1251
encoding - I
On Wed, Aug 5, 2009 at 16:35, Oleg Broytmannp...@phd.pp.ru wrote:
Perhaps that's not a big issue for Python, but it's certainly a big
issue for me.
I think there are extensions that try to deal with it. Have a look:
http://mercurial.selenic.com/wiki/UsingExtensions
If not, it should be easy
On Thu, Aug 06, 2009 at 12:12:08AM +1000, Nick Coghlan wrote:
Yep - while SVN does support full mime_type specification for files, I
don't think we have ever used it.
These files are in 8859-1 encoding (names in comments, at least):
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
Oleg Broytmann writes:
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8, another in koi8-r, and the third in cp1251
encoding - I certainly don't want to convert them back and force, but I
want hg web interface to provide charset in the
On Thu, Aug 06, 2009 at 12:34:39AM +0900, Stephen J. Turnbull wrote:
Oleg Broytmann writes:
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8, another in koi8-r, and the third in cp1251
encoding - I certainly don't want to convert them
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
Hi,
The expy project provides an express way to extend Python. After some careful
considerations, I came up with some reasons for expy (this is not an exhaustive
list):
(I). WYSIWYG. The expy project enables you to write your module in Python the
way your extension would be (WYSIWYG), and
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
These files are in 8859-1 encoding (names in comments, at least):
http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
These files are in 8859-1 encoding (names in comments, at least):
http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
Dirkjan, how does Mercurial handles charsets? If I have three files in
my repository - one in utf-8, another in koi8-r, and the third in cp1251
encoding - I certainly don't want to convert them back and force, but I
want hg web interface to provide charset in the Content-Type
Martin v. Löwis martin at v.loewis.de writes:
No, it's not. PEP 8 mandates that non-ASCII code in the Python source
code is in Latin-1.
Ok, point taken.
Having several encodings (and several indentation rules) certainly makes things
more annoying for contributors than they should, however.
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
Martin v. Löwis wrote:
These files are in 8859-1 encoding (names in comments, at least):
http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
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
2009/8/3 Dirkjan Ochtman dirk...@ochtman.nl:
So PEP 385 proposes to clean up the old branches we still have lying
around in SVN.
io-c: keep-clone?
strip - it was merged into py3k some months ago.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Yingjie Lan wrote:
Hi,
The expy project provides an express way to extend Python. After some
careful considerations, I came up with some reasons for expy (this is
not an exhaustive list):
This kind of advocacy for external projects belongs on python-list, not
python-dev (or, if you're
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
I'm new to this list, so please excuse me if this topic has been
discussed, but I didn't
see anything similar in the archives.
I very often want something like a try-except conditional expression similar
to the if-else conditional.
An example of the proposed syntax might be:
x =
At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
[Jeffrey E. McAninch, PhD]
I very often want something like a try-except conditional expression similar
to the if-else conditional.
An example of the proposed syntax might be:
x = float(string) except float('nan')
or possibly
x =
Raymond Hettinger wrote:
If accepted, this would also solve the feature requests for various
functions to have default arguments.
For example:
x = min(seq) except ValueError else 0 # default to zero for
empty sequences
It would also be helpful in calculations that have algebraic
Martin v. Löwis writes:
I don't see any good reason for having any encodings but UTF-8 in
Python's.
Just in case my previous message gets overlooked: PEP 8 mandates Latin-1
for Python 2.x source code (except for files that test PEP 263).
You're right, sorry for the misinformation.
Just in case my previous message gets overlooked: PEP 8 mandates Latin-1
for Python 2.x source code (except for files that test PEP 263).
You're right, sorry for the misinformation.
An exception should be made for gettext message files, too?
In principle, perhaps. However, Python
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
66 matches
Mail list logo
