[issue37337] Add _PyObject_VectorcallMethod() function

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 43d564c18c97421f73025ac3132a194975c76bd6 by Inada Naoki (Zackery 
Spytz) in branch 'master':
bpo-37337: Fix a GCC 9 warning in Objects/descrobject.c (GH-14814)
https://github.com/python/cpython/commit/43d564c18c97421f73025ac3132a194975c76bd6


--

___
Python tracker 

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

[issue28747] Expose SSL_CTX_set_cert_verify_callback

[Chih-Hsuan Yen]

Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue37846] declare that Text I/O use buffer inside

[Inada Naoki]

Inada Naoki  added the comment:

It's just an implementation detail.  Python implementation and C implementation 
behave slightly different.  But user program shouldn't rely on the detail.

Why do you think implementation details should be declared?
Who needs the information?

--
nosy: +inada.naoki

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

New submission from Greg Price :

Splitting this out from #32771 for more specific discussion. Benjamin writes 
there that it would be good to:

> implement the locale-specific case mappings of 
> https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and §3.13 of 
> the Unicode 12 standard in str.lower/upper/casefold.

and adds that an implementation would require having available in the core the 
data on canonical combining classes, which is currently only in the unicodedata 
module.

---

First, I'd like to better understand what functionality we have now and what 
else the standard describes.  Reading 
https://www.unicode.org/Public/12.0.0/ucd/SpecialCasing.txt , I see
* a bunch of rules that aren't language-specific
* some other rules that are.

I also see in makeunicodedata.py that we don't even parse the language-specific 
rules.

Here's, IIUC, a demo of us correctly implementing the language-independent 
rules.  One line in the data file reads:

FB00; FB00; 0046 0066; 0046 0046; # LATIN SMALL LIGATURE FF

And in fact the `lower`, `title`, and `upper` of `\uFB00` are those strings 
respectively:

$ unicode --brief "$(./python -c \
   's="\ufb00"; print(" ".join((s.lower(), s.title(), s.upper(')"
ff U+FB00 LATIN SMALL LIGATURE FF
  U+0020 SPACE
F U+0046 LATIN CAPITAL LETTER F
f U+0066 LATIN SMALL LETTER F
  U+0020 SPACE
F U+0046 LATIN CAPITAL LETTER F
F U+0046 LATIN CAPITAL LETTER F

OK, great.

---


Then here's something we don't implement. Another line in the file reads:

00CD; 0069 0307 0301; 00CD; 00CD; lt; # LATIN CAPITAL LETTER I WITH ACUTE

IOW `'\u00CD'` should lowercase to `'\u0069\u0307\u0301'`, i.e.:

i U+0069 LATIN SMALL LETTER I
 ̇ U+0307 COMBINING DOT ABOVE
 ́ U+0301 COMBINING ACUTE ACCENT

... but only in a Lithuanian (`lt`) locale.

One question is: what would the right API for this be? I'm not sure I'd want 
`str.lower`'s results to depend on the process's current Unix locale... and I 
definitely wouldn't want to get that without some way of instead telling it 
what locale to use. (Either to use a single constant locale, or to use a 
per-user locale in e.g. a web application.)  Perhaps `str.lower` and friends 
would take a keyword argument `locale`?


Oh, one more link for reference: the said section of the standard is in this 
PDF: https://www.unicode.org/versions/Unicode12.0.0/ch03.pdf , near the end.


And a related previous issue: #12736.

--
components: Unicode
messages: 349646
nosy: Greg Price, benjamin.peterson, ezio.melotti, lemburg, vstinner
priority: normal
severity: normal
status: open
title: More fully implement Unicode's case mappings
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

[issue28747] Expose SSL_CTX_set_cert_verify_callback

[Marcelo Salhab Brogliato]

Marcelo Salhab Brogliato  added the comment:

Exposing SSL_CTX_set_cert_verify_callback is useful when we want to use a 
Public Key Authentication, like it is done in the SSH Protocol.

Do you know any other way to use Public Key Authentication besides using 
SSL_CTX_set_cert_verify_callback?

--
nosy: +Marcelo Salhab Brogliato

___
Python tracker 

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

