[issue433228] repr(list) woes when len(list) big

[admin]

Change by admin :


--
github: None -> 34631

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Ma Lin]

Ma Lin  added the comment:

`_Stream.write` method in tarfile.py also has this code:
https://github.com/python/cpython/blob/v3.11.0a6/Lib/tarfile.py#L434

But this bug will not be triggered. When calling this method, always pass bytes 
data.

`_ConnectionBase.send_bytes` method in multiprocessing\connection.py can be 
micro-optimized:
https://github.com/python/cpython/blob/v3.11.0a6/Lib/multiprocessing/connection.py#L193
This can be done in another issue.

So I think this issue can be closed.

--
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Irit Katriel]

Irit Katriel  added the comment:

Can this be closed now or is there anything else to do?

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[miss-islington]

miss-islington  added the comment:


New changeset 0663ca17f5535178c083c6734fa52e40bd2db2de by Miss Islington (bot) 
in branch '3.9':
bpo-44439: _ZipWriteFile.write() handle buffer protocol correctly (GH-29468)
https://github.com/python/cpython/commit/0663ca17f5535178c083c6734fa52e40bd2db2de


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[miss-islington]

miss-islington  added the comment:


New changeset 21c5b3f73fb11fb0d3239971f72e8f0574a07245 by Miss Islington (bot) 
in branch '3.10':
bpo-44439: _ZipWriteFile.write() handle buffer protocol correctly (GH-29468)
https://github.com/python/cpython/commit/21c5b3f73fb11fb0d3239971f72e8f0574a07245


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[miss-islington]

Change by miss-islington :


--
pull_requests: +29868
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/31755

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[miss-islington]

Change by miss-islington :


--
pull_requests: +29869
pull_request: https://github.com/python/cpython/pull/31756

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 36dd7396fcd26d8bf9919d536d05d7000becbe5b by Ma Lin in branch 
'main':
bpo-44439: _ZipWriteFile.write() handle buffer protocol correctly (GH-29468)
https://github.com/python/cpython/commit/36dd7396fcd26d8bf9919d536d05d7000becbe5b


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Ma Lin]

Ma Lin  added the comment:

Serhiy Storchaka:

Sorry, I found `zipfile` module also has this bug, fixed in PR29468.

This bug was reported & fixed by GitHub user `marcoffee` firstly, so I list him 
as a co-author, his work:
https://github.com/animalize/pyzstd/issues/4

The second commit fixes an omission of issue41735, a very simple fix, I fix it 
in PR29468 by the way.

--
resolution: fixed -> later
status: closed -> open

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Ma Lin]

Change by Ma Lin :


--
pull_requests: +27721
pull_request: https://github.com/python/cpython/pull/29468

___
Python tracker 

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

[issue22294] 2to3 consuming_calls: len, min, max, zip, map, reduce, filter, dict, xrange

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
superseder:  -> Close 2to3 issues and list them here

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 01858fbe31e8e0185edfbd3f10172f7c61391c9d by Miss Islington (bot) 
in branch '3.10':
bpo-44439: BZ2File.write() / LZMAFile.write() handle buffer protocol correctly 
(GH-26764) (GH-26845)
https://github.com/python/cpython/commit/01858fbe31e8e0185edfbd3f10172f7c61391c9d


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for your contribution Ma Lin.

--
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 8bc26d8c9d092840054f57f9b4620de0d40d8423 by Ma Lin in branch 
'3.9':
bpo-44439: BZ2File.write()/LZMAFile.write() handle length correctly (GH-26846)
https://github.com/python/cpython/commit/8bc26d8c9d092840054f57f9b4620de0d40d8423


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Ma Lin]

Change by Ma Lin :


--
pull_requests: +25427
pull_request: https://github.com/python/cpython/pull/26846

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Christian Heimes]

Change by Christian Heimes :


--
nosy:  -christian.heimes

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset bc6c12c72a9536acc96e7b9355fd69d1083a43c1 by Ma Lin in branch 
'main':
bpo-44439: BZ2File.write() / LZMAFile.write() handle buffer protocol correctly 
(GH-26764)
https://github.com/python/cpython/commit/bc6c12c72a9536acc96e7b9355fd69d1083a43c1


--

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +25426
pull_request: https://github.com/python/cpython/pull/26845

___
Python tracker 

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

[issue44439] stdlib wrongly uses len() for bytes-like object

[Ma Lin]

Ma Lin  added the comment:

I am checking all the .py files in `Lib` folder.
hmac.py has two len() bugs:
https://github.com/python/cpython/blob/v3.10.0b3/Lib/hmac.py#L212
https://github.com/python/cpython/blob/v3.10.0b3/Lib/hmac.py#L214

I think PR 26764 is prepared, it fixes the len() bugs in bz2.py/lzma.py files.

--
nosy: +christian.heimes
title: PickleBuffer doesn't have __len__ method -> stdlib wrongly uses len() 
for bytes-like object

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

[issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size

[Eryk Sun]

Change by Eryk Sun :


--
components: +ctypes

___
Python tracker 

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

[issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size

[Eryk Sun]

Eryk Sun  added the comment:

> The Documentation component is for issues that only change the docs

That's not clear in the triaging guide for the multi-select component field. 
(However, it is clearly stated as such for the GitHub PR label 
"type-documentation".) If that's really the case, then I'll manually nosy the 
docs team in cases such as this. When wording is disputed and needs to be 
clarified, I want an expert at documentation to propose or review the change.

> Adding 'Documentation' amounts to rejecting this patch or anything 
> else that changes the code.

That was not my intent. I accepted Tom's position that "string" means a C 
string, which must be null-terminated. So I added the "Lib" tag and left it as 
a "behavior" issue instead of changing it to "enhancement". 

I'm concerned that the old c_buffer() function is defined to call 
create_string_buffer(), and it's not officially deprecated in the docs or the 
source code. (There's a commented-out deprecation warning.) A related concern 
is that the documentation says that the length of a byte-string initializer 
should not be used if the size is specified, which allows creating a 
character-array that's not null-terminated. If it raises a ValueError in this 
case, the wording should be clear that the value of `size` must be large enough 
to set the initial value as a null-terminated string. I also would want 
c_buffer() to get a separate implementation in this case. 

If accepted, create_unicode_buffer(init, size) should also be changed to 
require that init is set as a null-terminated string.

--
components: +Library (Lib)
priority: low -> normal
stage: needs patch -> patch review
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

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

[issue26425] 'TypeError: object of type 'NoneType' has no len()' in 'splitdrive'

[Steve Dower]

Steve Dower  added the comment:

Distutils is now deprecated (see PEP 632) and all tagged issues are being 
closed. From now until removal, only release blocking issues will be considered 
for distutils.

If this issue does not relate to distutils, please remove the component and 
reopen it. If you believe it still requires a fix, most likely the issue should 
be re-reported at https://github.com/pypa/setuptools

--
resolution:  -> out of date
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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[Irit Katriel]

Irit Katriel  added the comment:

Can this be closed?

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41938] concurrent.futures.wait calls len() on an possible iterable

[Kaushal Rohit]

Change by Kaushal Rohit :


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

___
Python tracker 

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

[issue41938] concurrent.futures.wait calls len() on an possible iterable

[Kaushal Rohit]

New submission from Kaushal Rohit :

`fs` argument could be an iterable, and calling len on it would raise an 
Exception.

We are converting `fs` into a set anyways for set difference, and that too 
twice. we can just put an `fs = set(fs)`.

Let me know if we choose to go with that and I will make a PR ASAP.

Thanks.

--
components: Library (Lib)
messages: 377991
nosy: rohitkg98
priority: normal
severity: normal
status: open
title: concurrent.futures.wait calls len() on an possible iterable
type: behavior
versions: Python 3.10

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Hi Jason,

I think I have to review the whole set of changes again to understand what your 
motivation is/was. 

For https://bugs.python.org/issue35967 I had already stated that your use case 
is not special enough to make the platform.py logic more complex.

BTW: Please don't open several different tickets for the same problem. It 
doesn't really help to see what is going on. I'll reopen the issue35967 to 
continue the discussion there.

Thanks.

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> you added a late binding optimization for the whole uname return
tuple to save the effort of ... shell access.

It wasn't to save the effort and it wasn't an optimization. There was a 
fundamental race condition where it became impossible to implement a `uname` 
command using Python because `platform.system()` (or anything else that 
delegated to `platform.uname()`) would unconditionally shell out to `uname`, 
and this would happen early, before a library could intercept the behavior. See 
issue35967 for more details on the motivation and challenges.

> I think this would have been better implemented...

This idea is interesting, but I believe it also falls prey to the same race 
condition if any code calls `platform.uname()` before a Python-based uname 
implementation has a chance to monkeypatch the behavior.

May I suggest that you either revive the conversation in issue35967 or open a 
new ticket to discuss improving the implementation so that the details aren't 
lost in this ticket, which was specifically about compatibility issues?

> I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.

I'll address this concern in the ticket I opened about the deprecation.

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ok, let me add some more context: When I wrote the uname interface
I was aware that calling the API will take some resources. That's
why I added the cache. IMO, that was enough as optimization.

Now, you added a late binding optimization for the whole uname return
tuple to save the effort of going out to the system and figure our
the value using separate APIs or even shell access.

I think this would have been better implemented in the various
uname() consumers
(https://github.com/python/cpython/blob/77c614624b6bf2145bef69830d0f499d8b55ec0c/Lib/platform.py#L898
and below), using a variant of the uname() API, say _uname(),
which leaves out the processor information for those APIs which don't
need it and only provide the late binding in processor() (which could
then also fill in the cache value for uname().

The uname() API would then still do the full lookup, but applications
could then use the specialized API to query only the information
they need.

I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 09 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've gone ahead and merged PR 20015 to fix the issue, but I'm happy to revisit 
if a better approach is proposed.

--
keywords: +3.9regression -patch
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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:


New changeset 2c3d508c5fabe40dac848fb9ae558069f0576879 by Jason R. Coombs in 
branch 'master':
bpo-40570: Improve compatibility of uname_result with late-bound .platform 
(#20015)
https://github.com/python/cpython/commit/2c3d508c5fabe40dac848fb9ae558069f0576879


--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks Marc-Andre for the suggestion, but I don't think that approach is viable 
here. The whole point of issue35967 was to defer the execution of the 
`.processor` behavior until it was requested. The intention is not to extend 
the tuple, but to shorten it (at least not to require the last element to be 
provided at construction time). Perhaps I'm missing something here, so feel 
free to provide a more concrete example of what you have in mind. Just be 
cautious not to violate the intention 
(https://github.com/python/cpython/blob/77c614624b6bf2145bef69830d0f499d8b55ec0c/Lib/platform.py#L784-L787).

I created issue40578 to track deprecation of uname for positional access.

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Hi Jason,

to achieve better backwards compatibility, it's probably better to use
the approach taken for CodeInfo in the codecs.py module:

class CodecInfo(tuple):
"""Codec details when looking up the codec registry"""

def __new__(cls, encode, decode, streamreader=None, streamwriter=None,
incrementalencoder=None, incrementaldecoder=None, name=None,
*, _is_text_encoding=None):
self = tuple.__new__(cls, (encode, decode, streamreader,
streamwriter))
self.name = name
self.encode = encode
self.decode = decode
self.incrementalencoder = incrementalencoder
self.incrementaldecoder = incrementaldecoder
self.streamwriter = streamwriter
self.streamreader = streamreader
if _is_text_encoding is not None:
self._is_text_encoding = _is_text_encoding
return self

def __repr__(self):
return "<%s.%s object for encoding %s at %#x>" % \
(self.__class__.__module__, self.__class__.__qualname__,
 self.name, id(self))

This used to be a 4 entry tuple and was extended to hold additional
fields. To the outside, it still looks like a 4-tuple in all aspects,
but attribute access permits accessing the additional fields.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 09 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks David for the report and the draft PR (which helped me validate my 
thinking on the matter). In PR 20015, I've included additional tests. I've also 
re-written the compatibility functions to rely on the main `__iter__` override.

Another situation that's likely to be incompatible is pickleability. Is that 
important?

I'm tempted to make deprecated the use of `uname_result` for anything other 
than attribute access (maybe with the ability to cast to a tuple, i.e. 
`tuple(res)`). The problem with namedtuples is that although they provide 
backward-compatibility for legacy behavior which returned tuples, they also 
bring that legacy as debt. By deprecating "access by index", that would 
constrain the interface to two basic usages: attribute access and `iter()` of 
all values.

--

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +19326
pull_request: https://github.com/python/cpython/pull/20015

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

If it is important to retain the `len`, it's probably also important to retain 
the `[-N]` accesses and possibly other behaviors of a length 6 tuple.

--

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Jason R. Coombs]

Jason R. Coombs  added the comment:

It was intentional to address issue35967, although it was meant to remain 
compatible.

Is len(uname()) an important behavior to retain? It feels like an 
implementation detail to me.

--

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[Zachary Ware]

Change by Zachary Ware :


--
nosy: +jaraco, lemburg

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[David Tucker]

Change by David Tucker :


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

___
Python tracker 

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

[issue40570] len(platform.uname()) has changed in Python 3.9

[David Tucker]

New submission from David Tucker :

https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00#diff-47c8e5750258a08a6dd9de3e9c3774acL741-R804

That diff changed len(platform.uname()) to 5 (from 6).

I noticed because we have some code that checks for 6 strs (arguably 
unnecessary),
but I can also think of contrived examples that would break (e.g. 
platform.uname()[-3]).
Interestingly, platform.uname()[5] still works.

Was this effect intentional?

--
components: Library (Lib)
messages: 368459
nosy: tucked
priority: normal
severity: normal
status: open
title: len(platform.uname()) has changed in Python 3.9
type: behavior
versions: Python 3.9

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

[issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function)

[Zac Hatfield-Dodds]

Change by Zac Hatfield-Dodds :


--
pull_requests: +17340
pull_request: https://github.com/python/cpython/pull/17934

___
Python tracker 

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

[issue39227] OverflowError in len(range(2**63))

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue39227] OverflowError in len(range(2**63))

[Mark Dickinson]

Mark Dickinson  added the comment:

(See also #21444)

--

___
Python tracker 

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

[issue39227] OverflowError in len(range(2**63))

[Mark Dickinson]

Mark Dickinson  added the comment:

Duplicate of #12159?

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue39227] OverflowError in len(range(2**63))

[Zac Hatfield-Dodds]

New submission from Zac Hatfield-Dodds :

The value for `len` internally passes through an `ssize_t`, which means that it 
raises OverflowError for (very) large collections.

This is admittedly only possible with collections such as `range` that do not 
store all their elements in memory, but it would still be nice to have 
`len(range(n)) == n` without caveats.

This was found via a teaching example and is now tracked in my repo of 
property-based tests for CPython:
https://github.com/rsokl/Learning_Python/pull/125
https://github.com/Zac-HD/stdlib-property-tests/blob/bb46996ca4500381ba09a8cd430caaddd71910bc/tests.py#L28-L34

Related to https://bugs.python.org/issue26423, but it's still present in the 
development branches for 3.7, 3.8, and 3.9; and instead of a wrong result it's 
an error (which is better!).

--
components: Interpreter Core
messages: 359394
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: OverflowError in len(range(2**63))
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[issue29352] provide the authorative source for s[i:j] negative slice indices (<-len(s)) behavior for standard sequences

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> out of date
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

[issue32644] unittest.mock.call len() error

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

call objects inherit from tuple and here the reported argument is a dict with 3 
items returning len of 3. I am closing this as part of triaging since there is 
no additional information from @snakevil on reproducing this. Feel free to 
reopen this if there is more information on reproducing the issue.

./python.exe
Python 3.9.0a0 (heads/master:cb65202520, Jun  6 2019, 11:15:04)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from unittest.mock import call
>>> c = call('solution', 'foo', {'__spots__': {}, '__event__': None, 
>>> '__solution__': None})
>>> len(c.args[2])
3
>>> len(c)
3
>>> c.args
('solution', 'foo', {'__spots__': {}, '__event__': None, '__solution__': None})
>>> c.kwargs
{}

--
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

STINNER Victor  added the comment:


New changeset aaed2c332ae8370e5e87d09c43ef7a39c2abf68d by Victor Stinner in 
branch '2.7':
bpo-26423: Fix test_descr.test_wrap_lenfunc_bad_cast() on 32-bit Windows 
(GH-13629)
https://github.com/python/cpython/commit/aaed2c332ae8370e5e87d09c43ef7a39c2abf68d


--

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13529
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/13629

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

STINNER Victor  added the comment:

Oh. The test fails on Python 2.7 on Windows:

https://buildbot.python.org/all/#/builders/26/builds/287

ERROR: test_wrap_lenfunc_bad_cast (test.test_descr.OperatorsTest)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\2.7.kloth-win64vs9\build\lib\test\test_descr.py", line 
407, in test_wrap_lenfunc_bad_cast
self.assertEqual(xrange(sys.maxsize).__len__(), sys.maxsize)
OverflowError: Python int too large to convert to C long

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Zackery Spytz for the fix. It's now applied to 2.7, 3.7 and master 
branches.

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 80dfe990162e7a2dd99524829beecd449a973e9e by Victor Stinner in 
branch '2.7':
bpo-26423: Fix possible overflow in wrap_lenfunc() (GH-13606) (GH-13625)
https://github.com/python/cpython/commit/80dfe990162e7a2dd99524829beecd449a973e9e


--

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13524
pull_request: https://github.com/python/cpython/pull/13625

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[miss-islington]

miss-islington  added the comment:


New changeset e7ddf586ae5b7a3b975103b09c8202226d77f421 by Miss Islington (bot) 
in branch '3.7':
bpo-26423: Fix possible overflow in wrap_lenfunc() (GH-13606)
https://github.com/python/cpython/commit/e7ddf586ae5b7a3b975103b09c8202226d77f421


--
nosy: +miss-islington

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[Zackery Spytz]

Change by Zackery Spytz :


--
nosy: +ZackerySpytz
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[miss-islington]

Change by miss-islington :


--
pull_requests: +13522
pull_request: https://github.com/python/cpython/pull/13622

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 05f16416d99dc9fc76fef11e56f16593e7a5955e by Victor Stinner 
(Zackery Spytz) in branch 'master':
bpo-26423: Fix possible overflow in wrap_lenfunc() (GH-13606)
https://github.com/python/cpython/commit/05f16416d99dc9fc76fef11e56f16593e7a5955e


--

___
Python tracker 

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

[issue26423] Integer overflow in wrap_lenfunc() on 64-bit build of Windows with len > 2**31-1

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue24767] can concurrent.futures len(Executor) return the number of tasks?

[Brian Quinlan]

Brian Quinlan  added the comment:

If we supported this, aren't we promising that we will always materialize the 
iterator passed to map?

I think that we'd need a really strong use-case for this to be worth-while.

--

___
Python tracker 

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

[issue30689] len() and iter() of ChainMap don't work with unhashable keys

[ebw]

ebw  added the comment:

I actually have a real life use case of that problem. Using the eval() function 
of pandas need to use a custom resolver:

class Resolver(object):
def __getitem__(self, name):
if name == "test":
return 0.5
else:
raise KeyError

resolvers = (Resolver(), )
pd.eval("test", resolvers=resolvers)

But pandas store the resolvers used for eval() in a DeepChainMap and uses 
bool(len(self.resolvers)) in the property has_resolvers. Which with my custom 
Resolver raise a KeyError because __getiem__ gets call with name = 0.

The way to solve/bypass the problem was to make Resolver a inherit from 
UserDict.

class Resolver(UserDict):
def __init__(self, data={}):
super(Resolver, self).__init__(data)
self.data["test"] = None

def __getitem__(self, name):
if (name == "test"):
return 0.5
else:
super(Resolver, self).__getitem__(name)

resolvers = (Resolver(), )
pd.eval("test", resolvers=resolvers)

I had to add a dummy "test" value to Resolver.data dict to avoid 
len(self.resolvers) to be 0. I tried to implement Resolver.__len__, keys... but 
it didn't help has ChainMap compute the len using set().union(*self.maps).

--
nosy: +ebw

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

[issue32644] unittest.mock.call len() error

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue27671] FAQ: len() is still function for good reason.

[INADA Naoki]

Change by INADA Naoki :


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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

miss-islington  added the comment:


New changeset dc9039da239ee572eaaf56e4a026be1fc4d74e24 by Miss Islington (bot) 
in branch '2.7':
bpo-27671: Update FAQ about why len is function (GH-8432)
https://github.com/python/cpython/commit/dc9039da239ee572eaaf56e4a026be1fc4d74e24


--

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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

miss-islington  added the comment:


New changeset 0b376eb0d63e0c51ed55c620b40edae6ded4ea48 by Miss Islington (bot) 
in branch '3.6':
bpo-27671: Update FAQ about why len is function (GH-8432)
https://github.com/python/cpython/commit/0b376eb0d63e0c51ed55c620b40edae6ded4ea48


--

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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

miss-islington  added the comment:


New changeset a621f406402e05febb302cf31962e9d2d747d8f6 by Miss Islington (bot) 
in branch '3.7':
bpo-27671: Update FAQ about why len is function (GH-8432)
https://github.com/python/cpython/commit/a621f406402e05febb302cf31962e9d2d747d8f6


--
nosy: +miss-islington

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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

Change by miss-islington :


--
pull_requests: +8087

___
Python tracker 

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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

Change by miss-islington :


--
pull_requests: +8086

___
Python tracker 

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

[issue27671] FAQ: len() is still function for good reason.

[miss-islington]

Change by miss-islington :


--
pull_requests: +8085

___
Python tracker 

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

[issue27671] FAQ: len() is still function for good reason.

[INADA Naoki]

INADA Naoki  added the comment:


New changeset c48e26dcadbff8620bb5881d3bd148fc8894d0ef by INADA Naoki in branch 
'master':
bpo-27671: Update FAQ about why len is function (GH-8432)
https://github.com/python/cpython/commit/c48e26dcadbff8620bb5881d3bd148fc8894d0ef


--

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

[issue27671] FAQ: len() is still function for good reason.

[INADA Naoki]

Change by INADA Naoki :


--
pull_requests: +7957
stage:  -> patch review

___
Python tracker 

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

[issue33933] Error message says dict has no len

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think this is an exact duplicate of issue32500.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> PySequence_Length() raises TypeError on dict type

___
Python tracker 

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

[issue33933] Error message says dict has no len

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue33933] Error message says dict has no len

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This probably doesn't warrant another tracker entry.  Serhiy already had a PR 
for this and attached it to the original bug report for 
https://bugs.python.org/issue32500 .  See 
https://github.com/python/cpython/pull/7846

