Python Editor for mobile

[CrazyVideoGamez]

Are there any good editors on Apple that don't cost money and already has 
matplotlib, numpy, and other modules already installed?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Sat, 31 Aug 2019 09:11:22 +1000, Cameron Simpson wrote:

>   '\r' + progress_status
> 
> which backs up to the start of the line, writes the status, and leaves
> the cursor at the end.
> 
> The latter has the advantage that any subsequent output (egthe shell
> prompt after the programmke exits) will not overwrite the status string.

Thanks a lot for your revision, it makes the status more clear on using 
this trick.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Fri, 30 Aug 2019 10:25:10 -0600, Michael Torrie wrote:

> No it is not. What kind of terminal are you using?

I use Debian 9 with gnome desktop and the default gnome terminal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Cameron Simpson]

On 31Aug2019 08:57, Cameron Simpson  wrote:

On 30Aug2019 10:25, Michael Torrie  wrote:

On Fri, Aug 30, 2019, 05:02 Hongyi Zhao 
On Fri, 30 Aug 2019 17:53:02 +1000, Chris Angelico wrote:

(Also, why the sleep? Seems unnecessary.)


Because without using sleep, the stuff on screen will display very
shortly and then disappear.  Is this not your testing result?


No it is not. What kind of terminal are you using?


Note that testing this stuff in a regular terminal will us the \r 
version. Which leaves the cursor at the left end of the progress 
display. Where it will be overwritten by your prompt, depending on the 
shell.


So what he describes is entirely possible on UNIX.


And just further to this. It is more common to write his one-line update 
not as:


 progress_status+'\r'

as he has it, which leaves the cursor at the left ready to overwrite 
things, but as:


 '\r' + progress_status

which backs up to the start of the line, writes the status, and leaves 
the cursor at the end.


The latter has the advantage that any subsequent output (egthe shell 
prompt after the programmke exits) will not overwrite the status string.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Sat, Aug 31, 2019 at 8:58 AM Eryk Sun  wrote:
>
> On 8/30/19, Chris Angelico  wrote:
> > On Sat, Aug 31, 2019 at 7:42 AM Eryk Sun  wrote:
> >
> >> In Windows 8+, a process attaches to a console by opening
> >> "\Device\ConDrv\Connect" as a connection to an instance of the console
> >> host process, conhost.exe. This handle is stored internally as
> >> "ConsoleHandle" (in its PEB->ProcessParameters). The console API uses
> >> this handle for functions that don't operate on a stream, such as
> >> GetConsoleTitle.
> >> [chomp more details]
> >
> > Huh. I kinda just assumed that, since cmd.exe was still running, the
> > console would continue to be in use. I guess technically it's a lot
> > more complicated than that, but still, to the average user, the
> > difference won't be visible.
>
> I was just clarifying the implementation details of what kind of
> reference is used to keep a console alive in Windows 8+. To me the
> details are useful to flesh out a picture of how things work, so that
> I know what to look for when they fail to work. For the average user
> and average use case, all that we need to know is that at least one
> process has to be attached to the console to keep it alive.

Yes, and I appreciate the info from the perspective of curiosity! Even
though it won't make a difference most of the time, it's still cool to
know.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Cameron Simpson]

On 30Aug2019 10:25, Michael Torrie  wrote:

On Fri, Aug 30, 2019, 05:02 Hongyi Zhao 
On Fri, 30 Aug 2019 17:53:02 +1000, Chris Angelico wrote:
> (Also, why the sleep? Seems unnecessary.)

Because without using sleep, the stuff on screen will display very
shortly and then disappear.  Is this not your testing result?


No it is not. What kind of terminal are you using?


Note that testing this stuff in a regular terminal will us the \r 
version. Which leaves the cursor at the left end of the progress 
display. Where it will be overwritten by your prompt, depending on the 
shell.


So what he describes is entirely possible on UNIX.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Eryk Sun]

On 8/30/19, Chris Angelico  wrote:
> On Sat, Aug 31, 2019 at 7:42 AM Eryk Sun  wrote:
>
>> In Windows 8+, a process attaches to a console by opening
>> "\Device\ConDrv\Connect" as a connection to an instance of the console
>> host process, conhost.exe. This handle is stored internally as
>> "ConsoleHandle" (in its PEB->ProcessParameters). The console API uses
>> this handle for functions that don't operate on a stream, such as
>> GetConsoleTitle.
>> [chomp more details]
>
> Huh. I kinda just assumed that, since cmd.exe was still running, the
> console would continue to be in use. I guess technically it's a lot
> more complicated than that, but still, to the average user, the
> difference won't be visible.

I was just clarifying the implementation details of what kind of
reference is used to keep a console alive in Windows 8+. To me the
details are useful to flesh out a picture of how things work, so that
I know what to look for when they fail to work. For the average user
and average use case, all that we need to know is that at least one
process has to be attached to the console to keep it alive.

> And that's why the pseudo-tty system is vital to making things make
> sense. On Unix-like platforms, a tool like ssh can connect a program
> to something that it perceives as a TTY, and then take the contents
> elsewhere. It's a consistent system that works with any program.

