A decade or so of Python programming, and I've never thought to "for-elif"

[Chris Angelico]

for ns in namespaces:
if name in ns:
print("Found!")
break
elif name.isupper():
print("All-caps name that wasn't found")

This actually doesn't work. I have been programming in Python for well
over a decade, and never before been in a situation where this would
be useful.

As YAGNIs go, this is right up there.

(For the record, since this was the last thing in the function, I just
made the break a return. Alternatively, an extra indentation level
"else: if name.isupper():" wouldn't have been that terrible.)

Your random piece of amusement for today.

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

Re: frozenset can be altered by |=

[Chris Angelico]

On Tue, Nov 30, 2021 at 12:41 PM Richard Damon  wrote:
>
> On 11/29/21 5:01 PM, Chris Angelico wrote:
> > On Tue, Nov 30, 2021 at 8:55 AM Marco Sulla
> >  wrote:
> >> I must say that I'm reading the documentation now, and it's a bit
> >> confusing. In the docs, inplace operators as |= should not work. They
> >> are listed under the set-only functions and operators. But, as we saw,
> >> this is not completely true: they work but they don't mutate the
> >> original object. The same for += and *= that are listed under `list`
> >> only.
> >>
> > Previously explained here:
> >
> >>> On Mon, 22 Nov 2021 at 14:59, Chris Angelico  wrote:
>  Yeah, it's a little confusing, but at the language level, something
>  that doesn't support |= will implicitly support it using the expanded
>  version:
> 
>  a |= b
>  a = a | b
> 
>  and in the section above, you can see that frozensets DO support the
>  Or operator.
> 
>  By not having specific behaviour on the |= operator, frozensets
>  implicitly fall back on this default.
> 
> > The docs explicitly show that inplace operators are defined for the
> > mutable set, and not defined for the immutable frozenset. Therefore,
> > using an inplace operator on a frozenset uses the standard language
> > behavior of using the binary operator, then reassigning back to the
> > left operand.
> >
> > This is a language feature and applies to everything. You've seen it
> > plenty of times with integers, and probably strings too. A frozenset
> > behaves the same way that anything else does.
> >
> > ChrisA
>
> I suppose the question comes down to is it worth adding a reminder in
> the description of the inplace operators that if a type doesn't support
> the inplace operator, it is automatically converted into the equivalent
> assignment with the binary operator?
>

My view is: no, because you'd have to put that reminder on every
single object in Python. The details are here, and apply to all Python
code, not to any particular type:

https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements

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

Re: frozenset can be altered by |=

[Richard Damon]

On 11/29/21 5:01 PM, Chris Angelico wrote:

On Tue, Nov 30, 2021 at 8:55 AM Marco Sulla
 wrote:

I must say that I'm reading the documentation now, and it's a bit
confusing. In the docs, inplace operators as |= should not work. They
are listed under the set-only functions and operators. But, as we saw,
this is not completely true: they work but they don't mutate the
original object. The same for += and *= that are listed under `list`
only.


Previously explained here:


On Mon, 22 Nov 2021 at 14:59, Chris Angelico  wrote:

Yeah, it's a little confusing, but at the language level, something
that doesn't support |= will implicitly support it using the expanded
version:

a |= b
a = a | b

and in the section above, you can see that frozensets DO support the
Or operator.

By not having specific behaviour on the |= operator, frozensets
implicitly fall back on this default.


The docs explicitly show that inplace operators are defined for the
mutable set, and not defined for the immutable frozenset. Therefore,
using an inplace operator on a frozenset uses the standard language
behavior of using the binary operator, then reassigning back to the
left operand.

This is a language feature and applies to everything. You've seen it
plenty of times with integers, and probably strings too. A frozenset
behaves the same way that anything else does.

ChrisA


I suppose the question comes down to is it worth adding a reminder in 
the description of the inplace operators that if a type doesn't support 
the inplace operator, it is automatically converted into the equivalent 
assignment with the binary operator?


--
Richard Damon

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

Re: print('\N{flag: Mauritius}') not supported in py3.9

[Cameron Simpson]

On 30Nov2021 10:59, DL Neil  wrote:
>Fedora names it as rxvt-unicode.
>Installed v9.26
>Text is too small for these old eyes.

Fair enough. There are resources, but not worth it unless you really 
want the app.

>No menu bar and no context menus.

Um, yes. The (hardware, serial) terminals we had a uni didn't have such 
niceties, and therefore we should not want them.

>Unable to copy-paste (the flag codes) into that window.
>Removed.

Fair enough.

>I choose not to even try to remember the difficulties of working with
>small screens over-laying one another and 'getting lost' in the pile!

Aye. Tiling is very nice.

>I'm a lazy toad. Thus the idea that the IDE will allow me to 'press a
>(single) button' to repeat the last-run test/execute the code, without
>me having to commit a Save and to jump between panels/windows/screens,
>is seductive.

I once had a vi macro bound to ";" for "^W:!!^M", which autosaves the 
current file and reran the last shell command. Used it a lot in the 
single-terminal days. I unbound it several years ago though.

>I've nominated Kitty as
>Fedora's default terminal. We'll see how it goes with work-loads beyond
>raising the flag...

I'd like to hear how that goes down the track. If I find myself on a 
Linux desktop again a good terminal emulator would be very welcome.

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

Re: Python child process in while True loop blocks parent

[Jen Kris via Python-list]

Thanks to you and Cameron for your replies.  The C side has an epoll_ctl set, 
but no event loop to handle it yet.  I'm putting that in now with a pipe write 
in Python-- as Cameron pointed out that is the likely source of blocking on C.  
The pipes are opened as rdwr in Python because that's nonblocking by default.  
The child will become more complex, but not in a way that affects polling.  And 
thanks for the tip about the c-string termination. 



Nov 29, 2021, 14:12 by ba...@barrys-emacs.org:

>
>
>> On 29 Nov 2021, at 20:36, Jen Kris via Python-list  
>> wrote:
>>
>> I have a C program that forks to create a child process and uses execv to 
>> call a Python program.  The Python program communicates with the parent 
>> process (in C) through a FIFO pipe monitored with epoll(). 
>>
>> The Python child process is in a while True loop, which is intended to keep 
>> it running while the parent process proceeds, and perform functions for the 
>> C program only at intervals when the parent sends data to the child -- 
>> similar to a daemon process. 
>>
>> The C process writes to its end of the pipe and the child process reads it, 
>> but then the child process continues to loop, thereby blocking the parent. 
>>
>> This is the Python code:
>>
>> #!/usr/bin/python3
>> import os
>> import select
>>
>> #Open the named pipes
>> pr = os.open('/tmp/Pipe_01', os.O_RDWR)
>>
> Why open rdwr if you are only going to read the pipe?
>
>> pw = os.open('/tmp/Pipe_02', os.O_RDWR)
>>
> Only need to open for write.
>
>>
>> ep = select.epoll(-1)
>> ep.register(pr, select.EPOLLIN)
>>
>
> Is the only thing that the child does this:
> 1. Read message from pr
> 2. Process message
> 3. Write result to pw.
> 4. Loop from 1
>
> If so as Cameron said you do not need to worry about the poll.
> Do you plan for the child to become more complex?
>
>>
>> while True:
>>
>>  events = ep.poll(timeout=2.5, maxevents=-1)
>>  #events = ep.poll(timeout=None, maxevents=-1)
>>
>>  print("child is looping")
>>
>>  for fileno, event in events:
>>  print("Python fileno")
>>  print(fileno)
>>  print("Python event")
>>  print(event)
>>  v = os.read(pr,64)
>>  print("Pipe value")
>>  print(v)
>>
>> The child process correctly receives the signal from ep.poll and correctly 
>> reads the data in the pipe, but then it continues looping.  For example, 
>> when I put in a timeout:
>>
>> child is looping
>> Python fileno
>> 4
>> Python event
>> 1
>> Pipe value
>> b'10\x00'
>>
> The C code does not need to write a 0 bytes at the end.
> I assume the 0 is from the end of a C string.
> UDS messages have a length.
> In the C just write 2 byes in the case.
>
> Barry
>
>> child is looping
>> child is looping
>>
>> That suggests that a while True loop is not the right thing to do in this 
>> case.  My question is, what type of process loop is best for this situation? 
>>  The multiprocessing, asyncio and subprocess libraries are very extensive, 
>> and it would help if someone could suggest the best alternative for what I 
>> am doing here. 
>>
>> Thanks very much for any ideas. 
>>
>>
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list
>>

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

Re: Python child process in while True loop blocks parent

[Barry]

> On 29 Nov 2021, at 20:36, Jen Kris via Python-list  
> wrote:
> 
> I have a C program that forks to create a child process and uses execv to 
> call a Python program.  The Python program communicates with the parent 
> process (in C) through a FIFO pipe monitored with epoll().  
> 
> The Python child process is in a while True loop, which is intended to keep 
> it running while the parent process proceeds, and perform functions for the C 
> program only at intervals when the parent sends data to the child -- similar 
> to a daemon process. 
> 
> The C process writes to its end of the pipe and the child process reads it, 
> but then the child process continues to loop, thereby blocking the parent. 
> 
> This is the Python code:
> 
> #!/usr/bin/python3
> import os
> import select
> 
> #Open the named pipes
> pr = os.open('/tmp/Pipe_01', os.O_RDWR)
> pw = os.open('/tmp/Pipe_02', os.O_RDWR)

You will need to set the fd’s to non blocking on parent and child.
Otherwise the parent will block on its write until the child reads the message.

Barry
> 
> ep = select.epoll(-1)
> ep.register(pr, select.EPOLLIN)
> 
> while True:
> 
> events = ep.poll(timeout=2.5, maxevents=-1)
> #events = ep.poll(timeout=None, maxevents=-1)
> 
> print("child is looping")
> 
> for fileno, event in events:
> print("Python fileno")
> print(fileno)
> print("Python event")
> print(event)
> v = os.read(pr,64)
> print("Pipe value")
> print(v)
> 
> The child process correctly receives the signal from ep.poll and correctly 
> reads the data in the pipe, but then it continues looping.  For example, when 
> I put in a timeout:
> 
> child is looping
> Python fileno
> 4
> Python event
> 1
> Pipe value
> b'10\x00'
> child is looping
> child is looping
> 
> That suggests that a while True loop is not the right thing to do in this 
> case.  My question is, what type of process loop is best for this situation?  
> The multiprocessing, asyncio and subprocess libraries are very extensive, and 
> it would help if someone could suggest the best alternative for what I am 
> doing here. 
> 
> Thanks very much for any ideas. 
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: Python child process in while True loop blocks parent

[Barry]

> On 29 Nov 2021, at 20:36, Jen Kris via Python-list  
> wrote:
> 
> I have a C program that forks to create a child process and uses execv to 
> call a Python program.  The Python program communicates with the parent 
> process (in C) through a FIFO pipe monitored with epoll().  
> 
> The Python child process is in a while True loop, which is intended to keep 
> it running while the parent process proceeds, and perform functions for the C 
> program only at intervals when the parent sends data to the child -- similar 
> to a daemon process. 
> 
> The C process writes to its end of the pipe and the child process reads it, 
> but then the child process continues to loop, thereby blocking the parent. 
> 
> This is the Python code:
> 
> #!/usr/bin/python3
> import os
> import select
> 
> #Open the named pipes
> pr = os.open('/tmp/Pipe_01', os.O_RDWR)
Why open rdwr if you are only going to read the pipe?
> pw = os.open('/tmp/Pipe_02', os.O_RDWR)
Only need to open for write.
> 
> ep = select.epoll(-1)
> ep.register(pr, select.EPOLLIN)

Is the only thing that the child does this:
1. Read message from pr
2. Process message
3. Write result to pw.
4. Loop from 1

If so as Cameron said you do not need to worry about the poll.
Do you plan for the child to become more complex?

> 
> while True:
> 
> events = ep.poll(timeout=2.5, maxevents=-1)
> #events = ep.poll(timeout=None, maxevents=-1)
> 
> print("child is looping")
> 
> for fileno, event in events:
> print("Python fileno")
> print(fileno)
> print("Python event")
> print(event)
> v = os.read(pr,64)
> print("Pipe value")
> print(v)
> 
> The child process correctly receives the signal from ep.poll and correctly 
> reads the data in the pipe, but then it continues looping.  For example, when 
> I put in a timeout:
> 
> child is looping
> Python fileno
> 4
> Python event
> 1
> Pipe value
> b'10\x00'
The C code does not need to write a 0 bytes at the end.
I assume the 0 is from the end of a C string.
UDS messages have a length.
In the C just write 2 byes in the case.

Barry

> child is looping
> child is looping
> 
> That suggests that a while True loop is not the right thing to do in this 
> case.  My question is, what type of process loop is best for this situation?  
> The multiprocessing, asyncio and subprocess libraries are very extensive, and 
> it would help if someone could suggest the best alternative for what I am 
> doing here. 
> 
> Thanks very much for any ideas. 
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: frozenset can be altered by |=

[Chris Angelico]

On Tue, Nov 30, 2021 at 8:55 AM Marco Sulla
 wrote:
>
> I must say that I'm reading the documentation now, and it's a bit
> confusing. In the docs, inplace operators as |= should not work. They
> are listed under the set-only functions and operators. But, as we saw,
> this is not completely true: they work but they don't mutate the
> original object. The same for += and *= that are listed under `list`
> only.
>

Previously explained here:

> > On Mon, 22 Nov 2021 at 14:59, Chris Angelico  wrote:
> > >
> > > Yeah, it's a little confusing, but at the language level, something
> > > that doesn't support |= will implicitly support it using the expanded
> > > version:
> > >
> > > a |= b
> > > a = a | b
> > >
> > > and in the section above, you can see that frozensets DO support the
> > > Or operator.
> > >
> > > By not having specific behaviour on the |= operator, frozensets
> > > implicitly fall back on this default.
> > >

The docs explicitly show that inplace operators are defined for the
mutable set, and not defined for the immutable frozenset. Therefore,
using an inplace operator on a frozenset uses the standard language
behavior of using the binary operator, then reassigning back to the
left operand.

This is a language feature and applies to everything. You've seen it
plenty of times with integers, and probably strings too. A frozenset
behaves the same way that anything else does.

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

Re: print('\N{flag: Mauritius}') not supported in py3.9

[dn via Python-list]

On 30/11/2021 10.19, Cameron Simpson wrote:
> On 29Nov2021 22:25, DL Neil  wrote:
 Probably a font issue. Not many fonts support the flags.
>>>
>>> Agree about the font support. Some terminal emulators make an effort to
>>> have fallback fonts for when your preferred font lacks a glyph. IIRC
>>> urxvt is such a terminal on Linux.
>>
>> Not sure about this. Most other applications on this PC will display the
>> two countries' flags, as desired, eg Writer, web-browser, even xed
>> (basic text editor).
> 
> Seem Stefan Ram's advice, which points out that you can tell if this is 
> a font problem (no flag glyph) or a combining problem (2 glyphs 
> presented instead of one). I had not considered that.

@Stefan's advice preceded by report that two glyphs were printed (not
one): "the two letters "N" and "Z" are shown with dotted-outlines"
(I think, the UTF-16 decoding)