My suggestion would be to just change the error message in PySequence_Size() 
from "object of type '%.200s' has no len()" to "object of type '%.200s' has no 
len() or does not support the sequence protocol (consider using a list 
instead)".

Marking this as low priority because the behavior has existed for a very long 
time and hasn't bothered anyone until now (possibly because the bisect module 
is documented to only search lists).  Also, this is a specific instance of a 
more general, pervasive, and hard problem where low level routines raise 
exceptions that have error messages than may not make much sense from the point 
of view someone calling higher level APIs.

Suggest closing this as a duplicate and continuing the discussion back in 
issue32500 where it arose.  This would show-up in any C code that calls 
PySequence_Size() not just bisect.

--
nosy: +rhettinger
priority: normal -> low

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

[issue33933] Error message says dict has no len

[Vedran Čačić]

New submission from Vedran Čačić :

Look at this:

>>> import bisect
>>> bisect.bisect({}, None)
Traceback (most recent call last):
  File "", line 1, in 
bisect.bisect({}, None)
TypeError: object of type 'dict' has no len()

Of course, objects of type 'dict' do have len. The problem is that bisect 
considers its first argument a sequence, which is very sensible to do 
(although, with ordered dicts, it's not the only sensible choice), but it gives 
a very wrong error message given that context.

At https://bugs.python.org/issue32500, R. David Murray told me to open this.

--
components: Interpreter Core
messages: 320178
nosy: veky
priority: normal
severity: normal
status: open
title: Error message says dict has no len
versions: Python 3.7

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

[issue33108] Unicode char 304 in lowercase has len = 2

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you Ma Lin.

Closed as a duplicate of issue17252.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Latin Capital Letter I with Dot Above

___
Python tracker 

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

[issue33108] Unicode char 304 in lowercase has len = 2

[Ma Lin]

Ma Lin  added the comment:

There was a discussion about "Latin Capital Letter I with Dot Above"
https://bugs.python.org/issue17252

--
nosy: +Ma Lin

___
Python tracker 

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

[issue33108] Unicode char 304 in lowercase has len = 2

[INADA Naoki]

INADA Naoki  added the comment:

Maybe, we should update UnicodeData?

--

___
Python tracker 

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

[issue33108] Unicode char 304 in lowercase has len = 2

[Steven D'Aprano]

Steven D'Aprano  added the comment:

It has never been the case that upper() or lower() are guaranteed to preserve 
string length in Unicode. For example, some characters decompose into a base 
plus combining characters. Ligatures are another example. See here for more 
details:

https://unicode.org/faq/casemap_charprop.html


However, this example surprises me. In Python 2, I get the result I expected:

py> c = unichr(304)
py> unicodedata.name(c)
'LATIN CAPITAL LETTER I WITH DOT ABOVE'
py> unicodedata.name(c.lower())
'LATIN SMALL LETTER I'


If I am reading the UnicodeData.txt file correctly, I think that the right 
behaviour is for LATIN CAPITAL LETTER I WITH DOT ABOVE to lowercase to LATIN 
SMALL LETTER I, as it did in Python 2.

ftp://ftp.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt

--
nosy: +steven.daprano

___
Python tracker 

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

[issue33108] Unicode char 304 in lowercase has len = 2

[Kiril Dimitrov]

Kiril Dimitrov <kiril.dimitr...@gmail.com> added the comment:

This is roughly my use case:
zip( "ßx", [0.5, 0.3]) is [('ß', 0.5), ('x', 0.3)]
zip("ßx".upper(), [0.5, 0.3])  will be [('S', 0.5), ('S', 0.3)] in later
case you never get to see the value for 'x'.

At least my expectation was that lower and upper should preserve text
length. At least this seemed to be the case in python2.7

2018-03-20 15:28 GMT+02:00 INADA Naoki <rep...@bugs.python.org>:

>
> INADA Naoki <songofaca...@gmail.com> added the comment:
>
> Another example:
>
> >>> s = "ß"
> >>> len(s)
> 1
> >>> len(s.upper())
> 2
> >>> s.upper()
> 'SS'
> >>> ord(s)
> 223
>
>
> > This breaks unicode text matching.
>
> What do you talking about? re module?
>
> --
> nosy: +inada.naoki
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue33108>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33108] Unicode char 304 in lowercase has len = 2

[INADA Naoki]

INADA Naoki <songofaca...@gmail.com> added the comment:

Another example:

>>> s = "ß"
>>> len(s)
1
>>> len(s.upper())
2
>>> s.upper()
'SS'
>>> ord(s)
223


> This breaks unicode text matching.

What do you talking about? re module?

--
nosy: +inada.naoki

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33108] Unicode char 304 in lowercase has len = 2

