Sorry, I forgot that you dropped the suggestion to make it an insert
operator and are only asking for an append operator.
I see no benefit to this, because += already is an elegant way to extend a
list, which is more flexible than append. Yes, if the right-hand is an
iterable and should be
On Thu, Jun 14, 2018, 7:24 PM Mikhail V wrote:
> what haven't we repeated in this thread yet? Motivation was explained.
>
You have repeated your explanations a few times. It isn't convincing.
It seems to me that your main complaint is that strings are iterable,
though you haven't expressed it
On Fri, Jun 15, 2018 at 1:04 AM, Michael Selik wrote:
[..]
> In case I need to clarify:
> 1. You're duplicating current clear and more flexible syntax.
> 2. Your proposed operators are confusing when compared with their meanings
> elsewhere.
what haven't we repeated in this thread yet?
There's nothing wrong with your ideas if you were designing a language from
scratch. However, Python has a long history and many tools and uses for the
same operators you are considering. And even has a current "insert"
operator (slice assignment).
When adding a new feature, you need to consider
I should note that numeric code "that works" is often much subtler than it
appears at first glance. So, for educational purposes, I'll point out some
of what _wasn't_ said about this crucial function:
[Tim]
> import mpmath
> from math import fmod
> # Return (n, x) such that:
> #
On Wed, Jun 13, 2018 at 6:45 PM, Mikhail V wrote:
> Another point is that people do like augmented operators much and for the
> append - there are so many advises like: hey, use L += [item] !
>
another data point -- in teaching, a number of newbie students do exactly
that.
Actually, they do:
On Thu, Jun 14, 2018 at 4:03 AM Daniel Sánchez Fábregas
wrote:
> My idea consist in:
> Adding a method to perform type checking in traceback objects
> When printing stack traces search for mistyped arguments and warn about
> them to the user.
>
Isn't it faster and far more reliable to run your
On 14/06/2018 13:33, Steven D'Aprano wrote:
> On Thu, Jun 14, 2018 at 09:27:05AM +, Steve Barnes wrote:
>
> [...]
>> What I would like to suggest is extending the dir built-in to allow an
>> optional filter parameter that takes fnmatch type wild card as an
>> optional filter. Then I could
On Thu, Jun 14, 2018 at 01:03:37PM +0200, Daniel Sánchez Fábregas wrote:
> My idea consist in:
> Adding a method to perform type checking in traceback objects
> When printing stack traces search for mistyped arguments and warn about
> them to the user.
Can you give a concrete example of how this
On Thu, Jun 14, 2018 at 09:27:05AM +, Steve Barnes wrote:
[...]
> What I would like to suggest is extending the dir built-in to allow an
> optional filter parameter that takes fnmatch type wild card as an
> optional filter. Then I could use:
>
> >>> dir(mpmath, "*sin*")
>
> To narrow
Oleg Broytman wrote:
import re as regular_expressions_operations
Personally I would use
import re as ridiculously_enigmatic_operations
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Steven D'Aprano wrote:
So math.sin is little different from math_sin, but the fact that math
alone is a module, a first-class object, and not just a prefix of the
name, makes a big difference.
This is important because it provides ways of referring to
things in the module without having to
My idea consist in:
Adding a method to perform type checking in traceback objects
When printing stack traces search for mistyped arguments and warn about
them to the user.
Don't know if it is in the roadmap, but seems that have a good
cost/benefit ratio to me.
Just changing the subject line here, to keep things on topic
Sincerely,
Ken;
-- Forwarded message -
Date: Thu, 14 Jun 2018 17:29:03 +1000
From: Steven D'Aprano
To: python-ideas@python.org
Subject: Re: [Python-ideas] Give regex operations more sugar
Message-ID:
On Thu, Jun 14, 2018 at 12:22:45AM -0700, Brendan Barnwell
wrote:
> If anything, I think the name "re" is too short
> and cryptic and should be made longer!
import re as regular_expressions_operations
> --
> Brendan Barnwell
Oleg.
--
Oleg Broytmanhttps://phdru.name/
On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell
wrote:
> as we all know, namespaces are one
> honking great idea!
Flat is better than nested, so additional string.re subnamespace is
not needed.
> --
> Brendan Barnwell
Oleg.
--
Oleg Broytmanhttps://phdru.name/
Currently when working with interactive sessions using the dir() or
dir(module) built in is incredibly useful for exploring what
functionality is available in a module. (Especially the regrettable
libraries or modules that add really valuable functionality but have no
or limited docstrings).
On Thu, Jun 14, 2018 at 6:21 PM, Steven D'Aprano wrote:
> On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell wrote:
>> On 2018-06-13 23:37, Chris Angelico wrote:
> [...]
>> >How is this materially different from:
>> >
>> >"some string".re_match(...)
>> >
>> >? It's not a grouped namespace
On Thu, Jun 14, 2018 at 12:12:34AM -0700, Brendan Barnwell wrote:
> On 2018-06-13 23:37, Chris Angelico wrote:
[...]
> >How is this materially different from:
> >
> >"some string".re_match(...)
> >
> >? It's not a grouped namespace in any technical sense, but to any
> >human, a set of methods that
On Thu, Jun 14, 2018 at 06:33:14PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >- should targets match longest first or shortest first? or a flag
> > to choose which you want?
> >
> >- what if you have multiple targets and you need to give some longer
> > ones priority, and some shorter
On 2018-06-14 00:10, Steven D'Aprano wrote:
Rather than add eight new methods, we could allow the existing string
methods to take pattern objects as arguments. That gives us potentially:
count, endswith, find, index, lstrip, partition, replace, rfind,
rindex, rpartition, rsplit,
On 2018-06-13 23:37, Chris Angelico wrote:
str.re can be a descriptor object which "knows" which string
instance it is bound to. This kind of thing is common in many libraries.
Pandas for example has all kinds of things like df.loc[1:3],
df.column.str.startswith('blah'), etc. The "loc"
On Wed, Jun 13, 2018 at 11:12:43PM -0700, Brendan Barnwell wrote:
> >How would this work? If I say:
> >
> >"My string".re.match(...)
> >
> >if str.re is "just a namespace" how will the match function know the
> >string it is to operate on?
>
> str.re can be a descriptor object which
On Thu, Jun 14, 2018 at 4:12 PM, Brendan Barnwell wrote:
> On 2018-06-13 22:29, Steven D'Aprano wrote:
>>
>> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>>
>>> > Attaching an entire module to a type is probably worse than
>>> > adding a slew of extra methods to the type.
>>>
Steven D'Aprano wrote:
- should targets match longest first or shortest first? or a flag
to choose which you want?
- what if you have multiple targets and you need to give some longer
ones priority, and some shorter ones?
I think the suggestion made earlier is reasonable: match
them in
On 2018-06-13 22:29, Steven D'Aprano wrote:
On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
> Attaching an entire module to a type is probably worse than
> adding a slew of extra methods to the type.
>
Not my point.
str.re would not be the re module, just a namespace where
On Wed, Jun 13, 2018 at 10:43:43PM +0200, Michel Desmoulin wrote:
> str.replace come to mind. It's a annoying to have to chain it 5 times
> while we could pass optionally a tuple.
Its not so simple. Multiple replacements underspecifies the behaviour.
The simplest behaviour is to have
27 matches
Mail list logo
