Python-ideas

python-ideas@python.org

25 participants
4603 discussions

by Antonio Cavallo

Hi is there any interest (or anyone has done it before), building the python interpreter using docker? The basic idea is building the toolchain (gcc) and on top of that the python interpreter. On mac/linux it can build natively, but it can use docker to target linux from mac/windows. Thanks

4 hours, 50 minutes

Explicitly defining a string buffer object (aka StringIO += operator)

by Paul Sokolovsky

Hello, 1. Intro -------- It is a well-known anti-pattern to use a string as a string buffer, to construct a long (perhaps very long) string piece-wise. A running example is: buf = "" for i in range(50000): buf += "foo" print(buf) An alternative is to use a buffer-like object explicitly designed for incremental updates, which for Python is io.StringIO: buf = io.StringIO() for i in range(50000): buf.write("foo") print(buf.getvalue()) As can be seen, this requires changing the way buffer is constructed (usually in one place), the way buffer value is taken (usually in one place), but more importantly, it requires changing each line which adds content to a buffer, and there can be many of those for more complex algorithms, leading to a code less clear than the original code, requiring noise-like changes, and complicating updates to 3rd-party code which needs optimization. To address this, this RFC proposes to add an __iadd__ method (i.e. implementing "+=" operator) to io.StringIO and io.BytesIO objects, making it the exact alias of .write() method. This will allow for the code very parallel to the original str-using code: buf = io.StringIO() for i in range(50000): buf += "foo" print(buf.getvalue()) This will still require updates for buffer construction/getting value, but that's usually 2 lines. But it will leave the rest of code intact, and not obfuscate the original content construction algorithm. 2. Performance Discussion ------------------------- The motivation for this change (of promoting usage of io.StringIO, by making it look&feel more like str) is performance. But is it really a problem? Turns out, it is such a pervasive anti-pattern, that recent versions on CPython3 have a special optimization for it. Let's use following script for testing: --------- import timeit import io def string(): sb = u"" for i in range(50000): sb += u"a" def strio(): sb = io.StringIO() for i in range(50000): sb.write(u"a") print(timeit.timeit(string, number=10)) print(timeit.timeit(strio, number=10)) --------- With CPython3.6 the result is: $ python3.6 str_iadd-vs-StringIO_write.py 0.03350826998939738 0.033480543992482126 In other words, there's no difference between usage of str vs StringIO. But it wasn't always like that, with CPython2.7.17: $ python2.7 str_iadd-vs-StringIO_write.py 2.10510993004 0.0399420261383 But Python2 is dead, right? Ok, let's see how Jython3 and IronPython3 fair. To my surprise, there're no (public releases of) such. Both projects sit firmly in the Python2 territory. So, let's try them: $ java -jar jython-standalone-2.7.2.jar str_iadd-vs-StringIO_write.py 10.8869998455 1.74700021744 Sadly, I wasn't able to get to run IronPython.2.7.9.zip on my Linux system, so I used the online version at https://tio.run/#python2-iron (after discovering that https://ironpython.net/try/ is dead). 2.7.9 (IronPython 2.7.9 (2.7.9.0) on Mono 4.0.30319.42000 (64-bit)) 26.2704391479 1.55628967285 So, it seems that rumors of Python2 being dead are somewhat exaggerated. Let's try a project which tries to provide "missing migration path" between Python2 and Python3 - https://github.com/naftaliharris/tauthon Tauthon 2.8.1+ (heads/master:7da5b76f5b, Mar 29 2020, 18:05:05) $ tauthon str_iadd-vs-StringIO_write.py 0.792158126831 0.0467159748077 Whoa, tauthon seems to be faithful to its promise of being half-way between CPython2 and CPython2. Anyway, let's get back to Python3. Fortunately, there's PyPy3, so let's try that: $ ./pypy3.6-v7.3.0-linux64/bin/pypy3 str_iadd-vs-StringIO_write.py 0.5423258490045555 0.01754526497097686 Let's not forget little Python brothers and continue with MicroPython 1.12 (https://github.com/micropython/micropython): $ micropython str_iadd-vs-StringIO_write.py 41.63419413566589 0.08073711395263672 Pycopy 3.0.6 (https://github.com/pfalcon/pycopy): $ pycopy str_iadd-vs-StringIO_write.py 25.03198313713074 0.0713810920715332 I also wanted to include TinyPy (http://tinypy.org/) and Snek (https://github.com/keith-packard/snek) in the shootout, but both (seem to) lack StringIO object. These results can be summarized as follows: of more than half-dozen Python implementations, CPython3 is the only implementation which optimizes for the dubious usage of an immutable string type as an accumulating character buffer. For all other implementations, unintended usage of str incurs overhead of about one order of magnitude, 2 order of magnitude for implementations optimized for particular usecases (this includes PyPy optimized for speed vs MicroPython/Pycopy optimized for small code size and memory usage). Consequently, other implementations have 2 choices: 1. Succumb to applying the same mis-optimization for string type as CPython3. (With the understanding that for speed-optimized projects, implementing mis-optimizations will eat into performance budget, and for memory-optimized projects, it likely will lead to noticeable memory bloat.) 2. Struggle against inefficient-by-concept usage, and promote usage of the correct object types for incremental construction of string content. This would require improving ergonomics of existing string buffer object, to make its usage less painful for both writing new code and refactoring existing. As you may imagine, the purpose of this RFC is to raise awareness and try to make headway with the choice 2. 3. Scope Creep, aka "Possible Future Work" ------------------------------------------ The purpose of this RFC is specifically to propose to apply *single* simple, obvious change. .__iadd__ is just an alias for .write, period. However, for completeness, it makes sense to consider both alternatives and where the path of adding "str-like functionality" may lead us. 1. One alternative to patching StringIO would be to introduce a completely different type, e.g. StringBuf. But that largely would be "creating more entities without necessity", given that StringIO already offers needed buffering functionality, and just needs a little touch of polish with interface. If 2 classes like StringIO and StringBuf existed, it would be extra quiz to explain difference between them and why they both exist. 2. On the other hand, this RFC fixates on the output buffering. But just image how much fun can be done re: input buffers! E.g., we can define "buf[0]" to have semantics of "tmp = buf.tell(); res = buf.read(1); buf.seek(tmp); return res". Ditto for .startswith(), etc., etc. So, well... This RFC is about making .__iadd__ to be an alias for .write, and cover with this output buffering usecase. Whoever may have interest in dealing with input buffer shortcuts would need to provide a separate RFC, with separate usecases and argumentation. 4. (Self-)Criticism and Risks. ------------------------------ 1. The biggest "criticism" I see is a response a-la "there's no problem with CPython3, so there's nothing to fix". This is related to a bigger questions "whether a life outside CPython exists", or put more formally, where's the border between Python-the-language and CPython-the-implementation. To address this point, I tried to collect performance stats for a pretty wide array of Python implementations. 2. Another potential criticism is that this may open a scope creep to add more str-like functionality to classes which classically expose a stream interface. Paragraph 3.2 is dedicated specifically to address this point, by invoking hopefully the best-practice approach: request to focus on the currently proposed feature, which requires very little changes for arguably noticeable improvements. (At the same time, for an abstract possibility of this change to be found positive, this may influence further proposals from interested parties). 3. Implementing the required functionality is pretty easy with a user subclass: class MyStringBuf(io.StringIO): def __iadd__(self, s): self.write(s) return self Voila. The problem is performance. Calling such .__iadd__() method implementing in Python is 3 times slower than calling .write() directly (with CPython3.6). But paradigmatic problem is even bigger: this RFC seeks to establish the best practice of using explicitly designed for the purpose type with ergonomic interface. Saying that "we lack such clearly designated type out of the box, but if you figure out that it's a problem (if you do figure that out), you can easily resolve that on your side, albeit with a performance hit when compared with it being provided out of the box" - that's not really welcoming or ergonomic. 5. Prior Art ------------ As many things related to Python, the idea is not new. I found thread from 2006 dedicated to it: https://mail.python.org/pipermail/python-list/2006-January/403480.html (strangely, there's some mixup in archives, and "thread view" shows another message as thread starter, though it's not: https://mail.python.org/pipermail/python-list/2006-January/357453.html) . The discussion there seemed to be without clear resolution and has been swamped into discussion of unicode handling complexities in Python2 and implementation details of "StringIO" vs "cStringIO" modules (both of which were deprecated in favor of "io"). -- Best regards, Paul mailto:pmiscml@gmail.com