[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +14986
pull_request: https://github.com/python/cpython/pull/14814

___
Python tracker 

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[Christian Heimes]

Christian Heimes  added the comment:

This is not a bug in Python but a misconfiguration on your side. A workaround 
for a misconfiguration doesn't belong into upstream code. The certificate 
validation code is security-sensitive and I don't feel comfortable to add 
unnecessary string transformation to it. The code refuses bad wildcards because 
we have had more than one CVE related to wildcard matching.

Besides the ssl.match_hostname() function is deprecated and no longer used. 
Starting with Python 3.7 the ssl module uses OpenSSL to verify host names.

I suggest that you either ship this fix locally with your app. Or talk to IT 
again and have them replace the wrong certificate with a correct one that does 
not violate the standards.

--
resolution:  -> rejected
stage: patch review -> 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

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

[Greg Price]

Change by Greg Price :


--
pull_requests: +14985
pull_request: https://github.com/python/cpython/pull/15265

___
Python tracker 

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

[issue17305] IDNA2008 encoding is missing

[Christian Heimes]

Christian Heimes  added the comment:

You have to ask the Chrome team.

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

[issue17305] IDNA2008 encoding is missing

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

Why would chrome still be using IDNA 2003 to link http://straße.de to 
http://strasse.de?

--

___
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

[Greg Price]

Greg Price  added the comment:

> From my perspective, the main problem with using type annotations is that 
> there's nothing checking them in CI.

Yeah, fair concern. In fact I think I'm on video (from PyCon 2018) warning 
everyone not to do that in their codebases, because what you really don't want 
is a bunch of annotations that have gradually accumulated falsehoods as the 
code has changed around them.

Still, I think from "some annotations + no checking" the good equilibrium to 
land in "some annotations + checking", not "no annotations + no checking". (I 
do mean "some" -- I don't predict we'll ever go sweep all over adding them.) 
And I think the highest-probability way to get there is to let them continue to 
accumulate where people occasionally add them in new/revised code... because 
that holds a door open for someone to step up to start checking them, and then 
to do the work to make that part of CI. (That someone might even be me! But I 
can think of plenty of other likely folks to do it.)

If we accumulated quite a lot of them and nobody had yet stepped up to make 
checking happen, I'd worry.  But with the smattering we currently have, I think 
that point is far off.

--

___
Python tracker 

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

[issue17305] IDNA2008 encoding is missing

[Ashwin Ramaswami]

Change by Ashwin Ramaswami :


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

___
Python tracker 

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

[issue33661] urllib may leak sensitive HTTP headers to a third-party web site

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

Martin, are you okay with doing this? It seems like this issue has been the 
topic of a few CVEs 
(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20060, 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-18074, 
https://curl.haxx.se/docs/CVE-2018-107.html) as well.

--
nosy: +epicfaace

___
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

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

Can this be closed now?

--
nosy: +epicfaace

___
Python tracker 

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

[issue37847] The IDLE does not show previous code suggestions if I tap on the up arrow

[Edwin Pratt]

New submission from Edwin Pratt :

If I am typing some Python code in the IDLE, for example a function:

def sayHi(name):
print('Hello ', name)

and I execute the function:

sayHi('Ed')

I can not edit the function or execute a previous line of code again if I tap 
the up arrow on my keyboard. It seemed to work in the previous versions of 
Python. In order to execute a previous line of code I have to either copy it, 
or type it in again.

--
assignee: terry.reedy
components: IDLE
messages: 349638
nosy: Edwin Pratt, terry.reedy
priority: normal
severity: normal
status: open
title: The IDLE does not show previous code suggestions if I tap on the up arrow
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

[issue32423] The Windows SDK version 10.0.15063.0 was not found

[Isuru Fernando]

Isuru Fernando  added the comment:

Fixed in https://github.com/python/cpython/pull/12445

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

[issue29535] datetime hash is deterministic in some cases

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

I've added a PR which should fix this. Do you think the documentation should 
also be updated to change "By default, the :meth:`__hash__` values of str, 
bytes and datetime objects are "salted" with an unpredictable random value." to 
"By default, the :meth:`__hash__` values of str, bytes, datetime.date, 
datetime.time and datetime.datetime objects are "salted" with an unpredictable 
random value."?

Technically, there are other objects in datetime such as datetime.relativedelta 
whose hash values are _not_ non-deterministic.

--

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

[Artem Khramov]

Change by Artem Khramov :


--
components: +FreeBSD, IO, Library (Lib), 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

[issue37821] IDLE shell uses wrong namespace for completions

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The current behavior is the quick and easy/dirty solution that we have, not 
what we especially want.  #27609 has multiple issues and ideas for completion 
improvements.  I made testing and improving the code priorities before worrying 
about most of the proposed changes.

Here is where we got confused a bit.  The title refers to shell completions.  
The opening post starts with shell completions and then moves to intended 
behavior for editor completions and its dependence on the presence of a shell.  
I disagreed with the latter and responded, not thinking much about shell 
completions.  Lets stick to shell completions, at least initially (and change 
the title if we include editor completions).

Tal: "Perhaps we should differentiate between completions in the shell vs. when 
editing a file."  I agree that we can consider adjusting the list according to 
the setting.  It is easy enough.  Open_completions, executed in the idle 
process, can detect whether the associated text is the shell or an editor and 
pass a (new) flag to fetch_completions, which will pass it to the 
fetch_completions executed in the run process.
 
Tal: "In the shell, having completions for things not actually available is 
weird".  That I can see and agree to. While the editor allows after-completion 
revisions anywhere in the file before running, the user cannot revise Shell 
history and insert an executed import before executing the current statement.  
A doc statement like "Name and attribute completion in the shell is restricted 
to names and objects available after previous shell statements." seems clear 
enough to anyone who reads it.

As near as I can tell, both before and after the #21261 patch, name (tab) 
completion *is* restricted to valid names.  But attribute completion will 
complete for modules such as socket import by run.py even when not in the main 
namespace.  Python in masOS Terminal (bash, I believe) does attribute 
completion (.), but only for user visible names, not, for instance, for 
reprlib.  The proposal is to restrict IDLE's Shell's attribute completion 
similarly.

Tal: "I really dislike the arbitrary availability of only certain modules for 
completion."  It is not completely arbitrary.  We could complete stdlib names 
from a pre-generated list.  But that would add perhaps 400 names to the name 
completion list.  But we can only complete attributes (which I, at least, use 
much more) for modules in sys.modules. A possible improvement mentioned more 
than once is on-demand import, at least of stdlib modules.  If any are shown to 
be a problem, we could make a blacklist.

--

___
Python tracker 

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

[issue37846] declare that Text I/O use buffer inside

[Windson Yang]

New submission from Windson Yang :

At the beginning of https://docs.python.org/3.7/library/io.html#io.RawIOBase, 
we declared that 

> Binary I/O (also called buffered I/O)
and 
> Raw I/O (also called unbuffered I/O)

But we didn't mention if Text I/O use buffer or not which led to confusion. 
Even though we talked about it later in 
https://docs.python.org/3.7/library/io.html#class-hierarchy

> The TextIOBase ABC, another subclass of IOBase, deals with streams whose 
> bytes represent text, and handles encoding and decoding to and from strings. 
> TextIOWrapper, which extends it, is a buffered text interface to a buffered 
> raw stream (BufferedIOBase). Finally, StringIO is an in-memory stream for 
> text.

IMO, it will be better to declare 'Reads and writes are internally buffered in 
order to speed things up' at the very beginning in 

> Text I/O
> Text I/O expects and produces str objects...

or maybe

> class io.TextIOBase
> Base class for text streams. This class provides a character and line based 
> interface to stream I/O. It inherits IOBase. There is no public constructor.

--
assignee: docs@python
components: Documentation
messages: 349633
nosy: Windson Yang, docs@python
priority: normal
severity: normal
status: open
title: declare that Text I/O use buffer inside
type: enhancement
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

[issue37757] TargetScopeError not raised for comprehension scope conflict

[Nick Coghlan]

Nick Coghlan  added the comment:

The outcome of the python-dev discussion was that we agreed to switch to 
raising a plain SyntaxError, as that's what we do everywhere else that this 
kind of problem comes up (e.g. conflicts between global and nonlocal 
declarations, or between those and parameter declarations, as well as the 
various other cases of "that statement/expression is fine in isolation, but you 
can't use it *here*").

Both PRs have been updated accordingly, and the PEP PR has been merged.

--

___
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 c03e698c344dfc557555b6b07a3ee2702e45f6ee by Benjamin Peterson 
(Greg Price) in branch 'master':
bpo-37760: Factor out standard range-expanding logic in makeunicodedata. 
(GH-15248)
https://github.com/python/cpython/commit/c03e698c344dfc557555b6b07a3ee2702e45f6ee


--

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

>From my perspective, the main problem with using type annotations is that 
>there's nothing checking them in CI.

--

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

The goal is to implement the locale-specific case mappings of 
https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and §3.13 of 
the Unicode 12 standard in str.lower/upper/casefold. To do this, you need 
access to certain character properties available in unicodedata but not the 
builtin database.

--

___
Python tracker 

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

[issue37831] bool(~True) == True

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Essentially we've got two competing desires:

* Given that & | and ^ are closed under bools,
  it would be nice for ~ to be closed as well.
  NOT isn't a reasonable alternative because
  of its operator precedence.

* Given that bool is a subclass of int,
  its operations should give results equivalent
  to what you would get for ints.

When reopening this, my thought was that the
first desire should win based on practicality-
beats-purity.  In the context of bools, the
current ~ operator violates user expectations
and there isn't a reasonable alternative that
has the correct precedence.

But in the face of opposition to the idea,
am willing to just let it die.  In the scheme
of things, it isn't important.

--

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

[Senthil Kumaran]

Senthil Kumaran  added the comment:


New changeset 38c7199beb30ae9a5005c0f0d9df9fae0da3680a by Senthil Kumaran 
(Ngalim Siregar) in branch 'master':
bpo-37256: Wording in Request class docs (#14792)
https://github.com/python/cpython/commit/38c7199beb30ae9a5005c0f0d9df9fae0da3680a


--

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

Change by Ashwin Ramaswami :


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

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

> I'm wary of trying to return it without the prefix.

Me too, but suddenly adding "\\?\" to the paths breaks a lot of assumptions.

> We would need a function that's shared with the proposed implementation of 
> realpath() to determine whether the given path (not the final path) is safe 
> to return as a normal DOS or UNC path.

My idea was to GetFinalPathName(path[4:])[4:] and if that fails, don't strip 
the prefix. Which is obviously not be perfect, but since we're not going to add 
a check for the LongPathsEnabled flag (let alone any of the other edge cases), 
we can't easily figure out whether it's safe to return manually.

I really want a fix for this in 3.8, or else os.stat(sys.executable) may fail, 
but I don't think changing the result of readlink() is okay at this stage. 
Maybe I'll leave that out for now and just take the st_reparse_tag and stat() 
changes?

--

___
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

[Bennet Fauber]

Bennet Fauber  added the comment:

Perhaps I should add, that we are able to reproduce this behavior on this 
hardware

Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
Dell R740 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
Dell R440 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz
Dell C6420 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz

but not on other chips, such as a recent i5, Haswell family, and older.  That 
may also make a difference if someone tries to reproduce this.

--

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[Srinivas Nyayapati]

Srinivas Nyayapati  added the comment:

Thank you Steve for accepting my pull requests. 

I was surprised to see the methods in the class and its decorators getting 
evaluated and causing the failures initially, but I then realized that the code 
is parsed before execution and that's when I was seeing the failure.

--

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[miss-islington]

miss-islington  added the comment:


New changeset e7ec9e04c82be72aef621fdfba03f41cbd8599aa by Miss Islington (bot) 
in branch '3.8':
bpo-25172: Add test for crypt ImportError on Windows (GH-15252)
https://github.com/python/cpython/commit/e7ec9e04c82be72aef621fdfba03f41cbd8599aa


--

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

> Until then, I think it makes sense for os.readlink() to handle the 
> prefix and _getfinalpathname() call, but leave nt.readlink() as
> returning the raw value.

os.readlink() shouldn't resolve the final path or realpath(). It should simply 
return the link substitute path, which starts with "?\\". I'm wary of 
trying to return it without the prefix. We would need a function that's shared 
with the proposed implementation of realpath() to determine whether the given 
path (not the final path) is safe to return as a normal DOS or UNC path.

---

BTW, I looked into how CreateFileW is supporting "\\??\\". It turns out at some 
point they changed RtlpDosPathNameToRelativeNtPathName to look for both 
"?\\" and "\\??\\" when determining whether to skip normalizing the path. I 
think that's a bad idea since the Windows API doesn't consistently support the 
NT prefix.

ReactOS is supposed to target NT 5.2 (Server 2003), and it doesn't allow the NT 
prefix here. Refer to its implementation of 
RtlpDosPathNameToRelativeNtPathName_Ustr [1]. It only looks for 
RtlpWin32NtRootSlash ("?\\"), not RtlpDosDevicesPrefix ("\\??\\"). So I 
suppose Windows changed this some time between Vista and Windows 10.

[1] 
https://github.com/reactos/reactos/blob/d93e516747e3220ba182f77824e8b1a8b548edae/sdk/lib/rtl/path.c#L1034

--

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[Steve Dower]

Steve Dower  added the comment:

Thanks for the patches, Srinivas!

--
resolution:  -> fixed
stage: patch review -> 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

[issue25172] Unix-only crypt should not be present on Windows.

[miss-islington]

miss-islington  added the comment:


New changeset 7f7f74734acd729d1f82b7cf672e064c9525fced by Miss Islington (bot) 
in branch '3.8':
bpo-25172: Raise appropriate ImportError msg when crypt module used on Windows 
(GH-15149)
https://github.com/python/cpython/commit/7f7f74734acd729d1f82b7cf672e064c9525fced


--
nosy: +miss-islington

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[miss-islington]

Change by miss-islington :


--
pull_requests: +14982
pull_request: https://github.com/python/cpython/pull/15263

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[Steve Dower]

Steve Dower  added the comment:


New changeset 243a73deee4ac61fe06602b7ed56b6df01e19f27 by Steve Dower 
(shireenrao) in branch 'master':
bpo-25172: Add test for crypt ImportError on Windows (GH-15252)
https://github.com/python/cpython/commit/243a73deee4ac61fe06602b7ed56b6df01e19f27


--

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

I think we'll want issue9949 merged as well, so that ntpath.realpath() does its 
job. Certainly the tests would benefit from it.

Until then, I think it makes sense for os.readlink() to handle the prefix and 
_getfinalpathname() call, but leave nt.readlink() as returning the raw value.

--

___
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

[Armin Rigo]

Change by Armin Rigo :


--
nosy:  -arigo

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

> Replacing "\??\" with "\\?\" in place is trivial though, as we start 
> with a mutable buffer. I'm just not clear that it's as simple as that, 
> though.

If the path starts with "\\??\\" we can just change the first question mark to 
a backslash. For a symlink, fail at this step if Flags includes 
SYMLINK_FLAG_RELATIVE, which would be inconsistent data. 

"\\??\\" is the NT prefix for the caller's local (logon session) device 
directory. This implicitly shadows the global device directory, "\\Global??". 
We don't use NT's real "\\Device" directory in Windows, but it's available as 
"//?/GlobalRoot/Device" or "//?/Global/GlobalRoot/Device". 

"\\??\\" shouldn't be used directly in Windows programming, since 
GetFullPathNameW (often implicitly called) doesn't recognize it, but some API 
functions will pass it along, even though they should really fail the call. It 
will work until it doesn't, and by then we could have a right mess.

If a path starts with exactly "?\\" (backslash only), Windows simply copies 
it verbatim, except for changing the prefix to "\\??\\". Other Windows device 
prefixes where the domain is "." or "?" can use any mix of forward slash and 
backslash because they get normalized first (e.g. "//?\\" -> "?\\"). Only 
an initial "?\\" bypasses the normalization step.

--

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

Speaking of improving functionality:

> Having unicodedata readily accessible to the str type would also permit 
> higher a fidelity unicode implementation. For example, implementing 
> language-tailored str.lower() requires having canonical combining class of a 
> character available. This data lives only in unicodedata currently.

Benjamin, can you say more about the behavior you have in mind here? I don't 
entirely follow. (Is or should there be an issue for it?)

--
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[Srinivas Nyayapati]

Srinivas Nyayapati  added the comment:

Thank you @paul.moore

--

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

> Loading it dynamically reduces the memory footprint.

Ah, this is a good question to ask!

First, FWIW on my Debian buster desktop I get a smaller figure for `import 
unicodedata`: only 64 kiB.

$ 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
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:  9888 kB

>>> import unicodedata
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:  9952 kB

But whether 64 kiB or 160 kiB, it's much smaller than the 1.1 MiB of the whole 
module.  Which makes sense -- there's no need to bring the whole thing in 
memory when we only import it, or generally to bring into memory the parts we 
aren't using.  I wouldn't expect that to change materially if the tables and 
algorithms were built in.

Here's another experiment: suppose we load everything that ast.c needs in order 
to handle non-ASCII identifiers.

$ 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
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:  9800 kB

>>> là = 3
>>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
VmRSS:  9864 kB

So that also comes to 64 kiB.

We wouldn't want to add 64 kiB to our memory use for no reason; but I think 64 
or 160 kiB is well within the range that's an acceptable cost if it gets us a 
significant simplification or improvement to core functionality, like Unicode.

--

___
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

[Greg Price]

Greg Price  added the comment:

> This is good. But the title mentioned dataclasses, and they are 3.7+.

Ahh, sorry, I think now I understand you. :-)

Indeed, when I switch to the branch with that change 
(https://github.com/gnprice/cpython/commit/2b4aec4dd -- it comes after the 
patch that's GH-15248, so I haven't yet sent it as a PR), then `python3.6 
Tools/unicode/makeunicodedata.py` no longer works.

I think this is fine. Most of all that's because this always works:

./python Tools/unicode/makeunicodedata.py

Anyone who's going to be running that script will want to build a `./python` 
right afterward, in order to at least run the tests. So it doesn't seem like 
much trouble to do the build first and then run the script (and then a quick 
rebuild for the handful of changed files), if indeed the person doesn't already 
have a `./python` lying around.

In fact `./python` is exactly what I used most of the time to run this script 
when I was developing these changes, simply because it seemed like the natural 
thing to do.

--

___
Python tracker 

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

[issue37689] Add Path.is_relative_to()

[Antoine Pitrou]

Change by Antoine Pitrou :


--
resolution:  -> fixed
stage: patch review -> 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

[issue37689] Add Path.is_relative_to()

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 82642a052dc46b2180679518bc8d87e1a28a88b5 by Antoine Pitrou (Hai 
Shi) in branch 'master':
bpo-37689: add Path.is_relative_to() method (GH-14982)
https://github.com/python/cpython/commit/82642a052dc46b2180679518bc8d87e1a28a88b5


--

___
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 feel like that's more work than is worth us doing for something that 
> will be relatively rarely used, will live in the stdlib, and is 
> obviously something that will become outdated as Microsoft adds new 
> reparse points.

Junctions (NT 5) and symlinks (NT 6) are stable. So if os.read_reparse_point 
only returns the unparsed bytes, maybe add os.read_junction as well. I know 
other projects overload this on POSIX readlink. They're both name-surrogate 
reparse points, but they have different constraints and behavior.

The I/O manager tries to make a junction behave something like a hard link to a 
directory, with the addition of being able to link across local volumes. This 
is in turn relates to how it evaluates relative symbolic links. For example, if 
"C:/Junction" and "C:/Symlink" both target r"\\?\C:\Temp1\Temp2", and there's a 
relative symlink "C:/Temp1/Temp2/foo_link" that targets r"..\foo", then 
"C:/Junction/foo_link" references "C:/foo" but "C:/Symlink/foo_link" references 
"C:/Temp1/foo".
 
Another difference is with remote filesystems. SMB special cases symlinks to 
have the server send the reparse request over the wire to be evaluated on the 
client side. (Refer to [MS-SMB2] 2.2.2.1 Symbolic Link Error Response, and the 
subsequent section about client-side handling of this error.) So an absolute 
symlink on the server that targets r"\\?\C:\Windows" actually references the 
client's "C:/Windows" directory, whereas the same junction target would 
reference the server's "C:/Windows" directory. The symlink evaluation will 
succeed only if the client's R2L (remote to local) policy allows it. Symlinks 
can also target remote devices, depending on the L2R and R2R policy settings. 
Junctions are restricted to local devices.

> In theory, we can't follow any reparse point that isn't documented as 
> being followable and provides the target name is a stable, documented
> manner. 

To follow a reparse point, we're just calling CreateFileW the normal way, 
without FILE_FLAG_OPEN_REPARSE_POINT. The Windows API also does this (usually 
via NtOpenFile, but this has a similar  FILE_OPEN_REPARSE_POINT option) for 
tags it doesn't handle. That's why MoveFileExW (os.rename and os.replace) fails 
on one of these app-exec links. In some cases, it adds a third open attempt if 
the reparse point isn't handled. This is important for DeleteFileW (os.remove) 
and RemoveDirectoryW (os.rmdir) because we should be able to delete a bad 
reparse point.

> The appexec links don't do this (I just looked at the returned 
> buffer), so we really should just not follow them. They exist solely 
> so that CreateProcess internally returns a unique error code that can 
> be handled without impacting regular process start, which means we 
> *don't* want to follow them.

I know, so a regular stat() will fail. I think for an honest result, stat() 
should fail for a reparse point that can't be handled. Scripts can use 
stat(path, follow_nonlinks=False) or stat(path, follow_reparse_points=False), 
or however this eventually gets parameterized to force opening all reparse 
points.

> Now, directory junctions are far more interesting. My gut feel is that 
> we should treat them the same as symlinks (with respect to stat vs. 
> lstat) for consistency

Junctions are their own thing. They're mount points that behave like Unix 
volume mounts (in Windows, target the root directory of a volume device named 
by its "Volume{...}" name) or Unix bind mounts (in Windows, target arbitrary 
directories on any local volume; in Linux it's a mount created with --bind or 
FUSE bindfs). Bind-like junctions are also similar to DOS subst drives (e.g. 
"W:" -> "C:/Windows") and UNC shares. These are all mount points of one sort or 
another. 

OTOH, the base device names such as "//?/C:" and "//?/Volume{...}", without a 
specified root directory, are aliases (object symlinks) for an NT device such 
as r"\Device\HarddiskVolume2". These paths open the volume itself, not the 
mounted filesystem, so they're not like Unix mount points. They're like Unix 
'/dev/sda1' device paths, except in Unix, devices don't have their own 
namespaces, so it would be nonsense to open "/dev/sda1/".

RemoveDirectoryW for a volume mount is special cased to call 
DeleteVolumeMountPointW, which notifies the mount-point manager. It won't do 
this for a junction that targets the same volume root directory via the DOS 
drive-letter name -- or any other device alias for that matter (e.g. Windows 10 
creates "\\?\BootPartition" as an alternative named for the system "C:" drive). 
So bind-like mounts are different from volume mounts, but both are different 
from symlinks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 

[issue37814] typing module: empty tuple syntax is undocumented

[miss-islington]

miss-islington  added the comment:


New changeset 37fd9f73e2fa439554977cfba427bf94c1fedb6b by Miss Islington (bot) 
(Josh Holland) in branch '3.7':
[3.7] bpo-37814: Document the empty tuple type annotation syntax (GH-15208) 
(GH-15262)
https://github.com/python/cpython/commit/37fd9f73e2fa439554977cfba427bf94c1fedb6b


--

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

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

[issue37814] typing module: empty tuple syntax is undocumented

[Josh Holland]

Change by Josh Holland :


--
pull_requests: +14981
pull_request: https://github.com/python/cpython/pull/15262

___
Python tracker 

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

[issue37814] typing module: empty tuple syntax is undocumented

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks Josh! The automated backport to 3.7 didn't work, that's okay, so I'll 
close this now. (Though if you want to experiment with the cherry-picker tool 
go ahead.)

--
resolution:  -> fixed
stage: patch review -> 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

[issue35669] tar symlink

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

I believe the SafeTarFile class proposed in issue21109 fixes this.

--
nosy: +epicfaace

___
Python tracker 

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

[issue37814] typing module: empty tuple syntax is undocumented

[miss-islington]

miss-islington  added the comment:


New changeset 6ad902a08814909b4d52c4000d5a10ce58516dac by Miss Islington (bot) 
in branch '3.8':
bpo-37814: Document the empty tuple type annotation syntax (GH-15208)
https://github.com/python/cpython/commit/6ad902a08814909b4d52c4000d5a10ce58516dac


--

___
Python tracker 

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

[issue37814] typing module: empty tuple syntax is undocumented

[miss-islington]

Change by miss-islington :


--
pull_requests: +14980
pull_request: https://github.com/python/cpython/pull/15261

___
Python tracker 

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

[issue37814] typing module: empty tuple syntax is undocumented

[miss-islington]

miss-islington  added the comment:


New changeset 8a784af750fa82c8355903309e5089eb2b60c16b by Miss Islington (bot) 
(Josh Holland) in branch 'master':
bpo-37814: Document the empty tuple type annotation syntax (GH-15208)
https://github.com/python/cpython/commit/8a784af750fa82c8355903309e5089eb2b60c16b


--
nosy: +miss-islington

___
Python tracker 

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

[issue37830] continue and break in finally with return in try results with segfault

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There may be a solution that does not require a significant change to the code 
generator, but small changes in many places with keeping the general structure. 
But it is a difficult task, so it takes some time. Don't worry, I'm working on 
it.

--

___
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

[Bennet Fauber]

Bennet Fauber  added the comment:

One additional note on this.  Thanks to a colleague at USC who pointed out that 
this bug does not seem to get exercised if one does not include 
`--enable-shared` at configuration.

I confirmed this using the distributed Python-3.7.4.tgz file and `configure 
--prefix=/path/to/install`.  The `make test` then runs to completion with no 
errors.  Running `make distclean`, then rerunning with `configure 
--prefix=/path/to/install --enable-shared` will then exercise the bug, and the 
faulthandler test fails with a segfault.

Applying the patch file attached to this report and rebuilding leads to `make 
test` passing all tests, also.

If someone was trying to reproduce and did not configure shared libraries, then 
that would have failed to reproduce.

--
nosy: +justbennet

___
Python tracker 

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[David K.]

Change by David K. :


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

___
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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I just checked and `python3.6 Tools/unicode/makeunicodedata.py` works fine, 
> both at master and with GH-15248.

This is good. But the title mentioned dataclasses, and they are 3.7+.

--

___
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

[Greg Price]

Greg Price  added the comment:

> What is the minimal Python version for developing CPython? The system Python 
> 3 on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger.

Ah, I think my previous message had an ambiguous parse: the earliest that 
*uses* of the typing module appeared in the stdlib was 3.7. The typing module 
has been around longer than that.

I just checked and `python3.6 Tools/unicode/makeunicodedata.py` works fine, 
both at master and with GH-15248.

I think it would be OK for doing development on CPython to require the latest 
minor version (i.e. 3.7) -- after all, if you're doing development, you're 
already building it, so you can always get a newer version than your system 
provides if needed.  But happily the question is moot here, so I guess the 
place to discuss that further would be a new thread.

--

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

Latest PR update uses GetFinalPathName to resolve SubstituteName, returning it 
unmodified on failure (e.g. symlink where the target file no longer exists).

Replacing "\??\" with "\\?\" in place is trivial though, as we start with a 
mutable buffer. I'm just not clear that it's as simple as that, though.

--

___
Python tracker 

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[David K.]

New submission from David K. :

Unable to establish SSL connections using company's private certificates where 
their SANs (Subject Alternative Names) contain at least one DNS Name that 
starts with white spaces.

Attempting to establish SSL connection would result in Exception:
SSLCertVerificationError("partial wildcards in leftmost label are not 
supported: '   *.x.y.com'.")

This situation made us co-depended on SecOps in a big company where ultimately 
all other none-python apps weren't effected by that change they made and thus 
couldn't or wouldn't fix the problem on their side for us. (We were at their 
mercy!)


I originally encountered this bug @ Python 3.7 and fixed it manually on my own 
local Python environment.

As the bug seems to be still unfixed to date, I publish this issue.

A small and simple fix will follow shortly on github.

--
assignee: christian.heimes
components: SSL
messages: 349600
nosy: DK26, christian.heimes
priority: normal
severity: normal
status: open
title: SLCertVerificationError: Unable to handle SAN names (from 
Certifications) published with white spaces at start
type: security
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

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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What is the minimal Python version for developing CPython? The system Python 3 
on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue37844] PyRun_SimpleFile should provide a version that does not need a FILE*

[Christian Biesinger]

New submission from Christian Biesinger :

Because FILE* requires that the runtime library matches between Python and a 
program using it, it is very hard to use this correctly on Windows. It would be 
nice if Python provided either:

- A function to open a FILE* given a filename, suitable for passing to the 
various PyRun_* functions, or
- Versions of the functions that take a filename and internally open the file

(ref: https://docs.python.org/3.9/c-api/veryhigh.html, which talks about this 
but provides no useful guidance:
"One particular issue which needs to be handled carefully is that the FILE 
structure for different C libraries can be different and incompatible. Under 
Windows (at least), it is possible for dynamically linked extensions to 
actually use different libraries, so care should be taken that FILE* parameters 
are only passed to these functions if it is certain that they were created by 
the same library that the Python runtime is using."
)

--
components: Windows
messages: 349598
nosy: cbiesinger, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PyRun_SimpleFile should provide a version that does not need a FILE*
type: crash
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

[issue37834] readlink on Windows cannot read app exec links

[Steve Dower]

Steve Dower  added the comment:

> If we support reading junctions, this should be using the substitute name 
> (with \??\ replaced by \\?\) instead of the print name.

GetFinalPathName() does this conversion for us, any reason not to use that? 
(GetFullPathName() doesn't seem to recognize the \??\ prefix and will prepend 
the current drive)

--

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[miss-islington]

miss-islington  added the comment:


New changeset ee989512528d178d6f088916aba3e67ea9487ceb by Miss Islington (bot) 
in branch '3.8':
bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-14729)
https://github.com/python/cpython/commit/ee989512528d178d6f088916aba3e67ea9487ceb


--
nosy: +miss-islington

___
Python tracker 

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

[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

[Guido van Rossum]

Guido van Rossum  added the comment:

PEP 8 intentionally allows users to choose whether to put the operator at the 
start or end of the line (as long as they're consistent within a file or 
project). This is to avoid a barrage of "style fixes" that are just noise.

But PEP 7 is only for CPython's own C code style, and here I don't want things 
to change. When it comes to readability of our code surely there are bigger 
fish to fry.

So I'm closing this as won't fix.

--
resolution:  -> wont fix
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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Netzeband]

Netzeband  added the comment:

Thanks for your feedback. I can create a pull-request. However, I did it never 
before for the Python-Lib, so I first have to setup the correct environment for 
that and ensure, that I can run all test-cases.

Since I'm on vacation soon, it could take several weeks. If someone wants to 
solve the issue earlier, please don't hesitate. 

I will write it in this issue ticket, as soon as I finished the PR.

--

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[hai shi]

Change by hai shi :


--
pull_requests: +14978
pull_request: https://github.com/python/cpython/pull/15259

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[miss-islington]

miss-islington  added the comment:


New changeset 853eecc7692503fec8240fd9a74d9f88e0392630 by Miss Islington (bot) 
in branch '3.8':
bpo-37841: Remove python_uwp dependency on msvcp140.dll (GH-15253)
https://github.com/python/cpython/commit/853eecc7692503fec8240fd9a74d9f88e0392630


--
nosy: +miss-islington

___
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

[Greg Price]

Greg Price  added the comment:

> BTW: Since when do we use type annotations in Python's stdlib ?

Hmm, interesting question!

At a quick grep, it's in a handful of places in the stdlib: asyncio, functools, 
importlib. The earliest it appeared was in 3.7.0a4.

It's in more places in the test suite, which I think is a closer parallel to 
this maintainer script in Tools/.

The typing module itself is in the stdlib, so I don't see any obstacle to using 
it more widely. I imagine the main reason it doesn't appear more widely already 
is simply that it's new, and most of the stdlib is quite stable.

--

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

> I looked into this spawn problem. It's due to Cygwin's spawnve, which calls 
> NtOpenFile to open the file, and then memory-maps it and reads the image 
> header [1].

Great, that's roughly what I suspected. Unfortunately, I've been told that 
looking into Cygwin's (GPL'd) code myself is going to cost me two weeks of dev 
work ("cooling off" period), so someone else will have to help them fix it.

