[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> I'm not against that concept, but it is only appropriate for >= 3.9 as that'd 
> be adding a feature.  This issue is marked a release blocker to decide what 
> to do for 3.5-3.7 (and maybe 3.8 if deemed a serious breaking change).

The key part of the regression for 2.7 and 3.5+ was that it became impractical 
to retain the existing behavior of sending invalid bytes. My recommendation is 
to provide a mechanism to achieve compatibility with the older versions of 
Python. Although it's a "feature", it's also a feature necessitated by the 
security bugfix and to alleviate the regression. For this reason, I think the 
change should be applied to all Python versions that were patched for the 
security issue.

--

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[miss-islington]

Change by miss-islington :


--
pull_requests: +15897
pull_request: https://github.com/python/cpython/pull/16320

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Andrew Svetlov]

Andrew Svetlov  added the comment:

There is an alternative proposal: let's deprecate and eventually remove streams 
API entirely (for sockets, pipes, and subprocesses).
By this, we will never have a chance to conflict with trio.

Another option is removing asyncio at all (again to never conflict with trio 
and possible future awesome libraries) but the ship has sailed maybe.

--

___
Python tracker 

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

[issue37921] Improve zipfile: add support for symlinks

[Pierre-Jean Grenier]

Pierre-Jean Grenier  added the comment:

The PR went through review and has been awaiting core review for almost a 
month, anyone to have a look at it? :)

--

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 37bc93552375cb1bc616927b5c1905bae3c0e99d by Raymond Hettinger 
(Miss Islington (bot)) in branch '3.8':
bpo-38237: Let pow() support keyword arguments (GH-16302) (GH-16320)
https://github.com/python/cpython/commit/37bc93552375cb1bc616927b5c1905bae3c0e99d


--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Reversion is cheap.  Published APIs are hard to take back.

If the plan is to deprecate, then anything added for 3.8 should be reverted.  
There's no point in publishing a new API only to take it away.

--
nosy: +rhettinger

___
Python tracker 

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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +15898
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16321

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +15899
pull_request: https://github.com/python/cpython/pull/16321

___
Python tracker 

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

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)

[Jason R. Coombs]

Change by Jason R. Coombs :


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

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Nathaniel Smith]

Nathaniel Smith  added the comment:

That seems a bit extreme, and I don't think conflicts with Trio are the most 
important motivation here. (And they shouldn't be.) But, we should probably 
write down what the motivations actually are.

Yury might have a different perspective, but to me the challenge of the asyncio 
stream API is that it's trying to do three things at once:

1. Provide a generic interface for representing byte streams
2. Provide useful higher-level tools for working with byte streams, like 
readuntil and TLS
3. Adapt the protocol/transports world into the async/await world

These are all important things that should exist. The problem is that 
asyncio.Stream tries to do all three at once in a single class, which makes 
them tightly coupled.

*If* we're going to have a single class that does all those things, then I 
think the new asyncio.Stream code does that about as well as it can be done.

The alternative is to split up those responsibilities: solve (1) by defining 
some simple ABCs to represent a generic stream, that are optimized to be easy 
to implement for lots of different stream types, solve (2) by building 
higher-level tools that work against the ABC interface so they work on any 
stream implementation, and then once that's done it should be pretty easy to 
solve (3) by implementing the new ABC for protocol/transports.

By splitting things up this way, I think we can do a better job at solving all 
the problems with fewer compromises. For example, there are lots of third-party 
libraries that use asyncio and want to expose some kind of stream object, like 
HTTP libraries, SSH libraries, SOCKS libraries, etc., but the current design 
makes this difficult. Also, building streams on top of protocols/transports 
adds unnecessary runtime overhead.

A further bonus is that (1) and (2) aren't tied to any async library, so it's 
possible to borrow the work that Trio's been doing on them, and to potentially 
share this part of the code between Trio and asyncio.

So that all sounds pretty cool, but what does it have to do with shipping 
asyncio.Stream in 3.8? The concern is that right now asyncio has two APIs for 
working with byte streams (protocols/transports + StreamReader/StreamWriter); 
then 3.8 adds asyncio.Stream; and then the design I'm describing will make a 
*fourth*, which is a lot. I think we need something *like* asyncio.Stream in 
the mix, for compatibility and bridging between the two worlds, but right now 
it's not quite clear how that should look, and pushing it off to 3.9 would give 
us time to figure out the details for how these things can all fit together 
best.

--
nosy:  -rhettinger

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Andrew Svetlov]

