On Tue, Jun 1, 2021 at 5:40 AM David Mertz wrote:
>
> I think making 'Ellipsis' a reserved word is too much. The analogy with
> non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate
> this, I think. I.e. redefining those is likely to cause bad things to
> happen, but we'
On Tue, Jun 1, 2021 at 6:22 AM Serhiy Storchaka wrote:
>
> 31.05.21 22:46, Chris Angelico пише:
> > Originally, the notation "..." could only be used inside a subscript,
> > and anywhere else, you'd have to spell it "Ellipsis". Now that you can
> >
On Tue, Jun 1, 2021 at 9:57 PM Steven D'Aprano wrote:
>
> On Thu, May 27, 2021 at 12:33:20PM -0400, Ricky Teachey wrote:
>
> > On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano
> > wrote:
> > >
> > > Okay. Without reading the source code, does this code snippet use the
> > > old `__call__` protoco
On Tue, Jun 1, 2021 at 10:16 PM Steven D'Aprano wrote:
> The only slightly awkward case is the bare variable case. Most of the
> time there will be no overlap between the function/class decorators and
> the bare variable decorator, but in the rare case that we need to use a
> single function in bo
On Wed, Jun 2, 2021 at 10:40 AM Steven D'Aprano wrote:
>
> On Tue, Jun 01, 2021 at 04:30:25PM -0400, Steele Farnsworth wrote:
>
> > This was proposed in 2014 and was rejected:
> > https://www.python.org/dev/peps/pep-0463/
>
> No, that's a proposal for a Python *expression* that can be imbedded in
On Wed, Jun 2, 2021 at 10:59 AM Steven D'Aprano wrote:
>
> On Wed, Jun 02, 2021 at 10:47:46AM +1000, Chris Angelico wrote:
>
> > I can understand the confusion though, given that the parallel
> > constructs cited for justification are all expressions.
>
&
On Wed, Jun 2, 2021 at 1:17 PM Julia Schmidt wrote:
>
> From https://docs.python.org/3.10/whatsnew/3.10.html:
>
> def http_error(status):
> match status:
> case 400:
> return "Bad request"
> case 404:
> return "Not found"
> case 418:
>
On Wed, Jun 2, 2021 at 7:01 PM Shreyan Avigyan
wrote:
>
> I want to propose a try-except expression to handle expression errors not
> stmt errors (Yes I initially proposed stmt but now I'm changing it to
> expressions after I researched a little more and found it would make a whole
> lot of sen
On Fri, Jun 4, 2021 at 10:02 PM Thomas Güttler wrote:
>
> Hi,
>
> I have a crazy idea how to extend Python for web development.
>
> What do you think? What are the next steps?
>
> [chomp details]
Something like this - but more generic - has been proposed already:
https://www.python.org/dev/peps/
On Thu, Jun 10, 2021 at 11:50 PM Thomas Güttler wrote:
>
>
>
> Am Do., 10. Juni 2021 um 15:33 Uhr schrieb David Mertz :
>>
>> Strong -1
>>
>> As others noted in prior discussion, even if this existed, it works be an
>> anti-pattern for SQL. So basically, it's just baking in an HTML-only
>> templ
On Thu, Jun 10, 2021 at 11:58 PM Ricky Teachey wrote:
>
> Something I don't understand is whether there is anything about this proposed
> feature that can't be accomplished with a simple function.
>
> IIUC, the proposal turns this:
>
> foo = "spam & eggs"
> `Here, have some {foo}.`
>
> ...into so
On Mon, Jun 14, 2021 at 8:58 AM Jim Baker wrote:
>
> * Logging strings which don't have to format their expressions - so similar
> to current logging when not using f-strings, but with the easy interface of
> f-strings, including desired formatting of expressions in simple logger
> scenarios
>
On Wed, Jun 16, 2021 at 10:51 AM Soni L. wrote:
>
> Sometimes it would be useful to be able to write:
>
> def foo():
> try: return thing()
> except ValueError;
> try: return otherthing()
> except ValueError;
> try: return yetotherthing()
> except ValueError;
> if shouldraise(): raise
On Wed, Jun 16, 2021 at 11:45 AM Steven D'Aprano wrote:
>
> On Wed, Jun 16, 2021 at 10:56:12AM +1000, Chris Angelico wrote:
>
> > Dangerous idea - my first interpretation of that syntax was that it
> > would be equivalent to "except ValueError: pass", whi
On Thu, Jun 17, 2021 at 9:04 AM Christopher Barker wrote:
>
> >
>>
>> The performance error for strings should be considered an anomaly, not a
>> feature to be extended to anything that could be used, or misused, with
>> non-linear behaviour.
>
>
> I’m pretty sure that using sum with strings was a
On Thu, Jun 17, 2021 at 9:46 AM Oliver Margetts
wrote:
>
> > I'm not sure why it doesn't special-case it to "".join()
> One reason might be because you'd have to read the entire iterator to know if
> it really was only strings. So there are concerns with generators which
> complicate things a fa
On Thu, Jun 17, 2021 at 3:27 PM David Mertz wrote:
>
> On Thu, Jun 17, 2021, 1:14 AM Christopher Barker
>>>
>>> I'm sympathetic to raising an exception on `sum(list_of_lists)` similar to
>>> `sum(list_of_strings)`. But what exactly is the recommended substitute?
>>> We have this:
>>>
>>> list(
On Thu, Jun 17, 2021 at 4:07 PM Guido van Rossum wrote:
>
> Just trolling along, flattening a list could be written as
>
> functools.reduce(list.__iadd__, xs, [])
>
> Right?
>
Insufficiently trolly - lacks walrus operator. :)
>>> l = [[1,2],[3,4],[5,6],[7,8],[9]]
>>> any(map((x:=[]).extend, l))
On Fri, Jun 18, 2021 at 12:43 AM Wes Turner wrote:
>
> > What would be the advantage of such a declaration?
>
> Constants don't need to be locked or unlocked; which is advantageous for
> parallelism and reasoning about program correctness.
> True consts (wherein everything referred to in that obj
On Fri, Jun 18, 2021 at 3:42 AM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > But logically, there is a significant difference between putting code
> > inside the except block, and having "except X: pass" and then putting
> > code after. Code
On Fri, Jun 18, 2021 at 3:43 AM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > Insufficiently trolly - lacks walrus operator. :)
> >
> > >>> l = [[1,2],[3,4],[5,6],[7,8],[9]]
> > >>> any(map((x:=[]).extend, l)) or x
> >
On Fri, Jun 18, 2021 at 11:13 PM Stephen J. Turnbull
wrote:
> Serhiy writes that a reason for not allowing this is that you'd want
> to allow [x, y for x in l], splicing the x, y values into the result
> list. That doesn't make sense to me, for two reasons. x, y already
> has a meaning in that c
On Sat, Jun 19, 2021 at 5:13 PM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 19/06/2021 05:33, Guido van Rossum wrote:
>
> On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano wrote:
>>
>> On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
>>
>> > Note the ambiguity around whether the
On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote:
>
>
>
> On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> > Soni L. writes:
> >
> > > The trick to extension methods is that they're only available when you
> > > explicitly use them.
> >
> > What does "explicitly use them" mean? How does this
On Tue, Jun 22, 2021 at 3:43 AM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 01:49:56AM +1000, Chris Angelico wrote:
>
> > So what you're saying is that, in effect, every attribute lookup has
> > to first ask the object itself, and then ask the module? Whi
On Tue, Jun 22, 2021 at 3:55 AM Soni L. wrote:
>
>
>
> On 2021-06-21 12:49 p.m., Chris Angelico wrote:
> > On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote:
> > >
> > >
> > >
> > > On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> > &
On Tue, Jun 22, 2021 at 10:40 AM Steven D'Aprano wrote:
> > True, all true, but considering that this is *not* actually part of
> > the class, some of that doesn't really apply. For instance, is it
> > really encapsulation? What does that word even mean when you're
> > injecting methods in from th
On Tue, Jun 22, 2021 at 8:01 PM Steven D'Aprano wrote:
> The whole point of extension methods is that once the caller opts in to
> use them, method look ups (and that includes hasattr and getattr) must
> work as if the extension methods **are in place**.
>
> The must be no semantic difference betw
On Tue, Jun 22, 2021 at 9:23 PM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 05:50:48PM +1000, Chris Angelico wrote:
>
> > Hmm, that's not what I'd usually understand "encapsulation" to mean.
> > That's what would normally be called "
On Tue, Jun 22, 2021 at 9:56 PM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 09:12:53PM +1000, Chris Angelico wrote:
>
> > > The must be no semantic difference between:
> > >
> > > obj.method(arg)
> > >
> > > and
> >
On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> Think about it like this, extension methods give you the ability to make
> imported functions that look like this:
>
> foo(bar, baz)
>
> look like this instead:
>
> bar.foo(baz)
>
> That's all there is to them. They're just a lie to change how you
>
On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
>
>
>
> On 2021-06-22 5:23 p.m., Chris Angelico wrote:
> > On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> > > Think about it like this, extension methods give you the ability to make
> > > imported functions
On Wed, Jun 23, 2021 at 8:30 AM Soni L. wrote:
>
>
>
> On 2021-06-22 5:54 p.m., Chris Angelico wrote:
> > On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
> > > It would have local scope, similar to uh... locals. Y'know how locals
> > > are just
On Wed, Jun 23, 2021 at 9:06 AM Soni L. wrote:
> On 2021-06-22 7:38 p.m., Chris Angelico wrote:
> > Have you actually tried designing this into a larger project to see
> > what problems you run into, or is this something you've only
> > considered at this trivial leve
On Wed, Jun 23, 2021 at 11:40 AM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 10:25:33PM +1000, Chris Angelico wrote:
>
> > > If its a problem for getattr, it is a problem for dot syntax, because
> > > they are essentially the same thing.
> >
>
On Wed, Jun 23, 2021 at 6:25 PM Steven D'Aprano wrote:
> Soni, and Chris, you seem to be responding as if extension methods are
> clearly, obviously and self-evidently a stupid idea. Let me remind you
> that at least ten languages (C#, Java, Typescript, Oxygene, Ruby,
> Smalltalk, Kotlin, Dart, VB
On Wed, Jun 23, 2021 at 6:49 PM Brendan Barnwell wrote:
> There aren't many things in Python that work this way. Future imports
> are the main one, but those are rare (and rightly so). The import
> machinery itself provides some possibility for this (as used by stuff
> like macropy) but
On Wed, Jun 23, 2021 at 11:25 PM Steven D'Aprano wrote:
>
> On Wed, Jun 23, 2021 at 03:47:05PM +1000, Chris Angelico wrote:
>
> > Okay. Lemme give it to you *even more clearly* since the previous
> > example didn't satisfy.
> >
> > # file1.py
On Thu, Jun 24, 2021 at 7:51 PM Steven D'Aprano wrote:
>
> I'm not sure if you completely understand the use-case I was describing,
> so let me clarify for you with a concrete example.
>
> Ints have a "bit_length" method, starting from Python 2.7. I needed to
> use that method going all the way ba
On Fri, Jun 25, 2021 at 3:31 AM Steven D'Aprano wrote:
>
> Here's a quick and dirty proof of concept I knocked up in about 20
> minutes, demonstrating that no deep compiler magic is needed. It's just
> a small change to the way `object.__getattribute__` works.
>
> I've emulated it with my own base
On Fri, Jun 25, 2021 at 1:54 PM Ricky Teachey wrote:
>
> Would this feature allow me to declare str objects as not iterable in some
> contexts?
>
> If so, +1.
>
That depends. If the proposal is to intercept every attribute lookup
(parallel to a class's __getattribute__ method), then yes, but if
On Fri, Jun 25, 2021 at 7:43 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > if it's a fallback after default behaviour fails (like __getattr__)
> > [...] it's likely to impact performance a lot less.
>
> I guess the effect on performance is
On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum wrote:
>
> On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote:
>>
>> I am not fully aware of how ssl.SSLContext is used, but adding __slots__
>> would prevent this. You would see an error similar to: AttributeError:
>> 'MyClass' object has no attribut
On Sat, Jun 26, 2021 at 5:09 AM Guido van Rossum wrote:
>
> On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico wrote:
>>
>> On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum wrote:
>> >
>> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote:
>> >>
>
On Tue, Jun 29, 2021 at 7:51 AM Max Shouman wrote:
>
> This is more of a syntactic sugar than an actual new feature, but...
> Exactly, 'but' is the idea: a special keyword to be used in for statements to
> exclude values from the iterable.
>
> E.g., when iterating over a generator:
> >>> for i in
On Tue, Jun 29, 2021 at 5:04 PM Steven D'Aprano wrote:
>
> On Tue, Jun 29, 2021 at 01:37:59AM +0100, Rob Cliffe via Python-ideas wrote:
>
> > for i in range(0, 10): if i not in range(2, 8):
> >
> > # This is arguably slightly easier to read than having two separate
> > lines,
>
> "Arg
On Tue, Jun 29, 2021 at 7:15 PM Steven D'Aprano wrote:
>
> On Tue, Jun 29, 2021 at 05:17:36PM +1000, Chris Angelico wrote:
>
> > What if you loop over the values in the range(0, 10) but skip all of
> > the odd numbers? Is that two concepts too?
>
> Of course it is
On Tue, Jun 29, 2021 at 8:29 PM Steven D'Aprano wrote:
>
> On Tue, Jun 29, 2021 at 07:27:11PM +1000, Chris Angelico wrote:
>
> > My point is that the *iteration* isn't any different - the *range* is
> > what's different. A filtered range makes very good sen
On Tue, Jul 6, 2021 at 6:10 AM Jim Baker wrote:
>
> On Mon, Jul 5, 2021, 12:56 PM Barry Scott wrote:
>>
>>
>>
>> On 5 Jul 2021, at 08:07, Thomas Güttler wrote:
>>
>> This means backticks, but without the dollar sign.
>>
>>
>> In bash the backtick was so often a problem that $(cmd) was added.
>>
On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing wrote:
>
> On 6/07/21 9:56 am, Jim Baker wrote:
> >
> > d = deferred_tag"Some expr: {:(x*2)}"
> >
> > All that is happening here is that this being wrapped in a lambda, which
> > captures any scope lexically as usual.
>
> Is there reason to think this will
On Tue, Jul 6, 2021 at 10:44 AM Guido van Rossum wrote:
>
> On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico wrote:
>>
>> On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing
>> wrote:
>> >
>> > On 6/07/21 9:56 am, Jim Baker wrote:
>> > >
>> >
On Wed, Jul 14, 2021 at 11:22 AM Steven D'Aprano wrote:
>
> On Tue, Jul 13, 2021 at 10:27:55PM +0300, Serhiy Storchaka wrote:
>
> > The writelines method is the part of interface. Adding new parameter or
> > new method to interface is a major breaking change. It will make invalid
> > all existing
On Wed, Jul 14, 2021 at 10:53 PM wrote:
>
> Hey dear community,
>
> I want to use advanced RGB Coloring in python for teminals.
>
> There are already some modules but not advancrd enough.
>
> I hope this feature will be added in the next python versions!
>
>
> I believe in this strong community, t
On Thu, Jul 22, 2021 at 1:14 AM Sven Voigt wrote:
>
> Paul,
>
> I agree that the mapping to a flat data structure might have limited use
> cases. However, like you said it is only one example. What I am proposing is
> a nested iteration tool that can map both keys and values to new keys and new
On Thu, Jul 22, 2021 at 1:28 AM Sven Voigt wrote:
>
> I could say the same thing about JSON dumps then and most itertools
> functions. The proposed functionality is in line with existing functionality
> and extends it to the case of nested data structures.
>
JSON itself is standardized, heavily
On Thu, Jul 22, 2021 at 5:22 AM Sven Voigt wrote:
>
> Thank you so much for all of your responses. I am not aware of the procedure
> for suggesting ideas but building a PyPI package with documentation and then
> sharing here seems like a good way to build this out (which I will get
> started on
On Wed, Jul 28, 2021 at 3:56 PM Yua wrote:
>
> Thank you for bringing that to my attention!
>
> I think maybe can the interpreter decide whether __class__ etc. should be
> added to the environment with regard to how the function is called?
>
> The interpreter does not provide __class__ etc. for p
On Thu, Jul 29, 2021 at 9:07 AM wrote:
>
> [Migrating the discussion from https://bugs.python.org/issue44768.]
>
> PEP 20 says:
>
> > There should be one-- and preferably only one --obvious way to do it.
>
> There are two ways to create a simple named type to store data:
> collections.namedtuple
On Thu, Jul 29, 2021 at 9:28 AM Paul Bryan wrote:
>
> I'm with you; since dataclasses were introduced, namedtuple has not see any
> use from me, though none of my uses have demanded ultra-high efficiency
> either.
>
> I wonder how many users are currently relying on namedtuple __getitem__
> sem
On Thu, Jul 29, 2021 at 9:37 AM wrote:
>
> I was writing some code the other day, and it needed a quick-and-dirty data
> structure definition for a set of related variables. I looked back at other
> code to try be consistent, and found that I used dataclasses in some parts
> and namedtuples in
On Thu, Jul 29, 2021 at 10:00 AM wrote:
>
> I'm with you on the backwards-compatibility front. Changing Python fast and
> for no particular reason incurs a big cost. Is the reason good enough to
> justify removing a chunk of the interface? Good question.
>
Answer: Almost never. Case in point:
On Thu, Jul 29, 2021 at 9:19 PM Joren Hammudoglu wrote:
>
> What about creating a dataclasses.datatuple decorator, that replaces
> typing.NamedTuple, and offers the same (or restricted) interface as regular
> dataclasses? This would make the distinction explicit between a mutable,
> object-like
On Fri, Jul 30, 2021 at 7:11 AM Leonardo Freua
wrote:
>
> >>> First line of the body vs line before the declaration doesn't feel
> >>> like it makes much difference to me.
>
> Usually, decorators or annotations are placed near the method signature, that
> is, at the beginning where any reading be
On Fri, Aug 6, 2021 at 5:31 PM wrote:
>
> Before the introduction of bool and also in other languages, `not not x`
> was/is used to convert to True (1) and False (0). However, the old way is
> still much faster than bool(x) or even operator.truth(x).
> Test:
> > py -3.10 -m timeit -s "objects =
On Fri, Aug 6, 2021 at 9:59 PM Steven D'Aprano wrote:
> > def fib(0):
> > return 0
> >
> > def fib(1):
> > return 1
> >
> > def fib(n):
> > return fib(n-1) + fib(n-2)
>
> I think that there is something rather disturbing about writing a
> function definition with a constant literal as
On Mon, Aug 9, 2021 at 1:42 PM wrote:
>
> This is a proposal to change the behaviour of the startswith() and
> endswith() methods for str, bytes and bytearray objects, making them
> return the matched value instead of the True boolean.
Unfortunately this would break backward compatibility, since
On Mon, Aug 9, 2021 at 10:32 PM Samuel Freilich wrote:
>
> > that can be used (eg) for indexing
>
> Even without it being used in as complicated a way as that it's still not
> backward compatible because of the trivial case, as foo.endswith("") is True.
>
I was talking specifically about the ori
On Tue, Aug 10, 2021 at 12:03 AM Simão Afonso
wrote:
>
> On 2021-08-09 23:57:42, Chris Angelico wrote:
> > On Mon, Aug 9, 2021 at 10:32 PM Samuel Freilich
> > wrote:
> > > Even without it being used in as complicated a way as that it's still not
> > > b
On Tue, Aug 10, 2021 at 12:08 AM wrote:
>
> Two possibilities:
>
> 1) the perfectly backward compatible, retrun False
> 2) the more pythonic, return the empty value of the object (i.e. "" for str)
Please quote the person you're responding to, for context. Were you
replying to Serhiy?
ChrisA
On Fri, Aug 13, 2021 at 12:00 AM Ricky Teachey wrote:
>
> On Thu, Aug 12, 2021 at 9:02 AM Calvin Spealman wrote:
>>
>> An alternative suggestion, which works today (... is a valid object called
>> Ellipsis):
>>
>>Foobar.search(
>> attr1="foo",
>> attr2=[10, ...],
>> a
On Wed, Aug 18, 2021 at 10:37 PM Joao S. O. Bueno wrote:
>
> So,
> It is out of scope of Pythonmultiprocessing, and, as I perceive it, from
> the stdlib as a whole to be able to allocate specific cores for each
> subprocess -
> that is automatically done by the O.S. (and of course, the O.S. havin
On Thu, Aug 19, 2021 at 12:52 AM Marc-Andre Lemburg wrote:
>
> On 18.08.2021 15:58, Chris Angelico wrote:
> > On Wed, Aug 18, 2021 at 10:37 PM Joao S. O. Bueno
> > wrote:
> >>
> >> So,
> >> It is out of scope of Pythonmultiprocessing, and, as I perce
On Thu, Aug 19, 2021 at 11:27 PM Matsuoka Takuo wrote:
>
> Dear Steve,
>
> Thank you for your detailed explanation.
>
> > > (i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this
> > > time). It would at least be consistent if we got SyntaxError in
> > > both cases (namely, the syn
On Fri, Aug 20, 2021 at 5:22 PM wrote:
> I simply tried to understand how processes transfering data between
> each other. I know they pickle. But how exactly? Which pickle protocol
> they use by default? Do they decide the protocol depending on the
> type/kind/structure of data? Do they compress
On Sun, Aug 22, 2021 at 10:28 PM Tim Hoffmann via Python-ideas
wrote:
>
> Hi all,
>
> The Programming Recommendations section in PEP-8 states
>
> "For sequences, (strings, lists, tuples), use the fact that empty sequences
> are false:"
>
> # Correct:
> if not seq:
> if seq:
>
> # Wrong:
>
On Mon, Aug 23, 2021 at 11:56 PM Thomas Grainger wrote:
>
> here's another fun one "A False midnight": https://lwn.net/Articles/590299/
> https://bugs.python.org/issue13936#msg212771
>
That was a consequence of a time value being an integer, and thus zero
(midnight) was false. It was changed, bu
On Tue, Aug 24, 2021 at 3:27 PM Christopher Barker wrote:
>
> On Mon, Aug 23, 2021 at 6:54 AM Thomas Grainger wrote:
>>
>> here's another fun one "A False midnight": https://lwn.net/Articles/590299/
>> https://bugs.python.org/issue13936#msg212771
>
>
> This is a great example of the problem of t
On Tue, Aug 24, 2021 at 4:31 PM Steven D'Aprano wrote:
> ... midnight is not the annihilating element (zero).
Unless you're Cinderella, of course.
> We conventionally represent clock times as numbers, but they're more
> akin to ordinal data. They have an order, but you can't do arithmetic on
> t
On Fri, Aug 27, 2021 at 1:15 PM Finn Mason wrote:
>
> > Is this too magical?
> > result = run('cat file.txt') | run('sort) | run('grep hello',
> > capture_output=True, text=True).stdout
>
> Interesting idea, especially overloading the union/pipe operator (|). I like
> it a lot. It reminds me of
On Mon, Aug 30, 2021 at 1:33 PM Steven D'Aprano wrote:
> However we could add a function, totalorder, which can be used as a key
> function to force an order on NANs. The 2008 version of the IEEE-754
> standard recommends such a function:
>
> from some_module import totalorder
> sorted([4,
On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker wrote:
>
> On Mon, Aug 30, 2021 at 12:57 AM Ronald Oussoren
> wrote:
> > On 28 Aug 2021, at 07:14, Christopher Barker wrote:
>>>
>>>
>> Also +1 on a string flag, rather than an Enum.
>>
>> ou prefer strings for the options rather than an Enum?
On Tue, Aug 31, 2021 at 4:46 AM Nick Parlante wrote:
> The problem for Python is what I will call the "mandatory-is" rule in
> PEP8, which reads:
>
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
The question is whether you're testing
On Tue, Aug 31, 2021 at 5:34 AM Nick Parlante wrote:
>
> Hi Chris - thanks for the response,
>
> so here you say:
>
>> I disagree; experienced programmers should be using "is" where it's
>> correct.
>
>
> I'd like to unpack that a little - like what do you mean by "correct" there.
> My guess is "
On Tue, Aug 31, 2021 at 6:52 AM Nick Parlante wrote:
>
> I claimed that uses of "is" where it is needed for correctness
> are quite rare. Let me back that up with a little data here.
>
> Just as a random supply of Python code, let's look at
> the first four Python modules where the name starts
> w
On Tue, Aug 31, 2021 at 7:17 AM Nick Parlante wrote:
>>
>> On what basis do you ascertain whether "==" would work correctly?
>> Please explain.
>
>
> Hi Chris, I'm just glancing at the line of code, and doing a little thought
> experiment to see if it would get the same output if == was used inst
On Tue, Aug 31, 2021 at 7:22 AM Chris Angelico wrote:
>
> On Tue, Aug 31, 2021 at 7:17 AM Nick Parlante wrote:
> >>
> >> On what basis do you ascertain whether "==" would work correctly?
> >> Please explain.
> >
> >
> > Hi Chris, I&#x
On Tue, Aug 31, 2021 at 8:54 AM Nick Parlante wrote:
>
> I agree that, of course, it's possible to construct a class where == has this
> kind of weird behavior, like claiming that == to None is True.
>
> So are you saying that the reason PEP8 should forbid writing the line like
> this
>
> if
On Tue, Aug 31, 2021 at 10:25 AM Nick Parlante wrote:
>
> I understand that Python itself should work with classes with any sort of
> crazy semantics, and I appreciate your spelling it out. We could say that the
> bar for the Python implementation is the highest, since who knows what
> experime
On Tue, Aug 31, 2021 at 11:47 AM Steven D'Aprano wrote:
>
> On Tue, Aug 31, 2021 at 02:23:29AM +1000, Chris Angelico wrote:
> > On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker
> > wrote:
>
> > > I suppose they provide a real advantage for static typing, but
On Tue, Aug 31, 2021 at 9:51 PM Steven D'Aprano wrote:
> > I want to (in iPython) do:
> >
> > statistics.median?
> >
> > and see everything I need to know to use it
>
>
> Okay, so if the API is (say) this:
>
> def median(data, *, nans='ignore'):
> ...
>
>
> will iPython give you a list
On Wed, Sep 1, 2021 at 5:35 AM Nick Parlante wrote:
>>
>> > I want to get to a world that is, let's say, "== tolerant" ...
>>
>> Do you use floating point values in your course?
>
>
> You will be relieved to know that we have great fun showing them how == does
> not work for floating point numbe
On Wed, Sep 1, 2021 at 6:06 AM Nick Parlante wrote:
> Is there anyone other than me who would like to push for "== None tolerant"
> carve out for non-Python-implementation code?
What you're asking is: Is there anyone other than you who would prefer
for Python to officially encourage people to wr
On Wed, Sep 1, 2021 at 10:23 AM Steven D'Aprano wrote:
> What doesn't work, for some definition of "doesn't", is everything
> else about floats: addition, subtraction, multiplication, conversion
> from decimal, etc. But *equality* is one of the few operations that
> works exactly.
>
Really, the o
On Wed, Sep 1, 2021 at 5:19 PM Steven D'Aprano wrote:
> Outside of contrived counter-examples, we're not likely to come across
> anything trying to mimac None in the real world. But that's not really
> why we use `is`, or at least, it's not the only reason. There are a
> bunch of reasons, none of
On Wed, Sep 1, 2021 at 6:55 PM Marc-Andre Lemburg wrote:
> BTW: In SQL you have to use "field IS NULL", "field = NULL" returns
> NULL, so you're not any smarter than before :-)
That's because NULL is kinda like None, kinda like NaN, kinda like "we
don't have any data here", and kinda like "we do
On Wed, Sep 1, 2021 at 6:58 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Sep 01, 2021 at 05:27:40PM +1000, Steven D'Aprano wrote:
> > Maybe I'm missing something, but I don't think that there is anyway to
> > remove a warning from the warnings filter list so that it will be shown
> > again.
>
On Thu, Sep 2, 2021 at 5:56 PM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
> > On Thu, Sep 02, 2021 at 04:04:40PM +0900, Stephen J. Turnbull wrote:
> >
> > > You may not need to teach them about singletons, though.
> >
> > It's hard to teach why `is` works with None,
>
> For defini
On Thu, Sep 2, 2021 at 7:36 PM Peter Otten <__pete...@web.de> wrote:
>
> On 02/09/2021 04:32, Steven D'Aprano wrote:
> > On Wed, Sep 01, 2021 at 03:40:37PM +0200, Peter Otten wrote:
> >
> >> Instead of removing it you might add a filter to get a similar effect:
> >
> > [...]
> >
> > warnings.fi
On Fri, Sep 3, 2021 at 12:45 AM Peter Otten <__pete...@web.de> wrote:
>
> On 02/09/2021 11:41, Chris Angelico wrote:
> > On Thu, Sep 2, 2021 at 7:36 PM Peter Otten <__pete...@web.de> wrote:
> >>
> >> On 02/09/2021 04:32, Steven D'Aprano wrote:
> &
On Fri, Sep 3, 2021 at 3:24 PM Steven D'Aprano wrote:
>
> On Thu, Sep 02, 2021 at 04:54:45PM +0900, Stephen J. Turnbull wrote:
> > Steven D'Aprano writes:
> > > On Thu, Sep 02, 2021 at 04:04:40PM +0900, Stephen J. Turnbull wrote:
> > >
> > > > You may not need to teach them about singletons, th
201 - 300 of 2716 matches
Mail list logo
