On Sat, Mar 30, 2019 at 12:15:00AM -0700, Christopher Barker wrote:
> On Fri, Mar 29, 2019 at 6:38 PM Steven D'Aprano wrote:
>
> > On Fri, Mar 29, 2019 at 04:05:55PM -0700, Christopher Barker wrote:
> >
> > > This proposal would provide a minor gain for an eve
On Fri, Mar 29, 2019 at 12:06:25PM +0900, Stephen J. Turnbull wrote:
> Anders Hovmöller writes:
[...]
> > just like always. This seems totally irrelevant to the
> > discussion. And it's of course irrelevant to all the end users that
> > aren't writing libraries but are using python directly.
>
On Sat, Mar 30, 2019 at 11:40:18AM +, Paul Moore wrote:
> Is str.trim like str.swapcase, or like str.split? Who knows, at this point?
I think you are making a rhetorical point, but not a very good one. I
think we all know, or at least *should* know, that this proposal is much
closer to
On Sun, Mar 31, 2019 at 03:05:59AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > The correct solution is a verbose statement:
> >
> > if string.startswith("spam"):
> > string = string[:len("spam")]
>
On Sun, Mar 31, 2019 at 04:48:36PM +1100, Chris Angelico wrote:
> Regardless of the method name, IMO the functions should accept a tuple
> of test strings, as startswith/endwith do. That's a feature that can't
> easily be spelled in a one-liner. (Though stacked suffixes shouldn't
> all be removed
On Sun, Mar 31, 2019 at 07:35:22PM +1100, Steven D'Aprano wrote:
> "musical".lcut(('al', 'ical'))
Oops, typo, I was thinking rcut and wrote lcut :-(
--
Steven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.pytho
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
On Thu, Mar 28, 2019 at 06:43:39PM -0700, Nathaniel Smith wrote:
> For example, here's a post of yours from a few weeks ago:
> https://mail.python.org/pipermail/python-ideas/2019-March/055911.html
>
> AFAICT, it is not possible to find that post with Google.
>
> For example,
> doing a
Without getting into the pros and cons of mailing lists versus github
versus discourse versus Stackoverflow versus ...
On Fri, Mar 29, 2019 at 02:23:52PM +1100, Chris Angelico wrote:
> Have you ever actually
> convinced someone to move off Gmail onto some other client?
Gmail is an email
On Fri, Mar 29, 2019 at 10:20:41PM +1100, Chris Angelico wrote:
> In those terms, I'm talking about convincing someone to move off the
> _Gmail client_, whether or not they continue using the Gmail service.
> Have you ever convinced someone to stop using the Gmail web interface
> and start using
On Sun, Apr 07, 2019 at 01:42:46PM +0200, Thomas Gläßle wrote:
> It would be nice to just type, e.g. any of:
>
> pyval os.pathsep
How will it know what object os is, without guessing, if you haven't
imported it?
> There is already a tool like this on PyPI [1] (sadly py2 only atm), but
>
On Sun, Apr 07, 2019 at 08:26:24PM -0700, Nathaniel Smith wrote:
> On Sun, Apr 7, 2019 at 7:37 PM Steven D'Aprano wrote:
> > There are quite a few important algorithms which require lists to be
> > sorted. For example, the bisect module, and for statistics median and
>
On Mon, Apr 08, 2019 at 03:18:53PM +1000, Cameron Simpson wrote:
> If this is a publicly queriable value, is there any need to have a
> dunder name at all? Why not just give lists a public is_sorted
> attribute?
I don't mind that.
> I'm also not convinced the cost to every insert/append is
On Mon, Apr 08, 2019 at 02:55:54AM -0700, Nathaniel Smith wrote:
> Right, by "doesn't affect" I meant "cannot get any benefit, even if their
> code is modified".
Ah, sorry I misunderstood you.
> > # This only makes sense if data is a sequence (list)
> > # not an iterator.
> >
On Mon, Apr 08, 2019 at 10:34:19AM +0100, Paul Moore wrote:
> On Mon, 8 Apr 2019 at 10:10, Steven D'Aprano wrote:
>
> > Possibly the maintainer of bisect may decide that its not worth the
> > change. But for the statistics module, I would certainly change the
> >
On Mon, Apr 08, 2019 at 01:31:14PM +1000, Cameron Simpson wrote:
> __setitem__ concerns me, along with other modification methods: what
> about subclasses(*)? Every existing subclass which overrides __setitem__
> now needs to grow code to maintain __issorted__ if they do not
> themselves call
On Mon, Apr 08, 2019 at 07:44:41AM +0100, Alex Chamberlain wrote:
> I think a better abstraction for a sorted list is a new class, which
> implements the Sequence protocol (and hence can be used in a lot of
> existing list contexts), but only exposed mutation methods that can
> guarantee that
See https://bugs.python.org/issue35892
The issue here is that statistics.mode, as initially designed, raises an
exception for the case of multiple equal most-frequent data points. This
is true to the way mode is taught in schools, but it may not be the most
useful behaviour.
Raymond has
On Thu, Feb 28, 2019 at 08:59:30PM -0800, Hasan Diwan wrote:
> Do we really need a "+" and a "-" operation on dictionaries?
> [dictinstance.update({k:v}) for k,v in dictinstance.items()] does handle
> merges already.
I don;t think that does what you intended. That merges dictinstance with
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
> from the result of the += operator.
That's how list.__iadd__ works too:
On Thu, Feb 28, 2019 at 07:40:25AM -0500, James Lu wrote:
> I agree with Storchaka here. The advantage of existing dict merge
> syntax is that it will cause an error if the object is not a dict or
> dict-like object, thus preventing people from doing bad things.
What sort of "bad things" are
Attached is a draft PEP on adding + and - operators to dict for
discussion.
This should probably go here:
https://github.com/python/peps
but due to technical difficulties at my end, I'm very limited in what I
can do on Github (at least for now). If there's anyone who would like to
co-author
Executive summary:
- I'm going to argue for subclass-preserving behaviour;
- I'm not wedded to the idea that dict += should actually call the
update method, so long as it has the same behaviour;
- __iadd__ has no need to return NotImplemented or type-check its
argument.
Details below.
On
On Mon, Mar 04, 2019 at 10:01:23AM -0500, James Lu wrote:
> If you want to merge it without a KeyError, learn and use the more explicit
> {**d1, **d2} syntax.
In your previous email, you said the {**d ...} syntax was implicit:
In other words, explicit + is better than implicit {**, **#,
On Mon, Mar 04, 2019 at 10:09:32AM -0500, James Lu wrote:
> How many situations would you need to make a copy of a dictionary and
> then update that copy and override old keys from a new dictionary?
Very frequently.
That's why we have a dict.update method, which if I remember correctly,
was
On Mon, Mar 04, 2019 at 09:42:53AM -0500, David Mertz wrote:
> On Mon, Mar 4, 2019, 8:30 AM Serhiy Storchaka wrote:
>
> > But is merging two dicts a common enough problem that needs introducing
> > an operator to solve it? I need to merge dicts maybe not more than one
> > or two times by year,
On Mon, Mar 04, 2019 at 03:43:48PM +0200, Serhiy Storchaka wrote:
> 01.03.19 12:44, Steven D'Aprano пише:
> >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
On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote:
> Here's a syntax that solves this using the new operators _:= and ,_
Be careful about making such dogmatic statements.
Language design is not a matter of picking random syntax and claiming
that it solves the problem -- especially
On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote:
> Hello,
>
> I'd like to propose an update to PEP8. Indeed, the 80 characters per line
> guideline is, I feel, outdated.
I know this is not precisely what you are arguing, but the thought of
people arguing that the only problem with a
On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
> On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote:
>
> > Here's a syntax that solves this using the new operators _:= and ,_
>
> Be careful about making such dogmatic statements.
Ah, I have just
On Wed, Feb 20, 2019 at 07:53:21PM +, Jonathan Fine wrote:
> Steven D'Aprano wrote:
>
> > > I wasn't making a point. I was providing evidence.
> >
> > Evidence of what?
> >
> > What was the point of this evidence?
> >
> > If it was to d
Correcting myself twice now, that's not a good sign... :-)
On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
> But there's a deeper problem with this entire concept, regardless of
> syntax, one which to my knowledge nobody has mentioned yet: it simply
> isn't c
On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote:
[Ben]
> > Other functions also conceptually have three ways of returning:
> > ordinary return with a value, a documented special return like
> > KeyError, and pass-through exceptions. If the pass-through exception
> > is KeyError, it
On Tue, Feb 19, 2019 at 01:52:34PM -0800, Brett Cannon wrote:
> On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote:
[...]
> > I would be happy to have
> >
> > >>> [1,2,3].append(4)::sort()::max() +1
> >
> > It makes things very easy to read: first create list, then append 4,
> > then sort, then
On Mon, Mar 04, 2019 at 11:56:54AM -0600, Dan Sommers wrote:
> On 3/4/19 10:44 AM, Steven D'Aprano wrote:
>
> > If you know ahead of time which order you want, you can simply reverse
> > it:
> >
> > # prefs = site_defaults + user_defaults + document_prefs
On Mon, Mar 04, 2019 at 09:34:34PM +, Paul Moore wrote:
> On Mon, 4 Mar 2019 at 20:42, Guido van Rossum wrote:
> >
> > Honestly I would rather withdraw the subtraction operators than
> > reopen the discussion about making dict more like set.
As some people have repeatedly pointed out, we
On Mon, Mar 04, 2019 at 10:18:13PM -0800, Amber Yust wrote:
> Adding the + operator for dictionaries feels like it would be a mistake in
> that it offers at most sugar-y benefits, but introduces the significant
> drawback of making it easier to introduced unintended errors.
What sort of errors?
On Sat, Mar 02, 2019 at 01:47:37AM +0900, INADA Naoki wrote:
> > If the keys are not strings, it currently works in CPython, but it may not
> > work with other implementations, or future versions of CPython[2].
>
> I don't think so. https://bugs.python.org/issue35105 and
>
On Mon, Mar 04, 2019 at 03:33:36PM -0500, Neil Girdhar wrote:
> Maybe, but reading through the various replies, it seems that if you
> are adding "-" to be analogous to set difference, then the combination
> operator should be analogous to set union "|".
That's the purpose of this discussion,
On Tue, Mar 05, 2019 at 06:04:40PM +0900, INADA Naoki wrote:
[...]
> One obvious merit of d.merge(...) is it returns same type of d.
> `type(d1)(d1, d2)` looks ugly.
>
> But people just want dict instead of some subtype of dict.
> This merit is not so important.
Not to me! It *is* important to
On Tue, Mar 05, 2019 at 08:11:29AM -0500, David Shawley wrote:
> "Putting Metaclasses to Work" (ISBN-13 978-0201433050) presents a more
> mathematical view of programming language types that includes two
> distinct operations for combining dictionaries -- merge and recursive
> merge.
>
> For two
On Mon, Mar 04, 2019 at 08:01:38PM -0500, James Lu wrote:
>
> > On Mar 4, 2019, at 11:25 AM, Steven D'Aprano wrote:
> > Another example would be when reading command line options, where the
> > most common convention is for "last option seen" to win:
> >
On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
> I propose that the + sign merge two python dictionaries such that if
> there are conflicting keys, a KeyError is thrown.
This proposal is for a simple, operator-based equivalent to
dict.update() which returns a new dict. dict.update
On Sat, Mar 02, 2019 at 11:14:18AM -0800, Raymond Hettinger wrote:
> If the existing code were in the form of "d=e.copy(); d.update(f);
> d.update(g); d.update(h)", converting it to "d = e + f + g + h" would
> be a tempting but algorithmically poor thing to do (because the
> behavior is
On Wed, Feb 27, 2019 at 10:34:43AM -0700, George Castillo wrote:
> >
> > The key conundrum that needs to be solved is what to do for `d1 + d2` when
> > there are overlapping keys. I propose to make d2 win in this case, which is
> > what happens in `d1.update(d2)` anyways. If you want it the other
On Fri, Mar 01, 2019 at 09:58:08PM +0900, INADA Naoki wrote:
> >>> {1} <= ({1} | {1.0})
> True
> >>> {1.0} <= ({1} | {1.0})
> True
>
> So dict + dict is totally different than set | set.
> dict + dict has los at equality level.
Is that an invariant you expect to apply to other uses of the +
On Fri, Mar 01, 2019 at 08:59:45PM +0900, INADA Naoki wrote:
> I dislike adding more operator overload to builtin types.
>
> str is not commutative, but it satisfies a in (a+b), and b in (a+b).
> There are no loss.
Is this an invariant you expect to apply for other classes that support
the
On Thu, Feb 21, 2019 at 05:06:51PM -0800, Chris Barker via Python-ideas wrote:
> To all the folks quoting theory: let's be honest. Yes, really long lines
> are harder to read, but the 80 char limit comes from old terminals, NOT any
> analysis that somehow that is optimum for readability.
Chris,
On Sat, Mar 16, 2019 at 06:43:52AM +0400, Abdur-Rahmaan Janhangeer wrote:
> Despite my poor python skills, i don't think i'd ever use this one.
>
> blocks = blocks + [block] # Not good for you.
Neither would I. But I would use:
result = process(blocks + [block])
in
On Fri, Mar 15, 2019 at 10:53:31PM +, MRAB wrote:
> There was also the suggestion of having both << and >>.
>
> Actually, now that dicts are ordered, that would provide a use-case,
> because you would then be able to choose which values were overwritten
> whilst maintaining the order of
On Fri, Mar 15, 2019 at 12:25:22PM +0100, Antoine Pitrou wrote:
> Yeah, well I do think "+=" for lists was a mistake. I *still* have
> trouble remembering the exact difference between "list +=" and
> "list.extend" (yes, there is one: one accepts more types than the
> other... which one it
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote:
> On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
> wrote:
>
> > [snip]
> >
> > I still remember being told in no uncertain terms by the core devs that
> > adding a clear() method to
On Fri, Mar 15, 2019 at 12:34:45PM +0100, Antoine Pitrou wrote:
> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a
On Mon, Mar 18, 2019 at 01:13:29AM +1100, Chris Angelico wrote:
[...]
> Yes, it will. Can you determine whether some code does this? Can you
> recognize what kind of object is on the left of a percent sign?
> Remember, it quite possibly won't be a literal.
I don't understand whether your question
Hi James,
Some weeks ago, you started a discussion here about "Clearer
Communication". Here's another suggestion to help: don't expect your
readers to either guess, or infer from the code, what your proposal
means. As the Zen of Python says:
Explicit is better than implicit.
Looking at your
On Thu, Mar 07, 2019 at 08:10:20AM -0500, James Lu wrote:
> Rationale: When I use a search engine to google a Python question, I
> frequently get a link to a page of the Python 2.7 documentation that
> shows before the Python 3 documentation link.
>
> This is annoying and slows down my
On Fri, Mar 08, 2019 at 03:43:10PM -0800, Chris Barker - NOAA Federal via
Python-ideas wrote:
> >
> > Rather than using map in this way, I would recommend a list comprehension:
>
> Exactly! I really don’t get why folks want to use map() so much when
> the comprehension syntax is often cleaner
On Sat, Mar 09, 2019 at 05:19:50PM +1300, Greg Ewing wrote:
> If we were going to add a syntax for abbreviating lambdas, I would
> rather see something more generally useful, e.g.
>
>x -> x.method()
>
> as an abbrevation for
>
>lambda x: x.method()
Cocnut does this!
On Fri, Mar 08, 2019 at 10:16:02PM +0100, Martin Bammer wrote:
> Hi,
>
> what about the idea that the interpreter preallocates and
> preinitializes the tuples and dicts for function calls where possible
> when loading a module?
That's an implementation detail. CPython may or may not use tuples
On Sat, Mar 09, 2019 at 04:34:01PM +, Jonathan Fine wrote:
> There are (many) numbers between 1 and infinity. If a programmer
> defines __at_python__ on type(guido) then guido@python will have
> semantics.
It already has meaning: it calls the @ operator with operands "guido"
and "python".
On Sat, Mar 09, 2019 at 03:33:25PM +, Jonathan Fine wrote:
> I've been thinking that it might be easier, in the long term, to make
> a big step and allow
> >>> a @update= b
> as valid Python. What do you think? (I hope it will look nicer once
> syntax highlighted.)
Are we supposed to know
Thanks to everyone who has contributed to the discussion, I have been
reading all the comments even if I haven't responded.
I'm currently working on an update to the PEP which will, I hope,
improve some of the failings of the current draft.
--
Steven
On Tue, Mar 19, 2019 at 09:58:55AM +1300, Greg Ewing wrote:
> Oleg Broytman wrote:
> > Three-way (tri state) checkbox. You have to distinguish False and
> >None if the possible valuse are None, False and True.
>
> In that case the conventional way to write it would be
>
> if
On Mon, Mar 18, 2019 at 04:07:11PM +0100, Jimmy Girardet wrote:
> The syntax {**b,**c} wasn't hard to remember.
[...]
> And easy because at the end it's idiomatic.
It is only idiomatic if moderately experienced Python programmers can
automatically read it and write it without thinking about
On Tue, Mar 19, 2019 at 11:32:56AM +1300, Greg Ewing wrote:
> Tim Delaney wrote:
> >I would argue the opposite - the use of "is" shows a clear knowledge
> >that True and False are each a singleton and the author explicitly
> >intended to use them that way.
>
> I don't think you can infer that.
On Mon, Mar 18, 2019 at 03:12:52PM +0100, Antoine Pitrou wrote:
> (also, don't forget you can still use the copy() + update() method)
If we had fluent method calls, we could write:
process(mapping.copy().update(other))
but we don't, so we use a pointless temporary variable:
temp =
On Sat, Mar 16, 2019 at 07:13:04PM -0400, Terry Reedy wrote:
> > new = a.copy()
> > new.update(b)
> > # do something with new
>
> In my census of the stdlib, already posted and noted as subject to
> error, this was twice as common as all other non-update-in-place
>
On Mon, Mar 18, 2019 at 05:51:08AM -0700, Rémi Lapeyre wrote:
> Maths’ typing is explicit so you don’t need to spend brain cycles to
> determine them.
Surely that depends on how formal you are being?
Maths can vary hugely in formality, even at a professional level. It is
a terrible
On Mon, Mar 18, 2019 at 06:34:48PM -0500, Dan Sommers wrote:
> So how many of you got tired of those three statements and
> added something like the following function to your private
> collection of useful functions:
>
> def merged_mappings(mapping, other):
> temp = mapping.copy()
>
On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas wrote:
> I therefore proposed
> https://smarie.github.io/python-makefun/ . In particular it provides
> an equivalent of `@functools.wraps` that is truly signature-preserving
Tell us more about that please. I'm very
On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
> Watch the tone please.
Brett, you might have missed my comment about wanting to avoid unhelpful
arguments about tone, but if you are going to complain about people's
tone, the considerate thing to do is to say what it is that
Hi Vlad, and welcome!
On Thu, Mar 14, 2019 at 10:00:03PM +0100, Vlad Tudorache wrote:
> Hello,
>
> I'd like to know if there is a basic HTML wrapper for Python, like
> TextWrapper but allowing the generation of HTML from strings or iterables
> of strings.
This list is for proposing and
On Thu, Mar 14, 2019 at 09:33:21PM +0100, francismb wrote:
[...]
> > Do you mean something like 2to3? Something which transforms source code
> > written in Python?
> >
> Yes a source transformer, but to be applied to some 3.x version to move
> it to the next 3.x+1, and so on ... (instead of
On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote:
> On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > Not really. For example, addition of syntax like "async" and "yield"
> > fundamentally changes the meaning of "def", in ways that *could not*
> > be fully emulated in earlier Pythons.
On Sat, Mar 09, 2019 at 11:39:39AM -0800, Stephan Hoyer wrote:
> Would __iadd__ and __isub__ be added to collections.abc.MutableMapping?
No, that will not be part of the PEP. The proposal is only to change
dict itself. If people want to add this to MutableMapping, that could be
considered
On Thu, Mar 07, 2019 at 05:53:58PM -0500, Terry Reedy wrote:
> On 3/7/2019 8:56 AM, Steven D'Aprano wrote:
[...]
> >I've found that the search engines are getting better at linking to the
> >more recent docs. For example, all of these:
> >give me Python 3 first and Python
On Mon, Mar 11, 2019 at 09:38:21PM +0100, francismb wrote:
> Hi,
> I would like to discuss on the idea of a code (minor) version
> evolver/re-writer (or at least a change indicator). Let's see one wants
> to add a feature on the next version and some small grammar change is
> needed, then the
On Thu, Mar 21, 2019 at 03:16:44PM +0200, Serhiy Storchaka wrote:
> 21.03.19 14:51, Chris Angelico пише:
> >... then, in the interests of productive discussion, could you please
> >explain? What is it about dict addition that makes it harder to
> >understand than other addition?
>
> Currently the
I'd like to make a plea to people:
I get it, there is now significant opposition to using the + symbol for
this proposed operator. At the time I wrote the first draft of the PEP,
there was virtually no opposition to it, and the | operator had very
little support. This has clearly changed.
At
On Thu, Mar 21, 2019 at 09:11:18AM -0700, Guido van Rossum wrote:
> I don't find it easy to understand or remember that d1.update(d2) modifies
> d1 in place, while d1.merge(d2) first copies d1.
>
> Maybe the name can indicate the copying stronger? Like we did with sorting:
> l.sort() sorts
On Fri, Mar 22, 2019 at 07:59:03AM +, Jonathan Fine wrote:
> Steven D'Aprano wrote:
>
> > (For the record, the PEP isn't set in stone in regards to the choice of
> > operator.
>
> Steven: Please say what parts of the PEP you consider to be set in
> stone. This wil
On Thu, Mar 21, 2019 at 08:13:01PM -0400, David Mertz wrote:
> On Thu, Mar 21, 2019, 7:48 PM Steven D'Aprano wrote:
[...]
> Nonetheless, if I see `dict1 + dict2` the meaning you intend in the PEP
> does not jump out as the obvious behavior. Nor even as the most useful
> behavior.
On Thu, Mar 21, 2019 at 06:02:05PM -0400, David Mertz wrote:
> I dislike the symbol '+' to mean "dictionary merging with value updates." I
> have no objection to, and mildly support, adding '|' with this meaning.
>
> It's not really possible to give "that one example" where + for meeting
> makes
On Thu, Mar 21, 2019 at 03:10:48PM -0700, Brandt Bucher wrote:
> For anyone interested in "trying it out": if you're not against cloning and
> compiling CPython yourself, here is a PEP 584 C implementation I have PR'd
> against master right now. I'm keeping it in sync with the draft PEP as it
>
On Thu, Mar 21, 2019 at 09:36:20PM -0400, Terry Reedy wrote:
> I counted what I believe to be 10 instances of copy-update in the top
> level of /lib. Do either of you consider this to be enough that any
> addition would be worthwhile.
I think you're referring to Guido and Antoine? But for
On Thu, Feb 07, 2019 at 03:17:18PM -0500, David Mertz wrote:
> Many apologies if people got one or more encrypted versions of this.
>
> On 2/7/19 12:13 AM, Steven D'Aprano wrote:
>
> It wasn't a concrete proposal, just food for thought. Unfortunately the
> thinking seems to hav
On Thu, Feb 07, 2019 at 10:13:29AM -0800, Mike Miller wrote:
> Was: "Dart (Swift) like multi line strings indentation"
[...]
> Anyone still interested in this?
I am, but it will surely need a PEP. I'm not interested enough to write
the PEP itself but I'm more than happy to tear it to bits^W^W^W
On Sun, Feb 10, 2019 at 01:05:42PM -0500, Kyle Lahnakoski wrote:
> I am interested in vector operations. I have situations where I want to
> perform some conceptually simple operations on a series of
> not-defined-by-me objects to make a series of conclusions. The
> calculations can be done
On Sun, Feb 03, 2019 at 09:46:44PM -0800, Christopher Barker wrote:
> I've lost track if who is advocating what, but:
Ironically, I started this sub-thread in response to your complaint that
you didn't like having to explicitly write loops/maps. So I pointed out
that in Julia, people can use
Before I respond to a specific point below, I'd like to make a general
observation.
I changed the subject line of this sub-thread to discuss a feature of
Julia, which allows one to write vectorized code in standard infix
arithmetic notation, that applies to any array type, using any existing
On Tue, Feb 19, 2019 at 02:13:24PM +, Paul Moore wrote:
> Any linter or project that treats PEP 8 as mandatory has *already*
> failed, as PEP 8 itself states that the rules can be broken as needed.
> Of course individual projects are entirely allowed to impose whatever
> draconian and
On Tue, Feb 19, 2019 at 05:29:33PM +, Jonathan Fine wrote:
> Previously, Samuel wrote that he would leave the conversation, because
> it was primarily opinion based, which he finds annoying.
>
> I then provided evidence (namely how black.py reformats a specific
> code example).
>
> Samuel
On Tue, Feb 19, 2019 at 11:05:55PM +0200, Miikka Salminen wrote:
> Hi!
>
> To help automatic document generators and static type checkers reason more
> about the code, the possible side-effects and raised exceptions could also
> be annotated in a standardized way.
This is Python. Nearly
On Tue, Feb 19, 2019 at 11:38:04AM +0100, Nicolas Rolin wrote:
> I understand that the writer wants to have shorter names, but why would I
> want more ambigious names as a reader ?
> How would you rename number_of_pages_in_current_section such that the
> reader is not left wondering what does
On Wed, Feb 20, 2019 at 01:41:27AM +1100, Chris Angelico wrote:
> page_count will usually be unambiguous. You might need total_pages to
> mean "not the current section", thus leaving the shorter one available
> for the narrower use. Obviously questions like this can't be answered
> without
On Tue, Jan 29, 2019 at 09:21:48PM +, Jonathan Fine wrote:
> I've not been following closely, so please forgive me if I'm repeating
> something already said in this thread.
>
> Summary: str.join allows us to easily avoid, when assembling strings,
> 1. Quadratic running time.
> 2. Redundant
On Tue, Jan 29, 2019 at 10:51:26PM +0100, Jamesie Pic wrote:
> What do you think of list.stringify(delim) ?
What's so special about lists? What do you think of:
tuple.stringify
deque.stringify
iterator.stringify
dict.keys.stringify
etc. And what's so special about strings that
On Wed, Jan 30, 2019 at 12:09:55AM +, Alex Shafer wrote:
> 2) strings are special and worthy of a "special case" because strings
> tend to be human readable and are used in all kinds of user interface.
So are ints, floats, bools, lists, tuples, sets, dicts, etc.
We already have a
This thought is motivated by this bug report:
https://bugs.python.org/issue35857
If you import a module, then edit the .py file that goes with it, and
then an exception occurs, the stack trace can show the wrong line.
It doesn't happen very often, but when it does happen, it can be very
On Wed, Jan 30, 2019 at 11:07:52AM +0100, Jamesie Pic wrote:
> What do you think could be the developer intent when they do
> ",".join([2, "2']) ?
I don't know what your intent was, although I can guess, but I do know
that I sure as hell don't want a dumb piece of software like the
interpreter
1001 - 1100 of 2842 matches
Mail list logo