Change by Andrew Svetlov :


--
nosy: +rhettinger

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> I think we need something *like* asyncio.Stream in the mix, for compatibility 
> and bridging between the two worlds, but right now it's not quite clear how 
> that should look, and pushing it off to 3.9 would give us time to figure out 
> the details for how these things can all fit together best.

Sorry, this was unclear. The "two worlds" I mean here are the current asyncio 
landscape and a future where we have standardized composable ABCs.

--
nosy:  -rhettinger

___
Python tracker 

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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've added PR 16321 illustrating my proposed solution. This solution, while 
more invasive than Tim's more surgical solution, addresses the concerns brought 
about by this issue as well as those articulated originally in issue36274.

I'm slightly inclined to suggest accepting this change for Python 3.8, and 
Tim's surgical patch for earlier versions except that doing so would not 
address the main concern of issue36274, which addresses a migration concern 
from Python 2.7 (a regression introduced in Python 3.0).

--
stage: patch review -> 

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Thomas Grainger]

Thomas Grainger  added the comment:

While it may not appear to be a permutation, python already considers it one:

graingert@onomastic:~$ cat test_assert_permutation.py 
import itertools
import unittest
from decimal import Decimal
from fractions import Fraction


class TestAssertPermutation(unittest.TestCase):
def assertPermutation(self, a, b):
return self.assertIn(tuple(a), itertools.permutations(b))

def test_do_not_look_like_permutations(self):
self.assertPermutation(
[Decimal(3), 5, Fraction(12, 4)], [3.0, 3, Fraction(15, 3)]
)


if __name__ == "__main__":
unittest.main()
graingert@onomastic:~$ python3 test_assert_permutation.py -v
test_do_not_look_like_permutations (__main__.TestAssertPermutation) ... ok

--
Ran 1 test in 0.000s

OK

--

___
Python tracker 

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

[issue35696] remove unnecessary operation in long_compare()

[hongweipeng]

Change by hongweipeng :


--
nosy: +hongweipeng

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Isn't it a new feature? Isn't it too later to add it to 3.8?

--
nosy: +lukasz.langa
status: closed -> open

___
Python tracker 

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

[issue38225] iscoroutinefunction broken with cython - allow tagging of functions as async?

[Stefan Behnel]

Stefan Behnel  added the comment:

> along with the appropriate CO_COROUTINE flag set

No, it never did that, for safety reasons. It's difficult to say if enabling 
these flags is the right thing to do, because it's unclear what assumptions 
code that tests for them would make. In CPython itself, there do not seem to be 
any "excessive" assumptions specific to that flag – also because Cython 
functions are not Python functions, and thus the flag will never be looked at:

https://github.com/python/cpython/blob/5b9ff7a0dcb16d6f5c3cd4f1f52e0ca6a4bde586/Lib/inspect.py#L178-L180

Thus, setting the CO_COROUTINE and CO_ASYNC_GENERATOR code flags has no effect 
for Cython functions.

--

___
Python tracker 

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

[issue38045] enum.Flag instance creation is slow

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue38166] ast identifies incorrect column for compound attribute lookups

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

As Serhiy explained, there is no bug here, _potentially_ we could change AST so 
that attribute name (i.e. "b" in "a.b") is wrapped in a special node holding 
the position info (similar to ``ast.arg``), but it is a breaking change and is 
not worth it. You can re-open your issue on PyLint tracker.

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

[issue38242] Revert the new asyncio Streams API

[Guido van Rossum]

Guido van Rossum  added the comment:

I am going to recommend sticking to the status quo, i.e. Andrew's improvements 
to asyncio.Stream should stay. The rest of this message is an elaboration.

The new perfect composable Streams design is just that -- a design. Many things 
could go wrong in the implementation. Once it exists as a 3rd party add-on and 
users agree it's better we *may* decide to deprecate asyncio.Stream. Or not -- 
there are many examples in the stdlib of modules for which a better 3rd party 
alternative exists but which are nevertheless useful and not deprecated.