6 hours, 44 minutes

Compound with .. else statement

by Jimmy Thrasibule

Hi, In Python, there are multiple [compound statements](https://docs.python.org/3/reference/compound_stmts.html) with the `else` keyword. For example: ``` for x in iterable: if x == sentinel: break else: print("Sentinel not found.") ``` or: ``` try: do_something_sensitive() except MyError: print("Oops!") else: print("We're all safe.") ``` In my situation, I would like to mix the `with` statement with `else`. In this case I would like that if no exception is raised within the `with` to run the `else` part. For example: ``` with my_context(): do_something_sensitive() else: print("We're all safe.") ``` Now imagine that in my `try .. except` block I have some heavy setup to do before `do_something_sensitive()` and some heavy cleanup when the exception occurs. I'd like my context manager to do the preparation work, execute the body, and cleanup. Or execute my else block only if there is no exception. Is there already a way to accomplish this in Python or can this be a nice to have? Regards, Jimmy

6 hours, 50 minutes

Changing Package Representation On Shell

by Abdur-Rahmaan Janhangeer

After a question i asked on python-list, Let's say i have a package. >>> import package >>> package <module 'package' from '<path>'> would it be nice to be able to change the repr of the package to >>> package package something some message .... ? Thanks! Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com <https://www.compileralchemy.com> | github <https://github.com/Abdur-rahmaanJ/> Mauritius

12 hours, 7 minutes

Re: Explicitly defining a string buffer object (aka StringIO += operator)

by Steven D'Aprano

On Tue, Mar 31, 2020 at 12:39:56AM -0700, Christopher Barker wrote: > But while the OP specifically suggested adding += to stringIO, you might > note that he did not suggest it as an extension to the file protocol, which > StringIO mimics. Rather, he suggested that there should be something that > can be used as an efficient buffer to build up strings, that had the same > API as str does. He figures that it would be pretty easy to get that by > adding += to StringIO. > > But wouldn’t a mutable string type satisfy that as well? Indeed it would, and if I ask for a nutcracker to crack open peanuts a nuclear powered 200 tonne bulldozer would satisfy the requirements too. What Paul asked for: https://media.qcsupply.com/media/catalog/product/cache/122b61bfb663175d7f1b… What we're talking about instead: http://media.firebox.com/pic/p1861_column_grid_12.jpg If you want a mutable string type, you have to support a rather extensive string API that includes at least ten operators: + * % == != in < <= >= > plus slicing and about 45 methods. (There may be some things I have missed.) Paul asked for *one* operator, `+=`. > And why WOULD folks that want a buffer to build strings in use string > concatenation? Maybe because in the end they want a string? But even if > StringIO grew +=, then they get a StringIO object at the end, and would > need to call .getvalue() to get a str. Yes, rather like the way you have to call `''.join(buf)` if you use a list. If your point is a criticism of the StringIO proposal, it is equally a criticism of the recommended list+join idiom, but we still tell people to use list+join, so it can't be a very important issue. And if it's not a valid criticism of the list+join idiom, or at least a very minor, unimportant one, then precisely the same applies to StringIO. > So how exactly does this meet the use case of being able to drop it into > code that’s written to use strings? This has been covered at least twice, once by Paul and once by me. When you are refactoring the "string concatenation" idiom to list append, you have to change three things: 1. the buffer initialisation: `buf = ''` --> `buf = []`; 2. add a conversion to the end: `result = ''.join(buf)`; 3. and potentially dozens of instances of `buf += s` to `buf.append(s)`. The third may be scattered around multiple functions. It is not always an easy refactoring. We should not assume that every append to the buffer will be in a single place or even a single function. Under Paul's suggestion, you change the buffer initialisation, add the conversion, and nothing else needs to be touched. You also get a performance boost (by my testing, using StringIO is about halfway in speed between string concat and list+join), and potentially a memory saving relative to the list version. (Although Paul's calculations on that have been disputed, and I don't think we have a definite answer on that one just yet.) > BTW, what about folks that concatenaste strings with plain + ? You couldn’t > drop StringIO in there reasonably either. Do you mean people who write `buf = buf + substring`? Maybe that's an argument to support `+` as well. Perhaps it would be weird and surprising to support augmented assignment for an operator without supporting the operator? But I don't have a strong feeling either way. Or maybe that's just an argument that no solution is going to solve *every* problem. What do we do about people who write this: buf = f'{buf}{substring}' inside a loop? We can't fix everyone's code with one change. > If we want to provide a way for folks to not do naive string concatenation— > adding += to StringIO is not any better than telling them to use a list and > .join() — it’s still a whole other way of doing it. It's not really. The point is to minimise how many things need to change. Instead of changing every `buf += s` into `buf.append(s)`, you just leave them alone. In that regard, it's *the same way* of doing it, the only difference is that the buffer changes from an immutable string to a builder. We should be careful to avoid exaggerating tiny differences, especially when that involves a double-standard. Is it a problem for the recommended list+join idiom that it is "a whole other way of doing it"? If no, then its not a problem for StringIO either. If the answer is yes, then StringIO is no worse than what people are already told to do, so it's not really much of a problem. > And the list and join() method uses two of the most common builtins— there > is a real advantage to that. Again, we must beware of double-standards. This list often says: "Not everything needs to be a builtin, just put it in a module." Also this list: "Being a builtin is a real advantage, we can't use StringIO because it comes from a module that needs importing." We can't have it both ways. In this case, using StringIO does involve one extra import. Okay, that's fine, the standard library is full of things that require one extra import but nevertheless are a common, or even sometimes recommended, way to do it. itertools comes to mind especially, using iterators in Python is ubiquitous and yet we still require people to import a module to do something as fundamental as slice an iterator. But maybe we can consider an alternative that doesn't require that import. > Anyway, I’m not proposing a mutable string type. It was really just an > example of: if this was really needed, it would have been done. Ah, so by that argument, *every* new proposal can be immediately rejected. If this were really needed, it would have already been done. Python 3.8 is the optimal language with literally every single desirable feature, nothing to be added, and no unneeded cruft to be removed. I trust that's not what you intended to say :-) -- Steven

1 day, 10 hours

Re: [Python-Dev] reversed enumerate

by Steven D'Aprano

Hi Ilya, I'm not sure that this mailing list (Python-Dev) is the right place for this discussion, I think that Python-Ideas (CCed) is the correct place. For the benefit of Python-Ideas, I have left your entire post below, to establish context. [Ilya] > I needed reversed(enumerate(x: list)) in my code, and have discovered > that it wound't work. This is disappointing because operation is well > defined. It isn't really well-defined, since enumerate can operate on infinite iterators, and you cannot reverse an infinite stream. Consider: def values(): while True: yield random.random() a, b = reversed(enumerate(values()) What should the first pair of (a, b) be? However, having said that, I think that your idea is not unreasonable. `enumerate(it)` in the most general case isn't reversable, but if `it` is reversable and sized, there's no reason why `enumerate(it)` shouldn't be too. My personal opinion is that this is a fairly obvious and straightforward enhancement, one which (hopefully!) shouldn't require much, if any, debate. I don't think we need a new class for this, I think enhancing enumerate to be reversable if its underlying iterator is reversable makes good sense. But if you can show some concrete use-cases, especially one or two from the standard library, that would help your case. Or some other languages which offer this functionality as standard. On the other hand, I think that there is a fairly lightweight work around. Define a helper function: def countdown(n): while True: yield n n -= 1 then call it like this: # reversed(enumerate(seq)) zip(countdown(len(seq)-1), reversed(seq))) So it isn't terribly hard to work around this. But I agree that it would be nice if enumerate encapsulated this for the caller. One potentially serious question: what should `enumerate.__reversed__` do when given a starting value? reversed(enumerate('abc', 1)) Should that yield...? # treat the start value as a start value (1, 'c'), (0, 'b'), (-1, 'a') # treat the start value as an end value (3, 'c'), (2, 'b'), (1, 'a') Something else? My preference would be to treat the starting value as an ending value. Steven On Wed, Apr 01, 2020 at 08:45:34PM +0200, Ilya Kamenshchikov wrote: > Hi, > > I needed reversed(enumerate(x: list)) in my code, and have discovered that > it wound't work. This is disappointing because operation is well defined. > It is also well defined for str type, range, and - in principle, but not > yet in practice - on dictionary iterators - keys(), values(), items() as > dictionaries are ordered now. > It would also be well defined on any user type implementing __iter__, > __len__, __reversed__ - think numpy arrays, some pandas dataframes, tensors. > > That's plenty of usecases, therefore I guess it would be quite useful to > avoid hacky / inefficient solutions like described here: > https://code.activestate.com/lists/python-list/706205/. > > If deemed useful, I would be interested in implementing this, maybe > together with __reversed__ on dict keys, values, items. > > Best Regards, > -- > Ilya Kamen > > ----------- > p.s. > > *Sketch* of what I am proposing: > > class reversible_enumerate: > > def __init__(self, iterable): > self.iterable = iterable > self.ctr = 0 > > def __iter__(self): > for e in self.iterable: > yield self.ctr, e > self.ctr += 1 > > def __reversed__(self): > try: > ri = reversed(self.iterable) > except Exception as e: > raise Exception( > "enumerate can only be reversed if iterable to > enumerate can be reversed and has defined length." > ) from e > > try: > l = len(self.iterable) > except Exception as e: > raise Exception( > "enumerate can only be reversed if iterable to > enumerate can be reversed and has defined length." > ) from e > > indexes = range(l-1, -1, -1) > for i, e in zip(indexes, ri): > yield i, e > > for i, c in reversed(reversible_enumerate("Hello World")): > print(i, c) > > for i, c in reversed(reversible_enumerate([11, 22, 33])): > > print(i, c) > _______________________________________________ > Python-Dev mailing list -- python-dev(a)python.org > To unsubscribe send an email to python-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NDDKDUD… > Code of Conduct: http://python.org/psf/codeofconduct/

1 day, 14 hours

PEP 9999: Retire animal-unfriendly language

by Gerrit Holl

(needs a sponsor) latest version at https://github.com/gerritholl/peps/blob/animal-friendly/pep-9999.rst PEP: 9999 Title: Retire animal-unfriendly language Author: Gerrit Holl <gerrit.holl(a)gmail.com> Discussions-To: python-ideas(a)python.org Status: Draft Type: Informational Content-Type: text/x-rst Created: 01-Apr-2020 Post-History: 01-Apr-2020 Sponsor: Abstract ======== Python has long used metasyntactic variables that are based on the consumption of meat and dairy products, such as "spam", "ham", and "eggs". This language is not considerate to pigs or chicken and violates the spirit of the Code of Conduct. This PEP proposes to retire the use of those names in official Python documentation and source code and to recommend users of Python to do the same. Motivation and Rationale ======================== Estimates for the number of animals slaughtered for meat every year vary, but `worldindata`_ estimates around 80 billion individuals. Farmed animals are often kept in small cages with little to no access to daylight, suffer stress during life and slaughter, or are otherwise systematically mistreated. The `Python Code of Conduct`_ describes that community members are open, considerate, and respectful. The Python standard library and documentation contain numerous references to meat or dairy based food products that are not respectful to our fellow inhabitants of planet Earth. Examples include "spam", "bacon", and "eggs". To align the language use in the standard library and documentation with the Code of Conduct, use of such language should be retired. Current practice ================ There is a widespread tradition in the Python standard library, the documentation, and the wider community, to include references to Monty Pythons Flying Circus. The use of "spam", "bacon", "sausage", and "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast by the British Broadcasting Corporation (BBC) on 8 September 1972. In this sketch, a couple are trying to order food in a diner where all items contain spam. The woman does not like spam and wants to order food without spam. A group of horned vikings then sing about the wonderful spam. To get an overview of the usage in the current standard library, the command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was used. This showed 2615 occurences for spam, 593 for ham (this include some false positives, among other reasons due to references to people whose name innociously contains the substring ham), 517 for eggs, 57 for bacon, and 10 for sausage. Searching ``*.rst`` in the documentation revealed 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and 10 for sausage. The source code for cpython revealed just 2 usages for spam and 1 for eggs. Proposed alternatives ===================== Keeping with the good practice of referencing sketches from Monty Python's Flying Circus, this PEP proposes to adopt the fruits mentioned in the `"Self-Defence Against Fresh Fruit" sketch`_: * raspberry (not currently in use) * banana (68 times in standard library) * apricot (not currently in use) * pineapple (8 times in standard library) * peach (once in standard library) * redcurrant (not currently in use) * damson (not currently in use) * prune (23 times in standard library) Other possible alternatives keeping with food items: * salad (occurs once in standard library) * aubergine (referred to in the spam sketch) * shallot (the same) * tofu (vegan protein alternative) Specification ============= For the reasons mentioned in the rationale, all references to meat or dairy products shall be removed from the Python standard library, the documentation, and the cpython source code. The wider Python community is recommended to follow this practice. In core Python: * Programmers SHALL NOT use the metasyntactic variables "spam", "ham", "bacon", or "sausage", neither as variable names, nor in example strings, nor in documentation. * Programmers SHALL NOT use the metasyntactic variable "eggs" in context with food items, but may still use it in context of other body parts. Prohibited: ``["salad", "eggs"]``. Allowed: ``["ovaries", "pouch", "eggs"]``. * Programmers SHALL NOT use any other metasyntactic variable that is unfriendly to animals. The wider Python community is encouraged to adopt these practices as well, but the continued use of animal-unfriendly metasyntactic variables will not be considered a violation of the code of conduct. Rejected ideas ============== The authors carefully considered the widespread use of the word "bug" in the meaning of a source code error. Insects including bugs play a crucial role in ecosystems around the world, and it is not fair to blame them for an error that can only be the programmer's. However, the use of the word "bug" for a source code error is too much ingrained into daily use, it far predates the Python community, is not limited to the Python community, and the word "bug" is less unfriendly than "spam", "ham", or "bacon". Therefore, the word "bug" may still be used. Reference Implementation ======================== The author promises to provide a reference implementation for Python 3.10, should this PEP be accepted. References ========== .. _worldindata: https://ourworldindata.org/meat-production .. _Python code of conduct: https://www.python.org/psf/conduct/ .. _"Spam" sketch: http://www.montypython.net/scripts/spam.php .. _"Self-Defence Against Fresh Fruit" sketch: http://www.montypython.net/scripts/fruit.php Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

1 day, 22 hours

returning a namedtuple on dict.items()

by Nadav Wexler

Hi, That is my first post here, I hope it's the right place for it. so I was using some dicts had the following code: env = dict(t for t in os.environ.items() if 'SUBSTRING' not in t[0]) and I thought: It could have really been nice if i could do: env = dict(t for t in os.environ.items() if 'SUBSTRING' not in t.key) now I see that environ is not exactly a dict, but i think this is useful for all dictionary types. on the other hand, dicts are everywhere and i'm not sure about the performance impact of this for those that just ignore the access by attribute. of course, a matching t.value must be in place as well. ;) I would have opened a PR just to try out, but I feel this is so in the core that I'd first like to hear some comments. I was searching if anyone else had this idea before but couldn't find anything. Thanks, Nadav

