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

[Antti Haapala]

Antti Haapala  added the comment:

Well, there's only one problem with casting to void *: while converting the 
function pointer to another *is* standard-compliant, and GCC is being just 
hypersensitive here, casting a function pointer to void * isn't, though it is a 
common extension (http://port70.net/~nsz/c/c11/n1570.html#J.5.7).

Pedantically the correct way is to cast to a function pointer with no prototype 
(empty parentheses) and from that to the target type. See for example. See for 
example https://godbolt.org/g/FdPdUj

--

___
Python tracker 

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

[issue33610] IDLE: Make multiple improvements to CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

While trying out variable lines, #33642, I encounter two related issues.

First is the context colors.  Black on gray is a variant of black on white.  I 
am using the dark theme, white on dark blue.  For fixed sized context, the high 
contrast is okay.  For variable context, having lines flip from light on dark 
to dark on light and back is distracting to obnoxious. So I want to change
9. Reenable user config of context colors?
to 
9. Reenable user config of context colors!
Add the current black on gray to the light theme and appropriate values, to be 
determined, to the dark theme.

Second is getting partial lines at the top of the text box as a result of 
scrolling with the mousewheel or scrollbar slider.  I never liked this but 
tolerated it.  With complete text lines above, it looks awful to me.  Hence, I 
consider the following to be a dependency of this issue.  
17. #33664 Scroll by lines instead of sometimes by pixels.

Following the implementation notes for #33664, once the label is changes to 
text, to get the target topline, 8. can be implemented with
text.xview_scroll(target_topline - current_topline, 'units')

I would like to release multiple user visible improvements at once, at least 7, 
9, and 17, so the new code context looks good from the start.   8, menu 
changes, and 14 could come later.

--
dependencies: +IDLE:  scroll text by lines, not pixels.

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

After testing the patch as a user, I would like 3 user-visible changes.

1. Only display a blank line when there are no context lines.

2. Replace the 'lines' option with a 'maxlines' option.  There is no need to 
worry about, or explain to users (see 3.) the possible complications of reusing 
'lines' with a different meaning.

3. Add a 'maxlines' entry to the General tab help page.  I will work on this 
either first or second.

I will post other thoughts on the master issue, #33610.

--

___
Python tracker 

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

[issue25015] Idle: scroll Text faster with mouse wheel

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This is 'out of date' in the sense that I have decided that the root problem is 
scrolling by pixels instead of lines.  Once we do the latter, for #33664, we 
can just scroll by, say, 5 lines instead of 3, which I think is sufficient.

--
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed
superseder:  -> IDLE:  scroll text by lines, not pixels.

___
Python tracker 

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

[issue33664] IDLE: scroll text by lines, not pixels.

[Terry J. Reedy]

New submission from Terry J. Reedy :

When tk and hence, IDLE, opens a text window, it contains an integral number of 
lines of text in the base font.  Clicking a vertical scrollbar arrow button 
moves text up or down exactly one line.  Clicking in the trough between the 
buttons and and the slider moves text up or down one 'page', a page being the 
number of lines in the window -2.

The text and window can be de-synchronized with the slider and mouse wheel.  
(If the window size is changes to a non-integral number of lines, 
'synchronized' means a complete line at the top.)  By default, the wheel moves 
text about 3 lines per 'click'.  Apparently, it is exactly 50 pixels at a time. 
 This is discussed on #25015.  For that issue, the focus was on '3' (or 50) 
being too small. 

This issue is about changing 'about' to 'exactly', so that synchronized text 
remains so when using the wheel or slider.  For both, the solution should be to 
use Text.xview_scroll(n, units).

For the wheel, we can replace the default tk wheel handler.  While we are at 
it, we could make the wheel effect be +- 5 lines, which would solve #25015, 
which I will close.  I don't think a configuration setting is needed.

For the slider, we can replace xview as the scrollbar command with a function 
that maps command('moveto', fraction) to xview_scroll(n, 'units').  The number 
n should be the difference between the current top line
  ("text.index("@0,0").split('.')[0]")
and the desired top line
  ("round(fraction * text.index('end').split('.')[0]").
Experiments should show if we need to adjust the rounded value 

We should not need to adjust for the fact that the last  lines of 
text cannot become top lines.  A request to scroll 'too far' goes as far as 
possible without raising an exception.

--
assignee: terry.reedy
components: IDLE
messages: 317819
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE:  scroll text by lines, not pixels.
type: behavior
versions: Python 3.6, 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

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

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

According to 
https://stackoverflow.com/questions/1969709/how-to-forward-headers-on-http-redirect
 , there's nothing in the specs that mention (even the possibility) of any 
special request header processing.

According to https://tools.ietf.org/html/rfc7231#section-6.4 , redirection 
targets are to be treated as effectively equal to the original URL.

So, there aren't any grounds for the proposed filtering from web standards' POV.


Neither are there from security POV:
once you have given your credentials to a server, it is free to do whatever it 
wants with them. So, by giving them, you have effectively put down your 
signature that you trust the server with your data -- which implies trusting 
its advice where to resend it.
The server could as well do that resending itself and passed you the end 
result. So, your proposed filtering does not actually achieve anything 
meaningful.1

--
nosy: +Ivan.Pozdeev

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

Christian, I believe 
https://github.com/python/cpython/pull/7130/commits/bd17a5593f03e3f2d39a64f5afd3ffb77c97e914
 fixes the issue with OpenSSL 1.1.1 (socket.shutdown was missing and asyncio's 
protocol didn't receive EOF, instead the connection was terminated (as expected 
though))

