[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Fri, Aug 28, 2020 at 10:10 PM Steven D'Aprano wrote: > On Thu, Aug 27, 2020 at 09:57:26AM -0400, Ricky Teachey wrote: > > > Sorry, I need to stop coding in shorthand. > > That might help. > > What might help even more is if you spend less time showing imaginary, > and invariably buggy, examples and more time explaining in words the > intended semantics of this, and the reason why you want those semantics. I'm sorry you had to read over my email so many times. I'm sorry I have confused things by throwing out more than one idea at a time. I am sorry I am so bad at explaining things. Hopefully now it is clear, regardless of how we got there. It sounds like it is. I was really trying to explain the semantics multiple times but as I look over my messages your criticism is correct, I was throwing out too many detailed examples rather than focusing on the idea. For your benefit- since my explanations weren't sufficient- I wrote a bunch of admittedly junkie code, which is sometimes easier to understand (even if it is buggy) than English, in an attempt to showcase the idea more clearly. So let me see if I have this. You want to add a special dunder method > which, if it exists, is automatically called by the interpreter to > preprocess the subscript before passing it to the usual get-, set- and > del-item dunders. > Yes, that's the basic idea as I envision it and as Jonathan Fine wote in the first message in this thread. > ... > > * interpreter passes arguments to the subscript dunder > * which preprocesses them and returns them > * and the interpreter then passes them to the appropriate dunder. > > I'm underwhelmed. > I think a new dunder is a good idea. I've explained why a couple times but I can try again if you'd like. On the other hand, we've established I'm bad at explaining things so maybe not a great idea. I can point you to this comment from Greg Ewing in the other thread where I first brought up the new dunders (3 new dunders, in that case) idea, maybe it will be better than I can do (however he's talking about 3 dunders-- still hoping he and others might come around to the idea of just one): https://mail.python.org/archives/list/python-ideas@python.org/message/NIJAZKTHPBP6Q3462V3DBUWDTQ5NU7QU/ > I *think* your intention here is to handle the transition from the > status quo to full function-like parameters in subscripts in a backwards > compatible way, but that's not going to work. > I'm not so sure that's fully true. There are certainly problems that need to be worked out. > The status quo is that the subscript is passed as either a single value, > or a tuple, not multiple arguments. If that *parsing rule* remains in > place, then these two calls are indistinguishable: > > obj[spam, eggs] > obj[(spam, eggs)] > > and your subscript dunder will only receive a single argument because > that's what the parser sees. So you need to change the parser rule. > Yes I've made this observation myself in a couple different replies and I agree it's a problem. Greg Ewing (again!) had a helpful comment about it, perhaps he is correct: https://mail.python.org/archives/list/python-ideas@python.org/message/XWE73VLLGYWYLNFMRKZXIBILBOLAI6Z3/ "We could probably cope with that by generating different bytecode when there is a single argument with a trailing comma, so that a runtime decision can be made as to whether to tupleify it. However, I'm not sure whether it's necessary to go that far. The important thing isn't to make the indexing syntax exactly match function call syntax, it's to pass multiple indexes as positional arguments to __getindex__. So I'd be fine with having to write a[(1,)] to get a one-element tuple in both the old and new cases. It might actually be better that way, because having trailing commas mean different things depending on the type of object being indexed could be quite confusing." > Your subscript preprocessor would allow the coder to stick spam and eggs > into a tuple and pass it on, but it also returns a dict so the getitem > dunder still needs to be re-written to accept `**kwargs` and check that > it's empty, so you're adding more, not less, work. No, that's not right. The kwargs mapping included in the return by the preprocessor gets unpacked in the item dunder call. An unpacked empty dict in an existing item dunder (without kwargs support) creates no error at all. Yes, if the kwargs dunder contains argument names not supported by the signature of the item dunders, we will get an error. But that's true with any function call. So, you know, don't do that. And besides, if I > have to add a brand new dunder method to my class in order for my item > getter to not break, it's not really backwards-compatible. > How is it going to be broken? Unless you add the new dunder to your class, it won't be operative. The implicitly existing internal python function that does the job of this proposed dunder acts as the preprocessor instead of the dunder. Okay, let's
[Python-ideas] Re: Option Read/Write Files without discarding comments
On Fri, Aug 28, 2020 at 09:34:43AM -0700, Christopher Barker wrote:
> And on the Python side, there is no standard way to represent arbitrary
> text files as Python objects.
Um, sure there is: unstructured text, which is exactly what Python does.
And contrary to Steve Barnes' comments, Python doesn't discard comments
when reading and writing text files, because it has no concept of a
generic "text file comment". It's all just text, regardless of whether
the text includes "#" or "{...}" or "--" or "REM" or ";" or "/* ... */".
--
Steve
___
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/U3JWGLPCMB7JRUAZOWNTZW6T47X4WI55/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Thu, Aug 27, 2020 at 09:57:26AM -0400, Ricky Teachey wrote:
> Sorry, I need to stop coding in shorthand.
That might help.
What might help even more is if you spend less time showing imaginary,
and invariably buggy, examples and more time explaining in words the
intended semantics of this, and the reason why you want those semantics.
I had to read over your email three times before the penny dropped what
you are actually saying. Partly because I haven't had breakfast yet,
partly because I was still thinking about earlier versions of your
proposal e.g. when you had a single subscript dunder get passed the name
of the get- set- or del-item dunder, and was expected to dispatch to
that method. But mostly because your description is so full of fine
detail that the big picture is missing.
So let me see if I have this. You want to add a special dunder method
which, if it exists, is automatically called by the interpreter to
preprocess the subscript before passing it to the usual get-, set- and
del-item dunders.
So instead of having this:
# hypothetical change to subscript behaviour
# to allow multiple arguments
def __getitem__(self, fee, fi, fo, fum):
...
# and similar for __setitem__ and __delitem__
We will have this:
def __subscript__(self, fee, fi, fo, fum):
return (fee, fi, fo, fum, {})
def __getitem__(self, fee, fi, fo, fum, **kw):
assert kw == {}
...
# and similar for __setitem__ and __delitem__
and the process changes from:
* interpreter passes arguments to the appropriate dunder
to this instead:
* interpreter passes arguments to the subscript dunder
* which preprocesses them and returns them
* and the interpreter then passes them to the appropriate dunder.
I'm underwhelmed.
I *think* your intention here is to handle the transition from the
status quo to full function-like parameters in subscripts in a backwards
compatible way, but that's not going to work.
The status quo is that the subscript is passed as either a single value,
or a tuple, not multiple arguments. If that *parsing rule* remains in
place, then these two calls are indistinguishable:
obj[spam, eggs]
obj[(spam, eggs)]
and your subscript dunder will only receive a single argument because
that's what the parser sees. So you need to change the parser rule.
But that breaks code that doesn't include the subscript dunder, because
now this:
obj[spam, eggs]
gets passed as two args, not one, and `__getitem__` has only been
written to accept one, so you get a TypeError.
Your subscript preprocessor would allow the coder to stick spam and eggs
into a tuple and pass it on, but it also returns a dict so the getitem
dunder still needs to be re-written to accept `**kwargs` and check that
it's empty, so you're adding more, not less, work. And besides, if I
have to add a brand new dunder method to my class in order for my item
getter to not break, it's not really backwards-compatible.
Okay, let's make the interpreter smarter: it parses spam, eggs as two
arguments, and then sees that there is no subscript dunder, so it drops
back to "legacy mode", and assembles spam and eggs into a tuple before
passing it on to the item getter.
Only that's not really backwards compatible either, because the
interpreter can't distinguish the two cases:
# single argument with trailing comma
obj[spam,]
# no trailing comma
obj[spam]
In both cases this looks like a single argument to the interpreter, but
the status quo is that they are different. The first one needs to be a
tuple of one item.
Why add all this complexity only to fail to remain backwards-compatible?
Better would be to add a new future directive to change the parsing of
subscripts, and allow people to opt-in when they are ready on a
per-module basis.
from __future__ import subscript_arguments
This sort of change in behaviour is exactly why the future mechanism was
invented. If it is desirable to change subscripting to pass multiple
positional arguments, then we should use that, not complicated jerry-
rigged "Do What I Mean" cunning plans that fail to Do What I Meant.
Notice that none of the above needs to refer to keyword arguments. We
could leave keyword arguments out of your proposal, and the argument
parsing issue remains.
--
Steve
___
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/SGL52P6BARYAOMQC52OOLB4GBMOETH34/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
Oops, look like I took this off-list by accident -- bringing it back on. On Fri, Aug 28, 2020 at 12:50 PM Guido van Rossum wrote: > IMO the bar for attempting to solve this is pretty high, since I can think > of no way to solve it without breaking old code that doesn't involve > introducing new names. > Exactly -- so we're kind of stuck with the existing ABCs for a good long while. Maybe that's OK, but it does mean we are choosing to freeze at least this part of Python. But I agree with you that it's problematic to add features to the builtins as well (like .get() to list and friends that aren't in the ABCs, so we're really freezing a lot of the language. Which may be a good thing, but on this list at least, I expect people wont like that :-) FWIW I don't think there's an exception for dunders -- if we were to add > Sequence.__new_dunder__ we'd still break code due to register(). > hmm -- I never actually used register(), and had always assumed that it did some checking -- but apparently not, so yes, anything registered with an ABC that something was added to could now be broken thanks for the tip. Though that's probably less breakage, but breakage all the same. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/LPMHTJ5SWLUGTFAJVO32567T3CAMKB3K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
Em qui, 27 de ago de 2020 10:37, M.-A. Lemburg escreveu: > On 27.08.2020 15:17, Alex Hall wrote: > > On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote: > > > >> I disagree on the above assessment. I have had such a get() builtin > >> in mxTools for more than 20 years now and found that I hardly ever > >> used it: > >> > >> > https://www.egenix.com/products/python/mxBase/mxTools/doc/#_Toc293606201 > >> > >> The reason is simple: unlike for dicts, where you often expect > >> non-existing items (e.g. in keyword arguments, config files, etc.), > >> having a missing index position in a list which you parse is > >> almost always an error. > >> > >> Now, errors should be clearly marked and handled as such, hence > >> having a try-except is the better coding strategy. > >> > >> For those cases, where a list can have a variable > >> number of entries (e.g. optional arguments, file lists, etc.), > >> code should clearly branch on list length and then determine the > >> right strategy to fetch items. > > > > > > I'm copying my earlier post because apparently linking to it repeatedly > has > > no effect and people keep on claiming that this method wouldn't be useful > > while not saying a word about the evidence I presented that it would be. > > > > dict.get is definitely much more useful. But list.get is still useful > > reasonably often. > > > > You can see quite a bit of demand for the method here: > > > https://stackoverflow.com/questions/5125619/why-doesnt-list-have-safe-get-method-like-dictionary > > > > Below are some use cases I found and how they could be refactored with > > .get. Apart from the first one, they were all found simply by grepping > for > > `except IndexError`. It's pretty easy to pick obvious use cases out from > > there. In some cases readability suffers a bit and using .get might not > be > > the best idea, but I've included them anyway so that we can see what > > over-eager usage of the method might look like. > > If I'm not mistaken, all those listed cases fall under the second case > I mentioned (branching on length). > > If your API allows for optional list entries, then it's better to > branch on length (e.g. as in the pytest case). If this happens only in > exceptional cases, use try-except (most other cases you listed). > > Both coding styles make the intent clear without doubt. > > As mentioned before, I had access to such a builtin for many years, > but hardly ever chose to use it and instead opted for the more explicit > branching on length. > > IMO, being able to write something with fewer key strokes is not > always a good idea. Unless you write code only for yourself, it's > usually better to emphasize on intent rather than brevity. > In this case is pretty obvious the intent and this is an know abstraction. Avoid brevity will not make it cleaner. IMHO, explicitng index bounds and try/catch are distracting noise which hides intent instead. Also .get() would not prevent anybody from explicity checking bounds or catching index exceptions when appropriate > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Aug 27 2020) > >>> Python Projects, Coaching and Support ...https://www.egenix.com/ > >>> Python Product Development ...https://consulting.egenix.com/ > > > ::: We implement business ideas - efficiently in both time and costs ::: > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >Registered at Amtsgericht Duesseldorf: HRB 46611 >https://www.egenix.com/company/contact/ > https://www.malemburg.com > ___ 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/25OXHPNDVYRYOOWU6YDRL3PLQVLIG2K5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
Thanks for the comments! Some food for thought. One comment: Paul Moore writes: > On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull > wrote: > > True, but not really fair under my assumption that `x[i, default=d]` > > becomes the accepted way of doing it generally. dict.get would be a > > legacy in that case. > > So one of [,default=] and dict.get is redundant. Why make the existing > way the redundant one? What's the actual benefit? Consistency with practice in other subscriptables. That makes it easier to learn the language as a whole. But it seems that most people are +/- 0 on .get, and -1 on default=, so .get is much more likely to become the consistent way to do things. Steve ___ 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/66GFMAR3HNPSYVTTNW4MIFSR3S2LYHWN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Fri, Aug 28, 2020 at 5:10 AM Todd wrote: > > But I don't see why this is a problem we have to deal with. The index > argument can just not be passed at all, and it is up to the class developer > to pick an appropriate sentinel if needed. > >> > That is a good point -- any existing ocde (Or new code that doesn't support keywords) would raise an Error -- though it would be a (TypeError, rather than a SyntaxError) if no index were passed in. So why not allow it? This does require some thought about backward compatibility -- as passing anything other than a single index is now a SyntaxError, most code in teh wild will not be set up to handle the run time TypeError that might now arise. As "proper" exception handling should be close to the operation, and catch specific Exceptions, most case will probably be fine. But not all. For example, there might be code in the wild that does try: a_function(something) except TypeError: do_something And there is something in a_function that uses indexing -- someone messes with that code, and puts something new in an index that used to be a SyntaxError and is now a TypeError -- in the past, that wouldn't have even run, but now it will, and the problem might not be caught in tests because the TypeError is being handled. Given that this would be a change from a compile time error to a runtime error, there is no code that used to work that will break, but it would be easier to write broken code in certain situations -- maybe not a huge deal, but worth thinking about. -CHB ___ 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/OBADMTX3WHU7DLJNYXHBBPOTZRTJUOWR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Option Read/Write Files without discarding comments
On Fri, Aug 28, 2020 at 5:45 AM Shahriar Heidrich <
smheidr...@weltenfunktion.de> wrote:
> On 8/28/20 6:56 AM, Steve Barnes wrote:
>
> This is just about the first part of your mail: There are external
> libraries for reading and writing various formats while preserving comments
> (and even more, e.g. spacing): For Python files, there is RedBaron, for
> YAML there is ruamel.yaml,
>
This is the key point -- each text file format has its own structure, etc,
there is no "standard" that could be generally supported.
And on the Python side, there is no standard way to represent arbitrary
text files as Python objects. Sure, for the most part,most file readers
build up a tree of dicts and lists, but where would comments fit into that
-- how would you even know which object to attach the comment to? that
specification would have to be part of the file format -- kind of like
docstrings, actually. there is a spec in Python code for where to put
strings that you want to preserve and "attach" to certain objects. But
notably, they are NOT comments -- comments, by their very nature, are more
free form.
> and JSON doesn't allow comments as far as I know.
>
It does not -- though many extensions to JSON do -- notably JSON-5 -- which
I wish were supported in the stdlib. But this makes a good point, if you
want conforming JSON, you can't use comments at all -- so maybe your own
stqndard would be helpful:
an_object = {"__comment__": " an arbitrary comment about this object",
"this": "a regular attribute",
"that": [3,4,5,6]}
And then you could have a "CommentedDict" Python object as well.
But having said all that -- I have, in fact, written my own file format
that looked a lot like INI files, but had comments thqt were preserved. It
is nice to have a simple way to handle comments in the raw file format,
while still capturing them. And tthe JSON example above is not simpel
enough for easy text editor action.
Maybe a standard way to do it with YAML would be doable.
So *maybe* a set of "commented" versions of the core builtins would be
useful.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
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/UQOUXTPLN5B3JQ6T7UBZIANU47GI6E4M/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On 29/08/20 12:06 am, David Mertz wrote: I only thought of it because `mydict[foo=bar]` now raises a SyntaxError, so raising something different would technically be a change in behavior. It's going to be a change in behaviour whatever you raise, because it's currently a compile time error. -- Greg ___ 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/DHGO3TT7N3PO2CXIMONTKT7AYGVPUQWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On 2020-08-28 at 08:41:04 -0400, Regarding "[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?," Richard Damon wrote: > On 8/28/20 8:24 AM, David Mertz wrote: > > > > As a side note, I don't really get why everyone else thinks a > > try/except is the most natural approach while a ternary seems more > > obvious to me for this situation. But it kinda connects to me liking > > list.get() better, I think... since "not enough items" doesn't seem as > > *exceptional* to me as it apparently does to some others. > > try/except is specifically looking for the error in question, index out > of bounds. The ternary requires restating in other words the bounds limit. > > For instance, for a list of N items, the allowable subscripts are -N to > N-1, and the sample ternary is only checking for the upper bound, not > the lower, so fails an too small of an index (maybe you know you are > only using positive indexes?) Missing this won't happen with try/except. Without more context, I've lost the forest for the trees. There are multiple ways to do this, and the "best" way likely depends on the context and not the readability, writability, maintainability, or expressivity of that exact line of code. Where did the index come from? How/when/where was the list constructed? Could this "problem" have been recognized and/or addressed sooner? What, exactly, are the conditions that cause the index being out of bounds at this point in the logic, and what are the semantics now that it's happened? Given the preceding logic, is an index that's too small (i.e. mathematically less than the opposite of the lenght of the list) even possible? I didn't find either of the examples (one using an if/else ternary and one using a hypothetical list.get method) particulary easy to read or particularly indicative of an obvious use case. And at that point, re-writing one [presumably correct] line of code into another won't make or break anything. ___ 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/BG2P6BCSDDANXU2XR4XU75O2AOLRVHM5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Fri, 28 Aug 2020 at 13:26, David Mertz wrote: > As a side note, I don't really get why everyone else thinks a try/except is > the most natural approach while a ternary seems more obvious to me for this > situation. But it kinda connects to me liking list.get() better, I think... > since "not enough items" doesn't seem as *exceptional* to me as it apparently > does to some others. Possibly because in reality, people very rarely write code like that, so they are working out what they'd use "from scratch", rather than just quoting a well-known idiom that they are familiar with? Which to me says that this method isn't nearly as useful in practice as some people are claiming. Paul ___ 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/6QPYCQHLKJ7TED4CLBWVDCKDB64QFNMM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Option Read/Write Files without discarding comments
On 8/28/20 6:56 AM, Steve Barnes wrote: > > It occurs to me that there are many situations where files are human > authored and can include comments but by default when python > reads/modifies/writes those files by default the comments are lost. > > > > Some examples include configfile, json and even python itself with the > special case that docstrings are read without being discarded. > > > > If we wish to generate a commented file, (such as an initial version > of a config file), then file type specific code is needed but in > general if we read in a file the comments are discarded – usually of > course this is what we need but not if we are going to be modifying > values are re-writing. > > > > In the case of files that are read and parsed into python objects we > could quite easily have an option to make comments a docstring on the > resulting objects and a write option to output the docstrings (marked > as comments). > > > > It would be necessary to have a mechanism for preserving file level > comments that are interleaved with values/objects and after the last > value/object. > > > > Of course, in many cases, it would be nice to have find commented > object and uncomment object, possibly comment out object methods but I > still believe that even without such methods could be useful to be > able to round trip files that include comments. > > > > Writing this has also sparked a thought of wouldn’t it be nice to have > a format for python line comments where the object so commented gets a > docstring from the line comment, e.g. > > > > class StockItem: > > “”” Represents an item available in store “”” > > lineno: str #! Catalogue Item Number in the format AA--AAA > > : > > > > The humble docstring can be so useful and as far as I know any python > object can carry one but currently base classes such as int, etc. Have > read only __doc__ members. > > > > Of course I am probably going to get told off for 2 related but > divergent elements in one thread! > > > > Steve Barnes > > This is just about the first part of your mail: There are external libraries for reading and writing various formats while preserving comments (and even more, e.g. spacing): For Python files, there is RedBaron, for YAML there is ruamel.yaml, and JSON doesn't allow comments as far as I know. For configfile I'm not sure, doesn't look like there is anything... but one could have a look at how comments are represented in RedBaron and ruamel.yaml and write a similar library for configfiles. Cheers ___ 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/7FTKAB7W7MKBRURSAHVZSXWHMTZBASIR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On 8/28/20 8:24 AM, David Mertz wrote: > > As a side note, I don't really get why everyone else thinks a > try/except is the most natural approach while a ternary seems more > obvious to me for this situation. But it kinda connects to me liking > list.get() better, I think... since "not enough items" doesn't seem as > *exceptional* to me as it apparently does to some others. try/except is specifically looking for the error in question, index out of bounds. The ternary requires restating in other words the bounds limit. For instance, for a list of N items, the allowable subscripts are -N to N-1, and the sample ternary is only checking for the upper bound, not the lower, so fails an too small of an index (maybe you know you are only using positive indexes?) Missing this won't happen with try/except. -- Richard Damon ___ 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/XGEFOQIG7DHNXYV3R554TG2KJ6J6R7BM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > > Suppose we didn't have dict.get(). I would then probably write: > > > val = mydict[key] if key in mydict else None > > > > > > Likewise, since we don't have list.get(), I would write: > > > val = mylist[N-1] if len(mylist) >= N else None > > I think David is comparing the .get syntax to the if-else syntax. > First of all, he got the if-else wrong, which is a sign that .get is > easier to use, at least for writers and quite likely for readers. > It was an unintentional mistake, but Stephen is right it makes the point. I fixed above, both my thinko reversing the N vs. N-1, and also the simple typo of `>-` instead of `>=`. No language change is going to fix the fact the '-' and '=' keys are next to each other on my keyboard. I think the comparison (with right syntax and semantics) is fair. Whatever the ontological significance MAL notes about "reaching into the void" versus "reaching into the dark", the code I would actually write if dict.get() didn't exist is pretty much the above. And it looks a whole lot like the code I actually do write for possibly-missing index positions. As a side note, I don't really get why everyone else thinks a try/except is the most natural approach while a ternary seems more obvious to me for this situation. But it kinda connects to me liking list.get() better, I think... since "not enough items" doesn't seem as *exceptional* to me as it apparently does to some others. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/ZEPTEIJUVEMYV2EECWO67JBBXTZHWXHV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Thu, Aug 27, 2020, 19:30 Joseph Martinot-Lagarde wrote: > As for foo[a=1, b=2], I'd propose to keep it a SyntaxError for now, and > always require an index. This way it can be changed later when people are > more used to the keyword args and have more ideas of what would be good as > a default argument. In the face of ambiguity, refuse the temptation to > guess ;) > This really wouldn't work for xarray, either. I think the simplest default value would be Ellipsis. So foo[a=1, b=2] would be equivalent to foo[..., a=1, b=2] But I don't see why this is a problem we have to deal with. The index argument can just not be passed at all, and it is up to the class developer to pick an appropriate sentinel if needed. > ___ 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/UDMJ6A2DGU7VNEAEPQQO5HYFVVQ4EN7F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
> I don't think it can be a SyntaxError because you can't always know
> that mylist is a builtin list. list.__getitem__(self, ...) gets
> called and it tells you "TypeError: __getitem__() takes no keyword
> arguments", as it does now. (Just for the record. I bet you realized
> that within nanoseconds of hitting "send". ;-)
>
I'm not nearly so clever :-).
I was thinking, hypothetically, that it's possible for dict.__getitem__()
to have code along the lines of:
def __getitem__(self, index, **kws):
if kws:
raise SyntaxError("Keywords not allowed in dictionary index")
# ... actual item getting ...
I'm not saying that's a good idea per se. Hence my parenthetical.
Probably any extra check on every dict access is a needless slowdown
though. I only thought of it because `mydict[foo=bar]` now raises a
SyntaxError, so raising something different would technically be a change
in behavior.
How do you folks feel about list.get and tuple.get (I expect many
> folks will think differently about these because tuples are
> immutable), and more generally Sequence.get?
>
-1 on Sequence.get. -0.5 on tuple.get.
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/FEWWNMJHVXD42JCS2VZX2RDS66HBOOLY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Fri, Aug 28, 2020 at 05:30:26PM +0900, Stephen J. Turnbull wrote: > David Mertz writes: > > > I support named indices. But I strongly oppose using them in list, > > tuple, or dict themselves. So `mylist[99, default=4]` would still > > be a syntax error (or maybe a different exception). > > I don't think it can be a SyntaxError because you can't always know > that mylist is a builtin list. It shouldn't be a syntax error because it wouldn't be a syntax error. -- Steve ___ 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/WNPJDFYEIEDYSWRCPVKXRC5EGUR73V5F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On 28.08.2020 10:30, Stephen J. Turnbull wrote: > M.-A. Lemburg writes: > > On 27.08.2020 17:53, David Mertz wrote: > > > > Suppose we didn't have dict.get(). I would then probably write: > > > > > > val = mydict[key] if key in mydict else None > > > > > > Likewise, since we don't have list.get(), I would write: > > > > > > val = mylist[N] if len(mylist) >- N-1 else None > > > > > > Neither of those is impractical, but in both cases .get(key) seems to > > > express the intent in a more obvious way. > > > > Really ? > > I think David is comparing the .get syntax to the if-else syntax. > > First of all, he got the if-else wrong, which is a sign that .get is > easier to use, at least for writers and quite likely for readers. > > Second I agree that ".get" is easier to read and understand > (especially with explicit default, as you advocate). It's even more > stark if you're after a component of the list element: > > val = mylist[N if len(mylist) > N else default].content > > vs. > > val = mylist.get(N, default).content > > > Let me try again :-) > > > > Getting an item from a bag of unknown items can easily fail, > > because you don't what's in the bag until you try to find > > the item. > > > > Trying to access an item from a non-existing bucket in an array > > will always fail. You know that in advance, since the bucket > > doesn't exist as per the array properties. You don't have to > > try finding it first. > > But this isn't a C array. You don't know the length from the syntax. > So you have to "do work" to discover the bucket isn't there before you > access -- or you can delegate to the interpreter and catch IndexError. > Given how precise IndexError is (it only catches integer arguments > that fall outside the range of the array), I don't really see the > argument for refusing to encapsulate the try in a .get method, or that > its semantics differ from explicit bounds-checking. > > It seems to me that you're expressing a preference for "look before > you leap" over "easier to ask forgiveness than permission" in the case > of array indicies, which is a stylistic thing. It's a style I prefer > in this case, but I can also see how other people would prefer a > different style, one that makes sense to encapsulate in .get. Is > there something more than stylistic preference that I'm missing? I was trying to explain why dict.get() is different than the suggested list.get(). dict.get() was added since the lookup is expensive and you want to avoid having to do this twice in the common case where the element does exist. It was not added as a way to hide away an exception, but instead to bypass having to generate this exception in the first place. dict.setdefault() has a similar motivation. list.get() merely safes you a line of code (or perhaps a few more depending on how you format things), hiding away an exception in case the requested index does not exist. If that's all you want, you're better off writing a helper which hides the exception for you. I argue that making it explicit that you're expecting two (or more) different list lengths in your code results in more intuitive and maintainable code, rather than catching IndexErrors (regardless of whether you hide them in a method, a helper, or handle them directly). So this is more than just style, it's about clarity of intent. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 28 2020) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ 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/LXWFEOTZUORVTFJXT4ILNUQK2RGBJJDP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
This is a continuation of my previous post. I wrote:
Here's an example of how the new dunder might work in practice.
>
> class A:
> __keyfn__ = None
> def __setitem__(self, val, x=0, y=0, z=0):
> print((val, x, y, z))
>
> >>> a = A()
> >>> a[1, z=2] = 'hello'
> ('hello', 1, 0, 2)
>
To continue, suppose that True is the default value for __keyfn__.
Consider now
class C:
__keyfn__ = True
def __setitem__(self, *argv, **kwargs):
print(f'argv={argv} | kwargs={kwargs}')
Here's one option for what should happen.
>>> c = C()
>>> c[1] = 'val'
argv=(1, 'val') | kwargs={}
>>> c[1, 2] = 'val'
argv=((1, 2), 'val') | kwargs={}
>>> c[a=1] = 'val'
TypeError: __keyfn__ got unexpected keyword argument 'a'
By the way, I've not tested this code.
In short, the present behaviour continues, except that that the compile
time error
>>> c[a=1] = 'val
SyntaxError: invalid syntax
is replaced by the run-time error
>>> c[a=1] = 'val'
TypeError: __keyfn__ got unexpected keyword argument 'a'
Some of us want
>>> d = dict()
>>> d[a=1] = 'val'
to raise an exception. I've just described how having True as the default
value for __keyfunc__ allows that to happen, should the Python community so
decide.
I hope this message helps.
--
Jonathan
___
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/RNQFT4USRCTYTSLAUNPTWGMC6WLZEPKH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull wrote: > > Paul Moore writes: > > > Furthermore, I'd be very, very strongly opposed to having x[i, > > default=d] be a way of supplying a default result if i isn't present > > in *any* subscriptable class, and particularly in dict as an > > equivalent for x.get(i, d). It's redundant, > > True, but not really fair under my assumption that `x[i, default=d]` > becomes the accepted way of doing it generally. dict.get would be a > legacy in that case. So one of [,default=] and dict.get is redundant. Why make the existing way the redundant one? What's the actual benefit? Particularly as *other* uses of keywords in indexes may well want to allow general keywords (Pandas named columns, for example) so we can't reasonably reserve "default" to mean a default value in the general case. Conversely, having a get method (if it exists) behave like the stdlib dict.get seems a reasonable application of duck typing. > How do you folks feel about list.get and tuple.get (I expect many > folks will think differently about these because tuples are > immutable), and more generally Sequence.get? I'm indifferent to list.get. I've never felt any need for it, and it's easy to implement if someone wants it (as you note in another mail). Making it a list method just means it doesn't work as well as a standalone function (in the sense that it's not going to support other types via duck typing). I see absolutely no point in tuple.get, it seems like the only reasons for it would be over-generalisation, or as a workaround for the fact that methods don't duck-type (x.get(i, default) where you don't know if x is a list or tuple - a get *function* would of course handle this perfectly via duck typing). > > confusing, and unlike any other language I'm familiar with (all > > IMO, if that's not obvious...). > > All this opposition is interesting. For reasons similar to those > expressed by MAL for sequences I rarely use dict.get, let alone want > list.get. To me it usually just feels wrong to be getting something > that might not be there, and then leaving it that way. I use > defaultdict much more than I use dict.get. I use dict.get a lot - as MAL says, not being sure if a particular key is present in a dict is perfectly normal, in contrast to not being sure if an index is valid for a list. Consider that "key in dict" is a language feature, but there's no "index in list" syntax... > Regarding the statement that it's "unlike any other language," I > suspect that's true; the only possible exception would be Lisps, but I > think the argument that they don't have true indexing ends it. Partly > by analogy to Lisp, I think of indexing as an optimized case of > function call (which is how it's implemented in Python! That's just > an amusing observation, not intended seriously.) The square brackets > basically say "you can expect this operation to be O[1], almost always > with small c" for appropriate values of "small". So this syntax > doesn't bother me, given that functions support arbitrary keywords. Lisp is an exception to most things :-) > I guess all this makes me an extremist. Doesn't stop me from liking > the Python you prefer just as well, though. :-) :-) Paul ___ 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/XP35WDTDWDNR3JZORLCQKCUUS3QZQ56F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
M.-A. Lemburg writes: > On 27.08.2020 17:53, David Mertz wrote: > > Suppose we didn't have dict.get(). I would then probably write: > > > > val = mydict[key] if key in mydict else None > > > > Likewise, since we don't have list.get(), I would write: > > > > val = mylist[N] if len(mylist) >- N-1 else None > > > > Neither of those is impractical, but in both cases .get(key) seems to > > express the intent in a more obvious way. > > Really ? I think David is comparing the .get syntax to the if-else syntax. First of all, he got the if-else wrong, which is a sign that .get is easier to use, at least for writers and quite likely for readers. Second I agree that ".get" is easier to read and understand (especially with explicit default, as you advocate). It's even more stark if you're after a component of the list element: val = mylist[N if len(mylist) > N else default].content vs. val = mylist.get(N, default).content > Let me try again :-) > > Getting an item from a bag of unknown items can easily fail, > because you don't what's in the bag until you try to find > the item. > > Trying to access an item from a non-existing bucket in an array > will always fail. You know that in advance, since the bucket > doesn't exist as per the array properties. You don't have to > try finding it first. But this isn't a C array. You don't know the length from the syntax. So you have to "do work" to discover the bucket isn't there before you access -- or you can delegate to the interpreter and catch IndexError. Given how precise IndexError is (it only catches integer arguments that fall outside the range of the array), I don't really see the argument for refusing to encapsulate the try in a .get method, or that its semantics differ from explicit bounds-checking. It seems to me that you're expressing a preference for "look before you leap" over "easier to ask forgiveness than permission" in the case of array indicies, which is a stylistic thing. It's a style I prefer in this case, but I can also see how other people would prefer a different style, one that makes sense to encapsulate in .get. Is there something more than stylistic preference that I'm missing? ___ 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/GFJRG7JALYCJNKVQNV3KCHQAADNG7GLV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
Alex Hall writes: > Do you not usually refactor duplicated code? Taking "you" as generic: it depends. > What *do* you refactor? Code is expressive. In cases where the duplication results in equivalent objects, I habitually refactor. When the process is important to express and the duplication is syntactic, I will prefer an explicit but idiomatic syntax repeated in unrelated contexts. Thus I generally wouldn't consider your list to be "duplicated code that cries out for refactoring." When the process is complex then I'd refactor. Detecting an out of bounds index is complex enough because of fenceposts and negative indicies, although I probably wouldn't notice the negative indicies until they bit me (and in that case wouldn't refactor until bitten). > > I'd find it more interesting if there were a larger variety of > > cases > > This sort of sounds like the problem. The examples aren't meant to be > interesting. "You [both] keep using that word but I do not think [Steven] means what you think it means." (pace, Inigo) I find the long list of examples with mostly identical syntax *unpersuasive* for two reasons. First, if you're going to bounds check array indicies explicitly (rather than allow IndexError to "bubble up"), we already have a facility for doing that precisely and accurately: catch IndexError. That catches out of bounds indicies and nothing else[1], and it handles negative indicies correctly. list.get can't be implemented much more efficiently than by using try ... except IndexError, and invoking it imposes attribute lookup and function call overhead so I guess you net approximately nothing on time, and a little bit of space. If you care so much about either time or space, you'd implement inline, something like: value = lst[index] if - (N := len(lst)) <= index < N else default try ... except IndexError is TOOWTDI now, it's as readable as .get and more readable than the inline version, so introducing list.get would be redundant. Second, I can see why people would want it (see my reply to MAL), I just don't want it myself, and implementing your own *correctly* as a function is trivial: def get(container, subscript, default): try: return container[subscript] except (IndexError, KeyError): return default It follows that I think dict.get is a YAGNI, at least since the introduction of KeyError, and definitely now that we can write y = mydict[x] if x in mydict else default Footnotes: [1] It turns out that slice bounds can't be out of bounds, they simply get truncated, in the degenerate case to the empty slice. ___ 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/2LYGWAUDPZJZW5BTEKVI7ZPL6S3J32L5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
David Mertz writes: > I support named indices. But I strongly oppose using them in list, > tuple, or dict themselves. So `mylist[99, default=4]` would still > be a syntax error (or maybe a different exception). I don't think it can be a SyntaxError because you can't always know that mylist is a builtin list. list.__getitem__(self, ...) gets called and it tells you "TypeError: __getitem__() takes no keyword arguments", as it does now. (Just for the record. I bet you realized that within nanoseconds of hitting "send". ;-) Paul Moore writes: > Furthermore, I'd be very, very strongly opposed to having x[i, > default=d] be a way of supplying a default result if i isn't present > in *any* subscriptable class, and particularly in dict as an > equivalent for x.get(i, d). It's redundant, True, but not really fair under my assumption that `x[i, default=d]` becomes the accepted way of doing it generally. dict.get would be a legacy in that case. How do you folks feel about list.get and tuple.get (I expect many folks will think differently about these because tuples are immutable), and more generally Sequence.get? > confusing, and unlike any other language I'm familiar with (all > IMO, if that's not obvious...). All this opposition is interesting. For reasons similar to those expressed by MAL for sequences I rarely use dict.get, let alone want list.get. To me it usually just feels wrong to be getting something that might not be there, and then leaving it that way. I use defaultdict much more than I use dict.get. Regarding the statement that it's "unlike any other language," I suspect that's true; the only possible exception would be Lisps, but I think the argument that they don't have true indexing ends it. Partly by analogy to Lisp, I think of indexing as an optimized case of function call (which is how it's implemented in Python! That's just an amusing observation, not intended seriously.) The square brackets basically say "you can expect this operation to be O[1], almost always with small c" for appropriate values of "small". So this syntax doesn't bother me, given that functions support arbitrary keywords. I guess all this makes me an extremist. Doesn't stop me from liking the Python you prefer just as well, though. :-) ___ 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/PR7YZYZXHA6EYCH4PROSNN3HGG3VYLWI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
On Thu, Aug 27, 2020 at 07:10:38PM +0200, Alex Hall wrote: > On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote: > > > Personally, I found your examples underwhelming because they're mostly > > repetitions of the same pattern. > > > > That's surprising to me. When I see the same pattern over and over that's > when I most want to refactor into a common function/method. The repetition > is annoying and the solution is easy and obvious. The repetition doesn't go away just because you give it a name. It's just easier to manage. > If the cases were all > different it'd be much more complicated and chances are there wouldn't be a > simple function that covered all cases. > > Do you not usually refactor duplicated code? What *do* you refactor? Depends on what the code is. If it's as trivial as a try...except with a single operation inside each block, it's hardly worth the bother to add an extra level of indirection, an extra function, just to reduce what is effectively a two-liner (albeit one which is commonly spread over four lines) to a one-liner: # Before try: x = L[index] except IndexError: x = "" # After x = get(L, index, "") Save a line of code, replace it with one more function to read, document and test. Instead of having to read a two (four) line try...except block where everything is explicitly in front of my eyes, I have to read a fairly bland and generic-looking "get" function where I'm not sure *precisely* what it does witout reading the docs. Get what? Does it support negative indices? Can it fail? If I change L to a deque will it continue to work? I'm not *against* it. I think if lists already had the method I wouldn't object to its existence. I'm just finding it hard to care, and I think that's probably the main issue you are up against. This doesn't have a compelling benefit, it's quite marginal, at least in the use-case above. That's my opinion, others may disagree. > I'd find it more interesting if there > > were a larger variety of cases > > > > This sort of sounds like the problem. The examples aren't meant to be > interesting. You're asking why people aren't interested in solving this issue, you wonder why few people are terribly interested in it, and now you're saying that its not supposed to be interesting. I think that explains the relative lack of interest :-) That's just my two cents though, others may feel differently. -- Steve ___ 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/NESSUAHBZDGF3LGXUYT3YVM3FKLS5UZE/ Code of Conduct: http://python.org/psf/codeofconduct/