2 days, 18 hours

Re: PEP 9999: Retire animal-unfriendly language

by Michael Christensen

We've got to be considerate of other languages: What if, for example, a German speaker is looking for example code in English documentation and sees the word "speck"? He/she will think it means bacon and will be offended! Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone Get Outlook for Android<https://aka.ms/ghei36>

2 days, 18 hours

dunder methods for encoding & prettiness aware formal & informal representations

by Steve Jorgensen

This is really an idea for an idea. I'm not sure what the ideal dunder method names or APIs should be. Encoding awareness: The informal (`str`) representations of `inf` and `-inf` are "inf" and "-inf", and that seems appropriate as a known-safe value, but if we're writing the representation to a stream, and the stream has a Unicode encoding, then those might prefer to represent themselves as "∞" and "-∞". If there were a dunder method for informal representation to which the destination stream was passed, then the object could decide how to represent itself based on the properties of the stream. Prettiness awareness: It would be nice if an object could have control of how it is represented when pretty-printed. If there is any way for that to be done now, it is not at all evident from the pprint module documentation. It would be nice if there were some method that, if implemented for the object, would be used to allow the object to tell the pretty printer to treat it is a composite with starting text, component objects, and ending text. Additional thoughts & open questions: Perhaps there should only be stream awareness for informal representation and prettiness awareness for formal representation (separate concepts and APIs) or perhaps both ideas are applicable to both kinds of representation. Is it better for a stream-aware representation method to return the value to be written to the stream or to directly append its representation to that stream?

2 days, 19 hours

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas