"Andrew McNamara" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I'm reluctant to mention the name of one particular tool I'm aware
| of, but as well as the above, it also has OCR to defeat CAPTCHA, and
How about asking a Python specific question, with answered filled in rather
t
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> I'm reluctant to mention the name of one particular tool I'm aware
| > of, but as well as the above, it also has OCR to defeat CAPTCHA, and
| > automatically creates throw-away e-mail accounts with a range of free
> I'm reluctant to mention the name of one particular tool I'm aware
> of, but as well as the above, it also has OCR to defeat CAPTCHA, and
> automatically creates throw-away e-mail accounts with a range of free
> web-mail providers for registration purposes.
Right. We considered CAPTCHA, but some
Aahz schrieb:
> On Mon, May 14, 2007, "Martin v. L?wis" wrote:
>> Skip(?):
>>> In the meantime (thinking out loud here), would it be possible to keep
>>> search engines from seeing a submission or an edit until a trusted person
>>> has had a chance to approve it?
>> It would be possible, but I woul
> You can always can make a checkout of the security-manteined-only
> branch, if you're in a particular hurry (maybe the PEP should say
> something about this).
Indeed. I can add explicit wording to say that.
Regards,
Martin
___
Python-Dev mailing list
> | I think we would need to restrict the total number of releases
> | made per year. The one-year limit may be debatable, and immediate
> | releases might be possible, as long as there is some provision
> | that releases are not made at a too-high rate.
>
> I would agree, but...
> has there been
> > In effect, this is what the PEP says. That's intentional (i.e. it
> > is my intention - others may have different intentions). It's the
> > repository that holds the security patches; the tarballs (and the
> > version number bumps) are just a convenience.
>
> It's not the intentions of th
"Martin v. Löwis" writes:
> > In general, I recognize the burden on the release engineer, and
> > obviously any burdensome policy needs his OK. But I think the policy
> > should be *effective* too, and I just don't see that a policy that
> > allows such long lags is a more effective security
>> I think a single-click button "Spammer"
>> should allow committers to lock an account and hide all messages
>> and files that he sent, but that still requires somebody to implement
>> it.
>
>I'd expect that to be pretty effective -- like graffiti artists,
>spammers want their work to be seen, an
> Still, I'm in agreement with you that the repository holds the security
> patches and that the tarballs are a convenience. They are an important
> convenience though, so I would say that they should be released in a
> timely manner after the commit of the security patches. I don't think
> we ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 14, 2007, at 5:32 PM, Martin v. Löwis wrote:
>> We should decide what's right for security releases and then assess
>> whether we need to recruit in order to perform that activity the
>> way we
>> want to.
>
> I disagree. If you would like to
> We should decide what's right for security releases and then assess
> whether we need to recruit in order to perform that activity the way we
> want to.
I disagree. If you would like to see a certain policy implemented, you
need to locate the volunteers *first*, and only then you can start
setti
> My point is that if those steps are required for a release, the branch
> is not "immediately releasable" by my standards if they're not done.
> Especially if a release candidate is required.
But how does that help in practice? If you find after the release that
the branch was not in a releasable
At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>Determining the class object to use
>'''
>
>The exact mechanism for associating the method with the defining class is
>not
>specified in this PEP, and should be chosen for maximum performance. For
>CPython, it is sugge
Martin v. Löwis wrote:
>> I don't understand the point of a "security release" made up to a year
>> after commit, especially in view of the first quoted paragraph.
>
> The objective is to reduce load for the release manager. Any kind of
> release that is worth anything takes several hours to pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 14, 2007, at 11:32 AM, Stephen J. Turnbull wrote:
> In general, I recognize the burden on the release engineer, and
> obviously any burdensome policy needs his OK. But I think the policy
> should be *effective* too, and I just don't see that a
"Martin v. Löwis" writes:
> The objective is to reduce load for the release manager. Any kind of
> release that is worth anything takes several hours to produce, in
> my experience (if it could be made completely automatic, it wouldn't
> be good, since glitches would not be detected).
I absol
Tim Peters wrote:
> I'm with Raymond on this one, especially given the triviality of
> implementing the revised spec's new logical operations.
Exactly. I already implemented part of it, and took less than read this
thread, ;).
The cost of having it is lines of code in decimal.py. The benefit is
On Mon, May 14, 2007, "Martin v. L?wis" wrote:
> Skip(?):
>>
>> In the meantime (thinking out loud here), would it be possible to keep
>> search engines from seeing a submission or an edit until a trusted person
>> has had a chance to approve it?
>
> It would be possible, but I would strongly oppo
On Fri, 2007-05-11 at 13:06 -0700, Guido van Rossum wrote:
> > attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')
>
> But wouldn't it be just as handy to teach the re module about \u and
> \U, just as it already knows about \x (and \123 octals)?
And \n, \r, etc. Implementin
Here is my modified version of PEP 367. The reference implementation in it
is pretty long, and should probably be split out to somewhere else (esp.
since it can't fully implement the semantics).
Cheers,
Tim Delaney
PEP: 367
Title: New Super
Version: $Revision$
Last-Modified: $Date$
Author: Ca
21 matches
Mail list logo
