me a day, I considered the repository corrupted so that I
actually had to branch from the last ok revision, and redo all checkins
since (I also discarded changes which I didn't chose to redo). It was
a real catastrophe to me.
Since the changes actually
ay.
I think this is overly optimistic. Visual Studio will break all your
files if you don't use that extension (and you actually use it to
modify source code).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
geset wouldn't
> tell you immediately where it comes from (2.x or 3.x development).
I would it call default only up to the point where the py3k branch was
branched off trunk. All changes up to this point actually *do* belong
to both branches. Python 3's history goes all the way back
> So, actually, hg promotes a slightly different terminology:
> - a "head" is a changeset without a child in the topology
So what do you call the LoD leading up to a head? (i.e. the set of
changesets that are ancestors of a head and not ancestors of any other head)
Am 26.02.2011 20:30, schrieb Antoine Pitrou:
>
> Martin, I have now enabled the eol hook on the test repo (a quick test
> seemed to show it works). Could you test again?
It seems to work fine, thanks. I modified a file with Visual Studio, and
that changed all line endings. I then decide
that it's a likely problem that people create named
branches by mistake, then we should have a hook.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
ent approaches wrt. LF-separated
files. For a long time, new lines added would be CRLF, whereas existing
line endings would remain unchanged, resulting in a mix of line endings.
It appears that VS 2008 now uniformly converts the entire file to CRLF
on first edit.
Regards,
Martin
_
hanks to everybody involved in the
original development of the eol extension. It originated from
python-dev, and, with the switchover taking so long as it took,
it's a standard extension of Mercurial releases by now. In the
Tortoise Global Settings GUI, there is even a ch
ldbot can do this too. It can even do it without xml, although it
>> does need *some* parseable format, which I think the Python test suite
>> is a long way from.
>>
>
> That would be a great improvement to the Python buildbot infrastructure.
fter the
> switch (the svnmerge information isn't retained in the converted repo).
Is that really going to work? I.e. will Mercurial be able to merge from
default to one of the feature branches? If so, what will be the
procedure? What would be the exact steps to try this out on the PEP 382
Am 28.02.2011 23:45, schrieb Antoine Pitrou:
> Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :
>>> In preparation for the hg switch, I would recommend that, if you have
>>> any feature branches managed with svnmerge, you sync them with the py3k
&g
at. Even a PEP might not make it policy (practicality beats
purity), but not having a PEP guarantees that it won't become policy.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
t at some point.
>
> I'm not sad about that, myself.
Neither am I. I personally also disagree with the decision taken at
the language summit (and believe that the language summit is no place
to make such decisions).
Regards,
Martin
___
tthias Klose represents Debian, Dave Malcolm represents Redhat,
and Dirkjan Ochtman represents Gentoo.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
one else to ship a python2 binary,
> 2.7.next should also install it when building from source...
I agree with Barry that this would be a new feature, and, by default,
cannot be added to the 2.7 release which is in maintenance mode.
IMO, an acce
, and I
can adjust. So the idea of /usr/bin/python being reserved for Python 2
strikes me as inconvenient.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
hon3 - "python" could
be either one, but should be present "normally" (i.e. SHOULD
in the RFC 2119 sense).
Nitpickingly, I'd add that scripts can, of course, also specify
python2.7 (or some such). Actually, scripts can do whatever they
want - it's mor
C. While that indeed may help python-dev most,
they called it summer of *code* deliberately - so the project idea
should be about programming (the hope being, of course, that the
students stay in the project, or at least in open source, when the
summer is over. some do, some don
hin
the PSF GSoC, so this is not for me to decide.
There is also the issue with greenfield projects - if the task is to
come up with a new webapp, it may not well integrate with an existing
code base. However, having that integration is (or should be, IMO)
also a requir
mentor had communication
with the student).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Am 04.03.2011 13:35, schrieb Antoine Pitrou:
> On Fri, 04 Mar 2011 09:35:38 +0100
> "Martin v. Löwis" wrote:
>> Google Summer of Code is coming up again, and we will again
>> be participating. Arc Riley will setup infrastructure later
>> today, and we nee
, which uses
> the conversion metadata to find the correct hg revision.
>
> The syntax for changeset hash links from now on is [hash], e.g.
> [1a1ed76a6ae2].
Is it really necessary to have the square brackets? ISTM that
the syntax of the short or long
r that
was difficult to track down - it seems that many Python users on Windows
set PYTHONPATH, and that is going to break Python 3 installations.
With that problem, and the extension problem, solving the exe name issue
doesn't actually resolve real problems.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
#x27;t create them. Whether or not
*that* is a feature change depends on the distribution policy. For
example, for Debian, it would likely be perfectly reasonable to do
that in the 2.7 installation, since 2.7 will be a new feature for
Debian, anyway.
Regards,
Martin
All patches should go to the bug tracker. If you host a clone somewhere,
you could start publishing patches by referring to a remote repository,
rather than uploading the diff. I'm curious how this DVCS thing works
out for contributors.
Regards,
Martin
_
s that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. double-clicking .py will continue to launch
the most-recently installed Python, rather than the "right" one, and
setting PYTHONPATH will continue to
> I don't think duplicating python.exe as python2.exe or python3.exe would
> be very much work at all, if we decide it is a good thing. Sure it
> doesn't resolve all the myriad problems of Python on Windows but I don't
> think that is a good reason not to consider i
o I guess mandating square brackets is reasonable - alternatively,
mandating a fixed length could have worked as well, I guess.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
or?
It's a wiki, so feel free to edit it. If it gets too unorganized, I'm
sure Arc will post more specific rules. Telling him that you are a
prospective member (with the information he asked for) can't hurt,
though.
Regards,
Martin
__
> The peps repo is the only other one that seems relevant
Actually, the stackless people also requested that their repository
gets converted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
Am 05.03.2011 19:26, schrieb Michael Foord:
> On 28/02/2011 21:59, "Martin v. Löwis" wrote:
>>>>> That's one of the big advantages that Jenkins (nee Hudson) has over
>>>>> buildbot - drilling down into individual test failures through the
>>&
or that. Agreements on python-dev are
quickly forgotten.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
so that the .hgeol file work
> fine.
Actually, the status that they had was deliberate. The vcproj files can
be in "native" EOL mode, and should have CRLF when checked out on
Windows. The solution file must have CRLF always.
The vcproj files where not in bi
I remember you making
the same mistake when we switched to Subversion: you continued to use
the test repository, and then found that subversion complains :-)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
LF, and reconsider if something actually breaks.
What is the recommended merge flow if I want to make this change to
all branches?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
How should patches be applied to the cpython repository if they
land in more than one branch?
More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
default - how do I apply the patches and how do I merge?
Regards,
Martin
___
Python-Dev
the --git option.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
modified all these files. That is
surprising, since you didn't change any file at all.
So how can I fix this properly: so that all files have CRLF, but
are still attributed to whoever last modified them, rather than
having them attributed to me?
Regards,
M
to work without a base revision, so for the time being, this cannot be
supported.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
al copy
hg push pydotorg # pushes directly into the remote directory
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
om the beginning) for the packaging inside a
distribution.
so -1 on the python link bits.
It is conforming to the PEP to have /usr/bin/python as 2.x "forever"
(i.e for at least two LTS releases - in Debian, that *is* "forever").
So Debian can
and no review would
be possible.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Not sure if it fits in your specific case you mention here, but
Mercurial has a reserved path alias name "default-push" with special
meaning:
Ah. I didn't know that, thanks.
Martin
___
Python-Dev mailing list
Python-Dev@
ng all
new changesets over as necessary).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e PEP repository.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
3.2 branch" of the "3.2 clone". Each clone has all
branches, even if you only "update" to one of them.
So after "hg push", the change is on the "3.1 branch" of the "3.2
clone". The "merge 3.1" tries to merge all changes on the 3.
he PEP author to take a stance, which
you did. It's recommended tradition to record any opposing opinions
in the PEP, along with rebuttals, so that the same arguments aren't
brought up over and over again. If discussion then settles, it's
up to the PEP dictator to appro
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
"Martin v. Löwis" writes:
> It seems that the dev guide recommends to use the --git option in hg
> diff. I'm working on the Rietveld integration, and found that this
> option makes things worse: the regula
Am 07.03.2011 03:43, schrieb Stephen J. Turnbull:
"Martin v. Löwis" writes:
> Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
> > "Martin v. Löwis" writes:
> >> It seems that the dev guide recommends to use the --git option in
hg
> &
mments get mailed to the nosy
list.
If there are any problems with that installation, please report
them to the meta tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
wrong that this isn't documented in "what's new";
there is an item about it in the "porting to 3.2" section.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
h I think would harm the review (since some changes may be
superseded in a separate patch).
So I would need to compute the most recent revision in both
repositories, and then create a diff between the default head
of the remote repository and that base revisi
Am 07.03.2011 23:09, schrieb Brendan Cully:
On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote:
I'd like to experiment with adding Rietveld support for reviewing
remote repositories. For that, I'd need to create a single patch
(programmatically) that covers all incoming changes. '
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
t. There is "hg
incoming -p", but it has the nasty problem that it may produce
multiple patches for a single file.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
cestor). Still, with this command, I get
martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff
-r'ancestor(.,default)' -r default
abort: unknown revision 'ancestor(.,default)'!
Regards,
Martin
___
Python-Dev mailing list
Python-
ng won't do for me. If I
could double-click it, I would like that more (there is also the issue
that the script needs the VS envvars set, so I'd need to find a solution
to that, also).
Regards,
Martin
___
Python-Dev mailing list
Python-
nment variable.
(Which again the Python installer doesn't do by default.)
Running foo.py works fine with the current installers (just try to see
for yourself). You don't need PATHEXT for that.
Regards,
Martin
___
Python-Dev mailing list
Py
om this command:
svn co http://svn.python.org/projects/python/tags/r27
Did you by any chance use hg clone -rv2.7?
No: the cpython repository simply does not contain a tag called 'v2.7'.
Not sure why not; v2.7rc1 and v2.7.1 are present.
Regards,
Martin
_
Am 08.03.2011 11:30, schrieb Stephen J. Turnbull:
"Martin v. Löwis" writes:
> > However, as Michael points out, you can have your tools generate the
> > patch. For example, it shouldn't be too hard to add a dynamic patch
> > generator to Roundup
Am 08.03.2011 11:19, schrieb Antoine Pitrou:
On Tue, 08 Mar 2011 09:38:27 +0100
"Martin v. Löwis" wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I
, and somebody will tell them.
I was not aware I could turn on deprecation warning for use of the C API.
How can I do that?
Not sure that you can. When I said "could have known", I meant "by
reading the documentation".
Regards,
Martin
_
martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' -r
default
abort: unknown revision 'ancestor(.,default)'!
It looks like that was fixed a week after 1.6.4 was released, here:
http://hg.intevation.org/mercurial/crew/rev/2063d36b406e
It should
that you
get good proposals from good students.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rmats, such as "hg export", do).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I can get users to use something different, any of "diff without
--git", "export with or without --git", "outgoing with or without --git"
would do (although outgoing uses a localized header, which would make
it more difficult to parse).
Regards,
Mart
for you to "import ssl".
In addition, that is also false. Even if OpenSSL is used, it is easy
to build Python so that OpenSSL is only loaded when needed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
r the volatile marker - I believe the code is also
correct without it, since the owned field is only accessed
through initialization and Interlocked operations.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it "proper" usage of the API to declare the storage
volatile. So ISTM that we should comply regardless of whether volatile
is considered "mora
PL, since the JVM wouldn't be a major
component, and hence you would need to distribute JVM's source code
under the terms of the GPL (which you may or may not be able to today,
but surely couldn't over many years during which many GPL'ed Java
programs were written).
Regards
still need the shared data to be re-loaded upon entering and
er-written upon leaving.
Please see the code. Where exactly does such reloading/rewriting need to
happen?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Am 10.03.11 07:55, schrieb Neil Hodgson:
Martin v. Löwis:
I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it "proper" usage of the API to declare the storage
volatile.
f you are merging into default?
ISTM that it should be "hg revert -ar ".
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
27;t think so. As release managers can easily find out, they
tend to switch those to "deferred blocker" just before a release,
and switch them back afterwards.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
cient
reduction for the case at hand, I don't know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
but recreated every time two objects need to be compared.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
h the cmp_to_key class in 3.x.
Fredrik classified this as "ugly and slow"; I'm not sure where this
classification comes from.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
feel obliged to honor it, until
some of the involved parties change their minds.
I don't think any of the regular core committers got any such explicit
veto powers on any code, and I don't think it should be granted to
anybody.
Regards,
Martin
_
other):
return self[0]*other[1] < self[1]*other[0]
python -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]"
-s "from fcomp import Fcomp" "sorted(L, key=Fcomp)"
Regards,
Martin
___
Python-Dev m
Am 12.03.11 22:36, schrieb s...@pobox.com:
Martin> I don't think any of the regular core committers got any such
Martin> explicit veto powers on any code...
"Veto powers" is your term, not mine. I suggested that Raymond's opinion
should be accorded extra
just push your changes to
cpython when done, which puts all your individual commits into Python's
history.
I tried to find an official statement on which way it should be in the
devguide, but couldn't find anything.
Regards,
Martin
___
P
patch).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I'd like to appoint Eric Smith as the PEP master for PEP 382
(Namespace Packages).
I hope to complete the implementation shortly, at which point
there will be a final call for comments.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pytho
use
of the deprecated construct to the alternative one."
If you think a year is too little, you should lobby for a PEP 5
change.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
s, you would have had a deprecation period of 19 months
and two releases. It's only if you are now migrating from 2 to 3
that you notice the breakage for the first time.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
d, so that
they have more time to adjust.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
anymore since the mercurial switch.
I don't know whether the pushlog is available remotely.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
ecution changes.
PEP 5 actually requires that backwards-incompatible changes must be
defined in a PEP. This wasn't done in this case; I agree it should have.
I guess it's not too late to write this PEP, even though that's after
the fact.
Regards,
Martin
not be done in 2.7.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
mpare against is the
difficult part; the other revision must be default's head,
which is always called 'default'.
Enjoy,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
r Debian/Ubuntu included the release; I think
I had the same issue with 1.6.4.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
Am 16.03.11 15:20, schrieb "Martin v. Löwis":
I get "unknown revision" (listing the full expression text) when using
Mercurial 1.6.3 (default version in Ubuntu 10.10).
That version apparently supports revsets, but I'm not sure when the
runtime evaluation of the command
called the API in any way taint Python?
Perhaps. So I'll see whether I can make use of the command line only, first.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Am 16.03.11 15:29, schrieb "Martin v. Löwis":
Am 16.03.11 15:20, schrieb "Martin v. Löwis":
I get "unknown revision" (listing the full expression text) when using
Mercurial 1.6.3 (default version in Ubuntu 10.10).
That version apparently supports revsets, but
Am 17.03.11 07:30, schrieb Baptiste Carvello:
Le 16/03/2011 18:49, "Martin v. Löwis" a écrit :
Having the revision of cpython to compare against is the
difficult part;
how about: 'max( ancestors(default) and not outgoing() )' ?
That fails if there have been later
Am 17.03.11 07:30, schrieb Baptiste Carvello:
Le 16/03/2011 18:49, "Martin v. Löwis" a écrit :
Having the revision of cpython to compare against is the
difficult part;
how about: 'max( ancestors(default) and not outgoing() )' ?
I take back what I just said: it looks go
I get "unknown revision" (listing the full expression text) when using
Mercurial 1.6.3 (default version in Ubuntu 10.10).
Based on Baptiste's approach, I propose the script below to compute a
patch. Please report whether it works for you.
Regards,
Martin
#!/bin/sh
base=`hg
> I did just poke around on the buildbot pages, but couldn't find
> anything resembling the old "buiild a branch" form.
>
> MvL/Antoine/Georg, any ideas?
Kelsey Hightower is already working on it. There is the buildbot 'try'
feature, but there may be ot
ly do that. Your merge (64eeb4cd4b56)
has your change (c63d7374b89a) as it's parent, so 64eeb4cd4b56 now
contains both the current state of cpython plus your change.
If somebody else now makes other changes that succeeded your merge,
you will need to mer
2801 - 2900 of 5755 matches
Mail list logo