> 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 desig
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
> > 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, Pyth
"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 misinform
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
restr
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 = float(
[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 = float(string) except ValueError float('nan')
+1
I've l
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 = float(stri
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 t
> From: Nick Coghlan
> Subject: Re: [Python-Dev] Reasons for using expy
> To: "Yingjie Lan"
> Cc: python-dev@python.org
> Date: Thursday, August 6, 2009, 1:44 AM
> This kind of advocacy for external projects belongs on
> python-list, not
> python-dev (or, if you're proposing something for use in
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
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 p
2009/8/3 Dirkjan Ochtman :
> 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
Python-Dev@pyt
Martin v. Löwis schrieb:
>> 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
> 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 .hg
"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
>
Stephen J. Turnbull schrieb:
> 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
> > proble
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).
>
>
Martin v. Löwis 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.
Regards
> >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
>>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
>> http://svn.python.org/view/
>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
> http://svn.python.org/view/pytho
>> 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 hoo
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 mea
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 Hammond 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.
Ev
2009/8/5 Mark Hammond :
> 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 these files were accident
I sent fourteen requests for licenses in to Microsoft. I've asked them
to let me know which they grant (since they may choose to limit the
number) and will inform you all personally when I hear their decision.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web L
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 conver
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
Oleg Broytmann phd.pp.ru> writes:
>
>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
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
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):
http://svn.python.org/view/python/trunk/Lib/encodings/puny
On Wed, Aug 5, 2009 at 16:35, Oleg Broytmann 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 to come up w
On Wed, Aug 05, 2009 at 04:04:24PM +0200, Dirkjan Ochtman wrote:
> On Wed, Aug 5, 2009 at 15:57, Oleg Broytmann 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
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 a
Dirkjan Ochtman wrote:
> On Wed, Aug 5, 2009 at 15:35, MRAB 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 com
On Wed, Aug 5, 2009 at 15:57, Oleg Broytmann 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 web interface
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, a
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
configura
On Wed, Aug 5, 2009 at 15:35, MRAB 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 committing, including any checks
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 two
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 pract
On 5/08/2009 9:28 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 13:19, Mark Hammond 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
On Wed, Aug 5, 2009 at 13:19, Mark Hammond 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 -- although it can be done
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 editors,
On 5/08/2009 8:04 PM, Paul Moore wrote:
2009/8/5 "Martin v. Löwis":
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 push. That will teac
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
On Wed, Aug 5, 2009 at 12:04, Paul Moore 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 me. That suits
2009/8/5 "Martin v. Löwis" :
> 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.
> The
"Martin v. Löwis" 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 solutions
pr
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:
*
> 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 suppor
>> 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
On Wed, Aug 5, 2009 at 11:02, Mark Hammond 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,
> the system (inc
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 b
On Wed, Aug 5, 2009 at 10:51, "Martin v. Löwis" 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"?) if some co
On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammond 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 s
> - 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 "pu
>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 a
On Wed, Aug 5, 2009 at 01:43, Mark Hammond 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 side :)
I'm not trying t
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 ful
>> 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
>> 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 volun
On 5/08/2009 6:00 PM, Ben Finney wrote:
Mark Hammond 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 distribu
Mark Hammond 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
same capability doesn'
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 y
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
> 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 t
On 5/08/2009 4:50 PM, Ben Finney wrote:
Mark Hammond writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond 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 comm
>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 numb
70 matches
Mail list logo
