[issue34106] Add --with-module-config= to 'configure' script

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +7804 ___ Python tracker <https://bugs.python.org/issue34106> ___ ___ Python-bugs-list mailin

[issue28643] Broken makefile depends for profile-opt target

Neil Schemenauer added the comment: Closing this as the current makefile works much better in this regard, at least based on my experience. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue31342] test.bisect module causes tests to fail

Neil Schemenauer added the comment: This is still broken, IMHO. Either we should rename test.bisect or we should remove all of the 'if __name__ == "__main__"' part of the test scripts. You can't run the tests reliably as scripts anymore. Doing so puts Lib/t

[issue31342] test.bisect module causes tests to fail

Neil Schemenauer added the comment: Yes, it looks like the same issue as bpo-29512. Renaming test.bisect is the simplest solution. I have trained myself to run "python -m test.regrtest " so this issue doesn't affect me any more. However, I think it was a trap that will ca

[issue34690] Store startup modules as C structures for 20%+ startup speed improvement

Neil Schemenauer added the comment: I commented on python-dev but maybe it is better to keep discussion here. Could we make the frozenmodules thing into a dynamically loaded module? Then you could have support for end users making their own. E.g. a command-line param that lists a set of

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

Neil Schemenauer added the comment: I would suggest that sharing of objects between interpreters should be stamped out. Could we have some #ifdef debug checking that would warn or assert so this doesn't happen? I know currently we share a lot of objects. However, in the long term,

[issue26979] The danger of PyType_FromSpec()

Change by Neil Schemenauer : -- nosy: +nascheme ___ Python tracker <https://bugs.python.org/issue26979> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34704] Do not access ob_type directly, introduce Py_TP

New submission from Neil Schemenauer : My long term goal is to make it possible to make PyObject an opaque structure. Obviously that would break nearly every 3rd party extension at this point. However, to allow freedom on certain interpreter implementation strategies, it is helpful if code

[issue34704] Do not access ob_type directly, introduce Py_TP

Change by Neil Schemenauer : -- pull_requests: +8767 ___ Python tracker <https://bugs.python.org/issue34704> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32892] Remove specific constant AST types in favor of ast.Constant

Neil Schemenauer added the comment: As someone who does AST manipulation (Quixote PTL template support), I'm interested in this patch. I think what is proposed sounds like a good change. I.e. having the extra node types is not useful and makes the compiler harder to understand. Prov

[issue32892] Remove specific constant AST types in favor of ast.Constant

Neil Schemenauer added the comment: I've checked Quixote PTL module support. I will have to make some changes to support the removal of Str and other node types. E.g. I have to change visit_Str to visit_Constant. The fixes are pretty easy though and I think it is reasonable that

[issue34801] codecs.getreader() splits lines containing control characters

New submission from Neil Schemenauer : This seems to be a bug in codecs.getreader(). io.TextIOWrapper(fp, encoding) works correctly. -- files: codecs_bug.py messages: 326382 nosy: nascheme priority: low severity: normal status: open title: codecs.getreader() splits lines containing

[issue34880] About the "assert" bytecode

Neil Schemenauer added the comment: Assuming it is not crazy complicated to fix, I would like to to be changed. It should work like the TypeError example. That fact that it has worked the current way since Python 1.5 isn't a strong argument. I think no one should be surprised

[issue34822] Simplify AST for slices

Neil Schemenauer added the comment: Hello Serhiy, I've not reviewed the patch but I trust that if you say it simplifies things, that's so. Perhaps the important question is if it is okay to change the AST in backwards incompatible ways within 3.x releases. As a library author

[issue34867] Add mode to disable small integer and interned string caches

Neil Schemenauer added the comment: Woudn't turning these off hurt performance a lot? If so, I don't know if people would actually use such a mode. Then it becomes pretty useless. Could we combine this idea with the PYTHONDEVMODE flag? If PYTHONDEVMODE is turned on, we could

[issue34850] Emit a syntax warning for "is" with a literal

Neil Schemenauer added the comment: > The problem with a SyntaxWarning is that the wrong people will see it. It > gets in the way of users of applications that happen to be written in Python. Turn the check on only when PYTHONDEVMODE is set? Seems like it solves the issue with the

[issue34801] codecs.getreader() splits lines containing control characters

Neil Schemenauer added the comment: Thank you for the research. The problem is indeed that \v is getting treated as a line separator. That is an intentional design choice, see: https://bugs.python.org/issue12855 It would seem to have some surprising implications for CSV parsing. E.g. if

[issue34801] codecs.getreader() splits lines containing control characters