> It could parse out as much as possible and return a struct sequence

TBH, I feel like that's more work than is worth us doing for something that 
will be relatively rarely used, will live in the stdlib, and is obviously 
something that will become outdated as Microsoft adds new reparse points.

If we return the parsed data as opaque bytes then someone can write a simple 
PyPI package to extract the contents. (Presumably the reparse tag will have 
come from stat() already.)

> Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks

I read this suggestion the first time and I think it would send the message 
that we are more capable than we really are :)

In theory, we can't follow any reparse point that isn't documented as being 
followable and provides the target name is a stable, documented manner. The 
appexec links don't do this (I just looked at the returned buffer), so we 
really should just not follow them. They exist solely so that CreateProcess 
internally returns a unique error code that can be handled without impacting 
regular process start, which means we *don't* want to follow them.

Again, if someone writes the PyPI package to parse all known reparse points, 
they can do that.

Now, directory junctions are far more interesting. My gut feel is that we 
should treat them the same as symlinks (with respect to stat vs. lstat) for 
consistency, but I'll gladly defer to you (Eryk) for the edge cases that may 
introduce.

---

My plan for PR 15231 is:
* make os.stat only follow symlinks and junctions
* make os.readlink only read symlinks and junctions
* add st_reparse_tag field to os.stat

