[issue38351] Modernize email example from %-formatting to f-string

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

I'd like to see consistent usage by default, with specific examples using the 
older forms as appropriate.  The use cases Raymond identified are worth 
discussing (and the tutorial may be a good place for this), and well as 
mentioned in the reference docs for the '%s' % x and ''.format() operations 
(and string.Template(), of course).

I would not like to see different syntaxes randomly applied to different 
examples that happen to involve formatting, but where that's not the emphasis.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Kyle Stanley]

Kyle Stanley  added the comment:

> For the most part, templating examples can be switched to the .format() style 
> but shouldn't be switched to f-strings.

Is there no specific use case for the older "%s" % sub template that .format() 
doesn't have?

> The former technique is still necessary if someone wants to move templates to 
> an external file

Interesting, I wasn't aware of that. This seems like it might be worth a brief 
mention in https://docs.python.org/3.9/library/stdtypes.html#str.format. 

> AFAICT, it will be around forever, so people still need to see some examples 
> of each.

To allow users to see examples of each, would you suggest that we should leave 
the existing .format() examples as is and have more recently created examples 
use f-strings? I'd be okay with this, as long as there's a balance of both 
everywhere (particularly in the tutorial).

Personally, I think that the f-string examples should be used more commonly 
used since they're generally more concise and readable. But, I can definitely 
understand the purpose of leaving the older ones around as long as they have a 
specific use case and are still utilized.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The revised PR appears to fix this and other issues, although the presence of 
astral chars in code being edited messes up tk's cursor positioning.  Assuming 
that this cannot be changed, we could add the the ability to replace astral 
chars with \U escapes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Basic python question

[Jagga Soorma]

Thanks again Aldwin.  This seems to work, guess it is the set that is
flipping the numbers:

x,y = (output.split())

Much appreciated!

On Wed, Oct 2, 2019 at 9:19 PM Aldwin Pollefeyt
 wrote:
>
> Seems to work also:
>
> >>> [x,y] = output.split()
>
> On Thu, Oct 3, 2019 at 12:17 PM Aldwin Pollefeyt  
> wrote:
>>
>> Oh, sorry .. please try this:
>>
>> >>> x,y = tuple(output.split())
>>
>> On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma  wrote:
>>>
>>> Thanks Aldwin that helps but it looks like it is reversing the numbers
>>> for some reason:
>>>
>>> the df command returns the following:
>>> 7  2
>>>
>>> I used your example and did:
>>> x,y = set(output.split())
>>>
>>> My assumption would be that x should be 7 and y should be 2.  However,
>>> when I print x and y it seems to be reversed (x is 2 and y is 7).  Am
>>> I missing something?
>>>
>>> Thanks
>>>
>>> On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt
>>>  wrote:
>>> >
>>> > You could use:
>>> >
>>> > >>> x, y = set(output.split())
>>> >
>>> > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I am new to python and trying to do some basic things with python.  I
>>> >> am writing a script that runs a df command and I need parts of that
>>> >> output saved in 2 different variables.  Is this something that can be
>>> >> done?  I can do this by running multiple df commands but would prefer
>>> >> to make only one call:
>>> >>
>>> >> --
>>> >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' 
>>> >> '"
>>> >> output  = subprocess.check_output( inode_cmd,
>>> >> stderr=subprocess.STDOUT, shell=True )
>>> >> --
>>> >>
>>> >> But this would end up giving me the following:
>>> >>
>>> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
>>> >>5   1
>>> >>
>>> >> I would like variable x to be 5 and variable y to be 1.  Is there a
>>> >> easier way to do this?
>>> >>
>>> >> Thanks in advance for your guidance.
>>> >> --
>>> >> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Basic python question

[Aldwin Pollefeyt]

Seems to work also:

>>> [x,y] = output.split()

On Thu, Oct 3, 2019 at 12:17 PM Aldwin Pollefeyt 
wrote:

> Oh, sorry .. please try this:
>
> >>> x,y = tuple(output.split())
>
> On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma  wrote:
>
>> Thanks Aldwin that helps but it looks like it is reversing the numbers
>> for some reason:
>>
>> the df command returns the following:
>> 7  2
>>
>> I used your example and did:
>> x,y = set(output.split())
>>
>> My assumption would be that x should be 7 and y should be 2.  However,
>> when I print x and y it seems to be reversed (x is 2 and y is 7).  Am
>> I missing something?
>>
>> Thanks
>>
>> On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt
>>  wrote:
>> >
>> > You could use:
>> >
>> > >>> x, y = set(output.split())
>> >
>> > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma  wrote:
>> >>
>> >> Hello,
>> >>
>> >> I am new to python and trying to do some basic things with python.  I
>> >> am writing a script that runs a df command and I need parts of that
>> >> output saved in 2 different variables.  Is this something that can be
>> >> done?  I can do this by running multiple df commands but would prefer
>> >> to make only one call:
>> >>
>> >> --
>> >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%'
>> ' '"
>> >> output  = subprocess.check_output( inode_cmd,
>> >> stderr=subprocess.STDOUT, shell=True )
>> >> --
>> >>
>> >> But this would end up giving me the following:
>> >>
>> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
>> >>5   1
>> >>
>> >> I would like variable x to be 5 and variable y to be 1.  Is there a
>> >> easier way to do this?
>> >>
>> >> Thanks in advance for your guidance.
>> >> --
>> >> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Basic python question

[Aldwin Pollefeyt]

Oh, sorry .. please try this:

>>> x,y = tuple(output.split())

On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma  wrote:

> Thanks Aldwin that helps but it looks like it is reversing the numbers
> for some reason:
>
> the df command returns the following:
> 7  2
>
> I used your example and did:
> x,y = set(output.split())
>
> My assumption would be that x should be 7 and y should be 2.  However,
> when I print x and y it seems to be reversed (x is 2 and y is 7).  Am
> I missing something?
>
> Thanks
>
> On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt
>  wrote:
> >
> > You could use:
> >
> > >>> x, y = set(output.split())
> >
> > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma  wrote:
> >>
> >> Hello,
> >>
> >> I am new to python and trying to do some basic things with python.  I
> >> am writing a script that runs a df command and I need parts of that
> >> output saved in 2 different variables.  Is this something that can be
> >> done?  I can do this by running multiple df commands but would prefer
> >> to make only one call:
> >>
> >> --
> >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' '
> '"
> >> output  = subprocess.check_output( inode_cmd,
> >> stderr=subprocess.STDOUT, shell=True )
> >> --
> >>
> >> But this would end up giving me the following:
> >>
> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
> >>5   1
> >>
> >> I would like variable x to be 5 and variable y to be 1.  Is there a
> >> easier way to do this?
> >>
> >> Thanks in advance for your guidance.
> >> --
> >> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Basic python question

[Jagga Soorma]

Thanks Aldwin that helps but it looks like it is reversing the numbers
for some reason:

the df command returns the following:
7  2

I used your example and did:
x,y = set(output.split())

My assumption would be that x should be 7 and y should be 2.  However,
when I print x and y it seems to be reversed (x is 2 and y is 7).  Am
I missing something?

Thanks

On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt
 wrote:
>
> You could use:
>
> >>> x, y = set(output.split())
>
> On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma  wrote:
>>
>> Hello,
>>
>> I am new to python and trying to do some basic things with python.  I
>> am writing a script that runs a df command and I need parts of that
>> output saved in 2 different variables.  Is this something that can be
>> done?  I can do this by running multiple df commands but would prefer
>> to make only one call:
>>
>> --
>> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '"
>> output  = subprocess.check_output( inode_cmd,
>> stderr=subprocess.STDOUT, shell=True )
>> --
>>
>> But this would end up giving me the following:
>>
>> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
>>5   1
>>
>> I would like variable x to be 5 and variable y to be 1.  Is there a
>> easier way to do this?
>>
>> Thanks in advance for your guidance.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[Kyle Stanley]

Change by Kyle Stanley :


--
keywords: +patch
pull_requests: +16140
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16552

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Basic python question

[Aldwin Pollefeyt]

You could use:

>>> x, y = set(output.split())

On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma  wrote:

> Hello,
>
> I am new to python and trying to do some basic things with python.  I
> am writing a script that runs a df command and I need parts of that
> output saved in 2 different variables.  Is this something that can be
> done?  I can do this by running multiple df commands but would prefer
> to make only one call:
>
> --
> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '"
> output  = subprocess.check_output( inode_cmd,
> stderr=subprocess.STDOUT, shell=True )
> --
>
> But this would end up giving me the following:
>
> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
>5   1
>
> I would like variable x to be 5 and variable y to be 1.  Is there a
> easier way to do this?
>
> Thanks in advance for your guidance.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Basic python question

[Jagga Soorma]

Hello,

I am new to python and trying to do some basic things with python.  I
am writing a script that runs a df command and I need parts of that
output saved in 2 different variables.  Is this something that can be
done?  I can do this by running multiple df commands but would prefer
to make only one call:

--
inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '"
output  = subprocess.check_output( inode_cmd,
stderr=subprocess.STDOUT, shell=True )
--

But this would end up giving me the following:

#df --output=pcent,ipcent /var | grep -v Use | tr '%' ' '
   5   1

I would like variable x to be 5 and variable y to be 1.  Is there a
easier way to do this?

Thanks in advance for your guidance.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38333] add type signatures to library function docs

[paul rubin]

paul rubin  added the comment:

abs takes any value that understands the __abs__ method and returns something 
of the same type.  In fact there is already a type protocol for it:

https://mypy.readthedocs.io/en/stable/protocols.html#supportsabs-t

So abs's signature would be (x : Abs[T]) -> T where T is a type parameter.  

I'm sure there are some examples where no good signature is possible, but lots 
of others are fine.  Someone did a Smalltalk study long ago and found that most 
functions were monomorphic in practice even though Smalltalk is dynamically 
typed like Python.  As a matter of style, Python code tends to be typed even 
when it doesn't have to be.  Not all the time of course.

I'm still getting used to types and mypy (I was a py2 holdout til quite 
recently, and mypy has been a more attractive reason to change than any of the 
other stuff) and I do keep noticing cases that don't work as I hoped, but it's 
still a good move in general.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Raymond Hettinger]

Raymond Hettinger  added the comment:

>  (Not that I can think of others off the top of my head.)

For the most part, templating examples can be switched to the .format() style 
but shouldn't be switched to f-strings.  The former technique is still 
necessary if someone wants to move templates to an external file or if they 
need to use gettext() i18n, f-strings don't work well in the latter case.

Also note, there are no plans to completely remove old-style formatting.  
AFAICT, it will be around forever, so people still need to see some examples of 
each.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[Kyle Stanley]

Kyle Stanley  added the comment:

> Another consideration is if we want this method to join the threads to be 
> called in `ThreadedChildWatcher.close()`.

An additional benefit of having the method called from `close()` is that it 
means we don't have to modify the tests directly. Also, ThreadedChildWatcher's 
implementation of `close()` does nothing at the moment.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[Kyle Stanley]

Kyle Stanley  added the comment:

First I'll work on adding a new method. Here's a few potential names, ordered 
roughly by my preferences:

1) join_threads()

2) shutdown_threads()

3) shutdown_threadpool()

The first and second options are roughly equal, but I think join_threads() is a 
bit more specific to what this is doing.

The third option is because a group of threads could be considered a 
"threadpool", but ThreadedChildWatcher doesn't utilize a dedicated threadpool 
class of any form, it just uses an internal dict named `_threads` that maps 
process IDs to threads. So this name might be potentially misleading.

I'm also wondering whether or not this method should have a timeout parameter 
that defaults to None. I'm thinking we can probably leave it out for now, but I 
wanted to hear some other opinions on this.

For now, I'll be implementing this as a regular method, but I could make it a 
coroutine if that's desired. Admittedly, I don't enough have knowledge of the 
realistic use cases for ThreadedChildWatcher to know if it would be 
particularly useful to have an awaitable method to join the threads.

Another consideration is if we want this method to join the threads to be 
called in `ThreadedChildWatcher.close()`. I think it makes sense from a design 
perspective to join all of the threads when the close method is used. 

Plus, it would allow the method to be integrated with the tests better. 
Currently, the test uses the same `setUp()` and `tearDown()` for each of the 
different subprocess watchers. If it weren't called in the `close()` method, 
we'd have to add an `if isinstance(watcher, ThreadedChildWatcher)` conditional 
in `tearDown()`. So, I would prefer to have the method called from `close()`.

Finally, should this method be part of the public API, or just a private 
method? As mentioned earlier, I'm not overly aware of the realistic use cases 
for ThreadedChildWatcher. As a result, I don't know if it would be especially 
useful for users to call this method independently, especially if this were 
called from `close()` as I was suggesting earlier. 

After we reach a consensus on the implementation details and API design for the 
new method, I'll work on adding an entry in the documentation (if it should be 
public) and updating test_subprocess.SubprocessThreadedWatcherTests to utilize 
it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[Vedran Čačić]

Vedran Čačić  added the comment:

In that case, I'm pretty sure you'd never be able to document almost _any_ 
function signature. Python is simply not a statically typed language, and we 
love it because of that.

Ok, go to the list of builtins, and start alphabetically. First is abs. What 
type does it take, and what type does it return? Again, I'd be completely ok 
with saying it takes an int, a float, or a complex, and returns either an int 
or a float. The same as the words in the docs already say. But according to 
Guido, that's "unacceptable", since abs can also take (and return) a 
datetime.timedelta, for example.

I am very afraid that if we start doing this, we will lose _many_ useful 
features that make Python the language it is. It's really not worth it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

It seems that it's still being worked on from gcc's side:

https://gcc.gnu.org/bugzilla//show_bug.cgi?id=78685

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38357] print adding extra bytes in hex above x7F

[Artificial]

Artificial  added the comment:

Thanks, Arfrever

Seems unnecessarily complicated for what worked in Python2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

Definitely agree with Eric on this; code modernization is definitely on the 
risky side, so judicious updates are important. (Of course, not updating is 
also a risk, eventually. But not much of one in this case.)

This issue is really about whether the docs should be updated to use the newer 
syntax. In general, I think we should update the docs, and we've delayed long 
enough for the general application of f-strings.

There will be cases to be wary of, certainly. I'm thinking especially of calls 
to the logging methods, or anywhere else doing delayed formatting. (Not that I 
can think of others off the top of my head.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38357] print adding extra bytes in hex above x7F

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

However print() called with non-str argument would firstly call str() on it, 
which is most likely not what reporter wanted:

>>> print(b'\x80')
b'\x80'
>>> str(b"\x80")
"b'\\x80'"
>>> print(str(b"\x80"))
b'\x80'

$ python -c "print(b'\x80')" > test.txt
$ xxd test.txt
: 6227 5c78 3830 270a  b'\x80'.


Proper solution is to write to files opened in binary mode, which in case of 
stdout and stderr means to use sys.stdout.buffer and sys.stderr.buffer:

>>> sys.stdout.buffer.write(b"\x80")
�1

$ python -c "import sys; sys.stdout.buffer.write(b'\x80')" > test.txt
$ xxd test.txt
: 80   .

--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[Benjamin Peterson]

Benjamin Peterson  added the comment:

If -Og is breaking debugging, isn't that a compiler bug? The GCC manpage claims 
" -Og enables optimizations that do not interfere with debugging."

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Eric V. Smith]

Eric V. Smith  added the comment:

>> I definitely think we should not modify any code in the stdlib just to 
>> switch to f-strings.

> Does this also apply to updating code to use f-strings in an area that's 
> already being modified for a functional purpose? 

No. As I said, not just to switch to f-strings. If other changes are also being 
made, discretion is advised. Just like any other cleanup.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38357] print adding extra bytes in hex above x7F

[Ammar Askar]

Ammar Askar  added the comment:

If you're trying to get raw bytes, you need to use

print(b'\x80')

what's happening right now is that the '\x80' is treated as a unicode code 
point (see https://docs.python.org/3/howto/unicode.html#the-string-type), and 
when Python goes to print it, it gets encoded to the raw underlying bytes. 
Which, in the default encoding of utf-8 requires the extra byte.

>>> '\x80'.encode()
b'\xc2\x80'

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38352] In typing docs, note explicit import needed for IO and Pattern/Match

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38357] print adding extra bytes in hex above x7F