Much of the asyncio universe already exists outside the stdlib -- the perfect 
composable Streams API should probably never be moved into the stdlib (unless 
it's so perfect that it never needs to change :-).

Andrew's improvements help current users of asyncio.Stream. If those users 
eventually want to migrate to the perfect composable Streams API, once it's 
available, fine. But I don't think we're helping them by not giving them 
improvements that have already been implemented (and which everyone here agrees 
are improvements!) right now.

Users of the current asyncio.Stream have a choice -- they can adopt the 
improvements in 3.8, or they can wait for the perfect design to be implemented. 
Everybody's constraints are different. Let's not pretend we already know what 
they should choose.

If in the future we end up changing our mind, that's okay. It's happened 
before, and we've lived.

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I would say that we can reimplement the Stream class on top of new composable 
streams in the future.
I'd love to do it right now but these streams don't exist yet.

I totally support the idea of new streams design, it looks very attractive. The 
implementation may take a while and require many labor-hours though. 

asyncio is driven by volunteers, mostly by Yuri and I. We constantly don't 
implement all our *wishes* at the time on next Python feature-freezing but only 
a subset of them.

Maybe the situation will change in the future but I have no strong confidence 
that we finish the design of the new streams in 3.9.

Task group is another very required thing. If I choose between groups and 
steams I probably invest my time into the former.

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Andrew Svetlov]

Change by Andrew Svetlov :


--
nosy: +rhettinger

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

As noted in the checkin, this was backported with the release manager's assent.

FWIW, pow() itself is an old feature, recently enhanced to support negative 
powers in a given modulus.  When the enhancement went in, we should have done 
this as well.

--
status: open -> closed
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

[issue38245] Why am I getting inconsistent results in this simple List assignment?

[Srinivasan Samuel]

New submission from Srinivasan Samuel :

Here is the my direct cut & paste from my Python 3.7.3 Shell
>>> C = 2*[[]]
>>> C
[[], []]
>>> 
>>> M = [[],[]]
>>> M
[[], []]
>>> 
>>> C == M
True
>>> 
>>> M[0].append(5)
>>> M
[[5], []]
>>> 
>>> C[0].append(5)
>>> C
[[5], [5]]
>>> 
>>> C == M
False
>>>

--
messages: 352945
nosy: pysolo
priority: normal
severity: normal
status: open
title: Why am I getting inconsistent results in this simple List assignment?
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

[issue38245] Why am I getting inconsistent results in this simple List assignment?

[Ammar Askar]

Ammar Askar  added the comment:

Check out this part of the FAQ: 
https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list

Essentially, when you did `C = 2*[[]]`, what happens is that the SAME empty 
list is placed into C[0] and C[1]. Whereas when you do `M = [[],[]]`, you're 
creating two different lists. You can confirm this using:

>>> C = 2*[[]]
>>> C[0] is C[1]
True
>>> M = [[],[]]
>>> M[0] is M[1]
False

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

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:

> Task group is another very required thing. If I choose between groups and 
> steams I probably invest my time into the former.

We should get them in 3.9.  I'm going to be working on the ExceptionGroup PEP 
today.

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Awesome!

--

___
Python tracker 

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

