[Python-Dev] Issue #16153: PyUnicode_FromFormatV() must fail if the format string is invalid
Hi, Does anyone know if there is a good reason why PyUnicode_FromFormatV() does not fail on invalid format string, but copies the format string as-if into the result? I would like to change this to raise a ValueError instead. PyUnicode_FromFormatV() is used by PyErr_Format(), so PyErr_Format() may now fail with a ValueError if the format string is invalid. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
> The amount of code will not be reduced, but now you also need to guess what > file some piece of functionality may be in. How do you search a piece of code? If you search for a function by its name, it does not matter in which file it is defined if you an IDE or vim/emacs with a correct configuration. For example, I type ":tag PyUnicode_Format" to go to the PyUnicode_Format() function. > Instead of having my text editor > (Emacs) search in one file, it will have to search across multiple files - > but not across all open buffers, but only some of them (since I will have > many other source files open as well). Does it mean that it would be more practical to merge all C files into one unique file? > I really fail to see what problem people have with large source files. > What is it that you want to do that can be done easier if it's multiple > files? Another problem with huge files is to handle "dependencies" with static functions. If the function A calls the function B which calls the function C, you have to order A, B and C "correctly" if these functions are private and not declared at the top of the file. If functions are grouped correctly, you just lhave to add the function to the right file, or reorder the files. I also prefer short files beacuse it's easier to review/audit a small file. My brain cannot store too many functions :-) Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
2012/10/7 Victor Stinner : > Another problem with huge files is to handle "dependencies" with > static functions. If the function A calls the function B which calls > the function C, you have to order A, B and C "correctly" if these > functions are private and not declared at the top of the file. Having separate files doesn't alleviate this, though. If they're in separate files, you have to have header files of prototypes. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
On Mon, Oct 8, 2012 at 8:17 AM, Victor Stinner wrote: > Another problem with huge files is to handle "dependencies" with > static functions. If the function A calls the function B which calls > the function C, you have to order A, B and C "correctly" if these > functions are private and not declared at the top of the file. > > If functions are grouped correctly, you just lhave to add the function > to the right file, or reorder the files. This isn't a fundamental problem, since you can always declare a private function if it's mutually recursive with another private function. But - forgive me if this is false in CPython - this isn't usually that common. Also, ordering the functions in (at least an approximation of) Define Before Use makes it easy to locate the one you're calling, even in a non-smart editor: just go to the top of the file and search for the function's name; the first hit will be the definition. It's not usually difficult to sort functions appropriately, and can pay dividends in readability. ChrisA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
Zitat von Victor Stinner : The amount of code will not be reduced, but now you also need to guess what file some piece of functionality may be in. How do you search a piece of code? I type / in vim, or Ctrl-s (incremental search) in Emacs. If you search for a function by its name, it does not matter in which file it is defined if you an IDE or vim/emacs with a correct configuration. For example, I type ":tag PyUnicode_Format" to go to the PyUnicode_Format() function. I don't like tag files. I want to search in all source code (including comments and strings), and I want to do a substring search (not sure whether that is supported in tag files). Instead of having my text editor (Emacs) search in one file, it will have to search across multiple files - but not across all open buffers, but only some of them (since I will have many other source files open as well). Does it mean that it would be more practical to merge all C files into one unique file? That would be extreme, of course. It may cause problems with the responsiveness of the editor, and with compile times; it may also cause problems with merging in version control. In addition, there might be naming conflicts which make it impractical (e.g. many structures containing the same tp_* struct slots, so when you search for tp_new, for example, you would get too many hits). But in principle, I don't mind maintaining *very* large source files. unicodeobject.c isn't really *that* large. What is it that you want to do that can be done easier if it's multiple files? Another problem with huge files is to handle "dependencies" with static functions. If the function A calls the function B which calls the function C, you have to order A, B and C "correctly" if these functions are private and not declared at the top of the file. If functions are grouped correctly, you just lhave to add the function to the right file, or reorder the files. I don't understand. Do you envision that A, B, and C are in separate files? If so, they cannot be all static anymore, unless you still combine all files with #include directives, or unless you put them still all in the same file. I don't see how multiple files gives any improvement. It seems to make matters worse: - if you put A, B, C in the same file, you have the same issue that you had when unicodeobject.c was a large file - you have to order them "correctly". - if you put them in different files, it gets worse: you need to place A in a file that gets included after the file that has B, even if it would be more logical to put them reverse. I also prefer short files beacuse it's easier to review/audit a small file. My brain cannot store too many functions :-) This is what I don't understand. Why do you have to remember all functions when reviewing or auditing a file? You can safely ignore all functions but the one you are reviewing - whether the other functions are in a different file or in the same file. Why can you ignore the functions only if they are stored in a different file? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 8492 [was Re: [Python-dev] History stepping in interactive session?]
Over on python-ideas, a question about readline was raised and, I think, resolved. But while investigating the question, it became obvious to me that the ability to inspect the current readline bindings from Python was both useful and important. I wrote: I don't believe that there is any direct mechanism for querying the current readline bindings in Python, But it was requested some time ago: http://bugs.python.org/issue8492 Is there anyone willing and able to give this issue some attention please? (Replies to python-dev only please.) -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
