On Thu, Dec 12, 2019 at 5:29 AM Siddharth Prajosh
wrote:
> Can we have an extra function for lists and string (and wherever slicing
> works) to explicitly mention that we're slicing?? Something like -
> *s=list(range(100));
> s.slice(10, 20).*
>
This exists already as ``itertools.islice`` and,
Those functions, ``load`` and ``loads``, for better or worse, are a
standard across many modules. Now that the standard has been established,
it's good to stick with it. Good interface design needs to consider
familiarity as well as what might be best without any history.
On Wed, Nov 27, 2019 at
The class statement works in this fashion.
foo = 1
class Bar:
foo = 2
assert foo = 1
assert Bar.foo = 2
On Fri, Jul 26, 2019, 12:19 AM Batuhan Taskaya
wrote:
> I am proposing namespace context managers with implementing `__enter__`
> and `__exit__` on dict objects. It would make closures
I've often wanted a windowing function in itertools. One exists as a recipe
in the docs. If I remember correctly, one reason this was never implemented
is that the most efficient implementation changes depending on the size of
the window.
Use a deque(maxsize=n) for large windows and tuple
On Tue, Mar 26, 2019, 1:09 PM Tim Mitchell
wrote:
> Is it time to add singledispatch for methods to the core library?
>
What's the motivation for it, beyond the fact that it's possible?
Regarding jargon, aren't Python's instance methods are already
single-dispatch, because they receive the
On Wed, Feb 27, 2019 at 10:22 AM Anders Hovmöller
wrote:
> I dislike the asymmetry with sets:
>
> > {1} | {2}
> {1, 2}
>
> To me it makes sense that if + works for dict then it should for set too.
>
> / Anders
>
> > On 27 Feb 2019, at 17:25, João Matos wrote:
> >
> > Hello,
> >
> > I would like
Any discussion of except expressions should reference PEP 463 and respond
to the arguments there.
https://www.python.org/dev/peps/pep-0463/
On Sun, Jan 27, 2019, 3:52 AM Alex Shafer via Python-ideas <
python-ideas@python.org wrote:
> Hello,
>
> I'd like to discuss an idea I had to shorten the
On Sat, Jan 26, 2019, 6:30 AM Anders Hovmöller
> > I don't see anything here that can't be done by returning a dict, a
> > namedtuple (possibly with optional fields), or some other object with
> > named fields. They can be optional, they can have defaults, and you can
> > extend the object by
On Tue, Jan 22, 2019, 12:11 PM Paul Ferrell I see this as the natural evolution of what 'with' is all about -
> replacing necessary try-finally blocks with something more elegant. We just
> didn't include the 'except' portion.
>
The time machine strikes again. In fact, you can handle exceptions
If you know the input is sizeable, why not check its length instead of the
map's?
On Mon, Nov 26, 2018, 1:35 PM Kale Kundert I just ran into the following behavior, and found it surprising:
>
> >>> len(map(float, [1,2,3]))
> TypeError: object of type 'map' has no len()
>
> I understand that
On Sat, Nov 10, 2018 at 6:56 PM Jonathan Crall wrote:
> Sometimes there's a good, useful function than doesn't get added because
>> there's no reasonable place to put it. For example, a "flatten" function
>> has been talked about since Python 1.x days, and we still don't have a
>> standard
On Fri, Nov 2, 2018 at 5:25 PM Anders Hovmöller wrote:
> Could you explain what the difference is between defaultdicts "factory
> which is unconditionally called when the key is missing" and "the default
> is evaluated only on need"?
>
The distinction was the motivation for this thread:
On Fri, Nov 2, 2018 at 10:31 AM Philip Martin
wrote:
> [Why don't] csv writer and DictWriter provide ...
> serialization/deserialization hooks?
>
Do you have a specific use-case in mind?
My intuition is that comprehensions provide sufficient functionality such
that changing the csv module
On Wed, Oct 31, 2018 at 12:31 PM Chris Angelico wrote:
> What is being asked for here (if I'm not misreading) is a relatively simple
> enhancement to a method on a built-in type (or a small handful of
> types). If that garners reasonable support, the next step wouldn't be
> a PEP, it'd just go
On Wed, Oct 31, 2018 at 10:17 AM Eric Fahlgren
wrote:
> On Wed, Oct 31, 2018 at 2:42 AM Chris Angelico wrote:
>
>> https://www.python.org/dev/peps/pep-0463/ wants to say hi.
>>
>
> That was exactly my reaction, too, and usually is whenever one of these
> "add a default" or similar ideas pops
I switched this thread to the python-ideas list, since this is proposing a
new feature.
On Mon, Oct 22, 2018 at 12:13 PM Sean Harrington
wrote:
> I contend that multiprocessing.Pool is used most frequently with a single
> task. I am proposing a feature that enforces this invariant, optimizes
How does a frozendict help in that example? It's not obvious to me.
Despite not understanding that example, I'm +1 for having a frozendict. I
don't think it'll increase cognitive load much, as it'll sit right next to
frozenset when someone reads the builtins in alphabetical order. In my own
On Wed, Oct 3, 2018 at 9:29 AM Anders Hovmöller wrote:
>>> foo(=a, =1+bar)
>
>> Unfortunately, that won't help with Jonathan's inital example
>> expression "big_array[5:20]" as it's not a valid keyword.
>
> I didn't understand that. The example you are referring to is
> print('big_array[5:20] =',
On Fri, Sep 28, 2018 at 11:32 PM Steve Barnes wrote:
> One of the strengths of the IEEE float, (to set against its many
> weaknesses), is the presence of the magic value NaN. Not a Number, or
> NaA, is especially useful in that it is a valid value in any
> mathematical operation, (always
On Wed, Sep 26, 2018, 9:42 AM Tobias Kohn wrote:
> Although I doubt it will really make it into Python's grammar, I am all +1
> for the idea of having "repeat" as a loop keyword in Python. Actually, I
> have been using "repeat" as a keyword in Python for quite some time now,
> and found it not
On Tue, Sep 25, 2018 at 8:46 PM Mikhail V wrote:
> I suggest allowing "while:" syntax for the infinite loop.
> I.e. instead of "while 1:" and "while True:" notations.
>
> My opinion:
> 1. I think it'd definitely improve clarity.
I prefer the explicit phrase, ``while True:``. Saying "while"
On Sat, Sep 22, 2018 at 4:53 AM Lee Braiden wrote:
> Problem: [Python] prevents actual default argument values being set in a
> function signature
> Feedback would be much appreciated.
You'd be more convincing if you stated the problem more precisely.
Python supports default values for function
On Sat, Sep 22, 2018 at 2:00 PM Stephen J. Turnbull
wrote:
> If one doesn't know who the senior developers are yet, she should
> think twice about whether she's ready to PEP anything.
On Sat, Sep 22, 2018 at 4:03 PM Anders Hovmöller wrote:
> Is there a committee? Then why not just name it?
>
On Thu, Sep 20, 2018, 3:52 PM Kyle Lahnakoski
wrote:
> KeyboardInterrupt (any interrupt really) is dangerous. Now, we can
> probably code a solution, but how about we remove the danger
>
The other day I accidentally fork-bombed myself with Python os.fork in an
infinite loop. Whoops. It seems to
On Thu, Sep 20, 2018 at 10:25 AM Anders Hovmöller wrote:
> >>> Not for drafting, but for submitting.
> >>
> >> Can you quote pep1? I think you’re wrong.
> >
> > I can't remember if I pulled this quote previously (that's one of the
> > troubles with emails): "Following a discussion on
On Thu, Sep 20, 2018 at 9:27 AM Anders Hovmöller wrote:
> >> That's because completion of discussion has never been a requirement
> >> for writing a PEP.
> >
> > Not for drafting, but for submitting.
>
> Can you quote pep1? I think you’re wrong.
I can't remember if I pulled this quote previously
On Thu, Sep 20, 2018 at 2:13 AM Stephen J. Turnbull
wrote:
> Michael Selik writes:
>
> > However, PEP 1 does not give instruction on how to evaluate whether
> > that discussion has been completed satisfactorily.
>
> That's because completion of discussion has
On Fri, Sep 14, 2018 at 12:30 AM Anders Hovmöller
wrote:
> Since neither version fits well on one line or even three, I'd have
> written each of those on a separate line, indented nicely to emphasize the
> repetition. Seems fine to me.
>
> Sure. As would I. Doesn't change anything[.]
>
Our
On Fri, Sep 14, 2018, 12:17 AM Anders Hovmöller wrote:
>
> That's a bit of a dodge. There is a huge difference in verbosity between
>
> handler.new_file(field_name, file_name, content_type, content_length,
> charset, content_type_extra)
>
> and
>
> handler.new_file(field_name=field_name,
On Thu, Sep 13, 2018, 11:58 PM Anders Hovmöller wrote:
> In that case, you should be able to link to a compelling example. If you
>> go to the trouble of finding one, I'll take time to try to refactor it.
>>
>>
>> https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L707
On Thu, Sep 13, 2018, 11:48 PM Anders Hovmöller wrote:
>
> It's a bit too large for me to make sense of it quickly. My apologies for
> not offering a holistic refactor.
>
>
> My tool will print plenty of other examples. You can pick anyone really...
>
>
> That’s positional because keyword is
On Thu, Sep 13, 2018 at 6:50 PM Anders Hovmöller
wrote:
> On 14 Sep 2018, at 03:35, Michael Selik wrote:
> In that case, you should be able to link to a compelling example. If you
> go to the trouble of finding one, I'll take time to try to refactor it.
>
>
> https://github
On Thu, Sep 13, 2018 at 5:22 PM Anders Hovmöller
wrote:
> For example:
> django-master/django/http/multipartparser.py 225
>
Sorry, I didn't recognize this as a link on first read. I'll provide a link
here to the code in context.
On Thu, Sep 13, 2018 at 5:34 PM Anders Hovmöller
wrote:
> I wrote a script so you can get a list of [good use cases] in big code
> bases without looking through the code randomly.
> https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502
>
In that case, you should be able to link to a
On Thu, Sep 13, 2018 at 11:35 AM Anders Hovmöller
wrote:
> Using keyword arguments is not painful. It's ugly in some unusual cases,
> such as creating helper functions with nearly the same signature.
>
> It’s more painful than positional. To me the fact that everyone who works
> on code bases
On Thu, Sep 13, 2018, 12:39 AM Anders Hovmöller wrote:
> It seems to me this discussion has drifted away from the original
> discussion toward one where you have a chain of functions with the same or
> almost the same signature. This is interesting for sure but we shouldn’t
> forget about the
The dict keys method has other benefits beyond iteration. For example, it
provides a set-like interface.
On Wed, Sep 12, 2018, 10:50 PM Elias Tarhini wrote:
> On Wed, Sep 12, 2018 at 4:42 PM Michael Selik wrote:
>
>> You want to have a Mapping that does not supply a keys meth
On Sat, Sep 8, 2018 at 4:17 AM Jonathan Fine wrote:
> I thank Steve D'Aprano for pointing me to this real-life (although
> perhaps extreme) code example
>
>
> https://github.com/Tinche/aiofiles/blob/master/aiofiles/threadpool/__init__.py#L17-L37
It's hard to know from just a brief glance how
Elias,
I'm a little confused about what you're suggesting. You want to have a
Mapping that does not supply a keys method? What use case motivated your
proposal?
On Mon, Sep 10, 2018, 7:04 PM Elias Tarhini wrote:
> This has been bouncing around in my head for a while regarding the
> requisite
On Sat, Sep 8, 2018, 6:34 AM Anders Hovmöller wrote:
> > A finer grained analysis tool would be helpful. I'm -0 on the idea
> because I believe it would discourage more expressive names in calling
> contexts in order to enable the proposed syntax. But I also see a big
> difference between cases
On Fri, Sep 7, 2018, 12:00 AM Jacco van Dorp wrote:
> Sometimes we make a function only to be called once at a specific
> location, more because of factoring out some functions for clarity.
>
I've found myself making the opposite refactoring recently, improving
clarity by eliminating
On Thu, Aug 30, 2018, 9:23 PM David Mertz wrote:
> On Fri, Aug 31, 2018, 12:08 AM Guido van Rossum wrote:
>
>> Hm. YAML is indeed a great, readable alternative to JSON or XML. But the
>> term DSL implies (to me) more than just nested key-value pairs. (Though who
>> knows maybe that's all Keras
On Thu, Aug 30, 2018 at 5:31 PM James Lu wrote:
> It would be nice if there was a DSL for describing neural networks (Keras).
>
> model.add(Dense(units=64, activation='relu', input_dim=100))
> model.add(Dense(units=10, activation='softmax'))
>
>
Why not JSON or XML for cross-language
On Sat, Aug 18, 2018 at 2:48 AM Steve Barnes wrote:
> "The removal of technical terminology needs to be moderated to account
> for the risk of loss of the essential meaning or the meaning being lost
> due to excessive length. Where such terminology is widely accepted
> within a given
On Wed, Aug 15, 2018, 12:06 AM Stefan Behnel wrote:
> Michael Selik schrieb am 14.08.2018 um 21:42:
> > This is supported by education research. Some light Googling found a
> > study on the topic [0] that is consistent with my own observations.
>
> OTx2, and no offence, bu
The conversation about syntactic sugar for ``functools.partial`` led to a
question about whether jargon like "lambda" makes the concept of an
anonymous function more difficult to learn.
In my own experience teaching, I find that many concepts are easier to
introduce if I avoid the Python jargon
On Mon, Aug 13, 2018, 5:48 PM Greg Ewing
wrote:
> Chris Angelico wrote:
> > No, lambda calculus isn't on par with brakes - but anonymous functions
> > are, and if they're called "lambda", you just learn that.
>
> It's like saying that people would find it easier to learn to
> drive if "brakes"
Something that limits posts to once per day per thread could be useful,
maybe even once per week.
On Mon, Aug 13, 2018, 10:06 AM Michael Selik wrote:
>
>
> On Mon, Aug 13, 2018, 5:59 AM Nicholas Chammas
> wrote:
>
>> Maybe we need to revive that discussion? Overall,
On Mon, Aug 13, 2018, 5:59 AM Nicholas Chammas
wrote:
> Maybe we need to revive that discussion? Overall, I don’t think we have a
> people problem on this list as much as we have an administration tooling
> problem.
>
+1
Even the fact that "straw poll" votes aren't counted automatically shows
On Mon, Jul 23, 2018 at 2:03 AM Jonathan Fine wrote:
> Thank you for your attention. What have I missed?
>
None and a few other things are special-cased by CPython. The compiler
won't bother to write bytecode instructions when an if-statement obviously
evaluates false. That might surprise some
Sounds good to me. It'll make OrderedDict look much nicer at the REPL.
On Thu, Jul 26, 2018 at 10:21 AM Terry Reedy wrote:
> I am not sure what our repr change policy is, as there is a
> back-compatibility issue but I remember there being changes.
Given the way different Python prompts feel
On Sat, Jul 21, 2018, 6:55 PM Steven D'Aprano wrote:
> On Sun, Jul 22, 2018 at 01:56:35AM +0200, Giampaolo Rodola' wrote:
> > On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano
> wrote:
> > > Tens of thousands of non-English speakers have had to learn the meaning
> > > of what might as well be
On Thu, Jul 19, 2018 at 8:40 PM Michael Lee
wrote:
>
>1. ...
>
>2. We can already easily get the same functionality using standard
>Python. E.g., instead of doing foo?["bar"]?[0]?["baz"], we could do
> lookup(foo,
>"bar", 0, "baz") where lookup is a function that looks roughly
On Thu, Jul 19, 2018 at 5:29 PM Steve Dower wrote:
> * "It makes it more complex"
> * "It's harder to follow the flow"
>
> Depends on your measure of complexity. For me, I prioritise "area under
> the indentation" as my preferred complexity metric (more lines*indents
> == more complex), as well
On Thu, Jul 19, 2018 at 2:19 PM Terry Reedy wrote:
> It seems to me that the problem is returning None.
If functions raised errors instead of returning None, we wouldn't have so
much trouble. Much of the benefit of PEP-572 was handling Nones and similar
sentinel values.
Instead of providing
On Mon, Jul 2, 2018 at 8:49 AM Chris Barker wrote:
> On Fri, Jun 29, 2018 at 11:25 PM, Guido van Rossum
> wrote:
>
>
>> Hm, this actually feels heavier to me. But then again I never liked or
>> understood the need for Counter --
>>
>
> actually, me neither -- and partly because it's too
Thanks for linking to these. I looked at many of them in my own research,
but for some reason didn't think to write down the links. I'll respond to
each one separately.
Throughout, I'm going to use my proposed ``grouped`` builtin to demonstrate
possible revisions. Note that I am *not* suggesting
On Wed, Jul 4, 2018, 3:11 AM Ivan Levkivskyi wrote:
> Replying to the question in subject, I think it would be better in
> collections as a class.
> Having it just as a function doesn't buy much, because one can do the
> same with three lines and a defaultdict.
>
Four lines. You'll need to
There are some cases when that's the correct behavior. It mimics
pandas.DataFrame.groupby. For example, what if you have a sequence of (key,
v1, v2) triples? Group by key, then keep the triples intact is the right
choice sometimes.
On Wed, Jul 4, 2018, 6:39 AM David Mertz wrote:
> Steven:
>
>
On Tue, Jul 3, 2018, 6:32 PM Steven D'Aprano wrote:
> On Tue, Jul 03, 2018 at 10:33:55AM -0700, Chris Barker wrote:
> > On Tue, Jul 3, 2018 at 8:33 AM, Steven D'Aprano
> wrote:
> >
> > > but why are we using key values by hand when grouping ought to do it
> for
> > >> us, as Michael Selik's
I'd prefer to simply write an example for the documentation or clarify the
existing ones, then add good answers to StackOverflow questions.
On Tue, Jul 3, 2018, 6:23 AM David Mertz wrote:
> Guido said he has mooted this discussion, so it's probably not reaching
> him. It took one thousand
ools use the equality function as the default.
On Mon, Jul 2, 2018 at 3:48 AM Steven D'Aprano wrote:
> On Mon, Jul 02, 2018 at 02:52:03AM -0700, Michael Selik wrote:
> > Third, some classes might have a rich equality method that allows many
> > interesting values to all wind up i
On Mon, Jul 2, 2018 at 2:52 AM Michael Selik wrote:
> On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin
> wrote:
>
>> I think the current default quite weird, as it pretty much account to a
>> count() of each key (which can be useful, but not really what I except from
>>
On Mon, Jul 2, 2018 at 2:32 AM Nicolas Rolin wrote:
> I think the current default quite weird, as it pretty much account to a
> count() of each key (which can be useful, but not really what I except from
> a grouping). I would prefer a default that might return an error to a
> default that says
PM Michael Selik wrote:
>
>> On Fri, Jun 29, 2018 at 2:43 PM Guido van Rossum
>> wrote:
>>
>>> On a quick skim I see nothing particularly objectionable or
>>> controversial in your PEP, except I'm unclear why it needs to be a class
>>> method on `d
to the GitHub repo, as per these comments.
> On Fri, Jun 29, 2018 at 10:54 AM Michael Selik wrote:
>
>> Hello,
>>
>> I've drafted a PEP for an easier way to construct groups of elements from
>> a sequence. https://github.com/selik/peps/blob/master/pep-.rst
>&
I created a separate thread to continue this discussion: "grouping / dict
of lists"
https://github.com/selik/peps/blob/master/pep-.rst
In my proposal, the update offers a key-function in case the new elements
don't follow the same pattern as the existing ones. I can understand the
view that
that the majority appreciate it. Some are
even able to guess what it does (would do) without any priming.
Thanks for your time,
-- Michael
On Thu, Jun 28, 2018 at 8:38 AM Michael Selik wrote:
> On Thu, Jun 28, 2018 at 8:25 AM Nicolas Rolin
> wrote:
>
>> I use list and dict comp
On Thu, Jun 28, 2018, 6:46 PM Nicolas Rolin wrote:
> The questions I should have asked In my original post was :
> - Is splitting lists into sublists (by grouping elements) a high level
> enough construction to be worthy of a nice integration in the comprehension
> syntax ?
>
My intuition is
On Thu, Jun 28, 2018 at 5:12 PM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:
> In [97]: student_school_list
> Out[97]:
> [('Fred', 'SchoolA'),
> ('Bob', 'SchoolB'),
> ('Mary', 'SchoolA'),
> ('Jane', 'SchoolB'),
> ('Nancy', 'SchoolC')]
>
> In [98]: result = defaultdict(list,
On Thu, Jun 28, 2018 at 4:34 PM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:
> On Thu, Jun 28, 2018 at 4:23 PM, Greg Ewing
> wrote:
>
>> Nicolas Rolin wrote:
>>
>>> student_by_school = {group_by(school): student for school, student
>>> in student_school_list}
>>>
>>
>> In
On Thu, Jun 28, 2018 at 8:25 AM Nicolas Rolin
wrote:
> I use list and dict comprehension a lot, and a problem I often have is to
> do the equivalent of a group_by operation (to use sql terminology).
>
> For example if I have a list of tuples (student, school) and I want to
> have the list of
On Wed, Jun 27, 2018 at 8:16 AM Franklin? Lee
wrote:
> On Wed, Jun 27, 2018, 10:31 Steven D'Aprano wrote:
>
>> On Wed, Jun 27, 2018 at 06:52:14AM -0700, Michael Selik wrote:
>> > My intent was to ask where a range was in fact passed into max, not
>> merely
&
On Wed, Jun 27, 2018 at 12:04 AM Fiedler Roman
wrote:
> Context: we are conducting machine learning experiments that generate some
> kind of nested decision trees. As the tree includes specific decision
> elements (which require custom code to evaluate), we decided to store the
> decision tree
On Wed, Jun 27, 2018 at 7:30 AM Steven D'Aprano wrote:
> On Wed, Jun 27, 2018 at 06:52:14AM -0700, Michael Selik wrote:
> > > > Have you ever written ``max(range(x))`` in production code?
> > > I have never written that.
> > > But I have written ``max(iterable)`
On Wed, Jun 27, 2018, 3:06 AM Steven D'Aprano wrote:
> On Wed, Jun 27, 2018 at 12:36:12AM -0700, Michael Selik wrote:
> > On Tue, Jun 26, 2018, 11:43 PM Jacco van Dorp
> wrote:
>
> > > Generators dont have a __len__ method. And they might have min/max
> > &g
Do you mind sharing an example usage in a realistic context? There might be
a good solution that doesn't require adding magic methods.
On Tue, Jun 19, 2018, 12:24 PM James Edwards wrote:
> I've only recently looked for these special methods, so that in and of
> itself may be the reason these
On Mon, Jun 18, 2018, 6:59 PM Michael Selik wrote:
>
> if isinstance(v, ParseResults):
> if v:
> s = v.dump(indent, depth + 1)
> else:
> s = _ustr(v)
> else:
>
On Mon, Jun 18, 2018 at 6:20 PM Juancarlo Añez wrote:
> For all practical purpose, it would be enough to define that the
>>> expression:
>>>
>>> mylist += [item]
>>>
>>> gets optimized to mylist.append(item).
>>>
>>
>> Unfortunately, that would create yet another special case of operators
>>
On Mon, Jun 18, 2018 at 2:55 PM Mikhail V wrote:
> On Mon, Jun 18, 2018 at 11:43 PM, Michael Selik wrote:
> > On Mon, Jun 18, 2018 at 12:56 PM Mikhail V wrote:
> >> Numpy arrays have also append() and insert() methods,
> > In [2]: np.arange(1).append(2)
> >
On Mon, Jun 18, 2018 at 5:52 PM Juancarlo Añez wrote:
> The idea is to introduce new syntax for the list.append() method.
>>
>> mylist[] = item
>>
>
> For all practical purpose, it would be enough to define that the
> expression:
>
> mylist += [item]
>
> gets optimized to
On Mon, Jun 18, 2018 at 12:56 PM Mikhail V wrote:
> Numpy arrays have also append() and insert() methods,
>
In [2]: np.arange(1).append(2)
AttributeError: 'numpy.ndarray' object has no attribute 'append'
In [3]: np.arange(1).insert
AttributeError: 'numpy.ndarray' object has no attribute
On Sun, Jun 17, 2018, 10:01 AM Mikhail V wrote:
> The idea is to introduce new syntax for the list.append() method.
>
While you have summarized your proposal, you haven't included a summary of
the criticism.
Also, one thing that's very common for proposals to change syntax and
create new uses
The idea of having a dunder to introspect the bound variable name has been
discussed before. You can find the past discussions in the mailing list
archive. If I recall correctly, there were very few use cases beyond
namedtuple. With dataclasses available in 3.7, there may be even less
interest
On Sat, Jun 16, 2018, 10:22 AM Mikhail V wrote:
> Plus it does not introduce overloading of the operator.
Now you're critizing duck typing.
And overloading has weakness in this - e.g. " var1 += var2 " does not
> have mnemonics, other than + character (it could be two integers as well).
>
On Fri, Jun 15, 2018, 6:18 PM Mikhail V wrote:
> On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote:
>
> > One of those links was discussing extend, not append.
>
> Yes and so what? ... What is different with append?
Luckily for extend, it's similar to the "obvious
On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote:
> there is just nothing against append() method.
>
Then why break the Zen: there should be only one obvious way?
But I see from various posts in the web and SO - people just want to spell
> it compact, and keep the 'item' part clean of brackets.
On Fri, Jun 15, 2018 at 10:25 AM Mikhail V wrote:
> very uncommon to see standalone statements like: x.method()
>
Python has many such mutation methods. It sounds like you're judging the
frequency of code patterns across all languages instead of just Python.
Even then, I don't think that's
On Thu, Jun 14, 2018, 11:22 PM Franklin? Lee
wrote:
> P.S.: Is there any way of guessing what proportion of Python programs
> use `re`, either explicitly or implicitly? How many programs will, at
> some point in their runtime, load the `re` module?
>
GitHub posts it's data to Google BigQuery.
e
statistics?
On Thu, Jun 14, 2018, 7:40 PM Michael Selik wrote:
>
>
> 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.
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
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
Google will probably fix this problem for you after dataclasses become
popular. The docs will gain a bunch of inbound links and the issue will
(probably) solve itself as time passes.
On Tue, Jun 12, 2018 at 2:48 PM Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> I'm testing "Data
On Tue, Jun 12, 2018 at 4:43 PM Mikhail V wrote:
> inserting in the beginning of the list may be also not rare.
>
Inserting in the beginning of a list is *slow* and should be rare.
If you want to append to the left-side of a list, you should use a deque.
Check out ``collections.deque`` for your
On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
> wrote:
>
> So the idea was about an insert/append operator.
> Which would use augmented operator. The operator may be
> /= or ^=. (I like ^= more, so I'll put here example with it).
>
The "/"
That's a slice assignment, works great. I think if you use it more often
you'll start to enjoy it.
However, lists are optimized for append. Insert is slow. It should be
discouraged, not encouraged by the language. If inserting is just a tad
more awkward than appending, that's the language design
On Mon, Jun 11, 2018, 1:18 PM Chris Barker wrote:
> On Mon, Jun 11, 2018 at 10:24 AM, Michael Selik wrote:
>
>> Would sind and cosd make Euler's formula work correctly?
>
>
> There is nothing inherently more accurate in using degrees rather than
> radians for trigonom
Whoops, it turns out Euler's formula does work! I expected imprecision, but
at least one test matched.
x = 42
cos(x) + 1j * sin(x) == e ** (1j * x)
I suppose that's because it's radians.
On Mon, Jun 11, 2018, 10:24 AM Michael Selik wrote:
> Would sind and cosd make Euler's formula w
Would sind and cosd make Euler's formula work correctly?
sind(x) + i * sind(x) == math.e ** (i * x)
I suspect that adding these functions is kind of like those cartoons where
the boat is springing leaks and the character tried to plug them with their
fingers. Floating point is a leaky
On Sat, Jun 9, 2018 at 2:22 AM Adam Bartoš wrote:
> The idea was that the functions could handle the PiMultiple instances in a
> special way and fall back to float only when a special value is not detected.
> It would be like the proposed dsin functionality, but with a magic class
> instead
1 - 100 of 110 matches
Mail list logo