>> rxvt: won't compile, gave-up fighting unfamiliar requirements
> 
> See if there's a package for urxvt, which was the "unicode" flavour of 
> rxvt (long ago - rxvt if probably supposed to be unicode capable these 
> days, surely).

Fedora names it as rxvt-unicode.
Installed v9.26
Text is too small for these old eyes.
No menu bar and no context menus.
Unable to copy-paste (the flag codes) into that window.
Removed.


>> Kitty: works!
> 
> Yay!
> 
>> Kitty is not something I've come-across before. Its write-up says
>> «
>> Kitty is a free, open-source, and fast, feature-rich, GPU accelerated
>> terminal emulator for Linux, that supports all present-day terminal
>> features, such as Unicode, true color, text formatting, bold/italic
>> fonts, tiling of multiple windows and tabs, etc.
> 
> A tiling terminal emulator can be a great thing. I'm on a Mac with 
> iTerm, which:
> - has tabs
> - has panes (split the view into multiple panels, each running a 
>   terminal)
> 
> My personal dev desktop tends to use a full screen iTerm split 
> vertically into 2 panes: an editor on the left (vim, itself split 
> vertically into 2 vim windows) and a shell on the right; sometimes 
> several shells (right hand pane further split horizontally).
> 
> Then, since I tend to keep per-branch checkouts around, tabs for the 
> things I'm working on, each configured as above. Then I just switch tabs 
> for the different areas.