--

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[miss-islington]

Change by miss-islington :


--
pull_requests: +14977
pull_request: https://github.com/python/cpython/pull/15258

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
stage: patch review -> resolved

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1ac2a83f30312976502fda042db5ce18d10ceec2 by Victor Stinner (Hai 
Shi) in branch 'master':
bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-14729)
https://github.com/python/cpython/commit/1ac2a83f30312976502fda042db5ce18d10ceec2


--

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[miss-islington]

Change by miss-islington :


--
pull_requests: +14976
pull_request: https://github.com/python/cpython/pull/15257

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[Steve Dower]

Steve Dower  added the comment:


New changeset b0dace3e979381426385c551b116d0f1434096ee by Steve Dower in branch 
'master':
bpo-37841: Remove python_uwp dependency on msvcp140.dll (GH-15253)
https://github.com/python/cpython/commit/b0dace3e979381426385c551b116d0f1434096ee


--

___
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

[Greg Price]

Greg Price  added the comment:

> I like to run pyflakes time to time on the Python code base. Please avoid 
> "import *" since it prevents pyflakes (and other code analyzers) to find bugs.

Ah fair enough, thanks!

Pushed that change to the next/current PR, GH-15248.

--

___
Python tracker 

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

[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PEP 8 contains contradictory examples.

https://www.python.org/dev/peps/pep-0008/#indentation

> # No extra indentation.
> if (this_is_one_thing and
> that_is_another_thing):
> do_something()
> 
> # Add a comment, which will provide some distinction in editors
> # supporting syntax highlighting.
> if (this_is_one_thing and
> that_is_another_thing):
> # Since both conditions are true, we can frobnicate.
> do_something()
> 
> # Add some extra indentation on the conditional continuation line.
> if (this_is_one_thing
> and that_is_another_thing):
> do_something()
> 
> (Also see the discussion of whether to break before or after binary
> operators below.)

(It was already reported in other issue.)

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I personally don't think we need to change this.  C and Python are different, 
and the PEP 7 rules have been in place for ages.

+Guido

--
nosy: +gvanrossum

___
Python tracker 

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

[issue37843] CGIHTTPRequestHandler does not take args.directory in constructor

[Richard Jayne]

New submission from Richard Jayne :

In Lib/http/server.py

if args.cgi:
handler_class = CGIHTTPRequestHandler
else:
handler_class = partial(SimpleHTTPRequestHandler,
directory=args.directory)

Notice that CGIHTTPRequestHandler does not accept directory=args.directory, and 
so the option does not work with the --cgi option.

--
components: Extension Modules
messages: 349585
nosy: rjayne
priority: normal
severity: normal
status: open
title: CGIHTTPRequestHandler does not take args.directory in constructor
type: enhancement
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

[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +barry

___
Python tracker 

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

[issue25299] TypeError: __init__() takes at least 4 arguments (4 given)

[paul j3]

paul j3  added the comment:

I'm not set up to work with the current development distribution (via github).  
All my proposed patches are diffs for earlier repos.

Paul

--

___
Python tracker 

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

[issue21109] tarfile: Traversal attack vulnerability

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

SafeTarFile does not pass the existing tests, mainly because the existing file 
Lib/test/tarfiletestdata/testtar.tar seems to be "unsafe", producing errors 
like these:

tarfile.SecurityError: : block device

tarfile.SecurityError: : duplicate 
name

It seems like the solution here is to remove block devices and duplicate names 
from testtar.tar. However, is this desirable -- do we need to keep these in for 
the tests for TarFile?

--
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue37842] Initialize Py_buffer variables more efficiently

[Sergey Fedoseev]

Change by Sergey Fedoseev :


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

___
Python tracker 

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

[issue37842] Initialize Py_buffer variables more efficiently

[Sergey Fedoseev]

New submission from Sergey Fedoseev :

Argument Clinic generates `{NULL, NULL}` initializer for Py_buffer variables. 
Such initializer zeroes all Py_buffer members, but as I understand only `obj` 
and `buf` members are really had to be initialized. Avoiding unneeded 
initialization provides tiny speed-up:

$ python -m perf timeit -s "replace = b''.replace" "replace(b'', b'')" 
--compare-to=../cpython-master/venv/bin/python --duplicate=1000
/home/sergey/tmp/cpython-master/venv/bin/python: . 43.0 ns 
+- 0.5 ns
/home/sergey/tmp/cpython-dev/venv/bin/python: . 41.8 ns +- 
0.4 ns

Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 43.0 ns +- 
0.5 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 41.8 ns +- 0.4 ns: 
1.03x faster (-3%)

--
components: Argument Clinic
messages: 349582
nosy: larry, sir-sigurd
priority: normal
severity: normal
status: open
title: Initialize Py_buffer variables more efficiently
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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Guido van Rossum]

