On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote:
> BTW, this workload was exacerbated by my foolish desire to keep the revision
> DAG nice and clean. So I was actually starting over from scratch and
> redoing all the cherry-picking every couple of days, just so I could get all
> the cherry-
Tae Wong,
Please don't speak on behalf the Gentoo Python team.
Everyone else, sorry for this, they are definitely not actually
connected to our Gentoo team.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
On Tue, Feb 26, 2013 at 4:13 PM, Maciej Fijalkowski wrote:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main reason why people
On Thu, Apr 11, 2013 at 11:27 PM, Antoine Pitrou wrote:
> Hmm, I think I'm tending towards the latter right now.
You might also want to look at what Mercurial does. As a
cross-platform filesystem-oriented tool, it has some interesting
issues in the department of casefolding.
Cheers,
Dirkjan
___
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote:
> Ordered comparisons between enumeration values are *not* supported. Enums
> are
> not integers (but see `IntEnum`_ below)::
>
> >>> Colors.red < Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
>
On Thu, Apr 18, 2013 at 11:17 PM, Ronald Oussoren
wrote:
> Stripping libffi from python's source tree would be fine by me, but would
> require testing with upstream libffi. AFAIK system libffi on osx wouldn't be
> goog enough, it doesn't work properly with clang.
If you mean http://bugs.python.
On Tue, May 14, 2013 at 12:14 PM, Ben Hoyt wrote:
> I don't think that's a big issue, however. If it's 3-8x faster in the
> majority of cases (local disk on all systems, Windows networking), and
> no slower in a minority (sshfs), I'm not too sad about that.
Might be interesting to test something
On Fri, May 24, 2013 at 10:23 PM, R. David Murray wrote:
> Gentoo has a (fairly complex) driver script that is symlinked to all
> of these bin scripts. The system then has the concept of the
> "current python", which can be set to python2 or python3. The default
> bin then calls the current defa
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only wi
On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou wrote:
>> (For those that haven't seen it, RhodeCode seems broadly comparable to
>> BitBucket feature wise, but because of the way it is licensed, the
>> source code is freely available to all, and running your own instance
>> is free-as-in-beer for
On Thu, Sep 5, 2013 at 10:30 PM, Tres Seaver wrote:
> +1 for supporting Persona as an alternative to OpenID on all *.python.org
> servers.
BTW, I'd be happy to assist with any Persona RP implementations for
python.org services. The MDN docs are pretty good, I got my first RP
going in just a few h
On Thu, Sep 5, 2013 at 10:33 PM, Glenn Linderman wrote:
> Is there a Python implementation of Persona I can install on my web server?
If you mean to use your web server as an Identity Provider, try this:
https://bitbucket.org/djc/persona-totp
It currently only implements TOTP-based authenticati
On Thu, Sep 5, 2013 at 10:57 PM, Donald Stufft wrote:
> Not that it changes this statement at all but you wouldn't expect to see a
> Persona login
> for gmail as persona solves the problem that people don't think of urls as
> personal
> identifiers by replacing it with emails. So Gmail would be
On Tue, Sep 10, 2013 at 11:28 AM, Antoine Pitrou wrote:
> On the tracker issue, it seems everyone agreed on the principle. There
> is some bikeshedding left to do, though. So here are the reasonable
> naming proposals so far:
>
> - transformkeydict
> - coercekeydict
> - transformdict
> - coercedic
On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote:
> If you wonder about the lack of progress reports on pep-431, this is
> because of a lack of progress. I simply haven't had any time to work
> on this. I considered make a kickstarter so I could take time off from
> working, but to be honest,
On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes wrote:
> Benchmark of 1000 times "python -c ''"
>
> Python 3.4dev with all my experimental patches:
>
> Avg: 0.705161 -> 0.443613: 1.59x faster
>
> 2.7 -> 3.4dev:
>
> Avg: 0.316177 -> 0.669330: 2.12x slower
>
> 2.7 -> 3.4dev with all my patches
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 j
On 02/03/2009 22:28, Georg Brandl wrote:
We're already quite inconsistent with type name casing in the collections
module, so it wouldn't matter so much. (Though I'd find symmetry with
defaultdict pleasing as well.)
Since the odict naming is already so prevalent in the wild, it seems to
me li
On 04/04/2009 17:40, Aahz wrote:
With Brett's (hopefully temporary!) absence, who is spearheading the
Mercurial conversion? Whoever it is should probably take over PEP 374
and start updating it with the conversion plan, particularly WRT
expectations for dates relative to 3.1 final and 2.7 final.
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. clone
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 fores
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 c
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 i
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 th
(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 many
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 branc
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 enoug
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, whet
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 ca
On Mon, Apr 6, 2009 at 00:48, Mark Hammond 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 be useful if someone ch
On Mon, Apr 6, 2009 at 04:27, 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 magnitude mor
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti
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 contributor's agreeme
Alexandre Vassalotti 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 specific
Martin v. Löwis 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. Of
Alexandre Vassalotti 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 server. You m
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy 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
> whitespace prob
On Mon, Apr 6, 2009 at 11:14, Philippe Fremy 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
> working versions find t
On Mon, Apr 6, 2009 at 13:55, Michael Foord 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 checkin...
Sure, it's a prob
On Tue, Apr 7, 2009 at 00:05, "Martin v. Löwis" 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 with the ema
On Tue, Apr 7, 2009 at 04:25, Steve Holden 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 have to find a way
On Tue, Apr 7, 2009 at 08:25, Ben Finney 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 we lock it down through
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano 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 luck), but the names wo
On Tue, Apr 7, 2009 at 16:29, Aahz 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 about that. But
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz 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).
Cheers,
Dirkjan
__
On Thu, Apr 9, 2009 at 07:15, Antoine Pitrou 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
> stream is UTF-8, UTF-
On Thu, Apr 9, 2009 at 13:10, Antoine Pitrou wrote:
> Sure, but then:
>
json.loads('[]')
> []
json.loads(u'[]'.encode('utf16'))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/antoine/cpython/__svn__/Lib/json/__init__.py", line 310, in loads
> return _defau
On Thu, Apr 9, 2009 at 17:31, Aahz 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,
Dirkjan
_
On Thu, Apr 16, 2009 at 11:54, Amaury Forgeot d'Arc 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 would do
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 ha
On Wed, May 13, 2009 at 12:29 AM, Barry Warsaw 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
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. Remove one byte from
On Sun, May 17, 2009 at 10:54 PM, "Martin v. Löwis" 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
> - py
On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis" 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
structure changes
On Mon, May 18, 2009 at 12:43 AM, Antoine Pitrou 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
> structures,
> but us
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs 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
> interested
On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray 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 guessing that's just bec
On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore 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 from misconfigured
On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown 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 there
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 Wierzbicki 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 project strategy been
On Mon, Jun 8, 2009 at 21:57, "Martin v. Löwis" 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 move it to a se
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. Concep
Sorry about that, got dev-lists mixed up in my head somewhere...
On Tue, Jun 9, 2009 at 16:52, Dirkjan Ochtman 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 also m
On Wed, Jun 17, 2009 at 12:27, abhishek goswami 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 comp.lang.python newsgroup.
On Thu, Jul 2, 2009 at 21:04, Brett Cannon 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.
Would it be help
On Thu, Jul 2, 2009 at 22:08, Brett Cannon 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
http://mail.python.org/mailman/listinfo/
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 Hammond 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
> the existing win32text
On Fri, Jul 3, 2009 at 15:31, Mark Hammond 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
> styles, I've found m
On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull 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 branches. The proble
On Fri, Jul 3, 2009 at 23:41, Brett Cannon 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
among it's peers
On Fri, Jul 3, 2009 at 20:04, Brett Cannon 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
> python.org hardwar
On Sat, Jul 4, 2009 at 07:13, Nick Coghlan 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 knows the mapping
On Fri, Jul 3, 2009 at 17:17, Georg Brandl 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 branch, in a
On Sat, Jul 4, 2009 at 00:09, "Martin v. Löwis" 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 first sentenc
On Sat, Jul 4, 2009 at 00:37, Barry Warsaw 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 from the svn
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg 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 the PEP and s
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburg 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 deadbeefdeadbeefff fo
On Wed, Jul 15, 2009 at 16:42, Peter
Hanecak 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 of 4 bytes explicit). So, eit
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, Ma
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 bran
On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis" 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 anyway, since we 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
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 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
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
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 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
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 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 Sat, Aug 8, 2009 at 22:22, A.M. Kuchling 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 decisio
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" 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 Hammond said he w
On Tue, Aug 18, 2009 at 13:32, Mark Hammond 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 mixed
> line-endings ca
On Tue, Aug 18, 2009 at 21:46, Brett Cannon 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 Hammond 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 for 'none' as a filte
1 - 100 of 284 matches
Mail list logo