Yes, a good way to work. Neatly explained.

I choose not to even try to remember the difficulties of working with
small screens over-laying one another and 'getting lost' in the pile!

My desktop/dev.svr features two screens: one in 'portrait mode' and the
other 'landscape'. The former is very good for code-listings. The latter
for execution-display, pytest reports, etc. As you describe, each can be
sub-divided when needs-arise. A neat feature is that "Tool Windows" can
be tucked-away, and only 'pulled-out' when required, eg am not looking
at Sourcery's assessments right now (unless it highlights the commission
of some 'crime' as I type) but will check prior to (or as part of) git
commit. The Tool Window's name/label in the 'dock' also forms a reminder
that I shouldn't (totally) neglect my responsibilities!

These are managed within the IDE - sadly, PyCharm's terminal/console
fails the 'flag test', as reported yesterday. (am not sure if one might
be able to select which terminal emulator to use ...)

I'm a lazy toad. Thus the idea that the IDE will allow me to 'press a
(single) button' to repeat the last-run test/execute the code, without
me having to commit a Save and to jump between panels/windows/screens,
is seductive.

Don't tell my trainees! Every course sees three or four who 'cry for
help' because making some change in their choice of editor/IDE does not
result in similar within the web-browser. Did you forget to save the
source, Luke? That's not to say there won't be considerably more who
manage to diagnose the problem without admitting such to 'the outside
world'!


