[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

[hai shi]

hai shi  added the comment:

IMHO, dropping the sort should be a default behavior. If some user need  
this feature, maybe we could supply a param to open the sort function or not?

--
nosy: +shihai1991

___
Python tracker 

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

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Richard Damon]

On 12/21/19 8:25 PM, MRAB wrote:
> On 2019-12-22 00:22, Michael Torrie wrote:
>> On 12/21/19 2:46 PM, Ben Hearn wrote:
>>> These 2 paths look identical, one from the drive & the other from an
>>> xml url:
>>> a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf -
>>> ¡Móchate! _PromoMix_.wav'
>>     ^^
>>> b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate!
>>> _PromoMix_.wav'
>>     ^^
>> They are actually are different strings.  The name is spelled
>> differently between the two.  Móchate vs Móchate (the former seems to
>> be the correct spelling according to my inline spell checker).  Is this
>> from your own program? I wonder how it got switched?
>>
> Use the 'ascii' function to see what's different:
>
> >>> ascii(a)
> "'/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf -
> \\xa1Mo\\u0301chate! _PromoMix_.wav'"
> >>> ascii(b)
> "'/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf -
> \\xa1M\\xf3chate! _PromoMix_.wav'"
> >>>

It is a Unicode Normalization issue. A number of characters can be
'spelled' different ways.

ó can be either a single codepoint U+00F3, or it can be the pair of
codepoints, the o and U+0301 (the accent).

If you want to make the strings compare equal then you need to make sure
that you have normalized both strings the same way. I beleive that the
Mac OS always converts file names into the NFD format when it uses them
(that is what the first (a) string is in)

-- 
Richard Damon

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

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[MRAB]

On 2019-12-22 00:22, Michael Torrie wrote:

On 12/21/19 2:46 PM, Ben Hearn wrote:

These 2 paths look identical, one from the drive & the other from an xml url:
a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav'

^^

b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav'

^^
They are actually are different strings.  The name is spelled
differently between the two.  Móchate vs Móchate (the former seems to
be the correct spelling according to my inline spell checker).  Is this
from your own program? I wonder how it got switched?


Use the 'ascii' function to see what's different:

>>> ascii(a)
"'/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - 
\\xa1Mo\\u0301chate! _PromoMix_.wav'"

>>> ascii(b)
"'/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - 
\\xa1M\\xf3chate! _PromoMix_.wav'"

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

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Chris Angelico]

On Sun, Dec 22, 2019 at 11:33 AM Michael Torrie  wrote:
>
> On 12/21/19 2:46 PM, Ben Hearn wrote:
> > These 2 paths look identical, one from the drive & the other from an xml 
> > url:
> > a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> > _PromoMix_.wav'
>^^
> > b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> > _PromoMix_.wav'
>^^
> They are actually are different strings.  The name is spelled
> differently between the two.  Móchate vs Móchate (the former seems to
> be the correct spelling according to my inline spell checker).  Is this
> from your own program? I wonder how it got switched?

Then your inline spell checker is flawed, because the two strings
differ only in whether a single "o with acute" or a pair "o" and
"combining acute" is used to represent the accented letter. The word
is the same either way.

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

[issue39071] email.parser.BytesParser - parse and parsebytes work not equivalent

[Abhilash Raj]

Change by Abhilash Raj :


--
nosy: +maxking

___
Python tracker 

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

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Michael Torrie]

On 12/21/19 2:46 PM, Ben Hearn wrote:
> These 2 paths look identical, one from the drive & the other from an xml url:
> a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav'
   ^^
> b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav'
   ^^
They are actually are different strings.  The name is spelled
differently between the two.  Móchate vs Móchate (the former seems to
be the correct spelling according to my inline spell checker).  Is this
from your own program? I wonder how it got switched?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

Re: [Scons-dev] SCons 3.1.2 Released

[Eric Fahlgren]

On Mon, Dec 16, 2019 at 7:02 PM Bill Deegan 
wrote:

> - EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration
>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>   SCons will cache the results of past calls to vcvarsall.bat to
>   a file; integrates with existing memoizing of such vars.
>   On vs2019 saves 5+ seconds per SCons invocation, which really
>   helps test suite runs.
>

Thanks a bunch for this one!  Our bare, no-target 'scons' invocation is
down to about 0.8 seconds now, and we can do a single DLL build in ~2.5 s,
which makes things very snappy indeed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Dan Sommers]

