Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Tue, Oct 09, 2018 at 01:21:57AM +1100, Chris Angelico wrote: > > > Yet we keep having use-cases shown to us involving one person with one > > > module, and another person with another module, and the interaction > > > between the two. > > > > Do we? I haven't noticed anything that matches that

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Sun, Sep 23, 2018 at 07:09:37AM +0200, Marko Ristin-Kaufmann wrote: > After the discussion we had on the list and after browsing the internet a > bit, I'm still puzzled why design-by-contract was not more widely adopted > and why so few languages support it. [...] > *. *After properly reading

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Sat, Sep 29, 2018 at 12:30:45PM +1200, Greg Ewing wrote: > Chris Angelico wrote: > >But as a part of the > >function's declared intent, it's fine to have a postcondition of "the > >directory will be empty" even though something could drop a file into > >it. > > If you only intend the contract

Re: [Python-ideas] Fix some special cases in Fractions?

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]: Fraction(-1, 1) ** Fraction(2, 3) > Out[5]: (-0.4998+0.8660254037844387j) > > In [6]: Fraction(0, 1) **

Re: [Python-ideas] Why shouldn't Python be better at implementing Domain Specific Languages?

On Fri, Aug 31, 2018 at 11:39:16AM -0400, James Lu wrote: > We should all take a look at Ruby Blocks and think about how Python > could benefit from something similar. You are not the first person to suggest Ruby-like anonymous blocks or multi-statement lambdas.

Re: [Python-ideas] Why shouldn't Python be better at implementing Domain Specific Languages?

On Fri, Aug 31, 2018 at 11:14:35AM +0400, Abdur-Rahmaan Janhangeer wrote: > let me take an example : > > a DSL to calculate the cost of houses [...] > --- file --- > house num 1,000 > house price 250,000 > calculate sum > > --- output --- > $ 250 000 000 I don't think the problem is people

Re: [Python-ideas] Add recordlcass to collections module

