Stelios Xanthakis wrote:
Now that 2.4 is out and everything maybe it's
about time to start discussing the use the
__source__ Luke feature which IMO will really
boost python into a new domain of exciting
possibilities.
I'm opposed to this idea. It creates overhead in
the size of .pyc files, for no
Stelios Xanthakis wrote:
The key point is that I think think should be the
job of the parser and the functionality provided
at the interactive prompt w/o the user having to
write 'dyndef' or store the code of exec's or request
from himself to use specific commands to create
functions. It should be
Raymond Hettinger wrote:
* Deprecated modules just get moved to the lib-old directory. If
someone has ancient code relying on the module, it is a somewhat trivial
maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see
the harm.
I have never considered this as an official policy.
Brett C. wrote:
I realize that much. But if you look in configure.in it seems to use
the previous value of LDFLAGS every time it is redefined as a base and
thus gets its initial value from the environment variable the first time
it is tweaked.
Yes, it would be possible to do the same thing for
Neal Norwitz wrote:
Can we remove aclocal.m4? The last log message states:
fix for bug #811160 - autoconf vs. hp/ux system header files.
also applied to release23-maint.
Note that aclocal.m4 can go away when autoconf 2.58 is out.
It appears to me that 2.59 indeed fixes the
Bob Ippolito wrote:
I believe this is not implementable: How can the DLL know which Python
DLL to use?
Well for py2app on Mac OS X, I wrote an executable stub that chooses a
Python runtime from an XML file, looks up and binds a few symbols from
it dynamically, and then starts doing stuff.
While
Bob Ippolito wrote:
I was talking about PYTHON_API_VERSION, hence forced in quotes.
Nobody likes to see an ugly error message.
Ah, that... If PYTHON_API_VERSION changes, it is because there is
a real incompatibility, somewhere. It is not automatically bumped
with each release. So it is safe to
Thomas Heller wrote:
And recently I played with bindings to OpenGL's glut32.dll - glut calls
exit() from internal C code. If linked with the wrong CRT, this will do
nothing instead of terminating the process.
Interesting. Looking at the code of exit(), it is clear that the wrong
atexit handlers
Armin Rigo wrote:
In other words, if you want 3rd parties to compile Windows binaries for 2.4,
tell them how.
The straight-forward answer is: Get VC7.1 (aka VS.NET 2003), and invoke
python setup.py bdist_wininst
That's not too hard to do, I think.
Regards,
Martin
Carlos Ribeiro wrote:
If none of your users volunteers to do the build for you, I would stop
worrying about the Windows users.
Sorry, Martin. I understand your point, but I think you are not being
realistic. I for myself took the decision to use only free tools for
my own development, but I still
Paul Moore wrote:
For a starter, what steps do you actually take to build a release? I
assume that the first step is to build Python, by clicking on build
in VS.NET.
Yes. You can skip this step by just putting all the .pyds, dlls, and
.exes into the PCbuild directory. The packaging will try to
Paul Moore wrote:
OK, I've got a copy of the Python sources, and had a look. The change
needed to msi.py to include libpythonXX.a in the installer looks
simple. But I'm less sure as to where to build the file. It seems to
me that msi.py is not the right place - that's focused on building the
Josiah Carlson wrote:
Is mmap's inability to be subclassed a feature or bug?
No.
It's a missing feature: it's not a bug, because nobody says this should
work, and anybody trying will find out that it doesn't work, so nobody
is tricked into believing it should work. The mmap type is not even
Randy Chung wrote:
I'm going to be leading a class on Python at the University of
California, Berkeley next semester (starting in January). I'm
interested in using actual bugs in Python as exercises for the class,
the goal being 1) to give the students something real to work with,
and 2) to
M.-A. Lemburg wrote:
Here's an update of the list I currently have:
I have
* SDK Itanium compiler
Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2240.8 for IA-64
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
Regards,
Martin
M.-A. Lemburg wrote:
Thanks, Martin. Could you also give me the official version
number of the compiler or SDK ?
It is Windows Server 2003 Platform SDK, February 2003.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
Jeremy Hylton wrote:
I got started on these this morning, will likely finish them tomorrow.
It would be perverse to apply your patch last, wouldn't it?
It turns out that Titus' patch might be more involved than he thought
it would be.
In any case, the review itself is a highly appreciated
Barry Scott wrote:
It seems that I can build extensions with msvc 6.0 that work with the
python 2.4 windows
binary kit.
Is this safe?
No, it isn't. This emerges as a Python 2.4 FAQ.
I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime
DLL's. Is this
an issue with python 2.4?
Barry Scott wrote:
I recursive grep'ed and missed this ref. However I did read this in
README.TXT:
Building on non-UNIX systems
For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 6.0, the
project files are in PCbuild, the workspace is pcbuild.dsw. See
Scott David Daniels wrote:
I believe
there is an issue actually building in the encryption/decryption in
terms of redistribution.
Submitters should not worry about this too much. The issue primarily
exists in the U.S., and there are now (U.S.) official procedures to
deal with them, and the PSF can
Andrew McNamara wrote:
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
Can you please elaborate on that? What needs to be done, and how is
that going to
Andrew McNamara wrote:
Marc-Andre Lemburg mentioned that he has encountered UTF-16 encoded csv
files, so a reasonable starting point would be the ability to read and
parse, as well as the ability to generate, one of these.
I see. That would be reasonable, indeed. Notice that this is not so much
a
Ronald Oussoren wrote:
Wouldn't it be better to link with the actual dylib inside the framework
on 10.2? Otherwise you can no longer build 2.3 extensions after you've
installed 2.4.
That's what I thought, too.
Regards,
Martin
___
Python-Dev mailing
When support for floating-point stat times was added in 2.3,
it was the plan that this should eventually become the default.
Does anybody object if I change the default now, for Python 2.5?
Applications which then break can globally change it back, with
os.stat_float_times(False)
Regards,
Martin
Alex Martelli wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
Couldn't we just specialcase strings specifically, to keep
Guido van Rossum wrote:
a) Is Exception to be new-style?
Probably not in 2.5; Martin and others have suggested that this could
introduce instability for users' existing exception classes.
Really? I thought that was eventually decided to be a very small amount of code.
I still think that only an
Donovan Baarda wrote:
Seriously, on the Python lists there has been a discussion rejecting an
md5sum implementation because the author donated it to the public domain.
Apparently lawyers have decided that you can't give code away. Intellectual
charity is illegal :-)
Despite the smiley: It is not
Reinhold Birkenfeld wrote:
No one listening? I'm sorry when patch reviews are not welcome in
python-devel; in this case I'll post individual comments to the patches
on SF.
I have seen them, and I appreciate them, but I had no time to respond,
yet (likewise for the 20+ other reviews which I still
Irmen de Jong wrote:
I've looked at one bug and a bunch of patches and
added a comment to them:
Thanks! I have now processed the ones for which I found guidance.
As for the remaining ones:
[ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
Looks good but added suggestion about when to
Raymond Hettinger wrote:
Are you sure about that? Contriving examples is easy, but download a
few modules, scan them for use cases, and you may find, as I did, that
partial() rarely applies. The argument order tends to be problematic.
So would you like to see the decision to accept PEP 309
Raymond Hettinger wrote:
I would like for the principal advocates to reach a consensus that the
proposed implementation is a winner.
That I cannot understand. Do you want the advocates to verify that the
implementation conforms to the specification? or that the implementation
of the PEP is faster
I find that I frequently need to open a bug report
whose bug number is in a python-dev email I read
with Mozilla Thunderbird.
I now tried to automate things a bit more, and found
the excellent DictionarySearch plugin:
http://dictionarysearch.mozdev.org/index.html
To install, follow these steps:
1.
Paul Moore wrote:
While I'm not saying that it's too late to attempt to persuade Guido
to reverse himself, it does seem to me to be a lot of fuss over a
fairly small function - and no-one said anything like this at the
time.
I would probably fuss much less if it would not simultaneously introduce
Raymond Hettinger wrote:
My reading of the PEP did not include making the structure members
public. This complicates and slows the implementation. The notion of
introducing mutable state to the PFA is at odds with the driving forces
behind functional programming (i.e. statelessness).
Notice that
Alan McIntyre wrote:
Thanks, somehow I managed to be oblivious to patches bugs being
essentially the same thing on SF. :-)
The SF URLs are different (or atleast, they used to be (*), as they
also include the tracker ID and the project ID, and SF complains
if you guess either wrong.
Therefore, I
Warnes, Gregory R wrote:
What else needs to be done to allow fpconst to go into the Python library?
See PEP 1. First, the PEP must be Accepted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Steve Holden wrote:
Now, the reason for this specific rant is this: I can tell a cry for
help when I see one. Brett has done a magnificent job of providing
python-dev summaries since Andrew decided he'd had enough, and he is to
be congratulated for it. I managed to offload another bunch of work
Reinhold Birkenfeld wrote:
just felt a little bored and tried to review a few (no-brainer) patches.
Thanks! They are now all closed.
Please understand that there is a chance that a review posted *only*
to python-dev might get lost/overlooked by the committers, and then
somebody may need to
I just mistakenly checked in import.c; I have outdated
this checkin (cvs admin -o 2.241 import.c). If you happened
to have checked-out import.c in-between, don't be surprised
if the version numbers go backwards.
Regards,
Martin
___
Python-Dev mailing
Brett C. wrote:
Assuming a code review says the patch is sane, do we want to go with
this garbage collection change? From past discussions I don't remember
a consensus on acceptance or rejection, just lots of discussion about
ripping out the hacks to allow freeing memory w/o holding the GIL (I
I don't know whether anybody has done this before,
but I just tried to run cvs2svn on the Python repository.
The conversion took 7 hours, and the result is now
available at
http://www.dcl.hpi.uni-potsdam.de/python/branches/
Because of the load that the conversion produces on
the machine, I cannot
Barry Warsaw wrote:
I personally have had no success doing this, but the last time I tried
was with a fairly old version of svn.
It gives an error message when you try. You then need to interpret the
error message, retry, and it gives you another error message. You do
this three times, and end up
Greg Ward wrote:
Presumably for Python's repository, this would work:
cvs2svn -s /home/svn/python /home/cvs/python/python
...except, umm, isn't distutils a separate top-level directory in the
Python repository or something?
Ok. Removing the CVSROOT before the conversion (from CVS) or after
the
Apparently, os.access was forgotten when the file system encoding
was introduced in Python 2.2, and then it was again forgotten in
PEP 277.
I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder
whether this is a backport candidate. People who try to invoke
os.access with a non-ASCII
Brett C. wrote:
If there was no other way to get os.access-like functionality, I would
say it should be backported. But since there are other ways to figure
out everything that os.access can tell you
I believe this is not really true, atleast not on Windows, and perhaps
not in certain NFS
Delaney, Timothy C (Timothy) wrote:
Does anyone else think it would be worthwhile adding these to
collections, or should I just make a cookbook entry?
-0 for the addition to the collections module, -1 on the specific
name.
Java made a *big* mistake by putting Hash into the names of these
things.
Thomas Heller wrote:
I cannot understand why people are against adding it to stdlib (after
the name, the implementation, and the exact place have been decided).
It's certainly a useful data type, isn't it?
It depends on the precise semantics. You often want a dictionary where
the keys come out in
John Williams wrote:
The other use case I have is for dealing with data where the iteration
order doesn't matter to the program but it does matter to users. For
instance, consider the ConfigParser's write method. Any ordering of
values in the output is functionally equivalent, but the
Anthony Baxter wrote:
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.4.1 (release candidate 1).
Python 2.4.1 is a bug-fix release. See the release notes at the website
(also available as Misc/NEWS in the source distribution) for
Skip Montanaro wrote:
I say backport. If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding unicode
filenames as a result or working around it some other way. I can't see how
making os.access work with unicode filenames is going
Michael Chermside wrote:
I tried several stranger things, like installing over 2.4.0 but in a
different directory. Everything worked like clockwork. I did NOT try
anything that would have involved a system with various things missing
(like lack of VBScript), but I did play around with alternate
Alexander Schremmer wrote:
Somebody reported that it failed to update python24.dll in
an update installation; not sure why this would be.
Because it was in use?
Perhaps. In that case, Installer should schedule a reboot, and
ask for the reboot when the installation is otherwise complete.
Regards,
Tim Peters wrote:
Don't think it's needed on HEAD. As the checkin comment said:
This doesn't appear to be an issue on the HEAD (MSVCCompiler initializes
itself via __init__() on the HEAD).
I verified by building Zope with unaltered HEAD too, and had no
problem with that.
Are you sure your
Leeuw van der, Tim wrote:
The generated files crash the Python interpreter with Python 2.4
Under Python 2.4.1c1, They give a syntax error!?
Even though the bug was fixed in pywin, it is interesting to observe
that Mark's analysis says
Cause of the underling crash is that the generated .py
causes
Jeremy Hylton wrote:
I seem to have a problem with the install on XP SP1. Python itself is
installed, but IDLE won't start. The error says: IDLE's subprocess
didn't make connection. Either IDLE can't start a subprocess or
personal firewall software is blocking the connection. I believe the
Kurt B. Kaiser wrote:
I had some strange experiences.
Weird indeed.
I downloaded the 2.4.1c1 installer to the desktop and clicked on it.
It complained that it couldn't access the installer.
Do you happen to remember the precise error message?
I then clicked on the 2.4.1b2 installer and that
Anthony Baxter wrote:
Ok, I'm convinced - Martin, can you check this in?
Done!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Kurt B. Kaiser wrote:
Do you happen to remember the precise error message?
This installation package could not be opened.
Ah, that you get if the file is already open. Do you run some shell
extension that might want to look into the MSI file, or virus scanners?
I also recall a KB article that the
Eric Nieuwland wrote:
[ test for exprlist in testlist list-iter-opt ]
Aren't these names a bit mixed up w.r.t. what's in that position?
It comes more-or-less straight out of Grammar/Grammar, so: no,
I don't think so.
As far as I know
test is not a test but a function as it produces any value
Jack Jansen wrote:
The comment in pyconfig.h suggests that defining _POSIX_C_SOURCE may
enable certain features, but the actual system headers appear to work
the other way around: it seems that defining this will disable features
that are not strict Posix.
Does anyone know what the real
Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere?
Literally, the answer to your question is no.
I'm surprised that it does not, for example, guarantee that reads and
writes are atomic, since CPython relies on fread and fwrite which are
atomic.
Where is the
Rodrigo Dias Arruda Senra wrote:
I propose a small change in webbrowse.py module.
I think I'm generally in favour of such a change. However:
- please don't post patches to python-dev, unless you *want*
them to be ignored. Typically, nobody will pick up patches
from python-dev and apply them,
Walter Dörwald wrote:
I'm not sure if this is the right approach.
I think the approach is right, but the implementation is wrong.
The encoding I specify in
setup.py should be independent of the encoding used between distutils
and PyPI to communicate on the wire. I.e. the author (and maintainer)
Andrew MacIntyre wrote:
This change has broken the build on FreeBSD 4.x for me:
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -
I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c
In file included from Python/thread.c:101:
Travis Oliphant wrote:
What is the opinion of people on this list about how to fix the
problem. I believe Martin was looking at the problem and had told
Perry Greenfield he was fixing it. Apparently at the recent PyCon,
Perry and he talked and Martin said the problem is harder than he had
Walter Dörwald wrote:
So is this change wanted? useful? implementable with reasonable effort? Or
just not worth it?
I think it is just not worth it. This means I won't attempt to implement
it. I think I defined originally the __module__ attribute for classes to
support better pickling (and defined
Walter Dörwald wrote:
The register command in 2.4 (and current CVS) simply does a
value = str(value)
in post_to_server() so the encoded bytes sent depend on the
default encoding. Would it be sufficient to change this to
value = unicode(value).encode(utf-8)
Indeed. I think this can go into
Walter Dörwald wrote:
There's been a problem with your request
exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
position 92: ordinal not in range(128)
That should be fixed now, please try again.
Please report further errors you find to sf.net/projects/pypi.
Suggestions/RFEs
Skip Montanaro wrote:
Here's a traceback:
Traceback (most recent call last):
File /usr/local/apache/cgi-bin/sf, line 82, in ?
log_type(report, tracker)
File /usr/local/apache/cgi-bin/sf, line 42, in log_type
os.unlink(idsfile+.lck)
OSError: [Errno 2] No such
Guido van Rossum wrote:
I forwarded this to MvL, who wrote the code; he'll look into it but
probably not before Sunday.
Actually, now that I saw that it is a permission problem, it turned
out to be fixable quite easily.
Regards,
Martin
___
Python-Dev
Josiah Carlson wrote:
re2 can be used as a limited structural parser. This makes the re
module useful for more things than it is currently. The question of it
being in the standard library, however, I think should be made based on
the criteria used previously (whatever they were).
In general, if
Michael Hudson wrote:
Asking mostly for curiousity, how hard would it be to have longs store
their sign bit somewhere less aggravating? It seems to me that the
top bit of ob_digit[0] is always 0, for example, and I'm sure this
would result no less convolution in longobject.c it'd be considerably
Stephen J. Turnbull wrote:
So there is a standard for the UTF-8 signature, and I know of
applications which produce it. While I agree with you that Python's
codecs shouldn't produce it (by default), providing an option to strip
is a good idea.
I would personally like to see an utf-8-bom codec
Walter Dörwald wrote:
The stateful decoder has a little problem: At least three bytes
have to be available from the stream until the StreamReader
decides whether these bytes are a BOM that has to be skipped.
This means that if the file only contains ab, the user will
never see these two
Walter Dörwald wrote:
There are situations where the byte stream might be temporarily
exhausted, e.g. an XML parser that tries to support the
IncrementalParser interface, or when you want to decode
encoded data piecewise, because you want to give a progress
report.
Yes, but these are not file-like
Stephen J. Turnbull wrote:
Of course it must be supported. My point is that many strings (in my
applications, all but those strings that result from slurping in a
file or process output in one go -- example, not a statistically valid
sample!) are not the beginning of what once was a stream. It
Nicholas Bastin wrote:
It would be nice if you could optionally specify that the codec would
assume UTF-16BE if no BOM was present, and not raise UnicodeError in
that case, which would preserve the current behaviour as well as allow
users' to ask for behaviour which conforms to the standard.
Skip Montanaro wrote:
Martin Yet, this *still* is a platform dependence. Python makes no
Martin guarantee that 1e1000 is a supported float literal on any
Martin platform, and indeed, on your platform, 1e1000 is not supported
Martin on your platform.
Are float(inf) and
Fredrik Lundh wrote:
I was under the impression that the marshal format has been stable for
quite a long time (people are using it for various RPC protocols, among
other things). I might be wrong.
Python 2.4 introduced support for string sharing in marshal files, with
an option to suppress
Nick Coghlan wrote:
Are context diffs still favoured for patches?
Just for the record: I also prefer unified over context diffs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Senthil Prabu.S wrote:
I tried python -4.2.1 on a HP-UX 11.11 PA machine. I was able to
python. Gmake passes, gmake test results in error. The python reported
that test_pty fails,when running this test alone.
Can anyone help to find why core dumps at running the
*test_subprocess.py*
Irmen de Jong wrote:
Please advise?
setup.py should refer to config_h_vars, which in turn should be set earlier.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Brett C. wrote:
Hmm. OK, that is an interesting idea. Would make rebuilding a lot easier if
it was just an environment variable that was part of the default OPT value;
``OPT=$BUILDFLAGS -g -Wall -Wstrict-prototyping.
I say we go with that. What is a good name, though? PY_OPT?
I think
Brett C. wrote:
Works for me. If no one objects I will check in the change for CFLAGS to make
it ``$(BASECFLAGS) $(OPT) $EXTRA_CFLAGS`` soon (is quoting it enough to make
sure that it isn't evaluated by configure but left as a string to be evaluated
by the shell when the Makefile is
Brett C. wrote:
Yep, you're right. I initially thought that the parentheses meant it was a
Makefile-only variable, but it actually goes to the environment for those
unknown values.
Before I check it in, though, should setup.py be tweaked to use it as well? I
say yes.
You means
Brett C. wrote:
You means sysconfig.py, right?
Right.
No, I mean Python's setup.py; line 174.
Ah, ok.
You mean Distutils' sysconfig, right? I can change that as well if you want.
Please do; otherwise, people might see strange effects.
Regards,
Martin
Brett C. wrote:
OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and
distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way
you wanted.
It is the way I wanted it, but it doesn't work. Just try and use it for
some extension modules to see for yourself, I
Ugo Di Girolamo wrote:
What am I doing wrong?
This is not the forum to ask this question, please use
python-list@python.org instead.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Nicholas Bastin wrote:
That makes PyUnicode_FromUnicode() a lot less useful. Well, really,
not useful at all.
Why do you say that? Py_UNICODE is as good a type to store characters
as any other, and if you happen to have a Py_UNICODE[], you can use
that function to build a unicode object.
Nicholas Bastin wrote:
This type represents the storage type which is used by Python
internally as the basis for holding Unicode ordinals. Extension module
developers should make no assumptions about the size of this type on
any given platform.
But people want to know Is Python's Unicode
Edward C. Jones wrote:
The documentation should discuss portability.
This is the critical issue here. Discussing portability is not
enough; these features really ought to be either available on
a majority of the installations, or not available at all.
In particular, they would need to be
I haven't followed the PEP 340 discussion in detail,
but as the PEP doesn't list keywords that have been
considered and rejected, I'd like to propose my own:
use after instead of block:
after opening(/etc/passwd) as f:
for line in f:
print line.rstrip()
after locking(myLock):
# code
Nicholas Bastin wrote:
The important piece of information is that it is not guaranteed to be a
particular one of those sizes. Once you can't guarantee the size, no
one really cares what size it is.
Please trust many years of experience: This is just not true. People
do care, and they want to
Nicholas Bastin wrote:
If this is the case, then we're clearly misleading users. If the
configure script says UCS-2, then as a user I would assume that
surrogate pairs would *not* be encoded, because I chose UCS-2, and it
doesn't support that.
What do you mean by that? That the interpreter
Nicholas Bastin wrote:
Because the encoding of that buffer appears to be different depending on
the configure options.
What makes it appear so? sizeof(Py_UNICODE) changes when you change
the option - does that, in your mind, mean that the encoding changes?
If that isn't true, then someone
Nicholas Bastin wrote:
No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
default is depends on your platform.
The truth is more complicated. If your Tcl is built for UCS-4, then
Python will also be built for UCS-4 (unless overridden by command line).
Otherwise, Python will
M.-A. Lemburg wrote:
Hmm, looking at the configure.in script, it seems you're right.
I wonder why this weird dependency on TCL was added.
If Python is configured for UCS-2, and Tcl for UCS-4, then
Tkinter would not work out of the box. Hence the weird dependency.
Regards,
Martin
Shane Hathaway wrote:
Ok. Thanks for helping me understand where Python is WRT unicode. I
can work around the issues (or maybe try to help solve them) now that I
know the current state of affairs. If Python correctly handled UTF-16
strings internally, we wouldn't need the UCS-4
Nicholas Bastin wrote:
What I mean is pretty clear. UCS-2 does *NOT* support surrogate pairs.
If it did, it would be called UTF-16. If Python really supported
UCS-2, then surrogate pairs from UTF-16 inputs would either get turned
into two garbage characters, or the I couldn't transcode
Shane Hathaway wrote:
Py_UNICODE would always be 32 bits wide.
This would break PythonWin, which relies on Py_UNICODE being
the same as WCHAR_T. PythonWin is not broken, it just hasn't
been ported to UCS-4, yet (and porting this is difficult and
will cause a performance loss).
Regards,
Martin
1 - 100 of 4853 matches
Mail list logo