Windows 10 has pseudoconsole support. I think the new Windows terminal
that's available in preview builds is based on this, but I haven't
experimented with it yet. Note that the console host process
(conhost.exe) is still in the loop. It works in this case as a
headless subsystem server (i.e. it doesn't create a window) that sits
in between the application and the terminal. The application<->ConHost
interface is still mediated in the kernel via the ConDrv console
device. But ConDrv is kept relatively simple. Most of the console
subsystem is implemented in the user-mode ConHost server process (in
coordination with the session subsystem process, CSRSS). The terminal
communicates with ConHost using a pair of pipes for I/O that stream
UTF-8 text with inline virtual-terminal sequences.

> Oh, and, well, GNU Readline is just a smidge better than the default
> Windows line editing, too...

There's pyreadline in Windows, which uses ctypes to access the console
at a low level in order to emulate GNU Readline. PowerShell has a
similar PSRreadline library that's enabled by default. It can be
configured to use Emacs or Vi mode, but it defaults to Windows mode,
which emulates the console's builtin line editing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pandas loc on str lower for column comparison

[Piet van Oostrum]

Sayth Renshaw  writes:

>
> I have tried both
>
> df1 = df.loc[:, ('UID','Name','New Leader','Current Team', 'New Team')] 
> df1['Difference'] = df1.loc['Current Team'].str.lower().str.strip() ==
> df1.loc['New Team'].str.lower().str.strip()
>
> and 
>
> df1 = df[['UID','Name','New Leader','Current Team', 'New Team']].copy()
> df1['Difference'] = df1.loc['Current Team'].str.lower().str.strip() ==
> df1.loc['New Team'].str.lower().str.strip()
>
> But on both occasions I receive this error.
>
> # KeyError: 'the label [Current Team] is not in the [index]'
>
> if I test df1 before trying to create the new column it works just fine.
>
> Sayth

What does df1.info() produce?
Which versions of numpy, scipy and pandas are you using?

It would be helpful if you could make a copy of the original .xlsx file 
available.
-- 
Piet van Oostrum 
WWW: http://piet.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Sat, Aug 31, 2019 at 7:42 AM Eryk Sun  wrote:
>
> On 8/30/19, Chris Angelico  wrote:
> > On Sat, Aug 31, 2019 at 5:40 AM Eryk Sun  wrote:
> >
> >> Or simply run python.exe from another console process that keeps the
> >> console alive (it's reference counted), which is typically cmd.exe or
> >> powershell.exe.
> >
> > Not sure what you mean by "reference counted"
>
> In Windows 8+, a process attaches to a console by opening
> "\Device\ConDrv\Connect" as a connection to an instance of the console
> host process, conhost.exe. This handle is stored internally as
> "ConsoleHandle" (in its PEB->ProcessParameters). The console API uses
> this handle for functions that don't operate on a stream, such as
> GetConsoleTitle.
> [chomp more details]

Huh. I kinda just assumed that, since cmd.exe was still running, the
console would continue to be in use. I guess technically it's a lot
more complicated than that, but still, to the average user, the
difference won't be visible.

> > Of course, most of us use a shell that's a tad more powerful than
> > cmd.exe, but the effect is the same regardless.
>
> Yes, CMD is not a great shell, and PowerShell is tedious (IMO). We can
> use bash.exe from MSYS2 or Git instead. But stick to the normal
> console interface (i.e. run bash.exe directly), or use winpty if you
> need to run Windows Python. The MSYS2 terminal interface (mintty) is
> based on named pipes. Its build of Python special cases these pipes,
> but they're just pipes to the Windows build, so isatty() is false and
> it defaults to full buffering. Also, the REPL of the Windows build
> depends on the system console for line editing and history, so even if
> we force interactive mode via `python -i`, the UI is horrible without
> a console.

And that's why the pseudo-tty system is vital to making things make
sense. On Unix-like platforms, a tool like ssh can connect a program
to something that it perceives as a TTY, and then take the contents
elsewhere. It's a consistent system that works with any program.

Oh, and, well, GNU Readline is just a smidge better than the default
Windows line editing, too...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Eryk Sun]

On 8/30/19, Chris Angelico  wrote:
> On Sat, Aug 31, 2019 at 5:40 AM Eryk Sun  wrote:
>
>> Or simply run python.exe from another console process that keeps the
>> console alive (it's reference counted), which is typically cmd.exe or
>> powershell.exe.
>
> Not sure what you mean by "reference counted"

In Windows 8+, a process attaches to a console by opening
"\Device\ConDrv\Connect" as a connection to an instance of the console
host process, conhost.exe. This handle is stored internally as
"ConsoleHandle" (in its PEB->ProcessParameters). The console API uses
this handle for functions that don't operate on a stream, such as
GetConsoleTitle.

Every open instance of this "Connect" file that connects a process to
a console is a reference on the console that keeps it alive. And every
handle for a kernel File object is a counted reference on the object.
Thus if we call DuplicateHandle to duplicate the connection handle to
another process that's not technically 'attached' to the console, then
even if we close all processes attached to the console, the console
will not be destroyed until the duplicate handle for the connection is
closed.

Other console files that have this property are "CON" (i.e.
"\Device\ConDrv\Console"), "CONIN$" (i.e. "\Device\ConDrv\CurrentIn")
and "CONOUT$" (i.e. "\Device\ConDrv\CurrentOut"). When opened, these
files reference the active input or output stream of the currently
attached console, and they keep the console alive. However, they only
work for I/O when we're attached to the referenced console, so this
property isn't really useful. Attaching to a console via WINAPI
AttachConsole requires the PID of a process that's already attached to
the console (and thus keeping it alive).

On the other hand, by default a console process starts with its
StandardInput handle set to a generic console input file (i.e.
"\Device\ConDrv\Input") and its StandardOutput and StandardError
handles set to a generic console output file (i.e.
"\Device\ConDrv\Output"). These generic files work with any console
connection, and they do not keep a console alive.

The implementation details of the console are completely different
prior to Windows 8, and not all behaviors are consistent with the
above description. But Windows 7 is almost at end of life.

> Of course, most of us use a shell that's a tad more powerful than
> cmd.exe, but the effect is the same regardless.

Yes, CMD is not a great shell, and PowerShell is tedious (IMO). We can
use bash.exe from MSYS2 or Git instead. But stick to the normal
console interface (i.e. run bash.exe directly), or use winpty if you
need to run Windows Python. The MSYS2 terminal interface (mintty) is
based on named pipes. Its build of Python special cases these pipes,
but they're just pipes to the Windows build, so isatty() is false and
it defaults to full buffering. Also, the REPL of the Windows build
depends on the system console for line editing and history, so even if
we force interactive mode via `python -i`, the UI is horrible without
a console.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: multiple lines in one line

[DL Neil]

On 31/08/19 8:26 AM, tascioglu.ta...@gmail.com wrote:

Hello,I working on some file operations with python.I have 2 text file which is 
consist of lines such as apple_pie 0.3434 0.6767 0.2312 and other text file has 
apple 0.2334 0.3412 0.123
pie 0.976 0.75654 0.2312
I want to append lines like apple_pie 0.3434 0.6767 0.2312 0.2334 0.3412 
0.123(values for apple) 0.976 0.75654 0.2312(values for pie) in one line. does 
anybody know how to do it ?Thanks...



This is a very broad question. Is it a homework assignment?


First find a consistent relationship between the three words: 
"apple_pie", "apple", and "pie" - is the first always a combination of 
the others? ... always separated by an under-score/under-line? ...always 
in the same sequence of words?


Are the two files sorted in a 1:1 relationship, ie so that the 
nth-record from one 'matches' the nth-record from the other - or is 
record-matching part of the problem?



To solve any ComSc problem think about how it can be split into 
sub-problems. The analogy that is often used, talks about peeling-back 
the successive layers of an onion. Reduce the size of the problem being 
considered, until each sub-problem is small-enough for you to 
(understand how to) solve.


Below, are several functions addressing possible sub-problems. Solving 
one sub-problem can then feed its 'answer' into solving a 'larger' 
problem...



Possibly useful functions:

- take a string and split it into 'first word' and 'rest of line'

- take a two-word string and split it into the two separate words

- take a two-part record and given the two independent words, split it, 
and return its two components


(plus, building sub-problem solutions as Python functions enables us to 
thoroughly test each function separately - to ensure it 'does the job', 
before moving-on to the next, ie before things become ever-more complex 
and testing 'the whole thing' reveals an error without giving ideas as 
to 'when/where' things went-wrong!)



If you come back to us, please add more data examples (otherwise the 
answer becomes: find( "apple" )!), plus sample code showing the progress 
you've made to-date...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

multiple lines in one line

[tascioglu . tansu]

Hello,I working on some file operations with python.I have 2 text file which is 
consist of lines such as apple_pie 0.3434 0.6767 0.2312 and other text file has 
apple 0.2334 0.3412 0.123
pie 0.976 0.75654 0.2312
I want to append lines like apple_pie 0.3434 0.6767 0.2312 0.2334 0.3412 
0.123(values for apple) 0.976 0.75654 0.2312(values for pie) in one line. does 
anybody know how to do it ?Thanks...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Sat, Aug 31, 2019 at 5:40 AM Eryk Sun  wrote:
>
> On 8/30/19, Chris Angelico  wrote:
> > On Sat, Aug 31, 2019 at 2:26 AM Michael Torrie  wrote:
> >> On Fri, Aug 30, 2019, 05:02 Hongyi Zhao  >>
> >>> Because without using sleep, the stuff on screen will display very
> >>> shortly and then disappear.  Is this not your testing result?
> >>
> >> No it is not. What kind of terminal are you using?
> >
> > Probably a Windows computer and just double-clicking on the program to
> > make it do stuff.
> >
> > Recommendation: If that's the case, get an actual terminal. Learn to use
> > it.
>
> Or simply run python.exe from another console process that keeps the
> console alive (it's reference counted), which is typically cmd.exe or
> powershell.exe.

Not sure what you mean by "reference counted", but yes, if you start
python.exe as a child of some shell such as cmd.exe, then the terminal
that cmd.exe is running in will remain. That is the most normal way to
do things.

Of course, most of us use a shell that's a tad more powerful than
cmd.exe, but the effect is the same regardless.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Eryk Sun]

On 8/30/19, Chris Angelico  wrote:
> On Sat, Aug 31, 2019 at 2:26 AM Michael Torrie  wrote:
>> On Fri, Aug 30, 2019, 05:02 Hongyi Zhao >
>>> Because without using sleep, the stuff on screen will display very
>>> shortly and then disappear.  Is this not your testing result?
>>
>> No it is not. What kind of terminal are you using?
>
> Probably a Windows computer and just double-clicking on the program to
> make it do stuff.
>
> Recommendation: If that's the case, get an actual terminal. Learn to use
> it.

Or simply run python.exe from another console process that keeps the
console alive (it's reference counted), which is typically cmd.exe or
powershell.exe. Or have the script spawn a process that keeps the
console alive (e.g. subprocess.Popen('cmd')). Or configure .py files
to use the py.exe launcher and change the shebang to `#!python3 -i`
when testing a script, which runs the REPL after the script
terminates.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Terry Reedy]

Eric, thank you for the detailed answer.  I stashed it away for future 
review ;-).


On 8/30/2019 3:10 AM, Eryk Sun wrote:

On 8/29/19, Terry Reedy  wrote:

On 8/29/2019 10:16 AM, Eryk Sun wrote:


In Windows, isatty() is true for any character-type file.


Does that mean one that can either send or receive data a character at a
time, as opposed to a block at a time?


Yes, any number of bytes can be written to a character device, whereas
a block device will require some fixed number of bytes such as a
512-byte disk sector.

WINAPI GetFileType classifies files for all of the following NT device
types as FILE_TYPE_CHAR (akin to Unix S_IFCHR):

 FILE_DEVICE_CONSOLE
 FILE_DEVICE_NULL
 FILE_DEVICE_SERIAL_PORT
 FILE_DEVICE_PARALLEL_PORT
 FILE_DEVICE_KEYBOARD
 FILE_DEVICE_MOUSE
 FILE_DEVICE_MODEM
 FILE_DEVICE_PRINTER
 FILE_DEVICE_SCREEN
 FILE_DEVICE_SOUND

FILE_DEVICE_CONSOLE is for the ConDrv console device, which was added
in Windows 8. In previous versions, GetFileType special cases console
pseudohandles.

GetFileType classifies files for all of the following NT device types
as FILE_TYPE_DISK (akin to Unix S_IFBLK):

 FILE_DEVICE_DISK
 FILE_DEVICE_VIRTUAL_DISK
 FILE_DEVICE_CD_ROM
 FILE_DEVICE_DISK_FILE_SYSTEM
 FILE_DEVICE_CD_ROM_FILE_SYSTEM
 FILE_DEVICE_DFS
 FILE_DEVICE_DATALINK
 FILE_DEVICE_CONTROLLER


Aha.  So this is why
https://pubs.opengroup.org/onlinepubs/009695399/functions/isatty.html
follows the doc for isatty, which says 'associated with a terminal
device', with an information section that contradicts that with
"The isatty() function does not necessarily indicate that a human being
is available for interaction via fildes. It is quite possible that
non-terminal devices are connected to the communications line."


As far as I know, only the Windows CRT classifies any character device
as a TTY. Linux doesn't. "/dev/null" is a character device, but not a
TTY.

I think the CRT's _isatty implementation is wrong, though I'm not
certain what the right answer looks like. Windows doesn't have any
notion of a tty/pty terminal. I suppose it can just check for a
console. For older versions of Windows that would be based on checking
for a console pseudohandle. In Windows 8+, we can query
NtQueryVolumeInformationFile: FileFsDeviceInformation to check for
FILE_DEVICE_CONSOLE. (It would be useful if they exposed this in the
Windows API, maybe as GetVolumeInformationByHandleEx, like what they
did for GetFileInformationByHandleEx.)


What makes a pipe on Windows not a character file?  Is data sent between
processes a block at a time?  Are posix pipes different?


FILE_TYPE_PIPE (akin to Unix S_IFIFO) is a type that accesses a
section of shared memory that's used as an inter-process communication
channel. Requesting a read on an empty pipe blocks until at least one
byte is available. Requesting a write on a pipe blocks until there's
available space for the write to complete, which may require multiple
reads at the other end. (Note that Windows also classifies sockets as
'pipes', but Unix has a dedicated S_IFSOCK type for sockets.)

A pipe channel can be inbound (client-write, server-read), outbound
(server-write, client-read), or duplex (read-write on both ends).
Anonymous pipes are in duplex mode but they're opened with access on
each end that makes them effectively inbound mode. Windows also
supports message-mode pipes, which handles each write as a message. A
message-mode pipe can be configured to be read in either byte mode or
message mode. (Pipes in most Unix systems do not support duplex and
message modes.)

In principle, a pipe can be used as the IPC channel for an interactive
terminal. For example, MSYS2 does this with specially named pipes that
its isatty() function special cases as a TTYs. But in general we
expect pipes to be non-interactive, and for performance we default to
full buffering with pipes instead of line buffering. Full buffering is
incompatible with interactive usage.


I don't understand the following.
---
C:\Users\Terry>python -c "print('hello\n') | python
hello

Traceback (most recent call last):
File "", line 1, in 
NameError: name 'python' is not defined


The command line is missing the closing double quote around
"print('hello\n')". In this case, CMD acts as if the whole statement
is quoted, so the vertical bar is not interpreted as a pipe to a
`python` command. Let's print the command line for the python.exe
process in order to demonstrate this:

 C:\>python -c "import win32api;print(win32api.GetCommandLine()) | python
 python  -c "import win32api;print(win32api.GetCommandLine()) | python
 Traceback (most recent call last):
   File "", line 1, in 
 NameError: name 'python' is not defined




--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Sat, Aug 31, 2019 at 2:26 AM Michael Torrie  wrote:
>
> On Fri, Aug 30, 2019, 05:02 Hongyi Zhao 
> > On Fri, 30 Aug 2019 17:53:02 +1000, Chris Angelico wrote:
> > > (Also, why the sleep? Seems unnecessary.)
> >
> > Because without using sleep, the stuff on screen will display very
> > shortly and then disappear.  Is this not your testing result?
>
>
> No it is not. What kind of terminal are you using?

Probably a Windows computer and just double-clicking on the program to
make it do stuff.

Recommendation: If that's the case, get an actual terminal. Learn to use it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Chris Angelico]

On Sat, Aug 31, 2019 at 2:19 AM Cristian Cocos  wrote:
>
> Thank you! Will give the "types" module a whirl.
>
> Otherwise, the whole idea behind building a rigorous taxonomical hierarchy
> ("taxonomy") is to provide a simpler management of the wealth of features
> objects have. And that is because entities belonging to the same
> taxonomical class ("clade") have common features, and also inherit the
> features of the taxonomical parent. A kosher type hierarchy (or class
> taxonomy) is thus meant to answer precisely your concern about
> entity/object behavior. Now, it may be that this was not the intention of
> Python developers when they came up with the breakdown of the class of
> objects into types/classes, in which case the term "type" and derivatives
> (subtype, supertype etc.) used in this context is nothing but a regrettable
> misnomer. Then maybe I should re-direct my quest away from studying the
> type hierarchy, toward asking for built-in-object inheritance: Is there a
> diagram of built-in-object inheritance available anywhere?
>

Even in biology, taxonomy has its limitations. For instance, you might
assert that all birds can fly, and therefore that all members of a
subclass of birds can fly; but the Emu would like to have a word with
you. Or you might posit that all mammals give birth to live young, but
then Platypus would give you a taste of its spur. [1]

In software design, the same kinds of exceptions do occur. By and
large, principles like "anywhere that you could use the superclass,
you can equivalently use a subclass of it" will hold true, but there
are good reasons to go against them sometimes. So if you're looking
for absolute hard-and-fast taxonomic rules about Python types, you
won't find them... but you CAN expect things to generally follow rules
like LSP. That means that, for instance, any operation valid on an
instance of the vanilla 'object' type can be done on literally any
object in Python, and anything you can do with the 'type' type can be
done with any Python class. Notably, since "type" is a subclass of
"object", this means that you can manipulate types the same way that
you manipulate anything else.

As to a diagram of built-in objects... this might be of some help:

https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

It's not fully comprehensive, but it hopefully will have some useful
information. Another neat trick is that all types have a
__subclasses__() method, so you can sometimes build up your hierarchy
that way:

>>> LookupError.__subclasses__()
[, , ]

Start from 'object' and delve from there. And when you hit 'type' in
your exploration, you'll learn something about re-entrant hierarchies
and how descriptors work :)

ChrisA

[1] One valid counter-argument here is that Australia is just plain
weird. I've lived here all my life, and it's certainly true.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Michael Torrie]

On Fri, Aug 30, 2019, 05:02 Hongyi Zhao  On Fri, 30 Aug 2019 17:53:02 +1000, Chris Angelico wrote:
> > (Also, why the sleep? Seems unnecessary.)
>
> Because without using sleep, the stuff on screen will display very
> shortly and then disappear.  Is this not your testing result?


No it is not. What kind of terminal are you using?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Cristian Cocos]

Thank you! Will give the "types" module a whirl.

Otherwise, the whole idea behind building a rigorous taxonomical hierarchy
("taxonomy") is to provide a simpler management of the wealth of features
objects have. And that is because entities belonging to the same
taxonomical class ("clade") have common features, and also inherit the
features of the taxonomical parent. A kosher type hierarchy (or class
taxonomy) is thus meant to answer precisely your concern about
entity/object behavior. Now, it may be that this was not the intention of
Python developers when they came up with the breakdown of the class of
objects into types/classes, in which case the term "type" and derivatives
(subtype, supertype etc.) used in this context is nothing but a regrettable
misnomer. Then maybe I should re-direct my quest away from studying the
type hierarchy, toward asking for built-in-object inheritance: Is there a
diagram of built-in-object inheritance available anywhere?

