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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
Alexandre Vassalotti wrote:
> C doesn't have an exponentiation operator. You use the pow() function,
> instead:
Wouldn't it make more sense, then, to have unary +/- have higher
precedence than the ** operator, so that -3**2 == 9?
Regards,
Dirkjan
__
Paul Moore wrote:
> That looks like it. I'll work up a patch and submit it to the
> Mercurial developers.
I've already got one going.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Barry Warsaw wrote:
Once again, I've gone through the release blocker issues and knocked
anything that doesn't specifically affect 2.6 to deferred blocker. This
leaves us with 7 open blocking issues.
I noticed you deferred issue3723. I wonder how this "doesn't affect" 2.6
when it appears I
Brett Cannon python.org> writes:
> So my first choice for Mercurial fell through. If you would like to
> represent Mercurial, let me know.
I can represent Mercurial, though it may be (more?) helpful if some of the
Mercurial-using python-dev regulars can occasionally step in.
Cheers,
Dirkjan
__
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
Martin v. Löwis 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 communi
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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, 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 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
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, 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
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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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, 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 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
_
201 - 284 of 284 matches
Mail list logo