There are times when there is no need to (wait quite a while to) boot-up
a whole IDE, eg running a utility program. I've nominated Kitty as
Fedora's default terminal. We'll see how it goes with work-loads beyond
raising the flag...
Salute!
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: frozenset can be altered by |=

[Marco Sulla]

I must say that I'm reading the documentation now, and it's a bit
confusing. In the docs, inplace operators as |= should not work. They
are listed under the set-only functions and operators. But, as we saw,
this is not completely true: they work but they don't mutate the
original object. The same for += and *= that are listed under `list`
only.

On Mon, 22 Nov 2021 at 19:54, Marco Sulla  wrote:
>
> Yes, and you do this regularly. Indeed integers, for example, are immutables 
> and
>
> a = 0
> a += 1
>
> is something you do dozens of times, and you simply don't think that
> another object is created and substituted for the variable named `a`.
>
> On Mon, 22 Nov 2021 at 14:59, Chris Angelico  wrote:
> >
> > On Tue, Nov 23, 2021 at 12:52 AM David Raymond  
> > wrote:
> > > It is a little confusing since the docs list this in a section that says 
> > > they don't apply to frozensets, and lists the two versions next to each 
> > > other as the same thing.
> > >
> > > https://docs.python.org/3.9/library/stdtypes.html#set-types-set-frozenset
> > >
> > > The following table lists operations available for set that do not apply 
> > > to immutable instances of frozenset:
> > >
> > > update(*others)
> > > set |= other | ...
> > >
> > > Update the set, adding elements from all others.
> >
> > Yeah, it's a little confusing, but at the language level, something
> > that doesn't support |= will implicitly support it using the expanded
> > version:
> >
> > a |= b
> > a = a | b
> >
> > and in the section above, you can see that frozensets DO support the
> > Or operator.
> >
> > By not having specific behaviour on the |= operator, frozensets
> > implicitly fall back on this default.
> >
> > ChrisA
> > --
> > https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print('\N{flag: Mauritius}') not supported in py3.9

