[issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints

[Greg Price]

Change by Greg Price :


--
pull_requests: +15027
pull_request: https://github.com/python/cpython/pull/15302

___
Python tracker 

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

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

[Greg Price]

Change by Greg Price :


--
pull_requests: +15026
pull_request: https://github.com/python/cpython/pull/15301

___
Python tracker 

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

[issue37864] Correct and deduplicate docs on "printable" characters

[Greg Price]

Change by Greg Price :


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

___
Python tracker 

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

[issue37864] Correct and deduplicate docs on "printable" characters

[Greg Price]

New submission from Greg Price :

While working on #36502 and then #18236 about the definition and docs of 
str.isspace(), I looked closely also at its neighbor str.isprintable().

It turned out that we have the definition of what makes a character "printable" 
documented in three places, giving two different definitions.

The definition in the comment on `_PyUnicode_IsPrintable` is inverted, so 
that's an easy small fix.

With that correction, the two definitions turn out to be equivalent -- but to 
confirm that, you have to go look up, or happen to know, that those are the 
only five "Other" categories and only three "Separator" categories in the 
Unicode character database.  That makes it hard for the reader to tell whether 
they really are the same, or if there's some subtle difference in the intended 
semantics.

I've taken a crack at writing some improved docs text for a single definition, 
borrowing ideas from the C comment as well as the existing docs text; and then 
pointing there from the other places we'd had definitions. PR coming shortly.

--
components: Unicode
messages: 349792
nosy: Greg Price, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Correct and deduplicate docs on "printable" characters
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

[issue37764] email.Message.as_string infinite loop

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


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

[issue11671] Security hole in wsgiref.headers.Headers

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +martin.panter

___
Python tracker 

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

[issue28778] wsgiref HTTP Response Header Injection: CRLF Injection

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


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

___
Python tracker 

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

[issue28778] wsgiref HTTP Response Header Injection: CRLF Injection

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
versions: +Python 2.7

___
Python tracker 

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

[issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints

[Greg Price]

Change by Greg Price :


--
nosy: +vstinner

___
Python tracker 

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

[issue32771] merge the underlying data stores of unicodedata and the str type

[Greg Price]

Greg Price  added the comment:

> About the RSS memory, I'm not sure how Linux accounts the Unicode databases 
> before they are accessed. Is it like read-only memory loaded on demand when 
> accessed?

It stands for "resident set size", as in "resident in memory"; and it only 
counts pages of real physical memory. The intention is to count up pages that 
the process is somehow using.

Where the definition potentially gets fuzzy is if this process and another are 
sharing some memory.  I don't know much about how that kind of edge case is 
handled.  But one thing I think it's pretty consistently good at is not 
counting pages that you've nominally mapped from a file, but haven't actually 
forced to be loaded physically into memory by actually looking at them.

That is: say you ask for a file (or some range of it) to be mapped into memory 
for you.  This means it's now there in the address space, and if the process 
does a load instruction from any of those addresses, the kernel will ensure the 
load instruction works seamlessly.  But: most of it won't be eagerly read from 
disk or loaded physically into RAM.  Rather, the kernel's counting on that load 
instruction causing a page fault; and its page-fault handler will take care of 
reading from the disk and sticking the data physically into RAM.  So until you 
actually execute some loads from those addresses, the data in that mapping 
doesn't contribute to the genuine demand for scarce physical RAM on the 
machine; and it also isn't counted in the RSS number.


Here's a demo!  This 262392 kiB (269 MB) Git packfile is the biggest file lying 
around in my CPython directory:

$ du -k .git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack
262392  .git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack


Open it for read -- adds 100 kiB, not sure why:

$ python
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 os, mmap
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:  9968 kB
>>> fd = 
>>> os.open('.git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack',
>>>  os.O_RDONLY)
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS: 10068 kB


Map it into our address space -- RSS doesn't budge:

>>> m = mmap.mmap(fd, 0, prot=mmap.PROT_READ)
>>> m

>>> len(m)
268684419
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS: 10068 kB


Cause the process to actually look at all the data (this takes about ~10s, 
too)...

>>> sum(len(l) for l in m)
268684419
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:271576 kB

RSS goes way up, by 261508 kiB!  Oddly slightly less (by ~1MB) than the file's 
size.


But wait, there's more. Drop that mapping, and RSS goes right back down (OK, 
keeps 8 kiB extra):

>>> del m
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS: 10076 kB

... and then map the exact same file again, and it's *still* down:

>>> m = mmap.mmap(fd, 0, prot=mmap.PROT_READ)
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS: 10076 kB

This last step is interesting because it's a certainty that the data is still 
physically in memory -- this is my desktop, with plenty of free RAM.  And it's 
even in our address space.  But because we haven't actually loaded from those 
addresses, it's still in memory only at the kernel's caching whim, and so 
apparently our process doesn't get "charged" or "blamed" for its presence there.


In the case of running an executable with a bunch of data in it, I expect that 
the bulk of the data (and of the code for that matter) winds up treated very 
much like the file contents we mmap'd in.  It's mapped but not eagerly 
physically loaded; so it doesn't contribute to the RSS number, nor to the 
genuine demand for scarce physical RAM on the machine.


That's a bit long :-), but hopefully informative.  In short, I think for us RSS 
should work well as a pretty faithful measure of the real memory consumption 
that we want to be frugal with.

--

___
Python tracker 

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

[issue11671] Security hole in wsgiref.headers.Headers

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
pull_requests: +15022
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15299

___
Python tracker 

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

[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699)

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
pull_requests: +15023
pull_request: https://github.com/python/cpython/pull/15299

___
Python tracker 

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

[issue28778] wsgiref HTTP Response Header Injection: CRLF Injection

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace
versions: +Python 3.9 -Python 2.7

___
Python tracker 

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

[issue11671] Security hole in wsgiref.headers.Headers

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace
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

[issue37863] Speed up hash(fractions.Fraction)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I make a quick PR for you.  Skipped #1 because I don't think Fraction hashing 
is worth adding another slot.

--
nosy: +mark.dickinson, rhettinger

___
Python tracker 

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

[issue37863] Speed up hash(fractions.Fraction)

[Raymond Hettinger]

Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +15021
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15298

___
Python tracker 

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

[issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


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

___
Python tracker 

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

[issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace

___
Python tracker 

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

[issue1722348] urlparse.urlunparse forms file urls incorrectly

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace

___
Python tracker 

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

[issue32084] [Security] http.server can be abused to redirect to (almost) arbitrary URL

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace

___
Python tracker 

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

[issue23505] Urlparse insufficient validation leads to open redirect

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +epicfaace

___
Python tracker 

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

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

[Greg Price]

Change by Greg Price :


--
pull_requests: +15019
pull_request: https://github.com/python/cpython/pull/15296

___
Python tracker 

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

[issue37863] Speed up hash(fractions.Fraction)

[ppperry]

Change by ppperry :


--
title: Speed hash(fractions.Fraction) -> Speed up hash(fractions.Fraction)

___
Python tracker 

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

Re: fopen() and open() in cpython

[Windson Yang]

Thank you so much for the answer, now it makes sense :D

eryk sun  于2019年8月15日周四 上午12:27写道：

> On 8/13/19, Windson Yang  wrote:
> > After my investigation, I found Since Python maintains its own buffer
> when
> > read/write files, the build-in python open() function will call the
> open()
> > system call instead of calling standard io fopen() for caching.  So when
> we
> > read/write a file in Python, it would not call fopen(), fopen() only use
> > for Python itself but not for python user. Am I correct?
>
> Python 2 I/O wraps C FILE streams (i.e. fopen, fclose, fread, fwrite,
> fgets). Python 3 has its own I/O stack (raw, buffered, text) that aims
> to be more reliably cross-platform than C FILE streams. Python 3 still
> uses FILE streams internally in some cases (e.g. to read pyvenv.cfg at
> startup).
>
> FYI in Windows open() or _wopen() is a C runtime library function, not
> a system function. It calls the Windows API function CreateFile, which
> calls the NT system function, NtCreateFile. It's similarly layered for
> all calls, e.g. read() calls ReadFile or ReadConsoleW, which calls
> NtReadFile or NtDeviceIoControlFile (ReadConsoleW).
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37863] Speed hash(fractions.Fraction)

[Tim Peters]

New submission from Tim Peters :

Recording before I forget.  These are easy:

1. As the comments note, cache the hash code.

2. Use the new (in 3.8) pow(denominator, -1, modulus) to get the inverse 
instead of raising to the modulus-2 power.  Should be significantly faster.  If 
not, the new "-1" implementation should be changed ;-)  Will require catching 
ValueError in case the denom is a multiple of the modulus.

3. Instead of multiplying by the absolute value of the numerator, multiply by 
the hash of the absolute value of the numerator.  That changes the 
multiplication, and the subsequent modulus operation, from unbounded-length 
operations to short bounded-length ones.  Hashing the numerator on its own 
should be significantly faster, because the int hash doesn't require any 
multiplies or divides regardless of how large the numerator is.

None of those should change any computed results.

--
messages: 349789
nosy: tim.peters
priority: low
severity: normal
stage: needs patch
status: open
title: Speed hash(fractions.Fraction)
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

[issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1

[Ned Deily]

Ned Deily  added the comment:

Thanks for the report.  This problem was reported earlier for 3.7.3 in 
Issue36890.  As described there, I have now uploaded a copy of the old 
bundle-format installer dmg file for 3.7.4 that should work on 10.6.  See 
msg349787 there for details and comment there if that solution works for you.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> python-3.7.3-macosx10.6.pkg verification error on macOS 10.6 
Snow Leopard
type: crash -> 

___
Python tracker 

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

[issue36890] python-3.7.3-macosx10.6.pkg verification error on macOS 10.6 Snow Leopard

[Ned Deily]

Ned Deily  added the comment:

Sorry, I did not get around to trying to repackage 3.7.3 and, since then, 3.7.4 
has been released and someone else has now run into this problem on 10.6.  As 
my Python time is very limited at the moment, rather than trying to find a 
build solution to make signed flat packages (.pkg) files work on 10.6 again, I 
have uploaded a copy of the old-style bundle installer disk image file (.dmg) 
for 3.7.4 which is still produced as an artifact of the build process for our 
installers so the Python files it installs are identical to those installed by 
the 10.6 pkg install.  Bundle-format installer packages no longer work on 
modern versions of macOS but should still be OK for 10.6.  Please test and let 
me know if it works for you for 10.6 and I'll add it to the 3.7.4 release page. 
 However, as Ronald noted, be aware that we plan to no longer provide the 10.6 
variant installers for Python 3.8.x.

The dmg installer and its PGP signature file are downloadable here:

https://www.python.org/ftp/python/3.7.4/python-3.7.4-macosx10.6.dmg
https://www.python.org/ftp/python/3.7.4/python-3.7.4-macosx10.6.dmg.asc

--

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

[Eryk Sun]

Eryk Sun  added the comment:

> I wish we could remove the MAX_PATH limit in this case.
>
> The problem is that we have to remove the limit in any case where the 
> resulting path might be used, which is what we're already trying to 
> encourage by supporting long paths.

Maybe it's better to ignore the MAX_PATH limit and let processes fail hard if 
they lack long-path support. A known and expected exception is better than 
unpredictable behavior (see the next paragraph for an example). That leaves the 
problem of a final component that's a reserved name, i.e. a DOS device name or 
a name with trailing dots or spaces. We have no choice but to return this case 
as an extended path. 

The intersection of this problem with SetCurrentDirectoryW (os.chdir) troubles 
me. Without long-path support, the current-directory buffer in the process 
parameters is hard limited to MAX_PATH, and passing SetCurrentDirectoryW an 
extended path can't work around this. Fair enough. But it still accepts a 
device path as the current directory, even though the docs do not explicitly 
allow it, and the implementation assumes it's disallowed. The combination is an 
ugly bug:

>>> os.chdir('//./C:/Temp')
>>> os.getcwd()
'.\\C:\\Temp'
>>> os.path._getfullpathname('/spam/eggs')
'spam\\eggs'

>>> os.chdir('//?/C:/Temp')
>>> os.getcwd()
'?\\C:\\Temp'
>>> os.path._getfullpathname('/spam/eggs')
'spam\\eggs'

In order to resolve a rooted path such as "/spam/eggs", the runtime library 
needs to be able to figure out the current drive from the current directory. It 
checks for a UNC path and otherwise assumes it's a DOS drive, since it's 
assuming device paths aren't allowed. It ends up assuming the current directory 
is a DOS drive and grabs the first two characters as the drive name, which is 
"". Then when joining the rooted path to this 'drive', the initial slash or 
backslash of the rooted path gets collapsed into the preceding backslash. The 
result is at best a broken path, and at worst an unrelated UNC path that 
exists. 

I think os.chdir should raise an exception when passed a device path. In 
explanation, we can point to the documentation of SetCurrentDirectoryW, which 
explicitly states the following:

Each process has a single current directory made up of two parts:

* A disk designator that is either a drive letter followed by 
  a colon, or a server name and share name 
  (\\servername\sharename)
* A directory on the disk designator

> Perhaps the best we can do is an additional test where we 
> GetFinalPathName, strip the prefix, reopen the file, 
> GetFinalPathName again and if they match then return it 
> without the prefix. That should handle the both long path 
> settings as transparently as we can.

I assume you're talking about realpath() here, toward the end where we're 
working with a solid path, or rather where we have at least the beginning part 
of the path as a solid path, up to the first component that's inaccessible.

For the problem of reserved names, GetFullPathNameW is all we need. This 
doesn't address the MAX_PATH issue. But that either works or not. It's a 
user-mode issue. There's nothing to resolve in the kernel. If the path is too 
long, then CreateFileW will fail at 
RtlDosPathNameToRelativeNtPathName_U_WithStatus with STATUS_NAME_TOO_LONG, 
before making a single system call.

--

___
Python tracker 

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

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

[Benjamin Peterson]

Benjamin Peterson  added the comment:

On Wed, Aug 14, 2019, at 03:25, STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> > From my perspective, the main problem with using type annotations is that 
> > there's nothing checking them in CI.
> 
> Even if unchecked, type annotations can serve as builtin documentation, 
> as docstrings (even when docstrings are not checked ;-)).

Yes, but no one has the expectation that docstrings are automatically verified 
in any way. :)

