M.-A. Lemburg:
> Unicode has the concept of combining code points, e.g. you can
> store an "é" (e with a accent) as "e" + "'". Now if you slice
> off the accent, you'll break the character that you encoded
> using combining code points.
> ...
> next_(u, index) -> integer
>
> Returns th
Martin v. Löwis:
> This aspect of rendering is often not implemented, though. Web browsers
> do it correctly, see
> ...
> GUI frameworks sometimes do it correctly, sometimes don't; most
> notably, Tk has no good support for RTL text.
Scintilla does a rough job with this. RTL text is displayed
M.-A. Lemburg:
> You mean a slice that slices out the next ?
Yes.
> This sounds a lot like you'd want iterators for the various
> index types. Should be possible to implement on top of the
> proposed APIs, e.g. itergraphemes(u), itercodepoints(u), etc.
Iterators may be helpful, but can a
Josiah Carlson:
> According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
> various languages have adopted a transliteration of their language
> and/or former alphabets into latin. They don't purport to know all of
> the reasons why, and I'm not going to speculate.
I used to wor
Martin v. Löwis:
> The problem (for me, atleast) is that VC is so much more convenient to
> work with.
In my experience Visual C++ has always produced faster, more
compact code than Mingw. While this may not be true with current
releases, I'd want to ensure that the normal Python download for
Neal Norwitz:
> I think a bigger bang for the buck would be to buy a Windows box with
> Purify. Rational was a real pain to deal with, maybe it's better now
> that IBM bought them. Parasoft (Insure++) was even worse to deal
> with.
My experience with the other Windows option, BoundsChecker,
Won't ctypes completely replace dl? dl provides only a small subset
of the functionality of ctypes and is very restricted in the set of
argument types allowed.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Stephen J. Turnbull:
> Jason> Filesystem paths are in fact strings on all operating
> Jason> systems I'm aware of.
>
> I have no idea what you could mean by that. The data structure used
> to represent a filesystem on all OS filesystems I've used is a graph
> of directories and files. A
Martin v. Löwis:
> So ideally, Python should drop usage of the CRT entirely (but getting
> there will be a long process). Hopefully, P3k will drop usage of
> stdio for file objects, which will be a big step forward.
You don't need to drop the CRT, just encapsulate it so there is one
copy contro
Martin v. Löwis:
> I don't think this would be good enough. I then also need a way to
> provide extension authors with an API that looks like the CRT, but
> isn't: they cannot realistically change all their code to use the
> wrapped objects. In a recent case, somebody tried to passed a FILE*
> to
Greg Ewing:
> But that won't help when you need to deal with third-party
> code that knows nothing about Python or its wrapped file
> objects, and calls the CRT (or one of the myriad extant
> CRTs, chosen at random:-) directly.
Can you explain exactly why there is a problem here? Its fairly
no
Martin v. Löwis:
> COM really solves all problems people might have on Windows.
COM was partly just a continuation of the practices used for
controls, VBXs and other forms of extension. Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should Pytho
Martin v. Löwis:
> Not sure whether this was a serious suggestion.
Yes it is.
> If pythonxy.dll
> was statically linked, you would get all the CRT duplication
> already in extension modules. Given that there are APIs in Python
> where you have to do malloc/free across the python.dll
> boundar
Paul Moore:
> This has all been thrashed out before, but the issue is passing
> CRT-allocated objects across DLL boundaries.
Yes, that was the first point I addressed through wrapping CRT objects.
> At first glance, this is a minor issue - passing FILE* pointers across
> DLL boundaries isn't
Martin v. Löwis:
> > Visual Basic never forced
> > use of a particular compiler or runtime library for extensions so why
> > should Python?
>
> Do you really not know? Because of API that happens to be defined
> the way it is.
It was rhetorical: Why should Python be inferior to VB?
I suppo
101 - 115 of 115 matches
Mail list logo