--

___
Python tracker 

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[Yury Selivanov]

Yury Selivanov  added the comment:

> I should have known better that I wasn't going to find a bug in python :)

We have a lot of bugs, as any other software :)  Don't be afraid to open issues.

I'll close this bug, feel free to re-open.

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[skorpeo]

skorpeo  added the comment:

yes, in this case they were meant to stay open to write and read multiple
messages.  I was hoping to read data when it is available, the other work
around was to specify n, but that also blocked once there was no more data
to be fetchedEither way I will stick to queues and this appears to be
expected behavior so you can disregard the report.  I should have known
better that I wasn't going to find a bug in python :)

On Mon, May 28, 2018 at 2:03 AM, Yury Selivanov 
wrote:

>
> Yury Selivanov  added the comment:
>
> > You are also correct that there is no clean up for closing the pipes.
>
> It's not just about the cleanup. If you don't close the pipes, they will
> be open forever, so there will be no EOF for which read(-1) will wait
> forever.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[Yury Selivanov]

Yury Selivanov  added the comment:

> You are also correct that there is no clean up for closing the pipes.

It's not just about the cleanup. If you don't close the pipes, they will be 
open forever, so there will be no EOF for which read(-1) will wait forever.

--

___
Python tracker 

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[Jean-Marc Le Peuvedic]

New submission from Jean-Marc Le Peuvedic :

When running the built-in web server of web.py, the following error messages 
appear when the HTTP client fetches a non existing CSS file:

TypeError('WSGI response header value 469 is not of type str.',)
Traceback (most recent call last):
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
 line 1089, in communicate
req.respond()
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
 line 877, in respond
self.server.gateway(self).respond()
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
 line 1982, in respond
for chunk in response:
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/httpserver.py", 
line 267, in __iter__
self.start_response(self.status, self.headers)
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/httpserver.py", 
line 320, in xstart_response
out = start_response(status, response_headers, *args)
  File 
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
 line 2029, in start_response
"WSGI response header value %r is not of type str." % v)
TypeError: WSGI response header value 469 is not of type str.

The faulty header is added by Python library, http/server.py. 
Error added in version 3.4 according to comments.

Lines 467-471 in the attached file:
body = content.encode('UTF-8', 'replace')
self.send_header("Content-Type", self.error_content_type)
self.send_header('Content-Length', int(len(body)))
self.end_headers()

The value for 'Content-Length' is passed as an 'int', but only a 'str' is 
acceptable.

In the latest revision of 'server.py', the same code appears line 453.
A possible correction is :

body = content.encode('UTF-8', 'replace')
self.send_header("Content-Type", self.error_content_type)
self.send_header('Content-Length', str(int(len(body
self.end_headers()

--
components: Library (Lib)
files: server.py
messages: 317813
nosy: jmlp
priority: normal
severity: normal
status: open
title: Web.py wsgiserver3.py raises TypeError when CSS file is not found
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47616/server.py

___
Python tracker 

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[skorpeo]

skorpeo  added the comment:

Yes makes sense, it could be another bug with TTY or just my error and I
did preface that I am submitting this humbly.  You are also correct that
there is no clean up for closing the pipes.

On Mon, May 28, 2018 at 1:45 AM, Yury Selivanov 
wrote:

>
> Yury Selivanov  added the comment:
>
> "if not block:" means EOF and replacing it with "if len(block) <
> self._limit:" would break everything.
>
> There might be another bug here (with TTY) or, maybe, there's a bug in
> pty_test.py.  For example, I don't see how you closing reader_pipe or
> writer_pipe.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[Yury Selivanov]

Yury Selivanov  added the comment:

"if not block:" means EOF and replacing it with "if len(block) < self._limit:" 
would break everything.

There might be another bug here (with TTY) or, maybe, there's a bug in 
pty_test.py.  For example, I don't see how you closing reader_pipe or 
writer_pipe.

--

___
Python tracker 

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

[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit

[skorpeo]

New submission from skorpeo :

I humbly submit what I think may be a bug in the asyncio.StreamReader.read() 
function.  When n=-1 is supplied and the data is less than self._limit the read 
function creates a future and never wakes it up.  I believe the culprit is 
https://github.com/python/cpython/blob/9d3627e311211a1b4abcda29c36fe4afe2c46532/Lib/asyncio/streams.py#L632.
  To fix the issue a condition is added to break out of the loop if the data 
read is less than the limit.  I can only attach one file so I am providing the 
fix here for asyncio streams.py:  

blocks.append(block)   # existing
if len(block) < self._limit:   # new
break  # new

I have also attached a test file that shows the blocking behavior which is 
alleviated with the above fix.  Finally, I am not sure how to handle a 
situation where the data is exactly equal to the limit and no subsequent data 
is sent.

--
components: asyncio
files: pty_test.py
messages: 317810
nosy: asvetlov, skorpeo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio Stream Reader Blocks on read when data fetched is less than limit
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47615/pty_test.py

___
Python tracker 

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

[issue33601] [EASY DOC] Py_UTF8Mode is not documented

[Yuwei Ren]

Change by Yuwei Ren :


--
keywords: +patch
pull_requests: +6777
stage:  -> patch review

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Terry J. Reedy]

Terry J. Reedy  added the comment:

'deleted somehow': Christian added himself while I had this page open, so when 
I submitted without refreshing, the nosy list did not include him.  When I saw 
the red warning, I did not notice the nosy list change; I should have.

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Christian Heimes]

Christian Heimes  added the comment:

Linux

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

Terry, you somehow deleted Christian from the nosy list.

Christian,

> It's failing reproducible with OpenSSL 1.1.1 and TLS 1.3 enabled. I haven't 
> seen it failing with TLS 1.2 yet.

On Linux or Windows?

--
nosy: +christian.heimes

___
Python tracker 

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

[issue32832] doctest should support custom ps1/ps2 prompts

[Tim Peters]

Tim Peters  added the comment:

Sergey, I understand that, but I don't care.  The only people I've ever seen 
_use_ this are people writing an entirely different shell interface.  They're 
rare.  There's no value in complicating doctest to cater to theoretical use 
cases that don't exist - to the contrary, that's counterproductive complication.

As your IPython example showed, their job is harder than _just_ replacing 
PS1/PS2.  See their `parse()` function.  They want to cater both to IPython's 
PS1/PS2 conventions _and_ to the standard CPython terminal shell PS1/PS2 
conventions.

But they don't cater to _more_ than just those either.  Why should they?  Same 
thing here:  extra complication for no good reason.

--

___
Python tracker 

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

[issue32832] doctest should support custom ps1/ps2 prompts

[Sergey B Kirpichev]

Sergey B Kirpichev  added the comment:

> doctest was intended to deal with the standard CPython terminal shell.  I'd 
> like to keep it that way

The point is: ps1/ps2 customization could be considered as part of the standard 
shell.  If stdlib allow such changes - doctest module should take this into 
account.

--

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Unlinked duplicate PR entry.  I have no idea how that could happen.

--

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests:  -6745

___
Python tracker 

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

[issue32832] doctest should support custom ps1/ps2 prompts

[Tim Peters]

Tim Peters  added the comment:

doctest was intended to deal with the standard CPython terminal shell.  I'd 
like to keep it that way, but recognize that everyone wants to change 
everything into "a framework" ;-)

How many other shells are there?  As Sergey linked to, IPython already dealt 
with its shell conventions, and PS1/PS2 differences account for a relatively 
tiny amount of the 600+ lines of IPython-customization code they'd need anyway. 
 That is, I don't see that this would be of much value to IPython.

So people who "need" this already figured out how to do this - and there aren't 
many of them anyway.  I'd leave it alone.

--

___
Python tracker 

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

[issue33409] Clarify the interaction between locale coercion & UTF-8 mode

[Ned Deily]

Ned Deily  added the comment:

Nick, thanks for the notification.  I assume this means you are planning to 
provide one or more updates.  If so, any idea when?

--

___
Python tracker 

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

[issue32832] doctest should support custom ps1/ps2 prompts

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Tim, what do you say, feature or feature creep, straightforward patch or can of 
worms?

--
assignee:  -> tim.peters
nosy: +rhettinger, tim.peters
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

[issue33494] random.choices ought to check that cumulative weights are in ascending order

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> or, for a minimal doc change, change this sentence:
> "For example, the relative weights [10, 5, 30, 5] are 
> equivalent to the cumulative weights [10, 15, 45, 50],"
>
> to:
> "For example, the relative call 'weights[10, 5, 30, 5]' 
> is equivalent to the cumulative call 'cum_weights[10, 15, 45, 50]',"

Sorry, that doesn't seem like an improvement at all to me.  Adding "call" just 
makes the sentence read awkwardly.

Also, this week I did some user testing on the existing docs and didn't find a 
single case of misreading what "cumulative weights" meant.

I'm marking this as closed.  The suggestion was appreciated but adding 
additional input checks would defeat the entire purpose of the feature.  The 
user testing suggest that the docs are okay as-is (and there are additional 
examples in the recipes section below).

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

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Marking this a closed. It can be reopened if ActiveState makes an announcement 
that they're actually going to kill the existing links.  Otherwise, this is 
pure speculation and not an actual problem to be solved.

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

[issue18307] Relative path in co_filename for zipped modules

[Vitaly Murashev]

Vitaly Murashev  added the comment:

Pull-requests for 2.7, 3.7 and master submitted on github,
all tests look passed, so

Python dev-team,
please, take a look.

--

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Vitaly Murashev]

Change by Vitaly Murashev :


--
versions: +Python 2.7, Python 3.7, Python 3.8 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

@serhiy.storchaka Is the race condition/freed memory reusage in the test suite 
or in the posix module?

--
nosy: +pablogsal

___
Python tracker 

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

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

[Matthias Kievernagel]

Change by Matthias Kievernagel :


--
pull_requests: +6776

___
Python tracker 

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

[issue32832] doctest should support custom ps1/ps2 prompts

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +6775
stage:  -> patch review

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Vitaly Murashev]

