Marc-Andre Lemburg added the comment:
On 04.01.2022 00:49, Erlend E. Aasland wrote:
>
> Erlend E. Aasland added the comment:
>
> I see that PEP 249 does not define the semantics of lastrowid for
> executemany(). What's the precedence here, MAL? IMO, it would be nice to
Marc-Andre Lemburg added the comment:
On 04.01.2022 11:02, Erlend E. Aasland wrote:
>
> Erlend E. Aasland added the comment:
>
> Thank you for your input Marc-André.
>
> For SQLite, it's pretty simple: we use an API called
> sqlite3_last_insert_rowid() which tak
Marc-Andre Lemburg added the comment:
On 04.01.2022 21:02, Erlend E. Aasland wrote:
>
> Erlend E. Aasland added the comment:
>
>> If possible, it's usually better to have the .executemany() create a
>> cursor with an output array providing the row ids, e.g. usin
Marc-Andre Lemburg added the comment:
Hi Tony,
from practical experience, it is a whole lot better to not deal with
timezones in data processing code at all, but instead only use
naive UTC datetime values everywhere, expect when you have to
prepare reports or output which has a requirement to
Marc-Andre Lemburg added the comment:
On 10.01.2022 23:01, Allie Hammond wrote:
>
> libc_ver() in platform.py (called from platform()) causes a runtime error if
> sys.executable returns null. In my case, FreeRADIUS offers a module
> rlm_python3 which allows you to run python cod
Marc-Andre Lemburg added the comment:
On 08.01.2022 21:56, Erlend E. Aasland wrote:
>
> Marc-André: since Python 3.6, the sqlite3.Cursor.lastrowid attribute does no
> longer comply with the recommendations of PEP 249:
>
> Previously, lastrowid was set to None for operat
Marc-Andre Lemburg added the comment:
On 11.01.2022 20:46, Erlend E. Aasland wrote:
>
> If we are to revert to this behaviour, we'll have to start examining the SQL
> we are given (search for INSERT and REPLACE keywords, determine if they are
> valid (i.e. not a comment, not
Marc-Andre Lemburg added the comment:
On 11.01.2022 21:30, Erlend E. Aasland wrote:
>
>> I'd suggest to deprecate the cursor.lastrowid attribute and
>> instead point people to the much more useful [...]
>
> Yes, I think mentioning the RETURNING ROWID trick in the
Marc-Andre Lemburg added the comment:
On 26.01.2022 01:29, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
>> Bit wmic seems nice solution.
>> Is still working for windows lower than 11?
>
> wmic.exe is still included in Windows 10 and 11, but it's off
Marc-Andre Lemburg added the comment:
> For these reasons, I propose to deprecate locale.getdefaultlocale():
> setlocale(), getpreferredencoding() and getlocale() should be used instead.
Please see the discussion on https://bugs.python.org/issue43552:
locale.getpreferredencoding() ne
Marc-Andre Lemburg added the comment:
On 08.02.2022 11:54, Erlend E. Aasland wrote:
>
> The sqlite3 timestamp converter is buggy, as already noted in the docs[^1].
> Adding timezone support is out of the question[^2][^3][^4][^5], but fixing it
> to be able to discard any attac
Marc-Andre Lemburg added the comment:
Thanks, Victor.
--
___
Python tracker
<https://bugs.python.org/issue46659>
___
___
Python-bugs-list mailing list
Unsub
Marc-Andre Lemburg added the comment:
Unassigning since I don't know the details of bsddb.
--
assignee: lemburg ->
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Marc-Andre Lemburg added the comment:
Closing this request as the encodings package search function should not
be used import external codecs (this poses a security risk).
--
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bug
Marc-Andre Lemburg added the comment:
Closing. There doesn't seem to be much interest in this.
--
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg added the comment:
Not sure why this is still open. The patches were checked in a long time
ago.
--
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
Unassigning: I've never had a need for this in the past years.
--
assignee: lemburg ->
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg added the comment:
Georg: Yes, sure.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue883466>
___
Python-bugs-list mailing list
Unsubs
Marc-Andre Lemburg added the comment:
Unassigning this.
Unless someone provides a patch to add context sensitivity to the
Unicode upper/lower conversions, I don't think anything will change.
The mapping you see in Python (for Unicode) is taken straight from the
Unicode database and th
Marc-Andre Lemburg added the comment:
Nice idea, but why don't you use a dictionary iterator (PyDict_Next())
for the fixup ?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Marc-Andre Lemburg added the comment:
Ah, I hadn't noticed that you're actually manipulating the input
dictionary. You should create a copy and fix that instead of changing
the dict that the user passed in to the function.
You can then use PyDict_Next() for fast iteration over th
Marc-Andre Lemburg added the comment:
The winerror module should really be coded in C. Otherwise you don't
benefit from the lookup object approach.
The files I uploaded only server as basis for such a C module. Would be
great if you could find someone to write such a module - preferably
us
Marc-Andre Lemburg added the comment:
A couple of notes:
* platform.uname() needs to be fixed, not the individual query functions.
* The third entry of uname() should return "Vista" instead of
"Microsoft" on MS Vista.
* A patch should go on trunk and into 2.5.2, since th
Marc-Andre Lemburg added the comment:
Yes, please. Thanks.
--
assignee: lemburg -> jafo
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
P
Marc-Andre Lemburg added the comment:
Pat, we already have system_alias() for exactly the purpose you suggested.
Software relying on platform.system() reporting "Vista" will have to use
Python 2.5.2 as minimum Python version system requirement - pretty much
the same as with all other
Marc-Andre Lemburg added the comment:
My name appears in that Makefile because I wrote it and used it to
create the charmap codecs.
The reason why the Mac Japanese codec was not created for 2.x was the
size of the mapping table.
Ideal would be to have the C version of the CJK codecs support
Marc-Andre Lemburg added the comment:
Adding Python 2.6 as version target.
--
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
Nice codec !
The only nit I have is the name: "xml" isn't intuitive enough. I had to
read the code to figure out what the codec actually does.
"xml" used a encoding usually refers to having Unicode text converted to
ASCII with X
Marc-Andre Lemburg added the comment:
Leaving the module name as "xml" would remove that name from the
namespace of possible encodings.
"xml" as encoding name is problematic, as many people regard writing
data in XML as "encoding the data in XML".
I'd simpl
Marc-Andre Lemburg added the comment:
Thanks, Walter !
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1399>
__
___
Python-bugs-list mailing list
Unsubs
Marc-Andre Lemburg added the comment:
The problem is also present in Python 2.4 and 2.3. Confirmed on AIX 5.3.
--
nosy: +lemburg
versions: +Python 2.3, Python 2.4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
I think you have a wrong understanding of round-tripping.
In Unicode it is really irrelevant if you're using a UCS2 surrogate pair
or a UCS4 representation to describe a code point. The length of the
Unicode representation may change, but the meaning
Marc-Andre Lemburg added the comment:
Rejecting the patch, since it hasn't been updated.
--
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
>
> I'm pretty sure that anything that claims to be UTF-{8,16,32} needs
> to reject both surrogates *and* noncharacters. Here's something from the
> published Unicode Standard's p.24 abo
Marc-Andre Lemburg added the comment:
The final parameter is an extension to the decoder API signature,
so it's not surprising that not all codecs implement it.
The ones that do should use it for all calls, since that way
the actual consumed number of bytes is correctly reported
back t
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> New submission from Antoine Pitrou :
>
> This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
>
> Example micro-benchmark:
>
> ./python -m timeit -s "a='x'*1
Marc-Andre Lemburg added the comment:
[Posted the reply to the right ticket; see issue13136 for the original
post to the wrong ticket]
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.
Looks like I posted the comment to the wrong ticket.
--
_
Marc-Andre Lemburg added the comment:
I don't see why these modules should be auto-generated. The constants
in the modules hardly ever change and are also not affected by architecture
differences (e.g. Mac OS X, Solaris, etc.) AFAICT.
If you think they need to be auto-generated, you s
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> you should make a case by example
>
> Did you read comments of this issue and my email thread on python-dev?
No.
> There are differents examples:
>
> - L
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> The error comes from the way Python computes timezone and daylight: it
> queries the tm_gmtoff of two timestamps, one close to the first of January,
> the other close to the first of July. But last Jan
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> A fairly "correct" way is to query the time zone database at time module
>> import time by using the DST and GMT offset of that tim
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>>> But that does not give the *other* timezone :-(
>> Which other timezone ?
> I meant the other timezone *name*.
>
> I think we don&#x
Marc-Andre Lemburg added the comment:
Terry J. Reedy wrote:
>
> Terry J. Reedy added the comment:
>
> Martin, I do not understand. The default hash is based on id (as is default
> equality comparison), not value. Are you OK with hash values changing if the
> &
Marc-Andre Lemburg added the comment:
Some comments:
1. The security implications in all this is being somewhat overemphasized.
There are many ways you can do a DoS attack on web servers. It's the
responsibility of the used web frameworks and servers to deal with
the possible cases.
I
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> 3. Changing the way strings are hashed doesn't solve the problem.
>
> Hash values of other types can easily be guessed as well, e.g.
> take integers which use a trivial hash function.
Here's an exa
Marc-Andre Lemburg added the comment:
The email interface ate part of my reply:
>>> g = ((x*(2**64 - 1), hash(x*(2**64 - 1))) for x in xrange(1, 100))
>>> s = ''.join(str(x) for x in g)
>>> len(s)
32397634
>>> g = ((x*(2**64 - 1), hash(x*(2
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> 1. The security implications in all this is being somewhat overemphasized.
>
> There are many ways you can do a DoS attack on web servers. It's the
> responsibility of the used web frameworks and server
Marc-Andre Lemburg added the comment:
Paul McMillan wrote:
>
> This is not something that can be fixed by limiting the size of POST/GET.
>
> Parsing documents (even offline) can generate these problems. I can create
> books that calibre (a Python-based ebook format shift
Marc-Andre Lemburg added the comment:
Before continuing down the road of adding randomness to hash
functions, please have a good read of the existing dictionary
implementation:
"""
Major subtleties ahead: Most hash schemes depend on having a "good" hash
function, i
Marc-Andre Lemburg added the comment:
Demo patch implementing the collision limit idea for Python 2.7.
--
Added file: http://bugs.python.org/file24151/hash-attack.patch
___
Python tracker
<http://bugs.python.org/issue13
Marc-Andre Lemburg added the comment:
The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.
Traceback (most recent call last):
File "", line 1, in
KeyError: 'too many hash collisions'
I
Marc-Andre Lemburg added the comment:
Stupid email interface again... here's the full text:
The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.
>>> d = dict((x*(2**64 - 1), hash(x*(2**64 - 1))
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> hash-attack.patch does never decrement the collision counter.
Why should it ? It's only used as local variable in the lookup function.
Note that the limit only triggers o
Marc-Andre Lemburg added the comment:
Here's an example of hash-attack.patch finding an on-purpose
programming error (hashing all objects to the same value):
http://stackoverflow.com/questions/4865325/counting-collisions-in-a-python-dictionary
(see the second example on the page for @Wi
Marc-Andre Lemburg added the comment:
Paul McMillan wrote:
>
>> I'll upload a patch that demonstrates the collisions counting
>> strategy to show that detecting the problem is easy. Whether
>> just raising an exception is a good idea, is another issue.
>
>
Marc-Andre Lemburg added the comment:
Tim Peters wrote:
>
> Tim Peters added the comment:
>
> [Marc-Andre]
>> BTW: I wonder how long it's going to take before
>> someone figures out that our merge sort based
>> list.sort() is vulnerable as well... its wors
Marc-Andre Lemburg added the comment:
Christian Heimes wrote:
> Marc-Andre:
> Have you profiled your suggestion? I'm interested in the speed implications.
> My gut feeling is that your idea could be slower, since you have added more
> instructions to a tight loop, that is
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Christian Heimes wrote:
>> Marc-Andre:
>> Have you profiled your suggestion? I'm interested in the speed implications.
>> My gut feeling is that y
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> Patch version 5 fixes test_unicode for 64-bit system.
Victor, I don't think the randomization idea is going anywhere. The
code has many issues:
* it is exceedingly complex
* the method would need to be implemen
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> * it is exceedingly complex
>
> Which part exactly? For hash(str), it just add two extra XOR.
I'm not talking specifically about your patch, but the whole idea
Marc-Andre Lemburg added the comment:
Mark Shannon wrote:
>
> Mark Shannon added the comment:
>
>>>> * the method would need to be implemented for all hashable Python types
>>> It was already discussed, and it was said that only hash(str) need to
>>>
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> OTOH, the collision counting patch is very simple, doesn't have
>> the performance issues and provides real protection against the
>> attack.
>
> I
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> [Antoine]
>> Also, how about false positives? Having legitimate programs break
>> because of legitimate data would be a disaster.
>
> This worries me, too.
&
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> On my slow dev machine 1000 collisions run in around 22ms:
>>
>> python2.7 -m timeit -n 100 "dict((x*(2**64 - 1), 1) for x in xrange(1,
>> 1000))&q
Marc-Andre Lemburg added the comment:
Frank Sievertsen wrote:
>
> I don't want my software to stop working because someone managed to enter
> 1000 bad strings into it. Think of a software that handles names of customers
> or filenames. We don't want it to break c
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> I suggest to:
> 1) remove the alias for tactis;
> 2) add the aliases for latin_* and the tests for the aliases;
> 3) fix the email.charset to use the new aliases in
Marc-Andre Lemburg added the comment:
I think it's better to use a StringIO instance for the tests.
Regarding resetting the incremental codec every time .encode() is called:
Hye-Shik will have to comment. Perhaps there's an internal reason why the
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> euc_jp and euc_kr seem to be backward (that is, codecs translates them to the
> _ version, instead of translating the _ version to the - version). I worry
> that th
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Sometimes, we need to know the version of the Linux kernel. Recent examples:
> test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux <
> 2.6.
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> The returned value should be a version string in a fixed format,
>> not a tuple. I'd suggest to use _norm_version() for this.
>
> How do you compare vers
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Use "%s.%s.%s" % linux_version() if you would like to format the version. The
> format is well defined. (You should only do that under Linux.)
No, please follow th
Marc-Andre Lemburg added the comment:
Closing the ticket again.
We still need codecs.open() to support applications that target Python 2.x and
3.x.
You can reopen it after Python 2.x has been end-of-life'd.
--
resolution: -> postponed
status: open -
Marc-Andre Lemburg added the comment:
Correcting the title: this ticket is about codecs.open(), not StreamRead and
StreamWriter, both of which are essential parts of the Python codec machinery
and are needed to be able to implement per-codec implementations of codecs
which read from and
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Codec.encode() and Codec.decode() refer to StreamCode, but I cannot find this
> class in the doc nor in the code.
>
> I suppose that it should be replaced by I
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> You can then use linux_version().split('.') in code that want
>> to do version comparisons.
>
> It doesn't give the expected result:
>
&g
Changes by Marc-Andre Lemburg :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12158>
___
___
Pyth
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> TextIOWrapper() is conceptually something completely different. It's
>> more something like StreamReaderWriter().
>
> That's a rather strange asser
Changes by Marc-Andre Lemburg :
--
title: Deprecate codecs.open(), codecs.StreamReader and codecs.StreamWriter ->
Deprecate codecs.open()
___
Python tracker
<http://bugs.python.org/iss
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I think it's better to use a StringIO instance for the tests.
>
> For which test excatly? An encoder produces bytes, I don't the relation with
> StringIO
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Do we need an additional method? It seems that this reset() could also be
> written encoder.encode('', final=True)
+1
I think that
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le mercredi 25 mai 2011 à 08:23 +, Marc-Andre Lemburg a écrit :
>>> Do we need an additional method? It seems that this reset() could
>>> also be written
Marc-Andre Lemburg added the comment:
Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
> Definitely. We can fix real bugs in distutils, but sometimes it’s best to
> avoid disruptive changes and let distutils with its buggy behavior and let
> the packaging mo
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> What is not-a-charset?
>
> I apparently misunderstood what normalize_encodings does. It isn't doing a
> lookup in the codecs registry and returning the ca
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> Well, my thought was to avoid having multiple charset alias lists in the
> stdlib, and reusing the one in codecs, which is larger than the one in email,
> seemed to
Marc-Andre Lemburg added the comment:
Roundup Robot wrote:
>
> Roundup Robot added the comment:
>
> New changeset 3555cf6f9c98 by Victor Stinner in branch 'default':
> Issue #8796: codecs.open() calls the builtin open() function instead of using
> http
Marc-Andre Lemburg added the comment:
Michele Orrù wrote:
>
> Michele Orrù added the comment:
>
> Any idea about how to unittest mime.aliases?
Test the APIs you probably created for accessing it.
> Also, since I've just created a new file, are there some buracratic iss
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> '\u1ff3'.upper() returns '\u1ffc', so we have:
> U+1FF3 (ῳ - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
> U+1FFC (ῼ - GREEK CAPITAL LETTER OMEGA WITH
Marc-Andre Lemburg added the comment:
Chris Rebert wrote:
>
> Chris Rebert added the comment:
>
> Per msg129958, attached is my stab at a patch to replace most uses of
> os.popen() with the subprocess module. The test suite passes on my Mac, but
> the patch does touc
Marc-Andre Lemburg added the comment:
mike bayer wrote:
> >
> > mike bayer added the comment:
> >
> > regarding "hey this is an MS bug not Python", projects which feature
> > optional C extensions are starting to apply workarounds for the issue on
Marc-Andre Lemburg added the comment:
Stefan Krah wrote:
> >
> > Stefan Krah added the comment:
> >
> > Marc-Andre Lemburg wrote:
>> >> Wouldn't it be better to have distutils tell the user about the
>> >> possible options, instead of
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> The change to sys.platform=='linux' would break code even on current
>> platforms.
>
> Correct. Compared to introducing 'linux3', I consi
Marc-Andre Lemburg added the comment:
I think it would be better to use this code:
if (!Py_UNICODE_ISUPPER(*s)) {
*s = Py_UNICODE_TOUPPER(*s);
status = 1;
}
s++;
while (--len > 0) {
if (Py_UNICODE_ISLOWER(*s)) {
*s = Py_UNICODE_TOLOWER
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Do you mean "if (!Py_UNICODE_ISLOWER(*s)) {" (with the '!')?
Sorry, here's the correct version:
if (!Py_UNICODE_ISUPPER(*s)) {
*s = Py_UN
Marc-Andre Lemburg added the comment:
Alan Justino wrote:
>
> I am getting a hard time trying to do some BDD with c-based datetime because
> I cannot mock it easily to force datetime.datetime.now() to return a desired
> value, making almost impossible to test time-based co
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
>
> Tom Christiansen added the comment:
>
> Please do not call this "utf-8-java". It is called "cesu-8" per UTS#18 at:
>
> http://unicode.org/reports/tr26/
>
> CESU-8 is *not* a a v
Marc-Andre Lemburg added the comment:
Corrected the title again. See my comment.
--
title: Add CESU-8 codec ("java modified utf-8") -> Add "java modified utf-8"
codec
versions: +Python 3.3 -Python 2.7, Python 3.2
__
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Corrected the title again. See my comment.
Please open a new ticket, if you want to add a CESU-8 codec.
Looking at the relevant use cases, I'm at most +0 on adding the
modified UTF-8 codec. I think such codecs ca
Marc-Andre Lemburg added the comment:
> Keep in mind that we should be able to access and use lone surrogates too,
> therefore:
> s = '\ud800' # should be valid
> len(s) # should this raise an error? (or return 0.5 ;)?
> s[0] # error here too?
> list(s) # he
Marc-Andre Lemburg added the comment:
Julian Taylor wrote:
>
> New submission from Julian Taylor :
>
> using unicode strings for locale.normalize gives following traceback with
> python2.7:
>
> ~$ python2.7 -c 'import locale; locale.normalize(u"en_US")
1 - 100 of 1946 matches
Mail list logo