[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output

[Steve Dower]

Steve Dower  added the comment:

Shouldn't this test be suppressed on LTO builds?

#0  builtin_id (self=, v=) at 
Objects/longobject.c:1113

builtid_id isn't in longobject.c, so this is incorrect debug information. The 
test expects to find it in bltinmodule.c:

re.match(r'.*#0\s+builtin_id\s+\(self\=.*,\s+v=\s*(.*?)?\)\s+at\s+\S*Python/bltinmodule.c.*'
 ...

--
nosy: +steve.dower

___
Python tracker 

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

[issue38243] A reflected XSS in python/Lib/DocXMLRPCServer.py

[Ned Deily]

Change by Ned Deily :


--
keywords: +security_issue
priority: normal -> high
versions: +Python 2.7, Python 3.5, Python 3.6, 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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I like using 'multiset', but I think 'assertMultisetEqual', proposed by Martin 
Panter in msg266207, is better than assertMultiSetEqual, as it does not imply 
the existence of a class 'MultiSet'.

Raymond's comment "distinct but equal values may appear on both sides, so it 
isn't really a permutation" turns on the ambiguity of 'same element' in the 
assertCoultEqual definition.  The doc never says explicitly that it means same 
by equality ('==') regardless of class, rather than same by equality within a 
class, which one might assume for 'permutation of values', or same by identity 
('is'), which would be needed for 'permutation of objects'.  I think it should 
what same means here.

Gregory Smith msg266208 objects to a name containing 'set' because "this is 
most notably an api having nothing to do with sets".  However, the short 
definition of the assertion, "a and b have the same elements in the same 
number, regardless of their order" *is* a definition of multiset equality.  The 
assertion looks at both collections as multisets.

Unlike R. David Murray msg266153, I see a difference between 'count' and 
'counts'.  The former can only mean comparing one count for each collection, 
the number of items.  The latter could mean the same, but could also mean 
comparing multiple counts for each collection, as is the case.

RDM goes on to claim that 'count' is correct because the function's doc defines 
it in terms of itertools.count.  It actually defines it in terms of 
collections.Counter, which would suggest, using the same logic, 
'assertCounterEqual' or assertCountersEqual.  Since Counter implements the 
mathematical idea of 'multiset' and "is similar to bags or multisets in other 
languages", we get to 'assertMultisetEqual' as the less Python-specific name.

[I am puzzled about a couple of things.  The doc says "Equivalent to: 
assertEqual(Counter(list(first)), Counter(list(second)))
but works with sequences of unhashable objects as well."  That expression *is* 
the current implementation.

1. It seems that the 'list' call should be irrelevant.
2. Counter calls fail  with iterables of unhashable objects.  Why not the 
overall expression?]

--

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[miss-islington]

Change by miss-islington :


--
pull_requests: +15901
pull_request: https://github.com/python/cpython/pull/16323

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 24231ca75c721c8167a7394deb300727ccdcba51 by Raymond Hettinger 
(Miss Islington (bot)) in branch '3.8':
bpo-38237: Shorter docstring (GH-16322) (GH-16323)
https://github.com/python/cpython/commit/24231ca75c721c8167a7394deb300727ccdcba51


--

___
Python tracker 

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

[issue38237] Expose meaningful keyword arguments for pow()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for the explanation Raymond and sorry for the disturb. My mistake, I 
had not noticed the release manager's assent.

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> 1. It seems that the 'list' call should be irrelevant.

It is relevant. Counter({1: 2}) != Counter(list({1: 2})).

--

___
Python tracker 

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

[issue38246] pathlib.resolve and .absolute leave trailing tilde in home expansion

[Infrasonics]

New submission from Infrasonics :

`Path('~').resolve()` gives `PosixPath('/home/youruser/~')`.
Same problem for `.absolute`, yet `.expanduser` works correctly.

--
components: Library (Lib)
messages: 352954
nosy: Infrasonics
priority: normal
severity: normal
status: open
title: pathlib.resolve and .absolute leave trailing tilde in home expansion
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue38247] list(str.split(ch)) Does not print blank elements upon repeating character(ch)

[Aman Priyanshu]

New submission from Aman Priyanshu :

I have been annoyed by the fact that at multiple where we print 
list(str.split(ch)) we get empty elements in place of repeated characters (ch).

Example:


>>> print(list("Hello World How Are You?".split(" ")))
['Hello', 'World', 'How', 'Are', 'You?']
>>> print(list("Hello World   How Are  You?".split(" ")))
['Hello', 'World', '', '', '', '', '', '', 'How', 'Are', '', '', '', '', '', 
'You?']


So can it be fixed so that  it gives:


>>> print(list("Hello World How Are You?".split(" ")))
['Hello', 'World', 'How', 'Are', 'You?']
>>> print(list("Hello World   How Are  You?".split(" ")))
['Hello', 'World', 'How', 'Are', 'You?']


--
messages: 352955
nosy: AmanPriyanshu
priority: normal
pull_requests: 15902
severity: normal
status: open
title: list(str.split(ch))  Does not print blank elements upon repeating 
character(ch)
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

[issue15902] imp.load_module won't accept None for the file argument for a C extension

[Aman Priyanshu]

Change by Aman Priyanshu :


--
pull_requests: +15903
pull_request: https://github.com/python/cpython/pull/16324

___
Python tracker 

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

[issue38247] list(str.split(ch)) Does not print blank elements upon repeating character(ch)

[Aman Priyanshu]

Change by Aman Priyanshu :


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

[issue38247] list(str.split(ch)) Does not print blank elements upon repeating character(ch)

[Ammar Askar]

Ammar Askar  added the comment:

For whitespace, the correct way to achieve this using split() with no argument:

>>> print(list("Hello World How Are You?".split()))
['Hello', 'World', 'How', 'Are', 'You?']
>>> print(list("Hello World   How Are  You?".split()))
['Hello', 'World', 'How', 'Are', 'You?']

Your proposed solution would be a breaking change to all code that relies on 
the old style.

--
nosy: +ammar2

___
Python tracker 

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

[issue38246] pathlib.resolve and .absolute leave trailing tilde in home expansion

[Eryk Sun]

Eryk Sun  added the comment:

Only Path.expanduser() special cases tilde as a POSIX shell would. Otherwise 
"~" is not a reserved filename character in POSIX. Path('~') is a file named 
"~" that's relative to the current working directory. By coincidence the 
working directory is the user's home directory in your example.

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

[issue38241] Pickle with protocol=0 in python 3 does not produce a 'human-readable' format

[Nicholas Neumann]

Nicholas Neumann  added the comment:

Wow, that's a great catch with bytearray on py2. Protocols 0-2 are all actually 
supposed to work with python 2, and I was using 0 from Py3 as it's the default 
for Py2, and what I want to use during a short transition where both Py3 and 
Py2 are operating on my pickled data. I was surprised when Py3's protocol 0 
output was so different than Py2's protocol 0.

To be "human-readable", I think the protocol would have to be even stricter, 
omitting the non-printable ASCII characters.

I wonder if protocol 0 was initially ASCII (or even stricter), and then this 
went out the window or was unintentionally not adhered to when new things like 
bytearray (2.6) were introduced.

--

___
Python tracker 

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

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

[Vinay Sajip]

Vinay Sajip  added the comment:

> Obviously the fix could be just to stop doing that in the standard library

Well, that's the right fix, and thanks for spotting it. I've applied those 
changes (42b6c5d and 19c42fb) to the master, 3.8 and 3.7 branches.

--

___
Python tracker 

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

[issue36876] Global C variables are a problem.

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests: +15904
pull_request: https://github.com/python/cpython/pull/16328

___
Python tracker 

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

[issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception

[Michael Tippie]

Michael Tippie  added the comment:

I am getting this error now, too.  I'm not sure what's causing it - when I use 
multiprocessing with a Manager.Queue, if I am passing around an object on the 
queue stack, I get this error.

Would really like it to "just work".

--
nosy: +Locane

___
Python tracker 

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

[issue38245] Why am I getting inconsistent results in this simple List assignment?

[Srinivasan Samuel]

Srinivasan Samuel  added the comment:

Thanks Ammar for your time, service and reply. It was really helpful. I learned 
some thing more.God Bless you.Srinivasan Samuel
On Saturday, September 21, 2019, 10:50:32 PM GMT+5:30, Ammar Askar 
 wrote:  

Ammar Askar  added the comment:

Check out this part of the FAQ: 
https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list

Essentially, when you did `C = 2*[[]]`, what happens is that the SAME empty 
list is placed into C[0] and C[1]. Whereas when you do `M = [[],[]]`, you're 
creating two different lists. You can confirm this using:

>>> C = 2*[[]]
>>> C[0] is C[1]
True
>>> M = [[],[]]
>>> M[0] is M[1]
False

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

___
Python tracker 

___

--

___
Python tracker 

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

[issue35603] table header in output of difflib.HtmlDiff.make_table is not escaped and can be rendered as code in the browser

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Closing this as the docs are merged with the initial patch to escape header 
reverted. Thanks all for the reviews.

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

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

[Kyle Stanley]

Kyle Stanley  added the comment:

> Is there an "aesthetic code cleanup" patch that's ever turned out well? ;-)

>From what I can tell, any remotely extensive aesthetic code patch I've seen 
>has been highly controversial. I think they can have value in some cases, but 
>the value relative to the potential cost may have been a bit overstated in 
>this particular case.

--

___
Python tracker 

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