Brett Cannon writes:
> As one of the co-authors of the PEP I say no.
Procedural question: Doesn't authorship disqualify you from BDF1P, so
you can't pronounce?
(Benevolent Dictator for One PEP)
___
Python-Dev mailing list
Python-Dev@python.org
http:/
First, let me offer congratulations and heartfelt thanks for your hard
work!
Victor Stinner writes:
> For network protocols, I don't know. It looks like the new email
> modules will offer two API levels: low level (native type) using
> bytes, high level using str (unicode). I don't know if the
Kristján Valur Jónsson writes:
> Second, it would be an official nod from the python community that,
> yes, we are not actively developing 2.x anymore, we want to focus
> on 3.x but we acknowledge that there are members of our community
> that cannot, for various reasons, move to 3.x, but stil
Barry Warsaw writes:
> Maybe so, but I think it's actually more fun to be working on
> something other people will actually use. ;)
I think that the point is that the people will be doing this are
supporting software to pay for Johnny's piano lessons, not for
personal pleasure. I imagine many,
l...@rmi.net writes:
> But one can't help but wonder if most of the development community
> is focused on some imaginary future user base, at the expense of
> the much larger current user base.
Of course not. Most of the development community is *focused* on a
very real, very current, and ver
Brett Cannon writes:
> I think people need to stop viewing the difference between Python 2.7
> and Python 3.2 as this crazy shift and view it from python-dev's
> perspective;
That phrasing *is* harsh. People also need to work with code bases
that are incompatible with Python 3.2 for various r
Casey Duncan writes:
> However there are many many more users of Python 2.x than Python
> 3.x. Many may never upgrade for the life of these projects,
> because if it ain't broke, why fix it? It doesn't matter how much
> better Python 3 is than Python 2. It isn't better enough.
And the "don't
C. Titus Brown writes:
> p.s. Seriously? I can accept that there's a rational minimalist argument
> for this "feature",
It is a feature, even if you aren't gonna need it. I want it.
Many programmers do know that sets are partially ordered by inclusion,
preordered by size, and (in Python) tot
Terry Reedy writes:
> ethical character. Or have them consider the partial order dependencies
> between morning get-ready-for-class activities (socks before shoes
> versus pants and shirt in either order). They already do topological
> sorting every day, even if the name seems fancy.
Augme
Thomas Wouters writes:
> To clarify (but I dont speak for the rest of #python, just myself), I think
> the move was premature, but I don't use Arch and I don't know what typical
> Arch users expect.
All of the Arch users I know expect Arch to occasionally do radical
things because they're the
Thomas Wouters writes:
> > This is unrealistic. It would seriously annoy Arch's intended
> > audience. (Eg, recently I've become a lot more favorable to using
> > Word instead of OOo because Word doesn't pop up a useless warning
> > every time I save a .doc file.) Practically speaking, it w
Nick Coghlan writes:
> > Module writers who compound the error by expecting to be imported
> > this way, thereby bogarting the global namespace for their own
> > purposes, should be fish-slapped. ;)
>
> Be prepared to fish-slap all of python-dev then - we use precisely
> this technique to s
James Y Knight writes:
>
> On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote:
>
> > 2010/11/8 James Y Knight :
> >> On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
> >>> So it can be done, but the question is "Why?"
> >>
> >> To keep the batteries included?
> >
> > But they'll only
Alexander Belopolsky writes:
> On Wed, Nov 10, 2010 at 7:28 AM, Victor Stinner
> wrote:
> ..
> > I don't know, but the commit is trivial and cheap. If it improves the
> > support
> > on uncommon compiler, I agree to commit such change.
> >
>
> But it does it at the cost of invalidating
Alexander Belopolsky writes:
> On Wed, Nov 10, 2010 at 10:04 PM, Stephen J. Turnbull
> wrote:
> > ... On the original question, I
> > think it's preferable to keep compilers happy unless you're willing to
> > *require* C99.
>
> Hmm,
"Martin v. Löwis" writes:
> The term "UCS-2" is a character set that can encode only encode 65536
> characters; it thus refers to Unicode 1.1. According to the Unicode
> Consortium's FAQ, the term UCS-2 should be avoided these days.
So what do you propose we call the Python implementation? Yo
"Martin v. Löwis" writes:
> Am 20.11.2010 05:11, schrieb Stephen J. Turnbull:
> > "Martin v. Löwis" writes:
> >
> > > The term "UCS-2" is a character set that can encode only encode 65536
> > > characters; it thus refers to
"Martin v. Löwis" writes:
> Chapter and verse?
Unicode 5.0, Chapter 3, verse C9:
When a process generates a code unit sequence which purports to be
in a Unicode character encoding form, it shall not emit ill-formed
code sequences.
I think anything called "UTF-8 something" is likely
R. David Murray writes:
> I'm sorry, but I have to disagree. As a relative unicode ignoramus,
> "UCS-2" and "UCS-4" convey almost no information to me, and the bits I
> have heard about them on this list have only confused me.
OK, point taken.
> On the other hand, I understand that 'narrow'
"Martin v. Löwis" writes:
> More interestingly (and to the subject) is chr: how did you arrive
> at C9 banning Python3's definition of chr? This chr function puts
> the code sequence into well-formed UTF-16; that's the whole point of
> UTF-16.
No, it doesn't, in the specific case of surrogate
Raymond Hettinger writes:
> Neither UTF-16 nor UCS-2 is exactly correct anyway.
>From a standards lawyer point of view, UCS-2 is exactly correct, as
far as I can tell upon rereading ISO 10646-1, especially Annexes H
("retransmitting devices") and Q ("UTF-16"). Annex Q makes it clear
that UTF-16
Terry Reedy writes:
> Yes. As I read the standard, UCS-2 is limited to BMP chars.
Et tu, Terry?
OK, I change my vote on the suggestion of "UCS2" to -1. If a couple
of conscientious blokes like you and David both understand it that
way, I can't see any way to fight it.
FWIW, ISO/IEC 10646 (whi
If you don't care about the ISO standard, but only about Python,
Martin's right, I was wrong. You can stop reading now.
"Martin v. Löwis" writes:
> I could only find the FCD of 10646:2010, where annex H was integrated
> into section 10:
Thank you for the reference.
I referred to two older ve
"Martin v. Löwis" writes:
> I disagree: Quoting from Unicode 5.0, section 5.4:
>
> # The individual components of implementations may have different
> # levels of support for surrogates, as long as those components are
> # assembled and communicate correctly.
"Assembly" is the problem. If
Nick Coghlan writes:
> For practical purposes, UCS2/UCS4 convey far more inherent information
> than narrow/wide:
That was my stance, but in fact (1) the ISO JTC1/SC2 has deliberately
made them ambiguous by changing their definitions over the years[1],
and (2) the more recent definitions and "i
Alexander Belopolsky writes:
> Yet finding a bug in a str object method after a 5 min review was a
> bit discouraging:
>
> >>> 'xyz'.center(20, '\U00010140')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: The fill character must be exactly one character long
>
James Y Knight writes:
> You put a smiley, but, in all seriousness, I think that's actually
> the right thing to do if anyone writes a new programming
> language. It is clearly the right thing if you don't have to be
> concerned with backwards-compatibility: nobody really needs to be
> able t
Note that I'm not saying that there shouldn't be a UTF-8 string type;
I'm just saying that for some purposes it might be a good idea to keep
UTF-16 and UTF-32 string types around.
Glyph Lefkowitz writes:
> > The theory is that accessing the first character of a region in a
> > string often occu
James Y Knight writes:
> a) You seem to be hung up implementation details of emacs.
Hung up? No. It's the program whose text model I know best, and even
if its design could theoretically be a lot better for this purpose, I
can't say I've seen a real program whose model is obviously better for
James Y Knight writes:
> But, now, if your choices are UTF-8 or UTF-16, UTF-8 is clearly
> superior [...]a because it is an ASCII superset, and thus more
> easily compatible with other software. That also makes it most
> commonly used for internet communication.
Sure, UTF-8 is very nice as a
Alexander Belopolsky writes:
> Any non-trivial text processing is likely to be broken in presence of
> surrogates.
If you're worried about this, write a UCS-2-producing codec that
rejects surrogates or stuffs them into the private zone of the BMP.
Maybe such a codec should be default, but so fa
Greg Ewing writes:
> On 24/11/10 22:03, Stephen J. Turnbull wrote:
> > But
> > if you actually need to remember positions, or regions, to jump to
> > later or to communicate to other code that manipulates them, doing
> > this stuff the straightforward way (just
M.-A. Lemburg writes:
> That would be a possibility as well... but I doubt that many users
> are going to bother, since slicing surrogates is just as bad as
> slicing combining code points and the latter are much more common in
> real life and they do happen to mostly live in the BMP.
That's
M.-A. Lemburg writes:
> Please note that we can only provide one way of string indexing
> in Python using the standard s[1] notation and since we don't
> want that operation to be fast and no more than O(1), using the
> code units as items is the only reasonable way to implement it.
AFAICT, t
Glyph Lefkowitz writes:
> But I don't think that anyone is filling up main memory with
> gigantic piles of character indexes and need to squeeze out that
> extra couple of bytes of memory on such a tiny object.
How do you think editors and browsers represent the regions that they
highlight, th
M.-A. Lemburg writes:
> It is not uncommon for Asians and other non-Latin script users to
> use their own native script symbols for numbers.
Japanese don't, in computational or scientific work where float()
would be used. Japanese numerals are used for dates and for certain
felicitous ages (an
M.-A. Lemburg writes:
> Just because ASCII-proponents may have a hard time reading such
> literals,
That's not the point.
> doesn't mean that script users have the same trouble.
The script users may have no trouble reading them, but that doesn't
mean it's not a YAGNI. In Japanese, it's a YA
Steven D'Aprano writes:
> But in any case, please don't conflate the question of whether Python
> should accept j and/or i for complex numbers with the question of
> supporting non-arabic numerals. The two issues are unrelated.
Different, yes, unrelated, no. They're both about whether varia
Lennart Regebro writes:
> *I* think it is more important. In python 3, you can never ever assume
> anything is ASCII any more.
Sure you can. In Python program text, all keywords will be ASCII
(English, even, though it may be en_NL.UTF-8) for the forseeable
future.
I see no reason not to make
Lennart Regebro writes:
> On Tue, Nov 30, 2010 at 09:23, Stephen J. Turnbull
> wrote:
> > Sure you can. In Python program text, all keywords will be ASCII
>
> Yes, yes, sure, but not the contents of variables,
Irrelevant, you're not converting these to a string re
Steven D'Aprano writes:
> With full respect to haiyang kang, hear-say from one person can hardly
> be described as "strong" evidence
That's *disrespectful* nonsense. What Haiyang reported was not
hearsay, it's direct observation of what he sees around him and
personal experience, plus extrapo
Ben Finney writes:
> Input from an existing text file, as I said earlier. Or any other way of
> text data making its way into a Python program.
> Direct entry at the console is a red herring.
I don't think it is. Not at all. Here's why: '''print "%d" %
some_integer''' doesn't now, and never
"Martin v. Löwis" writes:
> > Aside: how does one log into the Cheeseshop with your Launchpad OpenID?
> > When
> > I try to do it I end up on a "Manual user registration" page. I fill out
> > the
> > username with what I think my PyPI user name is, and add my python.org
> > email
> > ad
Lennart Regebro writes:
> 2010/12/2 Stephen J. Turnbull :
> > T1000 = float('一.◯◯◯')
>
> That was already discussed here, and it's clear that unicode does not
> consider these characters to be something you can use in a decimal
> number, and hence it&#
Neil Hodgson writes:
>While I don't have Excel to test with, OpenOffice.org Calc will
> display in Arabic or Han numerals using the NatNum format codes.
Display is different from input, but at least this is concrete
evidence.
Will it accept Arabic on input? (Han might be too much to ask f
Antoine Pitrou writes:
> The legacy format argument looks like a red herring to me. When
> converting from a format to another it is the programmer's job to
> his/her job right.
Uhmm, the argument *for* this "feature" proposed by several people
is that Python's numeric constructors do it (
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 ea
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 aroun
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 nume
Barry Warsaw writes:
> I said semi-jokingly that the first release of Py3k should be /
> literally/ called Python 3000. Then each successive stabilizing
> release should drop a zero -- e.g. Python 3000, then Python 300, then
> Python 30.
RKN = reverse Knuth numbering?
_
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
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
> > developin
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 la
"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.
>
> I
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 depe
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 patc
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 patche
"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 w
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
disser
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 tracke
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.
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 a
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 real
"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 [...]
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.
Impl
"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 prom
"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 commi
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 re
"Martin v. Löwis" writes:
> The objective is to reduce load for the release manager. Any kind of
> release that is worth anything takes several hours to produce, in
> my experience (if it could be made completely automatic, it wouldn't
> be good, since glitches would not be detected).
I absol
"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
[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.
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
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
> fulfil
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
Antoine Pitrou writes:
> Le vendredi 03 décembre 2010 à 13:58 +0900, Stephen J. Turnbull a
> écrit :
> > Antoine Pitrou writes:
> >
> > > The legacy format argument looks like a red herring to me. When
> > > converting from a format to another it is the
Alexander Belopolsky writes:
> In fact, once the language moratorium is over, I will argue that
> str.encode() and byte.decode() should deprecate encoding argument and
> just do UTF-8 encoding/decoding. Hopefully by that time most people
> will forget that other encodings exist. (I can dream
Steven D'Aprano writes:
> Martin v. Löwis wrote:
> >> It seems counter-productive to me to bother with an identity function
> >> which doesn't meet that constraint. If id(x) == id(y) implies nothing
> >> about x and y (they may, or may not, be the same object) then what's the
> >> point?
> >
Quotes are out of order.
"Martin v. Löwis" writes:
> No, it's not. java.lang.Object.hashCode() is equivalent to Python's
> hash(). In particular, for both of these, the following requirement
> holds: object that *compare* equal must hash equal.
Aha. I see, now. That is indeed a different co
"Martin v. Löwis" writes:
> > Why is useful to expose an identity hash? AFAICS it is *only* useful
> > in building an identity hash table. If so, why not just provide id()
> > or the is operator or both and be done with it?
>
> That's precisely James' point: Java provides the identity hash
Vinay Sajip writes:
> Indeed, and the very first code sample in the logging documentation
> shows exactly the simplistic easy usage you're talking about. I
> can't see why anyone would be scared off by that example.
They're not scared by that example. What you need is a paragraph
below it tha
Oleg Broytman writes:
>Better yet (IMHO) would be to split the huge page into "Logging: Simple
> start" and "Logging: Advanced usage (for the brave of of heart)".
Splitting is OK, but I disagree about the gloss "for the brave of
heart".
In my experience, if it is a YAGNI, the complexity is
Glenn Linderman writes:
> 1) simple example for one file programs, include an example of
> specifying output severity threshold. I'm with Antoine here on my
> expectations.
>
> 2) example for multi-module, showing how a single logging destination
> causes logging to happen in all module
Michael Foord writes:
> It seemed from the discussion that the biggest barrier to enabling it by
> default was possible difficulties when embedding Python (multiple
> interpreters, potential conflicts with application signal handling). A
> public C-API to disable the functionality per inter
Victor Stinner writes:
> >Sorry, I am still learning english :-)
Aren't we all! :-)
___
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/a
Amaury Forgeot d'Arc writes:
> Which precise steps do you take [to cherrypick with export/import]?
hg export -r $CHERRY .tmp.patch
xemacs .tmp.patch
;; Move to end of log message, type "Cherry-picked from: ", then
;; C-u M-! hg id -i -r $CHERRY RET C-x C-s C-x C-c>
hg import .tmp.patch
worked f
R. David Murray writes:
> We merge bug fixes to 2.7 on a routine basis. It is the rule rather
> than the exception, by a long shot.
For bugfixes, of course it's routine. I understand that. My point
was that the case Amaury fears, where the (new) VCS makes things
harder than patching or porti
R. David Murray writes:
> I thought Amaury was saying it was harder than svnmerge, not harder
> than patching by hand (ie: that it *was* patching by hand, including
> .rej files and the lack of tracking). I also heard Georg say that this
> should be fixable, and that he's partly fixed the tra
R. David Murray writes:
> I believe that we have had several cases where Windows "crashed" when
> out-of-range values were passed to the CRT that other platforms
> accepted.
XEmacs had crashes due to strftime on Windows native with VC++. Never
went so far as to BSOD, but a couple of users los
Glenn Linderman writes:
> On 1/6/2011 3:50 PM, And Clover wrote:
> > ISO-8859-1 is the encoding specified by the HTTP RFC
>
> Please could I have the reference to that specification?
RFC 2616 (probably obsolete by now, but IRC ISO 8859/1 is already
there IIRC), and I don't think UTF-8 is the
Victor Stinner writes:
> It doesn't work and so something has to be changed.
What specific bug have you observed?
Everybody hates this hack, or at the very least is somewhat
embarrassed by it, but the working group clearly believes that it
works and something like it is necessary. They've stud
Robert Brewer writes:
> Python 3.1 was released June 27th, 2009. We're coming up faster on the
> two-year period than we seem to be on a revised WSGI spec. Maybe we
> should shoot for a "bytes of a known encoding" type first.
You have one. It's called "ISO 2022: Information processing -- ISO
Antoine Pitrou writes:
> A drop-down [list of modules] would be terribly cumbersome.
On the XEmacs tracker, we use a multilink with a checkbox list for the
modules field. This allows you to type in the text field, to check
multiple boxes, and provides input checking. In my typical usage, I
don
Ian Bicking writes:
> On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull
> wrote:
>
> > Robert Brewer writes:
> >
> > > Python 3.1 was released June 27th, 2009. We're coming up faster on the
> > > two-year period than we seem to be on a revi
Nick Coghlan writes:
> On Fri, Jan 21, 2011 at 3:44 PM, Atsuo Ishimoto wrote:
> > I don't want Python to encourage people to use non-ascii module names.
I don't think anybody is *encouraging* it. The argument is for
*permitting* it, partly for consistency with other identifiers, and
partly be
Atsuo Ishimoto writes:
> Java, a leading language of IT industry, have already support
> non-ASCII class files for years. But I've never seen such files in
> production in Japan, and didn't improve situation until now.
So why wouldn't Python work the same way? The rest of the world can
use no
"Martin v. Löwis" writes:
> Actually, as long people only involve Windows, or only involve Mac,
> it will all work just fine. It's only when they use non-Mac Unix
> (such as Linux), or try to move files across systems using sub-prime
> technology (such as your typical Windows zip utility) they
Guido van Rossum writes:
> Really? I would have thought that cell phones have long been the
> platforms most supportive of Unicode.
I would think so too, except in Japan.
However, my previous phones exposed file systems with names encoded in
Shift JIS to USB and IR browsers, though. (My curre
"Martin v. Löwis" writes:
> It's one thing how the file systems are formatted, but another thing
> how they are presented to APIs. For example, the phones using Windows CE
> would have to convert the file names to Unicode in the OS kernel.
>
> So: for these phones - do you know how they pres
As Nick points out, nobody really seems to think this is an
argument against your patch. I'm going to bow out of this thread
after this post, as I'm clearly out of my technical depth.
Victor Stinner writes:
> Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
1001 - 1100 of 1553 matches
Mail list logo
