[EMAIL PROTECTED] writes:
> With all these distributed revision control systems now available (bzr, hg,
> darcs, svk, many more), I find I need an introduction to the concepts and
> advantages of repository distribution.
> Can someone point me to some useful content (web pages or books)
> wh
I think this howto is of general interest to the community, but I'm
crossposting to Tracker-Discuss and redirecting discussion there.
Reply-To set.
Barry Warsaw writes:
> Thanks Martin, I think this will work for now. Is there any way you
> can allow me to edit this query too?
While as Mart
Ben Finney writes:
> "Stanley A. Klein" <[EMAIL PROTECTED]> writes:
>
> > IMHO, the main system without a package manager is Windows.
>
> AFAICT the MacOS platform also lacks in this area.
Actually, they both have them. Windows has Cygwin (rpm-based), while
for MacOS Fink (deb-based), MacP
Stephen Hansen writes:
> >
> > > > IMHO, the main system without a package manager is Windows.
> > >
> > > AFAICT the MacOS platform also lacks in this area.
> >
> > Actually, they both have them. Windows has Cygwin (rpm-based), while
&
Frank Wierzbicki writes:
> On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I was also going to suggest a platform independent option. I like
> > -Xwhat-follows-is-impl-dependent.
> This would work just fine for us, and it makes sense to have it
> available for al
"Martin v. Löwis" writes:
> > How about "-X is reserved for implementation-specific arguments"?
> Isn't that bikeshedding?
No. I think "implementation-specific" is definitely more accurate,
and I was hoping the suggestion might get an immediate "good idea,
implemented", from somebody already
"Martin v. Löwis" writes:
> > > > How about "-X is reserved for implementation-specific arguments"?
> >
> > > Isn't that bikeshedding?
> >
> > No. I think "implementation-specific" is definitely more accurate,
> > and I was hoping the suggestion might get an immediate "good idea,
> > im
Steven writes:
> On Sat, 19 Apr 2008 22:13:19 +1000
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > Being indexable is subtly different from being subscriptable - the
> > former has stronger connotations of numeric indices and sequence-like
> > behaviour
> With my maths background, I wo
Nick Coghlan writes:
> To suggest yet another colour for the bikeshed, maybe we should ditch
> both unindexable and unsubscriptable and go with "'int' is not a
> sequence or mapping".
I like this best.
___
Python-Dev mailing list
Python-Dev@python.
Bill Janssen writes:
> Internet-compliant email actually has well-specified mechanisms for
> including encoding information; see RFCs 2047 and 2231. There's no
> need to guess; you can just look.
You must be very special to get only compliant email.
About half my colleagues use RFC 2047 to e
"Martin v. Löwis" writes:
> In any case, I'm very skeptical that a general "guess encoding"
> module would do a meaningful thing when applied to incorrectly
> encoded HTML pages.
That depends on whether you can get meaningful information about the
language from the fact that you're looking at
Guido van Rossum writes:
> To the contrary, an encoding-guessing module is often needed, and
> guessing can be done with a pretty high success rate. Other Unicode
> libraries (e.g. ICU) contain guessing modules. I suppose the API could
> return two values: the guessed encoding and a confidence
[EMAIL PROTECTED] writes:
> Currently we have no way to extract the function signatures from C
> code on-the-fly or in a preprocessing step (might be a good GSoC
> project),
+1 on GSoC, except for the bad timing (maybe somebody will start
sponsoring a "Winter Coding Sprint" event?)
__
Greg Ewing writes:
> [EMAIL PROTECTED] wrote:
> > I guess we're going to have to agree to disagree. I find hiding
> directories
> > which contain executable code extremely non-obvious.
>
> I'm worried by this too. I don't like the idea of putting
> large and important things in hidden d
Michael Urman writes:
> I know this way is fairly entrenched in the python release process,
> but it sounds like it's using the tools incorrectly. In particular
> with subversion is very easy (compared to cvs) to branch and to switch
> branches locally. Why not create a new prerelease branch a
[EMAIL PROTECTED] writes:
> It is possible to get both ordered dict and sorted dict semantics in
> the same type if you replace (key, value) pairs for dictionary entries
> with (key,value,order) triples.
Roundup uses something like this concept for its value choice menus.
I don't actually thin
"Martin v. Löwis" writes:
> Given the choice of "run slower" and "run out of memory", Python should
> always prefer the former.
>
> One approach could be to measure how successful a GC run was: if GC
> finds that more-and-more objects get allocated and very few (or none)
> are garbage, it m
"Martin v. Löwis" writes:
> > XEmacs implements this strategy in a way which is claimed to give
> > constant amortized time (ie, averaged over memory allocated).
>
> See my recent proposal.
I did, crossed in the mail. To the extent that I understand both
systems, your proposal looks like an
[EMAIL PROTECTED] writes:
> On 01:02 am, [EMAIL PROTECTED] wrote:
> >To bring my $0.02 to this discussion: the Pybots 'community buildbots'
> >turned out largely to be a failure.
>
> Let's not say it's a failure. Let's instead say that it hasn't yet
> become a success :-).
+1
> >I still
Steve Holden writes:
> "Fail" isn't a negative. As Guido said, it's a description of the test
> behavior under particular circumstances.
This is not true, however. "Fail" is a description of a potentailly
very large class of behaviors. Knowing that the test failed does not
tell you which of
Tristan Seligmann writes:
> * Stephen J. Turnbull <[EMAIL PROTECTED]> [2008-07-14 08:51:27 +0900]:
>
> > The analogy to the fact that True != not not 10 is telling, I think.
>
> What?
>
> >>> True == (not not 10)
Steven D'Aprano writes:
> On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
>
> > FWIW, I meant 10 != not not 10.
>
> >>> 10 != not not 10
> File "", line 1
> 10 != not not 10
> ^
> SyntaxError: invalid
Raymond Hettinger writes:
> Nobody I know spells setup and teardown as two words.
I set up a house of cards. When I'm done, I'm done with setup.
Similarly for "tear down" and "teardown". The two word forms are
verbs, the one word forms are nouns. I don't think it's worth a
column to make that
Ben Finney writes:
> Removal of ``assert*`` names
>
>
> There is no overwhelming consensus on whether to remove the
> ``assert*`` names or the ``fail*`` names;
7 to 1 is overwhelming in my book. See
Message-ID: <[EMAIL PROTECTED]>
From: Antoine Pitrou <[EMAIL P
Ben Finney writes:
> > Message-ID: <[EMAIL PROTECTED]>
> > From: Antoine Pitrou <[EMAIL PROTECTED]>
>
> That measured only usage of unittest *within the Python standard
> library*. Is that the only body of unittest-using code we need
> consider?
Yes, for the purposes of this PEP. We alrea
Terry Reedy writes:
> For the community as a whole, all stdlib modules are suggestions and
> examples, not commands.
Well, even if "standard" is too strong a word, the DeprecationWarnings
and eventual removal of the methods surely constitute an imposition.
_
Ben Finney writes:
> Removal of ``assert*`` names
>
> Arguments in favour of retaining only the ``assert*`` names:
>
> * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference
> for the ``assert*`` names.
>
> * Precedent: The Python standard lib
Ben Finney writes:
> This "fail is a negative word" has already been rebutted, by native
> speakers of English.
Not successfully, it hasn't. Steven d'Aprano describes one style of
testing as "the test passes if it fails to fail in each of a sequence
of cases." That is perfectly good English,
Ben Finney writes:
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes:
>
> > The intuition that "fail" is a negative word is thus well-founded in
> > standard usage.
>
> That's not the same thing as "fail" being a negative
Nick Coghlan writes:
> And downloading pybsddb and installing really shouldn't be all that
> difficult :)
It shouldn't be, but lots of "enterprise"[1] environments will require
qualifying the "new" package according to corporate standards.
I won't argue that this is a sufficient reason to kee
Matt Giuca writes:
> OK, for all the people who say URI encoding does not encode characters: yes
> it does. This is not an encoding for binary data, it's an encoding for
> character data, but it's unspecified how the strings map to octets before
> being percent-encoded.
In other words, it's a
Bill Janssen writes:
> > A quoting function that accepts bytes *must* have an encoding
> > argument.
>
> Huh? What would it use it for?
Ah, you're right. I was thinking in terms of an URI builder, where the
quoter would do any required conversion (eg, if the bytes represented
a string in J
Antoine Pitrou writes:
> It's not only the marketing. Having both releases in lock step means the
> development process is synchronized between trunk and py3k, that there is no
> loss of developer focus, and that merges/backports happen quite naturally.
As usual, in theory precision is infinit
Greg Ewing writes:
> Ulrich Eckhardt wrote:
>
> > AFAIK, OS X guarantees UTF-8 for filesystem encodings. So the OS
> > also provides Unicode filenames and how it deals with broken or
> > legacy media is left up to the OS.
>
> Does this mean that the OS always returns valid utf-8 strings
>
Guido van Rossum writes:
> On Mon, Sep 29, 2008 at 4:29 PM, Victor Stinner
> <[EMAIL PROTECTED]> wrote:
> > It would be hard for a newbie programmer to understand why he's
> > unable to find his very important file ("important r?port.doc")
> > using os.listdir().
> *Every* failure in this s
Adam Olsen writes:
> [1] You could argue that Unicode should add new scalars to handle all
> currently invalid UTF-8 sequences.
AFAIK there are about 2^31 of these, though!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Simon Cross writes:
> I still find this line of reasoning a bit worrying. Imagine an end
> user application like a music player. The user discovers that he can't
> see some .mp3 or .ogg file from the music player that is visibile is
> the file manager. I would expect him to file a bug on the m
Simon Cross writes:
> a) There is some chance that at least ASCII characters will be
> displayed correctly if getfilesystemencoding() is similar to the
> encoding used and corrupted filenames will display correctly except
> for corrupted characters.
All you're saying is that the cases *you* c
"Martin v. Löwis" writes:
> I'm skeptical that new tests actually need backporting at all. Python
> doesn't really get better by new tests being added to an old branch.
> Near-term, it might get worse because the new tests might cause false
> positives, making users worried for no reason.
If
"Martin v. Löwis" writes:
> > If they do fail, they're not "false" positives. If they're "false",
> > then the test is broken, no?
>
> Correct. But they might well be broken, no?
I would hope some effort is made that they not be. If they generate a
positive, I would expect that the contrib
Thomas Wouters writes:
> Neither of those (shipping sources or dynamically linking to GMP) would
> solve the LGPL issue. People who distribute that build of Python would still
> be held by the LGPL -- such as shipping any sources that they embed that
> Python into.
No, that's exactly what the
Jesse Noller writes:
> I don't see how git can be considered given poor windows support -
> compilation on OS/X can be a bear too.
I can't speak to the "poor Windows support", but I've been compiling
both in MacPorts (pretty much every MacPorts release, which is like
weekly) and from the kernel
Brett Cannon writes:
> I have yet to have met anyone who thinks git is great while having
> used another DVCS as extensively (and I mean I have never found
> someone who has used two DVCSs extensively).
When XEmacs was considering changing from CVS, I used Darcs as my
primary VCS for about 4 m
Gustavo Niemeyer writes:
> Both arguments strike me as odd.
I'm an odd fellow, what can I say?
> Having the *option* to leave your history on the server shouldn't
> be a problem, right?
Only if you later try to use it.
> The same goes for (1): having more ways to use the tool isn't
> exac
"Martin v. Löwis" writes:
> Stephen J. Turnbull wrote:
> > Thomas Wouters writes:
> >
> > > Neither of those (shipping sources or dynamically linking to
> > > GMP) would solve the LGPL issue. People who distribute that
> > > build
Thomas Wouters writes:
> Ah, but not true according to who? [...]
> It is certainly the case that such a combination is enough to scare
> off corporate lawyers who aren't sure either (most of them, I bet)
> and would advise against using that build of Python because of the
> LGPL components.
Cosmin Stejerean writes:
> On Tue, Nov 4, 2008 at 12:13 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > We're Python programmers. We're used to people telling us our
> > tool is too slow. We just say it does the job superbly and it's
> > usually fast enough. :)
> I don't agree with complet
Barry Warsaw writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Nov 5, 2008, at 2:44 PM, Martin v. Löwis wrote:
> > Unless somebody had committed to the tag - right?
>
> That would be insane, right? :)
AFAIK it's not insane, just impossible.
Of course in any system you can
In what follows, caveat IANB (I am not Brett, and neither is
Cosmin), but there is some experience with these systems, and my
recommendations are based on that.
Cosmin Stejerean writes:
> On Nov 5, 2008, at 12:16 PM, [EMAIL PROTECTED] wrote:
> > What DVCS fits my poor brain best? I feel I'm li
Tres Seaver writes:
> svn doesn't have any true tags, AFAIK: everything is a branch.
Yow! I couldn't have imagined that would be true. And didn't
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
Brett Cannon writes:
> > You need not feel that way. It's not you---the flexibility of dVCS
> > means that until the Powers That Be promulgate a Workflow, this will
> > be ambiguous.
>
> It also took me quite a while to finally grasp exactly how the typical
> workflow could go with a DVCS.
Nick Coghlan writes:
> If it isn't already there, suspending work on something to work on
> something else would make a very nice scenario to cover, as it is
> something even the core devs sometimes have to deal with.
>
> I'd expect any DVCS to be able to handily beat what I currently do
>
Brett Cannon writes:
> I consider that a perk feature.
Let's not judge which features are perks or essential quite yet. (If
the number of features/scenarios/whatnot becomes a burden on you, then
you must triage them, of course.)
But a lot of people will not know what the features are unless th
"Martin v. Löwis" writes:
> While I'm happy that Barry has automated his part to a high degree,
> my part is, unfortunately, much less automated. I could personally
> automate the build process a bit more, but part of it is also testing
> of the installers, which is manual.
Maybe you could de
"Martin v. Löwis" writes:
> That's not the issue - I don't mind spending that time. However, it
> means that several hours pass between starting the release process,
> and making the binaries available - during this time, users always
> complain why the Windows binaries are not released yet.
Michael Foord writes:
> Installer tests can definitely be automated, and there is also a Python
> API to the virtualbox VM. I wonder if it would be possible to automate
> testing all the installers in various scenarios - each running
> simultaneously in a VM.
Now that would be an impressiv
Nick Coghlan writes:
> True, but it's still a fairly important problem to have a solution to.
> Even internally in large organisations there can be some pretty insane
> environments as cruft accumulates over the years.
M&A and globalization makes it inevitable.
Toshio will remember the Mizuho
"Martin v. Löwis" writes:
> >> 5) represent all environment variables in Unicode strings,
> >>including the ones that currently fail to decode.
> >>(then do the same to file names, then drop the byte-oriented
> >> file operations again)
> >
> > Please, don't do that! Bytes are no
Guido van Rossum writes:
> This sounds too pessimistic to me. I expect that in five years it will
> be universally accepted that these variables must be encoded in a
> standard encoding.
Archival material will not catch up until the plastic rots. And I bet
it takes ten years before the Japane
; set of design mistakes will be with us forever.
For values of "forever" approximating ten years.
> It would be nice if there were a way for evolution to continue
> without another reboot of the world.
Stephen J. Gould says not.
I think Java is a very different case from
Glenn Linderman writes:
> But if you are interested in checking for security issues, shouldn't you
> _first_ decode into some canonical form,
Yes. That's all that is being asked for: that Python do strict
decoding to a canonical form by default. That's a lot to ask, as it
turns out, but th
Glenn Linderman writes:
> On approximately 12/7/2008 8:13 PM, came the following characters from
> I have no problem with having strict validation available. But
> doesn't validation take significantly longer than decoding?
I think you're thinking of XML, where validation can take significan
Glenn Linderman writes:
> "significantly" seems to be the only word at question; it seems that
> there are a fair number of validation checks that could be performed;
> the numeric part of UTF-8 decoding is just a sequence of shifts, masks,
> and ORs, so can be coded pretty tightly in C or
Steve Holden writes:
> Ulrich Eckhardt writes:
> > What I'd just like some feedback on is the approach to return a
> > distinct type (neither a byte string nor a Unicode string) from
> > readdir().
This is presumably unacceptable on the grounds that it will break
existing code that does somet
Toshio Kuratomi writes:
> Adam Olsen wrote:
> > On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
> > wrote:
> >> Unfortunately, even programmers experienced in I18N like Martin, and
> >> those with intuition-that-has-the-force-of-law like Guido,
>
Victor Stinner writes:
> I already asked in September to get an svn account to be able to
> commit directly patches to trunk (or other branches like py3k). My
> query was rejected because I didn't know Python core enough (and
> maybe other reasons that I don't know).
One possible reason is th
Victor Stinner writes:
> Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :
> > Would you review your own code in the same way that other committers
> > review their own?
>
> I'm unable to review my own code.
Of course not, in the forma
Steve Holden writes:
> Hey, isn't Ubuntu Debian-based? ...
Ouch. I don't actually use Ubuntu, but when everybody on my local LUG
list from the "Linux should be Windows but cheaper" newbies to former
NetBSD developers is grouching about upgrade hell, I don't see any
real benefits to be gained.
Aahz writes:
> all. Because I was lazy, last weekend I finally did a two-stage upgrade
> from 7.10 to 8.04 and then 8.10, with zero noticeable problems.
The scary one is two independent reports of fstab corruption in the
8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from
CD,
Disclaimer: I'm a member of the team working with Brett on the DVCS
PEP, and definitely pro-DVCS (specifically working on the git parts).
"Martin v. Löwis" writes:
> If "switching to a modern DVCS" means that users now need to start
> compiling their VCS before they can check out Python,
It do
s...@pobox.com writes:
> >> That failed because of a bug in configure.in:
> >>
> >> case $withval in
> >> no) CC=cc
> >> without_gcc=yes;;
> >> yes)CC=gcc
> >> without_gcc=no;;
> >> *) CC=$withval
> >> without_gcc=$withval;;
> >>
>
Barry Warsaw writes:
> > The scary one is two independent reports of fstab corruption in the
> > 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from
> > CD, mounting the partition, and editing fstab: the editor saves but
> > the fstab returns to the original corrupt state upon
Leif Walsh writes:
> True, most of the upgrade problems deal with packages that aren't in
> the server install. This should be an easy one, but now I'd ask, why
> not use Debian instead?
You mean, "why not stick with Debian instead?"
The reason is that Debian stable lags the real world drama
Raymond Hettinger writes:
> Does the copyright concept even apply to an abstract base class (I
> thought APIs were not subject to copyright, just like database
> layouts and language definitions)?
Yes, it does, although a public API per se is not subject to
copyright, because there's only one
M.-A. Lemburg writes:
> On 2009-01-20 11:02, Michael Foord wrote:
> > Mere collections of facts are not copyrightable as they are not
> > creative (the basis of copyright)
That's incorrect in the U.S.; what is copyrightable is an *original
work of expression fixed in some medium*. "Original"
"Martin v. Löwis" writes:
> So a conversion to a DVCS would only benefit those committers who
> see a benefit in using a DVCS (*) (and would put a burden on those
> committers who see a DVCS as a burden).
That's false. Especially with bzr, they would see improved log
formats by default, and w
Michael Foord writes:
> > If I can't choose a clear winner I am going to look into what it take
> > to run directly on top of svn to avoid the extra step for committers.
> Well, that sounds like an ideal situation to end up in. Is there a
> downside other than the work it creates for you?
I
"Martin v. Löwis" writes:
> > It might also be a good idea to take the download link off the front
> > page of python.org: until that happens newbies are going to keep coming
> > along and downloading it "because it's the newest".
>
> It was (and probably still is) Guido's position that 3.0 *
Raymond Hettinger writes:
> My preference is to *not* mark it as experimental.
Don't take the word "experimental" too seriously. It's clearly an
exaggeration given the current state of 3.0.x. What is meant is an
explicit announcement that the stability rules chosen in response to
the bool-True
"Martin v. Löwis" writes:
> > Don't take the word "experimental" too seriously. What is meant
> > is an explicit announcement that the stability rules will be
> > relaxed for the 3.0.x series *only*.
>
> The name for that shouldn't be "experimental", though. I don't think
> it needs any na
Greg Ewing writes:
> The fact that yielding is going on is not of
> interest in that situation -- it's just an
> implementation detail. What you really want to
> express is calling another function, but without
> losing your status of coroutine-ness.
But doesn't "yield" in the sense of "yiel
Scott Dial writes:
> On 8/21/2011 3:12 PM, Terry Reedy wrote:
> > On 8/21/2011 5:09 AM, Sandro Tosi wrote:
> >> I can see your point: the reason I committed it also on the stable
> >> branches is that .ico are already out there (since a long time) and
> >> they were currently not recognized. I
Nick Coghlan writes:
> Since I tend to use the one word 'filesystem' form myself (ditto for
> 'filename'), I'm +1 for FilesystemError, but I'm only -0 for
> FileSystemError (so I expect that will be the option chosen, given
> other responses).
I slightly prefer FilesystemError because it pars
Terry Reedy writes:
> The current UCS2 Unicode string implementation, by design, quickly gives
> WRONG answers for len(), iteration, indexing, and slicing if a string
> contains any non-BMP (surrogate pair) Unicode characters. That may have
> been excusable when there essentially were no su
Terry Reedy writes:
> Excuse me for believing the fine 3.2 manual that says
> "Strings contain Unicode characters."
The manual is wrong, then, subject to a pronouncement to the contrary,
of course. I was on your side of the fence when this was discussed,
pre-release. I was wrong then. My bet
Antoine Pitrou writes:
> On Thu, 25 Aug 2011 01:34:17 +0900
> "Stephen J. Turnbull" wrote:
> >
> > Martin has long claimed that the fact that I/O is done in terms of
> > UTF-16 means that the internal representation is UTF-16
>
> Which I/O?
Eg,
Antoine Pitrou writes:
> Le jeudi 25 août 2011 à 02:15 +0900, Stephen J. Turnbull a écrit :
> > Antoine Pitrou writes:
> > > On Thu, 25 Aug 2011 01:34:17 +0900
> > > "Stephen J. Turnbull" wrote:
> > > >
> > > > Marti
Terry Reedy writes:
> Please suggest a re-wording then, as it is a bug for doc and behavior to
> disagree.
Strings contain Unicode code units, which for most purposes can be
treated as Unicode characters. However, even as "simple" an
operation as "s1[0] == s2[0]" cannot be relied
Guido van Rossum writes:
> I see nothing wrong with having the language's fundamental data types
> (i.e., the unicode object, and even the re module) to be defined in
> terms of codepoints, not characters, and I see nothing wrong with
> len() returning the number of codepoints (as long as it i
Guido van Rossum writes:
> On Wed, Aug 24, 2011 at 5:31 PM, Stephen J. Turnbull
> wrote:
> > Strings contain Unicode code units, which for most purposes can be
> > treated as Unicode characters. However, even as "simple" an
> > operation as &quo
Nick Coghlan writes:
> GvR writes:
> > Let's just define a Unicode string to be a sequence of code points and
> > let libraries deal with the rest. Ok, methods like lower() should
> > consider characters, but indexing/slicing should refer to code points.
> > Same for '=='; we can have a libra
"Martin v. Löwis" writes:
> No, that's explicitly *not* what C6 says. Instead, it says that a
> process that treats s1 and s2 differently shall not assume that others
> will do the same, i.e. that it is ok to treat them the same even though
> they have different code points. Treating them diff
"Martin v. Löwis" writes:
> Am 25.08.2011 11:39, schrieb Stephen J. Turnbull:
> > "Martin v. Löwis" writes:
> >
> > > No, that's explicitly *not* what C6 says. Instead, it says that a
> > > process that treats s1 and s2 differe
Paul Moore writes:
> IronPython and Jython can retain UTF-16 as their native form if that
> makes interop cleaner, but in doing so they need to ensure that basic
> operations like indexing and len work in terms of code points, not
> code units, if they are to conform.
[...]
> They lose the
Guido van Rossum writes:
> I don't think anyone else has that impression. Please cite chapter and
> verse if you really think this is important. IIUC, UCS-2 does not
> allow surrogate pairs,
In the original definition of UCS-2 in draft ISO 10646 (1990),
everything in the BMP except for 0x
Raymond Hettinger writes:
> The naming convention for codecs is that the UTF prefix is used for
> lossless encodings that cover the entire range of Unicode.
Sure. The operative word here is "codec", not "str", though.
> "The first amendment to the original edition of the UCS defined
> UTF-1
Antoine Pitrou writes:
> On Mon, 29 Aug 2011 12:43:24 +0900
> "Stephen J. Turnbull" wrote:
> >
> > Since when can s[0] represent a code point outside the BMP, for s a
> > Unicode string in a narrow build?
> >
> > Remember, the UCS-2/na
Antoine Pitrou writes:
> Sorry, what is a conformant UTF-16 array op?
For starters, one that doesn't ever return lone surrogates, but rather
interprets surrogate pairs as Unicode code points as in UTF-16. (This
is not a Unicode standard definition, it's intended to be suggestive
of why many app
Guido van Rossum writes:
> On Tue, Aug 30, 2011 at 7:55 PM, Stephen J. Turnbull
> wrote:
> > For starters, one that doesn't ever return lone surrogates, but rather
> > interprets surrogate pairs as Unicode code points as in UTF-16. (This
> > is not a Unic
Glenn Linderman writes:
> From comments Guido has made, he is not interested in changing the
> efficiency or access methods of the str type to raise the level of
> support of Unicode to the composed character, or grapheme cluster
> concepts.
IMO, that would be a bad idea, as higher-level Unic
1201 - 1300 of 1553 matches
Mail list logo