[Artificial]

Artificial  added the comment:

python3 -c "print('\x7F')" > test.txt && xxd test.txt
: 7f0a ..   


python3 -c "print('\x80')" > test.txt && xxd test.txt
: c280 0a  ...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Correction, not fail, just a ton of warnings. The same is true for 
-D_FORTIFY_SOURCE=1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Kyle Stanley]

Kyle Stanley  added the comment:

> I definitely think we should not modify any code in the stdlib just to switch 
> to f-strings.

Does this also apply to updating code to use f-strings in an area that's 
already being modified for a functional purpose? 

I agree that that we shouldn't update stdlib code for the sole purpose of 
switching to f-strings, but if a function or method is already being changed 
for another purpose, I don't think updating the formatting to use f-strings is 
an issue. This would probably have to be decided on a case-by-case basis though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38357] print adding extra bytes in hex above x7F

[Artificial]

New submission from Artificial :

Any hex str of value above \x7F causes an extra byte to printed.

--
files: Screenshot from 2019-10-02 20-31-50.png
messages: 353796
nosy: Artificial
priority: normal
severity: normal
status: open
title: print adding extra bytes in hex above x7F
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48641/Screenshot from 2019-10-02 
20-31-50.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Do note though that if the -D_FORTIFY_SOURCE=2 hardening flag is used, the 
compilation will fail with an optimization level less than -Og.

Haven't tried yet with -D_FORTIFY_SOURCE=1 to see if it works with -O0.

--
nosy: +cstratak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38342] ImportError: cannot import name 'MetadataPathFinder' from 'importlib.metadata'

[Dima Tisnek]

Change by Dima Tisnek :


--
nosy: +Dima.Tisnek

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Eric V. Smith]

Eric V. Smith  added the comment:

I definitely think we should not modify any code in the stdlib just to switch 
to f-strings.

I think the code examples in the docs would benefit from a consistent style, 
and since f-strings are the least verbose way to format strings, I'd endorse 
using them except where .format or %-formatting is the point of the example.

I agree with Fred that hearing from Julien would be helpful.

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ipython in different loctions.

[Hongyi Zhao]

On Thu, 03 Oct 2019 10:19:23 +1000, Cameron Simpson wrote:

>   bash -x ~/.pyenv/shims/ipython3
> 
> and see what its final command does.

Tried as follows:

-
werner@localhost:~$ bash -x ~/.pyenv/shims/ipython3
+ set -e
+ '[' -n '' ']'
+ program=ipython3
+ [[ ipython3 = \p\y\t\h\o\n* ]]
+ export PYENV_ROOT=/home/werner/.pyenv
+ PYENV_ROOT=/home/werner/.pyenv
+ exec /home/werner/.pyenv/libexec/pyenv exec ipython3
Python 3.7.4 (default, Aug 29 2019, 06:59:32) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: 
-

Also tried the follows:

werner@localhost:~$ bash -x ~/.local/bin/ipython3
+ import re
+ import sys
+ from IPython import start_ipython
from: can't read /var/mail/IPython
/home/werner/.local/bin/ipython3: line 10: syntax error near unexpected 
token `('
/home/werner/.local/bin/ipython3: line 10: `sys.argv[0] = re.sub(r'(-
script\.pyw?|\.exe)?$', '', sys.argv[0])'
werner@localhost:~$ 


The former can start the ipython, while the latter will fail.


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

[issue19683] test_minidom has many empty tests

[karl]

karl  added the comment:

@zach.ware
@r.david.murray


So I was looking at that issue. There is a lot of work. 

I had a couple of questions, because there are different categories


# Empty tests for existing functions.

This seems to be straightforward as they would complete the module.

Example:
```python
def testGetAttributeNode(self): pass
```
https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/test/test_minidom.py#L412

which refers to: `GetAttributeNode`
https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/xml/dom/minidom.py#L765-L768
https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/test/test_minidom.py#L285-L294



# Tests without any logical reference in the module.

This is puzzling because I'm not sure which DOM feature they should be testing.

For example:

```
def testGetAttrList(self):
pass
```

https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/test/test_minidom.py#L383-L384


Or maybe this is just supposed to test Element.attributes returning a list of 
attributes, such as 
`NamedNodeMap [ def="ghi", jkl="mno"]` returned by a browser.


```
>>> import xml.dom.minidom
>>> from xml.dom.minidom import parse, Node, Document, parseString
>>> from xml.dom.minidom import getDOMImplementation
>>> dom = parseString("")
>>> el = dom.documentElement
>>> el.setAttribute("def", "ghi")
>>> el.setAttribute("jkl", "mno")
>>> el.attributes

```

or is it supposed to test something like 

```
>>> el.attributes.items()
[('def', 'ghi'), ('jkl', 'mno')]
```

This is slightly confusing. And the missing docstrings are not making it easier.



# Tests which do not really test the module(?)

I think for example about this, which is testing that `del` is working, but it 
doesn't have anything to do with the DOM. 

```
def testDeleteAttr(self):
dom = Document()
child = dom.appendChild(dom.createElement("abc"))

self.confirm(len(child.attributes) == 0)
child.setAttribute("def", "ghi")
self.confirm(len(child.attributes) == 1)
del child.attributes["def"]
self.confirm(len(child.attributes) == 0)
dom.unlink()
```

https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/test/test_minidom.py#L285-L294

Specifically when there is a function for it: `removeAttribute`
https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-6D6AC0F9 

which is tested just below that test.
https://github.com/python/cpython/blob/3e04cd268ee9a57f95dc78d8974b21a6fac3f666/Lib/test/test_minidom.py#L296-L305

so I guess these should be removed or do I miss something in the testing logic?




# Missing docstrings.

Both the testing module and the module lack a lot of docstrings.
Would it be good to fix this too, probably in a separate commit.



# DOM Level 2

So the module intent is to implement DOM Level 2.
but does that make sense in the light of 
https://dom.spec.whatwg.org/

Should minidom tries to follow the current DOM spec?

--
nosy: +karlcow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ipython in different loctions.

[Cameron Simpson]

On 02Oct2019 07:37, Hongyi Zhao  wrote:

I noticed that the ipython on my Debian box located in the following
locations:

werner@localhost:~$ ls .local/bin/ipython*
.local/bin/ipython  .local/bin/ipython3

werner@localhost:~$ ls .pyenv/shims/ipython*
.pyenv/shims/ipython  .pyenv/shims/ipython3


I would guess that the former came from "pip install ipython" and that 
the latter came from an an environment set up with pyenv.



And, they are different:


werner@localhost:~$ diff .pyenv/shims/ipython3 .local/bin/ipython3
1,3c1
< #!/usr/bin/env bash


This is a small shell script wrapper, presumably hooking into your pyenv 
setup to find the "real" ipython.



from IPython import start_ipython
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(start_ipython())


This is the Python boilerplate wrapper with pip uses to install an 
ipython executable script in a bin directory.


You may find that the shell script from .pyenv/shims eventually executes 
a python script like the one from .local/bin. Try going:


 bash -x ~/.pyenv/shims/ipython3

and see what its final command does.

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

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[Kyle Stanley]

Kyle Stanley  added the comment:

I can try to work on fixing this.

--
nosy: +aeros167

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Kyle Stanley]

Kyle Stanley  added the comment:

> so it would be a good candidate for the "newcomer friendly" label

Never mind, just noticed this was already labeled as newcomer friendly. I only 
saw the "easy" label at first. (:

If consensus is reached for this, we can open a separate issue for addressing 
the other doc files, something along the lines of "Update code examples to use 
f-strings". As mentioned earlier I think it would be worth having each new 
contributor update all of the instances in a single *.rst in a PR, but it can 
be a single issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Kyle Stanley]

Kyle Stanley  added the comment:

Welcome back from the OOOS break Mariatta!

