I've recently noticed that in py3k, the lack of a suitable sys.path will
cause Py_FatalError() to be called, which immediately terminates the
entire application.
On Windows, it is fairly easy for this to happen for developers or
anyone who hasn't run the official Python installation; just have
Barry Warsaw wrote:
> On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
>
>> It's always possible to make exceptions. It's not just about the VCS;
>> there have been requests to replace Apache, NTP, Zope, Postgres,
>> MoinMoin, and a few other packages. There have been many problems
>> on upgrade
Brett Cannon wrote:
[...]
> I have been using bzr for all of my importlib work. It's worked out
> well sans the problem that SOMEONE Barry has not
> upgraded the bzr installation to support the newest wire protocol.
>
If you think *that's* a problem try getting him to write a simple bloody
blog en
On Sat, Jan 3, 2009 at 16:39, "Martin v. Löwis" wrote:
>> Bazaar has been backwards-compatible with everything from my
>> understanding, so any changes they have made to the repository layout
>> or network protocol they use should not be an issue regardless of what
>> client or server versions are
Martin v. Löwis v.loewis.de> writes:
> > As for Mercurial, I have been told their repository layout has not
> > changed since their first release and updates have been more about bug
> > fixes and speed improvements.
>
> Speed improvements we can ignore; for bug fixes, it would be good to
> know
On Sun, Jan 4, 2009 at 9:28 AM, Brett Cannon wrote:
> On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote:
>>> Do any of the DVCS under consideration satisfy that requirement? I
>>> guess I'm asking whether you think all this talk about DVCSes is futile
>>> or premature?
>>
>> I still do hope
> Bazaar has been backwards-compatible with everything from my
> understanding, so any changes they have made to the repository layout
> or network protocol they use should not be an issue regardless of what
> client or server versions are being used. As for the version number,
> the team does mont
On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote:
>> Do any of the DVCS under consideration satisfy that requirement? I
>> guess I'm asking whether you think all this talk about DVCSes is futile
>> or premature?
>
> I still do hope that Debian releases lenny before any of this advances.
> Th
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 3, 2009, at 11:54 AM, Ulrich Eckhardt wrote:
>
>> 1. I think that a patch can not e.g. capture a moved, renamed or
>> deleted file.
>> Further, it can not handle e.g. things like the executable bit or
>> similar
>>
> Do any of the DVCS under consideration satisfy that requirement? I
> guess I'm asking whether you think all this talk about DVCSes is futile
> or premature?
I still do hope that Debian releases lenny before any of this advances.
This would mean
bzr 1.5
git 1.5.6
mercurial 1.0.1
I don't have t
On Sat, Jan 3, 2009 at 15:21, Ivan Krstić
wrote:
> On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
>>
>> There have been many problems on upgrade for the cases where we gave in:
>> shared libraries were missing after the upgrade (for Zope), the software
>> wasn't available anymore after the upg
Barry Warsaw python.org> writes:
>
> Do any of the DVCS under consideration satisfy that requirement?
Out of curiosity, I apt-get'ed Mercurial on a stable Debian (0.9.1-1+etch1)
and I was able to clone the trunk mirror (*) fine. It just took a bit over two
minutes.
(*) http://code.python.org/hg
> What's the preferred way of offering help with infrastructure problems,
> and to what extent, in your opinion, is the solution to have more hands
> on deck vs. farming out certain (groups of) services to different machines?
With the current installations, there aren't that many issues. The one
s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 6:27 PM, Martin v. Löwis wrote:
[I don't think Barry actually can/does provide these privileges]
I probably could, but I got pretty burned out doing regular admin
stuff. ;/
- -Barry
-BEGIN PGP SIGNATURE-
Version: Gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 6:12 PM, Martin v. Löwis wrote:
Maybe this is a false choice. Maybe the problem is standardizing on
Debian stable. If that distribution isn't giving us and our users
what
we need, maybe we need to re-evaluate that choice. Ye
> And with the
> tight feedback loop between committer and contributor along with
> working on a new feature instead of existing code leads to people
> getting commit privileges on the spot (if someone is there to give
> them the privileges; I honestly don't know who has the abilities to
> give the
On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
There have been many problems on upgrade for the cases where we gave
in: shared libraries were missing after the upgrade (for Zope), the
software wasn't available anymore after the upgrade (in case of
manually-install Python pacakges), and s
> Maybe this is a false choice. Maybe the problem is standardizing on
> Debian stable. If that distribution isn't giving us and our users what
> we need, maybe we need to re-evaluate that choice. Yes I know we've
> talked about that before and yes I know it would not be easy to switch
> to somet
On Sat, Jan 3, 2009 at 14:47, "Martin v. Löwis" wrote:
>>> As a consequence, I would always request that whatever VCS Python
>>> uses: the version that is in the current Debian's "stable" distribution
>>> must be sufficient to use the VCS, and must in particular be sufficient
>>> on the server sid
On 2/01/2009 10:32 PM, Ulrich Eckhardt wrote:
Hi!
I'm looking at NullImporter_init in import.c and especially at the call to
PyArg_ParseTuple there. What I'm wondering is what that call will do when I
call the function with a Unicode object. Will it convert the Unicode to a
char string first, wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
It's always possible to make exceptions. It's not just about the VCS;
there have been requests to replace Apache, NTP, Zope, Postgres,
MoinMoin, and a few other packages. There have been many proble
>> As a consequence, I would always request that whatever VCS Python
>> uses: the version that is in the current Debian's "stable" distribution
>> must be sufficient to use the VCS, and must in particular be sufficient
>> on the server side.
>>
>
> Even if someone like me or Barry volunteers to ma
Brett Cannon schrieb:
> And the sprints at PyCon have actually acted as a mentoring session
> for a lot of people. People end up helping out with a new feature and
> the committers there are able to do a review instantly. And with the
> tight feedback loop between committer and contributor along w
On Sat, Jan 3, 2009 at 14:17, "Martin v. Löwis" wrote:
>> I have been using bzr for all of my importlib work. It's worked out
>> well sans the problem that SOMEONE Barry has not
>> upgraded the bzr installation to support the newest wire protocol.
>
> I'm probably to blame for this. Debian doesn't
> I have been using bzr for all of my importlib work. It's worked out
> well sans the problem that SOMEONE Barry has not
> upgraded the bzr installation to support the newest wire protocol.
I'm probably to blame for this. Debian doesn't come with the latest
bzr revision (bzr evolves way too fast f
Martin v. Löwis schrieb:
>> Since I will probably add some documentation, and since this
>> documentation will probably
>> benefit from some reviews, what would be the best process ?
>>
>> 1/ commit the changeset and ask for a post-review by Georg (or others)
>> 2/ hold the changeset in a diff for
On Sat, Jan 3, 2009 at 09:52, Georg Brandl wrote:
> Steve Holden schrieb:
>
>> I think it was courageous of Brett to tackle this issue head-on as he
>> did, and of Victor to respond so positively to the various comments that
>> have been made on this thread. It would be a pity to lose a developer
hey, has anyone investigated compiling python2.5 using winegcc, under wine?
i'm presently working my way through it, just for kicks, and was
wondering if anyone would like to pitch in or stare at the mess under
a microscope.
it's not as crazed as it sounds. cross-compiling python2.5 for win32
wit
On Sat, Jan 3, 2009 at 10:42, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 3, 2009, at 11:36 AM, Martin v. Löwis wrote:
>
>> We can setup such a branch, unless you reconsider and try bazaar first.
>> There wouldn't be any pushing it back upstream, though - you w
> Out of curiosity : is there any mechanism in the post-commit that
> checks if "make html"
> doesn't spit any error ?
No, there is no such mechanism. There are daily builds which will
report errors eventually.
Regards,
Martin
___
Python-Dev mailing lis
On Sat, Jan 3, 2009 at 3:39 PM, Tarek Ziadé wrote:
>
> Out of curiosity : is there any mechanism in the post-commit that
> checks if "make html"
> doesn't spit any error ?
Not automatically. However, Georg and I test it fairly often and fix
markup errors if they're present.
--
Regards,
Benjam
On Sat, Jan 3, 2009 at 10:21 PM, Nick Coghlan wrote:
>> [cut]
>>
>>> 1/ is better for the flow, but the quality of the doc might suffer
>>> from it if Georg (or others) doesn't have time to review it
>>
>> This is of little concern. As long as the documentation continues
>> to build (into html), n
Martin v. Löwis wrote:
>> Since I will probably add some documentation, and since this
>> documentation will probably
>> benefit from some reviews, what would be the best process ?
>>
>> 1/ commit the changeset and ask for a post-review by Georg (or others)
>> 2/ hold the changeset in a diff for a
Georg Brandl wrote:
> I've become cautious of labeling patches as "trivial". Some may really be,
> e.g. typos and the like, but those are almost always dealt with quickly.
> Others may seem trivial, as in "add that line here", but there is often
> a problem associated -- like the question of porta
Hello,
it seems that both the following pages are identical, and are for
release30-maint:
http://www.python.org/dev/buildbot/3.0.stable/
http://www.python.org/dev/buildbot/3.x.stable/
Isn't the latter supposed to point to the py3k branch buildbots?
Regards
Antoine.
___
> Since I will probably add some documentation, and since this
> documentation will probably
> benefit from some reviews, what would be the best process ?
>
> 1/ commit the changeset and ask for a post-review by Georg (or others)
> 2/ hold the changeset in a diff for a pre-review ?
If you are con
On Sat, Jan 3, 2009 at 5:17 PM, "Martin v. Löwis" wrote:
>> Yes, that's the problem. Is it not possible to have finer permission (instead
>> of boolean permission: commit or not commit)? Eg. give commit access but only
>> for a file or a directory? It looks like Tarek Ziade is now allowed to
>> co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 1:51 PM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Although it doesn't help Victor specifically, anyone with svn commit
privileges also has permission to push Bazaar (and I think Mercurial)
branches back to code.py
Barry Warsaw python.org> writes:
>
> Although it doesn't help Victor specifically, anyone with svn commit
> privileges also has permission to push Bazaar (and I think Mercurial)
> branches back to code.python.org.
Actually the Mercurial repositories are read-only. We would need some
server-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 11:54 AM, Ulrich Eckhardt wrote:
1. I think that a patch can not e.g. capture a moved, renamed or
deleted file.
Further, it can not handle e.g. things like the executable bit or
similar
things that SVN otherwise does manage. T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 11:36 AM, Martin v. Löwis wrote:
We can setup such a branch, unless you reconsider and try bazaar
first.
There wouldn't be any pushing it back upstream, though - you would
still
need to go through the tracker for all changes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 10:52 AM, Victor Stinner wrote:
A little offtopic: it seems to me it is a flaw of svn, that it
encourages the model of two classes of developers, those with a
commit
access (first class) and those without it (second class).
Y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 7:57 AM, Steve Holden wrote:
In the old days this would have happened by a process known in the
British training world as "sitting with Nellie" - doing the work next
to, and directly supervised by, someone who had been doing it a
Georg Brandl wrote:
> Steve Holden schrieb:
>
>> I think it was courageous of Brett to tackle this issue head-on as he
>> did, and of Victor to respond so positively to the various comments that
>> have been made on this thread. It would be a pity to lose a developer
>> who so obviously has Python
On Saturday 03 January 2009 17:36:04 Martin v. Löwis wrote:
> > As far as your goal is concerned, couldn't you live with a branch where
> > you develop the feature?
>
> That still doesn't help the change getting merged into the trunk.
> Whether you store it in a patch file, in a DVCS, or in the ver
On 03/01/2009 17:54, Ulrich Eckhardt wrote:
1. I think that a patch can not e.g. capture a moved, renamed or deleted file.
Further, it can not handle e.g. things like the executable bit or similar
things that SVN otherwise does manage. That is what makes a patch only
partially suitable.
Actuall
2009-01-03 18:10:27 Martin v. Löwis napisał(a):
> > 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> > file.
>
> Correct. However, this rarely happened. Contributors are not supposed
> rename files, and they can indicate deletions and additions in plain
> English (I typ
On Sat, Jan 3, 2009 at 11:47 AM, Georg Brandl wrote:
> Martin v. Löwis schrieb:
>>> I don't know about others, but downloading and applying a patch doesn't
>>> bother me (it's actually much quicker than doing a whole new SVN checkout).
>>
>> Same here. In fact, when I had to backport patches befor
Steve Holden schrieb:
> I think it was courageous of Brett to tackle this issue head-on as he
> did, and of Victor to respond so positively to the various comments that
> have been made on this thread. It would be a pity to lose a developer
> who so obviously has Python's best interests at heart.
Martin v. Löwis schrieb:
>> I don't know about others, but downloading and applying a patch doesn't
>> bother me (it's actually much quicker than doing a whole new SVN checkout).
>
> Same here. In fact, when I had to backport patches before the usage of
> svnmerge.py, I would always apply the orig
Georg Brandl gmx.net> writes:
>
> It looks like it does, and that's a good thing (once in a while).
Hey, and we've even had a DVCS sub-thread in the process ;)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Victor Stinner schrieb:
>> > If I understood correctly, your main point is that using bugtracker
>> > for committing patches is very painful (I agree).
>>
>> I understood differently: I thought Victor's complaint is that some
>> of his patches stay uncommitted for a long time.
>
> Not only *my* pa
David Cournapeau wrote:
> On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote:
>> [I don't want to get into another DVCS flamewar, but I just
>> can't let this go uncommented :-]
>
> I am sorry if that sounded like a flamewar, that was not my intention:
Oops - maybe the smiley was not obvio
On Sat, Jan 3, 2009 at 8:46 AM, "Martin v. Löwis" wrote:
> [I don't want to get into another DVCS flamewar, but I just
> can't let this go uncommented :-]
>> (took me ~ 1 hour to get around
>> without any previous encounter with git and I am no genius)
>
> I'm no genius, either, and I think that
On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote:
> [I don't want to get into another DVCS flamewar, but I just
> can't let this go uncommented :-]
I am sorry if that sounded like a flamewar, that was not my intention:
I just wanted to point out that there are solution that the op can
imp
> 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> file.
Correct. However, this rarely happened. Contributors are not supposed
rename files, and they can indicate deletions and additions in plain
English (I typically request a tarfile for additions).
> Further, it can
Ulrich Eckhardt knuut.de> writes:
>
> 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> file.
> Further, it can not handle e.g. things like the executable bit or similar
> things that SVN otherwise does manage. That is what makes a patch only
> partially suitable.
Yo
> For me, as a reviewer, a patch is either obvious,
> correct, and complete at first sight - or it is difficult. I can review
> only one difficult patch per week (currently), and that can easily cause
> patches that I need to review to stay in the tracker many months.
The problem for the author o
On Saturday 03 January 2009 17:21:16 Antoine Pitrou wrote:
> Ulrich Eckhardt knuut.de> writes:
> > saying "please merge r1234 from
> > foo into trunk" is much easier than downloading and applying a patch,
> > which doesn't even cover all possible changes that SVN does.
>
> I don't know about other
[I don't want to get into another DVCS flamewar, but I just
can't let this go uncommented :-]
> (took me ~ 1 hour to get around
> without any previous encounter with git and I am no genius)
I'm no genius, either, and I think that git is the most horrible
VCS that I ever had to use. The error mess
> I don't know about others, but downloading and applying a patch doesn't
> bother me (it's actually much quicker than doing a whole new SVN checkout).
Same here. In fact, when I had to backport patches before the usage of
svnmerge.py, I would always apply the original patch multiple times,
rather
> As far as your goal is concerned, couldn't you live with a branch where you
> develop the feature?
That still doesn't help the change getting merged into the trunk.
Whether you store it in a patch file, in a DVCS, or in the very same
VCS-but-different-branch - these are all minor details, which
On Sun, Jan 4, 2009 at 1:21 AM, Antoine Pitrou wrote:
>
> You could clone one of the existing DCVS mirrors and open a branch on a public
> hosting service (bitbucket.org, launchpad, etc.). The annoying thing, though,
> is that it requires your co-workers to learn the DVCS in question.
The proble
Ulrich Eckhardt knuut.de> writes:
>
> saying "please merge r1234 from
> foo into trunk" is much easier than downloading and applying a patch, which
> doesn't even cover all possible changes that SVN does.
I don't know about others, but downloading and applying a patch doesn't
bother me (it's a
> Yes, that's the problem. Is it not possible to have finer permission (instead
> of boolean permission: commit or not commit)? Eg. give commit access but only
> for a file or a directory? It looks like Tarek Ziade is now allowed to
> commit, but only on distutils. I like such permission because
On Saturday 03 January 2009 16:52:56 Victor Stinner wrote:
> > A little offtopic: it seems to me it is a flaw of svn, that it
> > encourages the model of two classes of developers, those with a commit
> > access (first class) and those without it (second class).
>
> Yes, that's the problem. Is it n
> > If I understood correctly, your main point is that using bugtracker
> > for committing patches is very painful (I agree).
>
> I understood differently: I thought Victor's complaint is that some
> of his patches stay uncommitted for a long time.
Not only *my* patches. I spoke about my issues be
> A little offtopic: it seems to me it is a flaw of svn, that it
> encourages the model of two classes of developers, those with a commit
> access (first class) and those without it (second class).
Yes, that's the problem. Is it not possible to have finer permission (instead
of boolean permission
Brett Cannon wrote:
> On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" wrote:
>>> A little offtopic: it seems to me it is a flaw of svn, that it
>>> encourages the model of two classes of developers, those with a commit
>>> access (first class) and those without it (second class). Victor --
>>> may
On Friday 02 January 2009 23:18:04 Martin v. Löwis wrote:
> Correct me if I'm wrong: it seems that the function isn't called
> anymore. So I propose to just remove it (and the file it lives
> in).
Filed as issue #4817, including patch.
Uli
___
Python-De
David Cournapeau gmail.com> writes:
>
> It does not make integration easier, but it certainly makes patch
> management easier for the patch writer. There are other means to
> manage patch on top of svn, but I find git-svn extremely useful.
> Actually, I use git-svn on top of svn repositories for
On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" wrote:
>> A little offtopic: it seems to me it is a flaw of svn, that it
>> encourages the model of two classes of developers, those with a commit
>> access (first class) and those without it (second class). Victor --
>> maybe you can try something l
On Sat, Jan 3, 2009 at 5:50 PM, "Martin v. Löwis" wrote:
>> A little offtopic: it seems to me it is a flaw of svn, that it
>> encourages the model of two classes of developers, those with a commit
>> access (first class) and those without it (second class). Victor --
>> maybe you can try something
> I don't have new solutions, it's just an email to restart the discussion
> about
> bytes ;-) Martin also asked for a PEP to change the posix module API to
> support bytes.
And I repeat this request: we don't need new discussions; we need a
draft specification. Restarting discussion will just
> A little offtopic: it seems to me it is a flaw of svn, that it
> encourages the model of two classes of developers, those with a commit
> access (first class) and those without it (second class). Victor --
> maybe you can try something like "git svn", so that you don't have to
> use the bugtracke
> And I hope everyone realizes that they can speak up (publicly or
> privately) about *anyone* in regards to whether they think they need
> to lose their commit privileges for personal or coding reasons. I know
> it's tough to speak out publicly about someone and their coding
> abilities which is w
76 matches
Mail list logo