[Kiril Dimitrov]

Change by Kiril Dimitrov <kiril.dimitr...@gmail.com>:


--
title: Unicode char 304 in lowercase has len 2 -> Unicode char 304 in lowercase 
has len = 2

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33108] Unicode char 304 in lowercase has len 2

[Kiril Dimitrov]

New submission from Kiril Dimitrov <kiril.dimitr...@gmail.com>:

>>> chr(304)
'İ'
>>> chr(304).lower()
'i̇'
>>> len(chr(304).lower())
2

This breaks unicode text matching. There is no other unicode character with the 
same behaviour (in 3.6.2 and 3.6.4).

--
components: Unicode
messages: 314142
nosy: Kiril Dimitrov, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Unicode char 304 in lowercase has len 2
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32644] unittest.mock.call len() error

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Please either upload or include in a post a minimal testcase that reproduces 
the problem.  We can neither debug the problem or know if we fix it without one.

--
nosy: +michael.foord, terry.reedy

___
Python tracker 

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

[issue32644] unittest.mock.call len() error

[Snakevil]

New submission from Snakevil <zsnake...@gmail.com>:

In some testcase, an instance of unittest.mock.call was generated as:

call('solution', 'foo', {'__spots__': {}, '__event__': None, '__solution__': 
None})

The third argument is an instance of a derived component from dict.

