[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

Raymond Hettinger added the comment: Length hints were intentionally omitted from the Python 3 map() and filter() which used to be in the itertools module. I explored that notion of iterator length transparency years ago. While I don't remember all the details, I did record some notes at

[issue30034] csv reader chokes on bad quoting in large files

Raymond Hettinger added the comment: > In my experience CSV files with fields with embedded newlines > are pretty common. I don't really think we want to support > invalid CSV files. I concur with David on both points. Also, whether common or not, we don't want to break existing code that

[issue30035] [RFC] PyMemberDef.name should be const char *

New submission from Sunyeop Lee: PyMemberDef from Noddy examaple: https://docs.python.org/3/extending/newtypes.html static PyMemberDef Noddy_members[] = { {"first", T_OBJECT_EX, offsetof(Noddy, first), 0, "first name"}, {"last", T_OBJECT_EX, offsetof(Noddy, last), 0, "last

[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___

[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

Changes by Michael Seifert : -- pull_requests: +1220 ___ Python tracker ___ ___

[issue29030] argparse: choices override metavar

Changes by Raymond Hettinger : -- assignee: -> bethard nosy: +bethard ___ Python tracker ___

[issue26860] Make os.walk and os.fwalk yield namedtuple instead of tuple

Changes by Raymond Hettinger : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___

[issue30034] csv reader chokes on bad quoting in large files

Keith Erskine added the comment: As you say, David, however much we would like the world to stick to a given CSV standard, the reality is that people don't, which is all the more reason for making the csv reader flexible and forgiving. The csv module can and should be used for more than just

[issue30034] csv reader chokes on bad quoting in large files

R. David Murray added the comment: Well, ETL is semi-standardized. Try dealing with csv files exported from excel spreadsheets written by non-programmers :) "e"X is not a quoting the csv module will produce, but I don't think it is a csv error. insofar as csv has a standard, it is a defacto

[issue30034] csv reader chokes on bad quoting in large files

Keith Erskine added the comment: The csv reader already handles a certain amount of bad formatting. For example, using default behavior, the following file: a,b,c d,"e"X,f g,h,i is read as: ['a', 'b', 'c'] ['d', 'eX', 'f'] ['g', 'h', 'i'] It seems reasonable that csv should be able to

[issue30034] csv reader chokes on bad quoting in large files

R. David Murray added the comment: In my experience CSV files with fields with embedded newlines are pretty common. I don't really think we want to support invalid CSV files. -- nosy: +r.david.murray ___ Python tracker

[issue30034] csv reader chokes on bad quoting in large files

Keith Erskine added the comment: Perhaps I should add what I would prefer the csv reader to return in my example above. That would be: ['a', 'b', 'c'] ['d', 'e,f'] ['g', 'h', 'i'] Yes, the second line is still mangled but at least the csv reader would carry on and read the third line

[issue30034] csv reader chokes on bad quoting in large files

Changes by Mariatta Wijaya : -- components: +Library (Lib) nosy: +Mariatta ___ Python tracker ___

[issue30034] csv reader chokes on bad quoting in large files

New submission from Keith Erskine: If a csv file has a quote character at the beginning of a field but no closing quote, the csv module will keep reading the file until the very end in an attempt to close out the field. It's true this situation occurs only when the quoting in a csv file is

[issue29549] Improve docstring for str.index

Changes by Mariatta Wijaya : -- versions: -Python 2.7 ___ Python tracker ___ ___

[issue30032] email module creates base64 output with incorrect line breaks

R. David Murray added the comment: There is, however, an issue that if you pass a message with the default policy to the generator and specify SMTP as the policy, it doesn't *recode* the line endings. I thought there was an open issue for that, but I can't find it. One solution would be to

[issue30032] email module creates base64 output with incorrect line breaks

R. David Murray added the comment: Huh. I ran something like that test and thought I saw the reverse. I guess I misread my terminal. Looking at the code, set_content does take care to fix the line ending according to the policy before doing the encoding. -- resolution: -> out of

[issue30032] email module creates base64 output with incorrect line breaks

Jon Ribbens added the comment: So on further investigation, with the new API and policy=SMTP, it does generate correct base64 output. So I guess on the basis that the new version can generate the right output, and it appears to be a deliberate choice that the default policy breaks the RFCs,

[issue30033] email module base64-encodes utf-8 text

R. David Murray added the comment: The API exists in python3.5 and python3.4 as well, it was just provisional. Very few things changed between the provisional version and the final version in 3.6. -- ___ Python tracker

[issue30032] email module creates base64 output with incorrect line breaks

Changes by R. David Murray : -- components: +email ___ Python tracker ___ ___

[issue30032] email module creates base64 output with incorrect line breaks

Changes by R. David Murray : -- versions: -Python 2.7 ___ Python tracker ___ ___

[issue30032] email module creates base64 output with incorrect line breaks

R. David Murray added the comment: That is true for text/ types, yes. The policy is named after the target wire protocol, and if you are transmitting an email message over SMTP, that implies MIME. What to do if you are not sending it over SMTP, though, is a tougher question. One could

[issue29870] ssl socket leak

Alexander Mohr added the comment: yes, in the gist I created you can switch between the various clients, by default right now it uses raw sockets. -- ___ Python tracker

[issue30032] email module creates base64 output with incorrect line breaks

Jon Ribbens added the comment: OK cool, but please note that this is a MIME issue not an SMTP issue - if the message has text that is being base64-encoded then it must use CRLF line breaks regardless of whether SMTP is involved or not. -- ___

[issue30033] email module base64-encodes utf-8 text

Jon Ribbens added the comment: Just a note for anyone finding this in searching results: it appears that what David means by "python3 API" is actually a new API in Python 3.6 (email.message.EmailMessage). -- ___ Python tracker

[issue29870] ssl socket leak

Antoine Pitrou added the comment: I see. This may mean the leak is in memory that's not managed directly by Python (e.g. some OpenSSL structure). Is there a way to reproduce without third-party libraries such as requests? -- ___ Python tracker

[issue30032] email module creates base64 output with incorrect line breaks

R. David Murray added the comment: Actually, I think the fix would go in the generator, not in the contentmanager, but it's been long enough since I've worked on the code that I'm not sure. -- ___ Python tracker

[issue30032] email module creates base64 output with incorrect line breaks

R. David Murray added the comment: This appears to be a problem in the new API as well. I don't think we can change the legacy API because its been that way forever and applications might be depending on it (that is, the library preserves exactly what it is handed, and an application might

[issue29870] ssl socket leak

Alexander Mohr added the comment: @pitrou: sys.getallocatedblocks does not seem to increase -- ___ Python tracker ___

[issue30031] Improve queens demo (use argparse and singular form)

R. David Murray added the comment: Yeah, I was wondering if part of the demo was to show something that can be done with no library support...but that probably isn't the case. -- ___ Python tracker

[issue30033] email module base64-encodes utf-8 text

R. David Murray added the comment: Yes, this sub-optimal, but it's the way it works in the legacy API, and we aren't going to change the legacy (compat32) API at this point. The new policies and the new API in python3 handle this sensibly. -- resolution: -> out of date stage: ->

[issue30032] email module creates base64 output with incorrect line breaks

Changes by Serhiy Storchaka : -- components: +email nosy: +barry, r.david.murray ___ Python tracker ___

[issue30033] email module base64-encodes utf-8 text

Changes by Serhiy Storchaka : -- components: +email nosy: +barry, r.david.murray ___ Python tracker ___

[issue30031] Improve queens demo (use argparse and singular form)

Eric V. Smith added the comment: Oops, yes, __init__. Plenty of the demos use imports. I think it would be clearer with argparse, but I also don't feel strongly about it. -- ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Serhiy Storchaka added the comment: It is easy to implement this (just replace LOAD_ATTR with IMPORT_FROM in the compiler). The hardest part is writing tests. -- keywords: +easy (C) nosy: +serhiy.storchaka stage: -> needs patch ___ Python tracker

[issue30031] Improve queens demo (use argparse and singular form)

R. David Murray added the comment: I'm not sure about using argparse. Currently the demo uses no imports. I'm not strongly against, though. Did you mean __init__ instead of __new__? Also, its value could be made True and False instead of 0 and 1. (Which tells you how old this demo is.)

[issue30033] email module base64-encodes utf-8 text

New submission from Jon Ribbens: The email module, when creating text parts using character encoding utf-8, base64-encodes the output even though this is often inappropriate (e.g. if it is a Western language it is almost never appropriate). >>> from email.mime.text import MIMEText >>> m =

[issue30032] email module creates base64 output with incorrect line breaks

New submission from Jon Ribbens: The email module, when creating base64-encoded text parts, does not process line breaks correctly - RFC 2045 s6.8 says that line breaks must be converted to CRLF before base64-encoding, and the email module is not doing this. >>> from email.mime.text import

[issue29521] Minor warning messages when compiling documentation

Mariatta Wijaya added the comment: New changeset e0cba5b45a5c4bafd1ae772be52ca0d69651da24 by Mariatta in branch '2.7': [2.7] bpo-29521: Fix two minor documentation build warnings (GH-41) (GH-670) https://github.com/python/cpython/commit/e0cba5b45a5c4bafd1ae772be52ca0d69651da24 --

[issue30031] Improve queens demo (use argparse and singular form)

Eric V. Smith added the comment: I think these are reasonable improvements. Also, move the initialization of "silent" in to __new__. -- keywords: +easy nosy: +eric.smith ___ Python tracker

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Guido van Rossum added the comment: OK I won't close it but I'm withdrawing from the issue. If there are devs who want to implement this or mentor some contributor into implementing it feel free, but it sounds like Nick doesn't think it's important enough to fix (i.e. not worth his time) and

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

Serhiy Storchaka added the comment: Can you move forward this issue Victor? I'm very interesting in it. It is worth to advertise this API on Python-Dev. _PyArg_Parser also can utilize this API. -- ___ Python tracker

[issue30030] Simplify _RandomNameSequence

Serhiy Storchaka added the comment: The downside of this change: 1. The _RandomNameSequence iterator no longer has the rng field. But it isn't used in the stdlib. And since _RandomNameSequence is a private name, it shouldn't be used in third-party code. 2. The result of no longer copyable

[issue30031] Improve queens demo (use argparse and singular form)

New submission from Pavlo Kapyshin: Currently Tools/demo/queens.py: - does manual sys.argv parsing - says “Found 1 solutions” I propose to: 1) use argparse; 2) if q.nfound == 1, use “solution”. I you are ok with this, I’ll make a pull request. -- components: Demos and Tools