On 12/21/19 4:46 PM, Ben Hearn wrote:


import difflib
print('\n'.join(difflib.ndiff([a], [b])))
- /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav
?   
   ^^
+ /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! _PromoMix_.wav
?   
   ^


What am I missing when it comes to unquoting the string, or should I do some 
other fancy operation on the drive string?


I'm going to guess that the trailing characters are newline
(U+0010) and/or carriage return (U+001D) characters.  Use
str.strip() to remove them before comparing:

a = a.strip()

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

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Pieter van Oostrum]

Ben Hearn  writes:

> Hello all,
>
> I am having a bit of trouble with a string mismatch operation in my tool I am 
> writing.
>
> I am comparing a database collection or url quoted paths to the paths on the 
> users drive.
>
> These 2 paths look identical, one from the drive & the other from an xml url:
> a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav'
> b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav'
>
> But after realising it was failing on them I ran a difflib and these 
> differences popped up.
>
> import difflib
> print('\n'.join(difflib.ndiff([a], [b])))
> - /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav
> ? ^^
> + /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
> _PromoMix_.wav
> ? ^
>
>
> What am I missing when it comes to unquoting the string, or should I do
> some other fancy operation on the drive string?
>

In [8]: len(a)
Out[8]: 79

In [9]: len(b)
Out[9]: 78

The difference is in the ó. In (b) it is a single character, Unicode 0xF3,
LATIN SMALL LETTER O WITH ACUTE.
In (a) it is composed of the letter o and the accent "́" (Unicode 0x301).
So you would have to do Unicode normalisation before comparing.

For example:

In [16]: from unicodedata import normalize

In [17]: a == b
Out[17]: False

In [18]: normalize('NFC', a) == normalize('NFC', b)
Out[18]: True

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
-- 
https://mail.python.org/mailman/listinfo/python-list

urllib unqoute providing string mismatch between string found using os.walk (Python3)

[Ben Hearn]

Hello all,

I am having a bit of trouble with a string mismatch operation in my tool I am 
writing.

I am comparing a database collection or url quoted paths to the paths on the 
users drive.

These 2 paths look identical, one from the drive & the other from an xml url:
a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav'
b = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav'

But after realising it was failing on them I ran a difflib and these 
differences popped up.

import difflib
print('\n'.join(difflib.ndiff([a], [b])))
- /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! 
_PromoMix_.wav
?   
   ^^
+ /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! _PromoMix_.wav
?   
   ^


What am I missing when it comes to unquoting the string, or should I do some 
other fancy operation on the drive string?

Cheers,

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

Re: [Scons-dev] SCons 3.1.2 Released

[Bill Deegan]

Glad that helped!
Big thanks to Mats Wichmann for that one!

On Sat, Dec 21, 2019 at 10:41 AM Eric Fahlgren 
wrote:

> On Mon, Dec 16, 2019 at 7:02 PM Bill Deegan 
> wrote:
>
>> - EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration
>>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>>   SCons will cache the results of past calls to vcvarsall.bat to
>>   a file; integrates with existing memoizing of such vars.
>>   On vs2019 saves 5+ seconds per SCons invocation, which really
>>   helps test suite runs.
>>
>
> Thanks a bunch for this one!  Our bare, no-target 'scons' invocation is
> down to about 0.8 seconds now, and we can do a single DLL build in ~2.5 s,
> which makes things very snappy indeed.
> ___
> Scons-dev mailing list
> scons-...@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36051] Drop the GIL during large bytes.join operations?

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If there is a large chunk (e.g. several MBs), dropping the GIL during the 
memcpy of that chunk may be beneficial.  This kind of optimization may be 
applicable in other similar cases (such as extending a bytearray or a BytesIO 
object).

--
nosy: +pitrou

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Could you show evidences that dropping the GIL can help you? bytes.join() needs 
to perform operations which needs to hold the GIL (allocating the memory, 
iterating the list, getting the data of bytes-like objects). I afraid that the 
cost of memcpy() is a minor part of this.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> 1. Python daemon threads

I think the answer is to document a bit more clearly that they can pose all 
kinds of problems.  Perhaps we could even display a visible warning when people 
create daemon threads.

> 2. Python threads created in atexit handlers

We could run the "join non-daemon threads" routine a *second time* after atexit 
handlers have been called.  It probably can't hurt (unless people do silly 
things?).

> 3. non-Python threads accessing the C-API