In this issue, result of len() is 2 but not 3 as expected.

--
components: Tests
messages: 310565
nosy: snakevil
priority: normal
severity: normal
status: open
title: unittest.mock.call len() error
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32644>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32180] bool() vs len() > 0 on lists

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm sure adding list.__bool__() will not affect the performance. The real 
source of the difference is explained on the StackOverflow link.

PEP 8 contains a rule for testing the emptiness of a container.

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

[issue32180] bool() vs len() > 0 on lists

[Raymond Hettinger]

Raymond Hettinger  added the comment:

ISTM that there isn't a real issue here and the discussions of proper timing 
technique and micro-optimizations are more suitable for StackOverflow.

--
nosy: +rhettinger

___
Python tracker 

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

[issue32180] bool() vs len() > 0 on lists

[Дилян Палаузов]

Дилян Палаузов  added the comment:

Is the speedup a matter of adding "__bool__" to list_methods in 
object/listobject.c?

In any case, I am not in the internals of cpython, so that I am not going to 
provide a patch.

With PyObject_Bool I meant PyObject_IsTrue.

--

___
Python tracker 

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

[issue32180] bool() vs len() > 0 on lists

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I don't know what should mean PyObject_Bool(), but in C code you should use 
PyObject_IsTrue() for getting the boolean value of the object.