Neil Schemenauer added the comment: Perhaps the 'csv' module should do some sanity checking on the file passed to the reader. The docs recommend that newline='' be used to open the file. Maybe 'csv' could check that and warn if its not the case. I poked arou

[issue30825] csv.Sniffer does not detect lineterminator

Neil Schemenauer added the comment: There is another issue related to this. If you use codecs to get a reader, it uses str.splitlines() internally, which treats a bunch of different characters as line terminators. See issue #18291 and: https://docs.python.org/3.8/library/stdtypes.html

[issue18291] codecs.open interprets FS, RS, GS as line ends

Neil Schemenauer added the comment: I think one bug here is that codecs readers use str.splitlines() internally. The splitlines method treats a bunch of different characters as line separators, unlike io..readlines(). So, you end up with different behavior between doing iter

[issue18291] codecs.open interprets FS, RS, GS as line ends

Neil Schemenauer added the comment: Attached is a rough patch that tries to fix this problem. I changed the behavior in that unicode char 0x2028 is no longer treated as a line separator. It would be trival to change the regex to support that too, if we want to preserve backwards

[issue18291] codecs.open interprets FS, RS, GS as line ends

Neil Schemenauer added the comment: Some further progress on this. My patch slows down reading files with the codecs module very significantly. So, I think it could never be merged as is. Maybe we would need to implement an alternative str.splitlines that behaves as we want, implemented

[issue18291] codecs.open interprets FS, RS, GS as line ends

Neil Schemenauer added the comment: New patch that changes str.splitlines to work like Python 2 str.splitlines and like Python 3 bytes.splitlines. Surprisingly, only a few cases in the unit test suite fail. I've fixed them in my patch. -- Added file: https://bugs.pytho

[issue18291] codecs.open interprets FS, RS, GS as line ends

Neil Schemenauer added the comment: I just found bug #22232 myself but thanks for pointing it out. > changing the behavior unconditionally is not an option At this point, I disagree. If I do a search on the web, lots of pages referring to str.splitlines() seem it imply that is splits o

[issue22232] str.splitlines splitting on non-\r\n characters

Neil Schemenauer added the comment: If we introduce a keyword parameter, I think the default of str.splitlines() should be changed to match bytes.splitlines (and match Python 2 str.splitlines()). I.e. split on \r and \n by default. I looked through the stdline and I can't find any

[issue22232] str.splitlines splitting on non-\r\n characters

Neil Schemenauer added the comment: I've created a topic on this inside the "Ideas" area of discuss.python.org. Sorry if that wasn't appropriate, not sure if I should have keep the discussion here. Inada Naoki suggests creating a new method str.iterlines{[keepends]).

[issue22232] str.splitlines splitting on non-\r\n characters

Neil Schemenauer added the comment: > Why not simply add a new parameter, to make people who want ASCII linebreaks > continue to use .splitlines() ? That could work but I think in nearly every case you don't want to use splitlines() without supplying the parameter. So, it seems

[issue22232] str.splitlines splitting on non-\r\n characters

Neil Schemenauer added the comment: I too would prefer a new method name rather than overloading splitlines() with more keyword args (passed as hardcoded constants, usually). Again, I think we want: list(open(..).read().()) == list(open(..)) readlines() returns a list but I think this

[issue812369] module shutdown procedure based on GC

Neil Schemenauer added the comment: It's been quite a long time since I played with this patch so my memory might be a bit fuzzy. As I recall, it sounds good in theory but in practice it doesn't really work. One of the core problems is that many extension modules keep references

[issue20284] proof for concept patch for bytes formatting methods

New submission from Neil Schemenauer: This is a very rough, proof of concept patch that implements %-style formatting for bytes objects. Currently it calls __format__ with a bytes argument and expects a bytes result. I've only implemented support for bytes formatting for the 'lo

[issue20284] proof for concept patch for bytes formatting methods

Neil Schemenauer added the comment: I'm attaching v2 of my proposed patch. This one is quite a bit better, IMHO. - Introduce __ascii__ as a special method, like __str__ but required to exist only if an ASCII-only format exists. - Extract PyString_Format from Python 2.7 and update i

[issue20284] proof for concept patch for bytes formatting methods

Neil Schemenauer added the comment: Uploading new patch with the following changes: - Allow length 1 bytes object as argument to %c. - Make %r an alias for %a. I will upload a draft PEP (proposed as a replacement for 461). Victor, thanks for the review. My reply is: - regarding duplicated

[issue20284] proof for concept patch for bytes formatting methods

Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33507/pep-draft.txt ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bugs-list m

[issue20284] patch to implement %-interpolation for bytes (roughly PEP 461)