On Sun, Sep 02, 2018 at 10:56:50PM +0200, Martin Bammer wrote: > Compared to dataclass: > dataclass wins only on the topic object size. When it comes to speed and > functionality (indexing, sorting) dataclass would be my last choice. I see no sign that recordclass supports sorting. (But I admit

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Sep 04, 2018 at 12:08:31AM +0100, Ivan Levkivskyi wrote: > On Mon, 3 Sep 2018 at 23:51, Greg Ewing wrote: > > > Jonathan Fine wrote: > > > I've just read and article which makes a good case for providing > > > pre-conditions and post-conditions. > > > > > >

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Sep 04, 2018 at 10:50:27AM +1200, Greg Ewing wrote: > Jonathan Fine wrote: > >I've just read and article which makes a good case for providing > >pre-conditions and post-conditions. > > > >http://pgbovine.net/python-unreadable.htm > > There's nothing in there that talks about PBC-style

Re: [Python-ideas] Why is design-by-contracts not widely

On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote: > C and Python (currently) are known as simple languages. o_O That's a usage of "simple" I haven't come across before. Especially in the case of C, which is a minefield of *intentionally* underspecified behaviour which makes it near

Re: [Python-ideas] In fact, I'm a bit worry about this literal p""

On Mon, Dec 31, 2018 at 12:48:56AM -0800, Yuval Greenfield wrote: > In my opinion, only if this change would make 50% of programs run 50% > faster then it might be worth discussing. What if it were 100% of programs 25% faster? *wink* Generally speaking, we don't introduce new syntax as a speed

Re: [Python-ideas] Add regex pattern literal p""

On Thu, Dec 27, 2018 at 05:47:46PM +, MRAB wrote: > On 2018-12-27 11:48, Ma Lin wrote: > [snip] > >2, We can't use regex module as a drop-in replacement: import regex as re > >IMHO, I would like to see regex module be adopted into stdlib after > >cutting off its "full case-folding" and "fuzzy

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

On Fri, Jan 04, 2019 at 01:01:51PM -0600, Abe Dillon wrote: > I keep coming back to this great video about > coding style, and one point in particular rings true to me: > ALL_CAPS_IS_OBNOXIOUS > > It destroys the visual flow of code Does it? This claim doesn't ring

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

On Fri, Jan 04, 2019 at 06:15:11PM -0600, Abe Dillon wrote: > Sure everyone knows what it means, but it's meaning is essentially useless > because the default assumption when you encounter a variable you don't > know, is that you shouldn't overwrite it. If you found a module-level > variable in

Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks

On Sun, Jan 06, 2019 at 01:38:33AM +0100, Simon wrote: > I propose to be able to use the continue keyword to continue the execution > of the try block even when an error is handled. The above could then be > changed to : > > > try: > i = int("string") > print("continued on")

[Python-ideas] NAN handling in the statistics module

Bug #33084 reports that the statistics library calculates median and other stats wrongly if the data contains NANs. Worse, the result depends on the initial placement of the NAN: py> from statistics import median py> NAN = float('nan') py> median([NAN, 1, 2, 3, 4]) 2 py> median([1, 2, 3, 4,

Re: [Python-ideas] NAN handling in the statistics module

On Sun, Jan 06, 2019 at 07:46:03PM -0500, David Mertz wrote: > Would these policies be named as strings or with an enum? Following Pandas, > we'd probably support both. Sure, I can support both. > I won't bikeshed the names, but they seem to > cover desired behaviors. Good to hear. --

Re: [Python-ideas] tkinter: time for round buttons?

On Thu, Jan 17, 2019 at 04:26:06AM +0400, Abdur-Rahmaan Janhangeer wrote: > let us say i'm a novice user, for me py's gui is such. if on Mac it gives > rounded corners but on others no, it's pretty unpredictable. Its not unpredictable at all, it is easy to predict: if I'm using a Mac, it has

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

On Mon, Jan 21, 2019 at 05:56:17PM +1100, Steven D'Aprano wrote: [...] > > And a few more examples for clarity. > > > > def example(): > > locals()['a'] = 1 > > expr = `a+1` > > return expr() # error: one variable is required > > Still not clear to me.

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

On Sun, Jan 20, 2019 at 07:21:50PM -0500, James Lu wrote: > Backtick expressions work exactly like lambdas, except that they are > bound to the instance they are created in every time that class is > used to create one. To illustrate, this “percent” property is bound to > the instance, not to

Re: [Python-ideas] Potential PEP: with/except

On Tue, Jan 22, 2019 at 01:11:10PM -0700, Paul Ferrell wrote: [...] > I would like to propose that the syntax for 'with' blocks > be changed such that they can be accompanied by 'except', 'finally', > and/or 'else' blocks as per a standard 'try' block. What benefit does this give apart from

Re: [Python-ideas] Potential PEP: with/except

I've been thinking more about this proposal, and realised why I've been feeling a slight sense of disquiet about it. I think it encourages an anti-pattern of catching too much. (Or at least a code smell.) Although we're all guilty of violating this principle from time to time, in general we

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

On Mon, Jan 21, 2019 at 05:56:17PM +1100, Steven D'Aprano wrote: [...] > > Variable names that are declared but have not been assigned to will be > > considered to exist for the purposes of the backtick expression. > > Python doesn't have variable declarations, so

Re: [Python-ideas] Potential PEP: with/except

On Tue, Jan 22, 2019 at 03:22:27PM -0700, Paul Ferrell wrote: > Anecdotally, I showed the with/except example to my student (who's > relatively new to python), to see how he interpreted it. He (correctly?) > assumed the CM operations were within the 'try', and was pretty surprised > when I told

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Tue, Dec 11, 2018 at 12:48:10PM +0100, E. Madison Bray wrote: > Right now I'm specifically responding to the sub-thread that Greg > started "Suggested MapView object", so I'm considering this a mostly > clean slate from the previous thread "__len__() for map()". Different > ideas have been

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Mon, Dec 10, 2018 at 05:15:36PM -0800, Chris Barker via Python-ideas wrote: [...] > I'm still confused -- what's so wrong with: > > list(map(func, some_iterable)) > > if you need a sequence? You might need a sequence. Why do you think that has to be an *eager* sequence? I can think of two

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Wed, Dec 12, 2018 at 08:06:17PM -0800, Chris Barker - NOAA Federal wrote: > >>> and the test for an iterator is: > >>> > >>> obj is iter(obj) > > Is that a hard and fast rule? Yes, that's the rule for the iterator protocol. Any object can have an __iter__ method which returns anything you

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Thu, Dec 13, 2018 at 06:53:54PM +1300, Greg Ewing wrote: > In any case, I don't claim that my MapView implements the full > iterator protocol, only enough of it to pass for an iterator in > most likely scenarios that assume one. Whether your hybrid sequence+iterator is close enough to an

Re: [Python-ideas] [asyncio] Suggestion for a major PEP

On Sun, Dec 16, 2018 at 09:21:14AM +0100, Christophe Bailly wrote: > Async/Await logic has introduced a symetric relation wich introduces > unnecessary contraints. We should just the same logic as thread logic. I'm not an expert on async, but whenever I hear people saying "we should use

Re: [Python-ideas] struct.unpack should support open files

On Wed, Dec 26, 2018 at 03:10:05AM -0800, Nathaniel Smith wrote: > On Wed, Dec 26, 2018, 02:19 Andrew Svetlov > > > > Also I'm thinking about type annotations in typeshed. > > Now the type is Union[array[int], bytes, bytearray, memoryview] > > Should it be Union[io.BinaryIO, array[int], bytes,

Re: [Python-ideas] struct.unpack should support open files

On Wed, Dec 26, 2018 at 12:18:23PM +0200, Andrew Svetlov wrote: [...] > > json is correct: if `read()` is called without argument it reads the whole > content until EOF. > But with size argument the is different for interactive and non-interactive > streams. > RawIOBase and BufferedIOBase also

Re: [Python-ideas] struct.unpack should support open files

On Tue, Dec 25, 2018 at 04:51:18PM -0600, eryk sun wrote: > On 12/24/18, Drew Warwick wrote: > > The struct unpack API is inconvenient to use with files. I must do: > > > > struct.unpack(fmt, file.read(struct.calcsize(fmt)) > > Alternatively, we can memory-map the file via mmap. An important >

Re: [Python-ideas] struct.unpack should support open files

On Wed, Dec 26, 2018 at 09:48:15AM +0200, Andrew Svetlov wrote: > The perfect demonstration of io objects complexity. > `stream.read(N)` can return None by spec if the file is non-blocking > and have no ready data. > > Confusing but still possible and documented behavior.

Re: [Python-ideas] struct.unpack should support open files

On Tue, Dec 25, 2018 at 01:28:02AM +0200, Andrew Svetlov wrote: > The proposal can generate cryptic messages like > `a bytes-like object is required, not 'NoneType'` How will it generate such a message? That's not obvious to me. The message doesn't seem cryptic to me. It seems perfectly clear:

Re: [Python-ideas] struct.unpack should support open files

On Thu, Dec 27, 2018 at 10:02:09AM +1100, Cameron Simpson wrote: [...] > >Also I'm thinking about type annotations in typeshed. > >Now the type is Union[array[int], bytes, bytearray, memoryview] > >Should it be Union[io.BinaryIO, array[int], bytes, bytearray, > >memoryview] ? > > And this is

Re: [Python-ideas] struct.unpack should support open files

On Wed, Dec 26, 2018 at 01:32:38PM +, Paul Moore wrote: > On Wed, 26 Dec 2018 at 09:26, Steven D'Aprano wrote: > > Regardless, my point doesn't change. That has nothing to do with the > > behaviour of unpack. If you pass a non-blocking file-like object which > > returns

Re: [Python-ideas] TAPS Implementation

Hi Max, and welcome! On Mon, Dec 10, 2018 at 09:47:07PM +, Franke, Maximilian Julian Shawn wrote: [...] > We are currently looking into implementing TAPS, a novel way to offer > transport layer services to the application layer. [...] > TAPS is currently being standardized ... > Here you can

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Wed, Dec 12, 2018 at 11:31:03AM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >I suggest we provide a separate mapview() type that offers only the lazy > >sequence API, without trying to be an iterator at the same time. > > Then we would be back to the bad o

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Wed, Dec 12, 2018 at 12:50:41PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >The iterator protocol is that iterators must: > > > >- have a __next__ method; > >- have an __iter__ method which returns self; > > > >and the test for an

Re: [Python-ideas] struct.unpack should support open files

On Mon, Dec 24, 2018 at 03:01:07PM +0200, Andrew Svetlov wrote: > Handling files overcomplicates both implementation and mental space for API > saving. Perhaps. Although the implementation doesn't seem that complicated, and the mental space for the API not that much more difficult: unpack

Re: [Python-ideas] About the passing the function arguments in Keyword form.

On Mon, Dec 24, 2018 at 06:21:31PM +0800, 李默 wrote: > I am having an idea on loosing the argument validity check when passing the > function arguments in keyword way. > For example: > --- > deff(x, y): > print(x, y) > defcall_f(): > f(x=7, y=9, z=9) > > >

Re: [Python-ideas] struct.unpack should support open files

On Mon, Dec 24, 2018 at 03:36:07PM +, Paul Moore wrote: > > There should be no difference whether the text comes from a literal, a > > variable, or is read from a file. > > One difference is that with a file, it's (as far as I can see) > impossible to determine whether or not you're going to

Re: [Python-ideas] __len__() for map()

On Fri, Nov 30, 2018 at 10:32:31AM +0100, E. Madison Bray wrote: > I think it goes without saying that > map() is special in a way: It's one of the most basic extensions to > function application and is a fundamental construct in functional > programming and from a category-theortical

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

On Tue, Nov 27, 2018 at 10:47:06PM -0600, Abe Dillon wrote: > If we could figure out a cleaner syntax for defining invariants, > preconditions, and postconditions we'd be half-way to automated testing > UTOPIA! (ok, maybe I'm being a little over-zealous) You should look at the state of the art

Re: [Python-ideas] __len__() for map()

On Thu, Nov 29, 2018 at 08:13:12PM -0500, Paul Svensson wrote: > Excellent proposal, followed by a flood of confused replies, > which I will mostly disregard, since all miss the obvious. When everyone around you is making technical responses which you think are "confused", it is wise to

Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads

On Fri, Dec 07, 2018 at 01:25:19PM -0800, Nathaniel Smith wrote: > For this specific purpose, md5 is just as good as a proper hash. But all > else being equal, it would still be better to use a proper hash, just so > people don't have to go through the whole security analysis to check that. I

Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads

On Sat, Dec 08, 2018 at 11:05:43AM +0900, INADA Naoki wrote: > We already use SHA256 on PyPI. > Many project in the world moving from md5 to SHA256. [...] How easy is it to use sha256 on the major platforms, compared to md5? On Linux, it is just as easy: [steve@ando ~]$ md5sum x.py

Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads

On Fri, Dec 07, 2018 at 04:35:56PM -0800, Nathaniel Smith wrote: > On Fri, Dec 7, 2018 at 3:38 PM Steven D'Aprano wrote: > > > On Fri, Dec 07, 2018 at 01:25:19PM -0800, Nathaniel Smith wrote: > > > > > For this specific purpose, md5 is just as good as a proper has

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

On Mon, Dec 03, 2018 at 02:04:31AM +1300, Greg Ewing wrote: > Chris Angelico wrote: > >I can't help thinking that it will be extremely surprising to have the > >length remain the same while the items get consumed. > > That can be fixed. The following version raises an exception if > you try to

Re: [Python-ideas] __len__() for map()

On Thu, Nov 29, 2018 at 02:16:48PM +0100, E. Madison Bray wrote: > Okay, let's keep it simple: > > m = map(str, [1, 2, 3]) > len_of_m = None > if len(m.iters) == 1 and isinstance(m.iters[0], Sized): > len_of_m = len(m.iters[0]) > > You can give me pathological cases where that isn't true,

Re: [Python-ideas] __len__() for map()

On Thu, Nov 29, 2018 at 12:16:37PM +0100, E. Madison Bray wrote: > On Wed, Nov 28, 2018 at 11:27 PM Steven D'Aprano wrote: ["it" below being the length of an arbitrary iterator] > > If we could solve it, that would be great -- but I'm not convinced that > > it is sol

Re: [Python-ideas] __len__() for map()

On Thu, Nov 29, 2018 at 10:21:15PM +1100, Chris Angelico wrote: > On Thu, Nov 29, 2018 at 10:18 PM E. Madison Bray > wrote: > > > > On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico wrote: > > > > > > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray > > > wrote: [...] > > > If that's the case,

Re: [Python-ideas] __len__() for map()

On Sat, Dec 01, 2018 at 11:07:53AM -0500, Paul Svensson wrote: [...] > >Here's a map object I prepared earlier: > > > >from itertools import islice > >mo = map(lambda x: x, "aardvark") > >list(islice(mo, 3)) > > > >If I now pass you the map object, mo, what should len(mo) return? Five > >or

Re: [Python-ideas] __len__() for map()

On Sat, Dec 01, 2018 at 12:06:23PM -0500, David Mertz wrote: > Given that the anti-fix is just as simple and currently available, I don't > see why we'd want a change: > > # map->sequence > mo = list(mo) > > FWIW, I actually do write exactly that code fairly often, it's not hard. Sure, but

Re: [Python-ideas] __len__() for map()

On Sat, Dec 01, 2018 at 11:27:31AM -0500, David Mertz wrote: > A proposal to make map() not return an iterator seems like a non-starter. > Yes, Python 2 worked that way, but that was a long time ago and we know > better now. Paul is certainly not suggesting reverting the behaviour to the Python2

Re: [Python-ideas] Enhancing range object string displays

On Mon, Nov 19, 2018 at 05:09:25PM -0800, danish bluecheese wrote: > I think it is kind of useless effort. If somebody using range() then > probably knows about it. For experienced users, sure, but this is an enhancement to help beginners who may be confused by the half-open end points. Even

[Python-ideas] Enhancing range object string displays

On the bug tracker, there is a proposal to enhance range objects so that printing them will display a snapshot of the values included, including the end points. For example: print(range(10)) currently displays "range(10)". The proposal is for the __str__ method to instead return "".

Re: [Python-ideas] __len__() for map()

On Wed, Nov 28, 2018 at 04:14:24PM +0100, E. Madison Bray wrote: > For example, some function that used to expect some finite-sized > sequence such as a list or tuple is now passed a "map", possibly > wrapping one or more iterable of arbitrary, possibly non-finite size. > For the purposes of some

Re: [Python-ideas] __len__() for map()

On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote: > I mostly agree with the existing objections, though I have often found > myself wanting this too, especially now that `map` does not simply > return a list. This problem alone (along with the same problem for > filter) has had a

Re: [Python-ideas] __len__() for map()

On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote: > That effort is already mostly done and adding a helper function would > not have worked as users *passing* map(...) as an argument to some > function just expect it to work. Ah, that's what I was missing. But... surely the

Re: [Python-ideas] __len__() for map()

On Wed, Nov 28, 2018 at 05:37:39PM +0100, Anders Hovmöller wrote: > > > > I just mentioned that porting effort for background. I still believe > > that the actual proposal of making the arguments to a map(...) call > > accessible from Python as attributes of the map object (ditto filter, > >

Re: [Python-ideas] __len__() for map()

On Wed, Nov 28, 2018 at 02:53:50PM -0500, Terry Reedy wrote: > One of the guidelines in the Zen of Python is > "Special cases aren't special enough to break the rules." > > This proposal claims that the Python 3 built-in iterator class 'map' is > so special that it should break the rule that

Re: [Python-ideas] __len__() for map()

On Mon, Nov 26, 2018 at 10:14:58PM +, Jonathan Fine wrote: > Briefly, I don't like your suggestion because many important iterables > don't have a length! But many important iterables do. -- Steve ___ Python-ideas mailing list

Re: [Python-ideas] __len__() for map()

On Mon, Nov 26, 2018 at 02:06:52PM -0800, Michael Selik wrote: > If you know the input is sizeable, why not check its length instead of the > map's? The consumer of map may not be the producer of map. You might know that alist supports len(), but by the time I see it, I only see map(f, alist),

Re: [Python-ideas] __len__() for map()

On Mon, Nov 26, 2018 at 01:29:21PM -0800, Kale Kundert wrote: > 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 map() could be given an infinite sequence and therefore > might

Re: [Python-ideas] __len__() for map()

On Tue, Nov 27, 2018 at 09:36:08AM +1100, Chris Angelico wrote: > Don't forget, too, that map() can take more than one iterable I forgot about that! But in this case, I think the answer is obvious: the length of the map object is the *smallest* length of the iterables, ignoring any unsized or

Re: [Python-ideas] NAN handling in the statistics module

On Mon, Jan 07, 2019 at 11:27:22AM +1100, Steven D'Aprano wrote: [...] > I propose adding a "nan_policy" keyword-only parameter to the relevant > statistics functions (mean, median, variance etc), and defining the > following policies: I asked some heavy users of statistics

Re: [Python-ideas] NAN handling in the statistics module

On Mon, Jan 07, 2019 at 02:01:34PM +, Jonathan Fine wrote: > Finally, I suggest that we might learn from > == > Fix some special cases in Fractions? > https://mail.python.org/pipermail/python-ideas/2018-August/053083.html > == I remember that thread from August, and I've just re-read the

Re: [Python-ideas] NAN handling in the statistics module

On Mon, Jan 07, 2019 at 10:05:19AM -0500, David Mertz wrote: > On Mon, Jan 7, 2019 at 6:50 AM Steven D'Aprano wrote: > > > > I'll provide a suggested batch on the bug. It will simply be a wholly > > > different implementation of median and friends. > > >

Re: [Python-ideas] NAN handling in the statistics module

On Mon, Jan 07, 2019 at 01:34:47AM -0500, David Mertz wrote: > > I'm not opposed to documenting this better. Patches welcome :-) > > > > I'll provide a suggested batch on the bug. It will simply be a wholly > different implementation of median and friends. I ask for a documentation patch and

Re: [Python-ideas] NAN handling in the statistics module

On Mon, Jan 07, 2019 at 07:35:45PM +, MRAB wrote: > Could the functions optionally accept a callback that will be called > when a NaN is first seen? > > If the callback returns False, NaNs are suppressed, otherwise they are > retained and the function returns NaN (or whatever). That's an

Re: [Python-ideas] NAN handling in the statistics module

On Tue, Jan 08, 2019 at 04:25:17PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > By definition, data containing Not A Number values isn't numeric :-) > > Unfortunately, that's just a joke, because in fact numeric functions > produce NaNs. I'm not su

Re: [Python-ideas] NAN handling in the statistics module

(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, Nathaniel Smith wrote: > On Sun, Jan 6, 2019 at 11:06 PM Steven D'Aprano wrote: >

Re: [Python-ideas] Fixed point format for numbers with locale based separators

On Fri, Jan 04, 2019 at 03:57:53PM +0100, Łukasz Stelmach wrote: > Hi, > > I would like to present two pull requests[1][2] implementing fixed point > presentation of numbers and ask for comments. The first is mine. I > learnt about the second after publishing mine. Before I look at the

Re: [Python-ideas] Add regex pattern literal p""

On Sat, Dec 29, 2018 at 04:29:32PM +1100, Alexander Heger wrote: > for regular strings one can write > > "aaa" + "bbb" > > which also works for f-strings, r-strings, etc.; in regular expressions, > there is, e.g., parameter counting and references to numbered matches. How > would that be dealt

Re: [Python-ideas] NAN handling in the statistics module

On Sun, Jan 06, 2019 at 10:52:47PM -0500, David Mertz wrote: > Playing with Tim's examples, this suggests that statistics.median() is > simply outright WRONG. I can think of absolutely no way to characterize > these as reasonable results: > > Python 3.7.1 | packaged by conda-forge | (default,

Re: [Python-ideas] NAN handling in the statistics module

On Sun, Jan 06, 2019 at 07:40:32PM -0800, Stephan Hoyer wrote: > On Sun, Jan 6, 2019 at 4:27 PM Steven D'Aprano wrote: > > > I propose adding a "nan_policy" keyword-only parameter to the relevant > > statistics functions (mean, median, variance etc), and definin

Re: [Python-ideas] Keyword only argument on function call

On Wed, Sep 12, 2018 at 06:59:44AM -0700, Ethan Furman wrote: > On 09/12/2018 05:17 AM, Steven D'Aprano wrote: [...] > >We could solve this race condition with locking, or by making the pair > >of steps: [...] > >I'm not an expert on threaded code, so it is possible I'

Re: [Python-ideas] Keyword only argument on function call

On Wed, Sep 12, 2018 at 03:58:25PM +0100, Jonathan Fine wrote: > My question is about correctly implementing of __params__ as a keyword > identifier, with semantics as in Steve B's code snippet above. The semantics of Steve's code snippet are ambiguous. > Here's my question: Do you think

Re: [Python-ideas] PTPython REPL in IDLE

On Wed, Sep 12, 2018 at 05:15:51PM -0400, James Lu wrote: > Have y’all seen ptpython’s autocomplete and syntax highlighting > features? No. Do you have a link? What specific features have excited you? The standard Python REPL now comes with autocomplete turned on by default. How does that

Re: [Python-ideas] Keyword only argument on function call

On Wed, Sep 12, 2018 at 02:23:34PM +0100, Jonathan Fine wrote: > Steve Barnes suggested adding __params__, as in > > > def a_method(self, cr, uid, ids, values, context=None): > >... > >params = {k:v for k,v in __params__ if k in parent.a_method.keys()} > ># Possibly

Re: [Python-ideas] Keyword only argument on function call

On Tue, Sep 11, 2018 at 04:57:16PM +0100, Jonathan Fine wrote: > Summary: locals() and suggestion __params__ are similar, and roughly > speaking each can be implemented from the other. You cannot get a snapshot of the current locals just from the function parameters, since the current locals

Re: [Python-ideas] __len__() for map()

On Sat, Dec 01, 2018 at 12:28:16PM -0500, David Mertz wrote: > Other than being able to ask len(), are there any advantages to a slightly > less opaque map()? Getting the actual result of applying the function to > the element is necessarily either eager or lazy, you can't have both. I don't

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 02:04:12PM +0100, Thomas Güttler Lists wrote: > Example: > >     status = backend.transmit_data() > > But later you want to add something to the API. [...] > How could kwargs for return look like? return {'status': True, 'messages': []} Or perhaps better: return

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 03:29:59PM +0100, Anders Hovmöller wrote: > > > 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 > >

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 12:01:55PM -0500, Wes Turner wrote: > Tuples are a dangerous (and classic, legacy) interface contract. What? -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 11:59:36AM -0500, Wes Turner wrote: > This about object destructuring in JS is worth a read: > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuring Thanks. -- Steve

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:20:11AM -0800, Christopher Barker wrote: > My first thought was that function return tuples, so you could document > that your function should be called as such: > > x = fun()[0] > > but, alas, tuple unpacking is apparently automatically disabled for single > value

Re: [Python-ideas] kwargs for return

On Sat, Jan 26, 2019 at 10:20:11AM -0800, Christopher Barker wrote: [...] > Starting with the simplest example, when defining a function, you > can have one take a single positional parameter: [...] > Later on, if you want to exapand the API, ytou can add a keyword parameter: > > def fun(x,

Re: [Python-ideas] kwargs for return

On Sun, Jan 27, 2019 at 03:33:15PM +1100, Cameron Simpson wrote: > I don't think so. It looks to me like Thomas' idea is to offer a > facility a little like **kw in function, but for assignment. Why **keyword** arguments rather than **positional** arguments? Aside from the subject line, what

Re: [Python-ideas] Single line single expression try/except syntax

On Sun, Jan 27, 2019 at 07:21:36PM -0800, Ben Rudiak-Gould wrote: > If Guido wrote that rejection of PEP 463 then I can't help thinking that he > changed his perspective between then and PEP 572 and might have > accepted PEP 463 if it had been proposed more recently. Maybe, maybe not, but either

Re: [Python-ideas] Single line single expression try/except syntax

On Mon, Jan 28, 2019 at 02:52:54PM +1100, Steven D'Aprano wrote: > Maybe, maybe not, but either way Michael's advice that any discussion > about try/except expressions should respond to the points raised in PEP > 463. Oops, incomplete sentence... I meant that Michael's advice t

Re: [Python-ideas] New explicit methods to trim strings

On Mon, Apr 01, 2019 at 09:34:21PM -0400, David Mertz wrote: > On Mon, Apr 1, 2019, 8:54 PM Steven D'Aprano wrote: > > > The point I am making is not that we must not ever support multiple > > affixes, but that we shouldn't rush that decision. Let's pick the > > low-han

[Python-ideas] Lessons learned from an API design mistake [was New explicit methods to trim strings]

I think the point Chris made about statistics.mode is important enough to start a new subthread about API design, and the lessons learned. On Mon, Apr 01, 2019 at 02:29:44PM +1100, Chris Angelico wrote: > We're basically debating collision semantics here. It's on par with > asking "how should

Re: [Python-ideas] New explicit methods to trim strings

On Sun, Mar 31, 2019 at 08:23:05PM -0400, David Mertz wrote: > On Sun, Mar 31, 2019, 8:11 PM Steven D'Aprano wrote: > > > Regarding later proposals to add support for multiple affixes, to > > recursively delete the affix repeatedly, and to take an additional > > ar

Re: [Python-ideas] New explicit methods to trim strings

Thank you, this is a simple, unambiguous proposal which meets a real need and will help prevent a lot of wasted developer time misusing [lr]strip and then reporting it as a bug: remove a single prefix or suffix. This is a useful string primitive provided by other modern languages and libraries,

Re: [Python-ideas] New explicit methods to trim strings

On Wed, Apr 03, 2019 at 09:58:07AM +1100, Cameron Simpson wrote: [...] > Yeah. I was looking at the prefix list from a related article and seeing > "intra" and thinking "intractable". Hacky indeed. That example supports my position that we ought to be cautious about allowing multiple prefixes.

Re: [Python-ideas] New explicit methods to trim strings

On Tue, Apr 02, 2019 at 07:28:01PM +0100, MRAB wrote: [...] > > word[len(prefix) if word.startswith(prefix) else 0:] > > > It could be 'improved' more to: > > word[word.startswith(prefix) and len(prefix) : ] [...] > _Neither_ version copies if the word doesn't start with the prefix. If >

Re: [Python-ideas] New explicit methods to trim strings

On Mon, Apr 01, 2019 at 02:29:44PM +1100, Chris Angelico wrote: > The multiple affix case has exactly two forms: > > 1) Tearing multiple affixes off (eg stripping "asdf.jpg.png" down to > just "asdf"), which most people are saying "no, don't do that, it > doesn't make sense and isn't needed"

Re: [Python-ideas] New explicit methods to trim strings

On Fri, Mar 29, 2019 at 04:05:55PM -0700, Christopher Barker wrote: > This proposal would provide a minor gain for an even more minor disruption. I don't think that is correct. I think you are underestimating the gain and exaggerating the disruption :-) Cutting a prefix or suffix from a string

<    5   6   7   8   9   10   11   12   13   14   >