--

___
Python tracker 

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

[issue32180] bool() vs len() > 0 on lists

[Дилян Палаузов]

Дилян Палаузов <dilyan.palau...@aegee.org> added the comment:

Under these circumstances 
https://wiki.python.org/moin/PythonSpeed/PerformanceTips shall be updated to 
state that 

"len('a list') > 0" is slower than "True if 'a list' else False"

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32180] bool() vs len() > 0 on lists

[Дилян Палаузов]

Дилян Палаузов <dilyan.palau...@aegee.org> added the comment:

To my understanding this optimization (bool([]) faster than len([])) cannot be 
made until PyObject_Bool is introduced, similar to PyObject_Repr and 
PyObject_Length.

Am I not going to provide a patch.

--
status: pending -> open

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32180] bool() vs len() > 0 on lists

[Serhiy Storchaka]

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:

The cause of len() been faster than bool() is the same as why repr() is faster 
than str(). [1] len() and repr() are functions that just call corresponding 
slots, while bool() and str() are constructors.

In most cases you shouldn't use `bool(obj)` or `len(obj) > 0`. Instead use just 
`obj` in conditions.

If you can provide a patch that speeds up constructions of simple class 
instances, please open a pull request on GitHub. Otherwise this issue will be 
closed.

[1] 
https://stackoverflow.com/questions/45376719/why-is-reprint-faster-than-strint

--
nosy: +serhiy.storchaka
status: open -> pending
versions: +Python 3.7 -Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32180] bool() vs len() > 0 on lists

[Дилян Палаузов]

New submission from Дилян Палаузов <dilyan.palau...@aegee.org>:

Please make bool() on lists at least as fast as len() > 0 on lists is.

The trivial approach would be to define __bool__ on lists, that do something 
like  "True if self else False".

python3 
Python 3.6.3+ (heads/3.6-dirty:2b5cbbb13c, Nov  1 2017, 19:03:09) 
[GCC 6.4.1 20171025] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.timeit('len([]) > 0')
0.0983404889702797
>>> timeit.timeit('bool([])')
0.15502946823835373
>>> timeit.timeit('True if [] else False')
0.03108721226453781
>>> timeit.timeit('len([1]) > 0')
0.11656427383422852
>>> timeit.timeit('bool([1])')
0.19317257404327393
>>> timeit.timeit('True if [1] else False')
0.057590410113334656

--
messages: 307294
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: bool() vs len() > 0 on lists
type: performance
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: TypeError with map with no len()

[john polo]

On 9/25/2017 5:37 PM, Thomas Jollans wrote:

On 25/09/17 18:44, john polo wrote:

Python List,

I am trying to make practice data for plotting purposes. I am using
Python 3.6. The instructions I have are

import matplotlib.pyplot as plt
import math
import numpy as np
t = np.arange(0, 2.5, 0.1)
y1 = map(math.sin, math.pi*t)

If you use np.sin instead of math.sin, you don't have to use map: Most
numpy functions operate elementwise on arrays (for example, you're
multiplying math.pi with an array - something that wouldn't work with a
list).

Here's the numpy way of doing this:

t = np.arange(0, 2.5, 0.1)
y1 = np.sin(np.pi * t)

Without using numpy at all, this might be

t = [i * 0.1 for i in range(25)]
y1 = [math.pi * a for a in t]

The numpy way looks like a great alternative. Thank you, Thomas.

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

Re: TypeError with map with no len()

[Thomas Jollans]

