On 6/8/23, jsch...@sbcglobal.net wrote:
> I opened two issues regarding copyfileobj that were not bugs, but a fix that
> was involved helped me figure out I needed a new external drive, since it
> displayed the error number from the copyfileobj function. I'd like a
> modified version of this code
On 11/7/22, Eryk Sun wrote:
>
> def isjunction(path):
> """Test whether a path is a junction.
> """
> try:
> st = os.lstat(path)
> except (OSError, ValueError, AttributeError):
>
On 11/8/22, Charles Machalow wrote:
>
> Funny enough in PowerShell, for prints an "l" for both symlinks and
> junctions.. so it kind of thinks of it as a link of some sort too I guess.
As does Python already in many cases. For example, os.lstat() doesn't
traverse a mount point (junction). On Wind
On 11/8/22, Charles Machalow wrote:
> I tend to prefer adding isjunction instead of changing ismount since I tend
> to not think about junctions as being mounts (but closer to symlinks)..
Junctions are mount points that are similar to Unix bind mounts where
it counts -- in the behavior that's imp
On 11/7/22, Charles Machalow wrote:
> So would you be for specific methods to check if a given path is a
> junction?
I'd prefer for ismount() to be modified to always return true for a
junction. This would be a significant rewrite of the current
implementation, which is only true for a junction t
On 11/7/22, Charles Machalow wrote:
>
> Junctions are contextually similar to symlinks on Windows.
Junctions (i.e. IO_REPARSE_TAG_MOUNT_POINT) are implemented to behave
as mount points for local volumes, so there are a couple of important
differences.
In a remote path, a junction gets resolved o
On 10/18/22, Todd wrote:
>
> So I think it would make a lot of sense to include copying inside pathlib.
> I propose adding a `copy` method to `pathlib.Path` (for concrete paths).
>
> The specific call signature would be:
>
> copy(dst, *, follow_symlinks=True, recursive=True, dir_exist_ok=True)
>
>
On 10/18/22, Todd wrote:
>
> How is it any less of a "path operation" than moving files, reading and
> writing files, making directories, and deleting files?
Path-related operations involve creating, linking, symlinking, and
listing directories and files, and peripherally also accessing file
meta
On 7/24/22, Barry Scott wrote:
>
>> On 21 Jul 2022, at 16:42, Christopher Barker wrote:
>
>> However, I’m no Windows expert, but I *think* the modern Windows file
>> system(s?) support something like symlinks. It’s an under-the-hood
>> feature, but maybe it’s possible to add a symlink for bin.
>
On 5/26/22, Steven D'Aprano wrote:
>
> If you seek() to position 4, say, the results will be unpredictable but
> probably not anything good.
>
> In other words, the tell() and seek() cookies represent file positions
> in **bytes**, even though we are reading or writing a text file.
To clarify the
On 5/26/22, Christopher Barker wrote:
> IIRC, there were two builds- 16 and 32 bit Unicode. But it wasn’t UTF16, it
> was UCS-2.
In the old implementation prior to 3.3, narrow and wide builds were
supported regardless of the size of wchar_t. For a narrow build, if
wchar_t was 32-bit, then PyUnico
On 4/11/22, Chris Angelico wrote:
>
> Which raises the question: what if the current directory no longer has
> a path name? Or is that simply not possible on Windows?
The process working directory is opened without FILE_SHARE_DELETE
sharing. This prevents opening the directory with DELETE access
On 4/11/22, Chris Angelico wrote:
>
> If you say `open("/spam")`, Windows uses "default drive" + "explicit
> directory".
You can think of a default drive as being the drive of the current
working directory, but there is no "default drive" per se that's
stored separate from the working directory.
On 4/11/22, Steven D'Aprano wrote:
>
> How does that work in practice? In Windows, if you just say the
> equivalent to `open('spam')`, how does the OS know which drive
> and WD to use?
"spam" is resolved against the process working directory, which could
be a UNC path instead of a drive. OTOH, "Z
On 4/11/22, Steven D'Aprano wrote:
>
> You know how every OS process has its own working directory? Just like
> that, except every module.
A per-thread working directory makes more sense to me. But it would be
a lot of work to implement support for this in the os and io modules,
for very little g
On 2/13/22, Eric Fahlgren wrote:
>
> That may or may not work as Windows has inconsistent treatment of multiple
> separators depending on where they appear in a path. If TEMP is a drive
> spec, say "t:\", then it expands to "t:\\spam.csv", which is an invalid
> windows path. If TEMP is a directo
On 2/13/22, Paul Moore wrote:
>
> For better or worse, though, Windows (as an OS) doesn't have a "normal
> behaviour". %-expansion is a feature of CMD and .bat files, which
You're overlooking ExpandEnvironmentStringsW() [1],
ExpandEnvironmentStringsForUserW(), and PathUnExpandEnvStringsW() [2],
w
On 2/13/22, Christopher Barker wrote:
>
> Telling newbies that that means that it's either a property with no setter,
> or am object without a __dict__, or one with __slots__ defined is not
> really very helpful.
The __slots__ case is due to the lack of a __dict__ slot. It can be
manually added
On 2/11/22, Paul Moore wrote:
>
> I'm inclined to say just raise an issue on bpo. If it's easy enough,
> it'll just get done. If it's hard, having lots of people support the
> idea won't make it any easier. I don't think this is something that
> particularly needs evidence of community support bef
On 9/15/21, Paul Moore wrote:
>
> Just a somewhat off-topic note, but dir_fd arguments are only
> supported on Unix, and the functionality only appears to be present at
> the NT Kernel level on Windows, not in the Windows API.
Handle-relative paths are supported by all NT system calls that access
On 3/1/21, mmax42...@gmail.com wrote:
> And there is no way to make a mutable bytes object without a function call.
Since a code object is immutable, the proposed bytearray display form
would still require an internal operation that constructs a bytearray
from a bytes object. For example, someth
On 2/11/21, M.-A. Lemburg wrote:
> On 11.02.2021 13:49, Eryk Sun wrote:
>
>> Currently, locale.getpreferredencoding(False) is implemented as
>> locale._get_locale_encoding(). This ultimately calls
>> _Py_GetLocaleEncoding(), defined in "Python/fileutils.c"
On 2/11/21, M.-A. Lemburg wrote:
> I think the main problem here is that open() doesn't use
> locale.getlocale()[1] as default for the encoding parameter,
> but instead locale.getpreferredencoding(False).
Currently, locale.getpreferredencoding(False) is implemented as
locale._get_locale_encoding
On 2/11/21, Christopher Barker wrote:
> On Wed, Feb 10, 2021 at 12:33 AM Paul Moore wrote:
>
>> So get PYTHONUTF8 added to the environment activate script. That's a
>> simple change to venv. And virtualenv, and conda
>
> That's probably a good solution for venv and virtualenv -- essentially add
>
On 2/10/21, M.-A. Lemburg wrote:
>
> setx PYTHONUTF8 1
>
> does the trick in an admin command shell on Windows globally.
The above command sets the variable only for the current user, which
I'd recommend anyway. It does not require administrator access. To set
a machine value, run `setx /M PYTHON
On 2/9/21, Inada Naoki wrote:
> On Tue, Feb 9, 2021 at 7:42 PM M.-A. Lemburg wrote:
>
> But it affects to all Python installs. Can teachers recommend to set
> PYTHONUTF8 environment variable for students?
Users can simply create a shortcut that targets `cmd /k set
PYTHONUTF8=1`. Optionally chang
On 2/6/21, Christopher Barker wrote:
> On Sat, Feb 6, 2021 at 11:47 AM Eryk Sun wrote:
>
>> Relative to the installation, "python.cfg" should only be found in the
>> same directory as the base executable, not its parent directory.
>
> OK, my mistake — I thou
On 2/6/21, Christopher Barker wrote:
> On Fri, Feb 5, 2021 at 12:59 PM Eryk Sun wrote:
>
> But why limit it to that? If there are more things to configure in an
> environment-specific way — why not put it in this existing location?
I'd rather not limit the capabilit
On 2/6/21, Inada Naoki wrote:
>
> If adding option to pyvenv.cfg is not make sense, we can add
> `python.ini` to same place pyvenv.cfg. i.e., directory containing
> python.exe, or one above directory.
I'd rather look for "python.cfg" in the directory of the base
executable (e.g. "C:\Program Files
On 2/5/21, Barry Scott wrote:
>> On 5 Feb 2021, at 11:06, Inada Naoki wrote:
>
>> python.exe lookup pyvenv.cfg even outside of venv.
>> So we can write utf8mode=1 in pyvenv.cfg even outside of venv.
I don't like extending "pyvenv.cfg" with generic settings. This is a
file to configure a virtual
On 2/4/21, Ben Rudiak-Gould wrote:
>
> My proposal is to add a couple of single-character options to open()'s mode
> parameter. 'b' and 't' already exist, and the encoding parameter
> essentially selects subcategories of 't', but it's annoyingly verbose and
> so people often omit it.
>
> If '8' wa
On 2/2/21, Christopher Barker wrote:
>
> In the common case, folks have their environment variables set in an
> initialization file (or the registry? I've lost track of what Windows does
> these days)
It hasn't fundamentally changed since the mid 1990s. Configurable
system variables are set in th
On 1/26/21, Eryk Sun wrote:
>
> The process active code page for GetACP() and GetOEMCP() is changed to
> UTF-8 (65001). The C runtime also overrides the user locale to UTF-8
> if GetACP() returns UTF-8, i.e. setlocale(LC_CTYPE, "") will return
> "utf8" as the e
On 1/25/21, Inada Naoki wrote:
>
> Microsoft provides UTF-8 code page for process. It can be enabled by
> manifest file.
>
> How about providing Python binaris both of "UTF-8 version" and "ANSI
> version"?
I experimented with this manifest setting several months ago. To try
it out, simply export
On 12/22/20, David Mertz wrote:
> On Tue, Dec 22, 2020 at 10:26 PM Chris Angelico wrote:
>
> I'm not sure about Windows. Is 'cls' built into the command-line executable
> itself (like Busybox) or is it an exe?
CLS is an internal command of the CMD shell. An internal command takes
precedence as l
On 12/22/20, Barry Scott wrote:
>
> import sys
>
> def clear_terminal():
> if sys.platform == 'win32':
> import ctypes
> kernel32 = ctypes.windll.kernel32
> # turn on the console ANSI colour handling
> kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)
>
>
On 12/20/20, Cameron Simpson wrote:
> On 20Dec2020 15:48, Christopher Barker wrote:
>
>>That would be great, though I just looked at the 3.9 docs and saw:
>>"The Windows version of Python doesn’t include the curses module."
>
> Yeah, Windows.
A C or ctypes implementation is required in Windows.
On 11/12/20, Chris Angelico wrote:
>
> I actually don't use the "if name is main" idiom all that often. The
> need to have a script be both a module and an executable is less
> important than you might think. In a huge number of cases, it's
> actually better to separate out the library-like and sc
On 10/18/20, Mike Miller wrote:
> On 2020-10-17 17:05, Eryk Sun wrote:
>> CMD's CLS is implemented with three API calls:
>> GetConsoleScreenBufferInfo to get the screen-buffer dimensions and
>> default text attributes, ScrollConsoleScreenBufferW to sh
On 10/18/20, Mike Miller wrote:
>
> Also, a shell is not a terminal, so terminal routines don't feel right in
> shutil. Putting get_terminal_size() there was a mistake imho.
The shutil module "offers a number of high-level operations on files".
ISTM that shutil.get_terminal_size is a high-level
On 10/17/20, Christopher Barker wrote:
>
> then how about os.clear_terminal() ?
IMO, an os level function such as os.clear_terminal(fd) should only
support terminal/console devices and would be implemented in
Modules/posixmodule.c. Higher-level behavior and support for IDEs
belongs in shutil.
>
On 10/16/20, Rob Cliffe via Python-ideas wrote:
>
> May I suggest it be called os.clearscreen()?
I'd prefer shutil.clear_screen(). There's already
shutil.get_terminal_size(). I know there's also
os.get_terminal_size(), but its use isn't encouraged.
___
On 10/13/20, Mike Miller wrote:
>
> The legacy Windows console has another limitation in that I don't believe it
> has a single API call to clear the whole thing. One must iterate over the
> whole
> buffer and write spaces to each cell, or some similar craziness.
No, it's not really similar cra
On 10/16/20, Steven D'Aprano wrote:
>
> On terminals that support it, this should work:
>
> - `print('\33[H\33[2J')`
>
> but I have no idea how to avoid clearing the scrollback buffer on
> Windows, or other posix systems with unusual terminals.
In Windows 10, ANSI sequences and some C1 control ch
On 10/16/20, Barry Scott wrote:
>
> I find that you have to do this to turn on ANSI processing in CMD.EXE on
> Window 10 and I assume earlier Windwows as wel:
You mean the console-session host (conhost.exe). This has nothing to
do with the CMD shell. People often confuse CLI shells (CMD,
PowerShe
On 5/25/20, Christopher Barker wrote:
> On Mon, May 25, 2020 at 10:59 AM Steve Barnes
> wrote:
>
>> On Windows
>> https://freetechtutors.com/create-virtual-hard-disk-using-diskpart-windows/
>> gives a nice description of creating a virtual disk with only operating
>> system commands. Note that it
On 5/13/20, Antoine Pitrou wrote:
>
> If you know of a system function which accepts filenames with embedded
> NULs (which probably means it also takes the filename length as a
> separate parameter), I'd be curious to know about it.
Windows is layered over the base NT system, which uses counted s
On 5/11/20, Oleg Broytman wrote:
> On Mon, May 11, 2020 at 09:12:52PM -, Steve Jorgensen
> wrote:
>
>> When the platform is Windows, certainly, ":" should not be
>> allowed, and perhaps colon should not be allowed at all.
The meaning of ":name" is context dependent. If it occurs at
the begin
On 4/11/20, Barry Scott wrote:
>> On 10 Apr 2020, at 20:14, Christopher Barker wrote:
>>
>> Also, if order to get python top level scripts to work, there needs to be
>> a PATH entry for that, too.
>
> Do you mean the #! lines? That is taken care of by py.exe and how it was
> installed.
I think b
On 4/10/20, MRAB wrote:
> On 2020-04-10 20:14, Christopher Barker wrote:
>
>> How does py.exe get on the PATH?
>>
> py.exe goes into the Windows folder, which is on the PATH.
That's the typical setup, but a standard user that can't get OTS
administrator access has to install the launcher just for
On 3/25/20, Barry Scott wrote:
>> On 25 Mar 2020, at 09:15, Eryk Sun wrote:
>>
>> That is not consistent with Unix. env is supposed to search PATH for
>> the command. However, the launcher does not search PATH for a
>> versioned command such as "python3"
On 3/25/20, Steve Barnes wrote:
>> Except it's not necessarily what the original post wants. The OP wants the
>> shebang "#!/usr/bin/env python3" to "work everywhere by
>> default", for which I assume it's implied that it should work consistently
>> everywhere. I'd prefer for the launcher's env se
On 3/25/20, Steve Barnes wrote:
> Of course if, rather than creating symlinks, you create a batch file called
> python3.bat and containing the line:
> @py -3 %*
Batch scripts execute via cmd.exe, with an attached console, and when
Ctrl+C is typed they display a "Terminate batch job (Y/N)?" prompt
On 3/24/20, Mike Miller wrote:
> On 2020-03-24 11:58, Eryk Sun wrote:
>
>> You can manually copy or symlink python.exe to python3.exe in the
>> installation directory and venv "Scripts" directories. However, it
>> will only be used on the command line, and
On 3/24/20, Mike Miller wrote:
>
> C:\Users\User>python3
> (App store loads!!)
If installed, the app distribution has an appexec link for
"python3.exe" that actually works.
> C:\Python38>dir
> Volume in drive C has no label.
> [snip]
> Note there is no python3.exe binary.
Y
On 3/24/20, Barry Scott wrote:
>
> If you have python 2 and 3 installed then
>
>py -3 myscript
"myscript" may have a shebang that runs the "python2" virtual command
(e.g. "#!python2" or "#!/usr/bin/python2") because the script requires
2.x, but using "-3" will override it to run the "python3"
On 2/24/20, jdve...@gmail.com wrote:
>
> I try to use along with -m (`python -I -m a.b`) and get this error: "python:
> Error while finding module specification for 'a.b' (ModuleNotFoundError: No
> module named 'a')".
This is a use case for -m that requires adding the working directory
to sys.pat
On 2/24/20, jdve...@gmail.com wrote:
>
> It is the intended and the expected behaviour. The working directory is
> always added to the sys.path.
You mean always in this particular context, i.e. the working directory
is added normally when executing a command via -c or a module as a
script via -m.
On 2/24/20, Guido van Rossum wrote:
>
> The stdlib does very little logging of its own -- logging is up to
> the application.
It's not logging per se, but the standard library does have an
extensive and growing list of audit events that are intended to assist
with testing, logging and security mo
On 1/14/20, Inada Naoki wrote:
>
> UTF-8 mode shouldn't take precedence over legacy FS encoding.
>
> Mercurial uses legacy encoding for file paths. They use
> sys._enablelegacywindowsfsencoding() on Windows.
> https://www.mercurial-scm.org/repo/hg/rev/8d5489b048b7
This runtime call can override
On 1/10/20, Andrew Barnert via Python-ideas wrote:
> On Jan 10, 2020, at 03:45, Inada Naoki wrote:
>
> Also, PYTHONUTF8 is only supported on Unix, so presumably it’s ignored if
> you set it on Windows, right?
The implementation of UTF-8 mode (i.e. -Xutf8) is cross-platform,
though I think it cou
On 7/10/19, Brendan Barnwell wrote:
>
> I agree that it seems the real problem here is the lack of a real way
> to determine if an available version is a real release or a
> prerelease/beta. Is it not possible to change that, so that it is
> possible for the launcher to quickly and easily d
On 7/9/19, Steve Barnes wrote:
>
> Currently the py[w] command will launch the latest python by default however
> I feel that this discourages the testing of pre-releases & release
> candidates as once they are installed they will become the default. What I
> would like is for the default to be th
On 5/14/19, Steven D'Aprano wrote:
>
> On posix systems, you should be able to use chattr +i to make the file
> immutable, so that the attacker cannot remove or replace it.
Minor point of clarification. File attributes, and APIs to access
them, are not in the POSIX standard. chattr is a Linux com
On 5/14/19, Serge Matveenko wrote:
>
> My point was that in case of `os.symlink` vs `shutil.symlink` it is
> not obvious how they are different even taking into account their
> namespaces.
I prefer to reserve POSIX system call names if possible, unless it's a
generic name such as "open" or "close
On 4/12/19, Giampaolo Rodola' wrote:
>
> As such I was thinking that perhaps it would be nice to provide 2 new
> cPython APIs:
>
> PyErr_SetFromErrnoWithMsg(PyObject *type, const char *msg)
> PyErr_SetFromWindowsErrWithMsg(int ierr, const char *msg)
> PyErr_SetExcFromWindowsErrWithMsg(PyObject *ty
On 3/24/19, Giampaolo Rodola' wrote:
> On Wed, Mar 20, 2019 at 11:19 PM eryk sun wrote:
>
>> This code repeatedly calls PsGetNextProcessThread to walk the
>> non-terminated threads of the process in creation order (based on a
>> linked list in the process object)
On 3/18/19, Giampaolo Rodola' wrote:
>
> I've been having these 2 implemented in psutil for a long time. On
> POSIX these are convenience functions using os.kill() + SIGSTOP /
> SIGCONT (the same as CTRL+Z / "fg"). On Windows they use
> undocumented NtSuspendProcess and NtResumeProcess Windows
>
On 2/1/19, Steven D'Aprano wrote:
> On Fri, Feb 01, 2019 at 07:21:47PM -0600, eryk sun wrote:
>
>> As soon as "pipe" is mentioned, anyone familiar with the REPL's
>> behavior with pipes should know that making this work will require the
>> -i c
On 2/1/19, Terry Reedy wrote:
> On 2/1/2019 3:31 PM, Oleg Broytman wrote:
>
>> Python REPL is missing the following batteries:
>> * Persistent history;
Python's built-in REPL relies on the readline module for history. In
Windows you'll need to install pyreadline, an implementation that uses
the W
On 2/1/19, Steven D'Aprano wrote:
> On Fri, Feb 01, 2019 at 04:28:25PM -0600, Dan Sommers wrote:
>
>> As I indicated in what you quoted, shell co-processes allow you to run a
>> command in the background and interact with that command from your
>> shell.
>
> Okay, but what does that mean in practi
On 12/25/18, Steven D'Aprano wrote:
> On Tue, Dec 25, 2018 at 04:51:18PM -0600, eryk sun wrote:
>>
>> Alternatively, we can memory-map the file via mmap. An important
>> difference is that the mmap buffer interface is low-level (e.g. no
>> file pointer and the of
On 12/24/18, Drew Warwick wrote:
> The struct unpack API is inconvenient to use with files. I must do:
>
> struct.unpack(fmt, file.read(struct.calcsize(fmt))
Alternatively, we can memory-map the file via mmap. An important
difference is that the mmap buffer interface is low-level (e.g. no
file po
On Sat, Mar 17, 2018 at 10:42 AM, George Fischhof wrote:
>
> All functions from os module accept path-like objects,
> and none of the shutil functions.
shutil indirectly supports __fspath__ paths via os and os.path. One
exception is shutil.disk_usage() on Windows, which only supports str
strings.
On Wed, Mar 14, 2018 at 12:18 PM, Facundo Batista
wrote:
>
> Note that there's no penalty in adding the '+' between the strings,
> those are resolved at compilation time.
The above statement is not true for versions prior to 3.7. Previously
the addition of string literals was optimized by the pee
On Thu, Oct 19, 2017 at 9:05 AM, Stephan Houben wrote:
>
> I (quickly) tried to get something to work using the win32 package,
> in particular the win32job functions.
> However, it seems setting
> "ProcessMemoryLimit" using win32job.SetInformationJobObject
> had no effect
> (i.e. a subsequent win
On Thu, Jun 1, 2017 at 4:46 PM, Chris Angelico wrote:
> (AIUI, the *current directory* is never on Python's path, but the
> *script directory* is. They're the same thing a lot of the time.)
sys.path includes the current directory (i.e. an empty string) when
there's no script, which includes the R
On Mon, Mar 27, 2017 at 8:52 PM, Barry wrote:
> I took to using
>
> chcp 65001
>
> This puts cmd.exe into unicode mode.
conhost.exe hosts the console, and chcp.com is a console app that
calls GetConsoleCP, SetConsoleCP and SetConsoleOutputCP to show or
modify the console's input and output c
On Tue, Feb 7, 2017 at 3:27 PM, Paul Moore wrote:
> On 7 February 2017 at 14:29, Steve Dower wrote:
>> You can leave python.exe out of your distribution to avoid it showing up on
>> PATH, or if your stub explicitly LoadLibrary's vcruntime140.dll and then
>> python36.dll you should be able to put
On Thu, Jan 26, 2017 at 10:49 PM, Paul Moore wrote:
> On 26 January 2017 at 22:32, M.-A. Lemburg wrote:
>> On 26.01.2017 23:09, Random832 wrote:
>>> On Thu, Jan 26, 2017, at 11:21, Paul Moore wrote:
On a similar note, I always get caught out by the fact that the
Windows default download
On Wed, Oct 26, 2016 at 10:16 PM, Cody Piersall wrote:
> Isn't that check really just an isatty() check? Or is that not
> reliable enough for some reason?
It's not reliable in Windows. There are no tty devices, so the C
runtime's implementation of isatty() instead returns true for
character devi
On Tue, Oct 4, 2016 at 2:22 PM, Random832 wrote:
> On Wed, Sep 28, 2016, at 23:36, Chris Angelico wrote:
>> On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano
>> wrote:
>> > (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows
>> > is Ctrl-Z + Return. Can that be standardized t
On Thu, Sep 29, 2016 at 7:12 AM, João Matos wrote:
> What is your Windows version? Are you trying on the cmd.exe console or PS?
Are you talking about PowerShell ISE? That doesn't work for
interactive console programs such as Python's REPL shell.
Otherwise, FYI, there is no such thing as a cmd.ex
On Thu, Sep 29, 2016 at 7:08 AM, Stephan Houben wrote:
>
> I just tried with this official Python binary:
> Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit
> (Intel)] on win32
>
> and CTRL-L for sure does clear the window. It just doesn't then move the
> prompt to the
On Mon, Sep 19, 2016 at 3:07 PM, Oleg Broytman wrote:
>[Ctrl+D] also recognized as EOF only at the start of an input.
You're right. I was mixing it up with sys.stdin.buffer.raw.read(), for
which Ctrl+D can end the read anywhere if entered twice. Having to
enter it twice may be a bug, because
On Mon, Sep 19, 2016 at 1:12 PM, Paul Moore wrote:
> By the way - if you're on a system with readline support included with
> Python, GNU readline apparently has a binding for clear-screen
> (CTRL-L) so you may well have this functionality already (I don;'t use
> Unix or readline, so I can't comme
On Sat, Sep 17, 2016 at 1:15 PM, Wes Turner wrote:
> !cls #windows
cmd's built-in cls command doesn't clear just the screen, like a VT100
\x1b[1J. It clears the console's entire scrollback buffer. Unix
`clear` may also work like that. With GNOME Terminal in Linux, `clear`
leaves a single screen
On Sat, Sep 17, 2016 at 11:11 AM, João Matos wrote:
>On 17-09-2016 12:07, Oleg Broytman wrote:
>>
>> Pressing [Ctrl]+[L] works for me.
>
> Doesn't work on Windows.
Windows 10 added VT100 support to the console, so you can create a
little cls() function to clear the screen:
cls = lambda:
On Thu, Aug 25, 2016 at 2:29 AM, Nick Jacobson via Python-ideas
wrote:
> I've been finding that a common scenario is where I want to remove
> everything in a directory, but leave the (empty) root directory behind, not
> removing it.
>
> So for example, if I have a directory C:\foo and it contains
On Sun, Aug 21, 2016 at 6:53 AM, Michael Selik wrote:
> For that to make sense, Iterable should be a parent of C, or C should be a
> subclass of something registered as an Iterable. Otherwise it'd be creating
> a general recommendation to say ``__iter__ = None`` on every non-Iterable
> class, whic
On Sun, Aug 21, 2016 at 6:34 AM, Michael Selik wrote:
> The detection of not hashable via __hash__ set to None was necessary, but
> not desirable. Better to have never defined the method/attribute in the
> first place. Since __iter__ isn't present on ``object``, we're free to use
> the better tech
On Sun, Aug 21, 2016 at 5:27 AM, Chris Angelico wrote:
> Hmm. It would somehow need to be recognized as "not iterable". I'm not
> sure how this detection is done; is it based on the presence/absence
> of __iter__, or is it by calling that method and seeing what comes
> back? If the latter, then su
On Thu, Aug 18, 2016 at 3:25 PM, Steve Dower wrote:
> allow us to change locale.getpreferredencoding() to utf-8 on Windows
_bootlocale.getpreferredencoding would need to be hard coded to return
'utf-8' on Windows. _locale._getdefaultlocale() itself shouldn't
return 'utf-8' as the encoding because
On Thu, Aug 18, 2016 at 4:44 PM, Chris Angelico wrote:
> On Fri, Aug 19, 2016 at 2:39 AM, eryk sun wrote:
>> They're all just characters in the context of Unicode, so I think it's
>> clearest to use the character code, e.g.:
>>
>> The second call to g
On Thu, Aug 18, 2016 at 4:07 PM, Steve Dower wrote:
> On 18Aug2016 0900, Chris Angelico wrote:
>>
>> On Fri, Aug 19, 2016 at 1:54 AM, Steve Dower
>> wrote:
>>>
>>> On 18Aug2016 0829, Chris Angelico wrote:
The second call to glob doesn't have any Unicode characters at all,
the
On Thu, Aug 18, 2016 at 2:32 AM, Stephen J. Turnbull
wrote:
>
> So it's not just invalid surrogate *pairs*, it's invalid surrogates of
> all kinds. This means that it's theoretically possible (though I
> gather that it's unlikely in the extreme) for a real Windows filename
> to indistinguishable
On Wed, Aug 17, 2016 at 9:35 AM, Stephen J. Turnbull
wrote:
> BTW, why "surrogate pairs"? Does Windows validate surrogates to
> ensure they come in pairs, but not necessarily in the right order (or
> perhaps sometimes they resolve to non-characters such as U+1)?
A program can pass the filesy
On Tue, Aug 16, 2016 at 3:56 PM, Steve Dower wrote:
>
> 2. Windows file system encoding is *always* UTF-16. There's no "assuming
> mbcs" or "assuming ACP" or "assuming UTF-8" or "asking the OS what encoding
> it is". We know exactly what the encoding is on every supported version of
> Windows. UTF
On Tue, Aug 16, 2016 at 10:53 AM, Paul Moore wrote:
>
> Having said all this, I can't find the documentation stating that
> bytes paths are deprecated - the open() documentation for 3.5 says
> "file is either a string or bytes object giving the pathname (absolute
> or relative to the current worki
>> On Mon, Aug 15, 2016 at 6:26 PM, Steve Dower
>> wrote:
>
> and using the *W APIs exclusively is the right way to go.
My proposal was to use the wide-character APIs, but transcoding CP_ACP
without best-fit characters and raising a warning whenever the default
character is used (e.g. substitutin
1 - 100 of 108 matches
Mail list logo
