Hi folks
I was thinking about how sometimes, a function sometimes acts on classes, and
behaves very much like a method. Adding new methods to classes existing classes
is currently somewhat difficult, and having pseudo methods would make that
easier.
Code example: (The syntax can most likely be imp
Hi,
With this kind of feature, you never know which methods are included in the
class (depending of which modules have been loaded).
I don't think this is a good idea.
2017-08-04 9:39 GMT+02:00 Paul Laos :
> Hi folks
> I was thinking about how sometimes, a function sometimes acts on classes,
> a
On 4 August 2017 at 08:39, Paul Laos wrote:
> Hi folks
> I was thinking about how sometimes, a function sometimes acts on classes,
> and behaves very much like a method. Adding new methods to classes existing
> classes is currently somewhat difficult, and having pseudo methods would make
> that
>
Hi Paul, and welcome!
On Fri, Aug 04, 2017 at 07:39:56AM +, Paul Laos wrote:
> Hi folks
> I was thinking about how sometimes, a function sometimes acts on classes, and
> behaves very much like a method.
I'm not really sure what you mean by "acts on classes". I can only think
of a function w
A friend of mine (@bcjbcjbcj on twitter) came up with an idea for an
argparse improvement that I'd like to propose for inclusion.
Currently, argparse with nargs= collects arguments into
a list (or a list of lists in the case of action="append"). I would like to
propose adding a "collection type" a
Had not this been discussed here earlier this year?
(And despite there being perceived dangers to readability in the long term,
was accepted?)
Here it is on an archive:
https://mail.python.org/pipermail/python-ideas/2017-February/044551.html
And anyway - along that discussion, despite dislikng t
On 4 August 2017 at 14:20, Joao S. O. Bueno wrote:
> Had not this been discussed here earlier this year?
>
> (And despite there being perceived dangers to readability in the long term,
> was accepted?)
>
> Here it is on an archive:
> https://mail.python.org/pipermail/python-ideas/2017-February/044
On 4 August 2017 at 10:31, Paul Moore wrote:
> On 4 August 2017 at 14:20, Joao S. O. Bueno wrote:
> > Had not this been discussed here earlier this year?
> >
> > (And despite there being perceived dangers to readability in the long
> term,
> > was accepted?)
> >
> > Here it is on an archive:
> >
On Fri, Aug 04, 2017 at 10:20:55AM -0300, Joao S. O. Bueno wrote:
> Had not this been discussed here earlier this year?
>
> (And despite there being perceived dangers to readability in the long term,
> was accepted?)
>
> Here it is on an archive:
> https://mail.python.org/pipermail/python-ideas/2
I'm not a heavy argparse user so take my opinion with a grain of salt (and
I do appreciate the time you put into proposing this), but I'm not seeing
the usefulness to classify this as so pragmatic as to outweigh adding one
more thing to explain about argparse. Since you're proposing just having a
c
I mean, it's definitely possible, but I'd argue that's actually not any
more explicit - and, in fact, args.stuff = something(args.stuff) is
arguably less explicit because it's just an arbitrary transform, rather
than being called out as "this is the wrapper element for these args."
The places wher
11 matches
Mail list logo