--

___
Python tracker 

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

[issue32771] merge the underlying data stores of unicodedata and the str type

[Benjamin Peterson]

Benjamin Peterson  added the comment:

It's also possible we're missing some logical compression opportunities by 
artificially partitioning the Unicode databases. Encoded optimally, the 
combined databases could very well take up less space than their raw sum 
suggests.

--

___
Python tracker 

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

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 3e4498d35c34aeaf4a9c3d57509b0d3277048ac6 by Benjamin Peterson 
(Greg Price) in branch 'master':
bpo-37760: Avoid cluttering work tree with downloaded Unicode files. (GH-15128)
https://github.com/python/cpython/commit/3e4498d35c34aeaf4a9c3d57509b0d3277048ac6


--

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Greg has read my mind. An optional parameter to upper/lower/casefold was 
exactly the API I was thinking of. No C locales or the locale module involved.

--

___
Python tracker 

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

[issue37862] Search doesn't find built-in functions

[Kim Oldfield]

New submission from Kim Oldfield :

The python 3 documentation search
https://docs.python.org/3/search.html
doesn't always find built-in functions.

For example, searching for "zip" takes me to
https://docs.python.org/3/search.html?q=zip

I would expect the first match to be a link to
https://docs.python.org/3/library/functions.html#zip
but I can't see a link to this page anywhere in the 146 results.