On 25/09/17 18:44, john polo wrote:
> Python List,
>
> I am trying to make practice data for plotting purposes. I am using
> Python 3.6. The instructions I have are
>
> import matplotlib.pyplot as plt
> import math
> import numpy as np
> t = np.arange(0, 2.5, 0.1)
> y1 = map(math.sin, math.pi*t)

If you use np.sin instead of math.sin, you don't have to use map: Most
numpy functions operate elementwise on arrays (for example, you're
multiplying math.pi with an array - something that wouldn't work with a
list).

Here's the numpy way of doing this:

t = np.arange(0, 2.5, 0.1)
y1 = np.sin(np.pi * t)

Without using numpy at all, this might be

t = [i * 0.1 for i in range(25)]
y1 = [math.pi * a for a in t]

> plt.plot(t,y1)
>
> However, at this point, I get a TypeError that says
>
> object of type 'map' has no len()
>
> In [6]: t
> Out[6]:
> array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7, 0.8,  0.9,  1. ,
> 1.1,  1.2,  1.3,  1.4,  1.5,  1.6,  1.7,  1.8, 1.9,  2. ,  2.1,
> 2.2,  2.3,  2.4])
> In [7]: y1
> Out[7]: 
> In [8]: math.pi*t
> Out[8]:
> array([ 0.,  0.31415927,  0.62831853,  0.9424778 , 1.25663706,
> 1.57079633,  1.88495559,  2.19911486,  2.51327412, 2.82743339,
> 3.14159265,  3.45575192,  3.76991118,  4.08407045, 4.39822972,
> 4.71238898,  5.02654825,  5.34070751,  5.65486678, 5.96902604,
> 6.28318531,  6.59734457,  6.91150384,  7.2256631 , 7.53982237])
>
> At the start of creating y1, it appears there is an array to iterate
> through for the math.sin function used in map(), but y1 doesn't appear
> to be saving any values. I expected y1 to hold a math.sin() output for
> each item in math.pi*t, but it appears to be empty. Am I
> misunderstanding map()? Is there something else I should be doing
> instead to populate y1?
>
>
> John
>

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

Re: TypeError with map with no len()

[john polo]

On 9/25/2017 12:03 PM, Paul Moore wrote:

You're using Python 3, and I suspect that you're working from
instructions that assume Python 2. In Python 3, the result of map() is
a generator, not a list (which is what Python 2's map returned). In
order to get an actual list (which appears to be what you need for
your plot call) you just need to call the list constructor:

y1 = list(map(math.sin, math.pi*t))

Although given that you're using numpy, it may be that there's a more
idiomatic numpy way of doing this. I'm not a numpy expert though, so I
can't help on that.

Paul

Paul,
Thank you very much for the explanation.

best regards,
John
--
https://mail.python.org/mailman/listinfo/python-list

Re: TypeError with map with no len()

[Paul Moore]

You're using Python 3, and I suspect that you're working from
instructions that assume Python 2. In Python 3, the result of map() is
a generator, not a list (which is what Python 2's map returned). In
order to get an actual list (which appears to be what you need for
your plot call) you just need to call the list constructor:

y1 = list(map(math.sin, math.pi*t))

Although given that you're using numpy, it may be that there's a more
idiomatic numpy way of doing this. I'm not a numpy expert though, so I
can't help on that.

Paul

On 25 September 2017 at 17:44, john polo <jp...@mail.usf.edu> wrote:
> Python List,
>
> I am trying to make practice data for plotting purposes. I am using Python
> 3.6. The instructions I have are
>
> import matplotlib.pyplot as plt
> import math
> import numpy as np
> t = np.arange(0, 2.5, 0.1)
> y1 = map(math.sin, math.pi*t)
> plt.plot(t,y1)
>
> However, at this point, I get a TypeError that says
>
> object of type 'map' has no len()
>
> In [6]: t
> Out[6]:
> array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7, 0.8,  0.9,  1. ,
> 1.1,  1.2,  1.3,  1.4,  1.5,  1.6,  1.7,  1.8, 1.9,  2. ,  2.1,
> 2.2,  2.3,  2.4])
> In [7]: y1
> Out[7]: 
> In [8]: math.pi*t
> Out[8]:
> array([ 0.,  0.31415927,  0.62831853,  0.9424778 , 1.25663706,
> 1.57079633,  1.88495559,  2.19911486,  2.51327412, 2.82743339,
> 3.14159265,  3.45575192,  3.76991118,  4.08407045, 4.39822972,
> 4.71238898,  5.02654825,  5.34070751,  5.65486678, 5.96902604,
> 6.28318531,  6.59734457,  6.91150384,  7.2256631 , 7.53982237])
>
> At the start of creating y1, it appears there is an array to iterate through
> for the math.sin function used in map(), but y1 doesn't appear to be saving
> any values. I expected y1 to hold a math.sin() output for each item in
> math.pi*t, but it appears to be empty. Am I misunderstanding map()? Is there
> something else I should be doing instead to populate y1?
>
>
> John
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: TypeError with map with no len()

[Grant Edwards]

On 2017-09-25, john polo <jp...@mail.usf.edu> wrote:
> Python List,
>
> I am trying to make practice data for plotting purposes. I am using 
> Python 3.6. The instructions I have are
>
> import matplotlib.pyplot as plt
> import math
> import numpy as np
> t = np.arange(0, 2.5, 0.1)
> y1 = map(math.sin, math.pi*t)
> plt.plot(t,y1)
>
> However, at this point, I get a TypeError that says
>
> object of type 'map' has no len()

you probably need to convert y1 from a 'map' object (a type of an
iterator) to an array.

y1 = map(math.sin, math.pi*t)
y1 = np.fromiter(y1, float)

-- 
Grant Edwards   grant.b.edwardsYow! Will this never-ending
  at   series of PLEASURABLE
  gmail.comEVENTS never cease?

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