This one I don't know how to handle. By construction, a non-Python thread can 
do anything it wants, and we cannot add guards against this at the beginning of 
each C API function. I think that when someone calls the C API, we're clearly 
in the realm of "consenting adults".

--

___
Python tracker 

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

[issue39117] Performance regression for making bound methods

[Raymond Hettinger]

New submission from Raymond Hettinger :

$ python3.9 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
100 loops, best of 11: 230 nsec per loop

$ python3.8 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
200 loops, best of 11: 149 nsec per loop

$ python3.7 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
200 loops, best of 11: 159 nsec per loop

$ python3.6 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
1000 loops, best of 11: 0.159 usec per loop

Timings made using the recent released python.org macOS 64-bit builds.

--
components: Interpreter Core
messages: 358781
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Performance regression for making bound methods
type: performance
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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: How to specific multiple dtypes in numpy.ndarray?

[John Ladasky]

On Thursday, December 19, 2019 at 2:53:18 AM UTC-8, lampahome wrote:
> I meet performance is low when I use struct.unpack to unpack binary data.
> 
> So I tried to use numpy.ndarray
> But meet error when I want to unpack multiple dtypes
> 
> Can anyone teach me~
> 
> Code like below:
> # python3
> import struct
> import numpy as np
> s1 = struct.Struct("@QIQ")
> ss1 = s1.pack(1,11,111)
> np.ndarray((3,), [('Q','I','Q')], ss1)
> # ValueError: mismatch in size of old and new data-descriptor.

Is there some reason that you're calling the np.ndarray constructor directly 
instead of the np.array convenience function?  The arguments that you pass to 
each are slightly different.  Generally, you want to use np.array.

The first argument to np.ndarray is the shape.  You appear to want three 
elements.

The second argument to np.ndarray is the data type (dtype).  It needs to be a 
SINGLE data type, like 'float' or 'int' or 'object'.  All elements in in array 
are of the same dtype.  If you want different behavior, I think that you want 
lists, not arrays.  You can set the dtype to 'object' and you should be able to 
store any data type as an array element.  But I don't think that offers you any 
advantages over using ordinary Python lists.

In any case, it appears that you aren't passing a dtype as your second 
argument.  You're trying to pass the data itself, as a tuple wrapped in a 
single list.  This seems to be certain to raise an error.

The third argument to np.ndarray is supposed to be the buffer which contains 
your data.

https://docs.scipy.org/doc/numpy/reference/generated/numpy.array.html#numpy.array

ile:///usr/share/doc/python-numpy-doc/html/reference/generated/numpy.array.html#numpy.array
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36788] Add clamp() function to builtins

[Batuhan]

Batuhan  added the comment:

Should this issue stay? Maybe port this discussion over python-ideas and after 
the resolution open it again?

--
nosy: +BTaskaya

___
Python tracker 

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

[issue29732] Heap out of bounds read in tok_nextc()

[Batuhan]

Batuhan  added the comment:

(.venv) [ 10:04ÖS ]  [ isidentical@x200:~/Downloads ]
 $ python -V
Python 3.9.0a1+
(.venv) [ 10:04ÖS ]  [ isidentical@x200:~/Downloads ]
 $ python python_hoobr_tok_nextc.py
  File "/home/isidentical/Downloads/python_hoobr_tok_nextc.py", line 5

^
SyntaxError: EOF while scanning triple-quoted string literal

--
nosy: +BTaskaya

___
Python tracker 

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

[issue39087] [C API] No efficient C API to get UTF-8 string from unicode object.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I like this idea, but I think that we should at least notify Python-Dev about 
all additions to the public C API. If somebody have objections or better idea, 
it is better to know earlier.

--

___
Python tracker 

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

[issue34444] Module's __file__ should be absolute always ("." in sys.path)

[Batuhan]

Batuhan  added the comment:

I am not sure about computing absolute path every time when `__file__` called. 
I guess it is a static thing, that get setted on the import time and never 
changes. What you are proposing is to compute it dynamically which IMHO isn't 
the best way.

--
nosy: +BTaskaya, brett.cannon, eric.snow, ncoghlan

___
Python tracker 

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

[issue32599] Add dtrace hook for PyCFunction_Call

[Batuhan]

Batuhan  added the comment:

If there are no objections, I can work on a patch.