--
assignee: docs@python
components: Documentation
messages: 349781
nosy: docs@python, kim.oldfield
priority: normal
severity: normal
status: open
title: Search doesn't find built-in functions
type: behavior
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

[issue29535] datetime hash is deterministic in some cases

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

Randomizing the hash of datetime objects was first proposed in 
https://bugs.python.org/issue13703#msg151796.

For the same reasons as str and bytes are non-deterministically hashed in in 
PEP 456, shouldn't numerics, datetime objects, and tuples be 
non-deterministically hashed as well? This is for the reason that they can all 
be used as dictionary keys (additionally, hash(n) begins to repeat when n is a 
large enough number) -- so it seems like they are also susceptible to the hash 
collision DoS attacks.

--
nosy: +dmalcolm

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

[Steve Dower]

Steve Dower  added the comment:

And I just posted an update to PR 15231 with essentially a rewrite of stat() on 
Windows. Should be better than it was :)

--

___
Python tracker 

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

[issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren

___
Python tracker 

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

[issue37855] Compiling Python 3.7.4 with Intel compilers 2019

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Seems related : https://bugs.python.org/issue35473

--
nosy: +xtreak

___
Python tracker 

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

[issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1

[Clive Bruton]

Clive Bruton  added the comment:

Additional screen grab shows hardware/OS version.

--
Added file: https://bugs.python.org/file48544/grab2.png

___
Python tracker 

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

[issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1

[Clive Bruton]

New submission from Clive Bruton :

When attempting to install Python >= 3.7.1 on MacOS X 10.6 the installer fails 
with the message:


The operation couldn’t be completed. (com.apple.installer.pagecontroller error 
-1.)

Couldn't open "python-3.7.x-macosx10.6.pkg".


The installer runs without incident with the 3.7.0 installer.

Console reports (when "python-3.7.4-macosx10.6.pkg" is run):

***
15/08/2019 00:03:57 Installer[516]  @(#)PROGRAM:Install  
PROJECT:Install-596.1
15/08/2019 00:03:57 Installer[516]  @(#)PROGRAM:Installer  
PROJECT:Installer-430.1
15/08/2019 00:03:57 Installer[516]  Hardware: Macmini2,1 @ 1.83 GHz (x 2), 
2048 MB RAM
15/08/2019 00:03:57 Installer[516]  Running OS Build: Mac OS X 10.6.8 
(10K549)
15/08/2019 00:03:57 kernel  Installer (map: 0x5a9770c) triggered DYLD 
shared region unnest for map: 0x5a9770c, region 0x7fff8340->0x7fff8360. 
While not abnormal for debuggers, this increases system memory footprint until 
the target exits.
15/08/2019 00:03:58 Installer[516]  Failed to verify data against 
certificate.
15/08/2019 00:03:58 Installer[516]  Invalid Distribution File/Package


Similar reports are available here:

https://python-forum.io/Thread-Cannot-Install-python-3-7-3-macosx10-6-pkg

--
components: Installation
files: grab1.png
messages: 349776
nosy: typonaut
priority: normal
severity: normal
status: open
title: Install fails on MacOS X 10.6 with python >= 3.7.1
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48543/grab1.png

___
Python tracker 

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

[issue36732] test_asyncio: test_huge_content_recvinto() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

> ResourceWarning?

That's a small bug in the test, but the main issue is that 
test_huge_content_recvinto() has a race condition.

--

___
Python tracker 

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

[issue36732] test_asyncio: test_huge_content_recvinto() fails randomly

[Andrew Svetlov]

Change by Andrew Svetlov :


--
assignee:  -> asvetlov

___
Python tracker 

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

[issue36732] test_asyncio: test_huge_content_recvinto() fails randomly

[Andrew Svetlov]

Andrew Svetlov  added the comment:

ResourceWarning?
I'll take a look

--

___
Python tracker 

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

[issue36732] test_asyncio: test_huge_content_recvinto() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

Recent failure on AMD64 Windows7 SP1 3.8:
https://buildbot.python.org/all/#/builders/208/builds/268

test_huge_content_recvinto 
(test.test_asyncio.test_sock_lowlevel.ProactorEventLoopTests) ... 
C:\buildbot.python.org\3.8.kloth-win64\build\lib\test\support\__init__.py:1637: 
ResourceWarning: unclosed 
ResourceWarning: Enable tracemalloc to get the object allocation traceback

ERROR: test_huge_content 
(test.test_asyncio.test_sock_lowlevel.ProactorEventLoopTests)

Re-running failed tests in verbose mode
C:\buildbot.python.org\3.8.kloth-win64\build\lib\test\support\__init__.py:1637: 
ResourceWarning: unclosed 
ResourceWarning: Enable tracemalloc to get the object allocation traceback
FAIL: test_huge_content_recvinto 
(test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests)

--

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Artem Khramov for the nice analysis of the root issue! And thanks for 
the fix! The bug is now fixed in 3.7, 3.8 and master branches.

Python 2.7 is not affected: I added sock_call_ex() helper function in Python 3 
when I implemeneted the PEP 475 (Retry system calls failing with EINTR).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[Steve Dower]

Steve Dower  added the comment:

FYI, there's been some discussion of this on issue37834, as the issues quickly 
became conflated.

There's also issue14094 which is a dup of this one, but with a different patch.

---

To move the relevant discussion here, my current PR is basically the tests from 
the last attached patch here plus a simpler implementation for non-strict 
resolution.

Right now the big open question is how to deal with the \\?\ prefix. My last 
two commits will leave it alone if it was in the initial path, and otherwise 
strip it if the non-prefixed path resolves to the same path as the prefixed 
path (the _getfinalpathname always returns a prefixed path).

The downside of this is that any unresolvable symlinks (dangling links, cycles, 
etc.) will now be returned with the prefix, whereas previously they were being 
returned without any attempt to resolve them being made (not because they are 
invalid, but because the old code wasn't attempting to resolve anything at all).

I kinda feel like this is okay, but would appreciate any other opinions on the 
matter. The alternative is to always strip the prefix, which could make some 
valid paths become invalid (for example, the one in the new 
test_realpath_symlink_prefix).

--
nosy: +eryksun
versions: +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

[issue37834] readlink on Windows cannot read app exec links

[Steve Dower]

Steve Dower  added the comment:

> Perhaps the best we can do is an additional test where we GetFinalPathName, 
> strip the prefix, reopen the file, GetFinalPathName again and if they match 
> then return it without the prefix. That should handle the both long path 
> settings as transparently as we can.

I tried this and the downside (other than hitting the filesystem a few more 
times) is that any unresolvable path is going to come back with the prefix - 
e.g. symlink cycles and dangling links.

Maybe that's okay? The paths are going to be as valid as they can get (that is, 
unusable :) ) and it at least means that long paths and deliberately 
unnormalized paths.

Posted an update to PR 15287 with that change.

--

___
Python tracker 

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

[issue37775] update doc of compileall

[miss-islington]

miss-islington  added the comment:


New changeset dbe4c286ce28402c3bce71d568ae55b91280e777 by Miss Islington (bot) 
in branch '3.8':
bpo-37775: Update compileall doc for invalidation_mode parameter (GH-15148)
https://github.com/python/cpython/commit/dbe4c286ce28402c3bce71d568ae55b91280e777


--
nosy: +miss-islington

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

The bug has been fixed in 3.7, 3.8 and master (future 3.9) branches. I close 
the issue. Thanks to everyone who was involved to report the bug and help to 
find the root issue! The relationship between faulthandler, the Linux kernel 
version, CPU model, and the FPU state size wasn't obvious at the first look ;-)

If someone wants to cleanup/rework how Python handles thread stack size, please 
open a separated issue. I prefer to restrict this issue to 
test_faulthandler.test_register_chain() (which is now fixed).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9 -Python 3.3, Python 3.4, Python 3.5, Python 
3.6

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

"I can confirm that on the specific hardware I could reproduce this, that
PR14276 and setting the stacksize to SIGSTKSZ*2 passes the test_faulthandler 
test."

Thanks for testing. I merged my PR.

About PR 13649, I'm not sure that _PyThread_preferred_stacksize() is still 
relevant, since my change fixed test_faulthandler test_register_chain(). I 
chose my change since it's less invasive: it only impacts faulthandler, and it 
minimalizes the memory usage (especially when faulthandler is not used).

Python/thread_pthread.h refactor changes of PR 13649 are interested. Would you 
like to extract them into a new PR which doesn't add 
_PyThread_preferred_stacksize() but just add new PLATFORM_xxx macros?

--

Maybe test_faulthandler will fail tomorrow on a new platform, but I prefer to 
open a discussion once such case happens, rather than guessing how faulthandler 
can crash on an hypothetical platforms. I'm sure that libc developers are well 
aware of the FPU state size and update SIGSTKSZ accordingly.

glibc code computing xsave_state_size:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-features.c;h=4bab1549132fe8a4c203a70b8c7a51c1dc304049;hb=HEAD#l223

--

If tomorrow, it becomes too hard to choose a good default value for 
faulthandler stack size, another workaround would be to make it configurable, 
as Python lets developers choose the thread stack size: 
_thread.stack_size(size).

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[miss-islington]

miss-islington  added the comment:


New changeset 1581d9c405f140491791a07dca3f6166bc499ec1 by Miss Islington (bot) 
in branch '3.7':
bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276)
https://github.com/python/cpython/commit/1581d9c405f140491791a07dca3f6166bc499ec1


--

___
Python tracker 

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

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +15018
pull_request: https://github.com/python/cpython/pull/15295

___
Python tracker 

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

[issue37775] update doc of compileall

[miss-islington]

Change by miss-islington :


--
pull_requests: +15017
pull_request: https://github.com/python/cpython/pull/15294

___
Python tracker 

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

[issue37775] update doc of compileall

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 68e495df909a33e719e3f1ef5b4893ec785e10a4 by Victor Stinner (Hai 
Shi) in branch 'master':
bpo-37775: Update compileall doc for invalidation_mode parameter (GH-15148)
https://github.com/python/cpython/commit/68e495df909a33e719e3f1ef5b4893ec785e10a4


--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[miss-islington]

miss-islington  added the comment:


New changeset b8e682427a80798fec90dce31392beaf616c3e37 by Miss Islington (bot) 
in branch '3.8':
bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276)
https://github.com/python/cpython/commit/b8e682427a80798fec90dce31392beaf616c3e37


--
nosy: +miss-islington

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> I see that now. The behaviour was different in Linux, though, I suppose it 
> may benefit from a more precise counter, but since in Windows it also has a 
> precise counter with time.perf_counter_ns(), I was expecting to see that 
> value change, but it was mainly a confusion with the older time.clock().

On Windows, time.clock() was implemented with QueryPerformanceCounter(). This 
function became time.perf_counter() in Python 3.4. time.clock() was removed. 
Use time.get_clock_info('perf_counter') ;-)

The PEP 418 introduces new well defined clocks, since time.clock() was not 
portable.

perf_counter and process_time have very different properties. process_time is 
stopped when the process sleeps, for example.

https://docs.python.org/dev/library/time.html#time.perf_counter
https://docs.python.org/dev/library/time.html#time.process_time

--

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). 
> But the kernel schedules threads based on a timer that ticks every 15.625 ms 
> by default. It can be lowered to about 0.5 ms, but this degrades battery life.

