> it shouldn't be difficult to cobble together a build script that spins up a
> buildslave on EC2 and runs the tests there; I wrote something similar a
> few years ago for an infrequently connected home machine.
Ok - so it would be the master running this script? Sounds reasonable to me.
As for E
> This is supported in recent versions of BuildBot with a special kind of
> slave:
>
> http://djmitche.github.com/buildbot/docs/0.7.11/#On_002dDemand-
> _0028_0022Latent_0022_0029-Buildslaves
Interesting. Coming back to "PSF may spend money", let me say this:
If somebody would volunteer to set u
> I don't need to know that it works on every checkin
For us, that is a fairly important requirement, though.
Reports get more and more useless if they aren't instantaneous.
Sometimes, people check something in just to see how the build
slaves react.
Regards,
Martin
__
> The most *exciting* part of pony-build, apart from the always-riveting
> spectacle of "titus rediscovering problems that buildbot solved 5 years ago",
> is the loose coupling of recording server to the build slaves and build
> reporters. My plan is to enable a simple and lightweight XML-RPC and/
> Brett actually wants web hooks so pony-build will ping an App Engine web
> app when there is more data, ala PubSubHubbub. Or hell, just have
> pony-build have an Atom feed with updates and simply use PuSH. In other
> words I want to be told when there is an update, not have to poll to
> find out.
Triggered by the recent discussion, I looked at the changes in status
display that the buildbot people have implemented recently. I added
a few links into alternate renderings; see
http://www.python.org/dev/buildbot/
Regards,
Martin
___
Python-Dev maili
> It's not so much that I *require* the slave to shut down, more that
> I'm not sure how well I'll be able to ensure that it's up all the
> time, and I'm trying to understand the implications of that. My basic
> impression is that it's not really going to work, unfortunately.
There is a significa
> We were using sets to track the tips of a graph, and to compare whether
> one node was an ancestor of another one. We were caching that answer
> into frozensets, since that made them immutable. If
>
> res = heads(node1, node2)
> if len(res) == 1:
> # What is the 'obvious' way to get the node o
> Why not allow that?
>
> def any(self, predicate=lambda x: True, default=None)
> for a in self:
> if predicate(a):
> break
> else:
> return default
> return a
I'm +0 (given that I'm still skeptical about the need to have somethi
David Bolen wrote:
> MRAB writes:
>
>> Couldn't you write a script to check the status periodically?
>
> Sure, I suppose scraping the web status page would work. If it
> happened frequently I'd probably be forced to do something like that,
> but it's relatively low frequency (though I guess it
>>> This sounds like something that should be reported
>>> upstream. Particularly if you know how to reproduce it. Has it been?
>>
>> No, largely because I can't reproduce it at all. It's happened maybe
>> 4-5 times in the past 2 years or so. All that I see is that my end
>> looks good yet the m
> What do you think of creating a "buildbot" category in the tracker? There are
> often problems on specific buildbots which would be nice to track, but there's
> nowhere to do so.
Do you have any specific reports that you would want to classify with
this category?
Regards,
Martin
___
Jesse Noller wrote:
> On Thu, Oct 29, 2009 at 8:31 PM, R. David Murray
> wrote:
>
>> I'd say that particular one is a bug in the tests. If /dev/shm is
>> not available and is required, then the tests should be skipped with
>> an appropriate message. It would also secondarily be an issue with
>
> But the real reason for having a buildbot category (or at least a keyword)
> would be to be able to tag all bugs that are currently making buildbots
> fail that are _not_ the result of a recent checkin. This would make
> the task of finding the bugs that need to be cleaned up to stabilize
> the
> Is there a place where the status of the ssl module is summarized
The documentation of the ssl module should describe its features
correctly and precisely.
> or a better place to discuss this? I could try to provide contributions or
> further details if appropriate.
For contributions, this is
> Any thoughts/comments/ideas, anything?:)
Announce it to comp.lang.python.announce if you haven't done so, yet.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
> Well the general situation would be slightly easier to appreciate if there
> was a
> public medium where buildbot info was exchanged, announcements done, and
> problems tracked. Some kind of tracker, tracker keyword, mailing-list, or
> anything else.
As for the tracker keyword - I created one (
> Since I've never used any such service ("cloud"-based VMs), I'm not sure
> what the downsides would be. But it seems to be that it would be at least
> worth trying.
Not sure whether it's still relevant after the offers of individually
donated hardware. However, if you want to look into this, f
> How about:
> "indicates that related test failures are causing buildbot
> instability"
Ok, changed!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> It's not really reproducible. I think it sometimes happens when I
>> restart the master; sometimes, some clients fail to reconnect
>> (properly).
>
> Another common problem is that some build
> The new GIL does away with this by ditching _Py_Ticker entirely and
> instead using a fixed interval (by default 5 milliseconds, but settable)
> after which we ask the main thread to release the GIL and let another
> thread be scheduled.
I've looked at this part of the implementation, and have a
Sturla Molden wrote:
> Martin v. Löwis skrev:
>> b) notice that, on Windows, minimum wait resolution may be as large as
>>15ms (e.g. on XP, depending on the hardware). Not sure what this
>>means for WaitForMultipleObjects; most likely, if you ask for a 5ms
>>
>> c) is the gil_drop_request handling thread-safe? If your answer is
>>"yes", you should add a comment as to what the assumptions are of
>>this code (ISTM that multiple threads may simultaneously attempt
>>to set the drop request, overlapping with the holding thread actually
>>drop
> I've setup a buildslave on an EC2 Ubuntu Karmic instance here:
> http://www.python.org/dev/buildbot/all/buildslaves/pitrou-ubuntu
>
> However, since it's right now billed on my credit card, I'll shut it down in a
> couple of days. I wonder how we can get the PSF to be billed instead of me, if
>
> - all machines Python runs on should AFAIK be cache-coherent: CPUs synchronize
> their views of memory in a rather timely fashion.
Ok. I thought that Itanium was an example where this assumption is
actually violated (as many web pages claim such a restriction), however,
it seems that on Itanium,
> An always-on "small" EC2 instance is at least 500$ a year, with a small
> storage cost added to that.
OTOH, that isn't that expensive (compared to the other PSF expenses),
plus people keep donating money, so when we say what we use it for,
there may be a larger return than just the test results.
> I did, and it does nothing of what I suggested. I am sure I can make the
> Windows GIL in ceval_gil.h and the mutex in thread_nt.h at lot more precise
> and
> efficient.
Hmm. I'm skeptical that your code makes it more accurate, and I
completely fail to see that it makes it more efficient (by wh
> +lots on adding a module field (independent of automatically adding
> maintainers to the nosy list, it would assist in "I just did a major
> cleanup of module X, are there any old bugs I can kill off").
Link (1:1) or Multilink (1:n)? What is the impact on the Component field?
Would you be willi
s...@pobox.com wrote:
> Brett> Another summit, another potential time to see if people want to
> Brett> change anything about the issue tracker.
>
> I have no idea how hard this would be to implement and won't be at the
> language summit to formally present the idea, but it seems to me tha
> I don't currently have an opinion on this backport proposal, but in
> regard to this argument: if we do not do any 2.x releases after 2.7,
> then over time the number of packages that can afford to drop 2.6 support
> will grow, yet many will need to retain 2.7 support for much longer.
I don't t
R. David Murray wrote:
> On Mon, 2 Nov 2009 at 22:17, "Martin v. Löwis" wrote:
>>> I don't currently have an opinion on this backport proposal, but in
>>> regard to this argument: if we do not do any 2.x releases after 2.7,
>>> then over time the n
> Is it even wort doing a 2.7 release? Isn't the effort better spent on
> 3.2 alone? (Note, these aren't rhetorical questions. It's well
> possible that there are good reasons for pushing along with 2.7. Maybe
> considering those reasons will also help answering questions about
> whether to backpor
Barry Warsaw wrote:
> On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
>
>> A better language, i.e. Python 3.x, will become better faster without
>> dragging the 2.x series out any longer.
>
> If Python 2.7 becomes the last of the 2.x series, then I personally
> favor back porting as many
> A Python 3 version of NumPy might be enough of an improvement to bring
> *more* scientists and engineers onboard if the Python 3.x version shows
> what great productivity gains are to be had with Python 3.x over 2.x.
I would be really surprised if 2.7 would simplify porting to 3.x. How
could tha
>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>> object), which means it is better for people wanting to ease transition to
>> 3.x.
>>
>> But of course, as Martin said, few people will want to support 2.7 only and
>> not
>> 2.6.
>
> Since 2.7 will be closer to 3.2
>> I'd like to read some case studies of people who have migrated applications
>> from 2.6 to 3.0.
>
> +1, especially for packages which have a lot of C code: the current
> documentation is sparse :) The only helpful reference I have found so
> far is an email by MvL concerning psycopg2 port.
You
>> I'm not ready for that yet. I think there's plenty of time before we
>> have to agree to such a bleak view. In the mean time let's do
>> something practical like help NumPy port to Py3k.
>
> Or, for example, Django...
See
http://wiki.python.org/moin/PortingDjangoTo3k
Regards,
Martin
> It's pretty easy to make Python source that works under 2.6 and 3.x.
> It's basically impossible to make Python source that works under 2.4/2.5
> and 3.x. You may be able to write code that works under 2.4/2.5 and
> works cleanly with 2to3 to produce 3.x code. I haven't tried that
> route, tho
> To answer your question, the main issues are:
> - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
No, it should be well possible to have the same source being used in
both 2.x and 3.x. I've ported ZODB to Python
> Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be
> more to port the Django *community* to Py3k...
Exactly so. At the last Pycon, we then agreed that I would get a branch
in the Django code repository, but then progress stalled due to
inactivity on boths sides.
Regards,
Mar
>> I would be really surprised if 2.7 would simplify porting to 3.x. How
>> could that possibly work?
>
> The only things I can think of that would go into this category are
> features like:
> - PEP 3118, revised buffer protocol. If the buffer API that numpy
> uses is not present in py3k (I'm no
> * General language semantics
> The language operates as-is with only specific exemptions (see
> below).
Would PEP 382 (namespace packages) fall under the moratorium?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.
>>>
>>> Or, for example, Django...
>>
>> See
>>
>> http://wiki.python.org/moin/PortingDjangoTo3k
>
> W
> I wouldn't say that. For instance, I'm just starting a refactoring that will
> result in getmail v.5, but I need to target Python 2.5 and up, so there's
> essentially no way the code will run in Python 3.x (as another list member
> posted).
That's a common myth. It is very well possible, using
> yet another feature request or two to be lost to a mailing list thread
> along those lines:
>
> Maintainer or not i'd like to be able to setup triggers so that i'm
> automatically cc'ed on any bugs matching a simple search query i
> specify.
Please add that to the meta tracker (if you really wa
>> You may also want to take a look at my ZODB port:
>>
>> https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/
>
> Has that port been integrated back into the zodb project?
Only partially so.
> If not, it
> would be interesting to know the reasons (zodb project maintainers not
> interested, bar
>>> I wouldn't say that. For instance, I'm just starting a refactoring that
>>> will
>>> result in getmail v.5, but I need to target Python 2.5 and up, so there's
>>> essentially no way the code will run in Python 3.x (as another list member
>>> posted).
>> That's a common myth. It is very well p
>> But only if NumPy would drop support for 2.x, for x < 7, right?
>> That would probably be many years in the future.
>
> Yes. Today, given the choice of supporting py 3.x and dropping python
> < 2.7 and continue support for 2.4, the latter is by far my preferred
> choice today (RHEL still requir
Nick Coghlan wrote:
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively rea
Antoine Pitrou wrote:
> Paul Moore gmail.com> writes:
>> FWIW, I did a quick survey of some packages (a sampling of packages
>> I've used or considered using in the past):
>>
>> Twisted - no plans yet for Python 3
>
> Well Twisted depends on zope.interface which is not ported yet.
That's not str
> For one thing, we have a very long row to hoe here. The migration to
> 3.0 is a long, tedious process with little tangible benefit. I hope
> that sometime in the next decade Twisted can accelerate the process of
> dropping old 2.x versions, but I seriously doubt we could do a
> feature-complete
> It seems that there is no buildbot to test a wide unicode build.
>
> On http://www.python.org/dev/buildbot/3.x/ all outputs of the "configure"
> steps show this message::
> checking what type to use for str... unsigned short
> which looks like a ucs2 build to me.
>
> Since wide unicode is the
>> That's not my experience. I see a change in source (say, on Django)
>> available for 3.x within 5 seconds.
>
> This is for which version of 2to3 ? I got similar experience (several
> minutes), but maybe I am using 2to3 the wrong way. On my machine, with
> 2to3 from 3.1.1, it takes ~ 1s to conve
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> Well, 3to2 would then be an option for you: use Python 3 as the source
>> language.
>
> I was under the impression that 2to3 was officially supported as part of
> Python, but 3to2 was a third-party tool. W
> Mike Krell wrote:
>> Well, 3to2 would then be an option for you: use Python 3 as the source
>> language.
>
> Making life easier for 3to2 is an *excellent* rationale for backports.
>
I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't *use* these f
>I feel pretty strongly that it's a wart in the language, and a
> sufficiently strong one that it should be remedied. I'm happy to
> champion it, but haven't the faintest idea what that entails.
There are two ways
a) write a library that provides what you want, publish it on PyPI,
and rep
>> I would certainly agree to setup two slaves on mine. There are ample
>> resources available.
>
> I could do so as well. Gentoo is one of the distributions that uses
> the wide build by default, so that would make it a good test candidate
> as well.
I have now setup two slaves, murray-gentoo-w
> On Thu, Nov 5, 2009 at 5:02 PM, Raymond Hettinger wrote:
>> Forgot to post the code. It is short, fast, and easy. It is explicit about
>> handing the case with an empty input. And it is specific about which value
>> it returns (always the first iterated value; not an arbitrary one). There's
> JFTR, I didn't set up the IRC bot (I assume that credit goes to Martin,
> even if it's only one line in the buildbot config :). I just tried to
> get it to say something :)
Yes, it was always "on". I don't use IRC regularly, so I don't know
whether it's useful.
Regards,
Martin
>> Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM
>> anyway, so this can only be an issue for code using the new APIs in Python
>> 2.6.
>
> That's not going to stop the
> wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining
> about Python not releasi
> data = "GIF89a(..."
>
> Is there a potentially automated path from where the code is today to
> something Python 3 (and 2to3) will like?
Not sure how you'll fix these; I personally always provided a b()
function that will do the right thing in both 2.x and 3.x. This can
get eventually repla
> Quite an interesting question recently popped up in pygame community
> that I'd like to ask to Python developers.
>
> How many of you use IDLE?
I do, sometimes.
> What's wrong with it?
AFAICT, nothing.
>>From my side I like the idea of having default Python editor that is
> small, fast, conv
> The problem arises because we're systematically unbalancing the hash
> table. The iterator returns the first valid entry in the hash table,
> which we remove. Repeat several times and pretty soon the iterator has
> to spend O(n) time scanning through empty entries to find the first
> remaining
> So the rationale is to ensure that only add operations perform a resize
> and so that sequential pop() operations don't incur excessive resizing
> costs.
I agree that the use case of repeated .pop() operations is reasonable,
and (IIUC) that case is also special-cased using a finger/index.
I thi
Nick Coghlan wrote:
> Ben Finney wrote:
>> anatoly techtonik writes:
>>
>>> Quite an interesting question recently popped up in pygame community
>>> that I'd like to ask to Python developers.
>> This forum is specifically about development *of* Python.
>
> Anatoly's question is actually a fair on
> I'm not sure, but isn't that thread-unsafe?
You are right; it's thread-unsafe.
I would fix it by catching the RuntimeError, and retrying. Given the
current GIL strategy (including proposed changes to it), it won't happen
two times in a row, so the number of retries would be bounded.
Regards,
M
> I may well be barking up the wrong tree here, but as a first guess
> it looks as though something in the _PySys_Init function in
> Python/sysmodule.c is (directly or indirectly) causing the
> OverflowError to be raised.
My theory would be different. There is a pending unchecked OverflowError
be
> We repeatedly search through the slots sequentially and remove the first
> element we find. The first removal requires checking 1 slot, the second
> removal requires checking 2 slots, the third removal requires checking 3
> slots, and so forth. The hash table will shrink after the n/2-th
> remo
> If we filter list of http://wiki.python.org/moin/PythonEditors by
> language/license/framework, we will be able to see if there is any
> suitable open source Python code to replace IDLE's.
This is not how it works. We cannot incorporate something into Python
without explicit consent and support
>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>
> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
> should have
>> The buildbot waterfall is much greener now. Thanks to all who have
>> contributed to making it so (and it hasn't just been Mark and Antoine
>> and I, though we've been the most directly active (and yes, Mark, you
>> did contribute several fixes!)).
>
> The buildbots still show occasional oddit
Benjamin Peterson wrote:
> 2009/11/10 "Martin v. Löwis" :
>> I personally think that decoupling the releases would be best, i.e.
>> not start thinking about 3.2 for another 6 months.
>
> The problem with that is that there is a period of time where 2.x has
&
> Does that mean even if authors of some imaginary editor agree to
> incorporate their code into Python, the framework that it is built
> upon will have to be incorporated into Python also (and eventually
> abandoned at original location)?
It depends. It should work the same way as IDLE: it's ok t
> I was wondering what's the status of PEP 382. Is anyone (MvL?) is
> going to start to work on its implementation for Python 2.7/3.2
> inclusion ?
I'll be working on an implementation, but contributions are welcome.
Unfortunately, I'm really short on free software time recently (and
keep hoping t
> I am not an expert, I am just another python learner. These are just my
> views on the state of the standard libraries and to
> make them state-of-the-art..! ;)
If I understand correctly, you want the (current) standard library to be
separated from the Python implementation, and available separa
> If you were to ask me, the people arguing against ratings and user
> comments are fighting a losing battle. If they had an iPhone or
> Android phone (or some other device with an "app store" kind of place
> to find downloads) they'd know the value (for prospective downloaders)
> of ratings and co
> (more seriously, the problem with a comment system is that once it takes off,
> you need a whole array of functionalities to maintain a good S/N ratio. Just
> allowing people to "comment" without any sort of moderation, filtering or
> community building doesn't work)
The current rate is roughly
>> The current rate is roughly 1 comment per day (with peaks of 5
>> comments), so it takes of rather slowly.
>>
>
> Until spammers decide to attack...
Sure. However, spambots have avoided PyPI so far, and manual spamming
only had one incident (of somebody creating dozens of packages on a
single
Nick Coghlan wrote:
> Chris Withers wrote:
>> I'm quite okay with having a banner
>> saying "This package has opted not to receive comments".
>
> Particularly if the developer is able to add a prominent link to the
> project's own support site or mailing list.
It's really puzzling that people alw
> Part of the pypi problem is a startup problem of initially low numbers.
> If the only people who bother to log in to rate are the disgruntled,
> then the ratings/reviews will be biased.
Fortunately, that isn't actually the case. The majority of comments is
positive (from scanning the full list o
> At least it can be expected that in many cases project maintainers will
> *want* to use a conventional BTS, VCS, discussion forum, etc. So that
> route makes more sense than a mandatory comment system outside the
> project maintainer's control, while providing the user-participation
> that is the
> Except when they have a problem, and then they are likely to only complain
> through the comments.
As this theory has been repeated often here, I decided to go through all
comments and classify them, as:
- good: (overall) positive evaluation (possibly including minor
criticism/wishes)
- bad: n
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> Nick Coghlan wrote:
>>> Particularly if the developer is able to add a prominent link to the
>>> project's own support site or mailing list.
>> It's really puzzling that people always a
> And how many of the "good" comments are astroturfers?
If I understand that term correctly, it's about disguise: how would
I be able to answer that question?
> What's so bad about package maintainers from having an opt-out?
PyPI is not just (and perhaps not even primarily) there for the package
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> I think you are missing the point of the commenting system: these
>> comments are *not* directed towards the package author. Instead, they
>> are directed towards fellow users of the package. For this kind of
David Lyon wrote:
> On Fri, 13 Nov 2009 00:44:30 +0100, Xavier Morel
> wrote:
>> If pypi one day has a CPAN-style buildbot farm allowing it to test the
>> package on any platform under the sun, that can be included, the tests
> can
>> be included as well but given the number of testing solutions (
> Users (which includes e.g. language users) tend to be lazy, rather than
> stupid.
Then they likely won't comment on PyPI. To do so, they have to setup an
account (which most don't have). They can't post comments without an
account.
Regards,
Martin
__
> Why can't we just disable it until we can come up with a better system
> that finds a balance between the rights of maintainers, and those of
> the user?
Because I want to wait for the outcome of the poll first.
Regards,
Martin
___
Python-Dev mailing
> But you can bet your ass that if PyPI isn't made a good, neutral,
> central resource I'm going to leave for one that is. Do you really
> want a flood of package maintainers de-listing their packages just so
> that things work the way you think they should?
>
> I should clarify that I'm speaking
David Lyon wrote:
> On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis"
> wrote:
>
>> http://pycheesecake.org/
>
> Ok, so what is the current status on it?
Not sure; you would have to ask Grig. Apparently, there is a service
running somewhere that computes ch
> There's a problem with the poll's placement: on the front page of the
> PyPI website.
You really should participate in the proper forum for the discussion of
PyPI: catalog-sig. Then you would have noticed that I said I'll announce
the poll later (i.e. today), which I'm doing right now.
Feel fre
> Ben Finney benfinney.id.au> writes:
>> There's a problem with the poll's placement: on the front page of the
>> PyPI website.
>
> Speaking of which, why is it that http://pypi.python.org/pypi and
> http://pypi.python.org/pypi/ (note the ending slash) return different contents
> (the latter bein
> I only found the poll by accident by wondering randomly what might
> change if I hit the login using open id button. So you can only vote
> in the poll if you a) get told about it b) realise you need to create
> an account to login and use in order to vote. I realise there's good
> reasons for th
>> I've posted a tweet to the ThePSF account about the poll. If the poll
>> runs for a week or two, that would provide time for word of the poll
>> to propagate through Twitter, blogs, etc.
>
> You should also make an announcement on python-announce.
On catalog-sig (the place where PyPI was disc
> That's useful from a user perspective. Or is it? It's useful from a
> user perspective, until that issue is fixed. Then what? Is it still
> useful? Can the commenter remove it?
Yes.
> Can they get notified it's changed?
Yes.
> Can the maintainer say "this is fixed/changed?"
Yes.
> I never l
> mode = "python-dev reader"
>
> Please excuse me if I'm wrong here,
> but I think python-dev just isn't the right place to discuss this topic,
> because it's about 3rd party packages and it's got nothing to do with
> the development *of the python language itself*, but generated a lot of
> traffi
> What I really like on PyPi is that my packages are tested automatically
> with Cheesecake and the order of packages when searching is determined
> by this rating.
That is an (apparently widespread) myth. The Cheesecake rating is not
considered in ranking search results; it's just the relevance o
Paul Moore wrote:
> 2009/11/13 Tres Seaver :
>> I can see the information about the poll, and a link to view the
>> results, without logging in.
>>
>> http://pypi.python.org/pypi
>>
>> (second paragraph there). That paragraph tells you that you need to log
>> in to vote in the poll.
>
> I don't
> Martin, are you interested in help?
Certainly, yes. For the specific feature in question, I'd like to wait
for the outcome of the poll. Otherwise, contributions are welcome.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
> Yes, I think this just started happening. I'm guessing that the main
> site proxies the buildbot URL requests to the buildbot master process,
> and when it's down you get the 404s from the main server.
>
> I figured someone might be working on the master, though perhaps it
> just burped on its o
701 - 800 of 5277 matches
Mail list logo