Neil Schemenauer added the comment: Another revision of the patch, now quite close to PEP 461 as proposed. Changes from PEP 461: - include %a - add -2 command-line flag. When enabled have %s fallback to calling PyObject_Str() and encoding to ASCII and also enable %r as alias for %a

[issue20284] patch to implement %-interpolation for bytes (roughly PEP 461)

Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33501/bytes_mod.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement %-interpolation for bytes (roughly PEP 461)

Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33505/bytes_mod_v2.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement %-interpolation for bytes (roughly PEP 461)

Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33506/bytes_mod_v3.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement %-interpolation for bytes (roughly PEP 461)

Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33516/bytes_mod_v4.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement PEP 461 (%-interpolation for bytes)

Neil Schemenauer added the comment: I've updated my patch into a sequence, the first of which implements PEP 461. 02-code-a.patch adds support for %a (ascii() on arg) 03-py2-flag.patch makes %s and %r behave similar to Python 2 if a command line flag is provided to the interpreter

[issue20284] patch to implement PEP 461 (%-interpolation for bytes)

Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33575/02-code-a.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement PEP 461 (%-interpolation for bytes)

Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33576/03-py2-flag.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20284] patch to implement PEP 461 (%-interpolation for bytes)

Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33577/04-py2-eq.patch ___ Python tracker <http://bugs.python.org/issue20284> ___ ___ Python-bug

[issue20339] Make bytes() use tp_as_buffer for cmp

New submission from Neil Schemenauer: While poking around at bytes() related things, I noticed that the tp_richcompare method for bytes does not use the tp_as_buffer interface. Making it use it is quite easy, probably even makes the code simpler

[issue6855] ihooks support for relative imports

New submission from Neil Schemenauer : ihooks in 2.6 does not support relative imports. The attached patch was impired by Brett's "import in Python" code. -- assignee: brett.cannon components: Library (Lib) files: ihooks_relimport.txt messages: 92345 nosy: brett.c

[issue1754094] Tighter co_stacksize computation in stackdepth_walk

Neil Schemenauer added the comment: Committed to the Python 2.x and 3.x trunks. -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/iss

[issue6855] ihooks support for relative imports

Neil Schemenauer added the comment: I've been using this version of ihooks for some time and it seems to work fine. Committing the patch. -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___

[issue4152] ihooks module cannot handle absolute imports

Neil Schemenauer added the comment: Fixed in SVN rev 75423. -- nosy: +nascheme resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue1101399] dict subclass breaks cPickle noload()

Neil Schemenauer added the comment: Applied to 2.x trunk. The 3.x version _pickle.c doesn't have the noload method. -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.or

[issue812369] module shutdown procedure based on GC

Neil Schemenauer added the comment: It should fix issue1545463 and running a quick test seems to show that it does. -- ___ Python tracker <http://bugs.python.org/issue812

[issue4698] Solaris buildbot failure on trunk in test_hostshot

Neil Schemenauer added the comment: I checked in the fix on the 2.6 branch. -- ___ Python tracker <http://bugs.python.org/issue4698> ___ ___ Python-bugs-list m

[issue4152] ihooks module cannot handle absolute imports

Neil Schemenauer added the comment: Adding a patch that adds support for relative imports based on the import.c code. I've tested it by hacking the test_import.py test module. -- versions: +Python 2.7 Added file: http://bugs.python.org/file14132/ihooks_relativ

[issue9109] absolute import cleanups for Python 3

New submission from Neil Schemenauer : It looks like there is a bunch of legacy relative import cruft kicking around in Python 3. The first thing I noticed is that __import__.__doc__ claims that level=-1 is the default (i.e. use the Python 2 behavior). A little testing shows that the docs

[issue9109] absolute import cleanups for Python 3

Changes by Neil Schemenauer : -- assignee: -> brett.cannon nosy: +brett.cannon -nas ___ Python tracker <http://bugs.python.org/issue9109> ___ ___ Python-

[issue4151] Separate build dir broken

Neil Schemenauer added the comment: I believe the latest problem reported has been fixed by SVN rev 80649. -- assignee: -> nascheme nosy: -nas stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/

[issue28907] test_pydoc fails if build is in sub-directory

New submission from Neil Schemenauer: test_pydoc is failing for me for 3.6rc1. I build in a sub-directory, e.g. Python-3.6.0rc1/build-opt. The root of the issue is that pydoc getdocloc() is broken. It cannot build 'basedir' as it does and assume that is the location of standa

[issue28908] pydoc getdocloc() is broken