Many thanks for the clarifications,

C

On Fri, Aug 30, 2019 at 3:47 AM Gregory Ewing 
wrote:

> Cristian Cocos wrote:
>
> type(print)
> >
> > 
> >
> isinstance(print, builtin_function_or_method)
> >
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > NameError: name 'builtin_function_or_method' is not defined
> >
> > Just curious why builtin_function_or_method doesn't work as an argument
> of
> > isinstance().
>
> Because the type object in question is not bound to the name
> 'builtin_function_or_method' in the builtin namespace. There
> is a way to get at it, though:
>
>  >>> import types
>  >>> types.BuiltinFunctionType
> 
>  >>> isinstance(print, types.BuiltinFunctionType)
> True
>
> When it comes to objects that form part of the interpreter's
> internal machinery, the names shown when you print their types
> are often just suggestive and aren't meant to be taken literally.
> Most of them are available in the 'types' module, however,
> possibly under different names. The reasons for all this are
> buried in a lot of messy history.
>
> > The bottom line is that I am trying to figure out where exactly the world
> > of Python types _diverges from_ what I would expect as a mathematician.
> It
> > makes it easier for me to learn Python this way.
>
> I'm not sure that focusing on classes as mathematical sets is all
> that useful. In Python, what class an object belongs to isn't
> usually very important. Much more relevant is how the object
> *behaves*. We call this "duck typing" -- if it walks like a duck
> and quacks like a duck then it might as well be a duck, even if
> it doesn't belong to a class called "Duck".
>
> This is why Python doesn't have e.g. an elaborate tower of
> numeric types as is seen in some other languages. It just isn't
> necessary for getting things done, and Python, being a very
> pragmatic language, is all about getting things done.
>
> --
> Greg
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
"People think that I must be a very strange person. This is not correct. I
have the heart of a small boy. It is in a glass jar on my desk." -- Stephen
King
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Fri, 30 Aug 2019 18:42:51 +1000, Chris Angelico wrote:

