Could this idea be used to specify the default factory of a dataclass
field? For example,
@dataclass
class X:
x: list[int] = deferred []
instead of
@dataclass
class X:
x: list[int] = field(default_factory=list)
If so, it might be worth adding to your proposal as another common
Would it be desirable to save the state of functools.cache between program
executions? For example, by providing cache_state property on the cache
that is pickle-able.___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
This was discussed here: https://bugs.python.org/issue46757
This came up because I had a dataclass subclass to flax.linen.Module that
had its own post-init. When I figured out that I needed to call super, I
did so. Later, when I refactored my code to remove the superclass, the
super-call
I humbly disagree that any of what you wrote is "obvious".
On Fri, Feb 11, 2022 at 4:41 AM Steven D'Aprano wrote:
> On Thu, Feb 10, 2022 at 02:27:42PM -0800, Neil Girdhar wrote:
>
> > AttributeError: can't set attribute 'f'
> >
> > This can be a pain to
Hello, consider:
class C:
@property
def f(self) -> int:
return 2
class D(C):
pass
D().f = 2
Gives:
Traceback (most recent call last):
File "/home/neil/src/cmm/a.py", line 10, in
D().f = 2
AttributeError: can't set attribute 'f'
This can be a pain to debug when the
On Tue, Feb 8, 2022 at 5:50 AM Paul Moore wrote:
> On Tue, 8 Feb 2022 at 00:09, Neil Girdhar wrote:
> >
> > Currently, some type checkers rightly complain that a method is
> decorated with abc.abstractmethod when the class's type does not inherit
> from ABCMeta. Adding a
Currently, some type checkers rightly complain that a method is decorated
with abc.abstractmethod when the class's type does not inherit from
ABCMeta. Adding a metaclass is a fairly heavy dependency since you're
forced to poison all of your other metaclasses with the same base
metaclass. It
Even if f{1} creates a frozenset, I don't think f{} should create a
frozenset. I think it makes more sense to keep f{1: 2} open for frozendict
if it ever makes it in. Also, {} should be consisten with f{} (both should
create dicts). If you want an empty frozenset, you would have to do it the
Totally agree with this. I think both of points should be clarified in the
documentation: https://docs.python.org/3/library/functions.html#staticmethod
Namely that:
* Nearly all uses of static methods should instead be class methods, and
* The main exception is setting an ordinary function as a
+1 for appdirs. It's a shame that more projects don't yet use it.
On Wednesday, December 15, 2021 at 9:03:07 AM UTC-5 Matt del Valle wrote:
> There is appdirs which does precisely what you're looking for:
>
> https://pypi.org/project/appdirs/
>
> That said, it does seem to be a core bit of
FYI: The flake8 project refuses to add toml configuration file support in
part because there is no standard library toml
module: https://github.com/PyCQA/flake8/issues/234#issuecomment-812800722
The thread was eventually locked by the project owner, and a project sprang
up to try to address
On Monday, December 6, 2021 at 6:28:10 PM UTC-5 Steven D'Aprano wrote:
> On Mon, Dec 06, 2021 at 11:57:11AM -0800, Neil Girdhar wrote:
>
> > Has anyone done a survey of, say, the cpython library codebase to see
> what
> > proportion of arguments lists would signi
Has anyone done a survey of, say, the cpython library codebase to see what
proportion of arguments lists would significantly benefit from this PEP
given as a proportion of the total codebase? In all the Python I've ever
written or seen, I can only thing of one example of a custom sentinel ever
On Wednesday, December 1, 2021 at 1:18:33 AM UTC-5 Chris Angelico wrote:
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound
I wish this had gotten more attention! :)
___
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
> I propose (not for the first time) that similarly concatenating an
unknown number of iterables or dicts should be possible via comprehensions:
I'm really happy to see this feature proposal come up again! Every time,
it seems this feature is even more intuitive to even more people, and I'm
I like this comment.
The proposal to change list and str is way too ambitious. But some minor
cleanup might not be so pernicious?
On Saturday, November 13, 2021 at 5:31:49 PM UTC-5 Mike Miller wrote:
>
> I like this idea and disappointed it always gets a negative reaction. One
> of my
>
As someone who originally worked on implementing PEP 448, I wanted to chime
in that while I agreed with the decision to be conservative when adding new
features, I originally hoped that [*x for x in xs] would eventually make
its way into Python. To me, it seemed intuitive and I hoped people
Tue, Jun 1, 2021 at 6:47 AM Neil Girdhar wrote:
>
> On Tue, Jun 1, 2021 at 6:28 AM Oscar Benjamin
> wrote:
> >
> > On Tue, 1 Jun 2021 at 10:53, Neil Girdhar wrote:
> > >
> > > On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
> > > wrote:
> &
On Tue, Jun 1, 2021 at 6:28 AM Oscar Benjamin
wrote:
>
> On Tue, 1 Jun 2021 at 10:53, Neil Girdhar wrote:
> >
> > On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
> > wrote:
> > >
> > > On Tue, 1 Jun 2021 at 05:16, Neil Girdhar wrote:
> > &
On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
wrote:
>
> On Tue, 1 Jun 2021 at 05:16, Neil Girdhar wrote:
> >
> > Hi Oscar,
> >
> > The problem that the original poster was trying to address with
> > additional syntax is the automatic naming of symbols. He wa
Have you considered using the JAX library's trick of decorating functions
to provide automatic symbols?
For example, your problem could be done in current Python with an
appropriately-coded library:
@symbolic
def f(x, a, b, c):
return a * x ** 2 + b * x + c
sentinel = Sentinel()
I agree with the comment about removing full justification.
Also, I think the Masonite docs' navigation is far superior to the Python
docs. I like the full contents on the left, along with the version button,
and the local jump on the right. The python docs require you to navigate
somehwere
This is a great discussion. However, there's one issue that seems to
be getting lost. Consider this library structure:
test/lemon
test/lemon/__init__.py
test/module.py
where test/module.py is:
__all__ = ['lemon']
def lemon():
pass
and test/__init__.py is:
from .module import *
from
I like the idea of improving the way interfaces are exported in Python. I
still don't know what the standard is today.
Some of my favourite projects like Jax have started tucking their source in
a _src directory: https://github.com/google/jax/tree/master/jax/_src, and
then importing the
On Thu, Jan 21, 2021 at 7:19 PM Chris Angelico wrote:
>
> On Fri, Jan 22, 2021 at 11:10 AM Random832 wrote:
> >
> > On Thu, Jan 21, 2021, at 18:48, Chris Angelico wrote:
> > > Note that slicing is NOT easy. The proposed semantics for a reversed
> > > enumeration would make slicing extremely odd.
On Thu, Jan 21, 2021 at 3:13 PM Christopher Barker wrote:
>
> On Thu, Jan 21, 2021 at 10:43 AM Neil Girdhar wrote:
>>
>> > > I've seen this proposed here before. The general idea is that some
>> > > iterator transformations (like enumerate) should return se
On Thu, Jan 21, 2021 at 1:26 PM Chris Angelico wrote:
>
> On Fri, Jan 22, 2021 at 5:21 AM Neil Girdhar wrote:
> >
> > I've seen this proposed here before. The general idea is that some
> > iterator transformations (like enumerate) should return sequences when
> >
I've seen this proposed here before. The general idea is that some
iterator transformations (like enumerate) should return sequences when
they're applied to sequences. I think it's good idea, but it adds
complexity and work, which I guess needs to be justified on a case-by-case
basis.
In
Thanks for the correction Mark, I didn't realize that!
Shantanu is right about what my ask was meant to be. I guess I'm nowhere
near the first to propose things like this and there's a lot of discussion
in various threads about it that I wasn't aware of.
Best,
Neil
On Monday, January 18,
I've been following along various issues in mypy regarding challenges with
getting the ABCs in numbers
(https://docs.python.org/3/library/numbers.html) working. Currently,
there's a lot of clever logic in the functions int, float, and complex.
Currently, inheriting from Real doesn't give you
The way I understand it, multiple dispatch is programming language feature
wehreby a function or method overload is chosen based on run time types.
Python already has single dispatch (functools.singledispatch). It also has
the concept of overloads for type annotations (typing.overload).
My
You might be interested in https://pypi.org/project/extended-int/
On Sunday, September 6, 2020 at 12:41:04 AM UTC-4 Cade Brown wrote:
> Fair enough, I guess people have managed without it and there are plenty
> of "good-enough" solutions for this that can be used in the place.
>
> I can see
Julia's burgeoning popularity has renewed my interest in dynamic dispatch.
It seems to me that many methods that have been written as a giant switch
on types can more clearly be written using dynamic dispatch. It was
prettty exciting to see that Python already has single dispatch built in,
Can you not just use
https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.random_permutation
?
On Saturday, August 1, 2020 at 2:26:23 PM UTC-4 Ram Rachum wrote:
> I would also prefer a `random.shuffled` function. The reason I didn't
> propose it is because there's usually
What the future of this?
I looked at type annotations in networkx recently (
https://github.com/networkx/networkx/pull/4014), and I wanted to keep
things simple, so I proposed and implemented
Graph[NodeType]
However, I knew that they may ultimately want
Graph[NodeType, EdgeTypedDict,
Are all objects in Python equality-comparable? I know that you can delete
__hash__ to make an object unhashable (e.g., dicts). If so, this is a
great addition.
On Saturday, July 4, 2020 at 5:26:45 PM UTC-4, Joao S. O. Bueno wrote:
>
>
>
> On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka >
Oh, I guess there's gettext…
On Monday, June 29, 2020 at 5:04:05 AM UTC-4, Neil Girdhar wrote:
>
> PEP 622 proposes a special use for _: to match anything, discarding the
> whatever value matches. (If I understand.) This aligns with the way _ is
> conventionally used in othe
PEP 622 proposes a special use for _: to match anything, discarding the
whatever value matches. (If I understand.) This aligns with the way _ is
conventionally used in other statements. This special use in case
statements feels weird given that _ is otherwise just an ordinary
variable. It
Can you use SortedDict.peekitem(index):
http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html ?
As other people are saying, the computational complexity of CPython's dict
is linear for this operation. SortedDict does it in logarithmic time.
On Friday, June 26, 2020 at 1:32:58 PM
I'm just curious if there was a reason why Boolean was omitted from the
numeric tower in the numbers library? It seems that builtins.bool and
numpy.bool_ would both be elements of Boolean, and Boolean itself would be
Integral?
Best,
Neil
___
Nevertheless, it's nice to see how powerful the new parser is!
Any chance this would allow us to have a multi-line with statement?
with self.context_manager_one(some, parameters, that, are, passed) \
as return_value_one, \
self.context_manager_two(self.p, slice(None),
Have you seen PEP 505? https://www.python.org/dev/peps/pep-0505/
I'm still praying they add "??=" every time I need it.
Maybe if someone proposed just that operator, it would go a long way
towards simplifying code without resulting in endless debates?
Best,
Neil
On Sunday, May 17, 2020 at
I'm just curious, but is it usual for errors to be one-based rather than
zero-based? If I do zip(*iterables, strict=True), then "argument 1 is too
long" refers to iterables[0]?
On Friday, May 1, 2020 at 2:20:12 PM UTC-4, Brandt Bucher wrote:
>
> I have pushed a first draft of PEP 618:
>
>
I'm just curious: what is the downside of calling super with kwargs?
Usually when I define a class, the first I write is
def __init__(self, **kwargs):
super().__init__(**kwargs)
just in case I want to use the class in cooperative inheritance. I always
thought it couldn't hurt?
I might be
Dear Pythoners,
class X:
def __init__(self, x, **kwargs):
super().__init__(**kwargs)
print(x, kwargs)
@dataclass
class Y(X):
y: int
Y(1) # What should happen?
Y(1, 2) # What should happen?
I feel like it would be nice to be able to use dataclasses more often
, March 22, 2020 at 2:01:18 PM UTC-4, Neil Girdhar wrote:
>
> I really like this idea. It fixes the weirdness whereby cmath is for
> complex numbers, and math is for real numbers and integers. I like
> separating them into three categories.
>
> One suggestion: Consider
I really like this idea. It fixes the weirdness whereby cmath is for
complex numbers, and math is for real numbers and integers. I like
separating them into three categories.
One suggestion: Consider generalizing binom to the multinomial coefficent.
def binom(n, *ks):
# Returns n! /
Reviving this old thread since this is hitting me again today. Is there
any momentum on extending tuple unpacking to within slices?
On Thursday, December 21, 2017 at 4:33:07 PM UTC-5, Neil Girdhar wrote:
>
> I didn't think of this when we were discussing 448. I ran into this
> to
I also would prefer richer exceptions especially if it can be done without
introducing any other problems.
In the same vein, I once suggested a richer inheritance failure message
(this, basically: https://github.com/NeilGirdhar/inheritance_graph), for
which if I remember correctly Guido was
You may be interested in the excellent traitlets library:
https://traitlets.readthedocs.io/en/stable/
On Friday, February 7, 2020 at 11:11:59 AM UTC-5, Soni L. wrote:
>
> I'd like to see traits some day, with a syntax similar to this one:
>
> trait Trait:
>def x(self):
> raise
On Tuesday, December 3, 2019 at 7:54:03 PM UTC-5, Jan Bakuwel wrote:
>
> Hi Guido,
>
> On 4/12/19 1:06 pm, Guido van Rossum wrote:
> > I was playing the devil's advocate in jest. There is no way this will
> > be added to Python, for a large variety of sociological and software
> >
I really like this feature suggestion and I would definitely use it if it
were available.
It might be easiest to have the repr helper do as much as it can, but give
the user the flexibility to override things with varying levels of
precision. For example:
def kwargs(obj,
keys:
This is very cool, well thought-out, and solves an important problem. I
would have definitely benefited from Python having better pattern matching.
As an idealist though, if you're going to add pattern matching, why not
just do it completely? I agree that your proposal would be useful in some
I'm just glancing at this thread, but it sounds like you want to add the
quickselect algorithm to the standard library. As you point out in
another message, quickselect is faster than quicksort: it is linear time
(provided the pivot is chosen by median of medians) whereas quicksort is
On Tuesday, November 19, 2019 at 3:06:26 PM UTC-5, Paul Moore wrote:
>
> On Tue, 19 Nov 2019 at 19:03, Random832 > wrote:
> >
> > On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote:
> > > Because you don't have to create the context manager directly in the
> > > with statement
> >
> >
Some people find this legal syntax confusing:
A in B < C
(It means A in B and B < C.)
I feel like most code reviews would not allow this kind of code to be
checked in, at least without a comment explaining what the code does. What
are the motivating reasons for allowing this syntax? Is
I really like this idea. Once you've already decided to raise an
exception, does it really cost much to try to raise a more helpful one?
And helpful exception messages make programming a lot less painful, and a
lot more of a joy.
On Tue, Oct 22, 2019 at 2:43 PM Mike Miller
wrote:
>
> On
I would use it, and I prefer | for the reasons given by Stephen, MRAB, and
the other proponents.
On Monday, October 21, 2019 at 1:08:32 AM UTC-4, Andrew Barnert via
Python-ideas wrote:
>
> On Oct 20, 2019, at 21:10, Stephen J. Turnbull <
> turnbull...@u.tsukuba.ac.jp > wrote:
> >
> > I'm not
On Fri., Oct. 11, 2019, 2:38 a.m. Neil Girdhar,
wrote:
>
>
> On Fri, Oct 11, 2019 at 2:28 AM Andrew Barnert wrote:
>
>> > On Oct 10, 2019, at 22:13, Neil Girdhar wrote:
>> >
>> > That's funny, I always thought of that as legacy. The iterator
>>
On Monday, September 30, 2019 at 12:24:30 AM UTC-4, Andrew Barnert via
Python-ideas wrote:
>
> On Sep 29, 2019, at 16:41, Steven D'Aprano > wrote:
> >
> >> On Sun, Sep 29, 2019 at 11:27:32AM +0100, Oscar Benjamin wrote:
> >>
> >> That's the point that I would make as well. What can you do
I think I agree with Serhiy, but I don't think Anders' suggestion is
workable since it's very common in __init__.py to do exactly this (import *
from local modules in order to re-export them), and you definitely don't
want to explitly foo=foo for everything. That's the whole reason you
I'll let other people comment on this wrt Python (even though I think it
looks cool and useful to me). Out of curiosity, why does frozenmap not
have the same runtime and ordering guarantees as dict?
On Thursday, September 12, 2019 at 7:47:25 AM UTC-4, Yury Selivanov wrote:
>
> Hi!
>
> I've
The documentation is beautiful.
One of the features I was looking for when evaluating parsers was the
ability to run expression on the rules. For example if you matching
"\begin{\w*}"
and \w* turns out to be "enumeration", then later when you match
"\end{\w*}"
then you want to check that that
Now that Python is beginning to embrace type annotations, is it worth
revisiting the idea of having extended integers and an integer infinity?
I found myself trying to annotate this line:
events_to_do: Union[int, float] = math.inf
where I am only including float in the union to accommodate
On Mon, Mar 4, 2019 at 3:58 PM Christopher Barker wrote:
>
>
>
> On Mon, Mar 4, 2019 at 12:41 PM Guido van Rossum wrote:
>>
>> Honestly I would rather withdraw the subtraction operators than reopen the
>> discussion about making dict more like set.
I think that's unfortunate.
>
>
> +1
>
> I
On Mon, Mar 4, 2019 at 3:22 PM Guido van Rossum wrote:
>
> On Mon, Mar 4, 2019 at 12:12 PM Neil Girdhar wrote:
>>
>> On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum wrote:
>> >
>> > * Dicts are not like sets because the ordering operators (<, &l
On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum wrote:
>
> * Dicts are not like sets because the ordering operators (<, <=, >, >=) are
> not defined on dicts, but they implement subset comparisons for sets. I think
> this is another argument pleading against | as the operator to combine two
>
I think that sequence should be fixed.
On Fri., Mar. 1, 2019, 7:12 p.m. Brandt Bucher,
wrote:
> While working through my implementation, I've come across a couple of
> inconsistencies with the current proposal:
>
> > The merge operator will have the same relationship to the dict.update
> method
Looks like a good start.
I think you should replace all of the lines:
if isinstance(other, dict):
with
if isinstance(self, type(other)):
Since if other is an instance of a dict subclass, he should be the one to
process the addition. On the other hand, if self is an instance of the
derived
On Friday, March 1, 2019 at 5:47:06 AM UTC-5, Steven D'Aprano wrote:
>
> On Fri, Mar 01, 2019 at 08:47:36AM +0200, Serhiy Storchaka wrote:
>
> > Currently Counter += dict works and Counter + dict is an error. With
> > this change Counter + dict will return a value, but it will be different
>
eable", and
could be exposed in abc. When used in combination with @abstractmethod,
it could have the above behavior.
On Sunday, February 17, 2019 at 5:28:49 AM UTC-5, Neil Girdhar wrote:
>
> Marking a method M declared in C with abstractmethod indicates that M
> needs to be *implemented
Marking a method M declared in C with abstractmethod indicates that M needs
to be *implemented* in any subclass D of C for D to be instantiated.
We usually think of overriding a method N to mean replacing one
implementation in some class E with another in some subclass of E, F.
Often, the
On Monday, January 7, 2019 at 3:16:07 AM UTC-5, Steven D'Aprano wrote:
>
> (By the way, I'm not outright disagreeing with you, I'm trying to weigh
> up the pros and cons of your position. You've given me a lot to think
> about. More below.)
>
> On Sun, Jan 06, 2019 at 11:31:30PM -0800,
Why not just use pytest?
On Wednesday, October 10, 2018 at 7:12:02 AM UTC-4, David Shawley wrote:
>
> Hi everyone and good morning to some of you,
>
> Since asyncio and the async/await syntax are both part of Python, I think
> that we should extend TestCase to support it. The simplest solution
I prefer Python's syntax.
In the Keras example, Python pays off compared to the XML or YAML or
whatever as soon as you need to define something programmatically. For
example, if your model is generated based on some other input.
Anyway, most of your time is not spent typing punctuation.
On Thu, Aug 30, 2018 at 9:03 AM Steven D'Aprano wrote:
> On Wed, Aug 29, 2018 at 09:39:05PM -0700, Neil Girdhar wrote:
>
> > Would there be any problem with changing:
> >
> > In [4]: Fraction(1, 1) ** Fraction(2, 3)
> > Out[4]: 1.0
> >
> > In [5]: F
Hey, no worries. I do think though that people should feel free to suggest
ideas even if they have never contributed anything. I read python-ideas
for the discussion. Thank you for your feedback about my suggestion.
On Thu, Aug 30, 2018 at 8:18 AM Jonathan Fine wrote:
> Hi Neil
>
> When I
Yeah, you're right, my original mail was posted on google groups. Sorry
for the trouble.
On Thu, Aug 30, 2018 at 8:15 AM Paul Moore wrote:
> Thu, 30 Aug 2018 at 12:55, Neil Girdhar wrote:
> >
> > On Thu, Aug 30, 2018 at 7:13 AM Paul Moore wrote:
> >>
> >> (
using google groups. I'm only replying to the emails that are sent to me.
I guess gmail's reply-all is gathering the google groups mail from the
thread.
> On Thu, 30 Aug 2018 at 11:28, Neil Girdhar wrote:
> >
> > But I'm only asking for fractional powers of -1, 0, and 1. Is that
> r
On Thu, Aug 30, 2018 at 7:03 AM Jonathan Fine wrote:
> Hi Neil
>
> Summary: You say something should be done. But by who? Perhaps the
> should starts with you.
>
What does this mean? Are you asking who is going to do the
implementation? I posted here to get feedback about whether it would be
Thanks for the feedback.
On Thu, Aug 30, 2018 at 7:13 AM Paul Moore wrote:
> (You're still not fixing your mail headers. Please do, it's hard to be
> bothered responding if I keep having to fix your mails in order to do
> so).
>
> On Thu, 30 Aug 2018 at 11:28, Neil
On Thu, Aug 30, 2018 at 5:51 AM Nicolas Rolin
wrote:
>
>
>
>>> Right, but we already have some special cases:
>>
>> In [8]: Fraction(2, 3) ** Fraction(3, 1)
>> Out[8]: Fraction(8, 27)
>>
>> Fraction.__pow__ already tries to return Fraction objects where possible.
>>
>
>
> I think the main point
On Thu, Aug 30, 2018 at 5:27 AM Greg Ewing
wrote:
> Neil Girdhar wrote:
> > we want branch continuity in the power.
> > After all, floating point values have some inaccuracy, and we wouldn't
> > want chaotic behavior, i.e., small changes to the power to have drastic
>
On Thu, Aug 30, 2018 at 5:11 AM Jonathan Fine wrote:
> Hi Neil
>
> We wrote
>
> >> This gives the same results as Python's Fraction, except for your
> >> example [6]. There, it gives the Fraction(0) you ask for.
> >>
> >> If the smart mathematicians and computer scientists that wrote gp/pari
>
On Thu, Aug 30, 2018 at 4:38 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Neil Girdhar writes:
>
> > There are a lot of misunderstandings in this thread. It's probably
> > best to start by reading up on the roots of unity (
> >
On Thu, Aug 30, 2018 at 4:01 AM Paul Moore wrote:
> On Thu, 30 Aug 2018 at 08:38, Neil Girdhar wrote:
> >
> > There are a lot of misunderstandings in this thread. It's probably best
> to start by reading up on the roots of unity (
> https://en.wikipedia.org/wiki/Root_of_u
There are a lot of misunderstandings in this thread. It's probably best to
start by reading up on the roots of unity (
https://en.wikipedia.org/wiki/Root_of_unity). The key ideas are that a
real number has two complex square roots, three complex cube roots, and so
on.
Normally, in Python, we
On Thu, Aug 30, 2018 at 2:09 AM Greg Ewing
wrote:
> Jeroen Demeyer wrote:
> > On 2018-08-30 06:39, Neil Girdhar wrote:
> >
> >> I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
> >
> > Why? I cannot think of any natural use case why you would
Would there be any problem with changing:
In [4]: Fraction(1, 1) ** Fraction(2, 3)
Out[4]: 1.0
In [5]: Fraction(-1, 1) ** Fraction(2, 3)
Out[5]: (-0.4998+0.8660254037844387j)
In [6]: Fraction(0, 1) ** Fraction(2, 3)
Out[6]: 0.0
I'd like these to be Fraction(1), Fraction(1), and
Is None a builtin?
In [1]: from keyword import kwlist
In [3]: 'Ellipsis' in kwlist
Out[3]: False
In [4]: 'None' in kwlist
Out[4]: True
Maybe we should change
This type has a single value. There is a single object with this value.
This object is accessed through the built-in name None. It is
significant, and non-trivial.
>>
>> What, exactly, is the difference between "minor" and "non-trivial" and
>> when did I say the harm was "significant and non-trivial"?
>>
>> [Alex Walters]
>>
>>> You will find no evidence
On Monday, July 30, 2018 at 3:55:25 PM UTC-4, Kyle Lahnakoski wrote:
>
> Rudy,
>
> I think your proposal may be very specific to iterable context managers;
>
I don't think his proposal is specific to iterable context managers. You
can have a with clause that is used in a following for clause.
My only motivation for this idea is so that I can forget about namedtuple.
Thinking about it again today, I withdraw my suggestion until I one day see
a need for it.
On Fri, Aug 10, 2018 at 10:14 PM Eric V. Smith wrote:
> On 8/10/2018 7:01 PM, Neil Girdhar wrote:
> > It woul
It would be nice if dataclasses
(https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass)
had an option to make them a sequence. This would make
dataclass(frozen=True, order=True, sequence=True)
an optionally-typed version of namedtuple. It would almost totally
supplant it
On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon wrote:
> [Neil Girdhar]
>
> I prefer partial since many programmers studied computer science
>
>
> Many did not. I studied electrical engineering and wouldn't have been able
> to tell you what the word 'partial' meant four years
ssion, but I
> think they would (or do in the case of 'lambda') harm Python. I know the
> correct term for the 'if-else' expression is a 'ternary' expression, but
> that doesn't mean Python should have used the word 'ternary' in the syntax.
>
> On Thu, Aug 9, 2018 at 12:14 PM, Neil Gi
That's a nicer solution to me.
On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin
wrote:
> I'd rather have functools.partial() to be added as a new method on
> function objects.
>
> >
> > fromfunctools importpartial
> >
> >
> > def add(x:int,y:int)->int:
> > returnx +y
> >
> >
> > add_2 =
omplicated for a small fraction of users.
There will always be a gap between Python and symbolic equation generation.
On Mon, Aug 6, 2018 at 9:03 PM Steven D'Aprano wrote:
> On Mon, Aug 06, 2018 at 02:44:24PM -0700, Neil Girdhar wrote:
>
> > This doesn't work because the logical Boolean o
By the way, these are not "partial functions", and shouldn't be called
that. These are "partial function applications".
On Saturday, August 4, 2018 at 12:03:50 PM UTC-4, Fabrizio Messina wrote:
>
>
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment
1 - 100 of 203 matches
Mail list logo
