> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> But the base64 string itself *does* have text semantics.
What do you mean by that? The strings of abstract "characters"
defined by RFC 3548 cannot be concatenated in general, they may only
be split at 4-character intervals, they ca
> "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,
> "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> unfort
> "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 thin
> "Jim" == Jim Jewett <[EMAIL PROTECTED]> writes:
Jim> Nick Coghlan asked Marc-Andre Lemburg:
>> There's clearly something that bothers you about this though,
>> and I'd like to understand what it is. Does the term 'context'
>> carry additional, more specific, connotations for
> "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
> "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.
> "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 migr
> "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:
Willem> So, in short, Keyboard interrupts in Lisp are a
Willem> serious-condition, not an error.
Willem> (And what is labeled CriticalException in this discussion,
Willem> has in serious-condition Lisp's counterpart.)
> "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. Conversel
>>>>> "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:
Willem> On 8/2/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>> I don't see it that way. Rather, "Raisable" is the closest
>> equivalent to "ser
> "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 thro
> "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 E
> "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 Termin
> "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 histori
> "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 coul
> "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 opti
> "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 ha
> "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
Michael> (2) is what we have today, but I would prefer (1) to
Michael> gently encourage people to use the precompiled objects
Michael> (which are distinctly faster when re-used).
Didn't Fredrik Lundh strongly imply that
> "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
all
>>>>> "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 t
> "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 progr
> "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 appl
> "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 i1
> "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 mini
>>>>> "Antoine" == Antoine Pitrou <[EMAIL PROTECTED]> writes:
Antoine> Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen
Antoine> J. Turnbull a écrit :
>> It would be nice to be able to lose the "_()" calls to
>> gett
>>>>> "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.
>>
> "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!
Speaking-as-
> "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
Josiah> Indeed, they are similar, but_ different_ in my font as
Josiah> well. The trick is that the glyphs are not different in
Josiah> the case of certain greek or cyrillic letters. They don't
Josiah> just /look/ simil
> "Neil" == Neil Hodgson <[EMAIL PROTECTED]> writes:
Neil> Most variable names were poorly chosen with s, p, q, fla
Neil> (boolean=flag) and flafla being popular. When I asked some
Neil> Japanese coders why they didn't use Japanese words expressed
Neil> in ASCII (Romaji), their
> "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
> "skip" == skip <[EMAIL PROTECTED]> writes:
skip> BTW, there is one project I'm theoretically familiar with
skip> that attempts to handle the dual source situation: XEmacs.
skip> I'm still trying to come to terms with the practical issues
skip> involved. I'm supposed to be u
> "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.
> "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!
Martin> or they are entirely unaware of
> "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 interpret
> "Ian" == Ian Bicking <[EMAIL PROTECTED]> writes:
Ian> Nick Coghlan wrote:
>> While I quite like this idea, would it make it more difficult
>> when the bug tracking for the main source code is eventually
>> migrated off SF? And what would happen to existing
>> documentati
> "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 real
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> It *is* a bug for Python to emit warnings on "major
Martin> platforms" (PEP 7).
OK, I'm as big a standards bigot as the next guy, you hooked me.
After some consideration, I can't write the patch, though. I'm sorry
that
> "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, an
> "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 po
> "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
> "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
> "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
> "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_,
> "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 strin
> "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
> "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 lib
> "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
> "Tim" == Tim Peters <[EMAIL PROTECTED]> writes:
Tim> I'm not making myself clear.
Whatever makes you think that? 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
histor
> "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
> "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
> "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 th
1501 - 1553 of 1553 matches
Mail list logo
