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 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 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 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 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 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 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 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, 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 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 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 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 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 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 Mon, Jan 7, 2013 at 5:57 PM, Lennart Regebro wrote:
> Will this help the makers of distributions, like Ubuntu etc? If that is the
> case, then it might be worth doing, otherwise I don't think it's very
> useful.
As a Gentoo packager, I think it's useful.
Cheers,
Dirkjan
_
On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes wrote:
> The second PEP addresses key derivation functions for secure password
> hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the
> standard library.
Hashing only? I was hoping you would also include PKCS1 RSA primitives.
Cheers,
On Sat, Dec 29, 2012 at 11:45 AM, Antoine Pitrou wrote:
>> I'm still a fan of *always* shipping fallback tzdata, regardless of
>> platform. The stdlib would then look in three places for timezone data
>> when datetime.timezone was first imported:
>>
>> 1. the "tzdata-update" database
>> 2. the OS
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro wrote:
>> Why not keep a bit more of the pytz API to make porting easy?
>
> The renaming of the timezone() function to get_timezone() is indeed small,
> but changing pytz.timezone(foo) to timezone.timezone(foo) is really
> significantly easier than
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro wrote:
> Proposal
>
>
> The time zone support will be implemented by a new module called `timezone``,
> based on Stuart Bishop's ``pytz`` module.
I wonder if there needs to be something here about how to port from
pytz to the new timezone
On Tue, Nov 13, 2012 at 4:00 PM, Daniel Holth wrote:
> I'm willing to go ahead and move any mention of signing algorithms into a
> separate PEP, leaving only the basic manifest hash vs. file contents
> verification under the auspices of this PEP.
>From the discussion so far, that seems like the s
On Tue, Oct 23, 2012 at 7:46 AM, wrote:
> That's exactly what I want: it (PEP 427) should use one of the algorithms
> that is built-in (into web signatures). Web signatures give a choice of
> three algorithms; yet Daniel proposes to deviate and use a non-builtin
> algorithm.
>
> None of the algor
On Thu, Oct 4, 2012 at 12:32 PM, Christian Heimes wrote:
> Two days ago NIST announced the SHA-3 contest winner. My wrapper of
> keccak https://bitbucket.org/tiran/pykeccak/ is almost ready and just
> needs some cleanup and more tests. Once it's done I'll remove the Python
> 3.2 and 2.x compatibil
On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote:
> Since explicit is better than implicit, I *wouldn't* want to see
> magical side affects where merely installing the database from PyPI,
> or switching from Windows to Linux caused different behaviour.
I think that would be a pain. What you're
On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro wrote:
> A year is no age for a Python installation. A customer of mine has one
> website developed in 2003, still running on the same server. It runs Python
> 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7
> from 2008.
Ri
On Mon, Oct 1, 2012 at 9:02 AM, Lennart Regebro wrote:
> I don't want to default to a database that is guaranteed to be out of date.
> I don't see the purpose. This is also why I'm skeptical at including the
> data on Windows.
I think that would be a little too pure to be practical. There are
man
On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote:
> Can't we simply include the Olson database in Windows installers?
We probably can, but the problem is that it's updated quite often (for
example, in 2011, there were about 14 releases; in 2009, there were
21). So you'd want to have a mechan
On Sun, Sep 30, 2012 at 2:47 PM, Lennart Regebro wrote:
> What do you say? Is this a path worth pursuing?
+1. It's the kind of low-level thing that should be solved in the
stdlib as far as possible, and the pytz interface is as stable as the
stdlib's.
Cheers,
Dirkjan
___
On Mon, Sep 24, 2012 at 6:39 PM, Christian Heimes wrote:
> You proposed gave me another idea. What do you think about SPDY support
> in the stdlib? It's the next step after HTTP 1.1.
I'd wait it out a bit. SPDY is currently iterating, and there's an
effort to define HTTP 2 that will likely supers
On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
> So I prefer to hold it and have a solid implementation in the stldib. The
> only thing I am asking is to retain ourselves to do *anything* in distutils
> and continue to declare it frozen, because I know it will be tempting to do
> stuff there
On Tue, Jun 19, 2012 at 11:46 PM, Éric Araujo wrote:
> I don’t think (a) would give us enough time; we really want a few months
> (and releases) to hash out the API (most notably with the pip and buildout
> developers) and clean the bdist situation. Likewise (c) would require
> developer (my) ti
On Tue, Jun 5, 2012 at 5:07 PM, Guido van Rossum wrote:
> In fact, we might go further and define fromtimestamp() to do the same
> thing. Then the only difference between the two would be what timezone
> they use if there is *no* tzinfo. That's fine with me.
Yeah, that sounds good.
Cheers,
Dirk
On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote:
> For datetimes with tzinfo, dt.totimestamp() should return (dt -
> epoch).total_seconds() where epoch is
> datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for
> timezones without tzinfo, a similar calculation should be performed
>
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan wrote:
> My perspective is that if I'm dealing with strictly absolute time, I
> should only need one import: datetime
>
> If I'm dealing strictly with relative time, I should also only need
> one import: time
Can you define "relative time" here? The te
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting datetimes to timestamps
rather painful; IMO it shou
On Mon, May 7, 2012 at 9:49 PM, Antoine Pitrou wrote:
> I guess a long time ago, threading support in operating systems wasn't
> very widespread, but these days all our supported platforms have it.
> Is it still useful for production purposes to configure
> --without-threads? Do people use this op
On Wed, May 2, 2012 at 10:43 AM, Larry Hastings wrote:
> Do we officially support any C compilers that *don't* permit "intermingled
> variable declarations and code"? Do we *unofficially* support any? And if
> we do, what do we gain?
This might be of interest:
http://herbsutter.com/2012/05/03/
On Fri, Mar 23, 2012 at 09:26, Stefan Krah wrote:
> I'll add the --with-system-libmpdec option with the caveat that
> changes will probably make it first into the libmpdec shipped
> with Python, see also:
>
> http://bugs.python.org/issue7652#msg155744
Sounds good, thanks!
Cheers,
Dirkjan
__
On Wed, Mar 21, 2012 at 23:22, Victor Stinner wrote:
>>> http://hg.python.org/cpython/rev/730d5357
>>> changeset: 75850:730d5357
>>> user: Stefan Krah
>>> date: Wed Mar 21 18:25:23 2012 +0100
>>> summary:
>>> Issue #7652: Integrate the decimal floating point libmpdec libr
On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote:
> OK, that seems to be the main point people make... let me see if I can
> come up with a better compromise.
Would it be possible to limit the width of the page? On my 1920px
monitor, the lines get awfully long, making them harder to read.
Cheer
On Mon, Feb 27, 2012 at 19:53, Victor Stinner
wrote:
> A frozendict type is a common request from users and there are various
> implementations. There are two main Python implementations:
Perhaps this should also detail why namedtuple is not a viable alternative.
Cheers,
Dirkjan
___
On Mon, Feb 20, 2012 at 16:27, Antoine Pitrou wrote:
>> Should it be net.ipaddress instead of just ipaddress?
>>
>> Somewhat nested is better than fully flat.
>
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request impor
On Mon, Feb 20, 2012 at 14:23, Nick Coghlan wrote:
> I don't personally think the module API needs the provisional
> disclaimer as the core functionality has been tested for years in
> ipaddr and the API changes in ipaddress are just cosmetic ones either
> for PEP 8 conformance, or to make the API
On Wed, Feb 15, 2012 at 10:11, "Martin v. Löwis" wrote:
>> My primary concern with the PEP is adding to users confusion when they have
>> to
>> handle (at least) 5 different types[*] that represent time in Python.
>
> I agree with Barry here (despite having voiced support for using Decimal
> befo
FWIW, I'm with Barry on this; doing more with the datetime types seems
preferable to introducing yet more different stuff to date/time
handling.
On Mon, Feb 13, 2012 at 19:33, Victor Stinner wrote:
> Oh, I forgot to mention my main concern about datetime: many functions
> returning timestamp have
On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote:
> I didn't get a response from him to my e-mails since early 2010. Maybe
> others have more luck if they try, but I don't have the impression that
> waiting another two years gets us anywhere interesting.
>
> Given that it was two months ago that
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw 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 care
> a lot.
On Tuesday, January 17, 2012, Antoine Pitrou 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 Gentoo packager
On Wed, Dec 21, 2011 at 08:16, Chris Withers 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 we're just now gett
On Tue, Dec 20, 2011 at 11:27, Terry Reedy 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 as the list g
On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou 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 specification
On Sat, Dec 17, 2011 at 12:53, Maciej Fijalkowski 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 stop working
On Fri, Dec 16, 2011 at 10:17, Eli Bendersky 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 my buildslave
On Fri, Dec 9, 2011 at 09:02, Stefan Behnel 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 ElementTree.
An at
On Wed, Nov 23, 2011 at 13:21, Stephen J. Turnbull 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
> > encounter them?
>
>
On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull 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 to a Python
On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen 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 contains
On Sat, Oct 8, 2011 at 21:47, Toshio Kuratomi wrote:
> I have some similar code in kitchen:
> http://packages.python.org/kitchen/api-overview.html
It also sounds similar to six:
http://pypi.python.org/pypi/six
Avoid all the duplicate efforts would certainly make sense.
Cheers,
Dirkjan
___
On Mon, Aug 29, 2011 at 18:24, Barry Warsaw wrote:
>>Also, this PEP makes me wonder if there should be a way to distinguish
>>between language PEPs and (CPython) implementation PEPs, by adding a
>>tag or using the PEP number ranges somehow.
>
> I've thought about this, and about a similar split be
On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote:
> result strings. In PEP 393, a buffer must be scanned for the
> highest code point, which means that each byte must be inspected
> twice (a second time when the copying occurs).
This may be a silly question: are there things in place to
On Wed, May 25, 2011 at 15:41, Barry Warsaw wrote:
> I think it would be a nice feature, and I can see the conflict. OT1H you want
> to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a
> new, arguably more difficult to discover, function. Given those two choices,
> I still
On Tue, May 17, 2011 at 19:40, Jeremy Dunck wrote:
> So, to start with, is there a maintainer for the json module, or how
> should I go about discussing implementing this solution?
Your subject states that there is an actual bug in the json module,
but your message fails to mention any actual bug
On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
> What you're proposing doesn't address the question of who is going to
> do the ongoing maintenance. Bob apparently isn't interested in
> maintaining stdlib code, and python-dev members aren't interested in
> maintaining simplejson (assuming it
On Fri, Apr 1, 2011 at 02:30, Antoine Pitrou wrote:
> This is something you need to discuss with the Mercurial project.
> See http://mercurial.selenic.com/bts/ and
> http://mercurial.selenic.com/wiki/ContributingChanges
There's a lot you can change by just starting a new set of templates
(with Me
On Thu, Mar 24, 2011 at 12:40, Jameson Quinn wrote:
> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> want to save 3 characters/5 keystrokes for item access. Other languages such
> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> why not py
On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
wrote:
> Just as an aside, and I might be wrong. But reading through what strip
> does, (and from my knowledge of the disk layout) it can't actually be
> atomic. So if you kill it at the wrong time, it will have corrupted your
> repository.
>
> At
On Wed, Mar 23, 2011 at 04:39, wrote:
>
> Dirkjan> The right solution here is to use different clones for
> Dirkjan> different projects/areas. The proposed interpreter/stdlib
> Dirkjan> split, for example, might reduce contention (although I imagine
> Dirkjan> it would reduce it only
On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull wrote:
> No, software engineering scales up to a point, then it breaks and you
> need a serialization scheme. The problem is not the DVCS, it's the
> demand for a *centralized*, authoritative, safe, stable version. DVCS
> can scale at least to L
On Tue, Mar 22, 2011 at 21:56, Paul Moore wrote:
> On 22 March 2011 20:44, Dirkjan Ochtman wrote:
>> The right solution here is to use different clones for different
>> projects/areas.
>
> I'm not trolling here, just trying to learn something about Mercurial.
> Wou
On Tue, Mar 22, 2011 at 19:29, R. David Murray wrote:
> Note that svnmerge broke at exactly the same scale point, for exactly the
> same reason: every svnmerge touched root properties, thereby effectively
> serializing access to the tree. There were lots of curses from people
> trying to svnmerg
On Sun, Mar 13, 2011 at 12:25, Nick Coghlan wrote:
> I'm experimenting with creating some local branches for things I'd
> like to work on during the sprints this week, and have a couple of
> questions about the associated workflow.
By local branches, do you mean named branches (using the hg branc
On Tue, Mar 8, 2011 at 10:45, Stefan Krah wrote:
> Hi,
>
> I can't update to v2.7 in the new cpython repository:
>
> $ hg up v2.7
> abort: unknown revision 'v2.7'!
>
> Am I missing something here? My goal is to get the same directory state
> as from this command:
>
> svn co http://svn.python.org/p
On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou wrote:
> For the record, the reason these emails look a bit strange (and appear
> to be pushed by Dirkjan (sorry)) is that they were done directly on the
> server with the settings of the local user "hg".
FWIW, I have a tiny extension at work that can
On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote:
> If there are hundreds of them, it's far from trivial. I don't even know
> how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to extract into
a clone (at least that's how I was planning to do it, no
On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:
> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).
Unnamed heads are trivial to convert to clones.
Cheers,
Dirkjan
On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou wrote:
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
Sorry everyone for taking so long on the conversion. Looks like
Antoine and Georg have more time and ener
On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote:
> Do you have a public list of stuff to be done (i.e. Roadmap)?
> BTW, what is the size of Mercurial clone for Python repository?
There is a TODO file in the pymigr repo (though I think that is
currently inaccessible).
I don't have a recent
On Tue, Feb 15, 2011 at 09:30, "Martin v. Löwis" wrote:
> I'm going to perform a Debian upgrade of svn.python.org on Friday,
> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> that time. The outage shouldn't be longer than an hour.
It seems hg is no longer installed on dins
On Fri, Feb 18, 2011 at 00:17, "Martin v. Löwis" wrote:
> I think it's fair to say that the project currently rests, lacking
> a project lead. The most recent timeline is that conversion should
> be completed by PyCon, and, failing that, should start at PyCon.
It's not exactly resting; I've been
On Mon, Feb 7, 2011 at 15:46, Antoine Pitrou wrote:
> I'm not advocating anything in particular really. I think creating a
> named branch "foo" (or a bookmark? I've never used them but it sounds
> like they might do the trick) and then using "hg di -r py3k" to get the
> diff against upstream is ve
On Mon, Jan 31, 2011 at 22:50, anatoly techtonik wrote:
> If you don't want to receive a stupid answer, why don't you read the
> link and say what you don't like in this approach in a constructive
> manner?
Mercurial is a much smaller project, so it has different needs. It
would be nice if you co
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc wrote:
> And http://hg.python.org/cpython/ probably needs an initial "dummy merge"
> on every branch.
Yes, the present delays are all about getting that right.
Cheers,
Dirkjan
___
Python-Dev mailing
On Thu, Dec 2, 2010 at 20:24, Sridhar Ratnakumar
wrote:
> Also note that the dependency information is incomplete.
Also, a python3 version of chardet is available (from the website
only, looks like).
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-
On Fri, Nov 19, 2010 at 15:56, Nick Coghlan wrote:
> That's enough to make folks like me somewhat nervous as to whether or
> not we're actually going to have a usable source control system come
> December 12.
Yes, I've been negligent about updating the PEP. I'll try do so next
week. Georg, if you
On Wed, Nov 17, 2010 at 13:51, Jesus Cea wrote:
> I can't find the mail now, but I remember that months ago the Mercurial
> migration schedule was mid-december. I wonder if there is any update.
I'm still aiming for that date. I've had some problems getting the
test repository together. It's almos
On Sun, Nov 7, 2010 at 13:15, Dirkjan Ochtman wrote:
> Yeah, Martin has things for buildbot worked out. Notes about this are
> in the hg.python.org/pymigr repository.
I meant Georg here, of course. Sorry, Georg!
Cheers,
Dirkjan
___
Python-Dev m
On Sun, Nov 7, 2010 at 12:24, Trent Nelson wrote:
> Titus, for example, alluded to some nifty way for a committer to push his
> local hg branch/changes somewhere, such that it would kick off builds on
> multiple platforms in the same sorta' vein as point 2, but able to leverage
> cloud resources l
On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis" wrote:
> I don't feel like producing a complete list of build steps; the entire
> process takes about four hours.
So is most of this scripted, or is there just a process in your head?
> The steps that are difficult to automate are:
> - code signin
On Sat, Oct 30, 2010 at 05:22, Nick Coghlan wrote:
> Ultimately, the frequency of releases comes down to the burden on the
> release manager and the folks that build the binary installers. Any
> given RM is usually only responsible for one or two branches, but the
> same two people (Martin and Ron
On Fri, Oct 29, 2010 at 21:54, Barry Warsaw wrote:
> Another quick thought. What would people think about regular timed releases
> if python 2.7? This is probably more a question for Benjamin but doing
> sonmight provide better predictability and "customer service" to our users. I
> might like
On Thu, Oct 28, 2010 at 08:48, Georg Brandl wrote:
> I believe we'll eventually have the ability to create user repos as well, so
> that Kristjan can simply put his branch into one of these and still have it
> on hg.python.org.
+1.
Cheers,
Dirkjan
___
On Fri, Oct 22, 2010 at 11:06, Georg Brandl wrote:
> If everything goes as planned, there won't be many commits between RC2 and
> final, so it should be fine. The svn repos won't be removed anyway, so
> making a release from them is still possible.
Okay, but accepting commits in both SVN and hg
On Fri, Oct 22, 2010 at 00:57, Benjamin Peterson wrote:
> In the interest of getting 3.1.3 and 2.7.1 out by next year, here's a
> tentative release schedule:
>
> November 13th - RC1
> November 27th - RC2
> December 11th - Final
The last one might clash with the hg migration a bit, do we need to
w
Okay, we're getting somewhere here.
I've been conferring with Georg on when we can do the conversion. He's
done some testing with the buildbot setup, which seems to be mostly
done. He also completed preliminary ports of the hooks used in the SVN
repository. He managed to convince me that we're at
On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote:
> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1.
So, sorry for backing up to this, but isn't it true that many projects
do custom stuff in their setup.py that they wouldn't be able to do in
setup.cfg? Is the goal really to mak
2010/10/8 Fred Drake :
> Georg:
>> What happened to "python setup.py action"? Or is this a step towards
>> not requiring setup.py at all?
>
> I'm in favor of add a top-level setup module that can be invoked using
> "python -m setup ...". There will be three cases:
>
> - d2 projects without a setu
On Fri, Oct 8, 2010 at 09:05, Tarek Ziadé wrote:
> The feedback I received for this is pretty clear: people want a single
> script that can be called directly. e.g.
>
> $ distutils2 depgraph
> $ distutils2 install
> $ distutils2 run command
>
> Fair enough, I can add that script in the project and
On Thu, Oct 7, 2010 at 00:53, Trent Mick wrote:
> 1. Change `difflib.unified_diff` to emit:
>
> ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n',
> '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline
> at end of file']
>
> instead of:
>
> ['--- \n', '+++ \n',
On Tue, Oct 5, 2010 at 17:06, "Martin v. Löwis" wrote:
>> I can probably run a build slave on one of my boxes (Gentoo, Athlon 64
>> x2). Where are the setup docs?
>
> http://wiki.python.org/moin/BuildBot
Cool, can you get me username/passwd?
Cheers,
Dirkjan
_
1 - 100 of 284 matches
Mail list logo