> There is no magic here. It is simply asking a question, and then making
> a decision based on the answer.

What's your mean by saying this?  Sorry for my poor English.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Fri, 30 Aug 2019 17:53:02 +1000, Chris Angelico wrote:

> That's because sys.stderr is never changing in your example here. Try
> checking whether sys.stdout is a TTY instead.

OMG, thanks a lot, this does the trick.

> 
> (Also, why the sleep? Seems unnecessary.)

Because without using sleep, the stuff on screen will display very 
shortly and then disappear.  Is this not your testing result? 

-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] ACTION REQUIRED: Python 3.8.0b4 now available for testing

[Łukasz Langa]

It's time for the last beta release of Python 3.8. Go find it at:

https://www.python.org/downloads/release/python-380b4/ 



This release is the last of four planned beta release previews. Beta release 
previews are intended to give the wider community the opportunity to test new 
features and bug fixes and to prepare their projects to support the new feature 
release. The next pre-release of Python 3.8 will be 3.8.0c1, the first release 
candidate, currently scheduled for 2019-09-30.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.8 during the beta phase and report issues found to the Python bug tracker as 
soon as possible. Please note this is the last beta release, there is not much 
time left to identify and fix issues before the release of 3.8.0. If you were 
hesitating trying it out before, now is the time.

