Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Alternatively, you can install 2.6 first.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think you should use the locale's encoding to process the data, ie.
either mbstowcs, then Unicode from wchar_t, or decode with the
nl_langinfo(CODESET) encoding. You might have to set the locale before
this can work (which i
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> We've had the same issue with the OpenSSL license and the other
> 3rd party packages which come with the Python Windows installer.
No, the issue was completely different. Those licenses literally
say "include a co
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Guido, would you like to review?
--
assignee: effbot -> gvanrossum
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
It doesn't work that way - you can't use sizeof() in the preprocessor.
Instead, the pyconfig.h constants should be used. I'll try to look into
this later today.
___
Python trac
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I have now committed the change as r66362 (including the missing
documentation updates), and ported it to 3.0 as r66363 (where I had to
change the flag value and regenerate the data, as the flag 0x100 was
already
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is my attempt for a patch (obmalloc.diff). Please review.
--
keywords: +needs review
Added file: http://bugs.python.org/file11457/obmalloc.diff
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch is fine, please apply.
--
assignee: -> amaury.forgeotdarc
keywords: -needs review
nosy: +loewis
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<h
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I still don't see why this is a release blocker. Adding a 2to3 fixer
certainly isn't a release blocker - if the fixer isn't available, users
would need to manually fix the code.
Adding a Py3k warning shouldn't be
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Given that this is now a request for a fixer, and not a request for a
deprecation warning, I don't see why this is considered a release
blocker. Lowering the priority to normal. Even if the fixer isn't added
to the 2to3 c
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why is this a release blocker? If you configure without threads, you get
a few ugly compiler messages, but Python still builds exactly the same
way as without this patch, right?
So if the patch doesn't make it into 2.6, it c
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
If Christian's analysis is right, and memory is released except for the
last thread, I don't think this qualifies as a release blocker.
Also (unless I misinterpret the issue), it seems that we have made many
releases alread
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> That's unfortunate -- perhaps the 2.6 flag and data can be brought in
> line, to make future merges easier?
I thought of that, however, merging the databases themselves would still
not be possible: the 3.0 database has
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> The control characters?
Indeed, also the private-use characters. test_unicode explicitly
comments that the test is about unassigned characters, although
I don't understand the purpose of that test (it then also tests
a surro
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
versions: +3rd party
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I have now committed the new patch as r66383 and r66384
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch is fine, please apply. My only question is why the 3.0 patch
integrates the find_recursionlimit change, whereas the 2.6 patch does not.
--
assignee: mhammond -> amaury.forgeotdarc
nosy: +loewis
resolution: -&
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
According to POSIX, if no determinate value for SEM_VALUE_MAX can be
given, the actual value should be queried with
sysconf(_SC_SEM_VALUE_MAX), and SEM_VALUE_MAX should not be defined;
this is in particular the case when the value depe
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ah, ok. It's all fine, then.
--
keywords: -needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't think you meant to send this to the tracker.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch is fine, please try to apply it before rc1. If rc1 gets
missed, it should be defered to 2.7.
--
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Asking in the same direction: what is the consequence of this patch when
check_same_thread is False? Couldn't that result in very problematic
overlappings, e.g. when two threads try to execute statements on the
same cursor?
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> This has nothing to do with releasing/aquiring the GIL around
> sqlite3_prepare, though.
You mean, it doesn't make things worse, but I believe they do
(even if so only slightly). If you have two threads simultaneou
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3846>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is a duplicate of issue3820.
If you need to try something now, try 3.0b2.
--
nosy: +loewis
resolution: -> duplicate
status: open -> closed
___
Python tracker <[EMAIL PR
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the reminder. This is now fixed in r66439 and r66440, as well
as 2.6rc1 (although I haven't actually tested it, due to lack of access
to an AMD64 system right now - please report whether it works).
--
no
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Van, your recommendation is much appreciated. I'll add your text to the
LICENSE file of the next release candidates.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>> In any case, I also think this doesn't matter much either way.
> Why do you think so?
What's the actual difference that this change makes? At most 8
bytes per object, right? And for two objects in total. So
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r66460 and r66462; the text that gets included is
in Tools/msi/crtlicense.txt.
--
keywords: -easy
resolution: -> fixed
status: open -> closed
___
Python tra
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> So how should this bug report be handled? Provide a patch to handle
> getsizeof correctly for small_ints? 'wont fix' because there are issues
> anyway? I would prefer the former and try to come up with a p
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Do you have TCL_DIR or TK_DIR environment variables set?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As a security issue, the patch should also be backport to 2.5 (and 2.4
if applicable)
--
nosy: +loewis
versions: +Python 2.4, Python 2.5
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, closing. Thanks for the patch, anyway.
--
resolution: -> out of date
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
In 3.0rc1, I get, for "make htmlhelp"
... contents copyright distutils/apiref Exception occurred:
File
"/cygdrive/c/loewis/3k/python/Doc/tools/pygments/lexers/__init__.py", lin
e 83, in get_lexer_by_name
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch looks fine to me, except that the failure message is now out
of date.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I agree with Amaury's analysis (except that the preferred way to
override it is to define SQLITE_THREADSAFE directly). If it's not
defined, it defaults to 1.
Closing as works-for-me.
--
resolution: -> works
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I can't reproduce the problem. Did you install for all users, or just
for you? Do you have the CRT already installed or not?
Can you try replacing the manifest with the attached one (not sure why
it says x86)? You then also need
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Formally, I can't answer that question; you need to ask the RM.
Informally, I think only serious bugs can be fixed now; this bug is not
serious.
___
Python tracker <[EMAIL PRO
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
You were right; the x86 version of the CRT was included. This is now
fixed in r66514 and r66515.
If you want to try it out, try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6rc2.amd64.msi
http://www.dcl.hpi.uni-potsdam.d
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Amaury, what further review of the patch do you desire? I had already
commented that I consider the patch correct, except that it might use
stdout_encoding instead.
Also, I wouldn't consider this a release blocker. It is somewh
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'd like to appeal that decision. That the turtle module is implemented
in Tkinter is, well, an implementation detail. What matters to the end
user is the turtle API, which has little to do with Tkinter (at least,
the most hig
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r66531.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Is there any problem with always computing the end of the string as "s +
wcslen(s)"? I feel that this is actually more readable than wcschr.
Here is a patch that does that. It doesn't change PC/getpathp.c, since
it&#
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
msg71969 suggests that OpenBSD 4.4 still fails to build Python if
_XOPEN_SOURCE is defined.
Henry, can you please confirm that
a) the problem still is that select is unavailable if _POSIX_SOURCE is
defined, and
b) the attached patch
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Looking at the code again, it might be that definition of _POSIX_SOURCE
is not harmful per se anymore, as long as _BSD_SOURCE is also defined.
Can you please also try the alternative bsd2.diff?
Added file: http://bugs.python.org/fil
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is intentional. tkinter now lives directly in the lib directory
(and is a package).
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
___
Python tracker <[
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Hye-Shik, can you please review this patch?
--
assignee: -> hyeshik.chang
keywords: +needs review
nosy: +hyeshik.chang
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I didn't mean to suggest that a new codec is created; instead, mbstowcs
should be called directly in grpmodule.c.
By default, mbstowcs will use ASCII, so it is likely to fail - you would
need to call setl
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Dominique, unless you contribute a fix yourself, no fix might get
included in 2.6.
I still would leave Tix "in" 2.6, unless it can be shown that all Tix
widgets are broken.
I don't think it's a problem that the
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
It would be best if you could contribute a patch to fix this. The source
of configure is configure.in; you need autoconf to generate configure
from it.
--
nosy: +loewis
___
Python tracker &
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Jean-Paul, to find out why the specific patch was not backported, you
would have to ask the original committer (which happens to be Georg
Brandl). If you want to ask that question through the tracker, it's best
to add him to th
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
In this case, I think there is nothing we can do. Perhaps it is useful
to put a comment into the test, pointing out that this is likely to
break on Cygwin, and refer to this issue.
I don't see that as a problem: it's just a
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
nosy: +schuppenies
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3934>
___
__
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: -> low
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3938>
___
___
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Please submit separate patches for unrelated issues. As a whole, the
patch is unacceptable because of that.
Please don't add comments to the code that describe what has changed, or
what was before. Only describe what is. Specific
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Notice that the chm file is available on Windows only. So in general,
opening the online documentation might be the right thing to do.
--
nosy: +loewis
title: Help in IDLE doesn't work correctly -> Help in IDLE shoul
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Kurt, even if using online documentation is necessary, I think the URL
is not quite right - it should rather be a version-dependent URL, IMO.
--
assignee: -> kbk
nosy: +kbk
___
Pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
You are right that this was by mistake; here is a patch to revert that
mistake (revert.diff).
I'm marking the issue release-critical because of thsi patch; the other
patches (for adding a new configure option) clearly can't
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11588/revert.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Sorry about that - let me retry.
Added file: http://bugs.python.org/file11596/revert.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Doesn't getgrgid() return the untranslated content of /etc/group?
> Then the encoding of this file is relevant.
That certainly depends on the implementation of getgrgid. On some
systems, it uses NIS, LDAP, or a relat
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'm opposed to this patch. As a design principle, any class should
always call its base class' __init__, unless that is known to be empty.
With this patch, the base __init__ call becomes conditional, which hints
at a d
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As a follow-up, I also don't understand the two if blocks in
Screen.__init__: if there is meant to be a single Screen instance
anyway, why have _root, _canvas, and _title as class variables, whereas
everything else is in (share
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I see a list of owners in the code (although it's difficult to infer
real names or email addresses from that list). I think we should not
include the code without their explicit approval.
The question will then always be:
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Committed as r66616 and r66617
--
assignee: loewis ->
priority: release blocker -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think it is somewhat surprising that the file name shows up at the end
in the traceback. Instead of getting
IOError: [Errno 22] invalid filename or mode 'w': '/dos/foo\n'
it might be better if it said
IOErro
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> What is the procedure to have this new version merged into the msi file?
The version of Tix being used is the one in the Subversion externals
directory. See the subversion log for a complete list of changes; most
specifically, wi
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is the bug tracker for the Python Core project. Please report
problems with win32file to the Python-Win32 project
(http://sourceforge.net/projects/pywin32)
--
nosy: +loewis
resolution: -> invalid
status: open
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. I have now integrated this patch into
externals/tix-8.4.3.1 (along with a patch to compile it for AMD64). Demo
installers including this code are available at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please be more specific what precise version you have been trying?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'm skeptical. What networking code specifically are you using, and what
specifically does it use string formatting for?
--
nosy: +loewis
___
Python tracker <[EMAIL PRO
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I'm working on the tests for ftplib. [1] The dummy server uses string
> formatting to build responses.
I see. I propose to add a method push_string, defined as
def push_string(self, s):
self.push(s.encode(&quo
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I'll demonstrate here in a short interactive session (which you can
> reproduce using IDLE with the -n switch as usual), why the solution
> Martin proposes doesn't meet the requirements I tried to accomplish wit
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch that takes the alternative route, of making Screen a
singleton function, and renaming the class to _Screen.
Added file: http://bugs.python.org/file11643/singleton.diff
___
Python t
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11645/singleton.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11643/singleton.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
It was indeed the case that I had been packaging an unversioned file. I
don't recall the details; most likely, it was a quick work-around for
2to3 not having a .py extension, yet the MSI generator only
incorporating .py files f
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I dislike the brute-force approach of this patch. IMO, a less intrusive
solution should be found.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'd like to propose yet another approach: make sure that conversion
according to the file system encoding always succeeds. If an
unconvertable byte is detected, map it into some private-use character.
To reduce the chance of co
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Consider this scenario. On ext3/Linux, assume that UTF-8 is specified
> in the system locale. What would happen if you have two files, named
> b"\xf3\xb3\x83\x80\x00" and b"\xc0\x00"? Under your prop
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I agree we also need to
> support bytes strings (at least on Unix) in order to support backup
> routines
How about letting such applications set the file system encoding to
Latin-1?
___
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
James Knight points out that UTF-8b can be used to give unambiguous
round-tripping of characters in a UTF-8 locale. So I would like to amend
my previous proposal:
- for a non-UTF-8 encoding, use private-use characters for roundtrippin
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> When 2.6 is out, what do you think is the right point for a further
> discussion of this? (I think certainly not the bugtracker and
> particularly not this issue.
Depends on what you want to achieve with the discussion
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>>>> unicode('€', 'iso-8859-15')
> u'\x80'
>>>> unicode('€', 'iso-8859-1') #***
> u'\x80'
>
> It looks like iso-8859-1 behaves as iso-8
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>> I think Martin's suggesting of encoding back to ascii might be
>> the best thing to do
>
> As I understand, you would like to use bytes as characters, like
> b'{code} {message}'.forma
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Committed (with the two proposed modifications) as r66686 and r66687.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch that solves the issue in a different way: it introduces
sys.setfilesystemencoding. If applications invoke
sys.setfilesystemencoding("iso-8859-1"), all file names can be
successfully converted into a characte
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> The 2**16 in the error message is wrong.
As he says.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I don't know iso codeset that define characters in code range 0x80 0x9f.
That's not true. In ISO-8859-1 (atleast, in the IANA charset), these
characters are indeed assigned - for control functions. So the
ISO-8859-1 by
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r66710 and r66711.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
For the moment, this case is just not supported.
--
nosy: +loewis
versions: +Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> gpolo's patch issue3774_2.diff does seem to fix this bug, but it's not in
> the SVN trunk - could this be done before 2.6 final?
Definitely not. The release is about to be produced today.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Notice that there is also IOBinding.coding_spec. Not sure whether this
or the one in tokenize is more correct.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Guido, it seems you added these in r31526. What do you think?
--
assignee: -> gvanrossum
nosy: +gvanrossum, loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Martin, do you concur?
Not really. On my system, which is part of a domain, expanduser("~")
gives 'C:\\Documents and Settings\\martin.vonloewis', which is
indeed the directory where my profile lives. HOMEDRIVE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Martin, can you check in your changes to add sys.setfilesystemencoding()?
Will do tomorrow.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I had noticed the problem myself, and I don't know any solution to it.
It's still part of the aftermath of switching to VS 2008, maybe we
should have stayed with VS 2003 :-(
Out of curiosity: Is this Vista SP1? If so, can so
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I looked for
> a solution to this, but so far can't find any -- and this would also
> mean that .pyd files in site-packages and elsewhere would need .manifest
> files that contain the path to where msvcr90.dll is
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Oh! IOBinding reimplement many features now available in Python like
> universal new line or function to write unicode strings to a file.
It did not *re*implement. The implementation in IOBinding predates all
other impleme
1401 - 1500 of 4778 matches
Mail list logo