> My question (and it's just that) is whether we've made a decision to prefer 
> one formatting syntax over others (outside of examples discussing the 
> formatting approaches themselves).

I agree that we should reach a consensus on the preferred string formatting 
style. However, there seems to be two separate questions here:

1) Should the code examples in the docs be updated to use f-strings?

2) Should ALL instances of the old string formatting be updated to use 
f-strings? This would affect every *.py; potentially leading to additional code 
churn, which adds clutter to the commit logs and git blame.

The first one is far less costly and has very minimal risk of breakage. The 
cost of updating every *.py to use f-strings is worth considering, but is 
significantly higher and has more potential consequences, especially for the 
regression tests. I'm personally in favor of updating the code examples first 
and discussing the second question in a python-dev thread due to the wide 
impact.

> If a decision is made to prefer one over others, it's worth making that 
> decision separately, and then using separate PRs to deal with updates to 
> different parts of the docs.

Once we reach a decision on the matter, I think this particular issue could 
serve as a great first PR for a new contributor to become familiar with the 
workflow, so it would be a good candidate for the "newcomer friendly" label. 
Most python users are well acquainted with string formatting. I wouldn't mind 
opening a PR to fix it myself, but I think that leaving it open for a new 
contributor to work on as an intro to the workflow would be far more beneficial.

Although there may be a benefit to use f-strings instead here, there's 
certainly no rush to have it completed in a short period of time. I would be in 
favor of having each PR address a single documentation file. This would help 
accelerate the review process and provide a valuable learning experience to a 
greater number of new contributors, in comparison to a single PR that updates 
every single code example in the docs.

--
nosy: +aeros167

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38318] Issues linking with ncurses and tinfo (cannot resolve symbols)

[Michael Everitt]

Michael Everitt  added the comment:

Attached patch seems to fix build with python3.6 withh uclibc-ng.

Tested on x86_64 and ARMv6zk.

--
Added file: 
https://bugs.python.org/file48640/fix-tinfo-probably-python-3_6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38318] Issues linking with ncurses and tinfo (cannot resolve symbols)

[Michael Everitt]

Michael Everitt  added the comment:

Attached patch seems to fix build failure for python2.7 with uclibc-ng.

--
keywords: +patch
Added file: 
https://bugs.python.org/file48639/fix-tinfo-probably-python-2_7.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

I agree that it's less invasive and easier to review.

My question (and it's just that) is whether we've made a decision to prefer one 
formatting syntax over others (outside of examples discussing the formatting 
approaches themselves).

If a decision is made to prefer one over others, it's worth making that 
decision separately, and then using separate PRs to deal with updates to 
different parts of the docs.

Added Julien Palard to the issue; I'd value input on this.

--
nosy: +JulienPalard

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3e04cd268ee9a57f95dc78d8974b21a6fac3f666 by Victor Stinner in 
branch 'master':
bpo-36670, regrtest: Fix WindowsLoadTracker() for partial line (GH-16550)
https://github.com/python/cpython/commit/3e04cd268ee9a57f95dc78d8974b21a6fac3f666


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: pathlib

[DL Neil via Python-list]

On 3/10/19 12:42 AM, Dan Sommers wrote:

On 10/2/19 4:14 AM, DL Neil via Python-list wrote:


In the case that sparked this enquiry, and in most others, there is no
need for a path that doesn't actually lead somewhere. The paths that are
used, identify files, open them, rename them, create directories, etc.
The idea of a path that just 'exists' (sorry!), without being part of
some purpose, seems odd.


Think about preferences.  Users can put preferences in (e.g.)
~/.config/prefs, admins might provide "local" preferences in
/etc/prefs, and the developers might provide fallback preferences
in /etc/prefs.

When the application starts up, it could have a list of paths to files
that may or may not exist.


This is an excellent example. Without thinking I would have left such 
as-is. However, what I'm taking-in, is that in order to gain advantage 
from the semantic meaning inherent in the Path class(es), I shouldn't 
leave these as strings (the way they arrive from (current) config 
files*) but they should be defined as (Pure) Paths in the same way that 
numbers will probably be converted from string inputs. As you say, 
because system-defaults may be over-ridden by user-prefs, there's no 
point in 'proving' that such a file exists - such can wait until we 
actually issue the .open()


That said, surely we would still use a 'concrete' class, in case?


* in the case of YAML files, might we even be able to define those 
values as Path()-s...




Or think about the shell in that failed "cat" command.  It's
possible that cat created a path from what the user typed and
then tried to open it.  For that brief moment, cat had a path
to a file that didn't exist, however un-useful it may have been.

At this time (and assuming that after two (separate) incidents dragging
me away to solve other people's problems, I intend to stick with trying
to get my head around pathlib - even if I have to sub-class it (which my
reading shows is another 'can of worms'). So, 'reading' is about all
I've accomplished since the original post. Sadly, the majority of posts
seem to have come from other confused-minds - many of whom seemed to be
giving-up in disgust. If true, such represents TWO failures! I'm sure
that the designer(s) had a clear vision (having watched previous
attempts rise-and-fall), but per earlier in this discussion, maybe the
explanation and 'vision' could be better communicated to us simple-boys?


I don't think anyone gave up in disgust.  Yes, there was some


Late at night: I used the word "posts" twice, to describe two quite 
different communications. Apologies


The subject of that comment was the (other) research/reading I've been 
doing. No-one on THIS list has given the impression of wanting to dump 
pathlib (which encourages my persisting).


Certainly, although some may have quietly given-up talking to a non-OOP 
native - and one so 'slow', I am appreciative of all help-given!




disagreement, and now the discussion has slowed or stopped, but  > think your 
original question was answered:  Path objects,
apparently by an arguably questionable design, fail to meet your
expecation, and some simple changes end up breaking backwards
compatibility.  Maybe a documentation change could prevent others
from experiencing the same expectation failure.


As discussed previously, and elsewhere (just now).



Maybe you could implement one of the proposed changes in a private
library function as a workaround?


In my mind, I'm wondering if it will come to that (having 'got past' the 
original observation/issue, I'm concerned by .rename()'s silent errors, 
for example). However, that 'outside' research, eg StackOverflow, shows 
that sub-classing pathlib is problematic, and quite possibly not part of 
the design (this is repeating 'gossip' - I'm not going to try to justify 
the comment or the claim). That said, last night my code sub-classing 
Path() seemed to work quite happily (albeit only tested on a 'Posix' 
box). The yawning chasm/gaping jaws below, however, are that I've 
probably made yet another 'assumption' about how things 'should' work. 
Run for the hills!


This was supposed to be a simple, down-time task; a learning-opportunity 
re-factoring code to use a new (er, um, as of v3.4) library...


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

[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Also this is due to an expected behaviour from gcc. From the documentation:

"If you use multiple -O options, with or without level numbers, the last such 
option is the one that is effective. "

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

[STINNER Victor]

New submission from STINNER Victor :

Warning seen o AMD64 Ubuntu Shared 3.x buildbot:
https://buildbot.python.org/all/#/builders/141/builds/2593

test_devnull_output 
(test.test_a=syncio.test_subprocess.SubprocessThreadedWatcherTests) ...
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 
2)

The ThreadedChildWatcher class of asyncio.unix_events doesn't seem to have a 
method to join all threads. It should be done in tests to prevent "leaking" 
threads which can have side effects on following tests.

--
components: Tests, asyncio
messages: 353784
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: SubprocessThreadedWatcherTests leaks threads
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38355] ntpath.realpath() fails on sys.executable

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +16139
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16551

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[STINNER Victor]

STINNER Victor  added the comment:

Ok, I managed to reproduce the bug using this change:

diff --git a/Lib/test/libregrtest/win_utils.py 
b/Lib/test/libregrtest/win_utils.py
index f0c17b906f..78429faa89 100644
--- a/Lib/test/libregrtest/win_utils.py
+++ b/Lib/test/libregrtest/win_utils.py
@@ -14,7 +14,7 @@ BUFSIZE = 8192
 LOAD_FACTOR_1 = 0.9200444146293232478931553241
 
 # Seconds per measurement