While the release is planned to be feature complete entering the beta phase, it 
is possible that features may be modified or, in rare cases, deleted up until 
the start of the release candidate phase (2019-09-30). Our goal is have no ABI 
changes after beta 3 and no code changes after 3.8.0c1, the release candidate.

To achieve that, it will be extremely important to get as much exposure for 3.8 
as possible during the beta phase. That beta phase is coming to an end. Please 
test now.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

Acknowledgments

Many developers worked hard for the past four weeks to squash remaining bugs, 
some requiring non-obvious decisions. Many thanks to the most active, namely 
Raymond Hettinger, Steve Dower, Victor Stinner, Terry Jan Reedy, Serhiy 
Storchaka, Pablo Galindo Salgado, Tal Einat, Zackery Spytz, Ronald Oussoren, 
Neil Schemenauer, Inada Naoki, Christian Heimes, and Andrew Svetlov.

3.8.0 would not reach the Last Beta without you. Thank you!


- Ł


signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Fri, Aug 30, 2019 at 6:36 PM Hongyi Zhao  wrote:
>
> On Thu, 29 Aug 2019 16:42:44 +0100, Rhodri James wrote:
>
> > I don't understand what's to not to understand.
> >
> >if condition:
> >  do_something_because_condition_is_true()
> >else:
> >  do_something_because_condition_is_false()
> >
> > is a perfectly normal construction.  If you mean something else, please
> > be explicit.
>
> I've read some more thing on the python 3 's print, seems for the isatty
> () discussed here is completely can done with using it by something like:
>
> print(p, end='\r', flush=True)
>

