Martin v. Löwis martin at v.loewis.de writes:
Somebody will have to make a decision. Ultimately, Guido will have to
approve the PEP, but it might be that he refuses to make a choice of
specific DVCS. Traditionally, it is the PEP author who makes all
choices (considering suggestions from the
On 17/02/2009 17:55, Steve Holden wrote:
is for work on developing Python. Hence your posting (and your
protestations of innocence) is unsolicited commercial email, AKA spam.
Python users who are looking for jobs know about the jobs board, where
you have already submitted vacancy notices (now
On 05/04/2009 07:55, Alexandre Vassalotti wrote:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good. We'll also have to decide on named
branches vs.
On 05/04/2009 02:44, Martin v. Löwis wrote:
I'm personally happy letting you do that (although I do wonder who would
then be in charge of the Mercurial installation in the long run, the way
I have been in charge of the subversion installation).
I'd be happy to commit to that for the
On 05/04/2009 11:06, Martin v. Löwis wrote:
In particular, the Stackless people have requested that they move along
with what core Python does, so their code should also be converted.
I'd be interested to hear if they want all of their stuff converted, or
just the mainline/trunk of what is
On 05/04/2009 12:27, Antoine Pitrou wrote:
There's also the issue of how we adapt the current workflow of svnmerging
between branches when we want to back- or forward-port stuff. In particular,
tracking of already done or blocked backports.
Right. The canonical way to do that with Mercurial is
On 05/04/2009 13:00, Antoine Pitrou wrote:
Transplant or export/import have the right semantics IMO, but we lose the
tracking that's built in svnmerge. Perhaps a new hg extension? ;)
(the missing functionality is to store the list of transplanted or blocked
changesets in a .hgXXX file (storing
(going back on-list)
On 05/04/2009 15:42, Alexandre Vassalotti wrote:
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good.
What is bad about it?
For one thing, it has the [svn] prefixes, which I found to be quite
ugly. hgsubversion in
On 05/04/2009 15:11, Alexandre Vassalotti wrote:
I am not sure if it would be useful to convert the old branches to
Mercurial. The simplest thing to do would be to keep the current svn
repository as a read-only archive. And if people needs to commit to
these branches, they could request the
On 05/04/2009 16:39, Antoine Pitrou wrote:
The other nice thing with having [svn rXXX] in the patch subject line is that
it makes the info easily viewable and searchable in the Web front-end.
We can still make it accessible/searchable on the web if we don't put it
in the commit message.
I
On 05/04/2009 17:18, Antoine Pitrou wrote:
It is a cheap price to pay if there is a significant return for it. In my
experience using the hg mirror of the py3k branch, I don't remember having had
to run annotate on the trunk to hunt for a change that I'd witnessed in py3k.
Other developers may
On 05/04/2009 19:50, Martin v. Löwis wrote:
Ok, that's a problem. We currently run 0.7.5 on the master, and have
made custom changes that need to be forward-ported. IIUC, this will
also mean that the waterfall default page is gone, which might surprise
people.
I suppose all slaves also need to
On 05/04/2009 19:37, Martin v. Löwis wrote:
Any decision to have or not have such a feature should be stated in
the PEP. I personally don't use IDEs, so I don't care (although
I do notice that the apparent absence of IDE support for Mercurial
indicates maturity of the technology)
Well, there
On 05/04/2009 20:18, Martin v. Löwis wrote:
But then, I have not tried installing it, so I don't know what it
actually looks like.
Ah, right. In my setup, there was an index page with three lines of
text, one of which had a link to the waterfall. So I think that should
still be simple enough
On 05/04/2009 20:29, Martin v. Löwis wrote:
FYI: this is the list of hooks currently employed:
- pre: check whitespace
- post: mail python-checkins
inform regular buildbot
inform community buildbot
trigger website rebuild if a PEP was modified
(but then,
On 05/04/2009 20:36, Martin v. Löwis wrote:
We do require full real names (i.e. no nicknames). Can Mercurial
guarantee such a thing?
We could pre-record the list of allowed names in a hook, then have the
hook check that usernames include one of those names and an email
address (so people can
On Mon, Apr 6, 2009 at 00:48, Mark Hammond skippy.hamm...@gmail.com wrote:
Just to be clear, what input would you like on that map?
Review of email addresses, pointers to names/email addresses for the
usernames I don't have anything for yet. Also, there's a few commented
question marks, it would
On Mon, Apr 6, 2009 at 04:27, s...@pobox.com wrote:
Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)?
Sure, if we're doing cloned branches. But then someone will also need
to clone 2.5, and maybe 2.4. The point is, as long as it's a constant
factor and not an order of
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti
alexan...@peadrop.com wrote:
But that won't work if people who are not core developers submit us
patch bundle to import. And maintaining a such white-list sounds to me
more burdensome than necessary.
Well, if you need contributors to sign a
Alexandre Vassalotti alexandre at peadrop.com writes:
If I recall correctly, only ssh clients can request compression to the
server—in other words, the server cannot forces the clients to use
compression, but merely allow them use it.
See the man page for sshd_config and ssh_config for the
Martin v. Löwis martin at v.loewis.de writes:
Is it possible to branch from a subdirectory? For the different VMs
stuff, it's rather desirable to have a branch of the test suite, and
the perhaps the standard library, than extracting it from the source.
You can only branch the whole repository.
Alexandre Vassalotti alexandre at peadrop.com writes:
With Mercurial, we will need to add support for server-side clone
ourselves. There's few ways to provide this feature. We give Unix user
accounts to all core developers and let developers manages their
private branches directly on the
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy p...@freehackers.org wrote:
One question: if somebody pushes a changeset with 3 commits, will the
pre and post hooks be applied on all of the commits, or only on the
final commit ?
If this is applied on every commit, then you have no way to fix a
On Mon, Apr 6, 2009 at 11:14, Philippe Fremy p...@freehackers.org wrote:
This is a problem I have with my daily usage of mercurial. It's supposed
to be great to work offline and to commit your intermediate versions
before it's fully working but if you do that, all those intermediate non
On Mon, Apr 6, 2009 at 13:55, Michael Foord fuzzy...@voidspace.org.uk wrote:
Gated checkins can work fine but can also have many problems. For example if
we have a spuriously failing test then if you are working on an unrelated
issue it will be entirely up to chance as to whether you can
On Tue, Apr 7, 2009 at 00:05, Martin v. Löwis mar...@v.loewis.de wrote:
I think the identification in the SSH keys is useless. It contains
strings like loe...@mira or ncogh...@uberwald, or even multiple
of them (ba...@wooz, ba...@resist, ...).
Right, so we'll put up the author map somewhere
On Tue, Apr 7, 2009 at 04:25, Steve Holden st...@holdenweb.com wrote:
I would remind you all that it's *very* necessary to make sure that
whatever finds its way into released code is indeed covered by
contributor agreements. The PSF (as the guardian of the IP) has to
ensure this, and so we
On Tue, Apr 7, 2009 at 08:25, Ben Finney ben+pyt...@benfinney.id.au wrote:
Remembering, of course, that full names don't follow any template
(especially not first-name last-name). The person's full name must be
treated as free-form text, since there's no format common to all.
Of course, unless
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano st...@pearwood.info wrote:
Perhaps you should ask Aahz what he thinks about being forced to provide
two names before being allowed to contribute.
Huh? The contributor's agreement list would presumably include real
names only (so Aahz is out of
On Tue, Apr 7, 2009 at 16:29, Aahz a...@pythoncraft.com wrote:
What you apparently are unaware of is that Aahz is in fact my full
legal name. (Which was clearly the point of Steven's post since he knows
that Teller also has only one legal name -- it's not common, but we do
exist.)
Ah, sorry
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz aja...@gmail.com wrote:
BTW, keep in mind some people will prefer to submit diff-generated,
non-hg patches. IMO, this use case should be supported before the
rich-patch one.
Sure, that will be in the PEP as well (and it's quite simple).
On Thu, Apr 9, 2009 at 07:15, Antoine Pitrou solip...@pitrou.net wrote:
The RFC also specifies a discrimination algorithm for non-supersets of ASCII
(“Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
On Thu, Apr 9, 2009 at 13:10, Antoine Pitrou solip...@pitrou.net wrote:
Sure, but then:
json.loads('[]')
[]
json.loads(u'[]'.encode('utf16'))
Traceback (most recent call last):
File stdin, line 1, in module
File /home/antoine/cpython/__svn__/Lib/json/__init__.py, line 310, in loads
On Thu, Apr 9, 2009 at 17:31, Aahz a...@pythoncraft.com wrote:
Please do subscribe to python-dev ASAP; I also suggest that you subscribe
to python-ideas, because I suspect that this is sufficiently blue-sky to
start there.
It might also be interesting to the unladen-swallow guys.
Cheers,
On Thu, Apr 16, 2009 at 11:54, Amaury Forgeot d'Arc amaur...@gmail.com wrote:
In my opinion:
arithmetic with months is a mess. There is no such month interval or
year interval with a precise definition.
If we adopt some kind of month manipulation, it should be a function
or a method, like you
On 22/04/2009 14:20, gl...@divmod.com wrote:
-1. On UNIX, character data is not sufficient to represent paths. We
must, must, must continue to have a simple bytes interface to these
APIs. Covering it up in layers of obscure encoding hacks will not make
the problem go away, it will just make it
On Wed, May 13, 2009 at 12:29 AM, Barry Warsaw ba...@python.org wrote:
I've been in favor of that for a while now. With the move to a DVCS (how's
that coming along?)
I've been rewriting PEP 374 about the Mercurial migration. Will post
here once it's ready for review.
Cheers,
Dirkjan
On Fri, May 15, 2009 at 8:32 AM, Jeroen Ruigrok van der Werven
asmo...@in-nomine.org wrote:
Agreed. Within FreeBSD's ports the installed package registration gets a MD5
hash per file recorded. Size is less interesting though, since essentially
this information is encapsulated within the hash.
On Sun, May 17, 2009 at 10:54 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Excluded Functions
--
Functions declared in the following header files are not part
of the ABI:
- cellobject.h
- classobject.h
- code.h
- frameobject.h
- funcobject.h
- genobject.h
- pyarena.h
On Mon, May 18, 2009 at 12:07 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I fail to see the relationship, so: no effect that I can see.
Why do you think that optimization efforts could be related to
the PEP 384 proposal?
It would seem to me that optimizations are likely to require data
On Mon, May 18, 2009 at 12:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
Unless I'm misunderstanding something, Martin doesn't advocate locking data
structures down (except a couple of outliers such as Py_buffer). An
ABI-compliant application mustn't tinker directly with Python's data
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs jar...@jaraco.com wrote:
I wanted to share this with the community in case anyone else runs into this
issue. Also, if there's a recommended procedure for addressing this issue
(and others that might arise due to non-native line endings), I'd be
On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray rdmur...@bitdance.com wrote:
The above statement seems like a really odd design choice, with the
potential for causing considerable developer coordination headaches.
Any Mercurial boffins want to talk about how this works in practice?
I'm
On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore p.f.mo...@gmail.com wrote:
Silly question, but given that Mercurial itself does *no* conversion,
and CRLF is the only valid form for that file, why shouldn't the file
be checked into the repository with CRLF endings, and that's the end
of it (apart
On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown c...@msu.edu wrote:
In my experience this kind automated stuff is too fragile to work
reliably specifically over time, which is what we would want -- fire
and forget.
You could a python-dev account in the tracker and allow people to nosy it.
Is
So, a while ago Martin von Löwis asked who would champion the
migration to Mercurial, and I volunteered. He asked me to produce a
PEP outlining which steps to take, which I've been working on. The PEP
is numbered 385, and is just about ready for your review. I'd really
welcome any sort of feedback
On Mon, Jun 8, 2009 at 16:29, Frank Wierzbickifwierzbi...@gmail.com wrote:
At PyCon, we discussed moving Jython's svn repository to Python's with
Martin von Löwis. I would think that Jython would live in Python's hg
repository in the same way as stackless and distutils. Has the
parallel
On Mon, Jun 8, 2009 at 21:57, Martin v. Löwismar...@v.loewis.de wrote:
See my other message. We need to collect SSH keys, and I don't mind
moving the Jython repository. OTOH, if the Jython repository gets
converted into hg right away, it's certainly (a little) less work.
Yeah, I guess if you
So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
so that calls to heads() by default will not return closed heads.
Unfortunately, this also means that any tags from those heads will not
be considered anymore. That seems inadvertent at best, and may be
should be reverted.
Sorry about that, got dev-lists mixed up in my head somewhere...
On Tue, Jun 9, 2009 at 16:52, Dirkjan Ochtmandirk...@ochtman.nl wrote:
So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
so that calls to heads() by default will not return closed heads.
Unfortunately, this
On Wed, Jun 17, 2009 at 12:27, abhishek goswamizeal_gosw...@yahoo.com wrote:
Can anyone clarify me. Please let me know also it is right forum or not.
This is not the right forum. This mailing list is about developing the
CPython interpreter.
For general questions, you may want to try the
On Thu, Jul 2, 2009 at 21:04, Brett Cannonbr...@python.org wrote:
If you have commit privileges on Python but are not subscribed to
python-committers, please let me know and I will subscribe you. Membership
on python-committers is mandatory as that's where we announce branch
freezes, etc.
On Thu, Jul 2, 2009 at 22:08, Brett Cannonbr...@python.org wrote:
Maybe you should just get the commit privileges now. Any objections?
Not from me, obviously.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
- First of all, I've got the basic conversion down, I've done it a few
times now, with progressively better results.
On Fri, Jul 3, 2009 at 01:01, Mark Hammondskippy.hamm...@gmail.com wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and it isn't clear to me how that would work with
On Fri, Jul 3, 2009 at 15:31, Mark Hammondmhamm...@skippinet.com.au wrote:
So we must work without effective EOL support? I fear we will end up like
the mozilla hg repo with some files in windows line endings and some with
linux. While my editing tools are good enough to preserve existing EOL
On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbullstep...@xemacs.org wrote:
I'll have to try them again now that 1.3 is out, but I found Mercurial
named branches fundamentally unsuited to release management.
Can you explain why, please? It's not clear from what you say below.
Ditto named
On Fri, Jul 3, 2009 at 23:41, Brett Cannonbr...@python.org wrote:
If we make it universal I say it should be '2.x' and '3.x'. The whole 'py'
prefix is redundant.
Right, I was aiming for /python/2.x and /python/3.x as well.
Actually, I currently have /cpython to also make CPython less special
On Fri, Jul 3, 2009 at 20:04, Brett Cannonbr...@python.org wrote:
Fine by me as long as people realize that if anything is questionable then
the switch will not happen. Getting this right takes precedence over any
deadline. And obviously we will need to do at least one live conversion on
On Sat, Jul 4, 2009 at 07:13, Nick Coghlanncogh...@gmail.com wrote:
I'd guess that the only way to keep those functional is to keep
svn.python.org around in read-only mode.
No, actually: the idea (I think I floated it in the PEP, as well), is
that I can write a simple extension for hgweb that
On Fri, Jul 3, 2009 at 17:17, Georg Brandlg.bra...@gmx.net wrote:
Do you have a key to the second column in that file? E.g. the difference
between strip and discard is not clear to me. strip partial?
strip == discard. strip = remove, merged should be obvious, keep-clone
means we'll keep the
On Sat, Jul 4, 2009 at 00:09, Martin v. Löwismar...@v.loewis.de wrote:
I would drop the roundup integration from the things that need to
be done pre-migration - there currently is no svn integration, so
not having it for hg is not a step backwards.
Yeah, I mean just the linking here.
In the
On Sat, Jul 4, 2009 at 00:37, Barry Warsawba...@python.org wrote:
Doesn't Mercurial support an Subversion bridge? Would it be possible to
provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, and
3.1? If so, then the release managers would simply have to cut their
releases
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburgm...@egenix.com wrote:
Is there a standard notation for hg revisions that roundup could
detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
(Sorry for my absence from the discussion for some time. I'll try to
update
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburgm...@egenix.com wrote:
Hmm, no prefix or suffix ?
No, not really. hg often shows revision integers as well, but as they
aren't globally consistent, they're of little value in communicating
changeset pointers.
So we'll always have to write see
On Wed, Jul 15, 2009 at 16:42, Peter
Hanecakpeter.hane...@alcatel-lucent.sk wrote:
So my subsequent question is: What can help me solve the writing part?
The XML-RPC protocol, as specified at [1], doesn't support integers
with more than 32 bits (in fact, the i4 alias can be used to make the
use
The diff below should reflect changes from the discussion we had last
time. Please review. (Some comments may be more appropriate for the
other threads I just kicked off.)
Cheers,
Dirkjan
Index: pep-0385.txt
===
--- pep-0385.txt
So, I've been not-working on this, which I feel bad about. Suffice it
to say the day job has required more of my time then usual for the
past few weeks. I want to get back into it, so let's start by
re-raising this issue, which Mark Hammond conveniently summarized
below.
On 4/07/2009 2:03 PM,
So PEP 385 proposes to clean up the old branches we still have lying
around in SVN.
This list of branch: action items is what I've come up with to do this
cleanup. Legend first:
- keep-clone means we'll keep that branch in a separate clone
- keep-named means we'll keep that branch as a named
On Tue, Aug 4, 2009 at 08:06, Martin v. Löwismar...@v.loewis.de wrote:
I use that as a branch to tell build slaves to clean out their
current checkouts. So keep-clone sounds right, assuming it is possible
to target buildslaves at either clones or branches (which, IIUC, would
be necessary
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
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?)
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,
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 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 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 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
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 Sat, Aug 8, 2009 at 22:22, A.M. Kuchlinga...@amk.ca wrote:
svn.python.org was deliberately not brought up again. The backups
were a few hours behind and missing the ~10 most recent commits. Not
disastrous, but it could probably mess up people's SVN trees, so after
some IRC discussion, the
On Tue, Aug 18, 2009 at 10:12, Martin v. Löwismar...@v.loewis.de wrote:
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.
I think the most important item here is currently the win32text stuff.
Mark
On Tue, Aug 18, 2009 at 13:32, Mark Hammondmhamm...@skippinet.com.au wrote:
I can make time, somewhat spasmodically, starting fairly soon. Might I
suggest that as a first task I can resurrect my old stale patch, and you can
arrange to install win32text locally and start experimenting with how
On Tue, Aug 18, 2009 at 21:46, Brett Cannonbr...@python.org wrote:
Can we possibly get these todo items in the PEP? I keep looking at the
PEP out of habit to see what the blockers are and they are not there,
at which point I have to dig up Martin's email.
Will do.
Cheers,
Dirkjan
On Fri, Aug 21, 2009 at 09:16, Mark Hammondskippy.hamm...@gmail.com wrote:
I'm resurrecting my patch to support a filter called 'none' (which is
turning out to be harder than I thought). Off the top of my head, it would
the following would give us a pretty solid solution:
* Finish my patch
On Fri, Aug 21, 2009 at 16:10, Dj Gilcreasedigitalx...@gmail.com wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you just have a hgrc file
that works the same as the
On Sat, Aug 22, 2009 at 01:17, Martin Geislerm...@lazybytes.net wrote:
In the general case, you can specify an extension to be enabled by
filename:
[extensions]
foo = ~/src/foo
So if I can enable an extension like that on your system, I might be
evil and commit a bad extension *and*
On 05/09/2009 17:09, Antoine Pitrou wrote:
Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox developers are Windows-based). I wonder
whether they have written their own extension, or if they simply rely on their
text editors to do the
On 05/09/2009 16:59, Stephen J. Turnbull wrote:
git has a nice filter-branch command, which would allow you to
automatically repair the problem (it works basically by checking out
each changeset and rerecording it with the appropriate commands). I
know bzr is growing something similar, so
On Sat, Sep 5, 2009 at 18:18, Martin v. Löwismar...@v.loewis.de wrote:
But it shouldn't happen often that the server refuses a push;
all errors should already be caught on the clients.
We could just mandate the same hook code as a commit hook.
Cheers,
Dirkjan
On Sat, Sep 5, 2009 at 18:25, Martin v. Löwismar...@v.loewis.de wrote:
I think that's the case. It's pretty much a Unix-only tool, like most of
the other DVCS implementations.
I know a lot of projects use Mercurial on Windows as well, I'm not
aware of any big problems with it.
FWIW, I tried
On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen pe...@digip.org wrote:
Generally speaking, it's more useful for the checkin metadata to
reflect who actually did the checkin, since that's the most useful
information for the tracker and buildbot integration.
At least in git, the commit metadata
On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull step...@xemacs.org wrote:
This is still a big mess in Gentoo and MacPorts, though. MacPorts
hasn't done anything about ceating a transition infrastructure AFAICT.
Gentoo has its eselect python set VERSION stuff, but it's very
dangerous to set
On Wed, Nov 23, 2011 at 13:21, Stephen J. Turnbull step...@xemacs.org wrote:
Problems like what?
Like those I explained later in the post, which you cut. But I'll
They were in a later post, I didn't cut them. :)
Please create a connection to your distro by filing bugs as you
On Fri, Dec 9, 2011 at 09:02, Stefan Behnel stefan...@behnel.de wrote:
a) The stdlib documentation should help users to choose the right tool right
from the start.
b) cElementTree should finally loose it's special status as a separate
library and disappear as an accelerator module behind
On Fri, Dec 16, 2011 at 10:17, Eli Bendersky eli...@gmail.com wrote:
Do we have buildbots that build Python with Clang instead of GCC? The reason
I'm asking is that Clang's diagnostics are usually better, and fixing all
its warnings could nicely complement fixing GCC's qualms.
The box running
On Sat, Dec 17, 2011 at 12:53, Maciej Fijalkowski fij...@gmail.com wrote:
Note that unlike some other more advanced approaches, slots do change
semantics. There are many cases out there where people would stuff
arbitrary things on stdlib objects and this works fine without
__slots__, but will
On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou solip...@pitrou.net wrote:
If this documentation is to be used by other python implementations,
then mentions of performance are outright harmful, since the
performance characteristics differ quite drastically. Written in C is
also not a part of
On Tue, Dec 20, 2011 at 11:27, Terry Reedy tjre...@udel.edu wrote:
And I remember that Guido has
asked that the manual not discuss big O()
behavior of the methods of builtin classes.
Do you know when/where he did that? It seems useful to know that on
CPython, list.insert(0, x) will become slow
On Wed, Dec 21, 2011 at 08:16, Chris Withers ch...@simplistix.co.uk wrote:
What's the general consensus on supporting Python 2.5 nowadays?
Do people still have to use this in commercial environments or is
everyone on 2.6+ nowadays?
This seems rather off-topic for python-dev.
FWIW, on Gentoo
On Tuesday, January 17, 2012, Antoine Pitrou solip...@pitrou.net wrote:
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people involved in the
release process, and maintainers from third-party distributions of
Python.
As a
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw ba...@python.org wrote:
Identifying the use cases are important here. For example, even if it were a
lot slower, Mailman wouldn't care (*I* might care because it takes longer to
run my test, but my users wouldn't). But Bazaar or Mercurial users would
1 - 100 of 273 matches
Mail list logo