Patches are welcome to enhance time.get_clock_info() :-)

Don't rely too much on time.get_clock_info() on Linux neither: it basically 
always say 1 ns, even if the effective resolution is way worse.

See the PEP 418 for some numbers:
https://www.python.org/dev/peps/pep-0418/#process-time

I wrote these programs to write this PEP ;-)

https://github.com/python/peps/tree/master/pep-0418

--
nosy: +vstinner

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[miss-islington]

miss-islington  added the comment:


New changeset b0b178a2b80974da910ce6a344d66cc4d9a2fcfa by Miss Islington (bot) 
in branch '3.7':
bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202)
https://github.com/python/cpython/commit/b0b178a2b80974da910ce6a344d66cc4d9a2fcfa


--

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[miss-islington]

miss-islington  added the comment:


New changeset 123f6c4914827c4ced65d032fab74de62db31cd6 by Miss Islington (bot) 
in branch '3.8':
bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202)
https://github.com/python/cpython/commit/123f6c4914827c4ced65d032fab74de62db31cd6


--
nosy: +miss-islington

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[Eryk Sun]

Eryk Sun  added the comment:

> I suppose it may benefit from a more precise counter, but since in 
> Windows it also has a precise counter with time.perf_counter_ns(), 
> I was expecting to see that value change, but it was mainly a 
> confusion with the older time.clock().

Don't read too much into the clock info here:

>>> time.get_clock_info('process_time').resolution
1e-07

Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). But 
the kernel schedules threads based on a timer that ticks every 15.625 ms by 
default. It can be lowered to about 0.5 ms, but this degrades battery life.

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes

--
nosy: +eryksun

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

[Steve Dower]

Steve Dower  added the comment:

> Given the only option here is follow_symlinks, then the first CreateFileW 
> call in win32_xstat_impl should only open a reparse point if follow_symlinks 
> is false. In this case, if it happens to open a reparse point that's not a 
> symlink, it should try to reopen with reparsing enabled. In either case, if 
> reparsing fails because a reparse point isn't handled 
> (ERROR_CANT_ACCESS_FILE), try to open the reparse point itself. The latter 
> would be the second open attempt if follow_symlinks is true and the third 
> open attempt if follow_symlinks is false. 
>
> If a reparse point isn't handled, then there's nothing in principle that 
> stat() could ever follow. Given that it's impractical to fail in this case, 
> considering how much code would have to be modified, then the above 
> compromise should suffice.

This sounds like reasonable logic. I'll take a look at updating my PR.

> In the proposed implementation of realpath() that I helped on for issue 14094

I totally forgot about this issue and the PR (but it looks like the contributor 
did too). I just posted PR 15287 today with the tests from the patch on 
issue9949 and it's looking okay - certainly an improvement over the current 
behaviour. But it doesn't have the change to readlink() that would add the \\?\ 
prefix, which means it doesn't answer that question.

> I wish we could remove the MAX_PATH limit in this case.

The problem is that we have to remove the limit in any case where the resulting 
path might be used, which is what we're already trying to encourage by 
supporting long paths.

Perhaps the best we can do is an additional test where we GetFinalPathName, 
strip the prefix, reopen the file, GetFinalPathName again and if they match 
then return it without the prefix. That should handle the both long path 
settings as transparently as we can.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[miss-islington]

Change by miss-islington :


--
pull_requests: +15016
pull_request: https://github.com/python/cpython/pull/15292

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[miss-islington]

Change by miss-islington :


--
pull_requests: +15015
pull_request: https://github.com/python/cpython/pull/15291

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ac827edc493d3ac3f5b9b0cc353df1d4b418a9aa by Victor Stinner in 
branch 'master':
bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276)
https://github.com/python/cpython/commit/ac827edc493d3ac3f5b9b0cc353df1d4b418a9aa


--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

"I can understand the aversion to the waste when its never used - I can address 
37851 if you like - it seems pretty simple to fix. The pedant in me must point 
out that it's 8M of address space, not memory. The cost on 64-bit (well, with a 
47-bit user address space) is vanishingly small, ..."

Well, many users pay attention to the RSS value and don't care if the memory is 
physically allocated or not.

Moreover, I'm not sure that we can fix bpo-37851 in Python 3.7. In general, the 
policy is to minimize changes in stable Python versions. I'm not sure for 
Python 3.8 neither. I would suggest to only modify Python 3.9, simply to reduce 
the risk of regressions.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

"I do think SIGSTKSZ*2=16k is far too small considering the fault handler could 
be running arbitrary python code,"

We are talking abou the faulthandler_user() function of Modules/faulthandler.c. 
It is implemented in pure C, it doesn't allocate memory on the heap, it uses a 
very small set of functions (write(), sigaction(), raise()) and it tries to 
minimize its usage of the stack memory.

It is very different than the traceback module which is implemented in pure 
Python.

faulthandler is really designed to debug segmentation fault, stack overflow, 
Python hang (like a deadlock), etc.

--

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 28146206578ebe1b84b48e6f255738a227058c04 by Victor Stinner (Artem 
Khramov) in branch 'master':
bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202)
https://github.com/python/cpython/commit/28146206578ebe1b84b48e6f255738a227058c04


--

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[miss-islington]

Change by miss-islington :


--
pull_requests: +15014
pull_request: https://github.com/python/cpython/pull/15290

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[miss-islington]

Change by miss-islington :


--
pull_requests: +15013
pull_request: https://github.com/python/cpython/pull/15289

___
Python tracker 

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

