06.12.19 00:09, Ethan Furman пише:
I haven't followed the main thread, but I can unequivocally state that
for-loop version is easier to read.
I completely agree.
The only thing missing to make the
intent crystal clear is one more word in the function name:
def get_first_product_item(
06.12.19 07:38, Steven D'Aprano пише:
I'm sorry, I can't tell what that is supposed to do. Is the "return {}"
supposed to be inside the loop? If so, it has been accidentally
dedented. Is it meant to be outside the loop? The "for-else" is
redundent, since there is no break.
for item in jsonl
On Fri, Dec 06, 2019 at 04:38:10PM +1100, Steven D'Aprano wrote:
> On Thu, Dec 05, 2019 at 05:40:05PM -0400, Juancarlo Añez wrote:
> > I just found this code:
> >
> > def get_product_item(jsonld_items):
> > for item in jsonld_items:
> > if item['@type'] == 'Product':
> > re
On Fri, Dec 06, 2019 at 10:24:30AM +0200, Serhiy Storchaka wrote:
> In real code this can be a fragment of the larger function and look like:
>
> for item in jsonld_items:
> if item['@type'] == 'Product':
> break
> else:
> item = {}
Sure, b
My glitch. In my mind *finditer()* returned what *findall()*, but it
returns *Match* objects.
The implementation based on *search()*. Seems appropiate.
I just looked in *_sre.c*, and *findall() *uses *search()* and is quite
optimized.
It seems that the good implementation would be to write a *fi
On Thu, Dec 5, 2019, at 12:25, Andrew Barnert via Python-ideas wrote:
> It’s unfortunate that these functions aren’t better matched. Why is
> there a simple-semantics find-everything and a match-semantics
> find-iteratively and find-one? But I don’t think adding a
> simple-semantics find-one tha
On Dec 6, 2019, at 09:51, Random832 wrote:
>
> If match objects are too hard to use, maybe they should be made more
> user-friendly? What about adding str and iterable semantics to match objects
> so it can be used as str(re.search(...)); tuple(re.search(...)); a, b =
> re.search(...)?
That’s
I notice that most(all?) of those are from pretty old modules, which
explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but it
is a fair bit of code-churn for not much real gain. I guess it comes down
to:
- How much maintenance do those modules
On 2019-12-06 3:58 p.m., Christopher Barker wrote:
I notice that most(all?) of those are from pretty old modules, which
explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but
it is a fair bit of code-churn for not much real gain. I guess i
On 2019-12-06 18:24, Andrew Barnert via Python-ideas wrote:
On Dec 6, 2019, at 09:51, Random832 wrote:
If match objects are too hard to use, maybe they should be made more
user-friendly? What about adding str and iterable semantics to match objects so
it can be used as str(re.search(...)); t
06.12.19 19:49, Random832 пише:
If match objects are too hard to use, maybe they should be made more
user-friendly? What about adding str and iterable semantics to match objects so
it can be used as str(re.search(...)); tuple(re.search(...)); a, b =
re.search(...)?
What is semantic of these
I'm torn -- on the one hand, these very old modules may as well stay frozen
in time (please double check that they aren't listed in PEP 594). On the
other hand, for modules that are still actively maintained, the exception
may as well be named Error instead of error, and a rename of error -> Error
On Fri, Dec 6, 2019, at 14:50, MRAB wrote:
> On 2019-12-06 18:24, Andrew Barnert via Python-ideas wrote:
> > On Dec 6, 2019, at 09:51, Random832 wrote:
> >>
> >> If match objects are too hard to use, maybe they should be made more
> >> user-friendly? What about adding str and iterable semantics
Serhiy Storchaka wrote:
> Thank you Kyle for your investigation!
No problem, this seemed like an interesting feature proposal and I was
personally curious about the potential use cases. Thanks for the detailed
analysis, I learned a few new things from it. (:
Serhiy Storchaka wrote:
> - cler
On Fri, Dec 6, 2019, at 15:17, Serhiy Storchaka wrote:
> 06.12.19 19:49, Random832 пише:
> > If match objects are too hard to use, maybe they should be made more
> > user-friendly? What about adding str and iterable semantics to match
> > objects so it can be used as str(re.search(...)); tuple(re
On 2019-12-06 21:16, Random832 wrote:
On Fri, Dec 6, 2019, at 14:50, MRAB wrote:
On 2019-12-06 18:24, Andrew Barnert via Python-ideas wrote:
> On Dec 6, 2019, at 09:51, Random832 wrote:
>>
>> If match objects are too hard to use, maybe they should be made more user-friendly? What about adding
On Fri, Dec 06, 2019 at 09:11:44AM -0400, Juancarlo Añez wrote:
[...]
> > Sure, but in this case, it isn't a fragment of a larger function, and
> > that's not what it looks like. If it looked like what you wrote, I would
> > understand it. But it doesn't, so I didn't really understand what it was
On Fri, Dec 6, 2019 at 1:02 PM Guido van Rossum wrote
> check that there are no *other* classes in a module that also use a
> lowercase naming convention (if there are, that module needs more thought
> before we change just the exception name).
>
I expect that will be quite common — older code
> I'm torn -- on the one hand, these very old modules may as well stay frozen
in time (please double check that they aren't listed in PEP 594)
And
> I expect that will be quite common — older code commonly uses lower case
class names
Thank, checking 594 is a good idea; I understand why you are
On Fri, Dec 6, 2019 at 5:42 PM Matthias Bussonnier <
[email protected]> wrote:
> [...]
> My original request on bpo[1] was for `re` which is actively maintained,
> but I was advised to ask for a more general policy and thoughts here as
> whether renaming of a an exception was acceptable
On Dec 6, 2019, at 16:44, Steven D'Aprano wrote:
>
> We could, I guess, eliminate the difference by adding the ability to
> peek ahead to the next value of an arbitrary iterator without consuming
> that value. This would have to be done by the interpreter, not in Python
> code,
You can easily
06.12.19 23:21, Random832 пише:
On Fri, Dec 6, 2019, at 15:17, Serhiy Storchaka wrote:
06.12.19 19:49, Random832 пише:
If match objects are too hard to use, maybe they should be made more
user-friendly? What about adding str and iterable semantics to match objects so
it can be used as str(re.
On Fri, Dec 06, 2019 at 07:27:19PM -0800, Andrew Barnert wrote:
> On Dec 6, 2019, at 16:44, Steven D'Aprano wrote:
> >
> > We could, I guess, eliminate the difference by adding the ability to
> > peek ahead to the next value of an arbitrary iterator without consuming
> > that value. This would
06.12.19 23:20, Kyle Stanley пише:
Serhiy Storchaka wrote:
> It seems that in most cases the author just do not know about
> re.search(). Adding re.findfirst() will not fix this.
That's definitely possible, but it might be just as likely that they saw
re.findall() as being more simple to use
24 matches
Mail list logo