Guido van Rossum  added the comment:

Maybe we should tag this issue "newcomer friendly"? It seems a pretty open
and shut case.

--

___
Python tracker 

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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Using `__wrapped__` if present sounds like a good idea.

Yeah, I like this idea, this will likely cover most use cases (since most 
people actually do use @wraps).

--

___
Python tracker 

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

[issue37830] continue and break in finally with return in try results with segfault

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Note, that we have a regression in 3.8. There is a use case for "break" in 
"finally", and such code is even used in the stdlib. And who know in what 
third-party code it is used. In specific circumstances (see msg349513) it now 
can cause a crash. Other example:

import contextlib
def simple():
with contextlib.nullcontext():
for number in range(2):
try:
return number
finally:
break

simple()

It just raise an exception in 3.8, not crash:

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 7, in simple
TypeError: 'range_iterator' object is not callable

--
stage: patch review -> 
title: continue in finally with return in try results with segfault -> continue 
and break in finally with return in try results with segfault

___
Python tracker 

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

[issue37830] continue in finally with return in try results with segfault

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Batuhan, unfortunately your second solution does not work too, because continue 
and break can be conditional. For example:

def simple(x):
for number in range(2):
try:
return number
finally:
if x:
continue

print(simple(0))
print(simple(1))

It should print:

0
None


Ethan, your understanding is correct.

--
keywords: +3.8regression -patch

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[Steve Dower]

Change by Steve Dower :


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

___
Python tracker 

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

[issue37841] Python store app launcher has dependency on msvcp140.dll

[Steve Dower]

New submission from Steve Dower :

A change made to the python_uwp.vcxproj (or more likely the .cpp file) has 
introduced a runtime dependency on msvcp140.dll.

As we don't distribute this dependency, and it is not always installed by 
default, we should statically link it instead.

--
assignee: steve.dower
components: Windows
messages: 349575
nosy: lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python store app launcher has dependency on msvcp140.dll
type: crash
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

[issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values

[STINNER Victor]

STINNER Victor  added the comment:

This issue has been fixed in Python 3.3 by bpo-17576 which started to emit the 
DeprecationWarning.

--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> PyNumber_Index() is not int-subclass friendly (or 
operator.index() docos lie)

___
Python tracker 

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

[issue37774] Micro-optimize vectorcall using PY_LIKELY

[STINNER Victor]

STINNER Victor  added the comment:

Few more links about likely/__builtin_expect:

* GCC documentation says: "In general, you should prefer to use actual profile 
feedback for this (-fprofile-arcs), as programmers are notoriously bad at 
predicting how their programs actually perform."

  https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

* 
https://softwareengineering.stackexchange.com/questions/188853/how-much-usage-of-likely-and-unlikely-macros-is-too-much

  "If you're writing for x86/x64 (and are not using 20-year-old CPUs), the 
performance gain from using __builtin_expect() will be negligible if any."

* http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html

  "This optimized version [PGO] runs significantly faster (...) than our 
version that used __builtin_expect()."

  [When __builtin_expect() is misused] "In this case, unsurprisingly, we made 
each check run slower (...)"

* 
https://stackoverflow.com/questions/109710/how-do-the-likely-unlikely-macros-in-the-linux-kernel-work-and-what-is-their-ben

  "Like all such performance optimisations you should only do it after 
extensive profiling to ensure the code really is in a bottleneck (...)"

* https://stackoverflow.com/questions/10922607/gcc-likely-unlikely-macro-usage

--

___
Python tracker 

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

[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD

[egaudry]

egaudry  added the comment:

Hi, I think that there are some issues in the last patch 
(0001-Build-or-disable-readline-module-with-Editline.patch) made available.

For instance, the using_libedit_emulation variable should be protected by 
DETECT_EDITLINE ifdef (and not SUPPORT_EDITLINE). And the setup.py file 
mentioned a 'readline_lib' string instead of the readline_lib variable.

I am interested by being able to build python without readline but libedit 
instead too.

--
nosy: +egaudry

___
Python tracker 

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

[issue36266] Which module could not be found?

[Srinivas Nyayapati]

Srinivas Nyayapati  added the comment:

can a reviewer please take a look to my PR?

--

___
Python tracker 

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

[issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR'

[Anthony Sottile]

Anthony Sottile  added the comment:

In case it helps someone else, `insstr` seems to not have this limitation

--
nosy: +Anthony Sottile

___
Python tracker 

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

[issue37774] Micro-optimize vectorcall using PY_LIKELY

[STINNER Victor]

STINNER Victor  added the comment:

> We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros 
> only affect which of the two code paths in a branch is the "default" one, 
> i.e. the one not involving a jmp.

I know. My point about prefetching is that if we provide a way to developers to 
tune the compiler, they will use it, but it can lead the a performance 
regression whereas not using these tools would lead to such issue.

> I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance 
> randomness of non-PGO builds. So it would be strange to use that randomness 
> as an argument *against* this patch.

It's right that Py_LIKELY/Py_UNLIKELY should make performance more reliable. My 
question is if it is safe to let developers "abuse" it. If these macros are 
misused, they can lead to a performance regression.

I'm not sure that Py_LIKELY/Py_UNLIKELY is always more performant than not 
using it. For example, if you mark the error path as unlikely: this path will 
become slower. If the error path is taken "frequently" enough, the slowdown can 
become significant overall.

It's tricky to decide if a code path is likely or not.

I would be ok to use Py_UNLIKELY for sanity checks which raise SystemError: 
these code paths must never be taken in a valid code. I'm more in favor of 
simply removing these runtime checks in release mode, but that's a different 
issue :-) (bpo-37406)

I'm not sure about judging if the error case raising an exception really 
deserve a Py_UNLIKELY.

Maybe I would be more comfortable if you would split the PR into multiple 
parts. One PR to add the macros. Then one PR per kind of modified tests.

For example, "if (Py_UNLIKELY(tstate->use_tracing))" in ceval.c sounds 
reasonable, but I would prefer to have the opinion of other core devs.

About the macros, I would prefer to make it private to not promote it. It 
should also have a good explanation why it's better to not use it, except if 
you really well understand what you do.

--

___
Python tracker 

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

[issue37830] continue in finally with return in try results with segfault

[Ethan Furman]

Ethan Furman  added the comment:

My apologies if I missed something, but do we have a consensus on the desired 
solution?

My understanding of `try/finally` is that whatever happens in the `finally` 
clause should:

- always happen
- win any conflicts with `try` clause

For example:

  try:
 a = 2
  finally:
 a = 3
  print(a)
  # 3

and

  def f():
 try:
return 5
 finally:
return 7
  print(f())
  # 7

So it seems like the ideal solution to:

  def mult(thing):
  print(thing*2)
  return thing * 2

  def simple():
  for number in range(2):
  try:
  return mult(number)
  finally:
  continue
  print(simple())

would be:

  0
  2
  None

--
nosy: +ethan.furman

___
Python tracker 

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

[issue25172] Unix-only crypt should not be present on Windows.

[Paul Moore]

Paul Moore  added the comment:

To clarify, I think adding the label needs core dev (or maybe triager) rights 
on github, so I don't think it's something you can do yourself.

--

___
Python tracker 

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