[Cameron Simpson]

On 29Nov2021 22:25, DL Neil  wrote:
>>> Probably a font issue. Not many fonts support the flags.
>>
>> Agree about the font support. Some terminal emulators make an effort to
>> have fallback fonts for when your preferred font lacks a glyph. IIRC
>> urxvt is such a terminal on Linux.
>
>Not sure about this. Most other applications on this PC will display the
>two countries' flags, as desired, eg Writer, web-browser, even xed
>(basic text editor).

Seem Stefan Ram's advice, which points out that you can tell if this is 
a font problem (no flag glyph) or a combining problem (2 glyphs 
presented instead of one). I had not considered that.

>rxvt: won't compile, gave-up fighting unfamiliar requirements

See if there's a package for urxvt, which was the "unicode" flavour of 
rxvt (long ago - rxvt if probably supposed to be unicode capable these 
days, surely).

>Kitty: works!

Yay!

>Kitty is not something I've come-across before. Its write-up says
>«
>Kitty is a free, open-source, and fast, feature-rich, GPU accelerated
>terminal emulator for Linux, that supports all present-day terminal
>features, such as Unicode, true color, text formatting, bold/italic
>fonts, tiling of multiple windows and tabs, etc.

A tiling terminal emulator can be a great thing. I'm on a Mac with 
iTerm, which:
- has tabs
- has panes (split the view into multiple panels, each running a 
  terminal)

My personal dev desktop tends to use a full screen iTerm split 
vertically into 2 panes: an editor on the left (vim, itself split 
vertically into 2 vim windows) and a shell on the right; sometimes 
several shells (right hand pane further split horizontally).

Then, since I tend to keep per-branch checkouts around, tabs for the 
things I'm working on, each configured as above. Then I just switch tabs 
for the different areas.

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

Re: Python child process in while True loop blocks parent

[Cameron Simpson]

On 29Nov2021 21:34, Jen Kris  wrote:
>I have a C program that forks to create a child process and uses execv to call 
>a Python program.  The Python program communicates with the parent process (in 
>C) through a FIFO pipe monitored with epoll(). 
>
>The Python child process is in a while True loop, which is intended to keep it 
>running while the parent process proceeds, and perform functions for the C 
>program only at intervals when the parent sends data to the child -- similar 
>to a daemon process. 
>
>The C process writes to its end of the pipe and the child process reads it, 
>but then the child process continues to loop, thereby blocking the parent. 

It seems to me that the child Python process never writes anything back 
to the parent. If the parent is waiting for some response, of course it 
will be blocked.

Personally I wouldn't be using epoll at all. I'd just read data from pr, 
act on it, and write back to pw. That way the child blocks waiting for 
the parent istead of polling. You only want epoll if you're either 
polling something _while_ you do other work, or monitoring more than one 
thing. A plain read-from-one-pipe, work, write-back-to-the-other does 
not need it.

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

Python child process in while True loop blocks parent

[Jen Kris via Python-list]

I have a C program that forks to create a child process and uses execv to call 
a Python program.  The Python program communicates with the parent process (in 
C) through a FIFO pipe monitored with epoll().  

The Python child process is in a while True loop, which is intended to keep it 
running while the parent process proceeds, and perform functions for the C 
program only at intervals when the parent sends data to the child -- similar to 
a daemon process. 

The C process writes to its end of the pipe and the child process reads it, but 
then the child process continues to loop, thereby blocking the parent. 

This is the Python code:

#!/usr/bin/python3
import os
import select

#Open the named pipes
pr = os.open('/tmp/Pipe_01', os.O_RDWR)
pw = os.open('/tmp/Pipe_02', os.O_RDWR)

ep = select.epoll(-1)
ep.register(pr, select.EPOLLIN)

while True:

    events = ep.poll(timeout=2.5, maxevents=-1)
    #events = ep.poll(timeout=None, maxevents=-1)

    print("child is looping")

    for fileno, event in events:
    print("Python fileno")
    print(fileno)
    print("Python event")
    print(event)
    v = os.read(pr,64)
    print("Pipe value")
    print(v)

The child process correctly receives the signal from ep.poll and correctly 
reads the data in the pipe, but then it continues looping.  For example, when I 
put in a timeout:

child is looping
Python fileno
4
Python event
1
Pipe value
b'10\x00'
child is looping
child is looping

That suggests that a while True loop is not the right thing to do in this case. 
 My question is, what type of process loop is best for this situation?  The 
multiprocessing, asyncio and subprocess libraries are very extensive, and it 
would help if someone could suggest the best alternative for what I am doing 
here. 

