Re: [Python-ideas] Dict joining using + and +=
I’m having issues to understand the semantics of d1 + d2. I think mappings are more complicated than sequences it some things seems not obvious to me. What would be OrderedDict1 + OrderedDict2, in which positions would be the resulting keys, which value would be used if the same key is present in both? What would be defaultdict1 + defaultdict2? It seems to me that subclasses of dict are complex mappings for which « merging » may be less obvious than for sequences. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
Le 6 mars 2019 à 10:26:15, Brice Parent
(cont...@brice.xyz(mailto:cont...@brice.xyz)) a écrit:
>
> Le 05/03/2019 à 23:40, Greg Ewing a écrit :
> > Steven D'Aprano wrote:
> >> The question is, is [recursive merge] behaviour useful enough and
> > > common enough to be built into dict itself?
> >
> > I think not. It seems like just one possible way of merging
> > values out of many. I think it would be better to provide
> > a merge function or method that lets you specify a function
> > for merging values.
> >
> That's what this conversation led me to. I'm not against the addition
> for the most general usage (and current PEP's describes the behaviour I
> would expect before reading the doc), but for all other more specific
> usages, where we intend any special or not-so-common behaviour, I'd go
> with modifying Dict.update like this:
>
> foo.update(bar, on_collision=updator) # Although I'm not a fan of the
> keyword I used
Le 6 mars 2019 à 10:26:15, Brice Parent
(cont...@brice.xyz(mailto:cont...@brice.xyz)) a écrit:
>
> Le 05/03/2019 à 23:40, Greg Ewing a écrit :
> > Steven D'Aprano wrote:
> >> The question is, is [recursive merge] behaviour useful enough and
> > > common enough to be built into dict itself?
> >
> > I think not. It seems like just one possible way of merging
> > values out of many. I think it would be better to provide
> > a merge function or method that lets you specify a function
> > for merging values.
> >
> That's what this conversation led me to. I'm not against the addition
> for the most general usage (and current PEP's describes the behaviour I
> would expect before reading the doc), but for all other more specific
> usages, where we intend any special or not-so-common behaviour, I'd go
> with modifying Dict.update like this:
>
> foo.update(bar, on_collision=updator) # Although I'm not a fan of the
> keyword I used
This won’t be possible update() already takes keyword arguments:
>>> foo = {}
>>> bar = {'a': 1}
>>> foo.update(bar, on_collision=lambda e: e)
>>> foo
{'a': 1, 'on_collision': at 0x10b8df598>}
> `updator` being a simple function like this one:
>
> def updator(updated, updator, key) -> Any:
> if key == "related":
> return updated[key].update(updator[key])
>
> if key == "tags":
> return updated[key] + updator[key]
>
> if key in ["a", "b", "c"]: # Those
> return updated[key]
>
> return updator[key]
>
> There's nothing here that couldn't be made today by using a custom
> update function, but leaving the burden of checking for values that are
> in both and actually inserting the new values to Python's language, and
> keeping on our side only the parts that are specific to our use case,
> makes in my opinion the code more readable, with fewer possible bugs and
> possibly better optimization.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add method unittest.TestProgram to add custom arguments
Hi everybody,
I would like to add a new method to unittest.TestProgram that would let
the user add its own arguments to TestProgram so its behavior can be
changed from the command line, and make them accessible from a TestCase.
This would allow for more customization when running the tests.
Currently there is no way to do this, so users either have to rely on
environment variables or parse sys.argv themselves like what is proposed
in https://stackoverflow.com/a/46061210.
This approach have several disadvantages:
- it's more work to check and parse the argument
- it's not discoverable from the help
- everyone have its own way of doing this
Here's two cases where this would be useful for me:
- in one project, I have an option to run tests in "record mode". In
this mode, all tests are executed but the results are saved to files
instead of checking their validity. In subsequent runs, results are
compared to those files to make sure they are correct:
def _test_payload(obj, filename):
import json, os
filename = f"test/results/{filename}"
if "RECORD_PAYLOADS" in os.environ:
with open(filename, "w") as f:
json.dump(obj, f, indent=2)
else:
with open(filename) as f:
assert obj == json.load(f)
This let us updating tests very quickly and just checking they are
correct by looking at the diff. This is very useful for testing an
API with many endpoints.
As you can see, we use an environment variable to change TestCase
behavior but it is awkward to run tests as
`RECORD_PAYLOADS=1 python test_api.py -v` instead of a more
straightforward `python test_api.py -v --record-payloads`.
- in https://bugs.python.org/issue18765 (unittest needs a way to launch
pdb.post_mortem or other debug hooks)
Gregory P. Smith and Michael Foord propose to make TestCase call
pdb.post_mortem() on failure. This also requires a way to change the
behavior as this would not be wanted in CI.
Just subclassing TestProgram would not be sufficient as the result of the
parsing
would not be accessible from the TestCase.
One argument against making such change is that it would require adding
a new attribute to TestCase which would not be backward compatible and
which could break existing code but I think this can be manageable if we
choose an appropriate name for it.
I attached an implementation of this feature (also available at
https://github.com/remilapeyre/cpython/tree/unittest-custom-arguments)
and look forward for your comments.
What do you think about this?
---
Lib/unittest/case.py| 7 +-
Lib/unittest/loader.py | 73 +
Lib/unittest/main.py| 49 +-
Lib/unittest/test/test_discovery.py | 225
Lib/unittest/test/test_program.py | 34 -
5 files changed, 331 insertions(+), 57 deletions(-)
diff --git a/Lib/unittest/case.py b/Lib/unittest/case.py
index a157ae8a14..5698e3a640 100644
--- a/Lib/unittest/case.py
+++ b/Lib/unittest/case.py
@@ -1,6 +1,7 @@
"""Test case implementation"""
import sys
+import argparse
import functools
import difflib
import logging
@@ -416,7 +417,7 @@ class TestCase(object):
_class_cleanups = []
-def __init__(self, methodName='runTest'):
+def __init__(self, methodName='runTest', command_line_arguments=None):
"""Create an instance of the class that will use the named test
method when executed. Raises a ValueError if the instance does
not have a method with the specified name.
@@ -436,6 +437,10 @@ class TestCase(object):
self._testMethodDoc = testMethod.__doc__
self._cleanups = []
self._subtest = None
+if command_line_arguments is None:
+self.command_line_arguments = argparse.Namespace()
+else:
+self.command_line_arguments = command_line_arguments
# Map types to custom assertEqual functions that will compare
# instances of said type in more detail to generate a more useful
diff --git a/Lib/unittest/loader.py b/Lib/unittest/loader.py
index ba7105e1ad..d5f0a97213 100644
--- a/Lib/unittest/loader.py
+++ b/Lib/unittest/loader.py
@@ -5,6 +5,7 @@ import re
import sys
import traceback
import types
+import itertools
import functools
import warnings
@@ -81,7 +82,7 @@ class TestLoader(object):
# avoid infinite re-entrancy.
self._loading_packages = set()
-def loadTestsFromTestCase(self, testCaseClass):
+def loadTestsFromTestCase(self, testCaseClass,
command_line_arguments=None):
"""Return a suite of all test cases contained in testCaseClass"""
if issubclass(testCaseClass, suite.TestSuite):
raise TypeError("Test cases should not be derived from "
@@ -90,12 +91,21 @@ class TestLoader(object):
testCaseNames = self.getTestCaseNames(testCaseClass)
if not testCaseNames and hasattr(testCaseClass,
Re: [Python-ideas] Code version evolver
Le 15 mars 2019 à 19:44:15, francismb (franci...@email.de(mailto:franci...@email.de)) a écrit: > > > On 3/14/19 9:47 PM, Chris Angelico wrote: > > What happens when someone wants to support multiple Python versions? > > "Requires Python 3.5 or newer" is easy. Forcing people to install the > > correct one for each version isn't. > What are the reasons why people want to support multiple Python > versions, on the 3 series? do they really want? or they need to (may > be)? and for how many versions, "from 3.5 or newer" ... forever? will be > reasonable possible? IMHO more versions to support, the harder to support. I think it’s pretty much a requirement for any respectable library, when a library drop support for a Python version, its usefulness drop significantly. > Regards, > --francis > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 15 mars 2019 à 18:52:51, Guido van Rossum (gu...@python.org(mailto:gu...@python.org)) a écrit: … > The power of visual processing really becomes apparent when you combine > multiple operators. For example, consider the distributive law: > > mul(n, add(x, y)) == add(mul(n, x), mul(n, y)) (5) > > That was painful to write, and I believe that at first you won't see the > pattern (or at least you wouldn't have immediately seen it if I hadn't > mentioned this was the distributive law). > > Compare to: > > n * (x + y) == n * x + n * y (5a) Thanks for the insight. I think this omit a very important property of mathematic equations thought, maths is a very strongly typed language which can be a significant improvement for readability. For example, a mathematician working within the space of linear maps over a vector space will easily recognize the meaning of every symbol in: f(a * x + y) = a * f(x) + f(y) And know that the + in the above expression is very different from the meaning of + in: x = a * y + z when he is working over the C complex field. For example, he instinctively knows what 1 / z means in the second case but that 1 / f in the first is completely bogus. In Python there is not that much contextual information, but we can use explicit names to overcome this, for example if I wrote: o = d1 + d2 + d3 you would have no idea what this is but: options = defaults + environment_variables + command_line_arguments is meaningful. ... > Of course, it's definitely possible to overdo this -- then you get Perl. But > I think that the folks who point out "there is already a way to do this" are > missing the point that it really is easier to grasp the meaning of this: > > d = d1 + d2 > > compared to this: > > d = d1.copy() > d = d1.update(d2) Of course. I may have missed something but I don’t understand why INADA Naoki proposal does not get more attention. It is not binary, and we could use names to convey the meaning of the operation: options = dict.merge(defaults, environment_variables, command_line_arguments) His alternative options = defaults.merge(environment_variables, command_line_arguments) could also be used if preferred. Is there really something wrong with this? It would do exactly what most proponent of + want but could be more readable. I agree that the argument of performance may not be very strong as most of the time, the updated dict might be smalls, but it would also solved this elegantly. I’m sorry if what I’m saying is not clear or I’m not able to convey my thoughts clearly as English is not my mother tongue, many others are better suited then me to discuss this proposal on this list but I don’t understand why this possibility is not more discussed. Rémi ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 16 mars 2019 à 13:15:37, Dan Sommers (2qdxy4rzwzuui...@potatochowder.com(mailto:2qdxy4rzwzuui...@potatochowder.com)) a écrit: > On 3/16/19 6:17 AM, Richard Damon wrote: > > On 3/16/19 4:39 AM, Greg Ewing wrote: > >> Rémi Lapeyre wrote: > >>> I think this omit a very important property of > >>> mathematic equations thought, maths is a very strongly typed language > >>> which can be a significant improvement for readability. > >> > >> Python is very strongly typed too, so I don't really see how > >> maths is different. > > > > 'Strongly Typed Language' can have slightly different meaning to > > different people. In Python, an object have a very definite type which > > strongly defines what you can do with that object, while other languages > > are less definitive in that aspect. But in Python, names are NOT that > > strongly typed, as a name can be rebound to any sort of object with a > > wide variety of types, compared to other languages where before using > > (or at first use) a variable you need to declare the 'type' that will be > > stored in it, and that type is all that it can hold. > > That's not strong vs. weak typing, that's dynamic vs. static typing. > > That said, I agree that different people get this wrong. :-) Yes, I’m dumb. I should have wrote « maths is a static typed language ». This together with the fact that it is nearly purely functional means that the overhead to know what type a given symbol is is much smaller. If I say « let f an automorphism over E », I can write three pages of equations and f will still be the same automorphism and E its associated vector space. I don’t have to very carefully read each intermediate result to make sure I did not bind f to something else. In Python, if I write three pages of code f could be something else so to know its type, I must look at all intermediate lines, including the called functions to know what the operator will refer too. This means that the overhead to track what a given symbol is in Python and much larger than it is in math. It’s already the case in a given function, but it gets worse when some of the names come from arguments, then you have to look in the caller context which may have been written at completely another time, by another team, increasing again the overhead. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 16 mars 2019 à 13:15:37, Dan Sommers (2qdxy4rzwzuui...@potatochowder.com(mailto:2qdxy4rzwzuui...@potatochowder.com)) a écrit: > On 3/16/19 6:17 AM, Richard Damon wrote: > > On 3/16/19 4:39 AM, Greg Ewing wrote: > >> Rémi Lapeyre wrote: > >>> I think this omit a very important property of > >>> mathematic equations thought, maths is a very strongly typed language > >>> which can be a significant improvement for readability. > >> > >> Python is very strongly typed too, so I don't really see how > >> maths is different. > > > > 'Strongly Typed Language' can have slightly different meaning to > > different people. In Python, an object have a very definite type which > > strongly defines what you can do with that object, while other languages > > are less definitive in that aspect. But in Python, names are NOT that > > strongly typed, as a name can be rebound to any sort of object with a > > wide variety of types, compared to other languages where before using > > (or at first use) a variable you need to declare the 'type' that will be > > stored in it, and that type is all that it can hold. > > That's not strong vs. weak typing, that's dynamic vs. static typing. > > That said, I agree that different people get this wrong. :-) Yes, I’m dumb. I should have wrote « maths is a static typed language ». This together with the fact that it is nearly purely functional means that the overhead to know what type a given symbol is is much smaller. If I say « let f an automorphism over E », I can write three pages of equations and f will still be the same automorphism and E its associated vector space. I don’t have to very carefully read each intermediate result to make sure I did not bind f to something else. In Python, if I write three pages of code f could be something else so to know its type, I must look at all intermediate lines, including the called functions to know what the operator will refer too. This means that the overhead to track what a given symbol is in Python and much larger than it is in math. It’s already the case in a given function, but it gets worse when some of the names come from arguments, then you have to look in the caller context which may have been written at completely another time, by another team, increasing again the overhead. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 16 mars 2019 à 10:02:31, Greg Ewing (greg.ew...@canterbury.ac.nz(mailto:greg.ew...@canterbury.ac.nz)) a écrit: > Rémi Lapeyre wrote: > > I think this omit a very important property of > > mathematic equations thought, maths is a very strongly typed language > > which can be a significant improvement for readability. > > Python is very strongly typed too, so I don't really see how > maths is different. Sorry, this should have read « maths is a statically typed language ». For example, in Python I can write: def inverse(x): return x ** (-1) But this would never be accepted in maths, I should say one of R -> R f: x -> x ** (-1) R+* -> R f: x -> x ** (-1) [1; +oo[ -> R f: x -> x ** (-1) GLn(K) -> GLn(K) f: x -> x ** (-1) And in all those examples, ** would have meant something very different and the resulting objects f are very different. For example, the third one is Lipschitz continuous but not the first. On the other hand, I know nothing regarding the inverse Function in Python. Knowing nothing about `inverse` means that every time I use it i must determine what it means in the given context. > > For example, a > > mathematician working within the space of linear maps over a vector > > space will easily recognize the meaning of every symbol in: > > > > f(a * x + y) = a * f(x) + f(y) > > Yes, but he has to remember what types are associated with > the variables -- nothing at their point of use indicates that. > Likewise, the reader of a Python program has to remember what > type of object each name is expected to be bound to. If he > can remember that, he will know what all the operators do. The overhead to track the associated type for a given name in maths is far lower since it is a functional language. In maths, I can just make a mental note of it and be done with it; in Python, you can never be sure the type of the binded object did not change unexpectedly. > -- > Greg > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] True and False are singletons
Le 18 mars 2019 à 12:15:05, Juancarlo Añez (apal...@gmail.com(mailto:apal...@gmail.com)) a écrit: > It came to my attention that: > > > In the original PEP True and False are said to be singletons > > https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model > > https://docs.python.org/3/reference/datamodel.html > > This came to my attention by code wanting to own the valid values in a dict's > key: > > > if settings[MY_KEY] is True: > > ... > > > > > If True and False are singletons in the spec (and not only in the CPython > implementation), it should be prominent and well known. I think it’s what "The two objects representing the values False and True are the only Boolean objects." mean. Rémi > Cheers, > > -- > Juancarlo Añez ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why operators are useful
Le 17 mars 2019 à 02:01:51, Greg Ewing (greg.ew...@canterbury.ac.nz(mailto:greg.ew...@canterbury.ac.nz)) a écrit: > Richard Damon wrote: > > Rémi, I believe, is assuming in their example that by defining the field > > of mathematics being used, there is at least an implicit definition (if > > not actually explicit as such a statement would typically be preceded by > > definitions) definition of the types of the variables. > > In Python, we have such implicit definitions in the form > of comments, and inferences from the way things are used. Yes, exactly. You can make "inferences from the way things are used". But the comparison with maths stops here, you don’t make such inferences because your object must be well defined before you start using it. You can track types with comments but you need to comment each line. There is also no definitions if no comment was written. In maths, an given object is not duck because it quacks and walks like a duck, it’s either part of the set of all ducks, or not. Python’s typing is implicit Maths’ typing is explicit so you don’t need to spend brain cycles to determine them. Python is imperative Maths is functional So once you know the type or the value of an object in maths, you don’t have to check all the time to make sure they did not change and spend precious brain cycles tracking it. I would argue that those two differences are really important when using an operator, When doing maths, you are always acutely aware of the context. > > when looking at a piece of code you > > don't necessarily know the types of the objects being used > > And if you look at an equation from a mathematics text without > the context in which it appears, you won't always know what > it means either. But the equation is only meaningful in a given context. Asking whether f: x -> 1/x is differentiable is only meaningful if we know whether x is in R, C, [1; +oo[... > -- > Greg > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
Le 21 mars 2019 à 17:43:31, Steven D'Aprano (st...@pearwood.info(mailto:st...@pearwood.info)) a écrit: > I'd like to make a plea to people: > > I get it, there is now significant opposition to using the + symbol for > this proposed operator. At the time I wrote the first draft of the PEP, > there was virtually no opposition to it, and the | operator had very > little support. This has clearly changed. > > At this point I don't think it is productive to keep making subjective > claims that + will be more confusing or surprising. You've made your > point that you don't like it, and the next draft^1 of the PEP will make > that clear. > > But if you have *concrete examples* of code that currently is easy to > understand, but will be harder to understand if we add dict.__add__, > then please do show me! > > For those who oppose the + operator, it will help me if you made it > clear whether it is *just* the + symbol you dislike, and would accept > the | operator instead, or whether you hate the whole operator concept > regardless of how it is spelled. Thanks for the work you are doing on this PEP and for debunking my misconceptions regarding types, I’m currently learning a lot about them. I don’t know if it matters but I’m in favor of the method > And to those who support this PEP, code examples where a dict merge > operator will help are most welcome! Not matter the notation you end up choosing, I think this code: https://github.com/jpadilla/pyjwt/blob/master/jwt/utils.py#L71-L81 which is part of a widely used library to validate JWTs would greatly benefit from a new merge to merge dicts. (This package is 78 on https://hugovk.github.io/top-pypi-packages/) Rémi > ^1 Coming Real Soon Now™. > > > -- > Steven > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add logging to subprocess.Popen
Every time I use subprocess.run and others I find myself writing boilerplate code to log program calls and their results. Could we log those directly in subprocess.py so that we could just set a "subprocess" logger instead? Rémi ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S5MWG7KM5O42TVVK3GUUXFZTB6LYUROQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add logging to subprocess.Popen
> But couldn't you just write a simple helper function/class that handles your > usual workflow? I do when I’m the one calling subprocess.run() but it’s not possible to do that when it’s a library that does the call. > Why does this deserve in the stdlib? > (The stdlib does very little logging of its own -- logging is up to the > application.) Some parts of the stdlib output some logs like urllib, I think only the configuration of the handlers is up to the application. Is the stdlib not generating logs because of the overhead of calling logging.info()? > It's not logging per se, but the standard library does have an > extensive and growing list of audit events that are intended to assist > with testing, logging and security monitoring. Thanks, It looks like an audit hook could work. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P3UU2PNK6OWLYAHQVGXXKFKXROVDH57N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add logging to subprocess.Popen
> Some parts of the stdlib output some logs like urllib, I think only the > configuration of the handlers is up to the application. > > I don't see any logging calls in urllib. If you know of any, can you point me > to them? (There are some warnings.warn() calls, but that's different.) I mistook urllib3 for urllib sorry. There is no logs in urllib. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IRXZYZ4UNEQXO3CNLO6DCWV47GGOVLJR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
> On 5 Sep 2021, at 17:07, C. Titus Brown via Python-ideas > wrote: > > Hi all, > > the product of Sunday morning idle curiosity... > > I’ve been using the csv module a lot, and I’m wondering if there would be > value in adding a standard mechanism for opening a CSV file (correctly) using > a context manager? > > So, instead of > > with open(filename, newline=“”) as fp: > r = csv.DictReader(fp) > for row in r: > … > > support something like > > with csv.DictReader.open(filename) as r: > for row in r: > … This would only be helpful when the CSV is on the disk but csv.reader() takes a file object so that it can used with anything like a socket for example. json.load() does the same thing. It seems to me that it is better to keep a generic interface that are composable. Cheers, Rémi > > ? And something similar for ‘csv.reader’? I’m not wedded to the details here. > > The two main reasons I think this might be a positive addition are - > > * you wouldn’t have to know or remember the right way to open a CSV file > (newline=“”). > * it elides very common code. > > but perhaps there are things I’m missing here? > > As a side note, I think ‘csv.reader’ could usefully be renamed to something > else (maybe just Reader?), since it’s kind of out of sync with the CamelCase > used in ‘DictReader’. But maybe that’s just an attempt at foolish consistency > :). > > best, > —titus > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/EKHYCTYMXZG3VI4JYFA3Y3LD3ZNMI3IX/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZJNJQFC2LKQ76GTEBQNKTB3WO2POTKEN/ Code of Conduct: http://python.org/psf/codeofconduct/
