ration should be delayed until
after 3.2 is released.
Alternatively, b1 should be postponed until after the Mercurial
migration is done.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
erned about the lack of volunteers that
are interested in working on the infrastructure. I wish some of the
people who stated that they can't wait for the migration to happen
would work on solving some of the remaining problems.
Regards,
Martin
___
so that people could start identifying issues, and determine
where the PEP differs from reality - currently most obviously
in the branching approach).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
Am 19.11.2010 03:23, schrieb Benjamin Peterson:
> 2010/11/18 Jesus Cea :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18/11/10 18:32, "Martin v. Löwis" wrote:
>>> In general, I'm *also* concerned about the lack of volunteers that
get acquainted with the Mercurial tools they are going to use,
without fear of breaking something).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
lans how 2.7 and 3.1
will be maintained after the switchover.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
underestimate what API people actually use in applications
http://tinyurl.com/292vhxx
http://tinyurl.com/23ah8ps
http://tinyurl.com/27fhyvk
http://tinyurl.com/28cuyv9
etc.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
ython.org/dev/peps/pep-0261/
There had been a long discussion on this specific detail when PEP 261
was written, and in the end, an explicit, deliberate, considered
decision was made to raise a ValueError.
Regards,
Martin
___
Python-Dev mail
terms UCS2 and UCS4 which
> are correct and provide a clear description of what Python uses
> internally for code units.
No, we shouldn't. The term UCS-2 is deprecated, see above.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
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 Unicode 1.1. According to the Unicode
> > Consortium's
he Unicode standard, and in fact one of the primary Unicode design
principles.
> A Unicode-
> conforming Python implementation would error at the chr() call, or
> perhaps would not provide surrogateescape error handlers.
Chapter and verse?
> "Although practicality beats purity."
either (would your concern about utf-8
being misleading here been resolved if the thing had been called
"utf-8b"?)
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 sequ
Am 22.11.2010 11:47, schrieb Stephen J. Turnbull:
> "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-f
d UTF-32 (as these terms
designate CEFs). Unfortunately, they also designate CESs.
> If we have to document what the terms we choose mean anyway, why not
> document the existing terms and reduce entropy, rather than invent new
> ones and increase entropy?
Because the proposed existing ter
4".
I don't think this will work. If the linker finds a library of the wrong
ELF type, then it will choke.
Before enabling anything on a build slave, a patch needs to be
contributed to make it work in the first place.
Regards,
Martin
___
Pyt
-bit and 64-bit execution (making the need for adjusted
path names irrelevant).
> Since choosing 32 or 64 bits when compiling python under Solaris change
> the requirement, paths, etc., automating it should be a goal.
>
> PS: Martin, is there any reason to restrict the solaris 10 builds
1676121
http://bugs.python.org/issue1628484
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Am 23.11.2010 00:41, schrieb Jesus Cea:
> On 22/11/10 23:05, "Martin v. Löwis" wrote:
>>> PS: Martin, is there any reason to restrict the solaris 10 buildslaves
>>> to 32 bits, beside the said problems?.
>
>> I don't see that as a restriction. I have
her it uses 4 or 8 bytes).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
c (you always
have to at least make sure manually that the dependencies are
installed).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
fails to work.
The specific cause is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft
Strong Cryptographic Provider has as it's ImagePath value
%SystemRoot%\system32\rsaenh.dll
So the registry (and COM) do rely on environment variables.
Regar
n't always try to use a compiler that is still
available (and we are stressing that a little bit: 3.2 will use
VS 2008, even though it has been already superceded).
In any case, VS 2010 will stop using SxS for the CRT.
Regards,
Martin
___
Python-Dev ma
> So I presume it did the same with IOBinding.py.
No. This file contains only ASCII characters, so notepad has decided
to not add the BOM.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
spread.
So there is no backwards compatibility concern here.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Issue 1050 claims that the 3.1.2 installer has the virus Palevo.DZ.
Can somebody with a virus scanner please confirm or contest that
claim?
Thanks,
Martin
http://bugs.python.org/issue10500
___
Python-Dev mailing list
Python-Dev@python.org
http
t] fraction | intpart "."
exponentfloat ::= (intpart | pointfloat) exponent
intpart ::= digit+
fraction ::= "." digit+
exponent ::= ("e" | "E") ["+" | "-"] digit+
digit ::= "0"..."9"
Reg
Am 28.11.2010 23:31, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 5:17 PM, "Martin v. Löwis" wrote:
>>>>>>> float('١٢٣٤.٥٦')
>>>> 1234.56
>>
>> I think it's a bug that this works. The definition of the float
code points was explicitly added when Unicode
> support was added to Python and has been available since Python 1.6.
That doesn't necessarily make it useful. Alexander's complaint is that
it makes Python unstable (i.e. changing as the UCD changes).
> It is not a bug
Am 29.11.2010 00:01, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis" wrote:
> ..
>>> This definition fails long before we get beyond 127-th code point:
>>>
>>>>>> float('infinity')
>>> inf
&
g/wiki/Decimal_separator
suggests that they would rather U+066B, i.e. '١٢٣٤٫٥٦', which isn't
supported by Python.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tium's stability policy at
http://unicode.org/policies/stability_policy.html
In a sense, this is stronger than Python's backwards compatibility
promises (which allow for certain incompatible changes to occur
over time, whereas Unicode makes promises about al
I have now completed
http://www.python.org/dev/peps/pep-0384/
Benjamin has volunteered to rule on this PEP.
Please comment with any changes you want to see, or speak in
favor or against this PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
supports indo-arabic digits in any
locale (or more specifically in an arabic locale).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
Am 29.11.2010 00:56, schrieb Alexander Belopolsky:
> On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" wrote:
> ..
>> No no no. Addition of Unicode identifiers has a well-designed,
>> deliberate specification, with a PEP and all. The support for
>> non-ASCII di
e to have these digits
accepted, yet the alternative decimal points rejected?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
ll (namely, parsing local number
strings). I claim that there is no meaningful application
of this feature.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
> That's mostly irrelevant. This feature exists and someone, somewhere,
> may be using it. We normally don't remove stuff without deprecation.
Sure: it should be deprecated before being removed.
Regards,
Martin
___
Python-Dev mailing
; - PyStructSequence_SetItem(), similar to the
> macro PyStructSequence_SET_ITEM; the PyStructSequence structure should
> be hidden.
Sounds good.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
hon itself, but for extension modules.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ifying abi=3),
it should certainly be implemented in Python 3.2, despite the distutils
freeze.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
uldn't appear in the ABI then at all). Renaming them
right away might be fine.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ojects/python/branches/p...@84329
http://svn.python.org/projects/python/branches/pep-0384
(84329 is the value of svnmerge-integrated).
In any case, I posted it to Rietveld as
http://codereview.appspot.com/3262043/
Regards,
Martin
___
Python-Dev mailing li
Am 29.11.2010 19:33, schrieb Antoine Pitrou:
> On Mon, 29 Nov 2010 08:22:46 +0100
> "Martin v. Löwis" wrote:
>>> The former ensures that literals in code are always readable; the later
>>> allows users to enter numbers in their own number system. How could t
can it return false in another?
Implementations are free to use any version of the UCD.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Am 29.11.2010 09:36, schrieb Georg Brandl:
> Am 29.11.2010 09:09, schrieb "Martin v. Löwis":
>>> I have now completed
>>>
>>> http://www.python.org/dev/peps/pep-0384/
>>>
>>>
>>> was structseq.h considered?
>
ditional characters from outside the ASCII range
(see PEP 3131). For these characters, the classification uses the
version of the Unicode Character Database as included in the unicodedata
module.
That remains unchanged. It was a deliberate design decision of PEP 3131
to not codify a
> Would moving this functionality to the locale module make the issues any
> easier to fix?
You could delegate it to the C library, so: yes.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Am 30.11.2010 20:23, schrieb Antoine Pitrou:
> Le mardi 30 novembre 2010 à 20:16 +0100, "Martin v. Löwis" a écrit :
>>> Would moving this functionality to the locale module make the issues any
>>> easier to fix?
>>
>> You could delegate it to the C libr
n an
unreasonable implementation.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
that. You would need
a number of key strokes to enter each individual ideograph, plus you
have to press the keys for keyboard layout switching to enter the Latin
decimal separator (which you normally wouldn't use along with the Han
numerals).
Regards,
Martin
__
#x27;t actually work, despite the presence of the feature it
was supposedly meant to enable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tion. In fact, the documentation was recently clarified
to deny existence of that feature.
b) fixing it will be much more difficult than you apparently think.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> existing Python code.
And indeed, for the Chinese numerals, we have such strong evidence.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> As of today, "What’s New In Python 3.2" [1] does not even mention the
> unicodedata upgrade to 6.0.0.
One reason was that I was instructed not to change "What's New" a few
years ago.
Regards,
Martin
___
Python-Dev mai
ody can suggest about
> any utilities or scripts that are being widely used and need to be
> ported.
>
>
> http://onpython3yet.com/ might be helpful to you.
Another such list is at
http://www.python.org/3kpoll
Regards,
Martin
___
from an existing text file, as I said earlier.
Which *specific* existing text file? Have you actually *seen* such a
text file?
> Direct entry at the console is a red herring.
And we don't need powerhouses because power comes out of the socket.
Regards,
Martin
___
ollowing it (I didn't know it exists because I never look at the file).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
x27;barry' is already taken. Do I need some kind
> of back door linking of my lp openid and my pypi user id?
Since the "barry" account already exists, you first need to log into
that (likely using a password). You can then claim the LP OpenID as
being associated with that accoun
st straight-forward interpretation of the
specific wording gives an incorrect impression of the implementation.
> The Python 3.x docs apparently
> introduced a reference to the language spec which is clearly not
> capturing the wealth of possible inputs.
Right - but only because the 2.x documen
> Since discussion has trailed off without any blocking objections, I'm
> accepting PEP 384. Martin, you may mark the PEP accepted and proceed
> with merging the implementation for the beta on Saturday.
Thanks! will do (I'll also take into consideration the proposed changes
Am 02.12.2010 21:48, schrieb Tarek Ziadé:
> On Thu, Dec 2, 2010 at 9:24 PM, "Martin v. Löwis" wrote:
>>> Since discussion has trailed off without any blocking objections, I'm
>>> accepting PEP 384. Martin, you may mark the PEP accepted and proceed
>>>
n't specify any changes, anyway.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
n't apply - I don't deny them.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hink it was a bad decision to freeze distutils, and "we" certainly
didn't make that (not any we that includes me, that is). This freeze
made the situation worse.
IIRC, it was really the incompatible changes that made people ask you to
stop chan
Am 02.12.2010 22:30, schrieb Steven D'Aprano:
> Martin v. Löwis wrote:
>>>> Then these users should speak up and indicate their need, or somebody
>>>> should speak up and confirm that there are users who actually want
>>>> '١٢٣٤.٥٦' t
ng.
Instead of evolving a lot, and instead of freezing, I would have
preferred "evolve a little".
> So how would you make the situation better, if not by doing the work
> in distutils2 ?
Lift the freeze. I'm all for replacing distutils with distutils2, but
I'm not sure whether
Am 02.12.2010 22:54, schrieb Michael Foord:
> On 02/12/2010 21:39, "Martin v. Löwis" wrote:
>>> I was told not to touch to Distutils code to avoid any regression
>>> since it's patched to the bones in third party products. So we decided
>>> to
.
That would be useful if there was a clear vision of when distutils2
will be released. Please understand that I'm not blaming you for not
releasing it (it *is* too much for a single person), but please
understand that it's also not helpful to submit changes to a codebase
that is not going to
in alpha
> stage. I want a solid beta before Pycon.
>
> I would even remove Distutils from 3.x altogether at some point since
> setuptools is not Python 3 compatible, and just put distutils2.
>
> 3.3 sounds like a good target.
So will distuils2 be released before that? If so,
er than my motivation to
contribute to distribute (say). I'm just getting tired having to talk to
five projects just to make a single change to the build infrastructure
available to the Python community.
Regards,
Martin
___
Python-Dev mailing li
Am 02.12.2010 23:43, schrieb M.-A. Lemburg:
> Eric Smith wrote:
>>> The current behavior should go nowhere; it is not useful. Something very
>>> similar to the current behavior (but done correctly) should go into the
>>> locale module.
>>
>> I agree wit
e approximated by looking
at actual scripts. This, in turn, is inherently locale-dependent.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
easonably
> preserves backward compatibility.
It seems this is right out for policy reasons.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
> An alpha is already released. A beta will be released for Pycon (I
> need it for my talk :) ) Then hopefully the final before 3.2
Ok, that's promising.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
ossible with today’s distutils. I don’t know if it’s enough to
> build stable-ABI-conformant extension modules.
It is. However, there is also the proposal that they use an ABI tag in
the SO name; having that generated automatically would require a
distutils change.
Regards,
Martin
sibly affect existing code, it
should not be made" applies to essentially any change. So if you
want to avoid breaking things with certainty, not even bug
fixes would be acceptable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
ime. Contributions are welcome.
IOW, it's easier for me to educate users.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
s would be to never refer to "xmlcore"
explicitly (i.e. import from xml.sax._exceptions in
expatreader), but I guess that would defeat the purpose
of the xmlcore renaming.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
t to let people know about it.
See http://python.org/sf/1484556
ISTM that it generates too many false positives to be useful.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
as UTF-8, though: for the host part of the URL, you
have to encode it with IDNA (and there are additional complicated rules
in place, e.g. when the Unicode string already contains %).
Contributions are welcome, as long as they fix this entire issue "for
good" (i.e. in all URL-pr
AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.desktop)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Anthony Baxter wrote:
>> The right thing to do is IRIs.
>
> For 2.5, should we at least detect that it's unicode and raise a
> useful error?
That can certainly be done, sure.
Martin
___
Python-Dev mailing list
Python
.
No check for year since handled in gettmarg().
*/
So this was changed in response to a bug report about a crash.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Christopher Armstrong wrote:
> python -U is a failure for obvious reasons and a
> __future__ import is clearly better.
I disagree.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
and I can set them up.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ing with?
Don't get confused by these colors. The tree compiled nearly all of the
time, even if some tests were failing for an extended period of time on
some platforms.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
o know how to run a buildbot.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
n, they can contribute
patches. -U has worked fine for me in the past, I contributed various
patches to make it work better. It hasn't failed for me at all.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
ated *why* you think these
URLs are relevant in the context of the discussion. To me, it seemed
you are pointing to the existence of distributed testing frameworks.
I was pointing out that we (at least, I) am aware of the existence
of such frameworks,
ype.
The not so obvious way is to change the modules/methods receiving these
strings to work with either string type if that is reasonable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Yingbo Qiu wrote:
> Will anyone have interest in the patch?
This patch comes to late for Python 2.5. It might be considered for 2.6,
if anybody has time to review it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
does have a __module__ attribute, it uses __import__
to import the module, just to make sure it gets into sys.modules.
Otherwise, it looks correct.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
is currently unassigned
b) about a year old
c) in an area of your personal interests
Property a) and b) combined should guarantee that nobody beats you
in fixing the problem while you are researching it.
Regards,
Martin
___
Python-Dev mailing list
the current versions of python)?
It's guaranteed for now; unicode.lower is not locale-aware.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
believe the unicode.lower behaviour is currently right
for most applications, so it should continue to be the
default. An additional locale-aware version should be added,
but that probably means to incorporate ICU into Python,
to get this and other locale properties right in a
platform-in
Unicode 4. It specifies two kinds of case conversion:
simple case conversion, and full case conversion. Python only supports
simple case conversion at the moment. Full case conversion is context
(locale) dependent, and must take into account SpecialCasing.txt.
R
is out of scope of the Unicode specification.
It could be the C locale (and indeed, the C locale implementations
often take the Unicode casing procedure into account these days).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
obj:
>> break # use n as module name
>
> What is "module-ignored" above? It's obviously not a literal string...
It's skipped if module is None (skip dummy package entries)
or n=='__main__'.
Regards,
Martin
with Python 1.5.2, as that version did not
support Unicode at all.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Mihai Ibanescu wrote:
> Yes, as I said, it won't be more broken than before applying the patch (my
> first patch was breaking 1.5.2 completely).
Ah, I didn't notice that it deals with unicode() not being a builtin.
That's fine t
1901 - 2000 of 5755 matches
Mail list logo