Vitaly Murashev  added the comment:

> Vitaly, in the future please use gender-neutral words
Mariatta, OK, got it, I am sorry for that. I am not a native speaker.

--

___
Python tracker 

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

[issue33409] Clarify the interaction between locale coercion & UTF-8 mode

[Nick Coghlan]

Nick Coghlan  added the comment:

Ned, just adding you to the nosy list here, as I don't think this is a release 
blocker per se (since nothing's actually *broken*), but the current state of 
the PEP 538/540 docs is such that it isn't going to be clear to most readers 
why both mechanisms exist, or how they interact with each other.

--
nosy: +ned.deily

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +6774

___
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

[Xavier de Gaye]

Xavier de Gaye  added the comment:

> But the problem is that additional flags can be used, e.g. METH_CLASS.

Right, https://docs.python.org/3/c-api/structures.html says: "The individual 
flags indicate either a calling convention or a binding convention". This may 
be overcome by introducing another macro with 2 arguments, the second argument 
being used to set the binding convention flag:

#define SET_METH_VARARGS_KEYWORDS_FLAG(func, flag) \
(PyCFunction)(void *)(PyCFunctionWithKeywords)func, 
METH_VARARGS|METH_KEYWORDS|flag
#define SET_METH_VARARGS_KEYWORDS(func) SET_METH_VARARGS_KEYWORDS_FLAG(func, 
0x)