[issue29870] ssl socket leak

Antoine Pitrou added the comment: Can you record sys.getallocatedblocks() to see whether it grows continuously? -- nosy: +pitrou ___ Python tracker ___

[issue30028] make test.support.temp_cwd() fork-safe

Serhiy Storchaka added the comment: > os.getlogin document says `Availability: Unix, Windows.` Originally this meant "not in Mac OS, DOS, OS/2, VMS". But now the support of all these platforms is dropped and the note is outdated. -- ___ Python

[issue30030] Simplify _RandomNameSequence

Changes by Serhiy Storchaka : -- pull_requests: +1219 ___ Python tracker ___ ___

[issue30030] Simplify _RandomNameSequence

New submission from Serhiy Storchaka: _RandomNameSequence was added in issue589982 when generator functions were new optional feature. _RandomNameSequence is implemented as an iterator class. Proposed patch simplifies _RandomNameSequence by implementing it as a generator function. This is a

[issue29870] ssl socket leak

Changes by Michael Sghaier : -- pull_requests: +1218 ___ Python tracker ___ ___

[issue30028] make test.support.temp_cwd() fork-safe

INADA Naoki added the comment: > Oh. If os.getpid() is not always available, the documentation should be > updated. Yes, but CloudABI is not officially supported platform. They have many patches to run Python on CloudABI. https://github.com/NuxiNL/cloudabi-ports/tree/master/packages/python

