On Fri, Mar 29, 2019 at 2:07 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > General principle: People who complain about email are using
> > suboptimal clients, people who complain about non-email systems are
> > using suboptimal services. And there's nothing that's truly
Chris Angelico writes:
> General principle: People who complain about email are using
> suboptimal clients, people who complain about non-email systems are
> using suboptimal services. And there's nothing that's truly optimal in
> either case (some email clients do come close, but only for
Anders Hovmöller writes:
> Sure. And if library authors want to support older versions they'll
> have to vendor this into their own code,
You (indirectly) argue below that they can't, as a reason for including
the change. You can't have it both ways.
> just like always. This seems totally
On Thu, Mar 28, 2019 at 4:52 PM Steven D'Aprano wrote:
> On Thu, Mar 28, 2019 at 03:25:34PM -, Richard Whitehead wrote:
> > Chris,
> >
> > As a new member to this list, I can tell you that searching for relevant old
> > content was effectively impossible, so I'm all for some way of doing
On Fri, Mar 29, 2019 at 11:56 AM David Mertz wrote:
>
> That said, if someone writes a FAQ about this mailing list, the first answer
> can be "We are not moving discussion to GitHub / Slack / Discuss / Reddit /
> StackOverflow / MediaWiki /
> graffiti on popular buildings / etc"
>
That last
Dropping the mailing list is another topic that often comes up, and is
always a terrible idea. Every suggester had a different platform in mind,
only consistent in all being vastly worse than email for this purpose
That said, if someone writes a FAQ about this mailing list, the first
answer can
On Thu, Mar 28, 2019 at 03:25:34PM -, Richard Whitehead wrote:
> Chris,
>
> As a new member to this list, I can tell you that searching for relevant old
> content was effectively impossible, so I'm all for some way of doing that.
"Effectively impossible" is a gross exaggeration.
The old
28.03.19 19:45, Brett Cannon пише:
So I would say that a cache-clearing function convention would be a
reasonable starting point. If that turns out to not be enough for folks
we can talk about expanding it, but I think we should start small and
grow from there as needed.
So what name would
On Wed, Mar 27, 2019 at 10:34 AM Serhiy Storchaka
wrote:
> 27.03.19 15:46, Ma Lin пише:
> > re module [1] and struct module [2] have module-level cache for compiled
> > stuffs.
> > Other third-party modules may also need cache for something.
> >
> > Do we need an unified cache management API
On 28/03/2019 15:25, Richard Whitehead wrote:
Chris,
As a new member to this list, I can tell you that searching for relevant old
content was effectively impossible, so I'm all for some way of doing that.
Please can I make a more radical suggestion, though: Drop the mailing list.
How about a
>
> there's been lots of discussion about that in the past.
>
Indeed. Personally, I’m all for keeping the mailing list. See past
discussions for the advantage.
I do think it might be a good idea to move to a gitHub repo once a topic
gets past the vague idea stage to the hammer out a proposal
Hi Richard,
there's been lots of discussion about that in the past. You can check out
https://discuss.python.org, which is the current most popular idea about an
alternative. It has not been decided if the mailing lists will be dropped
or not though, as far as I know.
Lys
On Thu, Mar 28, 2019
Chris,
As a new member to this list, I can tell you that searching for relevant old
content was effectively impossible, so I'm all for some way of doing that.
Please can I make a more radical suggestion, though: Drop the mailing list.
How about a GitHub repo - a specific one (with no code),
>>> All of this would be well served by a 3rd party library on PyPI. Strings
>>> already have plenty of methods (probably too many). Having `stringtools`
>>> would be nice to import a bunch of simple functions from.
>>
>> I respectfully disagree. This isn't javascript where we are OK with
14 matches
Mail list logo