Re: TypeError with map with no len()

[Peter Otten]

john polo wrote:

> Python List,
> 
> I am trying to make practice data for plotting purposes. I am using
> Python 3.6. The instructions I have are
> 
> import matplotlib.pyplot as plt
> import math
> import numpy as np
> t = np.arange(0, 2.5, 0.1)
> y1 = map(math.sin, math.pi*t)
> plt.plot(t,y1)
> 
> However, at this point, I get a TypeError that says
> 
> object of type 'map' has no len()
> 
> In [6]: t
> Out[6]:
> array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7, 0.8,  0.9,  1. ,
>  1.1,  1.2,  1.3,  1.4,  1.5,  1.6,  1.7,  1.8, 1.9,  2. ,  2.1,
>  2.2,  2.3,  2.4])
> In [7]: y1
> Out[7]: 
> In [8]: math.pi*t
> Out[8]:
> array([ 0.,  0.31415927,  0.62831853,  0.9424778 , 1.25663706,
>  1.57079633,  1.88495559,  2.19911486,  2.51327412, 2.82743339,
>  3.14159265,  3.45575192,  3.76991118,  4.08407045, 4.39822972,
>  4.71238898,  5.02654825,  5.34070751,  5.65486678, 5.96902604,
>  6.28318531,  6.59734457,  6.91150384,  7.2256631 , 7.53982237])
> 
> At the start of creating y1, it appears there is an array to iterate
> through for the math.sin function used in map(), but y1 doesn't appear
> to be saving any values. I expected y1 to hold a math.sin() output for
> each item in math.pi*t, but it appears to be empty. Am I
> misunderstanding map()? Is there something else I should be doing
> instead to populate y1?

map() is "lazy" in Python 3, i. e. it calculates the values when you iterate 
over it, not before:

>>> def noisy_square(x):
... print("calculating {0} * {0}".format(x))
... return x * x
... 
>>> squares = map(noisy_square, [1, 3, 2])
>>> for y in squares:
... print(y)
... 
calculating 1 * 1
1
calculating 3 * 3
9
calculating 2 * 2
4

While you can convert y1 to a list with

y1 = list(y1)

the better approach is to use numpy:

y1 = np.sin(t * math.pi)

Now y1 is a numpy.array and can be fed to pyplot.plot() directly.

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

Re: TypeError with map with no len()

[Ned Batchelder]

On 9/25/17 12:44 PM, john polo wrote:

Python List,

I am trying to make practice data for plotting purposes. I am using 
Python 3.6. The instructions I have are


import matplotlib.pyplot as plt
import math
import numpy as np
t = np.arange(0, 2.5, 0.1)
y1 = map(math.sin, math.pi*t)
plt.plot(t,y1)

However, at this point, I get a TypeError that says

object of type 'map' has no len()

In [6]: t
Out[6]:
array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7, 0.8,  0.9, 1. ,
    1.1,  1.2,  1.3,  1.4,  1.5,  1.6,  1.7,  1.8, 1.9,  2. , 2.1,
    2.2,  2.3,  2.4])
In [7]: y1
Out[7]: 
In [8]: math.pi*t
Out[8]:
array([ 0.    ,  0.31415927,  0.62831853,  0.9424778 , 1.25663706,
    1.57079633,  1.88495559,  2.19911486,  2.51327412, 2.82743339,
    3.14159265,  3.45575192,  3.76991118,  4.08407045, 4.39822972,
    4.71238898,  5.02654825,  5.34070751,  5.65486678, 5.96902604,
    6.28318531,  6.59734457,  6.91150384,  7.2256631 , 7.53982237])

At the start of creating y1, it appears there is an array to iterate 
through for the math.sin function used in map(), but y1 doesn't appear 
to be saving any values. I expected y1 to hold a math.sin() output for 
each item in math.pi*t, but it appears to be empty. Am I 
misunderstanding map()? Is there something else I should be doing 
instead to populate y1?


In Python 2, map() produced a list. In Python 3, it returns a lazy 
iterator instead.  You can run the iterator with list():


    y1 = list(map(math.sin, math.pi*t))

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

TypeError with map with no len()

[john polo]

Python List,

I am trying to make practice data for plotting purposes. I am using 
Python 3.6. The instructions I have are


import matplotlib.pyplot as plt
import math
import numpy as np
t = np.arange(0, 2.5, 0.1)
y1 = map(math.sin, math.pi*t)
plt.plot(t,y1)

However, at this point, I get a TypeError that says

object of type 'map' has no len()

In [6]: t
Out[6]:
array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7, 0.8,  0.9,  1. ,
    1.1,  1.2,  1.3,  1.4,  1.5,  1.6,  1.7,  1.8, 1.9,  2. ,  2.1,
    2.2,  2.3,  2.4])
In [7]: y1
Out[7]: 
In [8]: math.pi*t
Out[8]:
array([ 0.    ,  0.31415927,  0.62831853,  0.9424778 , 1.25663706,
    1.57079633,  1.88495559,  2.19911486,  2.51327412, 2.82743339,
    3.14159265,  3.45575192,  3.76991118,  4.08407045, 4.39822972,
    4.71238898,  5.02654825,  5.34070751,  5.65486678, 5.96902604,
    6.28318531,  6.59734457,  6.91150384,  7.2256631 , 7.53982237])

At the start of creating y1, it appears there is an array to iterate 
through for the math.sin function used in map(), but y1 doesn't appear 
to be saving any values. I expected y1 to hold a math.sin() output for 
each item in math.pi*t, but it appears to be empty. Am I 
misunderstanding map()? Is there something else I should be doing 
instead to populate y1?



John

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