No, it can't. That will still do the same thing whether you're
outputting to a file or a console. The whole point of isatty() is to
log *differently* in those cases.

There is no magic here. It is simply asking a question, and then
making a decision based on the answer.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Thu, 29 Aug 2019 16:42:44 +0100, Rhodri James wrote:

> I don't understand what's to not to understand.
> 
>if condition:
>  do_something_because_condition_is_true()
>else:
>  do_something_because_condition_is_false()
> 
> is a perfectly normal construction.  If you mean something else, please
> be explicit.

I've read some more thing on the python 3 's print, seems for the isatty
() discussed here is completely can done with using it by something like:

print(p, end='\r', flush=True)

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Chris Angelico]

On Fri, Aug 30, 2019 at 5:51 PM Hongyi Zhao  wrote:
>
> On Fri, 30 Aug 2019 01:29:48 +0200, Peter Otten wrote:
>
> > Perhaps a simple example can help?
> >
> > $ cat checktty.py import sys
> >
> > stream = sys.stdout
> >
> > if stream.isatty():
> > message = "tty"
> > else:
> > message = "no tty"
> > print(message, file=stream)
> >
> > When you run the script it prints to the terminal:
> >
> > $ python3 checktty.py tty
> >
> > But when you redirect to a pipe or into a file:
> >
> > $ python3 checktty.py | cat no tty
> >
> > $ python3 checktty.py > tmp.txt $ cat tmp.txt no tty
>
>
> But, see my example:
>
> $ cat check-isatty.py
> import sys
> import time
>
> if sys.stderr.isatty():
> p = 'tty ' + '\r'
> else:
> p = 'no tty ' + '\n'
>
> sys.stderr.write(p)
> sys.stderr.flush()
> time.sleep(1.0)
>
>
> I run both of the following commands:
>
> $ python check-isatty.py
> $ python check-isatty.py | cat
>
> Both will output `tty'.  So still I cannot figure out the issue.
>

That's because sys.stderr is never changing in your example here. Try
checking whether sys.stdout is a TTY instead.

(Also, why the sleep? Seems unnecessary.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Hongyi Zhao]

On Fri, 30 Aug 2019 01:29:48 +0200, Peter Otten wrote:

> Perhaps a simple example can help?
> 
> $ cat checktty.py import sys
> 
> stream = sys.stdout
> 
> if stream.isatty():
> message = "tty"
> else:
> message = "no tty"
> print(message, file=stream)
> 
> When you run the script it prints to the terminal:
> 
> $ python3 checktty.py tty
> 
> But when you redirect to a pipe or into a file:
> 
> $ python3 checktty.py | cat no tty
> 
> $ python3 checktty.py > tmp.txt $ cat tmp.txt no tty


But, see my example:

$ cat check-isatty.py 
import sys
import time

if sys.stderr.isatty():
p = 'tty ' + '\r'
else:
p = 'no tty ' + '\n'

sys.stderr.write(p)
sys.stderr.flush()
time.sleep(1.0)


I run both of the following commands:

$ python check-isatty.py
$ python check-isatty.py | cat

Both will output `tty'.  So still I cannot figure out the issue.

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An "Object" class?

[Gregory Ewing]

Cristian Cocos wrote:


type(print)





isinstance(print, builtin_function_or_method)


Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'builtin_function_or_method' is not defined

Just curious why builtin_function_or_method doesn't work as an argument of
isinstance().


Because the type object in question is not bound to the name
'builtin_function_or_method' in the builtin namespace. There
is a way to get at it, though:

>>> import types
>>> types.BuiltinFunctionType

>>> isinstance(print, types.BuiltinFunctionType)
True

When it comes to objects that form part of the interpreter's
internal machinery, the names shown when you print their types
are often just suggestive and aren't meant to be taken literally.
Most of them are available in the 'types' module, however,
possibly under different names. The reasons for all this are
buried in a lot of messy history.


The bottom line is that I am trying to figure out where exactly the world
of Python types _diverges from_ what I would expect as a mathematician. It
makes it easier for me to learn Python this way.


I'm not sure that focusing on classes as mathematical sets is all
that useful. In Python, what class an object belongs to isn't
usually very important. Much more relevant is how the object
*behaves*. We call this "duck typing" -- if it walks like a duck
and quacks like a duck then it might as well be a duck, even if
it doesn't belong to a class called "Duck".

This is why Python doesn't have e.g. an elaborate tower of
numeric types as is seen in some other languages. It just isn't
necessary for getting things done, and Python, being a very
pragmatic language, is all about getting things done.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Eryk Sun]

On 8/30/19, Eryk Sun  wrote:
>
> GetFileType classifies files for all of the following NT device types
> as FILE_TYPE_DISK (akin to Unix S_IFBLK):