-SAMPLING_INTERVAL = 5
+SAMPLING_INTERVAL = 0
 # Windows registry subkey of HKEY_LOCAL_MACHINE where the counter names
 # of typeperf are registered
 COUNTER_REGISTRY_KEY = (r"SOFTWARE\Microsoft\Windows NT\CurrentVersion"


I wrote PR 16550 to handle partial lines.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16138
pull_request: https://github.com/python/cpython/pull/16550

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38355] ntpath.realpath() fails on sys.executable

[Steve Dower]

New submission from Steve Dower :

The change to error handling did not include ERROR_CANT_ACCESS_FILE, but this 
error occurs in the Store package install.

After suppressing this error, it then occurs again when stripping the prefix - 
we should just check for the same error here to determine whether it's safe to 
remove the prefix of a file we can't access.

--
assignee: steve.dower
components: Windows
keywords: 3.8regression
messages: 353782
nosy: lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: ntpath.realpath() fails on sys.executable
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: pathlib

[DL Neil via Python-list]

On 3/10/19 3:07 AM, Rhodri James wrote:

On 02/10/2019 09:14, DL Neil via Python-list wrote:
That said, it is one of the ways that a path can be shown to 
transition from some 'pure' state to become 'concrete'.


However, A.N.Other has suggested that I might be mis-applying the word 
"concrete", so maybe not. On which topic, I went looking for a decent 
technical definition of the word, but instead of coming-out smiling, 
I've been left somewhat stony-faced (hah, hah!).


A definition/description would be useful. Any pointers?


I think we're looking at a philosophical split, so I'd look in that 
direction rather than for technical terminology.


My rough and ready definition *in this instance* relies on observing 
that we are supposed to contrast "pure" and "concrete" and going from 
there.


The overriding thing for me is that paths are names.  Just names.  They 
have a particular syntax, but that's all.  This is obviously true for 
pure paths, which are clearly abstractions. 
PurePath("/home/rhodri/foo.txt") cannot refer to a real file because it 
has no mechanisms for relating to reality.  It can only be a name, and 
all the PurePath class gives us is convenient mechanisms for 
manipulating that name within its syntactic rules.


Concrete paths are not pure paths.  Literally, in logic terms.  Pure 
paths cannot refer to real file, concrete paths can refer to real files. 
  They don't necessarily do so otherwise we have a massive excluded 
middle.  Path("/home/rhodri/foo.txt") may or may not actually exist on 
any computer.  It may refer to a file, and by the end of this sentence 
it may refer to a different file to what it was at the start.  The only 
sensible interpretation I can see is that it is still a name, just one 
that may transiently be related to a real object.


Concrete may not be the best term for this, but I can't think of a 
better one.



Nor I, but had assumed (having seen it before) that it was a 
generally-accepted term in OOP that I have yet to learn. Was slightly 
surprised not to find it in any of the/my usual tech.dictionaries.


Obviously, my assumptions/expectations of its meaning were inaccurate or 
incomplete, but I appreciate your efforts to straighten-out it (and me)!

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

Re: pathlib

[DL Neil via Python-list]

On 3/10/19 6:25 AM, Barry Scott wrote:
On 2 Oct 2019, at 09:14, DL Neil via Python-list 
mailto:python-list@python.org>> wrote:

On 2/10/19 12:52 AM, Rhodri James wrote:

On 01/10/2019 06:03, DL Neil via Python-list wrote:

On 30/09/19 9:28 PM, Barry Scott wrote:
On 30 Sep 2019, at 05:40, DL Neil via Python-list 
mailto:python-list@python.org>> wrote:


Should pathlib reflect changes it has made to the file-system?


I think it should not.


The term "concrete" is applied to Path(), PosixPath(), and 
WindowsPath() - whereas the others are differentiated with the 
prefix "Pure".


I take "concrete" to mean 'existing in reality or real experience'. 
Thus, I saw the Pure* entities as supporting abstract paths, but the 
concrete entities as representing (and reflecting) real-world (file 
system) entities.


Thus, there is no need for .exists() to be available in the Pure 
paths, but there is when utilising their concrete implementations.
Sorry but your logic is inconsistent here.  For starters, it's not 
that there's no need for .exists() in Pure paths, it's that .exists() 
is meaningless.  Pure paths aren't related to any actual filing 
system (to paraphrase you), so existence isn't an option.
However if you insist that "concrete" means "existing in reality", 
then .exists() is unnecessary because by your very definition the 
path must exist.  The very act of creating the Path object would 
create the corresponding file or directory.  So either pathlib does 
something horrific, or your definition is wrong.



Very good! Yes, I'd picked-on .exists() purely (hah!) because it does 
not appear in PurePaths, but does in concrete Paths.





On which topic, I went looking for a decent technical definition of 
the word, but instead of coming-out smiling, I've been left somewhat 
stony-faced (hah, hah!).


"concrete

  *
adj.
Of or relating to an actual, specific thing or instance; particular.
"


That said, it is one of the ways that a path can be shown to 
transition from some 'pure' state to become 'concrete'.


However, A.N.Other has suggested that I might be mis-applying the word 
"concrete", so maybe not.


Concrete means a specific operating system's filesystem rules, Windows 
or Posix.


At last the gears have stopped grinding! (cement dust?)

The distinction of "pure", as distinct from "concrete", was readily grasped.

The idea that "concrete" refers to FS rules, cf files on the FS, has 
been what so many have been battling to lodge between my ears. Well done!


Also, nicely stated.

In view of my not being the only one to arrive with similar 
expectations, do you/we feel that this is carefully and sufficiently 
conveyed within the (PSL) documentation?

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

[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Dug a bit further here.

The issue is that CFLAGS_NODIST will always come after normal CFLAGS (which are 
subsets of PY_CFLAGS and PY_CFLAGS_NODIST) [0][1].

The EXTRA_CFLAGS variable is appended at the end of PY_CFLAGS [2], hence as 
reported here, whatever compiler flag comes after, embedded within 
PY_CFLAGS_NODIST, will override the previous flags if they contradict each 
other.

So basically EXTRA_CFLAGS can be used only for flags that can't be overwritten 
by PY_CFLAGS_NODIST, which in my opinion, is not very useful in the context of 
just adding extra flags.

Commit adding the variable to Python 2.5: 
https://github.com/python/cpython/commit/08cd598c2145d00f1517c93cabf80a5d7d2a4bc0

"EXTRA_CFLAGS has been introduced as an environment variable to hold compiler 
flags that change binary compatibility"

Apparently it was added in order to avoid using the OPT variable for the 
various debug builds described in 
https://github.com/python/cpython/blob/master/Misc/SpecialBuilds.txt

On another note this flag will get passed down to distutils, so if it was used 
for building the interpreter, C extensions compiled by users will also inherit 
it.

Honestly I am not sure what the best solution would be here. If the various 
sub-debug special builds are still relevant and they stack, by doing for 
example $ make CFLAGS_NODIST="-DPy_TRACE_REFS" EXTRA_CFLAGS="-DPy_REF_DEBUG" 
then the issue can be closed, and the documentation can be more explicit that 
the EXTRA_CFLAGS is to be used only for the special builds.

If the EXTRA_CFLAGS can also be used for adding our own flags, then the flag 
handling needs to change to take this into account.

[0] https://github.com/python/cpython/blob/master/setup.py#L85
[1] https://github.com/python/cpython/blob/master/Makefile.pre.in#L115
[2] https://github.com/python/cpython/blob/master/Makefile.pre.in#L97

--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

[Enji Cooper]

Enji Cooper  added the comment:

Capturing more context here, based on internal discussion: other handlers are 
doing address resolution in `emit()` (HTTPHandler, SMTPHandler), which is 
expensive. In order for SysLogHandler to not regress behavior and not become 
expensive, performance-wise, it would probably be best to use 
`functools.lru_cache()`, using the address and a timeout as the key when 
resolving the addresses to avoid always doing address resolutions, e.g., DNS 
lookups: https://docs.python.org/3/library/functools.html#functools.lru_cache .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[David Bolen]

David Bolen  added the comment:

I've confirmed the partial read with some local modifications, and the failures 
are always split between time stamp and value:

Warning -- Failed to parse typeperf output: '"10/02/2019 17:42:26.229"'
0.0
Warning -- Missing first field: ,"0.00"
0.0

Adding multiple variables to the typeperf command can vary the split position, 
but I've only seen it at a variable boundary (starting with the comma).  So I'm 
guessing with the current implementation the above is probably the only point 
where the I/Os can be interleaved.

Also, CRLF seems to only appear at the start of each read, never at the end.  
You can see that behavior interactively too where the cursor waits at the end 
of the line between samples.  So changes to wait for a complete line to be read 
would also delay load values by one sample interval.

So I'm thinking just reverting to silently ignoring this case is probably 
simplest.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[Guido van Rossum]

Guido van Rossum  added the comment:

@phr

To be clear, I agree that there's nothing wrong with adding signatures to docs. 
We just need to find a way to do it. There will definitely be some cases where 
it's better not to have a type rather than trying to spell out the actual type 
in the docs.

My "unacceptable" comment was meant in response to Vedran's suggestion that it 
would be okay to lie in the docs about the signature for sum(). If the truth is 
too subtle to use a specific type signature we should keep the words. (The 
words for sum() are actually pretty clear.)

FWIW: My objection against vague docs was specifically about situations where 
the word "string" is used without clarifying if this allows bytes. I've also 
seen docs that were even more vague, e.g. "a name" or "a filename".

Signatures in the code won't "break" the code (they are ignored at runtime) but 
if present they should nevertheless be precise since they will be used by type 
checkers. Signatures in code are *not* just documentation. Only in very limited 
situations would I be okay with lies in signatures -- this would have to be 
done on a case by case basis.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38353] Cleanup the path configuration implementation code (getpath.c)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16137
pull_request: https://github.com/python/cpython/pull/16549

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38353] Cleanup the path configuration implementation code (getpath.c)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 61691d833631fed42b86605b09e1535e3e8d40e5 by Victor Stinner in 
branch 'master':
bpo-38353: Cleanup includes in the internal C API (GH-16548)
https://github.com/python/cpython/commit/61691d833631fed42b86605b09e1535e3e8d40e5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[paul rubin]