Thanks very much for any ideas. 


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

Re: Negative subscripts

[Chris Angelico]

On Tue, Nov 30, 2021 at 6:45 AM dn via Python-list
 wrote:
>
>
>
> On 27/11/2021 21.23, Chris Angelico wrote:
> > On Sat, Nov 27, 2021 at 7:21 PM dn via Python-list
> >  wrote:
> >> The expression list is evaluated once; it should yield an iterable
> >> object. An iterator is created for the result of the expression_list.
> >> The suite is then executed once for each item provided by the iterator,
> >> in the order returned by the iterator. Each item in turn is assigned to
> >> the target list using the standard rules for assignments (see Assignment
> >> statements), and then the suite is executed. When the items are
> >> exhausted (which is immediately when the sequence is empty or an
> >> iterator raises a StopIteration exception), the suite in the else
> >> clause, if present, is executed, and the loop terminates.
> >> »
> >> https://docs.python.org/3/reference/compound_stmts.html#the-for-statement
> >>
> >>
> >> That said, I'm wondering if all is strictly true when the
> >> expression_list is a generator, which by definition features
> >> lazy-execution rather than up-front list production. So, things may
> >> depend upon the full-nature of the application.
> >
> > Yes, it is. Evaluating a generator expression gives you a generator
> > object, which is an iterable.
>
>
> You (and the text) are correct - the expression list is "evaluated once"
> and produces a generator object. For a particular understanding of
> "evaluate".
>
> However, as described, all that has been "evaluated" is a
> generator-object. Unlike (say) a list's iterator, a generator only
> eventually produces a 'list' - and each time the generator is
> called-upon to yield the next value, that value has to be "evaluated",
> ie there's some further evaluation loop-by-loop.
>
> Further, that the values-returned can be amended during the life of the
> generator (in ways anticipated and unanticipated by coder and
> interpreter alike). Thus, it seems that the "list" doesn't actually
> exist, as in, hasn't been "evaluated" as data-values, when the loop is
> enacted.
>
> What has been 'evaluated' are the terms by which the looping will
> proceed, and terminate.
>

That's true of ALL iterators though. If you get a list iterator, and
while you're stepping through it, the underlying list changes, you'll
see those changes. Nothing gets "snapshot" unless you explicitly
request it (eg by slicing the list first).

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

Re: Negative subscripts

[dn via Python-list]

On 27/11/2021 21.23, Chris Angelico wrote:
> On Sat, Nov 27, 2021 at 7:21 PM dn via Python-list
>  wrote:
>> The expression list is evaluated once; it should yield an iterable
>> object. An iterator is created for the result of the expression_list.
>> The suite is then executed once for each item provided by the iterator,
>> in the order returned by the iterator. Each item in turn is assigned to
>> the target list using the standard rules for assignments (see Assignment
>> statements), and then the suite is executed. When the items are
>> exhausted (which is immediately when the sequence is empty or an
>> iterator raises a StopIteration exception), the suite in the else
>> clause, if present, is executed, and the loop terminates.
>> »
>> https://docs.python.org/3/reference/compound_stmts.html#the-for-statement
>>
>>
>> That said, I'm wondering if all is strictly true when the
>> expression_list is a generator, which by definition features
>> lazy-execution rather than up-front list production. So, things may
>> depend upon the full-nature of the application.
> 
> Yes, it is. Evaluating a generator expression gives you a generator
> object, which is an iterable.


You (and the text) are correct - the expression list is "evaluated once"
and produces a generator object. For a particular understanding of
"evaluate".

However, as described, all that has been "evaluated" is a
generator-object. Unlike (say) a list's iterator, a generator only
eventually produces a 'list' - and each time the generator is
called-upon to yield the next value, that value has to be "evaluated",
ie there's some further evaluation loop-by-loop.

Further, that the values-returned can be amended during the life of the
generator (in ways anticipated and unanticipated by coder and
interpreter alike). Thus, it seems that the "list" doesn't actually
exist, as in, hasn't been "evaluated" as data-values, when the loop is
enacted.

What has been 'evaluated' are the terms by which the looping will
proceed, and terminate.


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

Re: pyinstaller wrong classified as Windows virus

[Benjamin Schollnick]

>> Windows Defender has a setting to also use “Reputation Scoring”.
>> What that simply means is that WDef will report back a hash to microsoft 
>> which is then checked to see if it is known.  If it is known, then it has a 
>> reputation and based off that reputation Defender will either allow it to 
>> run or not.
>> But if there is no reputation (eg no one has ever run it), that’s 
>> suspicious.  And that’s what you are running into.
>> You can submit the EXE to the defender team, which should allow it to 
>> operate properly without any issue.
>>  - Benjamin
> 
> sure... "that's suspicious". Unless you're a developer compiling your own 
> code. In which case every fresh build will be something "unknown". You have 
> to set every setting you can find to "developer mode" to help with this kind 
> of thing, and sometimes it's still not enough.