--
nosy: +BTaskaya, christian.heimes, vstinner

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It cannot be suppressed by the code in the module caused a warning, because the 
warning is emitted at compile time. You need to silence it before compiling 
that module. Once you have compiled it, warning will no longer be emitted.

--

___
Python tracker 

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

[issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
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

[issue33772] Fix few dead code paths

[Benjamin Peterson]

Change by Benjamin Peterson :


--
resolution:  -> fixed
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

[issue39116] StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop

[twisteroid ambassador]

New submission from twisteroid ambassador :

I have been getting these strange exception since Python 3.8 on my Windows 10 
machine. The external symptoms are many errors like "RuntimeError: aclose(): 
asynchronous generator is already running" and "Task was destroyed but it is 
pending!".

By adding try..except..logging around my code, I found that my StreamReaders 
would raise GeneratorExit on readexactly(). Digging deeper, it seems like the 
following line in StreamReader._wait_for_data():

await self._waiter

would raise a GeneratorExit.

There are only two other methods on StreamReader that actually does anything to 
_waiter, set_exception() and _wakeup_waiter(), but neither of these methods 
were called before GeneratorExit is raised. In fact, both these methods sets 
self._waiter to None, so normally after _wait_for_data() does "await 
self._waiter", self._waiter is None. However, after GeneratorExit is raised, I 
can see that self._waiter is not None. So it seems the GeneratorExit came from 
nowhere.

I have not been able to reproduce this behavior in other code. This is with 
Python 3.8.1 on latest Windows 10 1909, using ProactorEventLoop. I don't 
remember seeing this ever on Python 3.7.

--
components: asyncio
messages: 358774
nosy: asvetlov, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Zachary Ware]

Change by Zachary Ware :


--
keywords: +3.9regression

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Looking at changes to alpha2 I think it bisects to 
https://github.com/python/cpython/pull/6641


➜  cpython git:(5dcc06f6e0) git checkout 
fee552669f21ca294f57fe0df826945edc779090 && make -s -j4 > /dev/null 
Previous HEAD position was 5dcc06f6e0... bpo-38858: Allocate small integers on 
the heap (GH-17301)
HEAD is now at fee552669f... Produce cleaner bytecode for 'with' and 'async 
with' by generating separate code for normal and exceptional paths. (#6641)
➜  cpython git:(fee552669f) ./python ../backups/bpo39114.py 

3.9.0a1+ (tags/v3.9.0a1-43-gfee552669f:fee552669f, Dec 21 2019, 20:18:54) 
[GCC 4.8.4]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
➜  cpython git:(fee552669f) git checkout 
fee552669f21ca294f57fe0df826945edc779090~1 && make -s -j4 > /dev/null
Previous HEAD position was fee552669f... Produce cleaner bytecode for 'with' 
and 'async with' by generating separate code for normal and exceptional paths. 
(#6641)
HEAD is now at 5dcc06f6e0... bpo-38858: Allocate small integers on the heap 
(GH-17301)
➜  cpython git:(5dcc06f6e0) ./python ../backups/bpo39114.py 
  
3.9.0a1+ (tags/v3.9.0a1-42-g5dcc06f6e0:5dcc06f6e0, Dec 21 2019, 20:21:07) 
[GCC 4.8.4]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue39115] Clarify Python MIME type

[Josh de Kock]

New submission from Josh de Kock :

I'd like to add Python's MIME types to a database so that they can be properly 
used by other services. However, apart from the source code[1][2], I can't find 
any documentation from Python which highlights this. Is the source code correct 
here, and can it be taken as the 'official' MIME types from the project?

text/x-python py
application/x-python-code pyc pyo

[1]: 
https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L457
[2]: 
https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L528

--
assignee: docs@python
components: Documentation
messages: 358772
nosy: docs@python, jdek
priority: normal
severity: normal
status: open
title: Clarify Python MIME type
type: enhancement
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

Re: hexdump module installation error

[tommy yama]

fixed now. I guess pip3 is linked to pip2 and installed python3 again.

On Sat, Dec 21, 2019 at 8:44 AM tommy yama  wrote:

> Thanks to all giving me helpful comments.
> Multiple hexdump files are found. Maybe that"s the reason.
>
> I guess i can figure out
>
>
>
>
> On Thu, Dec 19, 2019 at 5:29 PM Dennis Lee Bieber 
> wrote:
>
>> On Thu, 19 Dec 2019 12:43:11 +, tommy yama 
>> declaimed the following:
>>
>> >
>> >user@USERnoMacBook-Air LibraBrowser % python3 hexdump.py
>> >
>>
>> >/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python:
>> >can't open file 'hexdump.py': [Errno 2] No such file or directory
>> >
>> >user@USERnoMacBook-Air LibraBrowser %
>> >
>>
>> Well... what does
>>
>> find / -iname hexdump.py
>>
>> return? If found, is it in the Python search path?
>>
>> {Debian system here, but... (after doing apt install python3-pip)}
>>
>> wulfraed@debian:~$ pip3 install hexdump
>> Collecting hexdump
>>   Downloading
>>
>> https://files.pythonhosted.org/packages/55/b3/279b1d57fa3681725d0db8820405cdcb4e62a9239c205e4ceac4391c78e4/hexdump-3.3.zip
>> Building wheels for collected packages: hexdump
>>   Running setup.py bdist_wheel for hexdump ... done
>>   Stored in directory:
>>
>> /home/wulfraed/.cache/pip/wheels/d5/d1/f2/c8183b5863b3df595c2eeafd8e015a43dae13d403a959467c6
>> Successfully built hexdump
>> Installing collected packages: hexdump
>> Successfully installed hexdump-3.3
>> wulfraed@debian:~$ sudo find / -iname hexdump.py
>> /home/wulfraed/.local/lib/python3.7/site-packages/hexdump.py
>> find: ‘/run/user/1000/gvfs’: Permission denied
>> /usr/lib/python3/dist-packages/pygments/lexers/hexdump.py
>> /usr/lib/python2.7/dist-packages/pygments/lexers/hexdump.py
>> wulfraed@debian:~$ python3
>> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
>> [GCC 8.3.0] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import hexdump
>> >>> dir(hexdump)
>> ['PY3K', '__author__', '__builtins__', '__cached__', '__doc__',
>> '__file__',
>> '__history__', '__license__', '__loader__', '__name__', '__package__',
>> '__spec__', '__version__', 'binascii', 'chunkread', 'chunks', 'dehex',
>> 'dump', 'dumpgen', 'genchunks', 'hexdump', 'main', 'normalize_py',
>> 'restore', 'runtest', 'sys']
>> >>> hexdump.__file__
>> '/home/wulfraed/.local/lib/python3.7/site-packages/hexdump.py'
>> >>>
>>
>> Note that there are "hexdump.py" files involved with the pygments
>> package, which likely are not what you are looking for (quick glance --
>> the
>> pygments hexdump READS dump files).
>>
>>
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlfr...@ix.netcom.com
>> http://wlfraed.microdiversity.freeddns.org/
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Ned Batchelder]

New submission from Ned Batchelder :

The way trace function reports return-finally has changed in Python 3.9.0a2. I 
don't know if this change is intentional or not.

(BTW: I want to put a 3.9regression keyword on this, but it doesn't exist.)

Consider this code:

--- 8< 
import linecache, sys

def trace(frame, event, arg):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, 
lineno).rstrip()))
return trace

print(sys.version)
sys.settrace(trace)

a = []
def finally_return():
try:
return 14
finally:
a.append(16)
assert finally_return() == 14
assert a == [16]
--- 8< 


(My habit is to use line numbers in the lines themselves to help keep things 
straight.)

In Python 3.7 (and before), the last traces are line 14, line 16, return 16.

In Python 3.8, the last traces are line 14, line 16, line 14, return 14.

In Python 3.9a1, the traces are the same as 3.8.

In Python 3.9a2, the traces are now line 14, line 16, line 14, line 16, return 
16.

This doesn't make sense to me: why does it bounce back and forth?

Full output from different versions of Python:

% /usr/local/pythonz/pythons/CPython-3.7.1/bin/python3.7 bpo.py
3.7.1 (default, Oct 20 2018, 18:25:32)
[Clang 10.0.0 (clang-1000.11.45.2)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
% /usr/local/pythonz/pythons/CPython-3.8.1/bin/python3.8 bpo.py
3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a1/bin/python3.9 bpo.py
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a2/bin/python3.9 bpo.py
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)

--
messages: 358771
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.9.0a2 changed how finally/return is traced
type: behavior
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

[issue39052] import error when in python -m pdb debug mode

[Xavier de Gaye]

Xavier de Gaye  added the comment:

As a workaround insert the following hard-coded breakpoint before the import 
statement and run your script with python, i.e. 'python myhome.py' instead of 
'python -m pdb myhome.p'.