The refactoring would be quite large though.

--

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +6773

___
Python tracker 

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

[issue18307] Relative path in co_filename for zipped modules

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +6772
stage: test needed -> patch review

___
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

[Alex Gaynor]

Change by Alex Gaynor :


--
nosy: +orsenthil

___
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

[Artem Smotrakov]

New submission from Artem Smotrakov :

After discussing it on secur...@python.org, it was decided to disclose it. Here 
is the original report:




Hello Python Security Team,

Looks like urllib may leak sensitive HTTP headers to third parties when 
handling redirects.

Let's consider the following environment:
- http://httpleak.gypsyengineer.com/index.php asks a user to authenticate via 
basic HTTP authentication scheme
- http://httpleak.gypsyengineer.com/redirect.php?url= is an open redirect 
which returns 301 code, and redirects a client to the specified URL
- http://headers.gypsyengineer.com just prints out all HTTP headers which a web 
browser sent

Let's then consider the following scenario:
- create an instance of urllib.request.Request to open 
'http://httpleak.gypsyengineer.com/redirect.php?url=http://headers.gypsyengineer.com'
- call urllib.request.Request.add_header() method to set Authorization and 
Cookie headers
- call urllib.request.urlopen() method to open a connection

Here is what happens next:
- urllib sends the HTTP authentication header to httpleak.gypsyengineer.com as 
expected
- redirect.php returns 301 code which redirects to headers.gypsyengineer.com 
(note that httpleak.gypsyengineer.com and headers.gypsyengineer.com are 
different domains)
- urllib processes 301 code and makes a request to 
http://headers.gypsyengineer.com

The problem is that urllib sends the Authorization and Cookie headers headers 
to http://headers.gypsyengineer.com as well.

Let's imagine that a user is authenticated on a web site via one of HTTP 
authentication schemes (basic, digest, NTLM, SPNEGO/Kerberos), 
and the web site has an open redirect like 
http://httpleak.gypsyengineer.com/redirect.php
If an attacker can trick the user to open 
http://httpleak.gypsyengineer.com/redirect.php?url=http://attacker.com, 
then urllib is going to send sensitive headers to http://attacker.com where the 
attacker can gather them. 
As a result, the attacker can imporsonate the user on the original web site.

Here is a simple POC which shows the problem:

import urllib.request
req = 
urllib.request.Request('http://httpleak.gypsyengineer.com/redirect.php?url=http://headers.gypsyengineer.com')
req.add_header('Authorization', 'Basic YWRtaW46dGVzdA==')
req.add_header('Cookie', 'This is only for httpleak.gypsyengineer.com');
with urllib.request.urlopen(req) as f:
  print(f.read(2048).decode("utf-8"))


Running this code results to loading http://headers.gypsyengineer.com which 
prints out Authorization and Cookie headers 
which are supposed to be sent only to httpleak.gypsyengineer.com:

Hello, I am headers.gypsyengineer.com
Here are HTTP headers you just sent me:
Accept-Encoding: identity
User-Agent: Python-urllib/3.8
Authorization: Basic YWRtaW46dGVzdA==
Cookie: This is only for httpleak.gypsyengineer.com
Host: headers.gypsyengineer.com
Cache-Control: max-age=259200
Connection: keep-alive


I could reproduce it with 3.5.2, and latest build of 
https://github.com/python/cpython

If I am not missing something, it would be better if urllib filtered out 
sensitive HTTP headers while handling redirects.

Please let me know if I wrote anything dumb and stupid, or if you have any 
questions :) Thanks!

Artem

--
components: Library (Lib)
messages: 317793
nosy: alex, artem.smotrakov
priority: normal
severity: normal
status: open
title: urllib may leak sensitive HTTP headers to a third-party web site
type: security
versions: Python 3.5

___
Python tracker 

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

[issue33659] leak in pythonrun.c?

[lekma]

lekma  added the comment:

sorry, my mistake, I missed the format specifier in PyObject_CallFunction()

sorry for the noise

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

[issue33658] Introduce a method to concatenate regex patterns

[Thrlwiti]

Change by Thrlwiti :


--
nosy: +THRlWiTi

___
Python tracker 

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

[issue33635] OSError when using pathlib.Path.rglob() to list device files

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is fairly odd behaviour of macOS, the same error can be seen from a bash 
session:

$ stat /dev/fd/3
stat: /dev/fd/3: stat: Bad file descriptor

The reason os.walk() works while the Path().is_file doesn't is that os.walk() 
explicitly guards against OSError exceptions raised by os.stat(). 

Looking at the documentation this could be seen as a bug in macOS, as the 
manual page for stat(2) doesn't mention EBADF as a valid error for this system 
call.  

I'm not sure at this point if we should add a workaround for this. An actual 
patch would be easy enough, "just" add EBADF to the list of ignored errno 
values in the implementation of is_file (and related method) in pathlib.py

--

___
Python tracker 

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

[issue33660] pathlib.Path.resolve() returns path with double slash when resolving a relative path in root directory

[QbLearningPython]

New submission from QbLearningPython :

I have recently found a weird behaviour while trying to resolve a relative path 
located on the root directory on a macOs.

I tried to resolve a Path('spam') and the interpreter answered 
PosixPath('//spam') —double slash for root— instead of (my) expected 
PosixPath('/spam').

I think that this is a bug.

I ran the interpreter from root directory (cd /; python). Once running the 
interpreter, this is what I did:

>>> import pathlib
>>> pathlib.Path.cwd()
PosixPath('/')
# since the interpreter has been launched from root
>>> p = pathlib.Path('spam')
>>> p
PosixPath('spam')
# just for checking
>>> p.resolve()
PosixPath('//spam')
# beware of double slash instead of single slash


I also checked the behaviour of Path.resolve() in a non-root directory (in my 
case launching the interpreter from /Applications).

>>> import pathlib
>>> pathlib.Path.cwd()
PosixPath('/Applications')
>>> p = pathlib.Path('eggs')
>>> p
PosixPath('eggs')
>>> p.resolve()
PosixPath('/Applications/eggs')
# just one slash as root in this case (as should be)

So it seems that double slashes just appear while resolving relative paths in 
the root directory.

More examples are:

>>> pathlib.Path('spam/egg').resolve()
PosixPath('//spam/egg')
>>> pathlib.Path('./spam').resolve()
PosixPath('//spam')
>>> pathlib.Path('./spam/egg').resolve()
PosixPath('//spam/egg')

but

>>> pathlib.Path('').resolve()
PosixPath('/')
>>> pathlib.Path('.').resolve()
PosixPath('/')

Intriguingly,

>>> pathlib.Path('spam').resolve().resolve()
PosixPath('/spam')
# 'spam'.resolve = '//spam'
# '//spam'.resolve = '/spam'!!!
>>> pathlib.Path('//spam').resolve()
PosixPath('/spam')

I have found the same behaviour in several Python versions:

Python 3.6.5 (default, May 15 2018, 08:20:57)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin

Python 3.4.8 (default, Mar 29 2018, 16:18:25)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin

Python 3.5.5 (default, Mar 29 2018, 16:22:58)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin

Python 3.7.0b4 (default, May 4 2018, 22:01:49)
[Clang 9.1.0 (clang-902.0.39.1)] on darwin


All running on: macOs High Sierra 10.13.4 (17E202)


There is also confirmation of same issue on Ubuntu 16.04 (Python 3.5.2) and 
Opensuse tumbleweed (Python 3.6.5)


I have searched for some information on this issue but I did not found anything 
useful.