Understandable, and Steve Gibson (GRC.com , creator of 
Spinrite) has mentioned that he has had this problem with every Beta of his 
applications.

I agree completely with you, but that’s how Microsoft has set things up.

- Benjamin


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

Re: pyinstaller wrong classified as Windows virus

[Mats Wichmann]

On 11/29/21 12:04, Benjamin Schollnick wrote:

Windows Defender has a setting to also use “Reputation Scoring”.

What that simply means is that WDef will report back a hash to microsoft which 
is then checked to see if it is known.  If it is known, then it has a 
reputation and based off that reputation Defender will either allow it to run 
or not.

But if there is no reputation (eg no one has ever run it), that’s suspicious.  
And that’s what you are running into.

You can submit the EXE to the defender team, which should allow it to operate 
properly without any issue.

- Benjamin


sure... "that's suspicious". Unless you're a developer compiling your 
own code. In which case every fresh build will be something "unknown". 
You have to set every setting you can find to "developer mode" to help 
with this kind of thing, and sometimes it's still not enough.



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

Re: Failure to Display Top menu

[Calvin Spealman]

This mailing list does not allow attachments. If you're trying to share a
screenshot, post it to imgur or something like that and share a URL here.

On Mon, Nov 29, 2021 at 2:12 PM Peter Mwale  wrote:

> Hello Christian,
> Am referring to menu marked in picture below. It's not coming on my window.
>
>
> On Sat, Nov 27, 2021, 20:19 Christian Gollwitzer  wrote:
>
> > Am 26.11.21 um 21:38 schrieb Peter Mwale:
> > > Hello, my python 3.10 shell is not displaying the top menu. What
> should I
> > > do?
> > >
> >
> > You should explain, what you do exactly. The Python interpreter does not
> > have a menu.
> >
> > a) What platform are you on? Windows, macOS, Linux?
> >
> > b) How did ou start Python and what was the expectation?
> >
> > Christian
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Failure to Display Top menu

[dn via Python-list]

On 30/11/2021 07.43, Peter Mwale wrote:
> Hello Christian,
> Am referring to menu marked in picture below. It's not coming on my window.
> 
> 
> On Sat, Nov 27, 2021, 20:19 Christian Gollwitzer  wrote:
> 
>> Am 26.11.21 um 21:38 schrieb Peter Mwale:
>>> Hello, my python 3.10 shell is not displaying the top menu. What should I
>>> do?
>>>
>>
>> You should explain, what you do exactly. The Python interpreter does not
>> have a menu.
>>
>> a) What platform are you on? Windows, macOS, Linux?
>>
>> b) How did ou start Python and what was the expectation?


Sadly, this mailing list will not forward non-text attachments (for
security reasons).

Please start at https://docs.python.org/3/using/index.html with
particular attention to the chapter on MS-Windows.

This should answer your question.

If not, at least we will have some common terminology to be able to
express and solve any remaining problem...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Failure to Display Top menu

[Peter Mwale]

Hello Christian,
Am referring to menu marked in picture below. It's not coming on my window.


On Sat, Nov 27, 2021, 20:19 Christian Gollwitzer  wrote:

> Am 26.11.21 um 21:38 schrieb Peter Mwale:
> > Hello, my python 3.10 shell is not displaying the top menu. What should I
> > do?
> >
>
> You should explain, what you do exactly. The Python interpreter does not
> have a menu.
>
> a) What platform are you on? Windows, macOS, Linux?
>
> b) How did ou start Python and what was the expectation?
>
> Christian
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pyinstaller wrong classified as Windows virus

[Benjamin Schollnick]

Windows Defender has a setting to also use “Reputation Scoring”.

What that simply means is that WDef will report back a hash to microsoft which 
is then checked to see if it is known.  If it is known, then it has a 
reputation and based off that reputation Defender will either allow it to run 
or not.

But if there is no reputation (eg no one has ever run it), that’s suspicious.  
And that’s what you are running into.  

You can submit the EXE to the defender team, which should allow it to operate 
properly without any issue.

- Benjamin



> On Nov 29, 2021, at 1:57 PM, Barry  wrote:
> 
> 
> 
>> On 29 Nov 2021, at 00:03, anthony.flury via Python-list 
>>  wrote:
>> 
>> 
>> On 26/11/2021 07:13, Ulli Horlacher wrote
 But consider another possibility that your compiler software is compromised
>>> Then https://www.python.org/ftp/python/3.10.0/python-3.10.0-amd64.exe
>>> is infected. I doubt this.
>> 
>> But you aren't using python3.10 to 'compile' the code to the executable that 
>> windows complains about: you are using pyinstaller, which if memory serves 
>> is a 3rd party application.
>> 
>> I assume that you have no problem running the script without pyinstaller ?
>> 
>> so Might pyinstaller be compromised in some way ?
> 
> Not likely.
> 
> On windows pyinstall, and other tools like it, create .exe files on windows.
> I would guess it’s that .exe that is triggering the malware detector false 
> positive.
> 
> Barry
>> 
>> 
>>> 
 Is this happening to only one set of code?
