Am 18.09.2010 15:27, schrieb Steve Holden:
> On 9/18/2010 9:21 AM, "Martin v. Löwis" wrote:
>> IT WILL BE NOT IN PREFERENCE TO DISTUTILS2.
>
> No need to shout.
I really felt that this otherwise wouldn't be heard - I tried
to say it a number of times before, and it
> Also could you provide me the master.cfg file (with obfuscated
> passwords) that is used by the Python buildbot master or tell me if it
> is in subversion somewhere?
Attached!
Regards,
Martin
# -*- python -*-
# This is a sample buildmaster config file. It must be installed as
# 'master.cfg' in
> Given that this came out rather unfortunately (even if the end result
> is the best that could have happened) I would recommend that in the
> future more attention is paid to "documenting" publicly that someone's
> being booted out was inevitable, by an exchange of messages on
> python-dev (or py
>> deputed tracker authority/ies. Not everyone has the same idea about how
>> to handle the various fields and processes. Who decides in cases of
>> disagreement?
>
> We discussed this a while back and I don't think we really have a tracker
> BD. Brett and Martin come closest, but mostly we jus
> Let me ask a question which I don't think has been asked in this
> thread: are there guidelines for tracker-trawlers? I'm never sure
> where to look for this kind of thing myself. If there's nothing,
> I'm happy to pen a dos-and-donts (which I might do anyway, simply
> as a blog entry...)
Can yo
Am 23.09.2010 11:43, schrieb Tim Golden:
> On 23/09/2010 10:38, "Martin v. Löwis" wrote:
>>> Let me ask a question which I don't think has been asked in this
>>> thread: are there guidelines for tracker-trawlers? I'm never sure
>>> where to look
> make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
> add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
> ensure other fields in the t
>>> add relevant keywords to make it easier to find in searches
>> -0. Going through old issues just to make sure the keywords are right
>> seems wasteful.
>>
>
> Hard as it may be to believe, we do have (and are trying to cultivate)
> people who want to contribute to Python and start by searching
Am 23.09.2010 16:33, schrieb Barry Warsaw:
> On Sep 23, 2010, at 10:16 AM, R. David Murray wrote:
>
>> I'd *much* rather edit rst files than futz with a web interface when
>> editing docs. The wiki also somehow feels "less official".
>
> There are dvcs-backed wikis, for example:
>
> https://lau
> There's no reason it *has* to be useless though. The Moin developer now has
> shell access, so if there are technical problems with wiki, like its theme,
> performance, or lack of features, we can get those fixed. If it's the content
> or organization that needs improvement, then we can recruit
> I have to agree with Jesse. We have too many wiki pages that are so
> out of date they're dangerous. They serve a purpose, and I think we
> should have a wiki in addition to the "official" documentation. This
> could be aggressively linked from it so people can comment on that
> documentation --
>> Asking every now and then "is this still an issue", or setting
>> the version number, doesn't really advance the issue.
>
>
> Setting Versions properly helps anyone searching for issues relevant to
> a particular version. If having a field set properly does not matter,
> then is should not be
> With an admin team behind it, you can also make more use of ACLs to
> flag certain parts of the wiki as "official" by making them only
> editable by certain people (e.g. only devs, only the triage team, only
> the wiki admins). But keeping those user lists up to date is itself
> something that re
Am 24.09.2010 00:39, schrieb Guido van Rossum:
> On Thu, Sep 23, 2010 at 3:35 PM, "Martin v. Löwis" wrote:
>>> With an admin team behind it, you can also make more use of ACLs to
>>> flag certain parts of the wiki as "official" by making them only
>&
> I assume this is unintended because (a) the docs weren't changed to
> warn about this; and, (b) it's wrong ;-)
It seems Jim is happy with (or has at least accepted) the behavior
change. Would you still like to see it fixed (or, rather, have the
2.6 state restored)?
I think it would be possible
Am 24.09.2010 23:22, schrieb Daniel Stutzbach:
> On Fri, Sep 24, 2010 at 4:09 PM, "Martin v. Löwis" <mailto:mar...@v.loewis.de>> wrote:
>
> I think it would be possible to have two versions of
> _PyGC_REFS_UNTRACKED, one being, say, -5.
> _PyGC_R
>> Guess the only way to settle this is look at the code, but I don't
>> care enough to bother. =)
>
> I'll bother Ezio when he's back. It just feels strange to me that the bit
> of statistic I feel is most interesting -- whether there are less open bugs
> at the end of the week than at the start
> Unfortunately, most sites using OpenID seem have an awkward login
> process. Maybe it's just me (I don't use OpenID much) but I expect
> that without a lot more handholding of new users, OpenID actually
> turns more people away than any other registration/login process.
So how do you like the Op
> I guess a better example would be
>
> old:
> open #1 #2
> closed #3
> new:
> open #1
> closed #2 #3 #4 #5
>
> which results in +2 for open (since #4 and #5 were opened) and +3 for closed
> (since #2, #4 and #5 were closed), however the total issue delta is +2. This
> is why I think th
>>> For me a major annoyance is the empty page with two links on wiki.python.org
>>> While it allows to tell new people that there is also a Jython wiki,
>>> my vision that it should be instead be oriented on existing
>>> contributors immediately providing instruments to work with Python
>>> wiki.
> Also, it's a horrible bug report, if that's what it is.
It's not a bug report, and I don't think it was meant to be
one. It started with "I wonder if", suggesting that it is
really a request for help.
What you read as a bug report was labeled "user story",
which I think is anatoly's way of sayi
> Redirect wiki.python.org to the Python wiki front page, and put the Jython
> wiki somewhere on its own (whether it's wiki.jython.org or not).
But that can't work: then off-site links into either wiki break.
Regards,
Martin
___
Python-Dev mailing list
Am 26.09.2010 00:48, schrieb Georg Brandl:
> Am 26.09.2010 00:16, schrieb "Martin v. Löwis":
>>> Redirect wiki.python.org to the Python wiki front page, and put the Jython
>>> wiki somewhere on its own (whether it's wiki.jython.org or not).
>>
>&g
Am 26.09.2010 03:45, schrieb P.J. Eby:
> I'm actually a bit surprised people are bringing this up now, since when
> I announced the plan to make these changes, I said that nothing would be
> changed that would break anything
I think people read this as "nothing would be changed, period."
However,
> Keywords are generally better than a restricted vocabulary for richness
> of content, but worse for finding the appropriate search term. You "pays
> yer money and takes yer chance".
I think you are unaware what a "roundup keyword" is, here.
> But without any smarts being applied to the problem
> 1) Registering via OpenID is a bit clumsy since there is a "Register"
> link that does not mention OpenID.
Thanks. Fixed.
> 2) The URL registered with the OpenID provider is a bit of a wart:
> "http://pypi.python.org/pypi?:action=openid_return"; vs.
> "http://bitbucket.org/";
You mean, as
> For example, it might be interesting to bring old release
> tags in line with newer tags (so Release_1_0 would become r10), or
> maybe use clean tags similar to what we do with hg itself (r266 would
> become just 2.6.6), or just remove some tags. Is this a good idea at
> all, or should we just le
Am 26.09.2010 13:58, schrieb Nick Coghlan:
> On Sun, Sep 26, 2010 at 8:16 AM, "Martin v. Löwis" wrote:
>> But that can't work: then off-site links into either wiki break.
>
> Georg isn't suggesting a general structural change, just a change to
> ha
> I've been talking about redirecting all the time, haven't I?
You said "put the Jython wiki somewhere on its own". That seemed to
suggest it won't be anymore at wiki.python.org/jython.
> * redirect from wiki.python.org to wiki.python.org/moin
>
> * (optionally) redirect from wiki.jython.org to
>> I think people read this as "nothing would be changed, period."
>
>> However, you did make substantial changes to the specification (or else
>> the whole exercise would have been pointless, I suppose, and you
>> couldn't have claimed that WSGI is now Python 3-friendly when it
>> previously was
> I'm sorry, but all this weasel-wording about how these changes aren't
> really changes and how this standard wasn't really a standard make me
> very uncomfortable. I'm happy approving Final status for the
> *original* PEP 333 and I'm happy to approve a new PEP which includes
> PJE's corrections.
> One point is to remove inconsistencies tied to CVS-era restrictions:
> the tags which correspond to (define) actual numbered releases have
> goofy names due to CVSism ('r266' is a ridiculously hard-to-figure-out
> alternative to '2.6.6').
>
> Given that nobody will be able to update checkouts in
Am 26.09.2010 12:54, schrieb Nick Coghlan:
> On Sat, Sep 25, 2010 at 9:20 AM, Tim Peters wrote:
> [MvL]
>>> I think it would be possible to have two versions of
>>> _PyGC_REFS_UNTRACKED, one being, say, -5.
>>> _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY would be what you get
>>> when you call PyObj
Am 26.09.2010 20:31, schrieb Terry Reedy:
> On 9/26/2010 12:54 PM, "Martin v. Löwis" wrote:
>
>> But then, if somebody volunteers to make these changes, I'm -0 to
>> the renaming (I slightly prefer calling even future release tags rXYZ).
>
> Except that r31
> No, Martin really meant "not possible": once basic auth is started,
> the browser prompts for username and password and you are in basic-auth
> land thereafter; the web server has *no way* to tell the browser to
> *stop* using basic auth.
Yes, but Scott proposed that OpenID users might fill in t
> The PEP still hasn't showed up on Python.org, though, so I'm wondering
> if maybe I broke something else somewhere.
See http://www.python.org/status/postcommitlog.txt
Error processing PEP None (./pep-.txt), excluding: (./pep-.txt):
"did not deal with u'Replaces' before having to handle
Am 27.09.2010 22:17, schrieb P.J. Eby:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>> All fixed.
>
> Nope.
Indeed. The immediate problem was that genpepindex tried to read
pep-, and didn't like it.
I worked around that in r85041, so that genpepindex now skips over
pep-.txt. Howeve
> Someone with web server access may want to double check the
> modification dates of the .txt files relative to the generated .html
> files for other PEPs though.
make will deal with that just fine. If a PEP was modified, svn up will
update the time stamp on the file. When then the rebuild fails,
> Because it's not clear to most of us on this thread what the failure
> modes and recovery strategies are? I know it's clear as mud to me how
> to debug these kinds of issues.
As a starting point, look at the postcommitlog. It should contain the
commands that got executed, and the error messages
> Well, one of the tradeoffs here is that Informational track allows
> something to grow into a solid standard without also having to pass the
> same level of up-front scrutiny and commitment that a Standards track
> item does. I rather doubt that either the DBAPI *or* WSGI would've
> passed that
Am 28.09.2010 05:45, schrieb Steve Holden:
> On 9/27/2010 11:27 PM, Benjamin Peterson wrote:
>> 2010/9/27 Meador Inge :
>>> which, as seen in the trace, is because the 'detect_encoding' function in
>>> 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string
>>> to tokenize 'first
> I certainly wouldn't be opposed to an API that accepts a string as well
> though.
Notice that this can't really work for Python 2 source code (but of
course, it doesn't need to).
In Python 2, if you have a string literal in the source code, you need
to know the source encoding in order to get t
> Do we expect Mercurial to require more, less, or about the same amount of
> babysitting as the current Subversion repository?
The ongoing effort is to manage write access; this is not going to
change with Mercurial.
With a hosted service, you still need someone who gives write
permissions to
> While I would personally love to see Rietveld declared the official
> core Python code review tool, I realize that since I wrote as a Google
> engineer and it is running on Google infrastructure (App Engine), I
> can't be fully objective about the tool choice -- even though it is
> open source, h
> That shouldn't be too hard. Someone just has to create an App Engine
> project and handle the deployment. I guess the trickiest part is
> making sure enough people have admin access so multiple people can
> update the website, especially if we run a modified copy so that
> bugs.python.org can pus
>> So perhaps we should just run our own Rietveld instance next to Roundup.
>
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that?
Most certainly. However, this works fairly well today already. If you
put [issue] into the Rietveld subject, it c
> I don't know how hg manages this, but can't we preserve the tag
> information of the tags that you've scheduled to be removed
> in some place that can easily be pulled in but doesn't
> affect the main repo size ?
Most certainly, and this is the plan already: we will keep the
subversion repositor
Am 30.09.2010 00:12, schrieb Antoine Pitrou:
> On Wed, 29 Sep 2010 23:58:05 +0200
> "Martin v. Löwis" wrote:
>>> That shouldn't be too hard. Someone just has to create an App Engine
>>> project and handle the deployment. I guess the trickiest part is
&
> The hard part is encouraging contributors to find the time and
> motivation to thoroughly review code that they aren't personally
> interested in (and perhaps not even familiar with).
Not sure how well 'tit for tat' schemes work - we *could* require
that people don't commit unreviewed changes, a
Am 30.09.2010 17:40, schrieb Senthil Kumaran:
>> On Thu, Sep 30, 2010 at 9:52 AM, wrote:
>>
>> Of course, this is only true if the core developers *do* submit to the
>> same
>> rules. Is anyone proposing that current core committers have all their
>> work reviewed before it is accept
Amaury just filed issue #1 yesterday; as counting started
with 1000, we are now into 9000 roundup issues.
I have become quite fond of roundup over the years, and would
like to thank Ka-Ping Yee, Richard Jones, and Erik Forsberg
for getting us here.
There are many contributions to this infrast
>>> With my branch, you'll end up with this in /tmp/python:
>>>
>>> bin/python3.2m - the normal build binary
>>> bin/python3.2dmu - the wide+pydebug build binary
>>> bin/python3.2m-config
>>> bin/python3.2dmu-config
>>
>> Do users really want to see such idiosyncratic suffixes?
>
Following up to the recent thread, I have now integrated Rietveld
into Roundup. This is a rough draft still, and highly experimental.
Please try it out, but expect that it may be necessary to discard
all data (including comments) to start over (of course, I'll try
to avoid having to do so).
The Ri
> Surely someone could volunteer an old Intel Mac to run some tests?
> (Actually, two someones -- we'd need separate machines for Leopard and
> Snow Leopard.) I'd be happy to stick it in a server room at PARC and
> keep an eye on it. (Right now I've got a rack full of old eMacs and a
> G5 running
> I'm already running a Jython buildslave on an Intel Mac Pro which is
> pretty underused - I'd be happy to run a CPython one there too, if
> it'd be worthwhile.
I think Bill was specifically after Snow Leopard - what system are you
using?
Regards,
Martin
Am 02.10.2010 22:42, schrieb Jesus Cea:
> On 30/09/10 22:41, Brett Cannon wrote:
>> Don't see why not, but those of us who use OpenID would need to start
>> caring about a password which would be unfortunate.
>
> +1. OpenID or OAuth is a must.
>
> Moreover, I am a bit worried of needing a google
> 1) who is the notification e-mail sent to when a review is published?
I haven't figured that out yet. I'm not even sure whether email gets
sent at all. I'll look into this a week from now, unless someone
resolves that earlier. But...
> I
> just tried on one of my patches and the e-mail came wit
Modified: tracker/instances/python-dev/config.ini.template
+[django]
+# generate on a per-instance basis
+secret_key = 'e...@4s$*(idwm5-87teftxlksckmy8$tyo7(tm!n-5x)zeuheex'
I assume the secrecy of this is rather irrelevant?
It's only the template. In the instance, you have to replace it with
We just lost Neal's AMD-64 build slave due to hardware
problems. There is another AMD6-64 slave in the pool, however,
it runs in a non-standard environment, so it shows test failures
at the moment.
Would anybody be willing to run a build slave on a machine that
you have available? The main requir
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
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
I feel that, only if a roundup issue has patch, the corresponding
rietveld issue be created, it is more helpful there and avoids
needless duplication.
I have changed that now.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:/
I have a fairly recent MacPro on Snow Leopard, which I
keep consistently up to date and its connected all the time. It has more
capacity then I can really find use for.
If its still needed, I can set up buildbot to run on it today.
That would be nice.
Is it all
pull/poll oriented, or does the
Am 05.10.10 20:15, schrieb Alexander Belopolsky:
I followed the review link from issue5109 to arrive at
http://bugs.python.org/review/5109/patch/179/325 . On the review page
I clicked on Modules/arraymodule.c> View for side-by-side diff and
got
Error fetching None/Modules/arraymodule.c?rev=831
Am 05.10.10 19:07, schrieb Antoine Pitrou:
On Tue, 05 Oct 2010 17:06:40 +0200
"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
By the way, is the distinction betwe
To simplify the task of contacting buildbot operators, would it be
worth having a "python-buildbot-owners" mailing list?
Depends on the traffic. It might spam those owners who are never the
target of any of these messages, because they are "well-behaving".
Do you really find it difficult to dete
I attempted to fix the branch at http://bugs.python.org/file18220 ,
but it did not trigger rietveld update. I assume you made "Tracker
Branch" editable on purpose, but there should be a way rietveld side
to know when this field is changed I think.
Please start submitting issues with the Rietv
Am 04.10.2010 03:56, schrieb Daniel Stutzbach:
> On Sat, Oct 2, 2010 at 3:55 PM, "Martin v. Löwis" <mailto:mar...@v.loewis.de>> wrote:
>
> I'll have to come up with a better way to determine the branch
> which a patch was created on.
>
>
&g
> As I said, most patches are supposed to be produced against py3k HEAD,
> so you could try just that as the primary heuristic.
I think this is impractical. There are tons of patches (the majority)
which are in the tracker and *not* against py3k head. So this heuristics
will only cover a small min
Am 08.10.2010 00:00, schrieb geremy condra:
> Seems like python.org has gone down and come back up a couple of times
> in the last few minutes, is this intentional?
Nothing on python.org suggests that this has actually happened. Could
it be that the issue is on your end?
Regards,
Martin
_
>>
>> Nothing on python.org suggests that this has actually happened. Could
>> it be that the issue is on your end?
>
> It's possible, but I was first notified that it was happening by
> someone literally 3000 miles away. It seems unlikely that we would
> both have had the same problem at the same
> FWIW, PyPI was inaccessible for some longish period of time this morning.
That I can confirm (assuming you are talking about the UTC night).
However, it stopped around 5:00 UTC, so it's clearly unrelated to
anything that happened reportedly 2 hours ago.
Regards,
Martin
_
Am 08.10.2010 09:21, schrieb Jeroen Ruigrok van der Werven:
> -On [20101008 01:22], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>> True. However, I really cannot see anything on the machines that
>> indicates some outage. I'm still unsure what "it"
Am 09.10.2010 01:35, schrieb Greg Ewing:
> Georg Brandl wrote:
>> The explanation is that everything that comes after "import" is
>> thereafter
>> usable as an identifier (or expression, in the case of dotted names) in
>> code. ".mymodule" is not a valid expression, so the question would be
>> how
> Any comments?
For 3.2, this is out of scope, because of the moratorium.
For later versions, I'd rather not see a builtin name polluting the
global namespace for this.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Am 08.10.2010 17:21, schrieb Michael Foord:
> On 08/10/2010 16:07, Barry Warsaw wrote:
>> On Oct 08, 2010, at 11:04 AM, Toshio Kuratomi wrote:
>>
>>> python-setup is a lot like python setup.py
>>> pysetup is shorter
>>> pyegg is even shorter :-)
>> wfm!
>
> To avoid any potential confusion, wfm
> So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on
> Windows please. (I'd really like a python-3.2.exe as well.)
Please submit a patch to the installer, then.
I'm still skeptical about adding PATH, because
a) I find that fairly invasive, and despise long paths myself
(it hur
> Assume, for the sake of the argument, that we patched the
> MSI so it (optionally) added the installing version of Python
> (and, optionally ./scripts) to the PATH. What, then, do we
> do with existing PATH entries which point to older/other Python
> installations? Option (a) says: clear them
> a
I have appointed Antoine Pitrou as the authority/manager
for which build slave are considered stable. If you want
to get a certain slave elevated or demoted, you have to
convince him.
I would also like to ask release managers to take the
stable list serious: test failures in a stable slave should
> And, of course, we'd like to get some of these Mac buildbots into the
> "stable" category, so that they are consulted for releases. The
> PPC Leopard and x86 Snow Leopard buildbots look like good candidates.
See the message I just sent: you need to convince Antoine, and
he'll arrange it.
Regar
Am 14.10.2010 00:08, schrieb Stephen Hansen:
> On 10/13/10 2:47 PM, Antoine Pitrou wrote:
>> (you'll notice that we have currently no 64-bit Windows machine although
>> 64-bit support under Windows has specific issues)
>
> Provided its not a problem that its a VM, I have a hefty 64-bit Win7
> Prof
> I'll give it a go; I have all the software needed to run the buildbot on
> it already besides VC Express, which I'm installing now. If ultimately
> it becomes too much of a pain, I'll go back to just providing the mac.
> But, I actually have a vested interest in upgrading our Python to 64-bit
> i
> #python-dev thought that VS express was all that was needed; then here,
> it seemed to me that Martin said that you needed the full version of VS
> or perhaps a complex setup with the SDK compiler; but you seem to be
> interpreting Martin that the SDK provides everything and nothing else is
> nee
Am 14.10.2010 11:25, schrieb Antoine Pitrou:
>
> Hello,
>
> In the http://bugs.python.org/issue10093 discussion, I proposed to add a
> specific warning category for unclosed files. The rationale is that
> these warnings will happen in destructors and therefore filtering by
> line number and filen
Am 14.10.2010 19:57, schrieb Daniel Stutzbach:
> On Thu, Oct 14, 2010 at 12:38 PM, barry.warsaw
> mailto:python-check...@python.org>> wrote:
>
> -# Generated by GNU Autoconf 2.65 for python 3.2.
> +# Generated by GNU Autoconf 2.67 for python 3.2.
>
>
> Was the change in autoconf versions
>> I think it was intentional (at least deliberate), but I think it is a
>> problem and should be reverted. There is, at any point, the official
>> version that Python uses for autoconf, which at the moment is 2.65.
>> The rationale is that with changing autoconf versions, the actual
>> configure s
> I don't see it as any more of a problem than upgrading against other
> dependencies (like gcc?).
Ok, so let's drop the requirement then.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
> Is it possible to pin the autoconf version (not just floor it)?
Not that I know of, no.
> Should we appoint an autoconf BDFL who can commit changes after configure.in
> is changed?
Most recently, it was between me and Benjamin most of the time, and that
seems to have worked fine. Now Benjami
> ISTM, the use of 64-bit builds is growing in popularity. It was be a bummer
> to have a locked-in an effective size limit for dictionaries and sets
> because the API only supports 32-bit hash values.
If the ABI is frozen with 3.2, it would still be possible to introduce
"wide" hashes - it just
Am 19.10.2010 19:47, schrieb exar...@twistedmatrix.com:
> On 04:50 pm, j...@jcea.es wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Current Python lacks support for "aio_*" syscalls to do async IO. I
>> think this could be a nice addition for python 3.3.
>
> Adding more platform w
> So, in conclusion, I disagree that adding wrappers for these would be
> nice. It wouldn't. It would cause some people to think they would be
> useful things to call, and they would always be wrong.
We are all consenting adults. If people want to shoot themselves in
their feet, we let them. For e
> Also, the canonical way to do file I/O in Python 3 is the `io` lib,
> therefore it would be a bit of a shame to have separate, non-integrated
> `aio_*` functions.
I disagree. We also have posix.open, posix.dup, etc. We always expose
POSIX functions in the posix module (except for the socket func
> Any ideas what could cause this or how to fix this?
It could be a compiler bug; try disabling optimization.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
Am 22.10.2010 16:09, schrieb Benjamin Peterson:
> 2010/10/22 Dirkjan Ochtman :
>> 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
>>
>> Issues stats:
>> open2494 (+32)
>> closed 19460 (+110)
>> total 21954 (+56)
>
> The figures in parentheses look wrong. Last week, the stats said:
No: they just mean something different that you think.
+32 doesn't mean that there are now 32 more open issues than
last week, but that
> Who is doing multiprocessing maintenance these days? I thought Ask
> Solem had been given commit privs for that, but I haven't seen any
> activity from him; and Jesse is, mostly, absent. Is anyone working on
> the multiprocessing issues?
>
> (no, I'm not planning to address them :-))
You mean:
> Both. Originally the module is/was meant to be officially maintained by
> Jesse, as far as I understand. But bugs filed against multiprocessing
> have been lingering in the tracker for quite a long time.
I personally think we should treat these reports in the same way as all
other lingering issu
Am 23.10.2010 20:56, schrieb Barry Warsaw:
> I will also do any future 2.6 release from svn. It does mean that
> patches for those release need to make it into svn. I propose that
> only the RM have commit to the svn branches after the switch.
This is also my thinking. I would like to see a Mercur
> If you have anything you want me to look at please forward it,
> and if you already did then don't be afraid to nag me.
Please keep the release schedule in mind. After 3.2b1, no new
features can be accepted (until after the 3.2 release). So
there might be some urgency for some of the patches.
A
> Add casts (one needed, one for consistency).
FWIW, I feel that these casts are misguided. Having function pointer
casts means that type errors in the signature get suppressed. E.g.
people using such casts for tp_hash will be unable to detect the change
in the tp_hash return type that we have imp
Am 26.10.2010 19:24, schrieb Peter Ingebretson:
> --- On Tue, 10/26/10, Benjamin Peterson wrote:
>> Is there any reason that you'd want to do this?
>>> http://doublestar.org/python-hot-loading-prototype/
>
> I have a relatively large application written in Python, and a
> specific use case where
1301 - 1400 of 5277 matches
Mail list logo
