Re: [Python-Dev] Summary of Tracker Issues
Terry Reedy schrieb: > "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 > that multiple choice selected: I would be willing to make up a bunch. > > The initials of Python's founder. > The keyword for looping by condition. > The char that signals a name-binding statement. > (I am intentionally avoiding question words and ? that would signal Test > Question to automated software.) There are two problems with this: * The set of questions is limited, and bots can be programmed to know them all. * Even programmers might not immediately know an answer, and I can understand them turning away on that occasion (take for example the "name-binding" term). > If we anticipate users rather than programmers to register (as if so, it > would be nice to collect that info to formulate sensible responses), then > questions like > The orb that shines in the sky during the day. > > | automatically creates throw-away e-mail accounts with a range of free > | web-mail providers for registration purposes. > > Either don't accept registrations from such accounts (as other sites have > done), or require extra verification steps or require approval of the first > post. How many current legitimate registered users use such? This is impossible to find out, I think, since SF.net does not publicly show real e-mail addresses, instead, each user has an alias [EMAIL PROTECTED] Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Functools Defaults (was Python-ideas parameter omit)
> -Original Message- > From: Steven Bethard [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 15, 2007 1:54 AM > > On 5/15/07, Aaron Brady <[EMAIL PROTECTED]> wrote: > > You might be able to get away without a PEP, but you'll definitely > need to post an implementation patch to the bug tracker > (http://sourceforge.net/tracker/?group_id=5470&atid=105470). Once > you've posted your implementation, you should send an email to > python-dev asking folks what they think about it. Be sure to give > some code examples that using this decorator would simplify. Code with proposal are in SourceForge [ 1719222 ] new functools. Python feature Functools gains a new decorator. `Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to. It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem. But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam What -do- you think about it? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Functools Defaults (was Python-ideas parameter omit)
Aaron Brady wrote: > It might be useful in cases where you want the calling signature to look > alike for a group of dispatched functions and the added overhead the > decorator adds isn't a problem. But you probably wouldn't want that > overhead all the time, so having it as an optional decorator would be good. > -Ron Adam > > What -do- you think about it? -1 It took me a couple of rereads to actually figure out what this decorator was trying to do (which is simply allowing callers to skip parameters in a function call without using keyword arguments). I think it would be significantly clearer (and far more efficient) to simply use keyword arguments at the call site where the parameters are being skipped rather than significantly slowing down every single call to a function simply to permit some sloppy coding. To take the example from the SF tracker: .>>> @defaults. .>>> def f(a=123, b=None, c='abc'): .>>> return a, b, c .>>> .>>> use_default = defaults.absent .>>> f(123, use_default, 'abc') 123, None, 'abc' As opposed to: .>>> def f(a=123, b=None, c='abc'): .>>> return a, b, c .>>> .>>> f(123, c='abc') 123, None, 'abc' Keyword only parameters (coming in Py3k and possibly in 2.6) will be an even cleaner solution for cases where you don't want callers to have to care about a default value, but still give them the ability to override it if needed. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 14, 2007, at 7:19 PM, Martin v. Löwis wrote: >> 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 need to be that exact about spelling out when that happens. >> >> (I personally would like to see it within "weeks" of a security >> patch, >> not "months" or "years".) > > Couldn't that lead to many more 2.x.y releases in the "security fixes" > period than in the "active maintenance" period? For active > maintenance, > we don't do roll security fixes into releases more often than every > six months. > > I would dislike a quick succession of 2.3.7, 2.3.8, 2.3.9, etc. > (also because these numbers should not grow above 10 :-) I think we could reasonably batch security releases, if we know that there are a few critical issues in the pipeline. That ought to be part of the job of the PSRT. Personally, I don't care much if the micro release number goes above 10 although I know there are many here who don't like that. We should definitely try to reduce churn. It's a balancing act. >> Also, I would like to document explicit that it is the >> responsibility of >> the PSRT (or its designate) to commit security patches to revision >> control. The act of committing these patches is a public event >> and has >> an important impact on any embargoes agreed upon by the PSRT with >> other >> organizations. > > I also disagree. Regular committers should continue to do that. I > haven't seen a single activity from the PSRT (or, perhaps one), so > for all I can tell, it doesn't exist. > > If a security patch is reported to the Python bug tracker, it's as > public as it can get. Right, but hopefully people know to report them to security at python dot org instead. Also hopefully, the new tracker will support private/security bug reports that won't be made public (I don't actually know if this is the case or not). > If PSRT members (who are they, anyway) also > happen to be committers, they can commit these changes at the > time the PSRT deems appropriate. If they are not committers, they > need to post the patch to SF as anybody else. > > (you can tell that I come from a country where people are quite > skeptical about the secret service). There's no secret police here, since almost anyone who's foolish enough to volunteer to do some work could easily infiltrate that most cloistered of organizations. I believe there is value in having a PSRT that coordinates security reports, fixes, and disclosures. If the community disagrees, that's cool. But in that case there's not much point in a security at python dot org mailing list or a PSRT, so let's disband them. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkm9RHEjvBPtnXfVAQKO5gP+IE+AhsUo28ayVojGWbIyupV0eIYBrOke R+Hvulllcr9LAVmlxlWNZV+TeReavKL+SSzmoyzj/Dv2U5szvTRld7Ca4PBl+mJ8 mfyjqg6uWp1At4OVhf93J6JCrLZkw2sY1lH+yAfcvmxivTr7Rf5+vugDJ822enUt pKtcowVQCwI= =ms5P -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
>> 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 oppose it. A bug tracker >>> where postings need to be approved is just unacceptable. >> >> Could you expand this, please? It sounds like Skip is just talking >> about a dynamic robots.txt, essentially. Anyone coming in to the >> tracker itself should still see everything. Martin> I must have misunderstood Skip then - I thought he had a scheme Martin> in mind where an editor would have approve postings before they Martin> become visible to tracker users; the tracker itself cannot Martin> distinguish between a search engine and a regular (anonymous) Martin> user. Okay, let me expand. ;-) I didn't mean do dynamically update robots.txt. I meant to modify Roundup to restrict view of items which have not yet been explicitly or implicitly approved. I envision three classes of users: 1. People with no special credentials (I include anonymous users such as search engine spiders in this class) 2. Tracker admins (Erik, Aahz, Martin, me, etc) 3. Other trusted users (include admins in this group - they are the root of the trust network). Anyone can submit an item or edit an item, however, if that person is not trusted, their submissions need to be approved by a trusted user before they are made visible to the unwashed masses in group 1. Also, such users will not be able to see any unapproved items. (That thwarts the desire of the spammers for visibility - search engine spiders will not know their submissions exist, and anonymous users will just get 404 responses when they try to access unapproved attachments or submissions.) The intent is that this would be done by modifying Roundup. True, initially, lots of submissions would be held for review, but I think we would fairly quickly expand the trust network to a larger, fairly static group of users. Once someone adds Guido to the trust network, any pending and future modifications of his will be visible to the world. Once trusted, Guido can extend the trust network himself, by, for example adding Georg to the network. Also, once trusted, a user would see everything and would be able to approve individual submissions. Again, as I indicated, I was thinking out loud. I don't think this is a trivial undertaking. I suspect the approach might work for a number of similar systems (Trac, MoinMoin, etc), not just Roundup though. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 15, 2007, at 12:55 AM, Martin v. Löwis wrote: > I don't think I can be more plain than that: yes, I do not take > security > seriously enough to release security fixes for old Python versions > more > than once a year. As a user, it's easy to demand things, and people > really have to learn that in open source, all things are done by > volunteers, and that demanding gets you nowhere. To get a better > service, somebody really has to volunteer and offer it. I've volunteered, and I contend that this community is big enough that we can recruit more people if necessary. So the question really comes down to what is in the best interest of Python. If resources weren't an issue, would you still say that doing security releases once a year is enough? If so, and if that represents the consensus of the community, then that's what we'll do. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkm+ynEjvBPtnXfVAQJW/gQAnzhTEwt9/YCydkRTqI51Z9iAQTikaDpI /2YMpvv6nxJX7dUoDQam08T8BoZ0Vt2iXFXMQ90GD99nYOevFTKMSx7u4l/kY/Do U0a4BG8lVaIZUS5ipW/7suvrQtlkEDqLQ9qpms2LP+6J/32wugw6YLPEi5PyiurM Hax4oeJB37A= =fLgb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] updated for gdbinit
Hi, I tried to use gdbinit today and found that the "fragile" pystacks macro didn't work anymore. I don't know gdb very well, but this turned out to work a bit more reliably: # print the entire Python call stack define pystack set $last=0 while $sp != $last if $pc > PyEval_EvalFrame && $pc < PyEval_EvalCodeEx pyframe end set $last=$sp up-silently 1 end select-frame 0 end Just in case anybody might want to use this and update the existing gdbinit. Christian PS: I'm not subscribed to this list. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updated for gdbinit
Christian> I tried to use gdbinit today and found that the "fragile" Christian> pystacks macro didn't work anymore. I don't know gdb very Christian> well, but this turned out to work a bit more reliably: ... Thanks. I'll give it a try and check it in if it checks out. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] updated for gdbinit
On Tue, 15 May 2007 09:26:55 -0500, [EMAIL PROTECTED] wrote: >Christian> I tried to use gdbinit today and found that the "fragile" >Christian> pystacks macro didn't work anymore. I don't know gdb very >Christian> well, but this turned out to work a bit more reliably: > >... > >Thanks. I'll give it a try and check it in if it checks out. > It would also be nice if it handled non-main threads. This is accomplished by additionally checking if the pc is in t_bootstrap (ie, between that and thread_PyThread_start_new_thread). Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] marshal and ssize_t (PEP 353)
Martin,
I'm looking at Python/marshal.c and there are a lot of places that
don't support sequences that are larger than would fit into size(int).
I looked for marshal referenced in the PEP and didn't find anything.
Was this an oversight or intentional?
To give you some examples of what I mean from the code:
(line 255)
n = PyString_GET_SIZE(v);
if (n > INT_MAX) {
/* huge strings are not supported */
p->depth--;
p->error = 1;
return;
}
w_long((long)n, p);
w_string(PyString_AS_STRING(v), (int)n, p);
...
(line 717)
n = r_long(p);
if (n < 0 || n > INT_MAX) {
PyErr_SetString(PyExc_ValueError, "bad marshal data");
return NULL;
}
v = PyTuple_New((int)n);
if (v == NULL)
return v;
for (i = 0; i < n; i++) {
v2 = r_object(p);
if ( v2 == NULL ) {
if (!PyErr_Occurred())
PyErr_SetString(PyExc_TypeError,
"NULL object in marshal data");
Py_DECREF(v);
v = NULL;
break;
}
PyTuple_SET_ITEM(v, (int)i, v2);
Also, the PEP references the ssize_t branch which no longer exists.
Is it possible to reference the specific revision: 42382?
Thanks,
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marshal and ssize_t (PEP 353)
> I'm looking at Python/marshal.c and there are a lot of places that > don't support sequences that are larger than would fit into size(int). > I looked for marshal referenced in the PEP and didn't find anything. > Was this an oversight or intentional? These changes were only made after merging the ssize_t branch, namely in r42883. They were intentional, in the sense that the ssize_t changes were meant to *only* change the API. Supporting larger strings would have been a change to the marshal format as well, and that was not within the mandate of PEP 353. Now, if you think the marshal format should change as well to support large strings, that may be worth considering. There are two design alternatives: - change the 's', 't', and 'u' codes to use an 8-byte argument That would be an incompatible change that would also blow up marshal data which don't need it (by 4 bytes per string value). - introduce additional codes (like 'S', 'T', and 'U') that take 8-byte lengths. That would be (forward?) compatible, in that old marshal data can be still read in new implementations, and mostly backwards-compatible, assuming that S/T/U get used only when needed. However, it would complicate the implementation. I'm still leaning towards "don't change", since I don't expect that such string objects occur in source code, and since I still think source code / .pyc is/should be the major application of marshal. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
> If we anticipate users rather than programmers to register (as if so, it > would be nice to collect that info to formulate sensible responses), then > questions like > The orb that shines in the sky during the day. This question I could not answer, because I don't know what an orb is (it's not an object request broker, right?) Is the answer "sun"? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marshal and ssize_t (PEP 353)
Ah, forgot to mention that a browsable version of the branch is at http://svn.python.org/view/python/branches/ssize_t/?rev=42382 Unfortunately, you cannot check out that URL. OTOH, you can checkout "peg revisions" (I have no clue what a peg is) http://svn.python.org/projects/python/branches/[EMAIL PROTECTED] but that URL is, unfortunately, not browsable. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marshal and ssize_t (PEP 353)
On 5/15/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I'm looking at Python/marshal.c and there are a lot of places that > > don't support sequences that are larger than would fit into size(int). > > I looked for marshal referenced in the PEP and didn't find anything. > > Was this an oversight or intentional? > > These changes were only made after merging the ssize_t branch, > namely in r42883. > > They were intentional, in the sense that the ssize_t changes were > meant to *only* change the API. Supporting larger strings would > have been a change to the marshal format as well, and that was not > within the mandate of PEP 353. > > Now, if you think the marshal format should change as well to > support large strings, that may be worth considering. There > are two design alternatives: > - change the 's', 't', and 'u' codes to use an 8-byte argument > That would be an incompatible change that would also blow up > marshal data which don't need it (by 4 bytes per string value). > - introduce additional codes (like 'S', 'T', and 'U') that take > 8-byte lengths. That would be (forward?) compatible, in that > old marshal data can be still read in new implementations, > and mostly backwards-compatible, assuming that S/T/U get used > only when needed. However, it would complicate the > implementation. > > I'm still leaning towards "don't change", since I don't expect > that such string objects occur in source code, and since I still > think source code / .pyc is/should be the major application > of marshal. Agreed. I see little use to changing .pyc files to support >2G literals or bytecode. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
>> The orb that shines in the sky during the day. Martin> This question I could not answer, because I don't know what an Martin> orb is (it's not an object request broker, right?) Martin> Is the answer "sun"? It is indeed. I would use "star" instead of "orb". It might be reasonable to have a translate the questions into a handful of other languages and let the user select the language. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
On 15-May-07, at 12:32 AM, Georg Brandl wrote: > > There are two problems with this: > * The set of questions is limited, and bots can be programmed to > know them all. Sure, but if someone is customizing their bot to python's issue tracker, in all likelyhood they would have to be dealt with specially anyway.Foiling automated bots shoud be the first priority--they should represent the vast majority of cases. > * Even programmers might not immediately know an answer, and I can > understand > them turning away on that occasion (take for example the "name- > binding" term). It would be hard to make it so easy that anyone with business submitting a bug report should know the answer: What python keyword is used to define a function? What file extension is typically used for python source files? etc. If there is still worry, then a failed answer could simply be the moderation trigger. -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marshal and ssize_t (PEP 353)
On 5/15/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I'm looking at Python/marshal.c and there are a lot of places that > > don't support sequences that are larger than would fit into size(int). > > I looked for marshal referenced in the PEP and didn't find anything. > > Was this an oversight or intentional? > > I'm still leaning towards "don't change", since I don't expect > that such string objects occur in source code, and since I still > think source code / .pyc is/should be the major application > of marshal. I agree this is fine. I'll update the PEP with this rationale and the link(s) you provided unless anyone objects. That way we have it clearly documented that this was intentional. I didn't remember this discussion back when ssize_t was done. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
[EMAIL PROTECTED] writes: > >> The orb that shines in the sky during the day. > > Martin> This question I could not answer, because I don't know what an > Martin> orb is (it's not an object request broker, right?) > > Martin> Is the answer "sun"? > > It is indeed. I would use "star" instead of "orb". And what happens if the user writes "the sun"? Everyday knowledge is pretty slippery. > It might be reasonable to have a translate the questions into a > handful of other languages and let the user select the language. Since English is the common language used in the community, I think a better source of questions would be the English language itself, such as: How many words are in the question on this line? ___ten___ John threw a ball at Mark. Who threw it?__John___ John was thrown a ball by Mark. Who threw it? __Mark___ I think most human readers able to use the tracker would be able to handle even the passive "was thrown" construction without too much trouble. We could also use easy "reading comprehension" questions, say from the Iowa achievement test for 11-year-olds. :-) Or even the SAT (GMAT, LSAT); there must be banks of practice questions for those. (Copyright might be a problem, though. Any fifth-grade teachers who write drill programs for their kids out there?) You could also have the user evaluate a simple Python program fragment. Probably it should contain an obvious typo or two to foil a program that evals it. It would be sad if somebody who could write a program to handle any of those couldn't find a better job than working for spammers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Terry Reedy schrieb: | > How about asking a Python specific question, with answered filled in rather | > that multiple choice selected: I would be willing to make up a bunch. And I would spend longer than a couple of minutes at 3am to do so. | There are two problems with this: | * The set of questions is limited, but unbounded. I would aim for, say, 50 to start | and bots can be programmed to know them all. by hacking into the site? or by repeated failed attempts? Then someone has to answer the questions correctly to put the correct answers in. A lot of work for very temporary access (a day?) to one site. Then maybe I reword the questions or add new ones, so more programming is needed. | * Even programmers might not immediately know an answer, and I can | understand them turning away on that occasion (take for example the "name- | binding" term). I would expect and want review by others, including non-American, non-native-English speakers to weed out unintended obscurities and ambiguities. | > | automatically creates throw-away e-mail accounts with a range of free | > | web-mail providers for registration purposes. | > | > Either don't accept registrations from such accounts (as other sites have | > done), or require extra verification steps or require approval of the first | > post. How many current legitimate registered users use such? | | This is impossible to find out, I think, since SF.net does not publicly show | real e-mail addresses, instead, each user has an alias [EMAIL PROTECTED] If the list of registrants we got from SF does not have real emails, we will need such to validate accounts on our tracker so *it* can send emails. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |> If we anticipate users rather than programmers to register (as if so, it | > would be nice to collect that info to formulate sensible responses), then | > questions like | > The orb that shines in the sky during the day. | | This question I could not answer, because I don't know what an orb is | (it's not an object request broker, right?) Ugh. The sort of reason why I would want review both by myself when not half asleep and by others ;-) | Is the answer "sun"? Yes. Skip is right about 'star' My underlying point: seeing porno spam on the practice site gave me a bad itch both because I detest spammers in general and because I would not want visitors turned off to Python by something that is completely out of place and potentially offensive to some. So I am willing to help us not throw up our hands in surrender. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
Terry Reedy wrote: > My underlying point: seeing porno spam on the practice site gave me a bad > itch both because I detest spammers in general and because I would not want > visitors turned off to Python by something that is completely out of place > and potentially offensive to some. So I am willing to help us not throw up > our hands in surrender. Typically spammers don't go through the effort to do a custom login script for each different site. Instead, they do a custom login script for each of the various software applications that support end-user comments. So for example, there's a script for WordPress, and one for PHPNuke, and so on. For applications that allow entries to be added via the web, the solution to spam is pretty simple, which is to make the comment submission form deviate from the normal submission process for that package. For example, in WordPress, you could rename the PHP URL that posts a comment to an article to a non-standard name. The spammer's script generally isn't smart enough to figure out how to post based on an examination of the page, it just knows that for WordPress, the way to submit comments is via a particular URL with particular params. There are various other solutions. The spammer's client isn't generally a full browser, it's just a bare HTTP robot, so if there's some kind of Javascript that is required to post, then the spammer probably won't be able to execute it. For example, you could have a hidden field which is a hash of the bug summary line, calculated by the Javascript in the web form, which is checked by the server. (For people who have JS turned off, failing the check would fall back to a captcha or some other manual means of identification.) Preventing spam that comes in via the email gateway is a little harder. One method is to have email submissions mail back a confirmation mail which must be responded to in some semi-intelligent way. Note that this confirmation step need only be done the first time a new user submits a bug, which can automatically add them to a whitelist for future bug submissions. -- Talin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
Terry Reedy schrieb: > "Georg Brandl" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | Terry Reedy schrieb: > | > How about asking a Python specific question, with answered filled in > rather > | > that multiple choice selected: I would be willing to make up a bunch. > > And I would spend longer than a couple of minutes at 3am to do so. > > | There are two problems with this: > | * The set of questions is limited, > > but unbounded. I would aim for, say, 50 to start > > | and bots can be programmed to know them all. > > by hacking into the site? or by repeated failed attempts? By requesting a registration form over and over, and recording all questions. A human would then answer them, which is easily done for 50 questions (provided that they are *not* targeted at experienced Python programmers, which shouldn't be done). > Then someone > has to answer the questions correctly to put the correct answers in. A lot > of work for very temporary access (a day?) to one site. Assuming that you don't replace all questions after killing the bot account, he can get the access again very easily. > Then maybe I reword the questions or add new ones, so more programming is > needed. > > | * Even programmers might not immediately know an answer, and I can > | understand them turning away on that occasion (take for example the > "name- > | binding" term). > > I would expect and want review by others, including non-American, > non-native-English speakers to weed out unintended obscurities and > ambiguities. That's necessary in any case. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