>>> This is happening SOMETIMES, not always. With the SAME source code. When I
>>> call pyinstaller often enough, then the virus scanner is quiet. In about 1
>>> of 20 compile runs.
>>> 
>>> 
>>> 
>> -- 
>> Anthony Flury
>> *Moble*: +44 07743 282707
>> *Home*: +44 (0)1206 391294
>> *email*: anthony.fl...@btinternet.com 
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list
>> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: pyinstaller wrong classified as Windows virus

[Barry]

> On 29 Nov 2021, at 00:03, anthony.flury via Python-list 
>  wrote:
> 
> 
> On 26/11/2021 07:13, Ulli Horlacher wrote
>>> But consider another possibility that your compiler software is compromised
>> Then https://www.python.org/ftp/python/3.10.0/python-3.10.0-amd64.exe
>> is infected. I doubt this.
> 
> But you aren't using python3.10 to 'compile' the code to the executable that 
> windows complains about: you are using pyinstaller, which if memory serves is 
> a 3rd party application.
> 
> I assume that you have no problem running the script without pyinstaller ?
> 
> so Might pyinstaller be compromised in some way ?

Not likely.

On windows pyinstall, and other tools like it, create .exe files on windows.
I would guess it’s that .exe that is triggering the malware detector false 
positive.

Barry
> 
> 
>>   
>>> Is this happening to only one set of code?
>> This is happening SOMETIMES, not always. With the SAME source code. When I
>> call pyinstaller often enough, then the virus scanner is quiet. In about 1
>> of 20 compile runs.
>> 
>> 
>> 
> -- 
> Anthony Flury
> *Moble*: +44 07743 282707
> *Home*: +44 (0)1206 391294
> *email*: anthony.fl...@btinternet.com 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

Re: pyinstaller wrong classified as Windows virus

[Ulli Horlacher]

anthony.flury  wrote:
> 
> On 26/11/2021 07:13, Ulli Horlacher wrote
> >> But consider another possibility that your compiler software is compromised
> > Then https://www.python.org/ftp/python/3.10.0/python-3.10.0-amd64.exe
> > is infected. I doubt this.
> 
> But you aren't using python3.10 to 'compile' the code to the executable 
> that windows complains about: you are using pyinstaller, which if memory 
> serves is a 3rd party application.
> 
> I assume that you have no problem running the script without pyinstaller ?
> 
> so Might pyinstaller be compromised in some way ?

Then is the pip repository compromised. I doubt this, too.
I have installed pyinstaller with: pip intall pyinstaller


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print('\N{flag: Mauritius}') not supported in py3.9

[dn via Python-list]

On 29/11/2021 12.06, Cameron Simpson wrote:
> On 29Nov2021 09:19, Chris Angelico  wrote:
>> On Mon, Nov 29, 2021 at 8:10 AM dn via Python-list
>>  wrote:
>>> However, when trying the above, with our local flag in (Fedora Linux,
>>> Gnome) Terminal or PyCharm's Run terminal; the two letters "N" and "Z"
>>> are shown with dotted-outlines. Similarly, the Mauritius' flag is shown
>>> as "M" and "U".
>>>
>>> Whereas here in email (Thunderbird) or in a web-browser, the flags
>>> appear, as desired.
>>>
>>> Is this a terminal short-coming (locale charmap -> UTF-8 - which brings
>>> to mind the old UCS-4 questions), a font issue, or what (to fix)?
>>
>> Probably a font issue. Not many fonts support the flags.
> 
> Agree about the font support. Some terminal emulators make an effort to 
> have fallback fonts for when your preferred font lacks a glyph. IIRC 
> urxvt is such a terminal on Linux.


Not sure about this. Most other applications on this PC will display the
two countries' flags, as desired, eg Writer, web-browser, even xed
(basic text editor).

Accordingly, took @Cameron's advice. Leading to:

Gnome Terminal: won't display "\U0001F1F3\U0001F1FF" (etc)
Terminator: won't display
Tabby: doesn't seem to load from (rpm) repo
RoxTerm: no choice of fonts, won't display
rxvt: won't compile, gave-up fighting unfamiliar requirements
Terminology: offers choice of fonts, but still fails

Kitty: works!


Kitty is not something I've come-across before. Its write-up says
«
Kitty is a free, open-source, and fast, feature-rich, GPU accelerated
terminal emulator for Linux, that supports all present-day terminal
features, such as Unicode, true color, text formatting, bold/italic
fonts, tiling of multiple windows and tabs, etc.

Kitty is written in C and Python programming languages, and it is one of
few terminal emulators with GPU support
»


Yes, the one that 'works', is using the same fonts as (say) Writer, and
the original (Gnome) Terminal that fails.


Please don't take this as a scientific survey. I didn't spend any time
investigating - either the s/w worked or it didn't! However, a terminal
is doing a simple job (at the user-level), so there's not much to them
in terms of knobs to twiddle or levers to pull.
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list