New submission from Sarah Harvey :
I've been tracking this through a bunch of different projects now. With the
release of Mac OS X Catalina, libcrypto.dylib is a dummy library that causes an
automatic segfault, to prevent upstream software from relying on it.
However a large amou
Changes by Sarah Mount :
--
nosy: +snim2
___
Python tracker
<http://bugs.python.org/issue14060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Sarah :
--
resolution: -> works for me
Added file: http://bugs.python.org/file31078/ReplaceDialogPatch.patch
___
Python tracker
<http://bugs.python.org/issu
New submission from Sarah:
In Windows, the 'find' and 'replace' dialogs do not work properly on text that
has been commented out using quotation marks.
More specifically, the dialog *finds* the text in question, however, it does
not *highlight* it. Without the highlighti
Changes by Sarah :
--
nosy: +Sarah
___
Python tracker
<http://bugs.python.org/issue2704>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Sarah added the comment:
I agree that discussion is a good idea.
Personally, though, I don't want to make the user hit ^F once to set the key
and use ^G to find it again. It works well and, for a more advanced user, is
great, but it adds to what a user must learn to get up and runni
Sarah added the comment:
'Find Again' switched to 'Find Next'
--
Added file: http://bugs.python.org/file29740/issue_17511_FindNext.patch
___
Python tracker
<http://bug
Sarah added the comment:
Terry-
There should be a checkbutton option labeled 'Wrap Around'. This is
instantiated on lines 7 and 105-111 of SearchDialogBase.py
Admittedly, it is standard practice to have a 'find' function wrap around. I
suppose we could have the dialog sta
Sarah added the comment:
This changes the button's text from "Find" to "Find Again", as per Todd Rovito
and Terry J. Reedy's suggestion.
--
Added file: http://bugs.python.org/file29735/issue17511_FindAgain.patch
___
Sarah added the comment:
This should allow the 'find' window to stay open. It also circumvents an issue
in Windows, wherein highlighted text did not show while the 'find' window was
open. The found text should now show as highlighted for any OS (as far as I
know; please
New submission from Sarah:
When I use the 'find' function in Idle, the dialogue closes after the first
instance is found.
To find the next instance, one must then use the 'find again' function, rather
than the 'find' function. One can also use Ctrl+G, but that
David-Sarah Hopwood added the comment:
Giampaolo: See #msg120700 for why that won't work, and the subsequent comments
for what will work instead (basically, using WriteConsoleW and a workaround for
a Windows API bug). Also see the prototype win_console.patch from Victor
Stinner: #msg1
David-Sarah Hopwood added the comment:
If I understand the bug in the Windows console functions correctly, a limit of
32767 bytes might not always be small enough. The problem is that if two or
more threads are concurrently using any console functions (which all use the
same 64 KiB heap
David-Sarah Hopwood added the comment:
Glenn wrote:
> So if flush checks that bit, maybe TextIOWriter could just call buffer.flush,
> and it would be fast if clean and slow if dirty?
Yes. I'll benchmark how much overhead is added by the calls to flush; there's
no point
David-Sarah Hopwood added the comment:
I wrote:
> A similar issue arises for stdin: to maintain strict compatibility, every
> read from a TextIOWrapper attached to an input console would have to drain
> the buffer of its buffer object, in case the app has read from it. This is a
>
David-Sarah Hopwood added the comment:
First a minor correction:
> The new requirement would be that a correct app also needs to flush between a
> sequence of buffer.writes (that end in an incomplete line, or always if
> PYTHONUNBUFFERED or python -u is used), and a sequence of writ
David-Sarah Hopwood added the comment:
Glenn Linderman wrote:
> Presently, a correct application only needs to flush between a sequence of
> writes and a sequence of buffer.writes.
Right. The new requirement would be that a correct app also needs to flush
between a sequence of buffer.
David-Sarah Hopwood added the comment:
I wrote:
$ python3 -c 'import sys; sys.stdout.write("foo");
sys.stdout.buffer.write(b"bar"); sys.stdout.write("baz\n")'
barfoobaz
Hmm, the behaviour actually would differ here: the proposed implementation
wou
David-Sarah Hopwood added the comment:
I wrote:
> The only caveat would be that if you write a partial line to the buffer
> object (or if you set the buffer object to be fully buffered and write to
> it), and then write to the text stream, the buffer wouldn't be flushed before
David-Sarah Hopwood added the comment:
(For anyone wondering about the hold-up on this bug, I ended up switching to
Ubuntu. Not to worry, I now have Python 3 building in XP under VirtualBox --
which is further than I ever got with my broken Vista install :-/ It seems to
behave identically to
David-Sarah Hopwood added the comment:
Feedback from Julie Solon of Microsoft:
> These console functions share a per-process heap that is 64K. There is some
> overhead, the heap can get fragmented, and calls from multiple threads all
> affect how much is available for this buffer.
Changes by David-Sarah Hopwood :
--
title: windows console doesn't print utf8 (Py30a2) -> windows console doesn't
print or input Unicode
Added file: http://bugs.python.org/file20363/doc-patch.diff
___
Python tracker
<http:/
Changes by David-Sarah Hopwood :
Added file: http://bugs.python.org/file20362/doc-patch.diff
___
Python tracker
<http://bugs.python.org/issue1602>
___
___
Python-bug
Changes by David-Sarah Hopwood :
--
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20361/doc-patch.diff
___
Python tracker
<http://bugs.python.org/issue1
Changes by David-Sarah Hopwood :
--
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20360/doc-patch.diff
___
Python tracker
<http://bugs.python.org/issue1
David-Sarah Hopwood added the comment:
"... os.dup2() ..."
Good point, thanks.
It would work to change os.dup2 so that if its second argument is 0, 1, or 2,
it calls _get_osfhandle to get the Windows handle for that fd, and then reruns
the console-detection logic. That would
David-Sarah Hopwood added the comment:
Looking at
http://svn.python.org/view/python/branches/py3k/PC/getpathp.c?r1=73322&r2=73321&pathrev=73322
, wouldn't it be better to add a Py_WGETENV function? There are likely to be
other cases where that would be the correct
David-Sarah Hopwood added the comment:
Note: Michael Kaplan's code checks whether GetConsoleMode failed due to
ERROR_INVALID_HANDLE. My code intentionally doesn't do that, because it is
correct and conservative to fall back to the non-console behaviour when there
is *any*
David-Sarah Hopwood added the comment:
> The script unicode2.py uses the console STD_OUTPUT_HANDLE iff
> sys.stdout.fileno()==1.
You may have missed "if not_a_console(hStdout): real_stdout = False".
not_a_console uses GetFileType and GetConsoleMode to check whether that handle
David-Sarah Hopwood added the comment:
I'll have a look at the Py3k I/O internals and see what I can do.
(Reopening a bug appears to need Coordinator permissions.)
--
___
Python tracker
<http://bugs.python.org/i
David-Sarah Hopwood added the comment:
Don't use win32file.GetDiskFreeSpace; the underlying Windows API only supports
drives up to 2 GB
(http://blogs.msdn.com/b/oldnewthing/archive/2007/11/01/5807020.aspx). Use
GetFreeDiskSpaceEx, as the code I linked to does.
I'm not sure it make
David-Sarah Hopwood added the comment:
haypo wrote:
> davidsarah wrote:
>> It is certainly possible to write Unicode to the console
>> successfully using WriteConsoleW
>
> Did you tried with characters not encodable to the code page and with
> character that cannot
David-Sarah Hopwood added the comment:
Sorry, missed out the imports:
from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_int
from ctypes.wintypes import LPWSTR, LPCWSTR
--
___
Python tracker
<http://bugs.python.org/issue2
David-Sarah Hopwood added the comment:
The following code is being used to work around this issue for Python 2.x in
Tahoe-LAFS:
# This works around <http://bugs.python.org/issue2128>.
GetCommandLineW = WINFUNCTYPE(LPWSTR)(("GetCommandLineW", windll.kernel32))
Co
David-Sarah Hopwood added the comment:
Glenn Linderman wrote:
> I skipped the unmangling of command-line arguments, because it produced an
> error I didn't understand, about needing a buffer protocol.
If I understand correctly, that part isn't needed on Python 3 because issue
David-Sarah Hopwood added the comment:
It is certainly possible to write Unicode to the console successfully using
WriteConsoleW. This works regardless of the console code page, including 65001.
The code http://tahoe-lafs.org/trac/tahoe-lafs/browser/src/allmydata/windows/fixups.py";
David-Sarah Hopwood added the comment:
"Is there a portable way to get the available disk space by now?"
No, but
http://tahoe-lafs.org/trac/tahoe-lafs/browser/src/allmydata/util/fileutil.py?rev=4894#L308
might be helpful (uses pywin32).
--
nosy: +
David-Sarah Hopwood added the comment:
Oops, false alarm. python -c "import os; print repr(os.getcwdu())" works as
expected, so the exception is part of issue 1602.
(My command about there being no need to distinguish this codepage from UTF
David-Sarah Hopwood added the comment:
I meant to say that the os.getcwdu() test in msg119440 was done with Windows
native Python 2.6.2.
--
___
Python tracker
<http://bugs.python.org/issue6
David-Sarah Hopwood added the comment:
I said: "There is only one correct way to encode/decode UTF-8". This is true
modulo differences in the treatment of initial byte order marks.
--
___
Python tracker
<http://bugs.python.
David-Sarah Hopwood added the comment:
This problem causes {{{os.getcwdu()}}} to fail when the console code page is
set to 65001 (always, I think):
{{{
t:\>ver
Microsoft Windows [Version 6.0.6002]
t:\>chcp
Active code page: 65001
t:\>python -c "import os; print os.getcwdu()&qu
David-Sarah Hopwood added the comment:
Correction: when input is followed by output, the call needed to avoid
undefined behaviour has to be to a "file positioning function" (fseek, fsetpos,
or rewind, but not fflush). Since fileobject.c does not use wide I/O
operations, it
New submission from David-Sarah Hopwood :
The C standard (any version, or POSIX), says in the description of fopen that:
{{{
When a file is opened with update mode ( '+' as the second or third character
in the mode argument), both input and output may be performed on the associat
43 matches
Mail list logo
