Marc-Andre Lemburg m...@egenix.com 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**64 - 1))) for x in xrange(1, 100))
d
Marc-Andre Lemburg m...@egenix.com 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 servers to deal
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com 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 time.
But that does
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
But that does not give the *other* timezone :-(
Which other timezone ?
I meant the other timezone *name*.
I think we don't understand each other
Marc-Andre Lemburg m...@egenix.com 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 January
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com 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 pit...@free.fr added the comment:
Before going further with this, I'd suggest you have a look
Marc-Andre Lemburg m...@egenix.com 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 m...@egenix.com added the comment:
Antoine Pitrou wrote:
New submission from Antoine Pitrou pit...@free.fr:
This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
Example micro-benchmark:
./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com 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 about noncharacter code points
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
New submission from Ezio Melotti ezio.melo...@gmail.com:
From Chapter 03 of the Unicode Standard 6[0], D91:
• UTF-16 encoding form: The Unicode encoding form that assigns each Unicode
scalar value in the ranges U
Marc-Andre Lemburg m...@egenix.com added the comment:
Tennessee Leeuwenburg wrote:
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment:
Thanks for the review. Here is a patch incorporating the two comments being
to move some comments.
Hmm, the documentation patch doesn't
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC
is supported at build time.
I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether
Marc-Andre Lemburg m...@egenix.com added the comment:
Georg Brandl wrote:
Also, we might think about removing this version number everywhere.
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12326
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
So what about doing the same for FreeBSD, SunOS, and Windows?
I agree that's definitely out of scope of this issue.
We could change the title of the ticket
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm not sure I understand why platform.release() isn't sufficient
for this purpose. Note that some systems return alphanumeric
values
Marc-Andre Lemburg m...@egenix.com added the comment:
Moved the discussion here from issue12326:
[Larry Hastings]
If we're changing linux2 / linux3 to just linux, we should be
consistent and do it for everybody. I propose sys.platform under 3.3
should contain things like linux, freebsd
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
We could change the title of the ticket :-)
No please, move the discussion to #12795 which has a well defined title. This
issue is closed. (#12795
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
What we could do is add a function that tries to find out the
true version number of the OS, e.g. for Windows 7 that would
be (6, 1, 7601) instead of the marketing name '7' returned by
platform.release().
Yes
Marc-Andre Lemburg m...@egenix.com added the comment:
Nick Coghlan wrote:
As a separate, but related point, IncrementalDecoder.getstate() includes an
explanation on how to save arbitrary state as an integer, but no such
explanation (not even a reference to the IncrementalDecoder version
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
FreeBSD or OpenBSD release major version frequently, something like one
per year, or one per two years. FreeBSD and OpenBSD developers knows
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, it is important to somehow get the build information for
Python, since that tells us which OS features were available
at the time of compilation
Marc-Andre Lemburg m...@egenix.com added the comment:
[This discussion is really off-topic for this issue, it should either
be moved to issue12795 or a new ticket]
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
No, it doesn't (except for a bug that Matthias
Marc-Andre Lemburg m...@egenix.com added the comment:
Tennessee Leeuwenburg wrote:
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment:
Some more tests, updated initial state of BufferedIncrementalEncoder to be
the correct type, updated rst file. Bit tired, hope I got it right
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
sys.platform refers to build time information,
so the platform module won't help.
When I wrote my patch, I realized that sys.platform is used
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
The attached patch adds the following 4 public macros to unicodeobjects.h:
Py_UNICODE_IS_SURROGATE(ch)
Py_UNICODE_IS_HIGH_SURROGATE(ch
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
It is mostly to test FreeBSD major version, and it looks like Python is
build on the same FreeBSD major version that it is running on. Maybe
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
#12326 proposes to remove the major version from sys.platform. If we remove
it, we will need another easy way to get this information. I don't
Marc-Andre Lemburg m...@egenix.com added the comment:
James Y Knight wrote:
James Y Knight f...@users.sourceforge.net added the comment:
Sure, you can compile and run Python on both versions of Linux, but
what if your application uses features that are only present in Linux
3.0 and later
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin von Gagern wrote:
Martin von Gagern martin.vgag...@gmx.net added the comment:
Marc-Andre Lemburg wrote:
Both Python and the application will make certain assumptions about
the platform depending on the compile time environment
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
The suggested change removes the compile time information from
the platform string, so that information needs to be preserved
in a new attribute.
-1 on any new
Marc-Andre Lemburg m...@egenix.com added the comment:
Éric Araujo wrote:
Éric Araujo mer...@netwok.org added the comment:
We do have distutils to read the full compile time information
We have sysconfig in the stdlib in 2.7 and 3.2+.
Right (it originated in distutils), but it has
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Please reread the quoted sentence:
The *compile time* version information needs to be preserved.
Then please give it a very explicit name
Marc-Andre Lemburg m...@egenix.com added the comment:
James Y Knight wrote:
YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't
it, since that's been fixed at linux2 approximately forever). Why do you
think people would suddenly start needing to know the build
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
It's really hard to follow this issue. I'm trying to sum up, please comment
my message if I'm wrong.
--
If I understood correctly, this issue
Marc-Andre Lemburg m...@egenix.com added the comment:
R. David Murray wrote:
R. David Murray rdmur...@bitdance.com added the comment:
MAL wrote:
As already mentioned, the diff between Linux 2.x and 3.x will
grow over time and while there may not be much to see now,
things will change
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
The only way I can read this argument that makes any sense to me is
that you are arguing for a precise build-time OS string. If it is
supposed
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I don't think that macros specific to unicodeobject.c should get the
_PY_UNICODE_ prefix. _Py_ prefix is reserved to exported symbols, but
symbols
Marc-Andre Lemburg m...@egenix.com added the comment:
Some thoughts:
* We can't change the value of a system variable in a patch level
release. It's not a bug and the change is not motivated by
Python, but by the OS vendor. So changes to released versions
are not possible
Marc-Andre Lemburg m...@egenix.com added the comment:
James Y Knight wrote:
James Y Knight f...@users.sourceforge.net added the comment:
M.A., your comments do not make sense in the context of Linux. It does not
actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive
Marc-Andre Lemburg m...@egenix.com added the comment:
Barry A. Warsaw wrote:
Barry A. Warsaw ba...@python.org added the comment:
On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:
As for the cases where linux3 is reported: I don't care that
they break. Python 2.6 and Python 2.7.2
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le 17/08/2011 07:04, Ezio Melotti a écrit :
As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and
Py_UNICODE_JOIN_SURROGATES can
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
Ezio used two different naming schemes in his email. Please always
use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).
Indeed, that was a typo
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
For bug fixes, you can put the macros straight into unicodeobject.c,
but please leave unicodeobject.h untouched - otherwise people will
mess around
Marc-Andre Lemburg m...@egenix.com added the comment:
Maxim Koltsov wrote:
New submission from Maxim Koltsov kolma...@gmail.com:
Python docs (http://docs.python.org/library/time.html#time.time) say that
time.time() function should return UTC timestamp, but actually i get local
one
Changes by Marc-Andre Lemburg m...@egenix.com:
--
assignee: - docs@python
components: +Documentation, Library (Lib)
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12758
Changes by Marc-Andre Lemburg m...@egenix.com:
--
keywords: +easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12758
___
___
Python-bugs-list
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
A PEP 393 draft implementation is available at
https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into
3.3, this issue will be outdated: there won't be narrow builds of Python
anymore (nor
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
#10542 proposes the following macros to factor out common code:
#define _Py_UNICODE_ISSURROGATE
#define _Py_UNICODE_ISHIGHSURROGATE
#define
Marc-Andre Lemburg m...@egenix.com added the comment:
Tom Christiansen wrote:
So keeping your preamble bits, I might have considered doing it
this way if it were me doing it:
#define _Py_UNICODE_IS_SURROGATE
#define _Py_UNICODE_IS_LEAD_SURROGATE
#define
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm reposting my patch from #12751. I think that it's simpler than
belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't
Marc-Andre Lemburg m...@egenix.com added the comment:
Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm reposting my patch from #12751. I think that it's simpler than
Marc-Andre Lemburg m...@egenix.com 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) # here too?
p = s
Marc-Andre Lemburg m...@egenix.com added the comment:
Julian Taylor wrote:
New submission from Julian Taylor jtaylor.deb...@googlemail.com:
using unicode strings for locale.normalize gives following traceback with
python2.7:
~$ python2.7 -c 'import locale; locale.normalize(uen_US
Marc-Andre Lemburg m...@egenix.com added the comment:
Tom Christiansen wrote:
Tom Christiansen tchr...@perl.com 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 valid Unicode Transform
Marc-Andre Lemburg m...@egenix.com 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
___
Python tracker rep
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com 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 code, like
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
The change to sys.platform=='linux' would break code even on current
platforms.
Correct. Compared to introducing 'linux3', I consider this the better
Marc-Andre Lemburg m...@egenix.com added the comment:
mike bayer wrote:
mike bayer mike...@zzzcomputing.com 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
their end (I
Marc-Andre Lemburg m...@egenix.com added the comment:
Stefan Krah wrote:
Stefan Krah stefan-use...@bytereef.org added the comment:
Marc-Andre Lemburg rep...@bugs.python.org wrote:
Wouldn't it be better to have distutils tell the user about the
possible options, instead of guessing
Marc-Andre Lemburg m...@egenix.com added the comment:
Chris Rebert wrote:
Chris Rebert pyb...@rebertia.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
'\u1ff3'.upper() returns '\u1ffc', so we have:
U+1FF3 (ῳ - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
U+1FFC (ῼ - GREEK CAPITAL LETTER OMEGA
Marc-Andre Lemburg m...@egenix.com added the comment:
Roundup Robot wrote:
Roundup Robot devnull@devnull 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://hg.python.org
Marc-Andre Lemburg m...@egenix.com added the comment:
Michele Orrù wrote:
Michele Orrù maker...@gmail.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Éric Araujo wrote:
Éric Araujo mer...@netwok.org 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
Marc-Andre Lemburg m...@egenix.com added the comment:
R. David Murray wrote:
R. David Murray rdmur...@bitdance.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
R. David Murray wrote:
R. David Murray rdmur...@bitdance.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com 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's a much more
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Changes by Marc-Andre Lemburg m...@egenix.com:
--
title: Deprecate codecs.open(), codecs.StreamReader and codecs.StreamWriter -
Deprecate codecs.open()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8796
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
R. David Murray wrote:
R. David Murray rdmur...@bitdance.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com 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 - closed
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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:
('2', '6', '9
Changes by Marc-Andre Lemburg m...@egenix.com:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12158
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
TextIOWrapper() is conceptually something completely different. It's
more something like StreamReaderWriter().
That's a rather strange assertion. Can you expand
Marc-Andre Lemburg m...@egenix.com added the comment:
Michele Orrù wrote:
Michele Orrù maker...@gmail.com added the comment:
Well, actually encodings.aliases links to the encoding _module name_, as
described in the doc:
Encoding Aliases Support
This module is used by the encodings
Marc-Andre Lemburg m...@egenix.com added the comment:
Michele Orrù wrote:
Michele Orrù maker...@gmail.com added the comment:
Sorry, I was told that email the bugtracker could not work properly.
- mcbs has something broken in its imports;
mbcs is only available on Windows.
So
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com 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
Marc-Andre Lemburg m...@egenix.com 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 they do
Marc-Andre Lemburg m...@egenix.com added the comment:
Santoso Wijaya wrote:
Santoso Wijaya santoso.wij...@gmail.com added the comment:
`strftime` does not, indeed, seem to define what behaviour it is supposed to
do when given non-supported format characters. Under Windows, in fact
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
Python 3.2 has been published. Can we start deprecating StreamWriter and
StreamReader in Python 3.3 (to remove them from Python 3.4)? The doc should
Marc-Andre Lemburg m...@egenix.com added the comment:
Éric Araujo wrote:
Éric Araujo mer...@netwok.org added the comment:
Is it on purpose that there is a doc deprecation but no
[Pending]DeprecationWarning?
No, I guess just an oversight
Marc-Andre Lemburg m...@egenix.com added the comment:
Éric Araujo wrote:
Éric Araujo mer...@netwok.org added the comment:
haypo asked me on IRC if I’d like to make a patch for this; I will, in some
weeks.
With respect to the recent thread about deprecations and 2.7 → 3.latest
Marc-Andre Lemburg m...@egenix.com added the comment:
Thanks for the patch, Victor.
Some comments on the patch:
* the codec will have to be able to work with lone surrogates
(see the wikipedia page explaining this detail), which the
UTF-8 codec in Python 3.x no longer does, so another
Marc-Andre Lemburg m...@egenix.com added the comment:
Terry J. Reedy wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
Looking at cjkencodings.py the format is pretty clear. The file consists of
one statement that creates one dict that maps encoding names to a pair of
(encoded
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
Patch to optimize this: make it 10 times faster.
Try attached benchmark script. On a debug build I got the following results:
* original: 299.8
Marc-Andre Lemburg m...@egenix.com added the comment:
David Coles wrote:
David Coles coles.da...@gmail.com added the comment:
After doing some more investigation it appears that Android's wchar_t support
before android-9 is totally broken (see
http://android.git.kernel.org/?p=platform
Marc-Andre Lemburg m...@egenix.com added the comment:
From the document you posted:
As documented, the Android platform did not really support wchar_t until
Android 2.3. What this means in practical terms is that:
- If you target platform android-9 or higher, the size of wchar_t is
4
Marc-Andre Lemburg m...@egenix.com added the comment:
David Coles wrote:
I agree that it's not worthwhile trying to port Python to those Android
versions that have a single-byte wchar_t definition.
Yup. Will be using Android 2.3+. If I'm forced to use an earlier
version of Android I
901 - 1000 of 1900 matches
Mail list logo