[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

[STINNER Victor]

STINNER Victor  added the comment:

> See Also: #31334

Oh, I didn't know bpo-31334. This issue is basically a duplicate of bpo-31334, 
but triggered differently.

--
nosy: +vstinner

___
Python tracker 

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

[issue37860] Add netlify deploy preview for docs

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


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

___
Python tracker 

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

[issue37860] Add netlify deploy preview for docs

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


--
nosy: +Mariatta

___
Python tracker 

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

[issue37860] Add netlify deploy preview for docs

[Ashwin Ramaswami]

New submission from Ashwin Ramaswami :

It would be good to preview the cpython documentation on PRs using Netlify.

See https://github.com/python/core-workflow/issues/348

--
assignee: docs@python
components: Documentation
messages: 349752
nosy: docs@python, epicfaace
priority: normal
severity: normal
status: open
title: Add netlify deploy preview for docs
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

[issue37826] Document PEP 3134 in tutorials/errors.rst

[miss-islington]

miss-islington  added the comment:


New changeset dcfe111eb5602333135b8776996332a8dcf59392 by Miss Islington (bot) 
(Abhilash Raj) in branch 'master':
bpo-37826: Document exception chaining in Python tutorial for errors. (GH-15243)
https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dcf59392


--
nosy: +miss-islington

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Christian Heimes]

Christian Heimes  added the comment:

PEP 456 explains why hash of str and bytes must be randomized.

I don't know any reason why hash of datetime objects must be randomized. They 
can be deterministic like floats and ints.

--

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

[Eryk Sun]

Eryk Sun  added the comment:

> but suddenly adding "\\?\" to the paths breaks a lot of assumptions.

The unwritten assumption has been that readlink() is reading symlinks that get 
created by CreateSymbolicLinkW, which sets the print name as the DOS path 
that's passed to the call. In this case, readlink() can rely on the print name 
being the intended DOS path. I raised a concern in the case of reading 
junctions. There's no high-level API to create junctions, so we can't assume 
the print name is reliable. PowerShell's new-item doesn't even set a print name 
for junctions. That symlinks also are valid without a print name (in principle; 
I haven't come across it practice) lends additional weight to always using the 
substitute name.

Even if we have the DOS path, resolving paths manually is still complicated if 
it's a relative symlink with a reserved name (DOS device; trailing dots or 
spaces) as the final component or if it's a long path. Reparsing a relative 
symlink in the kernel doesn't reserve such names and there's no MAX_PATH limit 
in the kernel. So using readlink() is tricky. Fortunately realpath() in Windows 
doesn't require a resolve loop based on readlink(). The kernel almost always 
knows the final path of an opened file, and we can walk the components from the 
end until we find one that exists.

> My idea was to GetFinalPathName(path[4:])[4:] and if that fails

An existing file named "spam" would be a false positive for a link that targets 
"spam.". The internal CreateFileW call would open "spam". Also, symlinks allow 
remote paths, and this doesn't handle "?\\UNC" paths. More generally, a 
link target doesn't have to exist, so being able to access it shouldn't be a 
factor. I see it's also returning the result from _getfinalpathname. readlink() 
doesn't resolve a final, solid path. It just returns the contents of a link, 
which can be a relative or absolute path.