paul rubin  added the comment:

Yes, the suggestion was just for the docs, and since those are intended for 
human rather than machine consumption, it's fine if there are some blurry cases 
where there is no signature.  Ideally in those cases, the issue should be 
explained in the doc text.

I actually don't see what's wrong with including signatures in the source code 
as well, as long as doing so doesn't break anyone's existing code.  I agree 
with Veky that one should be very hesitant about breaking existing working 
code, even if that code relies on undocumented behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

[Enji Cooper]

Change by Enji Cooper :


--
title: Fix for bug 30378 regressed SysLogHandler -> Fix for bug 30378 regressed 
SysLogHandler by making it resolve addresses at initialization instead of in 
`.emit()`

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38354] Fix for bug 30378 regressed SysLogHandler

[Enji Cooper]

New submission from Enji Cooper :

The change made for bug 30378 caused a regression in our code by making
lookups for SysLogHandler addresses at init time, instead of making them more 
lazy. Example:

>>> import logging.handlers
>>> LOGGER = logging.getLogger("logger")
>>> LOGGER.addHandler(logging.handlers.SysLogHandler(address=('resolvessometimesbutnotthefirsttime.com',
>>>  logging.handlers.SYSLOG_UDP_PORT)))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python2.7/logging/handlers.py", line 767, in __init__
ress = socket.getaddrinfo(host, port, 0, socktype)
socket.gaierror: [Errno -2] Name or service not known

This is exacerbated by the fact that a lot of code the organization I work for 
(and to be honest, I have written in the past) initializes global loggers once 
at import time. If the SysLogHandler is added to the global logger and the DNS 
resolution isn't possible (/etc/hosts is empty on Unix or does not contain the 
entry, and DNS out is to lunch), it will fall on its face at initialization 
time.

There needs to be a more graceful way of initializing loggers like this, or a 
way of delaying the host resolution, so it fails gracefully and doesn't crash 
the entire program (restoring the previous behavior).

Example: SMTPHandler doesn't do name resolution until it calls emit, which 
seems like a much more logical place to do the operation (especially since DNS 
records can change or become invalid).

--
components: Library (Lib)
messages: 353775
nosy: calcheng, ngie
priority: normal
severity: normal
status: open
title: Fix for bug 30378 regressed SysLogHandler
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38353] Cleanup the path configuration implementation code (getpath.c)

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +16136
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16548

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38353] Cleanup the path configuration implementation code (getpath.c)

[STINNER Victor]

New submission from STINNER Victor :

Place holder issue for changes related to path configuration cleanup changes 
(Modules/getpath.c).

--
components: Interpreter Core
messages: 353774
nosy: vstinner
priority: normal
severity: normal
status: open
title: Cleanup the path configuration implementation code (getpath.c)
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38014] Python 3.7 does not compile

[Matej Cepl]

Matej Cepl  added the comment:

Sorry, got confused. My openSUSE bug has nothing to do with it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[David Bolen]

David Bolen  added the comment:

Oh, I agree it's just a warning, and I suspect few people look into warnings, 
but since it's not from an actual test, I'm not sure the overall build should 
be flagged.

The manual typeperf looks fine, but there's no way I could tell visually how 
the I/O is being done under the covers.  My bet is typeperf is probably issuing 
multiple output calls, one for the leading timestamp and then one for each 
value.  So regrtest just happens to interleave its own read in between the two. 
 The subsequent read would then get the trailing "," which the current code 
would parse normally as it only cares about the second field.  In which case 
it's not even affecting the load monitoring, other than the warning message.

I suspect it's happening on the Windows 10 buildbot as the machine is 
reasonably fast.  But to your earlier comment about things just working 
previously, I'm not sure there's that much value in adding code to deal with 
this case.

I'd probably just remove the warning to restore the earlier behavior.  The 
current code still ignores other issues like an actual read failure in 
read_output.  Or, if there's a way to generate the message without it being 
considered an overall test build warning, that would work too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38014] Python 3.7 does not compile

[Matej Cepl]

Matej Cepl  added the comment:

Isn’t https://bugzilla.suse.com/1152793 (removal of stropts.h from glibc) cause 
of this?

--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[STINNER Victor]

STINNER Victor  added the comment:

> Just an FYI that this change is generating warnings on my Windows 10 buildbot 
> with some regularity about a failure to parse testperf output, such as:

Warning -- Failed to parse typeperf output: '"10/01/2019 07:58:50.056"'

Aha, interesting. I added a warning to debug the code.

> Now, clearly there's no queue length in that output so the parsing warning is 
> accurate, but does the overall build have to reflect a warning in such cases, 
> given that it's just a test harness issue, and not anything going wrong with 
> the actual tests?

The build is marked as "warning" (orange) which is different than "fail" (red). 
Warnings are used to detect bugs or interesting issues, but not considered as a 
regression.

> I don't know why both fields aren't present although it seems plausible that 
> it's just a partial line from the I/O (I don't think it guarantees it 
> receives full lines), and the queue length field would appear on the 
> following read.

Right, the code doesn't ensure that a line ends with a newline character. Could 
you try to run manually the following command to check its output?

   typeperf "\System\Processor Queue Length" -si 1

Maybe uncomplete lines should be buffered in read_output().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Sorry, I did not test the last version on Windows. There was a bug which caused 
using the Linux version on Windows. Now it should be fixed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german)

[David Bolen]

David Bolen  added the comment:

Just an FYI that this change is generating warnings on my Windows 10 buildbot 
with some regularity about a failure to parse testperf output, such as:

Warning -- Failed to parse typeperf output: '"10/01/2019 07:58:50.056"'

from https://buildbot.python.org/all/#/builders/217/builds/487

Now, clearly there's no queue length in that output so the parsing warning is 
accurate, but does the overall build have to reflect a warning in such cases, 
given that it's just a test harness issue, and not anything going wrong with 
the actual tests?  Previously any such cases would be ignored silently, so this 
probably isn't a new issue but just one that is now shows up as an overall 
build warning.

I don't know why both fields aren't present although it seems plausible that 
it's just a partial line from the I/O (I don't think it guarantees it receives 
full lines), and the queue length field would appear on the following read.