To clarify, file-system files and directories in a mounted file system
on such as device are akin to Unix S_IFREG and S_IFDIR. Their file
type is FILE_TYPE_DISK, but this is simply based on the underlying
device type. If it's a file-system file, then GetFileAttributesW will
succeed. FILE_TYPE_DISK is only akin to S_IFBLK when we open a volume
or disk device directly, such as "//./C:" or "//./PhysicalDrive0".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: if STREAM.isatty():

[Eryk Sun]

On 8/29/19, Terry Reedy  wrote:
> On 8/29/2019 10:16 AM, Eryk Sun wrote:
>
>> In Windows, isatty() is true for any character-type file.
>
> Does that mean one that can either send or receive data a character at a
> time, as opposed to a block at a time?

Yes, any number of bytes can be written to a character device, whereas
a block device will require some fixed number of bytes such as a
512-byte disk sector.

WINAPI GetFileType classifies files for all of the following NT device
types as FILE_TYPE_CHAR (akin to Unix S_IFCHR):

FILE_DEVICE_CONSOLE
FILE_DEVICE_NULL
FILE_DEVICE_SERIAL_PORT
FILE_DEVICE_PARALLEL_PORT
FILE_DEVICE_KEYBOARD
FILE_DEVICE_MOUSE
FILE_DEVICE_MODEM
FILE_DEVICE_PRINTER
FILE_DEVICE_SCREEN
FILE_DEVICE_SOUND

FILE_DEVICE_CONSOLE is for the ConDrv console device, which was added
in Windows 8. In previous versions, GetFileType special cases console
pseudohandles.

GetFileType classifies files for all of the following NT device types
as FILE_TYPE_DISK (akin to Unix S_IFBLK):

FILE_DEVICE_DISK
FILE_DEVICE_VIRTUAL_DISK
FILE_DEVICE_CD_ROM
FILE_DEVICE_DISK_FILE_SYSTEM
FILE_DEVICE_CD_ROM_FILE_SYSTEM
FILE_DEVICE_DFS
FILE_DEVICE_DATALINK
FILE_DEVICE_CONTROLLER

> Aha.  So this is why
> https://pubs.opengroup.org/onlinepubs/009695399/functions/isatty.html
> follows the doc for isatty, which says 'associated with a terminal
> device', with an information section that contradicts that with
> "The isatty() function does not necessarily indicate that a human being
> is available for interaction via fildes. It is quite possible that
> non-terminal devices are connected to the communications line."

As far as I know, only the Windows CRT classifies any character device
as a TTY. Linux doesn't. "/dev/null" is a character device, but not a
TTY.

I think the CRT's _isatty implementation is wrong, though I'm not
certain what the right answer looks like. Windows doesn't have any
notion of a tty/pty terminal. I suppose it can just check for a
console. For older versions of Windows that would be based on checking
for a console pseudohandle. In Windows 8+, we can query
NtQueryVolumeInformationFile: FileFsDeviceInformation to check for
FILE_DEVICE_CONSOLE. (It would be useful if they exposed this in the
Windows API, maybe as GetVolumeInformationByHandleEx, like what they
did for GetFileInformationByHandleEx.)

> What makes a pipe on Windows not a character file?  Is data sent between
> processes a block at a time?  Are posix pipes different?

FILE_TYPE_PIPE (akin to Unix S_IFIFO) is a type that accesses a
section of shared memory that's used as an inter-process communication
channel. Requesting a read on an empty pipe blocks until at least one
byte is available. Requesting a write on a pipe blocks until there's
available space for the write to complete, which may require multiple
reads at the other end. (Note that Windows also classifies sockets as
'pipes', but Unix has a dedicated S_IFSOCK type for sockets.)

A pipe channel can be inbound (client-write, server-read), outbound
(server-write, client-read), or duplex (read-write on both ends).
Anonymous pipes are in duplex mode but they're opened with access on
each end that makes them effectively inbound mode. Windows also
supports message-mode pipes, which handles each write as a message. A
message-mode pipe can be configured to be read in either byte mode or
message mode. (Pipes in most Unix systems do not support duplex and
message modes.)

In principle, a pipe can be used as the IPC channel for an interactive
terminal. For example, MSYS2 does this with specially named pipes that
its isatty() function special cases as a TTYs. But in general we
expect pipes to be non-interactive, and for performance we default to
full buffering with pipes instead of line buffering. Full buffering is
incompatible with interactive usage.

> I don't understand the following.
> ---
> C:\Users\Terry>python -c "print('hello\n') | python
> hello
>
> Traceback (most recent call last):
>File "", line 1, in 
> NameError: name 'python' is not defined

The command line is missing the closing double quote around
"print('hello\n')". In this case, CMD acts as if the whole statement
is quoted, so the vertical bar is not interpreted as a pipe to a
`python` command. Let's print the command line for the python.exe
process in order to demonstrate this:

C:\>python -c "import win32api;print(win32api.GetCommandLine()) | python
python  -c "import win32api;print(win32api.GetCommandLine()) | python
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'python' is not defined
-- 
https://mail.python.org/mailman/listinfo/python-list