In the proposed implementation of realpath() that I helped on for issue 14094 
(I wasn't aware of the previous work in issue 9949), there's an 
_extended_to_normal function that tries to return a normal path if possible. 
The length of the normal path has to be less than MAX_PATH, and 
_getfullpathname should return the path unchanged. GetFullPathNameW is just 
rule-based processing in user mode; it doesn't touch the file system.

I wish we could remove the MAX_PATH limit in this case. I think at startup we 
should try to call RtlAreLongPathsEnabled, even though it's not documented, and 
set a sys flag to indicate whether we can use long paths. Also, support a -X 
option and an environment variable to override automatic detection.

--

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[Red Glyph]

Red Glyph  added the comment:

I see that now. The behaviour was different in Linux, though, I suppose it may 
benefit from a more precise counter, but since in Windows it also has a precise 
counter with time.perf_counter_ns(), I was expecting to see that value change, 
but it was mainly a confusion with the older time.clock().

Thanks!

--

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

[Eryk Sun]

Eryk Sun  added the comment:

> I really want a fix for this in 3.8, or else os.stat(sys.executable) 
> may fail

I agree, but Python can support this without handling junctions as symlinks or 
limiting the reparse points that we can follow. There are reparse points for 
offline storage and projected file systems (e.g. VFS for Git) that should 
normally be traversed, and to that I would add junctions. stat() in Unix always 
opens a mounted directory, not the underlying directory of a mount point. 
Windows Python should try to be consistent with Unix where doing so is 
reasonable. 

Given the only option here is follow_symlinks, then the first CreateFileW call 
in win32_xstat_impl should only open a reparse point if follow_symlinks is 
false. In this case, if it happens to open a reparse point that's not a 
symlink, it should try to reopen with reparsing enabled. In either case, if 
reparsing fails because a reparse point isn't handled (ERROR_CANT_ACCESS_FILE), 
try to open the reparse point itself. The latter would be the second open 
attempt if follow_symlinks is true and the third open attempt if 
follow_symlinks is false. 

If a reparse point isn't handled, then there's nothing in principle that stat() 
could ever follow. Given that it's impractical to fail in this case, 
considering how much code would have to be modified, then the above compromise 
should suffice.

I checked RtlNtStatusToDosError over the range 0xC000_ - 0xC0ED_. (In 
ntstatus.h, FACILITY_MAXIMUM_VALUE is 0xED, so there's no point in checking 
facilities 0x0EF-0xFFF.) Only STATUS_IO_REPARSE_TAG_NOT_HANDLED maps to 
ERROR_CANT_ACCESS_FILE, so we don't have to worry about unrelated failures 
using this error code. This is separate from an invalid reparse point 
(ERROR_INVALID_REPARSE_DATA) or a reparse point that can't be resolved 
(ERROR_CANT_RESOLVE_FILENAME), which should still be errors that fail the call.

--

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[Zachary Ware]

Change by Zachary Ware :


--
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[Zachary Ware]

Zachary Ware  added the comment:

Try this:

while time.process_time() < 0.5:
print('.', flush=True, end='')

Or:

>>> time.process_time()
0.03125
>>> len(str(2**500_000))
150515
>>> time.process_time()
0.484375


Basically, process_time() (and process_time_ns()) measure CPU time used by the 
process, and you aren't making the CPU do anything between your checks.

--
resolution: not a bug -> 
stage: resolved -> 
status: closed -> pending

___
Python tracker 

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

[issue37859] time.process_time() constant / erratic on Windows

[Red Glyph]

Change by Red Glyph :


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

[issue37859] time.process_time() constant / erratic on Windows

[Red Glyph]

New submission from Red Glyph :

Tested with 
- Python 3.7.4, 64-bit, Windows version (installer version)
- python-3.8.0b3-embed-amd64.zip
- python-3.7.2.post1-embed-amd64.zip 
on Windows 7 x64 Professional

time.process_time() always returns the same value. If I check the value of 
time.process_time_ns(), sometimes it is constant, sometimes I observe a few 
changes, then it becomes constant too.

Here is a log of an example session, I'm waiting at least 1-2 seconds between 
each command:

Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> import time
>>> time.process_time()
0.1092007
>>> time.process_time()
0.1092007
>>> time.process_time_ns()
109200700
>>> time.process_time_ns()
124800800
>>> time.process_time_ns()
124800800
>>> time.process_time()
0.1248008
>>> time.process_time()
0.1248008
>>> time.process_time()
0.1248008
>>> time.process_time_ns()
124800800
>>> time.process_time_ns()
124800800
>>> time.process_time_ns()
124800800
>>> time.process_time_ns()
124800800
>>> time.clock()

Warning (from warnings module):
  File "__main__", line 1
DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be 
removed from Python 3.8: use time.perf_counter or time.process_time instead
77.006126126
>>> time.clock()
79.245575778
>>> time.clock()
80.801103036
>>> time.process_time()
0.1248008
>>>

--
components: Library (Lib), Windows
messages: 349745
nosy: Red Glyph, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: time.process_time() constant / erratic on Windows
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file

[Ned Deily]

Change by Ned Deily :


--
nosy:  -ned.deily

___
Python tracker 

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

[issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file

[Ned Deily]

Ned Deily  added the comment:

(removing the macOS component since presumably this behavior is not 
platform-dependent)

--
components:  -macOS
nosy:  -ronaldoussoren

___
Python tracker 

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

[issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file

[Ashley Harvey]

New submission from Ashley Harvey :

I'm on macOS 10.14.6, wget 1.20.3, python 2.7.

Command line:
$ wget --save-cookies cookies.txt --keep-session-cookies --post-data
'username=myUserName=myPassword' --delete-after 

Line 39 of _MozillaCookieJar.py (cookielib) shows it looking for 'magic_re = 
"#( Netscape)? HTTP Cookie File"' in order to validate the supplied cookies 
file.  Unlike cURL, wget however, produces a cookies file that begins with "# 
HTTP cookie file".  Note the lower-case c and f.  I reported this as a bug to 
the wget team who looked for the spec to say that that line must follow a 
certain format and couldn't find any such mention.  (See: 
https://savannah.gnu.org/bugs/?56755)

The lack of upper-case c and f cause cookielib to choke and stop processing
the cookies file, and so here I am reporting it as a bug that the regex is 
case-sensitive.

--
components: Library (Lib), macOS
messages: 349743
nosy: ashleyharvey, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate 
cookies file
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +15011
pull_request: https://github.com/python/cpython/pull/15287

___
Python tracker 

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

[issue35214] Get the test suite passing with clang Memory Sanitizer enabled

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Nope, work remains to be done.  I've got an msan buildbot system waiting but 
haven't had time to follow up on figuring out what remains in a while.  
(getting a functioning memory sanitizer build is... finnicky to say the least)

--

___
Python tracker 

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

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

[Zane Bitter]

Change by Zane Bitter :


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

___
Python tracker 

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

[issue30962] Add caching to logging.Logger.isEnabledFor()

[Zane Bitter]

Change by Zane Bitter :


--
pull_requests: +15009
pull_request: https://github.com/python/cpython/pull/15286

___
Python tracker 

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

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

[SilentGhost]

Change by SilentGhost :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

[Zane Bitter]

New submission from Zane Bitter :

This is a related issue to bug 34269, in the sense that it is also due to the 
caching added by the fix for bug 30962.

In this case, the bug is triggered by setting the public 'level' attribute of a 
logging.Logger object, instead of calling the setLevel() method. Although this 
was probably never a good idea, prior to Python3.7 it worked as expected. Now 
it renders the level out of sync with the cache, leading to inconsistent 
results that are hard to debug.

An example in the wild: https://review.opendev.org/676450

--
components: Library (Lib)
messages: 349741
nosy: zaneb
priority: normal
severity: normal
status: open
title: Setting logger.level directly has no effect due to caching in 3.7+
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue37856] Adding additional python installations to py launcher

[evanTO]

New submission from evanTO :

I have four instances of Python installed on my machine, 2.7x32 & 3.7x32 that I 
installed manually into their default locations, and 2.7x64 & 3.4x64 that came 
pre-packaged with a third party piece of software (SPSS). Py Launcher 
successfully detects the two installations that I installed manually but cannot 
see the two installations that came with the third party software.

Here (https://www.python.org/dev/peps/pep-0397/#configuration-file) there is an 
allusion to there being commands which allow customization of Py launcher 
within user space (monkeying around with the registry in a corporate 
environments is often disallowed).

I have created a py.ini file using the [commands] section with respective 
copies of the following entry: "3.4-64="C:\Program 
Files\IBM\SPSS\Statistics\24\Python3\python.exe" and saved to 
"C:\Users\\AppData\Local" but the additional installations do not appear.

I have added the two additional installation directories (and Scripts folders) 
to the PATH variable and confirmed that the changes persisted (displayed below):

PATH=C:\Program Files (x86)\Python37-32\Scripts\;C:\Program Files 
(x86)\Python37-32\;C:\Python27\;C:\Python27\Scripts;C:\Program 
Files\IBM\SPSS\Statistics\24\Python\;C:\Program 
Files\IBM\SPSS\Statistics\24\Python\Scripts\;C:\Program 
Files\IBM\SPSS\Statistics\24\Python3\;C:\Program 
Files\IBM\SPSS\Statistics\24\Python3\Scripts\;

Current result of "py -0p" (List the available pythons with paths)

C:\>py -0p
Installed Pythons found by py Launcher for Windows
 -3.7-32"C:\Program Files (x86)\Python37-32\python.exe" *
 -2.7-32C:\Python27\python.exe


Expected result of "py -0p"

C:\>py -0p
Installed Pythons found by py Launcher for Windows
 -3.7-32"C:\Program Files (x86)\Python37-32\python.exe" *
 -2.7-32C:\Python27\python.exe
 -3.4-64"C:\Program Files\IBM\SPSS\Statistics\24\Python3\python.exe"
 -2.7-64"C:\Program Files\IBM\SPSS\Statistics\24\Python\python.exe"

--
components: Windows
messages: 349740
nosy: evanTO, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Adding additional python installations to py launcher
type: behavior
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

In following subplot I have to change the first plot into a bar plot. But using plt.bar rather than plt.plot gives a white plot !

[amirrezaheidarysbu]

plt.Figure()


plt.subplots_adjust(top=0.945, bottom=0.05, left=0.04, right=0.985, 
hspace=0.67, wspace=0.345)

plt.subplot(6,1,1)
plt.plot(Date,Energy, "r")
plt.title("Hourly hot water energy use")
plt.ylabel("kWh")
plt.margins(x=0)


plt.subplot(6,1,2)
plt.plot(Date,Tin)
plt.title("Indoor air temperature")
plt.ylabel("Celsius")
plt.margins(x=0)

plt.subplot(6,1,3)
plt.plot(Date,RHin, "g")
plt.title("Indoor air relative humidity")
plt.ylabel("%")
plt.margins(x=0)

plt.subplot(6,1,4)
plt.plot(Date,Tamb, "darkblue")
plt.title("Ambient air temperature")
plt.ylabel("Celsius")
plt.margins(x=0)

plt.subplot(6,1,5)
plt.plot(Date,Insol, "gold")
plt.title("Solar insolation")
plt.ylabel("$W/m^2$")
plt.margins(x=0)

plt.subplot(6,1,6)
plt.plot(Date,Wind, "darkslategrey")
plt.title("Wind speed")
plt.ylabel("$m/s$")
plt.margins(x=0)


plt.show()
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37848] More fully implement Unicode's case mappings

[Greg Price]

Greg Price  added the comment:

(I should add that it was only after doing the reading that produced the OP 
that I had a clear idea what I thought the priority of the issue was -- before 
doing that work I didn't have a clear sense of the scope of what it affects. 
Based on that SpecialCasing.txt file as of Unicode 12.0.0, I believe the 
functionality we don't currently support is entirely about the handling of 
certain versions of the Latin letter I, as treated in Lithuanian, Turkish, and 
Azerbaijani. Though one function of this issue thread is that it would be a 
great place to point out if there's another component to it!)

--

___
Python tracker 

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

[issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide

[reimar]

reimar  added the comment:

I guess one way this could be "solved" would be by libpython doing a dlopen on 
itself with RTLD_GLOBAL on Python initialization.
I wouldn't bet that that wouldn't end up with some very interesting unintended 
consequences as well though.

--

___
Python tracker 

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

[issue37833] tkinter crashes macOS in the latest macOS update 10.14.6

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The py2app issue I mentioned is not relevant for this issue. 

A simple tkinter runs fine with Python 3.7 (64-bit, 3.7.4, Python.org 
installer), the same script causes a WindowServer crash (SEGV) when bundled 
with py2app. 

This is definitely a bug in macOS, the WindowServer should not crash like this 
even if an app is misbehaving. 

I'm therefore changing the status of this issue to closed/third party.

--
resolution:  -> third party
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

[issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide

[reimar]

reimar  added the comment:

I'm not sure how I can explain it much better, I even wrote example code after 
all, but I'll try...

> So if you are embedding python by dlopen'ing libpython.so

Neither me nor Laszlo are using/embedding or otherwise involving Python 
(directly/intentionally at least).
We just want to load some .so file.
That .so itself might then use libpython. Or use a library that uses libpython. 
Or uses a library that uses a library  that uses libpython.
And how could we know whether SOME library down that dependency chain uses 
libpython or not?
The result is that now EVERY SINGLE LIBRARY IN THE WHOLE SYSTEM needs to be 
loaded with RTLD_GLOBAL.
Because a library 50 dependencies down that uses python might break otherwise 
and there's not really any way to know.

Just to try be very clear: We are not users of libpython, we do not write or 
use any python code ourselves (except through indirect dependencies) and we are 
still hit by this issue.

--

___
Python tracker 

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

[issue19820] docs are missing info about module attributes

[Michael Anckaert]

Michael Anckaert  added the comment:

@emmanuel: thanks for offering your help. 

I made a first attempt at improving the docs in this branch: 
https://github.com/MichaelAnckaert/cpython/tree/bpo-19820

--

___
Python tracker 

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

[issue37855] Compiling Python 3.7.4 with Intel compilers 2019

[Zhiyong Zhang]

New submission from Zhiyong Zhang :

Compilation of Python 3.7.4 with Intel icc/2019 failed with the following 
errors: 

icpc -c -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -O0 -Wall -O3 
-fp-model strict -fp-model source -xHost -ipo -prec-div -prec-sqrt   -std=c++11 
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fp-model strict -Wextra 
-Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fp-model strict  -IObjects -IInclude 
-IPython -I. -I../Include-DPy_BUILD_CORE -o Programs/python.o 
../Programs/python.c
In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(32): error: identifier "memory_order_relaxed" is undefined
  _Py_memory_order_relaxed = memory_order_relaxed,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(33): error: identifier "memory_order_acquire" is undefined
  _Py_memory_order_acquire = memory_order_acquire,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(34): error: identifier "memory_order_release" is undefined
  _Py_memory_order_release = memory_order_release,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(35): error: identifier "memory_order_acq_rel" is undefined
  _Py_memory_order_acq_rel = memory_order_acq_rel,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(36): error: identifier "memory_order_seq_cst" is undefined
  _Py_memory_order_seq_cst = memory_order_seq_cst
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(40): error: identifier "atomic_uintptr_t" is undefined
  atomic_uintptr_t _value;
  ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(44): error: identifier "atomic_int" is undefined
  atomic_int _value;
  ^

--
components: Installation
messages: 349734
nosy: zyzhang2006
priority: normal
severity: normal
status: open
title: Compiling Python 3.7.4 with Intel compilers 2019
type: compile error
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

[issue37848] More fully implement Unicode's case mappings

[Greg Price]

Greg Price  added the comment:

> Maintaining Python is already expensive [...] There are already enough bugs 
> waiting for you to be fixed ;-)

BTW I basically agree with this. I think this is not a high-priority issue, and 
I have my eye on some of those bugs. :-)

I think the fact that it's per-*language* (despite my inaccurate phrasing in 
the OP), not per-locale, simplifies it some -- for example the whole `.UTF-8` 
vs `.utf8` thing doesn't appear. And in particular I think if/when someone 
decides to sit down and make an implementation of this, then if they take the 
time to carefully read and absorb the relevant pages of the standard... this is 
a feature where it's pretty feasible for the implementation to be a 
self-contained and relatively stable and low-bugs piece of code.

And in general I think even if nobody implements it soon, it's useful to have 
an issue that can be pointed to for this feature, and especially so if the 
discussion clearly lays out what the feature involves and what different 
people's views are on the API. For example #18236 has been open for 6 years, 
but the discussion there was extremely helpful for me to understand it and work 
up a fix, after just being pointed to it by someone who'd searched the tracker 
on seeing me send in the doc fix GH-15019.

--

___
Python tracker 

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