[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: As far as I can recall, the patch is generally speaking good to go. A number of discussions arose on various details, however. In any event, I'll take a look at it during the next few days. -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: I have actually managed to lost my local branch of this fix, though I assume I can just start another one, manually copy over the changes, somehow mark this current PR as cancelled, aborted, or in my option the best: "replaced/superseeded by: [new PR]". In any case, there were discussions that seem to be unresolved, allow me to summarize: * Document that index() raises ValueError when *value* is not found? > vstinner: We don't do this, remove this addition. > serhiy: Other index() methods does this. ---> My patch current does this. Who has final saying here? * 'start' and 'stop' arguments are not keyword arguments, and also not shown in the signature as '.. start=0 ..' for this very reason (it may make them look as keyword arguments). Also, this lines up with list.index() for consistency. Wishes about changing this for all index()-methods has been expressed, but it seems to be consensus on doing this in unison for all index()-methods at once, in a bigger change... So, what is currently in the PR is good enough for now, or? * Wording in documentation: Clarify that "the returned index is still relative to the start of the array, not the searched sub sequence" or not? * Comment in the code about checking the length of the array on each iteration? There were comments about it being "confusing" - and while I agree, the other index()-code for lists, does not comment on this. Again I followed the path of most consistency, but I did receive comments about this. Yes to descriptive comments, or not? Generally speaking: In the end, all I really did was mimic how list.index() is both written and documented, and that's when discussions about issues related to that started occurring, and so I now remember that I halted my PR, waiting for these issues to be resolved. -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38673] REPL shows continuation prompt (...) when comment or space entered
Anders Lorentsen added the comment: As a person without much experience, it sounded like a simple enough task, but having dug a bit, I found it quite complicated. It seems to me that the interpreter loop (in the standard REPL, that you get when you start ./python, blocks for input somewhere inside a massive function called 'parsetok' (in Parser/parsetok.c). Now, I could maybe investigate further, to have it return to the interpreter loop if it reads a comment (or empty line), but I'm afraid to mess up something. >From my understanding, there aren't that many other choices, because >parsetok() doesn't return before you finish the statement (in other words, it >does not return if you type a comment line or a blank line - it instead waits >for more input, as indicated by the '... '). Am I way off in concluding that this would be a change to the parser? -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue38673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: This is strange, because _execute_child calls os.fsdecode with `args` as the argument, which may be a list. os.fsdecode calls fspath. Now, the python docstring of _fspath, as defined in Lib/os.py on line 1031, clearly states that it will raise a TypeError if the argument is not of type bytes, str or is a os.PathLike object, and that's probably why I wrote the initial code the way I did (catching TypeError from os.fsdecode). Doesn't the try-except block actually catch this TypeError? I don't understand off the top of my head why my code doesn't catch this exception.. -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: Also, isn't there continuous integration testing? Everything passed on the PR, so where does this come from? -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: Wait a minute. The failing test is test_nonexisting_with_pipes, and it fails because args[0] is a tuple - how can that be? Nobody is supposed to pass cmd=sequence-where-first-element-is-a-tuple! Is everything all right with the test itself? -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: > # runs this weird file > subprocess.run([bin]) > # Currently an error; if this is implemented, would run > # /bin/ls, and pass it the -l argument. Refers to something > # completely different than our .exists() call above. I do not understand where it is stated that this is the behavior. My understanding was that if run() is passed a single argument, it will interpret the string "/bin/ls -l" to mean "run the `/bin/ls` program, and pass it one argument `-l`, whereas if instead run() is given a list, it will literally treat the first element as the program to run, regardless of how many spaces or whatever else it contains ... And as such, if `bin` is a Path-like object, this issue tries to resolve that run([bin]) works as excepted, but run(bin) fails horribly. Sure, I can understand that for strings it may not feel natural how these two things are interpreted differently, but if `bin` is a Path-like object, it at least feels very natural to me that then it should be run as the program name itself (as "paths" does not have arguments). -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: What do you mean "is a bug", and "the PR would encourage this"? Can't it be fixed? Are you saying that just because it is a bug now, we should be discouraged from making it work in the way you'd expect it to work? If `exe` is a path, these two lines of code should do exactly the same, right? It seems unintuitive to me if they produce different results. run(exe) run([exe]) -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31843] sqlite3.connect() should accept PathLike objects
Anders Lorentsen added the comment: Had my first go at a python patch. Added a test case for it, and all tests passing when I test with `./python -bb -E -Wd -m test -v test.test_sqlite -r -w -uall -R 3:2` -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue31843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: I was able to make a test that reproduces your code, and expectedly fails. Also implemented a fix for it. See a temporary diff here: https://pastebin.com/C9JWkg0i However, there is also a specific MS Windows version of _execute_child() (a phrase only computer-folks can say out loud without feeling very...wrong...). It uses a different method to extract and parse arguments, and it should be corrected and tested under windows, before I submit a PR for this. Also, my test messes up the formatting. Instead of saying "ok", they both say "... total 0\nok". I have no idea why. -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: While researching this, I discovered that on MS Windows >>> subprocess.run([pathlike_object, additional_arguments]) did not run like it did on Posix. My PR includes this problem and it's fix. -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: I decided to work on this, and I would like some review, as this would be my second contribution to cpython. Also, a general question: As I defined the start and end arguments Py_ssize_t, bigger indexes (more negative or more positive) than what can fit in Py_ssize_t will trigger an overflow error. This should be OK, though, as other functions with index arguments has them as Py_ssize_t - and getarrayitem() itself accepts a Py_ssize_t. Or? -- nosy: +Phaqui Added file: https://bugs.python.org/file47261/WIP-issue-31956 ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: Writing my tests, I originally looked at Lib/test/seq_tests.py. One test case uses indexes that are (+-)4*sys.maxsize. This does not fit in Py_ssize_t, and so these tests cause my array implementation to raise an overflow exception. A solution is of course to have the function take general objects instead, and then truncate them down to a number that can fit in Py_ssize_t if it's too negative or positive). But I concur. It seems more reasonable to stay consistent with the rest of the module, too. I'll look over the test code to make sure I test for every given scenario (or as many as I can think of), and prepare a PR for this, then :) -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero
Changes by Anders Lorentsen : -- nosy: +Phaqui ___ Python tracker <http://bugs.python.org/issue27623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero
Anders Lorentsen added the comment: Isn't it possible to just add a small line of code that checks if length is less than or equal to 0, and if it is, call the necessary c functions to have python raise a valueerror...? Sorry if this is giving a solution without actually submitting the patch - but this is all very new to me. I have never contributed to anything yet (fourth year CS-student), and I am as fresh to the process as can be. I registered here just now. This seems like an issue I could handle.. I just need to take the time to learn about the process of how things are done around here. -- ___ Python tracker <http://bugs.python.org/issue27623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero
Anders Lorentsen added the comment: So, am I to understand that the only corner case we should fix is that >>> (-1).to_bytes(0, 'big', signed=True) should raise an overflow error (currently it returns b'') ? -- Added file: http://bugs.python.org/file43925/int_to_bytes_overflow_cornercase.patch ___ Python tracker <http://bugs.python.org/issue27623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero
Anders Lorentsen added the comment: I updated my patch to account for that second corner case. But ideally, shouldn't it rather be accounted for in the function that does the actual conversion, that is, in _PyLong_AsByteArray? -- Added file: http://bugs.python.org/file43942/int_to_bytes_overflow_cornercase2.patch ___ Python tracker <http://bugs.python.org/issue27623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