--
nosy: +db3l

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Tal Einat]

Tal Einat  added the comment:

More info:

>>> '\N{PERSONAL COMPUTER}'.encode('utf-8').decode('latin-1') == '💻'
True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Tal Einat]

Tal Einat  added the comment:

Not sure if this helps, but a bit of experimentation brought this up:

>>> '\N{PERSONAL COMPUTER}'.encode('utf-8')
b'\xf0\x9f\x92\xbb'
>>> '💻'.encode('utf-16le')
b'\xf0\x00\x9f\x00\x92\x00\xbb\x00'
>>> '💻'.encode('utf-16')
b'\xff\xfe\xf0\x00\x9f\x00\x92\x00\xbb\x00'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Tal Einat]

Tal Einat  added the comment:

Serhiy, this looks like a great step in the right direction!

Tested on Win10 with PR GH-16545 (commit f4db0e7e00). Here is a copy/paste from 
an IDLE shell session:

>>> '\N{PERSONAL COMPUTER}'
'💻'
>>> print('')
SyntaxError: 'utf-8' codec can't encode characters in position 7-12: surrogates 
not allowed

Note that in the first output, the second and third chars in the string aren't 
visible in IDLE; i.e. what is actually displayed is 'ð»'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38344] activate.bat else needs to be on the same line as the if

[Steve Dower]

Steve Dower  added the comment:

Also adding Ned - this made it into 3.7 as well.

--
nosy: +ned.deily
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38352] In typing docs, note explicit import needed for IO and Pattern/Match

[Karl Kornel]

New submission from Karl Kornel :

Hello!

In https://github.com/python/cpython/blob/master/Lib/typing.py#L115-L117, there 
is a note about the io and re classes not being included in typing.__all__.  I 
am a relatively new user of typing, and I did `from typing import *` in my 
code.  I ran the code through mypy first, which reported no problems, but then 
running Python 3.6 failed with a NameError (name 'IO' is not defined).

Reading through the typing source, it's clear that this was an intentional 
decision.  So, instead of reporting a bug, I'd like to request a documentation 
enhancement!

The docs for typing make no mention of typing.io or typing.re.  So, my request 
is: In the sections for the IO/TextIO/BinaryIO and Pattern/Match classes, 
include text warning the user that these types are not imported when you do 
`from typing import *`.

--
assignee: docs@python
components: Documentation
messages: 353763
nosy: Karl Kornel, docs@python
priority: normal
severity: normal
status: open
title: In typing docs, note explicit import needed for IO and Pattern/Match
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Mariatta]

Mariatta  added the comment:

I think updating one isolated code example is less invasive and easier to 
review, instead of one big PR to change everything from "%s" to str.format or 
f-string.

I brought up this example code merely because I happen to be reading this page.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
Removed message: https://bugs.python.org/msg353759

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
Removed message: https://bugs.python.org/msg353760

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 16545 solves the problem by using OS specific methods for converting between 
Python and Tcl strings. It is not ideal, but is good enough for most real cases.

Now you can paste, copy and print non-BMP characters. The code containing them 
can be displayed weird, but the result of print looks OK.

>>> '\N{PERSONAL COMPUTER}'
''
>>> print('')


As a side effect, printing '\udcf0\udc9f\udc90\udc8d' on Linux and 
'\ud83d\udcbb' on Windows should have the same effect as printing '\U0001f4bb'.

I do not know about macOS, but expect the same behavior as on Linux. Could 
anybody test please?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +16135
pull_request: https://github.com/python/cpython/pull/16545

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Oops, it is better to attach it to issue13153.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 16545 solves the problem by using OS specific methods for converting between 
Python and Tcl strings. It is not ideal, but is good enough for most real cases.

Now you can paste, copy and print non-BMP characters. The code containing them 
can be displayed weird, but the result of print looks OK.

>>> '\N{PERSONAL COMPUTER}'
''
>>> print('')


As a side effect, printing '\udcf0\udc9f\udc90\udc8d' on Linux and 
'\ud83d\udcbb' on Windows should have the same effect as printing '\U0001f4bb'.

I do not know about macOS, but expect the same behavior as on Linux. Could 
anybody test please?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38335] simplify overlaps function in ipaddress.py

[Sanjay]

Change by Sanjay :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22214] Tkinter: Don't stringify callback arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +16134
pull_request: https://github.com/python/cpython/pull/16545

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38344] activate.bat else needs to be on the same line as the if

[Steve Dower]

Steve Dower  added the comment:

Adding this to the end of test_unicode_in_batch_file seems to be sufficient to 
cause the test to fail:

self.assertEqual(err.strip(), '')

Potentially we should add that additional check throughout this test module, 
but I don't think that's needed for a post-RC fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

Does it make sense to change just one example?

I'm not sure what the long-term stance is on whether %-formatting should be 
replaced at this point, but shouldn't this be a matter of which string 
formatting approach we want overall, rather than adjusting only specific 
examples?

--
nosy: +fdrake

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: pathlib

[Barry Scott]

> On 2 Oct 2019, at 09:14, DL Neil via Python-list  
> wrote:
> 
> On 2/10/19 12:52 AM, Rhodri James wrote:
>> On 01/10/2019 06:03, DL Neil via Python-list wrote:
>>> On 30/09/19 9:28 PM, Barry Scott wrote:
> On 30 Sep 2019, at 05:40, DL Neil via Python-list 
>  wrote:
> 
> Should pathlib reflect changes it has made to the file-system?
 
 I think it should not.
>>> 
>>> The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - 
>>> whereas the others are differentiated with the prefix "Pure".
>>> 
>>> I take "concrete" to mean 'existing in reality or real experience'. Thus, I 
>>> saw the Pure* entities as supporting abstract paths, but the concrete 
>>> entities as representing (and reflecting) real-world (file system) entities.
>>> 
>>> Thus, there is no need for .exists() to be available in the Pure paths, but 
>>> there is when utilising their concrete implementations.
>> Sorry but your logic is inconsistent here.  For starters, it's not that 
>> there's no need for .exists() in Pure paths, it's that .exists() is 
>> meaningless.  Pure paths aren't related to any actual filing system (to 
>> paraphrase you), so existence isn't an option.
>> However if you insist that "concrete" means "existing in reality", then 
>> .exists() is unnecessary because by your very definition the path must 
>> exist.  The very act of creating the Path object would create the 
>> corresponding file or directory.  So either pathlib does something horrific, 
>> or your definition is wrong.
> 
> 
> Very good! Yes, I'd picked-on .exists() purely (hah!) because it does not 
> appear in PurePaths, but does in concrete Paths.
> 


> On which topic, I went looking for a decent technical definition of the word, 
> but instead of coming-out smiling, I've been left somewhat stony-faced (hah, 
> hah!).

"concrete
adj.
Of or relating to an actual, specific thing or instance; particular.
"

> That said, it is one of the ways that a path can be shown to transition from 
> some 'pure' state to become 'concrete'.
> 
> However, A.N.Other has suggested that I might be mis-applying the word 
> "concrete", so maybe not.

Concrete means a specific operating system's filesystem rules, Windows or Posix.

> 
> A definition/description would be useful. Any pointers?

Barry

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

[issue38344] activate.bat else needs to be on the same line as the if

[Steve Dower]

Steve Dower  added the comment:

Should be a straightforward fix (replace the "else" with "if not defined..."), 
but since it slipped through testing we probably want a regression test in 
test_venv as well.

(+RM for the 3.8 regression)

--
keywords: +3.8regression
nosy: +lukasz.langa
priority: normal -> release blocker
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38349] Email example using imaginary library installation error. The install shows that it only supports python 2.x but is listed under python 3.6+ docs.

[jackotonye]

jackotonye  added the comment:

Might be best to make it a little more obvious since most examples are
considered executable code. That would require little modification.

On Wed, Oct 2, 2019 at 12:20 PM SilentGhost  wrote:

>
> SilentGhost  added the comment:
>
> imaginary in the example is not meant to refer to
> https://pypi.org/project/Imaginary/ it's meant to refer to a module that
> you could write that would do all the dirty work. Perhaps, it's not the
> best name to use provided there is an actual module on pypi, alternatively
> half-baked outdated modules could be remove.
>
> --
> nosy: +SilentGhost
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23445] Use -Og for debug builds

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-38350 to propose to revert this change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[STINNER Victor]

