Anders == Anders J Munch [EMAIL PROTECTED] writes:
Anders Unless the EULA contains specific language to forbid such
Anders multi-stage open-ended redistribution, I'd say you can
Anders just re-redistribute away.
Anders but-then-I-am-not-a-lawyer-ly y'rs, Anders
I am not either,
MAL == M [EMAIL PROTECTED] writes:
MAL The BOM (byte order mark) was a non-standard Microsoft
MAL invention to detect Unicode text data as such (MS always uses
MAL UTF-16-LE for Unicode text files).
The Japanese memopado (Notepad) uses UTF-8 signatures; it even adds
them to
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Stephen J. Turnbull wrote:
However, this option should be part of the initialization of an
IO stream which produces Unicodes, _not_ an operation on
arbitrary internal strings (whether raw or Unicode).
Martin
Walter == Walter Dörwald [EMAIL PROTECTED] writes:
Walter Not really. In every encoding where a sequence of more
Walter than one byte maps to one Unicode character, you will
Walter always need some kind of buffering. If we remove the
Walter handling of initial BOMs from the
Andrew == Andrew Koenig [EMAIL PROTECTED] writes:
Andrew Wel Shouldn't you have written
Andrew (mapcar car list-of-lists)
Andrew or am I missing something painfully obvious?
Greg should have written
(with-file foo/blarg 'do-something-with)
too. I guess I should
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido You mean like this?
if x 0:
...normal case...
elif y 0:
abnormal case...
else:
...edge case...
The salient example! If it's no accident that those conditions are
mutually exclusive and
Skip == Skip Montanaro [EMAIL PROTECTED] writes:
Skip If you provide the necessary namespace structure for them to
Skip nestle into, I suspect most of them could be maintained
Skip outside the stdlib just fine.
FWIW, this has worked well for XEmacs; it's one of our most popular
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW So are you saying that moving to svn will let us do more long
BAW lived branches? Yay!
Yes, but you still have to be disciplined about it. svn is not much
better than cvs about detecting and ignoring spurious conflicts due to
code that
Willem == Willem Broekema [EMAIL PROTECTED] writes:
Willem I hope the above makes the way I'm thinking more clear.
Willem Like Phillip J. Eby, I think that labeling
Willem KeyboardInterrupt a CriticalException seems wrong; it is
Willem not an error and not critical.
Uh,
Donovan == Donovan Baarda [EMAIL PROTECTED] writes:
Donovan Yeah. IMHO the sadest thing about SVN is it doesn't do
Donovan branch/merge properly. All the other cool stuff like
Donovan renames etc is kinda undone by that. [...] This is why
Donovan I don't bother migrating any
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip You just said, Unhandled, KeyboardInterrupt means...
Phillip If the program doesn't *want* to handle
Phillip KeyboardInterrupt, then it obviously *isn't* critical,
Phillip because it doesn't care. Conversely, if it
aahz == aahz [EMAIL PROTECTED] writes:
aahz I'd rather not rely on licensing of a closed-source system;
aahz one of the points made during the talk was that the Linux
aahz project had to scramble when they lost their Bitkeeper
aahz license
Python is unlikely to throw away its
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M Other non-commercial alternatives are Berlios and Savannah, but
M I'm not sure whether they'd offer Subversion support.
Savannah doesn't offer great reliability or support, at least to judge
by the frequency with which the GNU Emacs and GNU
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin I think your doubts are unfounded. Many Japanese people
Martin change it to EUC-JP (I believe), as UTF-8 support doesn't
Martin work well for them (or atleast didn't use to).
If you mean the UTF-8 support in Terminal, it's no
Donovan == Donovan Baarda [EMAIL PROTECTED] writes:
Donovan It all comes down to how painless branch/merge is. Many
Donovan esoteric features of version control systems feel like
Donovan they are there to workaround the absence of proper
Donovan branch/merge histories.
It's not
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin While this would work, it would still feel wrong: the
Martin binary data are *not* latin1 (most likely), so declaring
Martin them to be latin1 would be confusing. Perhaps a synonym
Martin '8bit' for latin1 could be
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin I don't know how this scales in OpenSSH having an
Martin authorized_keys file with hundred or more keys.
On cvs.xemacs.org (aka SunSITE.dk) ssh+cvs access with cvs access
control being handled by a Perl script scales to
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Raymond Hettinger wrote:
Do you have an ANSI-strict option with your compiler?
Martin gcc does have an option to force c89 compliance, but there
Martin is a good chance that Python stops compiling with option:
Raymond == Raymond Hettinger [EMAIL PROTECTED] writes:
Raymond FWIW, I am VERY happy with the name partition().
Raymond ... [I]t is exactly the right word. I won't part with it
Raymond easily.
+1
I note that Emacs has a split-string function which does not have
those happy
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Er, pardon? I don't think I've ever heard 'piece' used as a
Greg verb in English. Can you supply an example sentence?
I'll let the reader piece it together.
More closely related, I've heard/seen piece out used for task
allocation (from
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
But you could have string objects (or a derivative) grow a
compiled_regexp attribute internally.
Greg That would make the core dependent on the re module, which I
Greg think would be a bad idea
Steve == Steve Holden [EMAIL PROTECTED] writes:
Steve Since Python strings *can* contain embedded NULs, doesn't
Steve that rather poo on the idea of passing pointers to their
Steve data to C functions as things stand?
I think it's a consenting adults issue.
Ie, C programmers always
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I'm not at all convinced that we should attempt to find a
Guido solution that handles both use cases [print replacement
Guido and i18n]; most Python code never needs i18n.
It's true that the majority of Python applications
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido Sure, we must provide good i18n support. But the burden on
Guido users who don't need i18n should be negligeable; they
Guido shouldn't have to type or know extra stuff that only exists
Guido for the needs of i18n.
Agreed.
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I certainly didn't mean to rule that out.
Speaking for myself, that's all I really wanted to hear at this time.
As Bob Ippolito said, currently it's straightforward to
internationalize an application, and well worth the minimal
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
IMO strings that are being printf'd can probably be assumed to
be human readable, and therefore candidates for translation.
This
Greg That's a dangerous assumption to make, I think.
Could
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M From what I've read on the web about the Python Unicode
M implementation we have one of the better ones compared to other
M languages implementations and their choices and design
M decisions.
Yes, indeed!
Michiel == Michiel Jan Laurens de Hoon [EMAIL PROTECTED] writes:
Michiel What is the advantage of Tk in comparison to other GUI
Michiel toolkits?
IMO, Tk's _advantage_ is that it's there already. As a standard
component, it works well for typical simple GUI applications (thus
Fred == Fred L Drake, [EMAIL PROTECTED] writes:
Fred On Thursday 22 December 2005 13:23, [EMAIL PROTECTED] wrote:
Who is asking this of potential contributors? I know you, Aahz
and I have repeatedly told people on c.l.py that LaTeX
knowledge is not necessary. Plain text is
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin That would assume that the user knows that exit is a
Martin function: apparently, people expect it to be a statement
Martin (like print),
Oh, the irony of that analogy!wink
Martin or they are entirely unaware of the
Nick == Nick Coghlan [EMAIL PROTECTED] writes:
Nick Samuele Pedroni wrote:
It's not a matter of defending the status quo, more about what
kind of price is reasonable for DWIM.
IMHO, +N*10^6 for simplicity, regularity, and discoverability, -1 for
DWIM in the interpreter. DWIM is
skip == skip [EMAIL PROTECTED] writes:
Bob The easy fix is to upgrade your OS. I don't think anyone is going
Bob to bother with the preprocessor hackery necessary to make that
Bob (harmless) warning go away on older versions of the OS.
skip Excuse me, but this really pisses me
Fredrik == Fredrik Lundh [EMAIL PROTECTED] writes:
Fredrik many test frameworks support expected failures for this
Fredrik purpose. how hard would it be to add a
Fredrik unittest.FailingTestCase
Fredrik class that runs a TestCase, catches any errors in it, and
Fredrik
Anthony == Anthony Baxter [EMAIL PROTECTED] writes:
Anthony It sounds like configure needs to grow a test to detect
Anthony that a libreadline it finds is actually the crackful
Anthony libedit and refuse to use it if so.
FYI: Real libreadline is GPL, and rms made a point of forcing
Anthony == Anthony Baxter [EMAIL PROTECTED] writes:
Anthony Python's license is GPL-compatible, so this isn't an
Anthony issue.
I'm sorry, but you seem to misunderstand what GPL compatibility
means. It is a _one-way_ street. A license is GPL-compatible if its
terms permit the code it
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW Unix weenies shouldn't be totally forgotten in P3K.
Great idea! Put all this stuff in a weenie module. You can have
weenie.unix and weenie.vms and weenie.unicode, besides the weenie.math
that got all this started.
--
School of Systems
Steven == Steven Bethard [EMAIL PROTECTED] writes:
Steven My only fear with the / operator is that we'll end up with
Steven the same problems we have for using % in string formatting
Steven -- the order of operations might not be what users expect.
Besides STeVe's example, (1) I
Thomas == Thomas Heller [EMAIL PROTECTED] writes:
Thomas I cannot uinderstand your reasoning. How can 'info
Thomas autoconf' incluence the license of the aclocal.m4 file?
It doesn't. The point is the documentation explains that all of the
other files are _part of autoconf_, and come
Jason == Jason Orendorff [EMAIL PROTECTED] writes:
Jason I. Here's an example of the sort of thing you might say if
Jason you did *not* think of paths as strings:
[...]
Jason II. And here is the sort of thing you'd say if you thought
Jason of paths *solely* as strings:
Please
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
BTW. The argument that the readline module should be GPL
licensed seems rather stronger, it's designed to work with a
GPL-ed library and doesn't work with a BSD licensed work-alike
of that library.
Martin This is the
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin So would you just like to see the readline module to be
Martin removed from the Python distribution?
No. I would much prefer that the readline module be made compatible
with libedit (or whatever the pseudo-readline library is
Tim == Tim Peters [EMAIL PROTECTED] writes:
Tim [Martin v. Löwis]
Also, I firmly believe that the FSF would *not* sue the PSF,
but instead first ask that the status is corrected.
They would ask first. That's what they did in the case of Aladdin
Ghostscript's use of readline.
Tim == Tim Peters [EMAIL PROTECTED] writes:
Tim I'm not making myself clear.
Whatever makes you think that?wink In fact, everything you've said
about your criteria for behavior was quite clear from the first, and
it was fairly easy to infer your beliefs about the implications of
history.
I
Jason == Jason Orendorff [EMAIL PROTECTED] writes:
Jason You seem to think that because I said operating systems,
Jason I'm talking about kernel algorithms and such.
I can see how you'd get that impression, but it's not true. My reason
for mentioning OS-level filesystem was to show
Travis == Travis E Oliphant [EMAIL PROTECTED] writes:
Travis Numpy supports arrays of arbitrary fixed-length records.
Travis It is much more than numeric-only data now. One of the
Travis fields that a record can contain is a string. If strings
Travis are supported, it makes
Brett == Brett Cannon [EMAIL PROTECTED] writes:
Brett On 2/9/06, Barry Warsaw [EMAIL PROTECTED] wrote:
Maybe we can amend your rules to those people who both have
commit privileges and have successfully submitted a PEP before.
PEP virgins should go through the normal process.
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M James Y Knight wrote:
Nice and simple.
M Albeit, too simple.
M The above approach would basically remove the possibility to
M easily create bytes() from literals in Py3k, since literals in
M Py3k create Unicode objects,
Fred == Fred L Drake, [EMAIL PROTECTED] writes:
Fred On Tuesday 14 February 2006 22:34, Greg Ewing wrote:
Seems to me this is a case where you want to be able to change
encodings in the middle of reading the stream. You start off
reading the data as ascii, and once you've
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I think that the implementation of encoding-guessing or
Guido auto-encoding-upgrade techniques should be left out of the
Guido standard library design for now.
As far as I can see, little new design is needed. There's no
Bob == Bob Ippolito [EMAIL PROTECTED] writes:
Bob Huh? What does that have to do with anything? I've never
Bob seen a system where /usr/include, /usr/lib, /usr/bin,
Bob etc. are not all on the same mount. It's not really any
Bob different with OS X either.
/usr/share often is
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I'd say there are two symmetric API flavors possible (t
Guido and b are text and bytes objects, respectively, where text
Guido is a string type, either str or unicode; enc is an encoding
Guido name):
Guido -
Ian == Ian Bicking [EMAIL PROTECTED] writes:
Ian Encodings cover up eclectic interfaces, where those
Ian interfaces fit a basic pattern -- data in, data out.
Isn't filter the word you're looking for?
I think you've just made a very strong case that this is a slippery
slope that we
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M Martin v. Löwis wrote:
No. The reason to ban string.decode and bytes.encode is that it
confuses users.
M Instead of starting to ban everything that can potentially
M confuse a few users, we should educate those users and tell
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M The main reason is symmetry and the fact that strings and
M Unicode should be as similar as possible in order to simplify
M the task of moving from one to the other.
Those are perfectly compatible with Martin's suggestion.
M Still,
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole
rationale for /usr/share.
Guido I don't think I've worked at a place where something like
Guido
Josiah == Josiah Carlson [EMAIL PROTECTED] writes:
Josiah The question remains: is str.decode() returning a string
Josiah or unicode depending on the argument passed, when the
Josiah argument quite literally names the codec involved,
Josiah difficult to understand? I don't
Bob == Bob Ippolito [EMAIL PROTECTED] writes:
Bob On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
But you aren't always getting *unicode* text from the decoding
of bytes, and you may be encoding bytes *to* bytes:
Please note that I presumed that you can indeed assume that
Bengt == Bengt Richter [EMAIL PROTECTED] writes:
Bengt The characters in b could be encoded in plain ascii, or
Bengt utf16le, you have to know.
Which base64 are you thinking about? Both RFC 3548 and RFC 2045
(MIME) specify subsets of US-ASCII explicitly.
--
School of Systems and
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Stephen J. Turnbull wrote:
Bengt The characters in b could be encoded in plain ascii, or
Bengt utf16le, you have to know.
Which base64 are you thinking about? Both RFC 3548 and RFC
2045 (MIME) specify subsets
Josiah == Josiah Carlson [EMAIL PROTECTED] writes:
Josiah I try to internalize it by not thinking of strings as
Josiah encoded data, but as binary data, and unicode as text. I
Josiah then remind myself that unicode isn't native on-disk or
Josiah cross-network (which stores and
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Please do take a look. It is the only way: If you were to
Martin embed base64 *bytes* into character data content of an XML
Martin element, the resulting XML file might not be well-formed
Martin anymore (if the encoding of
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
What I advocate for Python is to require that the standard
base64 codec be defined only on bytes, and always produce
bytes.
Greg I don't understand that. It seems quite clear to me that
Greg
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
Base64 is a (family of) wire protocol(s). It's not clear to me
that it makes sense to say that the alphabets used by baseNN
encodings are composed of characters,
Greg Take a look
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron Terry Reedy wrote:
I prefer the shorter names and using recode, for instance, for
bytes to bytes.
Ron While I prefer constructors with an explicit encode argument,
Ron and use a recode() method for 'like to like' coding.
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron We could call it transform or translate if needed.
You're still losing the directionality, which is my primary objection
to recode. The absence of directionality is precisely why recode
is used in that sense for i18n work.
There really isn't a
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
No, base64 isn't a wire protocol. It's a family[...].
Greg Yes, and it's up to the programmer to choose those code
Greg units (i.e. pick an encoding for the characters) that will,
Greg in fact
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron So, lets consider a codec and a coding as being two
Ron different things where a codec is a character sub set of
Ron unicode characters expressed in a native format. And a
Ron coding is *not* a subset of the unicode character set,
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg (BTW, doesn't the fact that you *can* load an XML file into
Greg what we call a text editor say something?)
Why not answer that question for yourself, and then turn that answer
into a description of text semantics?
For me, it says that,
martin == martin [EMAIL PROTECTED] writes:
martin I don't understand. How can you use a C++ compiler, but
martin not the C++ language?
An abbreviation for those features that aren't in C.
martin As the recent const dilemma shows, C99 and C++98 have,
martin unfortunately,
Anthony == Anthony Baxter [EMAIL PROTECTED] writes:
Anthony It's probably worth mentioning that right now, we don't
Anthony even come close to compiling with a C++ compiler. A bunch
Anthony of the bugs are shallow (casting result from malloc, that
Anthony sort of thing) but a
Brett Cannon writes:
There was never a formal one to my knowledge. Part of the problem is that
the PSF acted as a blanket organization this year so we just basically
helped dole out slots to various Python projects. This meant it was not
under very centralized control and thus not easy
Raymond Hettinger writes:
Two people had some difficulty building non-upgraded third-party modules
with Py2.5 on 64-bit machines (I think wxPython was one of the problems)
In my experience wxPython is problematic, period. It's extremely
tightly bound to internal details of everything around
Neal Becker writes:
Well consider this:
str (4)
'4'
int(str (4))
4
str (False)
'False'
bool(str(False))
True
Doesn't this seem a bit inconsisent?
The former case is a *conversion* from an expression that *does not*
have an interpretation in a numerical context to an
Giovanni Bajo writes:
On 05/03/2007 20.30, Phil Thompson wrote:
1. Don't suggest to people that, in order to get their patch
reviewed, they should review other patches. The level of knowledge
required to put together a patch is much less than that required
to know if a patch is the
Giovanni Bajo writes:
On 05/03/2007 19.46, A.M. Kuchling wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
developing
Phil Thompson writes:
MvL wrote:
I doubt this will help. Much of the code isn't owned by anybody
specifically. Those parts that are owned typically find their patches
reviewed and committed quickly (e.g. the tar file module, maintained by
Lars Gustäbel).
Doesn't your last
Martin v. Löwis writes:
Stephen J. Turnbull schrieb:
Second, where the stdlib module is closely bound to the core, the
maintainer ends up being the group of core developers. It can't be
any other way, it seems to me.
It might be that individuals get designated maintainers: Guido
George Brandl writes:
As far as I recall, there has been nearly no one who asked for
commit rights recently, so why complain that the entry barrier is
too great? Surely you cannot expect python-dev to got out and say
would you like to have commit privileges?...
Why not? It depends on
Josiah Carlson writes:
And the best way to encourage someone to maintain a package is...
accepting their patches.
And that's what I think is bull. Whether or not we want or need
maintainers for module or package X is independant of the fact that user
Y has submitted a patch for
Paul Moore writes:
On 16/03/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
What's *actually* under dispute here is whether it's acceptable to classify
this perfectly useful-as-is behavior, that was documented and tested in
released versions of Python for several years (with patches to
Martin v. Löwis writes:
Phillip J. Eby schrieb:
Some other options:
1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
No. It's useful to have a function that performs a
Anthony Baxter writes:
Just a random aside - is anyone else getting increasingly annoyed by
these mass-mailed out survey requests from students?
Annoyed, not particularly. Scared, yes: it's long been known that a
field=FIELD is moribund when people start getting PhDs in FIELD for
Brett Cannon writes:
All in one is fine. Just be *very* wary of getting burned out. I
especially would watch out for python-ideas as any random idea can end
up there and just go on and on with no resolution.
As basically a lurker, I second that -- these summaries (and the
weekly tracker
Barry Warsaw writes:
The problem is that
_(some string
and more of it)
is not the same as
_(some string +
and more of it)
Are you worried about translators? The gettext functions themselves
will just see the result of the operation. The extraction
Barry Warsaw writes:
IMO, this is a problem. We can make the Python extraction tool work,
but we should still be very careful about breaking 3rd party tools
like xgettext, since other projects may be using such tools.
But
_(some string +
and more of it)
is already
Michael Sparks writes:
We generate our component documentation based on going through the AST
generated by compiler.ast, finding doc strings (and other strings in
other known/expected locations), and then formatting using docutils.
Are you talking about I18N and gettext? If so, I'm really
Martin v. Löwis writes:
However, I would prefer to not use the verb support at all. We (the
PSF) don't provide any technical support for *any* version ever
released: '''PSF is making Python available to Licensee on an AS IS
basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES [...].'''
Of
Terry Reedy writes:
This strikes me as an improvement, but 'maintain' is close to
'support' and seems to make a promise that might also have
unintended legal consequences. But that is what your legal consel
is for.
Unilateral statements on a web page do not constitute a contract.
Implied
Martin v. Löwis writes:
I'm all in favor of formalizing a policy of when Python releases
are produced, and what Python releases, and what kinds of changes
they may contain. However, such a policy should be addressed
primarily to contributors, as a guidance, not to users, as
a promise.
Martin v. Löwis writes:
A security fix must not risk the releasability of the branch, i.e. the
maintenance branch should be in a shape to produce a release out of it
as-is at all times.
[...]
Security releases should be made at most one year after a security
patch has been committed
Terry Reedy writes:
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| The impression that many people (including python-dev regulars) have
| that there is a policy of support for both the current release
| (2.5) and the (still very widely used) previous
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 absolutely
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 response
[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
Georg Brandl writes:
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).
We are not going to
Aaron Brady writes:
ISTM you need one only question requiring human attention at a time,
because once a spammer assigns a human (or inhuman of equivalent
intelligence) to cracking you, you're toast.
I can't believe this is still profitable. It's either lucrative or
fulfilling,
O.R.Senthil Kumaran writes:
:-) My idea was, a human got to answer it unscrambled as 'fourth' as he
understands what the question is and gives the proper answer.
Agreed, there could be confusion at first.
But for any given user, there's only going to be a first. Either they
pass the
Terry Reedy writes:
Why not simply embargo any post with an off-site link? Tho there might
have been some, I can't remember a single example of such at SF.
Fine by me; if it doesn't happen often, then embargoing them would be
fine. My occasional experience with distro reporting processes
Neal Becker writes:
Perhaps my comment was misunderstood. I have no objection to a new system,
and it does not have to be based on latex. I just hope there will be some
escape mechanism that allows math.
Docutils already provides the raw directive. I don't know if the
latex backend
Armin Ronacher writes:
rst is simpler than latex:
LaTeX:
\item[\code{*?}, \code{+?}, \code{??}] The \character{*},
\character{+}, and \character{?} qualifiers are all \dfn{greedy}; they
match as much text as possible. Sometimes this behaviour isn't
desired; if the RE
1 - 100 of 1435 matches
Mail list logo