[issue30028] make test.support.temp_cwd() fork-safe

STINNER Victor added the comment: Naoki: > #28156 added HAVE_GETPID check. > Maybe, we should have dummy getpid() for CloudABI? Oh. If os.getpid() is not always available, the documentation should be updated. -- ___ Python tracker

[issue30028] make test.support.temp_cwd() fork-safe

INADA Naoki added the comment: #28156 added HAVE_GETPID check. Maybe, we should have dummy getpid() for CloudABI? -- nosy: +inada.naoki ___ Python tracker

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

Segev Finer added the comment: It's been a while since this got any attention... -- ___ Python tracker ___

[issue30028] make test.support.temp_cwd() fork-safe

STINNER Victor added the comment: I proposed PR 1074 to remove the hasattr(os, 'getpid') from logging.LogRecord constructor. -- ___ Python tracker ___

[issue30028] make test.support.temp_cwd() fork-safe

Changes by STINNER Victor : -- pull_requests: +1217 ___ Python tracker ___ ___

[issue29694] race condition in pathlib mkdir with flags parents=True

Armin Rigo added the comment: Maybe we should review pathlib.py for this kind of issues and first apply the fixes and new tests inside PyPy. That sounds like a better way to get things done for these rare issues, where CPython is understandably reluctant to do much changes. Note that the

[issue29989] subprocess.Popen does not handle file-like objects without file descriptors

Changes by Terry J. Reedy : -- resolution: -> not a bug ___ Python tracker ___ ___

[issue30028] make test.support.temp_cwd() fork-safe

Serhiy Storchaka added the comment: Then LGTM. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue30028] make test.support.temp_cwd() fork-safe

Anselm Kruis added the comment: I had the same concerns about os.getpid(), but test.support uses it unconditionally in various places. See https://github.com/python/cpython/blob/master/Lib/test/support/__init__.py#L803 for an example. -- ___

[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

Nick Coghlan added the comment: Right, this problem only arises with import cycles, and that's why we resisted making eager submodule resolution work *at all* for so long (issue 992389 was filed way back in 2004). We only conceded the point (with issue 17636 being implemented for 3.5)

[issue30028] make test.support.temp_cwd() fork-safe

Christian Heimes added the comment: The line is from 2006. Some parts of the logging module are much older, maybe even from the time Python had DOS support. -- nosy: +christian.heimes ___ Python tracker