New submission from Neil Schemenauer: The getdocloc() method in pydoc.py is supposed to return the doc location for modules. It uses a 'basedir' parameter that is supposed to point to the location of the standard library modules. That logic is broken for a number of different sc

[issue28908] pydoc getdocloc() is broken

Neil Schemenauer added the comment: Attached is a first pass at the idea of just keeping a list of standard modules that have docs. I generated the list with: $ (cd Doc/library; ls *.rst | sed 's/.rst//') Probably that should be incorporated into the Doc/Makefile somehow. Perhaps

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: This looks to be a good idea and a good time to merge it now the bytecode has changed to 16-bit. The increase in complexity to compile.c is not bad and reducing the complexity of the eval loop is worth it, IMHO. -- nosy: +nascheme

[issue27377] Add smarter socket.fromfd()

New submission from Neil Schemenauer: When implementing server software that inherits a socket via a file descriptor, it is useful to be able to query the descriptor and find out what kind of socket has been passed. This can be done with getsockopt() and getsockname(). Python does not

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Add documentation for new functions. -- Added file: http://bugs.python.org/file43524/fromfd2.txt ___ Python tracker <http://bugs.python.org/issue27

[issue27377] Add smarter socket.fromfd()

Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file43523/fromfd2.txt ___ Python tracker <http://bugs.python.org/issue27377> ___ ___ Python-bugs-list m

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Thank you for the excellent review Martin. I'm attaching a new patch which I think addresses your points. I created it from hg, maybe that works nicer. I've added constants for SO_DOMAIN, SO_PROTOCOL, SO_PASSCRED, SO_PEERSEC, and SO_PASS

[issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general

Neil Schemenauer added the comment: I've created a patch to add fromfd2(). I think it addresses the original concern of this issue. My patch also adds the constants suggested by Issue #26907. -- nosy: +nascheme ___ Python tracker

[issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general

Neil Schemenauer added the comment: Sorry, forgot to link the patch: Issue #27377. -- ___ Python tracker <http://bugs.python.org/issue18391> ___ ___ Python-bug

[issue26907] Add missing getsockopt constants

Neil Schemenauer added the comment: Issue #27377 adds these constants. -- nosy: +nascheme ___ Python tracker <http://bugs.python.org/issue26907> ___ ___ Python-bug

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: I've revised the patch based on the second round of comments from Martin. I've removed the ifdef test for CO_TYPE and assumed it is always available. That means fdtype() should be available on all platforms. I did not change the test as suggest

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Adding yet another revised patch. I think this is ready to commit, if someone would like to do it. The documentation for constants can be added as a separate commit, if Martin wants. I think the generic SO_* style documentation is okay. Changes in this

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: I just tested on Windows. fdtype() fails with: OSError: [WinError 10022] An invalid argument was supplied The getsockname() call fails with WSAGetLastError() == 10022. getsockname() is used to find the address family. Perhaps there is some other way to

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Updated patch, v5. Disable fdtype() function on Windows. Fix documentation nits as suggested by review of v4. -- Added file: http://bugs.python.org/file43722/fromfd2_v5.txt ___ Python tracker <h

[issue27377] Add smarter socket.fromfd()

Neil Schemenauer added the comment: Tested on FreeBSD 10.3. getsockname() on a IPPROTO_SCTP protocol socket returns errno = FileNoFoundError. We could just comment out that test I guess. My theory is that on FreeBSD, getsockname() on an SCTP socket fails if it is not bound. Indeed, adding

[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)

Neil Schemenauer added the comment: I don't see how that patch can be correct. The logic is now if the directory has two links inside it then skip it. The filesystems that don't count '.' and '..' will have zero links when empty and will have two links when two

[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)

Neil Schemenauer added the comment: So what happens for the filesystems that doesn't count '.' and '..'? It looks to me like if there are exactly two messages in a folder then the revised code will return [] (i.e. it will think the folder is empty). Probably we sho

[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)

Neil Schemenauer added the comment: Okay, feel free to close this bug. I had heard that HFS+ counts files but I don't have a way to verify that. -- ___ Python tracker <http://bugs.python.org/i

[issue28643] Broken makefile depends for profile-opt target

New submission from Neil Schemenauer: I notice that after running "make" then running "make install", the build will go through the whole compile/profile/compile process again. This is really infuriating behaviour, given the extremely long make time for the profiled o

[issue28643] Broken makefile depends for profile-opt target

Neil Schemenauer added the comment: Okay, my initial idea was wrong (I blame years of not having to look at Makefiles). I think the attached patch works. It uses a "stamp" file to record the fact that the profiled build is complete. The fix is sub-optimal because changing some s

<    1   2   3   4