STINNER Victor  added the comment:

My use case is to debug a crash using a Python compiled in debug module, like 
python3-debug program in Fedora. Since the debug ABI is now compatible with the 
release build, the idea is to attempt to reproduce a crash in gdb using 
python3-debug instead of python3, and then use gdb to see what's going on.

With -Og, the call stack is wrong sometimes, and some function arguments and 
local variables cannot be read (displayed as ).

On Travis CI, a few months ago, Python was built in debug mode using -O3. But 
it was a side effect of OpenSSL flags if I recall correctly.

With my PR 16544, Travis CI now uses -O0.

--
nosy: +pablogsal, pitrou, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38342] ImportError: cannot import name 'MetadataPathFinder' from 'importlib.metadata'

[Brett Cannon]

Brett Cannon  added the comment:

Closing as not a bug as this seems to be an issue from installing over a b3 or 
earlier build where the importlib/metadata/ directory gets left behind and thus 
take priority in import over importlib/metadata.py.

--
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +16133
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16544

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38338] [2.7] test_ssl fails on RHEL8

[miss-islington]

miss-islington  added the comment:


New changeset 183733dfb6b4779d1a5e47f41a2fb86c6be08dda by Miss Islington (bot) 
in branch '3.8':
bpo-38338, test.pythoninfo: add more ssl infos (GH-16539)
https://github.com/python/cpython/commit/183733dfb6b4779d1a5e47f41a2fb86c6be08dda


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[STINNER Victor]

STINNER Victor  added the comment:

test_gdb is failing in different architectures and different operating systems:

* Fedora, Python 3.8, x86-64:
  https://bugzilla.redhat.com/show_bug.cgi?id=1734327

* RHEL8, Python 3.6, s390x
  https://bugzilla.redhat.com/show_bug.cgi?id=1712977

* RHEL 8, Python 3.6, ppc64le
  https://bugzilla.redhat.com/show_bug.cgi?id=1714733

I'm quite sure that most issues are caused by the compiler optimization level 
which is not -O0.

See also bpo-37631: the debug build of the RHEL8 package is supposed to be 
compiled using -O0 using EXTRA_CFLAGS variable, but -O0 in EXTRA_CFLAGS 
variable is overriden by -02 in CFLAGS_NODIST.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38351] Modernize email example from %-formatting to f-string

[Mariatta]

New submission from Mariatta :

A string was formatted with %s in the code example 

https://github.com/python/cpython/blob/b3e7045f8314e7b62cd95861d207fe2f97e47198/Doc/includes/email-simple.py#L15
 

```
msg['Subject'] = 'The contents of %s' % textfile
```

It would be great to modernize that into fstring.

Doc can be read at: https://docs.python.org/3.7/library/email.examples.html

--
assignee: docs@python
components: Documentation
keywords: easy, newcomer friendly
messages: 353749
nosy: Mariatta, docs@python
priority: normal
severity: normal
stage: needs patch
status: open
title: Modernize email example from %-formatting to f-string
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[STINNER Victor]

STINNER Victor  added the comment:

I basically propose to revert bpo-23445 change:

commit 3d6c784371bccc2407048652bce50c5bccf9b1af
Author: Antoine Pitrou 
Date:   Wed Feb 11 19:39:16 2015 +0100

Issue #23445: pydebug builds now use "gcc -Og" where possible, to make the 
resulting executable faster.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: pymysql.err.InterfaceError after some hours of usage

[Νίκος Βέργος]

Τη Τετάρτη, 2 Οκτωβρίου 2019 - 7:11:52 μ.μ. UTC+3, ο χρήστης Inada Naoki έγραψε:
> 2019年10月3日(木) 0:56 Νίκος Βέργος :
> 
> > Τη Τετάρτη, 2 Οκτωβρίου 2019 - 8:26:38 π.μ. UTC+3, ο χρήστης Inada Naoki
> > έγραψε:
> > > MySQL connection can be closed automatically by various reasons.
> > > For example, `wait_timeout` is the most common but not only reason for
> > > closing the connection.
> > >
> > > You should connect and close MySQL connection for each HTTP request.
> > >
> > > Or you can use more smart connection pool (e.g. Engine in SQLAlchemy).
> > > It provides `pool_recycle` and `pool_pre_ping` options.
> > >
> > > https://docs.sqlalchemy.org/en/13/core/pooling.html#setting-pool-recycle
> >
> > You mean that every time i insrt/update and in general having a
> > cur.execute() i then need to close the pymysql connection in order to not
> > have this error?
> >
> 
> No, I meant one new DB connection for each HTTP request, not for each DB
> query.

After seeing a stackoverflow link, it was stating that:

This is caused by a global cursor. Try creating and closing the cursor within 
each method a raw query is needed.

cursor = connection.cursor() cursor.execute(query) cursor.close()

Does that mean that i have to create a cursor then execute the SQL statement 
and the close the cursor? And i must do that before and after executing each 
SQL statement in all of my scripts?

Doesn't the DB Connection have a directive to autoclose the resources?

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

[issue38338] [2.7] test_ssl fails on RHEL8

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 403ca7ea70232e520af18511fbfb89b58ef2a046 by Victor Stinner in 
branch '2.7':
[2.7] bpo-38338, test.pythoninfo: add more ssl infos (GH-16543)
https://github.com/python/cpython/commit/403ca7ea70232e520af18511fbfb89b58ef2a046


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

[STINNER Victor]

New submission from STINNER Victor :

In Python 2.7, when using ./configure --with-pydebug, Python is built using -O0 
compiler optimization level: disable all optimizations. The comment is quite 
explicit: "Optimization messes up debuggers, so turn it off for debug builds".

if test "$Py_DEBUG" = 'true' ; then
# Optimization messes up debuggers, so turn it off for
# debug builds.
OPT="-g -O0 -Wall $STRICT_PROTO"
else
OPT="-g $WRAP -O3 -Wall $STRICT_PROTO"
fi

In Python 3, -Og is preferred over -O0 for pydebug, if -Og is available:

if test "$Py_DEBUG" = 'true' ; then
# Optimization messes up debuggers, so turn it off for
# debug builds.
if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then
OPT="-g -Og -Wall"
else
OPT="-g -O0 -Wall"
fi
else
OPT="-g $WRAP -O3 -Wall"
fi

Problem: in my experience, gdb traceback doesn't make sense sometimes, and gdb 
fails to inspect some function arguments and some variables which are displayed 
as .

See a very concrete example with a test_gdb failure on x86-64 when Python is 
compiled using gcc -Og:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c22

My colleague who is working on gdb suggests to use -O0:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c27

Since I started contributing to Python, I always forced gcc -O0 because any 
other optimization level caused me many issues in gdb. I'm using -O0 for 10 
years with sucess.

The GCC documentation says "It is a better choice than -O0 for producing 
debuggable code because some compiler passes that collect debug information are 
disabled at -O0." But my experience says the opposite.

Note: instead of -g, we could use -g3 to include debug information for macros 
and defines.

--

I'm proposing to change the *default* compiler flags from -Og to -O0. 
Obviously, Linux distributions and developers are free to override the compiler 
optimization level. For example: ./configure --with-pydebug CFLAGS="-Og" 
ensures that Python is always built using -Og.

I propose to modify 3.7, 3.8 and master branches.

--
components: Build
messages: 353746
nosy: vstinner
priority: normal
severity: normal
status: open
title: ./configure --with-pydebug should use -O0 rather than -Og
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38349] Email example using imaginary library installation error. The install shows that it only supports python 2.x but is listed under python 3.6+ docs.

[SilentGhost]

SilentGhost  added the comment:

imaginary in the example is not meant to refer to 
https://pypi.org/project/Imaginary/ it's meant to refer to a module that you 
could write that would do all the dirty work. Perhaps, it's not the best name 
to use provided there is an actual module on pypi, alternatively half-baked 
outdated modules could be remove.

--
nosy: +SilentGhost

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com