from pdb import Pdb; Pdb(skip=['importlib*']).set_trace()

--
nosy: +xdegaye

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[Tarn Yeong Ching]

Tarn Yeong Ching  added the comment:

GOD... I see. Thank you very much!

--

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[Mark Dickinson]

Mark Dickinson  added the comment:

[ctarn]

> it works as expected with Python 3.6 (the owner of each of them is d), and 
> Python 3.8 and Python 3.7 work differently

The change in behaviour is the result of a bug fix that was applied in 3.7 and 
upwards: see GH-13169 and #27639.

As Eric says, UserList is behaving as intended here. Your problem stems from a 
design flaw in your code, namely that Nodes have owners. If a node exists both 
in a Tree *and* in a slice of that Tree (which slice, since the #27639 fix, is 
again a Tree), that node can't have both the original Tree *and* the slice as 
owner. In this case, what's happening is that accessing `d[0:1]` creates a new 
Tree object, and the __init__ method for that Tree object then reassigns the 
"owner" of the node in that slice.

> I don’t know what is discussion list

See https://www.python.org/community/lists/, and particularly 
https://mail.python.org/mailman/listinfo/python-list

Closing again here, but feel free to start a discussion or ask questions on the 
list above.

--
nosy: +mark.dickinson
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue33961] Inconsistency in exceptions for dataclasses.dataclass documentation

[Fabio Sangiovanni]

Change by Fabio Sangiovanni :


--
pull_requests: +17137
pull_request: https://github.com/python/cpython/pull/17677

___
Python tracker 

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

Re: Understanding of GIL

[Barry]

> On 19 Dec 2019, at 14:19, onlinejudge95  wrote:
> 
> Hi Devs,
> 
> I am currently writing some custom Django commands for data updation, my
> workflow is like
> 
> Fetch data from *PostgreSQL*.
> Call *Elasticsearch* for searching based on the data fetched from
> *PostgreSQL*.
> Query *PostgreSQL* and do an upsert behavior.
> I am using pandas data frame to hold my data during processing.
> 
> The host we are using to run this jobs has a *CPython* interpreter as given
> by
> 
> `platform.python_implementation()`
> 
> I want to confirm whether *multithreading* would be a better choice here,
> given the fact that GIL is the biggest blocker(I agree it has to be there)
> for the same in CPython interpreters.

You mean multi process vs. Threaded?

The GIL is only a problem if you are executing pure python compute bound code 
on multiple threads. When your code does lots of I/O and uses extensions it’s 
not the limiting factor. I guess you app will spent if time waiting of 
PostgreSQL etc.

Barry

> 
> In case further information is required do let me know.
> 
> Thanks
> onlinejudge95
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

Re: Problems with "Tarfile.close()"

[Barry]

> On 20 Dec 2019, at 15:31, Dr Rainer Woitok  wrote:
> 
> Greetings,
> 
> One of my Python scripts basically does the following:
> 
> source = tarfile.open(name=tar_archive  , mode='r|*')
> dest   = tarfile.open(fileobj=sys.stdout, mode='w|', format=fmt)
> 
> .
> .
> .
> 
> source.close()
> dest.close()
> 
> In an attempt to move my Python scripts  from Python 2.7 to Python 3.6 I
> ran into the problem  that under Python 3.6  the call to  "dest.close()"
> fails:
> 
> Traceback (most recent call last):
> File ".../tar_archive.copy", line 137, in 
> dest.close()
> File "/usr/lib64/python3.6/tarfile.py", line 1742, in close
> self.fileobj.close()
> File "/usr/lib64/python3.6/tarfile.py", line 467, in close
> self.fileobj.write(self.buf)
> TypeError: write() argument must be str, not bytes
> 
> What am I doing wrong?   By the way:  since on some hosts this script is
> running on  the transition from Python 2.7 to Python 3.x will not happen
> immediately, I need a solution which works with both versions.

Stdout on python 3 is a text stream. Tarfiles need a binary stream.

I searched for “python 3 binary stdout” and found this
 stack over flow question that has suggested fixes.

https://stackoverflow.com/questions/908331/how-to-write-binary-data-to-stdout-in-python-3#908440

Barry

> 
> Sincerely,
>  Rainer
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hexdump module installation error

[tommy yama]

Thanks to all giving me helpful comments.
Multiple hexdump files are found. Maybe that"s the reason.

