Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu

2013-02-16 Thread Neil Hodgson
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

Re: [Python-Dev] cffi in stdlib

2013-02-27 Thread Neil Hodgson
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

Re: [Python-Dev] cffi in stdlib

2013-02-28 Thread Neil Hodgson
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

Re: [Python-Dev] IDLE in the stdlib

2013-03-20 Thread Neil Hodgson
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

Re: [Python-Dev] Ext4 data loss

2009-03-10 Thread Neil Hodgson
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

Re: [Python-Dev] Ext4 data loss

2009-03-11 Thread Neil Hodgson
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

Re: [Python-Dev] Ext4 data loss

2009-03-11 Thread Neil Hodgson
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

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

2009-03-29 Thread Neil Hodgson
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,

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

2009-04-09 Thread Neil Hodgson
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

Re: [Python-Dev] Support for Python/Windows

2009-07-21 Thread Neil Hodgson
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

Re: [Python-Dev] command line attachable debugger

2009-07-24 Thread Neil Hodgson
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

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-25 Thread Neil Hodgson
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;

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-25 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-04 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-05 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-05 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-05 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-06 Thread Neil Hodgson
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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Neil Hodgson
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

Re: [Python-Dev] Mercurial migration: help needed

2009-09-05 Thread Neil Hodgson
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 >

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-10-07 Thread Neil Hodgson
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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-12 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 3147: PYC Repository Directories

2010-01-31 Thread Neil Hodgson
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

Re: [Python-Dev] Reworking the GIL

2010-02-02 Thread Neil Hodgson
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

Re: [Python-Dev] Proposal for virtualenv functionality in Python

2010-02-21 Thread Neil Hodgson
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

Re: [Python-Dev] Python and Windows 2000

2010-03-01 Thread Neil Hodgson
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

Re: [Python-Dev] Python and Windows 2000

2010-03-02 Thread Neil Hodgson
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

Re: [Python-Dev] C++

2010-03-12 Thread Neil Hodgson
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

Re: [Python-Dev] Support byte string API of Windows in Python3?

2010-04-19 Thread Neil Hodgson
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

Re: [Python-Dev] email package status in 3.X

2010-06-18 Thread Neil Hodgson
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

Re: [Python-Dev] email package status in 3.X

2010-06-21 Thread Neil Hodgson
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

Re: [Python-Dev] Licensing // PSF // Motion of non-confidence

2010-07-05 Thread Neil Hodgson
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

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

2010-07-12 Thread Neil Hodgson
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?

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

2010-07-12 Thread Neil Hodgson
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

Re: [Python-Dev] Removing IDLE from the standard library

2010-07-14 Thread Neil Hodgson
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

Re: [Python-Dev] mingw support?

2010-08-08 Thread Neil Hodgson
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

Re: [Python-Dev] Fwd: i18n

2010-08-25 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 384 status

2010-08-31 Thread Neil Hodgson
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

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

2010-09-21 Thread Neil Hodgson
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

Re: [Python-Dev] Python and the Unicode Character Database

2010-12-02 Thread Neil Hodgson
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

Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/

2006-07-20 Thread Neil Hodgson
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

Re: [Python-Dev] Python 2.4, VS 2005 & Profile Guided Optmization

2006-07-23 Thread Neil Hodgson
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

Re: [Python-Dev] More tracker demos online

2006-07-25 Thread Neil Hodgson
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

Re: [Python-Dev] Extended Buffer Interface/Protocol

2007-03-21 Thread Neil Hodgson
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

Re: [Python-Dev] Extended Buffer Interface/Protocol

2007-03-21 Thread Neil Hodgson
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

Re: [Python-Dev] Extended Buffer Interface/Protocol

2007-03-23 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)

2007-04-09 Thread Neil Hodgson
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

Re: [Python-Dev] Python and the Unicode Character Database

2010-12-03 Thread Neil Hodgson
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

Re: [Python-Dev] Import and unicode: part two

2011-01-20 Thread Neil Hodgson
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

Re: [Python-Dev] Import and unicode: part two

2011-01-26 Thread Neil Hodgson
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

Re: [Python-Dev] Mercurial conversion repositories

2011-02-25 Thread Neil Hodgson
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

Re: [Python-Dev] Mercurial conversion repositories

2011-02-25 Thread Neil Hodgson
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

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

2011-02-26 Thread Neil Hodgson
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

Re: [Python-Dev] devguide (hg_transition): Advertise hg import over patch.

2011-02-27 Thread Neil Hodgson
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

Re: [Python-Dev] devguide (hg_transition): Advertise hg import over patch.

2011-02-27 Thread Neil Hodgson
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

Re: [Python-Dev] CPython hg transition complete

2011-03-05 Thread Neil Hodgson
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

Re: [Python-Dev] CPython hg transition complete

2011-03-05 Thread Neil Hodgson
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 ___

Re: [Python-Dev] CPython hg transition complete

2011-03-05 Thread Neil Hodgson
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

Re: [Python-Dev] hgeol

2011-03-05 Thread Neil Hodgson
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

Re: [Python-Dev] Bugs in thread_nt.h

2011-03-10 Thread Neil Hodgson
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

Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-09 Thread Neil Hodgson
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

Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-09 Thread Neil Hodgson
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

Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-09 Thread Neil Hodgson
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

Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-09 Thread Neil Hodgson
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

Re: [Python-Dev] The socket HOWTO

2011-06-04 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)

2008-03-21 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-08-31 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-08-31 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Neil Hodgson
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

Re: [Python-Dev] PEP 393 Summer of Code Project

2011-09-01 Thread Neil Hodgson
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,

Re: [Python-Dev] Windows 8 support

2011-09-14 Thread Neil Hodgson
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

Re: [Python-Dev] Python as a Metro-style App

