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
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
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
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
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
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
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
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,
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
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
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
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;
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
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:
> 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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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:
> 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
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,
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
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
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
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
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
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'.
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
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
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
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
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
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
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
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\
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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 - 100 of 115 matches
Mail list logo