I guess i can figure out




On Thu, Dec 19, 2019 at 5:29 PM Dennis Lee Bieber 
wrote:

> On Thu, 19 Dec 2019 12:43:11 +, tommy yama 
> declaimed the following:
>
> >
> >user@USERnoMacBook-Air LibraBrowser % python3 hexdump.py
> >
>
> >/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python:
> >can't open file 'hexdump.py': [Errno 2] No such file or directory
> >
> >user@USERnoMacBook-Air LibraBrowser %
> >
>
> Well... what does
>
> find / -iname hexdump.py
>
> return? If found, is it in the Python search path?
>
> {Debian system here, but... (after doing apt install python3-pip)}
>
> wulfraed@debian:~$ pip3 install hexdump
> Collecting hexdump
>   Downloading
>
> https://files.pythonhosted.org/packages/55/b3/279b1d57fa3681725d0db8820405cdcb4e62a9239c205e4ceac4391c78e4/hexdump-3.3.zip
> Building wheels for collected packages: hexdump
>   Running setup.py bdist_wheel for hexdump ... done
>   Stored in directory:
>
> /home/wulfraed/.cache/pip/wheels/d5/d1/f2/c8183b5863b3df595c2eeafd8e015a43dae13d403a959467c6
> Successfully built hexdump
> Installing collected packages: hexdump
> Successfully installed hexdump-3.3
> wulfraed@debian:~$ sudo find / -iname hexdump.py
> /home/wulfraed/.local/lib/python3.7/site-packages/hexdump.py
> find: ‘/run/user/1000/gvfs’: Permission denied
> /usr/lib/python3/dist-packages/pygments/lexers/hexdump.py
> /usr/lib/python2.7/dist-packages/pygments/lexers/hexdump.py
> wulfraed@debian:~$ python3
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import hexdump
> >>> dir(hexdump)
> ['PY3K', '__author__', '__builtins__', '__cached__', '__doc__', '__file__',
> '__history__', '__license__', '__loader__', '__name__', '__package__',
> '__spec__', '__version__', 'binascii', 'chunkread', 'chunks', 'dehex',
> 'dump', 'dumpgen', 'genchunks', 'hexdump', 'main', 'normalize_py',
> 'restore', 'runtest', 'sys']
> >>> hexdump.__file__
> '/home/wulfraed/.local/lib/python3.7/site-packages/hexdump.py'
> >>>
>
> Note that there are "hexdump.py" files involved with the pygments
> package, which likely are not what you are looking for (quick glance -- the
> pygments hexdump READS dump files).
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.com
> http://wlfraed.microdiversity.freeddns.org/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36000] __debug__ is a keyword but not a keyword

[Batuhan]

Batuhan  added the comment:

import builtins
builtins.__dict__['__debug__'] = 'Surprise!'
builtins.__dict__['None'] = 'Surprise!'

print(__debug__)
print(None)

 $ ./python ../t.py
True
None

I guess this is related to Python/ast_opt.c transformation

case Name_kind:
if (_PyUnicode_EqualToASCIIString(node_->v.Name.id, "__debug__")) {
return make_const(node_, PyBool_FromLong(!optimize_), ctx_);
}
break;

--

___
Python tracker 

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

Re: Problems with "Tarfile.close()"

[Dr Rainer Woitok]

Chris,

On Saturday, 2019-12-21 06:45:24 +1100, you wrote:

> ...
> This construct can be simplified down to:
> 
> stdout = getattr(sys.stdout, "buffer", sys.stdout)

Nice!  And with my admittedly trivial test case it correctly works under
both, Python 2 and Python 3.

Now I'll do some more serious testing ...

Sincerely,
  Rainer
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30905] Embedding should have public API for interactive mode

[Batuhan]

Batuhan  added the comment:

> (1) BUT: The value of 'a' is not printed

Isn't this the expected behavior for file input? You need to call print() in 
order to get 'a' printed.

> (2) This is OK! We run one statement at a time

As it should be for "single input". 

> (3) This is NOT OK! Python throws a SyntaxError because we used 
> Py_single_input.

Yes, because AFAIK single stands for single statement. There are 2 (assign + 
expression)

> These two requirements are in conflict, because while Py_single_input enables 
> the first, it forbids the second.

It is why there is a code module which allows implementation of REPL loops.

--
nosy: +BTaskaya

___
Python tracker 

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