2012-01-07 Thread Neil Hodgson
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

Re: [Python-Dev] Python as a Metro-style App

2012-01-07 Thread Neil Hodgson
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

Re: [Python-Dev] VS 11 Express is Metro only.

2012-05-30 Thread Neil Hodgson
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

Re: [Python-Dev] Is msvcr71.dll re-redistributable?

2005-02-02 Thread Neil Hodgson
Anders J. Munch: > 1. John X. Programmer buys the product, agrees to the EULA and puts >the DLL up for download, with the explicit and stated intent of >distributing it to anyone who needs it. Disallowed in 3.1(a): # you agree: ... to distribute the Redistributables only ... in # conj

Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())

2005-03-13 Thread Neil Hodgson
Guido van Rossum: > - Before anybody asks, I really do think the reason this is requested > at all is really just to save typing; there isn't the "avoid double > evaluation" argument that helped acceptance for assignment operators > (+= etc.), and I find redability is actually improved with 'for'.

Re: [Python-Dev] Visual studio 2005 express now free

2006-04-24 Thread Neil Hodgson
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

Re: [Python-Dev] unicode imports

2006-06-16 Thread Neil Hodgson
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

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-06-27 Thread Neil Hodgson
Andrew Durdin: > While we'ew discussing outstanding issues: In a related discussion of > the path module on c.l.py, Thomas Heller pointed out that the path > module doesn't correctly handle unicode paths: > ... Here is a patch that avoids failure when paths can not be represented in a single 8

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-06-30 Thread Neil Hodgson
Guido van Rossum: > Whoa! Do we really need a completely different mechanism for doing the > same stuff we can already do? One benefit I see for the path module is that it makes it easier to write code that behaves correctly with unicode paths on Windows. Currently, to implement code that may

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-01 Thread Neil Hodgson
Thomas Heller: > OTOH, Python is lacking a lot when you have to handle unicode strings on > sys.path, in command line arguments, environment variables and maybe > other places. A new patch #1231336 "Add unicode for sys.argv, os.environ, os.system" is now in SourceForge. New parallel features

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-03 Thread Neil Hodgson
Guido van Rossum: > Then maybe the code that handles Unicode paths in arguments should be > fixed rather than adding a module that encapsulates a work-around... It isn't clear whether you are saying this should be fixed by the user or in the library. For a quick example, say someone wrote some

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-04 Thread Neil Hodgson
Thomas Heller: > Not only that, all the other flags like -O and -E are also in sys.argvu > but not in sys.argv. OK, new patch fixes these and the "-c" issue. > Those are nearly obsoleted by the subprocess module (although I do not > know how that handles unicode. It breaks. The argspec is

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-06 Thread Neil Hodgson
Guido van Rossum: > Ah, sigh. I didn't know that os.listdir() behaves differently when the > argument is Unicode. Does os.listdir(".") really behave differently > than os.listdir(u".")? Yes: >>> os.listdir(".") ['abc', ''] >>> os.listdir(u".") [u'abc', u'\u0417\u0434\u0440\u0430\

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-08 Thread Neil Hodgson
Thomas Heller: > OTOH, I once had a bug report from a py2exe user who complained that the > program didn't start when installed in a path with japanese characters > on it. I tried this out, the bug existed (and still exists), but I was > astonished how many programs behaved the same: On a PC with

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-08 Thread Neil Hodgson
Thomas Heller: > But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import > this file as module. Internally Python\import.c converts everything to > strings. I started to refactor import.c to work with PyStringObjects > instead of char buffers as a first step - PyUnicodeObjects c

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-09 Thread Neil Hodgson
M.-A. Lemburg: > I don't really buy this "trick": what if you happen to have > a home directory with Unicode characters in it ? Most people choose account names and thus home directory names that are compatible with their preferred locale settings: German users are unlikely to choose an accoun

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-11 Thread Neil Hodgson
Guido van Rossum: > In some sense the safest approach from this POV would be to return > Unicode as soon as it can't be encoded using the global default > encoding. IOW normally this would return Unicode for all names > containing non-ASCII characters. On unicode versions of Windows, for attri

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-11 Thread Neil Hodgson
M.-A. Lemburg: > It's naive to assume that all people in Germany using the German > locale have German names ;-) That is not an assumption I would make. The assumption I would make is that if it is important to you to have your account name in a particular character set then you will normally

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-11 Thread Neil Hodgson
M.-A. Lemburg: > > 2) Return unicode when the text can not be represented in ASCII. This > > will cause a change of behaviour for existing code which deals with > > non-ASCII data. > > +1 on this one (s/ASCII/Python's default encoding). I assume you mean the result of sys.getdefaultencoding()

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-12 Thread Neil Hodgson
Hi Marc-Andre, > >With the proposed modification, sys.argv[1] u'\u20ac.txt' is > > converted through cp1251 > > Actually, it is not: if you pass in a Unicode argument to > one of the file I/O functions and the OS supports Unicode > directly or at least provides the notion of a file system

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-16 Thread Neil Hodgson
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

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

2005-07-17 Thread Neil Hodgson
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

Re: [Python-Dev] Replacement for print in Python 3.0

2005-09-02 Thread Neil Hodgson
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

Re: [Python-Dev] Replacement for print in Python 3.0

2005-09-04 Thread Neil Hodgson
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

Re: [Python-Dev] international python

2005-09-09 Thread Neil Hodgson
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

Re: [Python-Dev] international python

2005-09-09 Thread Neil Hodgson
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

Re: [Python-Dev] Pythonic concurrency

2005-10-10 Thread Neil Hodgson
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

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).

2005-10-23 Thread Neil Hodgson
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

Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).

2005-10-24 Thread Neil Hodgson
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

  1   2   >