Terry Reedy:
> Broken (and quirky): it has an absurdly limited output buffer (under a
> thousand lines)
The limit is actually lines.
> Quirky: Windows uses cntl-C to copy selected text to the clipboard and (where
> appropriate) cntl-V to insert clipboard text at the cursor pretty much
Armin Rigo:
> Maybe. Feel like adding an issue to
> https://bitbucket.org/cffi/cffi/issues, with references?
OK, issue #62 added.
> This looks
> like a Windows-specific extension, which means that I don't
> automatically know about it.
While SAL is Windows-specific, gcc supports some si
Armin Rigo:
> So the general answer to your question is: we google MessageBox and
> copy that line from the microsoft site, and manually remove the
> unnecessary WINAPI and _In_opt declarations:
Wouldn't it be better to understand the SAL annotations like _In_opt so that
spurious NULLs (for e
Nick Coghlan:
> - no need for extensive cross-OS testing prior to commit, that's a key
> part of the role of the buildbots
Are the buildbots able to test UI features like menu selections?
Neil
___
Python-Dev mailing list
Python-Dev@python.org
ht
Curt:
>> But will it be able to target Windows XP?
It will likely be possible in a reasonable manner at some point. From
http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx
:
"""C++ developers can also use the
Antoine Pitrou:
> How does it translate to C?
The simplest technique would be to use C++ code to bridge from C to
the API. If you really wanted to you could explicitly call the
function pointer in the COM vtable but doing COM in C is more effort
than calling through C++.
> I'm not sure why "r
Antoine Pitrou:
> When you say MoveFile is absent, is MoveFileEx supported instead?
WinRT strongly prefers asynchronous methods for all lengthy
operations. The most likely call to use for moving files is
StorageFile.MoveAsync.
http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
Austin Fernandes:
> Which versions of python will be compatible with windows8. I am using
> currently 2.7.2 version.
Current releases of both Python 2.7 and Python 3.2 appear to run
fine on the Windows 8 Developer Preview. You should download and
install the preview to ensure that your own cod
Stephen J. Turnbull:
> ... Eg, this is why the common GUIs for Unix (X.org, GTK+, and
> Qt) either provide or require UTF-8 coding for their text.
Qt uses UTF-16 for its basic QString type. While QString is mostly
treated as a black box which you can create from input buffers in any
encoding,
Glenn Linderman:
> How many different iterators into the same text would be concurrently needed
> by an application? And why? Seems like if it is dealing with text at the
> level of grapheme clusters, it needs that type of iterator. Of course, if
> it does I/O it needs codec access, but that is
Guido van Rossum:
> On Wed, Aug 31, 2011 at 5:58 PM, Neil Hodgson wrote:
>> [...] some text drawing engines draw decomposed characters ("o"
>> followed by " ̈" -> "ö") differently compared to their composite
>> equivalents ("ö") an
Glenn Linderman:
> That said, regexp, or some sort of cursor on a string, might be a workable
> solution. Will it have adequate performance? Perhaps, at least for some
> applications. Will it be as conceptually simple as indexing an array of
> graphemes? No. Will it ever reach the efficiency
Antoine Pitrou:
> So what you're saying is that the text is mostly useless (or at least
> quite dispensable), but you think it's fine that people waste their
> time trying to read it?
I found it useful when starting to write socket code. Later on I
learnt more but, as an introduction, this doc
Michael Urman:
> That screenshot seems to show UTF-8 is being used. This may just be
> the literal bytes in the .c file, but could it be something more
> dependable?
The file is in UTF-8 so the compiler may just be copying the bytes.
There is a setlocale pragma but that seems to be just for st
Michael Urman:
> I'm not convinced this is correct for this case. GetProcAddress takes
> an "ANSI" string, meaning while it could theoretically use UTF-8, in
> practice I doubt it uses anything outside of ASCII safely. So while
> the name of the library would be encoded in UTF-16, the name of the
Victor Stinner:
> I read these documents but they don't explain which encoding is used in
> libraries and programs. Does it mean that Windows and Linux may use
> different encodings?
Yes, Windows will use UTF-16 as it does for almost everything. From
a user's point of view, these should both j
Victor Stinner:
> C and C++ identifiers are restricted to ASCII. I don't know for Fortran
> or Java.
Some C and C++ implementations currently allow non-ASCII
identifiers and the forthcoming C1X and C++0x language standards
include non-ASCII identifiers. The allowed characters are specified in
Martin v. Löwis:
> I guess all this advice doesn't really apply to this case, though.
> The Microsoft API declares the parameter as a volatile*, indicating
> that they consider it "proper" usage of the API to declare the storage
> volatile.
The 'volatile' here is a modifier on the parameter an
Martin v. Löwis:
> So how can I fix this properly: so that all files have CRLF, but
> are still attributed to whoever last modified them, rather than
> having them attributed to me?
I don't think this is possible from the current state. It may be
possible to change the conversion process to 'r
To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.
Another possibility is to set Visual Studio project files to CRLF
but this is les
Antoine Pitrou:
> It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
checked out by svn with Windows \r\n line ends.
Neil
___
Georg Brandl:
> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
OK, I just performed a clone OK. It seems wrong to me that the
*.vcproj and *.vsprops files
Adrian Buehlmann:
> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st),
> which ported the current Gtk based TortoiseHg to Qt (although, it was
> more like a rewrite :-).
I hope this is going to be fast. One of the reasons I chose Hg over
Bzr for another project was that the B
Scott Dial:
> I don't believe TortoiseHG has such a feature (or I can't find it),
> although if you have TortoiseSVN, you can still use that as a patch tool.
The Import... command is in the Synchronize menu of Hg Repository Explorer.
There is no GUI equivalent to --no-commit but you can ex
Line end problems do occur in real projects. A scintilla-cocoa
project was branched off Scintilla to support the Cocoa GUI framework
on OS X. Here is one of the revisions in that project:
http://bazaar.launchpad.net/~mike-lischke/scintilla-cocoa/trunk/revision/5#include/ScintillaWidget.h
If
Antoine Pitrou:
> It should now be fixed in current SVN, meaning the final conversion
> should be perfectly usable with the eol extension enabled.
Good.
> Do you find other issues under Windows? Have you tried pushing changes?
Since I'm not a member of core developers I used a http pull a
With hg 1.7.5 on Windows 7 I performed a non-core checkout:
hg clone http://hg.python.org/cpython
The eol extension is enabled in global settings. I looked at things
a bit, opening some files and using the Tortoise Hg Repository
Explorer. But made no actual changes. Running hg diff produces
Toshio Kuratomi:
> When they update their OS to a version that has
> utf-8 python module names, they will find that they have to make a choice.
> They can either change their locale settings to a utf-8 encoding and have
> the system installed modules work or they can leave their encoding on their
Toshio Kuratomi:
> My examples that you're replying to involve two "properly
> configured" OS's. The Linux workstations are configured with a UTF-8
> locale. The Windows OS's use wide character unicode. The problem occurs in
> that the code that one of the parties develops (either the students
Stephen J. Turnbull:
> Will it accept Arabic on input? (Han might be too much to ask for
> since Unicode considers Han digits to be "impure".)
I couldn't find a direct way to input Arabic digits into OO Calc,
the normal use of Alt+number didn't work in Calc although it did in
WordPad where Al
Stephen J. Turnbull:
> Here's why: '''print "%d" %
> some_integer''' doesn't now, and never will (unless Kristan gets his
> Python 2.8), produce Arabic or Han numerals. Not in any
> language I know of, not in Microsoft Excel, and definitely not in
> Python 2.
While I don't have Excel to test
Ian Bicking:
> I think the use case everyone has in mind here is where
> you get a URL from one of these sources, and you want to handle it. I have
> a hard time imagining the sequence of events that would lead to mojibake.
> Naive parsing of a document in bytes couldn't do it, because if you hav
M.-A. Lemburg:
> Is it possible to have multiple versions of the lib C loaded
> on Windows ?
Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.
Historically, each vendor has shipped their own C runtime
libraries. This was also
Terry Reedy:
> File "C:\Python26\lib\socket.py", line 406, in readline
> data = self._sock.recv(self._rbufsize)
> socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs
> kÚnyszerÝtette n bezßrta
That is pretty good mojibake. One of the problems of providing
localized error mess
Terry Reedy:
> I suspect that the persons who first ported Python to MSDOS simply used what
> they were used to using, perhaps in their paid job. And I am sure that is
> still true of at least some of the people doing Windows support today.
Some Windows developers actually prefer Visual Studio
Stephen J. Turnbull:
> But it's very important to be able to *move* tabs across windows or
> panes. ...
> In many apps, however, you would have to select the foo.c tab, close
> it, bring up a new window, and open foo.c using the long path
> (presumably with a file browser interface, but often eno
Kurt B. Kaiser:
>> The tear off menus are ugly as well as being non-standard on all three
>> major platforms.
>
> Well, would you discard them? They can (occasionally) be useful.
Yes, I would replace the menus with ones missing the tear line.
Most of the GUI toolkits experimented with tear-off
Kurt B. Kaiser:
> I'm mystified about the comments that the GUI is ugly. It is minimal.
> On XP, it looks exactly like an XP window with a simple menubar. Those
> who haven't looked at it for awhile may not be aware of the recent
> advances made by Tk in native look and feel. What is ugly?
anatoly techtonik:
> The file consists of several licenses for multiple versions of Python.
> It is an unusual mix that negatively affects understanding.
A simpler license would be better.
There have been moves in the past to simplify the license of Python
but this would require agreement
Steven D'Aprano:
> Do any other languages have any equivalent to this ebtyes type?
The String type in Ruby 1.9 is a byte string with an encoding attribute.
Most online Ruby documentation is for 1.8 but the API can be examined here:
http://ruby-doc.org/ruby-1.9/index.html
Here's somethin
Michael Foord:
> Python 3.0 was *declared* to be an experimental release, and by most
> standards 3.1 (in terms of the core language and functionality) was a solid
> release.
That looks to me like an after-the-event rationalization. The
release note for Python 3.0 (and the "What's new") gives
Victor Stinner:
> It's a choice, I didn't want to patch Windows because I know that Windows use
> unicode internally. I consider that developers using Python3 should use
> unicode on Windows, and byte or unicode+surrogates on other OS.
The Win32 byte string APIs convert their inputs to Unicode
Antoine Pitrou:
> Is this concern still valid? We are in the 2010s now.
> I'm not saying I want us to put some C++ in the core interpreter, but
> the portability argument sounds a little old...
There are still viable platforms which only support subsets of C++.
IIRC, Android does not support e
Martin v. Löwis:
> See http://bugs.python.org/issue6926
>
> The SDK currently hides symbolic constants from us that people are
> asking for.
Setting the version to 0x501 (XP) doesn't actively try to stop
running on version 0x500 (2K), it just reveals the symbols and APIs
from 0x501. Including
Martin v. Löwis:
> I don't recall whether we have already decided about continued support
> for Windows 2000.
>
> If not, I'd like to propose that we phase out that support: the Windows
> 2.7 installer should display a warning; 3.2 will stop supporting Windows
> 2000.
Is there any reason for t
Larry Hastings:
> But IIUC telling the compiler how to
> do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to
> support any environment variable containing an include /path/.
The INCLUDE environment variable is a list of ';' separated paths
http://msdn.microsoft.com/en-us/l
Eric Hopper:
> I don't suppose it will ever be ported back to Python 2.x? It doesn't
> look like the whole GIL concept has changed much between Python 2.x and
> 3.x so I expect back-porting it would be pretty easy.
There was a patch but it has been rejected.
http://bugs.python.org/issue7753
Tim Delaney:
> I like this solution combined with having a single cache directory and a few
> other things I've added below.
> ...
> 2. /tmp is often on non-volatile memory. If it is (e.g. my Windows system
> temp dir is on a RAMdisk) then it seems wise to respect the obvious desire
> to throw awa
When SourceForge started having comments and ratings, I was a
little upset at having poor negative comments there (like "not
work!"). But after it has been running for a while it appears useful.
I suppose it helps that Scintilla has 88% thumbs up from 134
respondents. Because there is voting on
Ronald Oussoren:
> Both Carbon and the modern APIs use UTF-16.
If Unicode size standardization is seen as sufficiently beneficial
then UTF-16 would be more widely applicable than UTF-32. Unix mostly
uses 8-bit APIs which are either explicitly UTF-8 (such as GTK+) or
can accept UTF-8 when the l
Paul Moore:
> 1. Given that the "problematic" tools (notepad and Visual Studio) are
> Windows tools, we seem to be back to the idea that this extension is
> only needed by Windows developers. As I understood the consensus to be
> that the extension should be for all users, I suspect I've missed
>
Dirkjan Ochtman:
> I know a lot of projects use Mercurial on Windows as well, I'm not
> aware of any big problems with it.
If you have a Windows-only project with CRLF files using Mercurial
then there is no line end problem as Mercurial preserves the CRLFs for
you. Line end problems occur on m
M.-A. Lemburg:
> ... and because of this, the feature is already available if
> you use codecs.open() instead of the built-in open():
So should I not add an issue for the basic open because codecs.open
should be used for this case?
Neil
___
Pytho
Glenn Linderman:
> and perhaps other things (and
> are there new Unicode control characters that could be used for line
> endings?),
Unicode includes Line Separator U+2028 and Paragraph Separator
U+2029 but they are rarely supported and very rarely used. They are a
pain to work with since they
Martin v. Löwis:
> Or don't you understand why that single unresolved item didn't manage
> to revert the decision? Well, there are many unresolved items in
> the Mercurial conversion, some much more stressful than the eol issue
> (e.g. the branching discussion).
Then these issues should have b
Martin v. Löwis:
> Is it really that you don't *understand*? It's fairly easy: there was
> a PEP ...
The PEP process is straightforward. However, a PEP may produce an
outcome that proves after more experience to be wrong. ISTM a
prerequisite to choosing a DVCS is that it should support the ful
Mark Hammond:
> Thanks Nick; I didn't want to be the only one saying that. There is a fine
> line between asserting reasonable requirements for Windows users and being
> obstructionist and unhelpful, and I'm trying to stay on the former side :)
I haven't commented on this issue before because
Martin v. Löwis:
> Yes: alignof(PyGC_HEAD) would be specified as being the maximum
> alignment on a platform; sizeof(PyGC_HEAD) would be frozen.
Maximum alignment currently on x86 is 16 bytes for SSE vector
types. Next year AVX will add 32 byte types and while they are
supposed to work OK with
Martin v. Löwis:
> I propose to add another (regular) double into the union.
Adding a regular double as a second dummy gives the same sizes and
alignments with Mingw or MSVC as the original definition with MSVC:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
Glyph Lefkowitz:
> Sounds like this is moving into hypothetical territory better-suited to
> python-ideas. (Although I'm sure that if you wanted to contribute polished,
> tested code for a standard remote debugger interface, few people would
> complain.)
There is a remote debugger protocol ca
Curt Hagenlocher:
> Ah, you're right -- the PGO bits probably need VS Pro. The 64-bit
> compilers should be in the Windows SDK, but it wouldn't surprise me if
> they were not included in Express.
64-bit isn't in Express and merging the 64 bit compiler from the
SDK into Express may be possible
cmake does not produce relative paths in its generated make and
project files. There is an option CMAKE_USE_RELATIVE_PATHS which
appears to do this but the documentation says:
"""This option does not work for more complicated projects, and
relative paths are used when possible. In general, it i
Jeffrey Yasskin:
> 1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately
I have looked at a couple of build tools (scons was probably one)
that generate Visual Studio project files in the past and they
produced fairly poor project files,
Antoine Pitrou:
> It depends on what you call "ACLs". It does copy the chmod permission bits.
Access Control Lists are fine grained permissions. Perhaps you
want to allow Sam to read a file and for Ted to both read and write
it. These permissions should not need to be reset every time you
mod
Antoine Pitrou:
> How about shutil.copystat()?
shutil.copystat does not copy over the owner, group or ACLs.
Modeling a copymetadata method on copystat would provide an easy to
understand API and should be implementable on Windows and POSIX.
Reading the OS X documentation shows a set of low
The technique advocated by Theodore Ts'o (save to temporary then
rename) discards metadata. What would be useful is a simple, generic
way in Python to copy all the appropriate metadata (ownership, ACLs,
...) to another file so the temporary-and-rename technique could be
used.
On Windows, the
zooko:
> Um, isn't this tool called "unzip"? I have done this -- accessed the
> source code -- many times, and unzip suffices.
The type of issue I ran into with eggs is when you get an exception
with a trace that includes an egg, you can't use the normal means to
look at the code. Instead y
Travis Oliphant:
> PEP: 3118
> ...
I'd like to see the PEP include discussion of what to do when an
incompatible request is received while locked. Should there be a
standard "Can't do that: my buffer has been got" exception?
Neil
___
Python-Dev m
I have developed a split vector type that implements the buffer protocol at
http://scintilla.sourceforge.net/splitvector-1.0.zip
It acts as a mutable string implementing most of the sequence
protocol as well as the buffer protocol. splitvector.SplitVector('c')
creates a vector containing 8 b
Greg Ewing:
> So an array-of-pointers interface wouldn't be a direct
> substitute for the existing multi-segment buffer
> interface.
Providing an array of (pointer,length) wouldn't be too much extra
work for a split vector implementation.
Guido van Rossum:
> But there's always a call to remo
Travis Oliphant:
> 3) information about discontiguous memory segments
>
>
> Number 3 is where I could use feedback --- especially from PIL users and
> developers. Strides are a common way to think about a possibly
> discontiguous chunk of memory (which appear in NumPy when you select a
> sub-reg
Martin v. Löwis:
> Currently, we have two running tracker demos online:
After playing with them for 30 minutes, Jira seems to have too busy
an interface and finicky behaviour: not liking the back button
sometimes (similar to SF) and clicking on diffs wants to download them
rather than view the
Trent Nelson:
> I ended up playing around with Profile Guided Optimization, running
> ``python.exe pystones.py'' to collect call-graph data after
> python.exe/Python24.dll had been instrumented, then recompiling with the
> optimizations fed back in.
It'd be an idea to build a larger body of Py
Brett Cannon:
> But SourceForge does not support anonymous reporting.
SourceForge does support anonymous reporting. A large proportion of
the fault reports I receive for Scintilla are anonymous as indicated
by "nobody" in the "Submitted By" column.
https://sourceforge.net/tracker/?group_id=243
Kristján V. Jónsson:
> Although python has had full unicode support for filenames for a long time
> on selected platforms (e.g. Windows), there is one glaring deficiency: It
> cannot import from paths containing unicode. I´ve tried creating folders
> with chinese characters and adding them to pa
Martin v. Löwis:
> Apparently, the status of this changed right now: it seems that
> the 2003 compiler is not available anymore; the page now says
> that it was replaced with the 2005 compiler.
>
> Should we reconsider?
I expect Microsoft means that Visual Studio Express will be
available free
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
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:
> 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
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
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:
> 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
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
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
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
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,
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
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
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
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:
> 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:
> That's very tricky. If you have multiple implementations, you make
> usage at the C API difficult. If you make it either UTF-8 or UTF-32,
> you make PythonWin difficult. If you make it UTF-16, you make indexing
> difficult.
For Windows, the code will get a little uglier, nee
Guido van Rossum:
> Folks, please focus on what Python 3000 should do.
>
> I'm thinking about making all character strings Unicode (possibly with
> different internal representations a la NSString in Apple's Objective
> C) and introduce a separate mutable bytes array data type. But I could
> use s
Bruce Eckel:
> I would say that the troublesome meme is that "threads are easy." I
> posted an earlier, rather longish message about this. The gist of
> which was: "when someone says that threads are easy, I have no idea
> what they mean by it."
I think you are overcomplicating the issue by lo
Antoine Pitrou:
> I don't have a Windows machine at hand right now to test it, but, even
> if this solution works, it breaks the principle of least astonishment:
Astonishment is subjective and so a poor tool to measure by. At one
stage Ruby tried to follow the more common formulation "principl
Antoine Pitrou:
> As for seamless unicode support, there are also problems sometimes with
> filenames and filepaths: see e.g.
> https://sourceforge.net/tracker/?func=detail&aid=1283895&group_id=5470&atid=105470
This bug report is using byte string arguments causing byte string
processing rathe
Gareth McCaughan:
> >Interactive use is its own mode and works differently to the base
> > language. To print the value of something, just type an expression.
>
> Doesn't do the same thing.
In interactive mode, you are normally interested in the values of
things, not their formatting so i
Gareth McCaughan:
> 3. It's convenient for debugging, interactive use, simple scripts,
>and various other things.
Interactive use is its own mode and works differently to the base
language. To print the value of something, just type an expression.
Python will evaluate and print the value o
Martin v. Löwis:
> This appears to be based on the usedDefault return value of
> WideCharToMultiByte. I believe this is insufficient:
> WideCharToMultiByte might convert Unicode characters to
> codepage characters in a lossy way, without using the default
> character. For example, it converts U+03
Martin v. Löwis:
> - But then, the wide API gives all results as Unicode. If you want to
> promote only those entries that need it, it really means that you
> only want to "demote" those that don't need it. But how can you tell
> whether an entry needs it? There is no API to find out.
I
1 - 100 of 115 matches
Mail list logo