Python docs (https://docs.python.org/3/library/pathlib.html) talks about "UNC 
shares" but this is not the case (in using a macOs HFS+ filesystem).

PEP 428 (https://www.python.org/dev/peps/pep-0428/) says:


Multiple leading slashes are treated differently depending on the path 
flavour. They are always retained on Windows paths (because of the UNC 
notation):

>>> PureWindowsPath('//some/path')
PureWindowsPath('//some/path/')

On POSIX, they are collapsed except if there are exactly two leading 
slashes, which is a special case in the POSIX specification on pathname 
resolution [8] (this is also necessary for Cygwin compatibility):

>>> PurePosixPath('///some/path')
PurePosixPath('/some/path')
>>> PurePosixPath('//some/path')
PurePosixPath('//some/path')


I do not think that this is related to the aforementioned issue.

However, I also checked the POSIX specification link 
(http://pubs.opengroup.org/onlinepubs/009...#tag_04_11) and found:

A pathname that begins with two successive slashes may be interpreted in an 
implementation-defined manner, although more than two leading slashes shall be 
treated as a single slash.


I do not really think that this can cause a double slashes while resolving a 
relative path on macOs.


So, I think that this issue could be a real bug in pathlib.Path.resolve() 
method. Specifically on POSIX flavour.

A user of Python Forum (killerrex) and I have traced the bugs to 
Lib/pathlib.py:319 in the Python 3.6 repository 
https://github.com/python/cpython/blob/3...pathlib.py.

Specifically, in line 319:

newpath = path + sep + name

For pathlib.Path('spam').resolve() in the root directory, newpath is '//spam' 
since:

path is '/'
sep is '/'
name is 'spam'

killerrex has suggested two solutions:

1) from line 345 

base = '' if path.is_absolute() else os.getcwd()
if base == sep:
base = ''
return _resolve(base, str(path)) or sep

2) from line 319:

if path.endswith(sep):
newpath = path + name
else:
newpath = path + sep + name


Thank you.

--
components: Library (Lib)
messages: 317790
nosy: QbLearningPython
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve() returns path with double slash when resolving a 
relative path in root directory
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

[issue33659] leak in pythonrun.c?

[lekma]

New submission from lekma :

Am I wrong in thinking 'filename_obj' should be decrefed before the last two 
return statements in set_main_loader()? If yes, what am I missing?

--
components: Interpreter Core
messages: 317789
nosy: lekma
priority: normal
severity: normal
status: open
title: leak in pythonrun.c?
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue33658] Introduce a method to concatenate regex patterns

[Ales Kvapil]

New submission from Ales Kvapil :

After removing inline flags (deprecated in https://bugs.python.org/issue22493) 
piping patterns will not work:
pats = [r'(?m)^line.continues$', r'(?s)begin.*?end']
re.compile('|'.join(pats))


Maybe there should be introduced some method to merge patterns (similar to 
re.escape)?

--
components: Regular Expressions
messages: 317787
nosy: aleskva, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Introduce a method to concatenate regex patterns
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

[issue22493] Deprecate the use of flags not at the start of regular expression

[Ales Kvapil]

Ales Kvapil  added the comment:

See also https://bugs.python.org/issue33658

--

___
Python tracker 

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

[issue22493] Deprecate the use of flags not at the start of regular expression

[Ales Kvapil]

Ales Kvapil  added the comment:

Maybe there should be introduced some method to merge patterns as just piping 
patterns will not work:
pats = [r'(?m)^line.continues$', r'(?s)begin.*?end']
re.compile('|'.join(pats))

--
nosy: +aleskva

___
Python tracker 

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

[issue32911] Doc strings no longer stored in body of AST

[Benjamin Ragan-Kelley]

Benjamin Ragan-Kelley  added the comment:

That should work well for us. Our patches for this are all conditional on the 
module body being empty, so reverting causes us no issues at all.

Thank you!

--
nosy: +Benjamin Ragan-Kelley

___
Python tracker 

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

[issue32911] Doc strings no longer stored in body of AST

[Ned Deily]

Ned Deily  added the comment:

OK, since I believe everyone who has spoken up so far has chosen B or a 
variation on it, I think we can eliminate option A.  And there also seems to be 
a consensus so far among the core developers who have spoken up for the 
approach in PR 7121.  Before we commit to it and produce 3.7.0b5, I really 
would like to hear from at least one of the downsteamers that this approach 
seems OK for 3.7.0. mbussonn? MIN RK?

Thank you all for your (prompt) help so far with this!

--

___
Python tracker 

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

[issue32911] Doc strings no longer stored in body of AST

[INADA Naoki]

INADA Naoki  added the comment:

I'm +1 on PR-7121 too.

--

___
Python tracker 

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