On Tue, Oct 19, 2021 at 9:00 AM Cameron Simpson wrote:
> The problem with a "download()" method is that it is almost never what
> you need. There are too many ways to want to do it, and one almost
> _never_ wants to suck the download itself into memory as you do above
> with read() because
On Tue, Oct 19, 2021 at 3:34 AM Ricky Teachey wrote:
> insert(x).into.seq(s).at(i)
> insert(k, v).into.mapping(m)
>
> I would never use any of this in a serious application, but it's still fun.
Reminds me of some testing/assertion frameworks. I'm not a fan, but
some people like it.
On Mon, Oct 18, 2021 at 9:22 PM Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
As stated, it basically is but the cool thing about crazy ideas
is,
On Sun, Oct 17, 2021 at 8:26 PM Steven D'Aprano wrote:
> (I think the difference has to do with sending values into the
> generator, throwing and catching exceptions, but I can't think of a
> simple example where it would make a difference.)
Yeah mainly. And genexps don't usually do that. So it
On Sat, Oct 16, 2021 at 8:22 AM Jeremiah Paige wrote:
>
> Here is a pseudo-program showing where I would like to use this token in
> my own code if it existed. I think besides the cases where one is forced to
> always repeat the variable name as a string (namedtuple, NewType) this
> is an easy
On Fri, Oct 15, 2021 at 12:16 AM Steven D'Aprano wrote:
>
> On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> > On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> > wrote:
> > >
> > > Results are in (tested
> > > `next(iter(d)
On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
wrote:
>
> Results are in (tested
> `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> `next(reverse())` counterparts):
> `*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
> `+` / `-` implemented
On Thu, Oct 14, 2021 at 7:37 PM Jeremiah Vivian
wrote:
>
> So I implemented these functions as operators in a downloaded source of
> CPython... the differences are insane! (Sorry if this produces nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
> > >>>
On Thu, Oct 14, 2021 at 8:04 AM Oscar Benjamin
wrote:
>
> On Wed, 13 Oct 2021 at 18:30, Chris Angelico wrote:
> >
> > On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
> > wrote:
> > > Your suggestion is that this is a bug in map() which is a fair
> > >
On Thu, Oct 14, 2021 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-14 at 00:00:25 +0900,
> "Stephen J. Turnbull" wrote:
>
> > Chris Angelico writes:
> >
> > > +1, although it's debatable whether it should be remove suff
On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
wrote:
> Your suggestion is that this is a bug in map() which is a fair
> alternative view. Following through to its conclusion your suggestion
> is that every possible function like map, filter, and all the iterator
> implementations in itertools
On Wed, Oct 13, 2021 at 7:57 PM Marc-Andre Lemburg wrote:
>
> The idea to use "-" in the context of strings may have some
> merrit. Not as unary minus, but as sequence operation and
> shorthand for str.removesuffix(x):
>
> s = 'abc' + 'def' - 'ef' + 'gh'
>
> giving
>
> s == 'abcdgh'
>
> Removing
On Wed, Oct 13, 2021 at 11:21 AM MarylandBall Productions
wrote:
>
> I would think `~string` could be good for a shorthand way to convert a string
> to an integer, considering you’re “inverting” the string to another type,
> though a downside to this would be that explicit is always better than
On Wed, Oct 13, 2021 at 10:53 AM Jeremiah Vivian
wrote:
>
> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these implementations:
> > +string -
On Wed, Oct 13, 2021 at 10:02 AM Steven D'Aprano wrote:
>
> On Wed, Oct 13, 2021 at 09:22:09AM +1100, Chris Angelico wrote:
>
> > Mathematicians and programmers both extend
> > operators to new meanings, but only where it makes sense.
>
> In fairness, mathematician
On Wed, Oct 13, 2021 at 9:15 AM Jeremiah Vivian
wrote:
>
> Using the caret as a prefix unary operator would require changes in python
> grammar. For now, stick to implementing existing operators. But the rest of
> the ideas are good though.
>
You may need to get your sensors tuned up, as not
On Wed, Oct 13, 2021 at 2:39 AM Christopher Barker wrote:
>
> On Tue, Oct 12, 2021 at 4:51 AM Chris Angelico wrote:
>>
>> > Exactly: simple usage of next is often a bug. We need to be careful about
>> > this every time someone suggests that it's straight-for
On Tue, Oct 12, 2021 at 11:47 PM Steven D'Aprano wrote:
>
> Shouldn't your safe_map raise RuntimeError rather than ValueError?
> That's what PEP 479 does *wink*
>
> https://www.python.org/dev/peps/pep-0479/
>
If I'm explicitly choosing the exception to raise, ValueError seems
better, although
On Tue, Oct 12, 2021 at 11:27 PM Jeremiah Vivian
wrote:
>
> > -1. It's unnecessary optimization for an uncommon case, abuse of syntax
> Good point. But what else can the unary positive do? I'm just trying to add a
> use for it.
> > illogical - why should +"a" be the integer 97?
> Because
On Tue, Oct 12, 2021 at 10:41 PM Jeremiah Vivian
wrote:
>
> So `ord` is already a really fast function with (last check before this
> thread was posted) 166 nsec per loop. But I'm wondering... doing `ord(a)`
> produces this bytecode:
> > 2 4 LOAD_NAME1 (ord)
> >
On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
wrote:
>
>
> On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
>>
>> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
>> wrote:
>> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
>
On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
wrote:
> A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it gets
> caught in a generator but that PEP (which was rushed through very quickly
> IIRC)
On Mon, Oct 11, 2021 at 10:59 PM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 10/10/2021 13:31, Steven D'Aprano wrote:
> > On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote:
> >
> >> import sys
> >> if sys.version_info < (3, 6):
> >> # Yell at the user
> > Please, version checking
On Mon, Oct 11, 2021 at 12:17 AM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
> > On Sun, Oct 10, 2021 at 01:51:52AM +0900, Stephen J. Turnbull wrote:
> > > Christopher Barker writes:
> > >
> > > > But last time, one of the use cases was "get [an arbitrary] item
> > > > from a
On Sun, Oct 10, 2021 at 3:05 PM Finn Mason wrote:
>
> On Sat, Oct 9, 2021, 9:56 PM Steven D'Aprano wrote:
>>
>> [Snip...]
>
>
>> Newbies won't know first() lives in itertools, and those experienced
>> enough to know it is there probably won't bother to use it.
>
>
> A very good point.
>
> Let's
On Sat, Oct 9, 2021 at 10:02 AM Jeremiah Paige wrote:
>
> On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico wrote:
>>
>> On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige wrote:
>> > Bellow are some examples of where I believe the reflection token wou
On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige wrote:
> Bellow are some examples of where I believe the reflection token would be
> used if adopted.
>
>
> >>> Point = namedtuple(<<<, 'x, y, z')
> >>> Point
>
>
>
> >>> UUIDType = NewType(<<<, str)
> >>> UUIDType
> __main__.UUIDType
Not very
On Tue, Oct 5, 2021 at 9:50 AM Caleb Donovick wrote:
>
> > 2) Some OTHER exception occurs on the reevaluation. It's a chained
> > exception like any other.
>
> Except it's not a chained exception and displaying as such would be VERY
> confusing IMO.
> Granted we could easily strip the chained
On Tue, Oct 5, 2021 at 9:02 AM Caleb Donovick wrote:
>
> > I wonder, could this be simplified a bit, on the assumption that a
> > well-written assertion shouldn't have a problem with being executed
> > twice?
>
> While I agree as an engineering principle an assert should not have side
> effects
On Mon, Oct 4, 2021 at 2:02 AM Jonathan Crall wrote:
>
> @Marc-Andre
>
> One of the motivations of this proposal is to incentivize writing code in a
> local scope, rather than a global one. People in this thread have made the
> argument "Python is a scripting language, so it should do that".
On Sun, Oct 3, 2021 at 9:04 AM Abdulla Al Kathiri
wrote:
>
> Yeah empty parentheses for parameters-less function is the clear obvious way.
> Optional parenthesis for single parameter function is a wise choice. In fact,
> I read C# lambdas and they made really great design choices. I
On Sun, Oct 3, 2021 at 4:18 AM Paul Bryan wrote:
>
> Thanks for finding that.
>
> While I don't feel strongly one way or the other, I do think the discussion
> is worthwhile.
>
> As I understand, the arguments for:
> - let's get rid of boilerplate, that many (esp. beginners) may not understand
On Sun, Oct 3, 2021 at 1:55 AM Debashish Palit wrote:
>
> Ok it is a 3 way flag, but the code is not awkward. 'c' is just a name I
> chose - it does not mean anything.
>
> The check for a valid number can be used on a list of strings -
>
> [float(s) for s in lst if s.isfloat() is not None]
>
>
On Sat, Oct 2, 2021 at 3:15 PM Jonathan Crall wrote:
>
> That's effectively every module I write. I don't think that's uncommon or bad
> practice.
>
Interesting. Why is that?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To
On Sat, Oct 2, 2021 at 2:01 PM Jonathan Crall wrote:
>
> @Steven D'Aprano Yes my original post is somewhat pithy and has some harsh
> words for decorators. Like many I have some opinions about code. Don't take
> them too seriously if they disagree with your experience, but I do hold my
>
On Sat, Oct 2, 2021 at 1:00 PM Nick Parlante wrote:
>
> I have also often wondered if there could be something more turn-key for that
> bit at the bottom.
>
> Here is a suggestion I'll throw into the ring:
>
> sys.run_main()
>
> It goes at the bottom of the file, and basically just lets the
On Sat, Oct 2, 2021 at 12:19 PM Debashish Palit wrote:
>
> The method need not take care of every variation. Currently there is no
> method to check for a float in a string even without formatting. str.numeric
> or str.decimal don't work. str.isfloat would test unformatted strings for
> floats
On Fri, Oct 1, 2021 at 3:02 PM Steven D'Aprano wrote:
> We might take the point of view that StopIteration is reserved for use
> by iterators, and that the interpreter reserves the use to treat *any*
> use of StopIteration in any other context as undefined behaviour, and
> that we ought to be
On Fri, Oct 1, 2021 at 6:12 AM Soni L. wrote:
> > Congratulations, you showed me some extremely complicated code, and
> > then got miffed when I messed up something in trying to simplify it.
> > Well done, you successfully tripped me up in my attempt to make code
> > better.
>
> Fair enough, we
On Fri, Oct 1, 2021 at 1:10 AM Soni L. wrote:
>
>
>
> On 2021-09-30 11:23 a.m., Chris Angelico wrote:
> > > For example this: (real code)
> > >
> > > def get_property_values(self, prop):
> > > try:
> > > factory = s
On Fri, Oct 1, 2021 at 12:03 AM Soni L. wrote:
>
> > But what you're talking about doesn't have this clear distinction,
> > other than in *your own definitions*. You have deemed that, in some
> > areas, a certain exception should be turned into a RuntimeError; but
> > in other areas, it
On Thu, Sep 30, 2021 at 8:43 PM Soni L. wrote:
> You misnderstand exception hygiene. It isn't about "do the least stuff
> in try blocks", but about "don't shadow unrelated exceptions into your
> public API".
>
> For example, generators don't allow you to manually raise StopIteration
> anymore:
>
On Thu, Sep 30, 2021 at 4:19 PM Steven D'Aprano wrote:
>
> On Wed, Sep 29, 2021 at 02:09:03PM -0700, Guido van Rossum wrote:
> > Over in typing-sig we're considering a new syntax for callable *types*,
> > which would look like (int, int, str) -> float. A matching syntax for
> > lambda would use a
On Thu, Sep 30, 2021 at 11:03 AM Soni L. wrote:
>
> So uh, this is a hardly at all fleshed out idea, but one thing we really
> don't like about python is having to do stuff like this so as to not
> swallow exceptions:
>
> def a_potentially_recursive_function(some, args):
> """
> Does stuff
On Wed, Sep 29, 2021 at 10:56 PM Dominik Vilsmeier
wrote:
> members.sort(key=(?[1], ?[0]))
How do you know whether this is one function that returns a tuple, or
a tuple of two functions?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
On Wed, Sep 22, 2021 at 9:57 AM Andres Torres
wrote:
>
> Title is pretty self explanatory.
>
> Right the following causes an error:
> ```py
> >>> ipaddress.IPv4Address('localhost')
> Traceback (most recent call last):
> File "", line 1, in
> File "C:\ProgramData\Anaconda3\lib\ipaddress.py",
On Mon, Sep 20, 2021 at 9:48 PM Gustavo Carneiro wrote:
>
> Note that you can wrap any of those methods with an asyncio.wait_for().
>
> try:
>try:
>await asyncio.wait_for(lock.acquire(), 1.0)
>except asyncio.TimeoutError: # times out after 1 second
>print("deadlock!")
>
On Sun, Sep 19, 2021 at 1:44 PM Steven D'Aprano wrote:
>
> On Sat, Sep 18, 2021 at 03:50:00PM -0700, Christopher Barker wrote:
>
> > Folks are not surprised by:
> >
> > >> 2 * 3 == [2] * 3
> >
> > False
> >
> > Because 2 is not only a different type than [2] but because they are
> > different
On Thu, Sep 16, 2021 at 5:28 AM wrote:
>
> I would love to make the 'subcommands' functionality provided in argparse
> more user-friendly.
> I think I have a worthwhile feature request to share:
>
> * Be able to add multiple subcommands to an ArgumentParser, without needing
> to track the
On Wed, Sep 15, 2021 at 9:22 PM Steven D'Aprano wrote:
>
> On Wed, Sep 15, 2021 at 08:53:21PM +1000, Chris Angelico wrote:
>
> > Sometimes there is no valid path to something,
>
> I don't understand what you mean by that. If there is no valid path to
> something, wher
On Wed, Sep 15, 2021 at 8:41 PM Christian Heimes wrote:
>
> On 15/09/2021 11.56, Marc-Andre Lemburg wrote:
> > - Chris mentioned that library code should not be changing the
> > CWD. In an ideal world, I'd agree, but there are cases where
> > you don't have an option and you need to change
On Wed, Sep 15, 2021 at 9:36 AM Cameron Simpson wrote:
>
> On 15Sep2021 07:50, Chris Angelico wrote:
> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
> >> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> >> including command line code
On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote:
>
> On 14Sep2021 21:43, M.-A. Lemburg wrote:
> >- The context manager is not thread safe. There's no thread safe model
> > for the current work dir. OTOH, scripts usually don't use threads,
> > so not a big deal.
>
> This is the source of
On Wed, Sep 15, 2021 at 4:58 AM Tim Peters wrote:
> Or perhaps the `compress()` implementation could grow internal
> conditionals to use a different algorithm if the second argument is
> omitted. But that would be a major change to support something that's
> already easily done in more than one
On Wed, Sep 15, 2021 at 4:03 AM m...@dyatkovskiy.com
wrote:
>
> > The signature is wrong.
> Thanks for remark. Of course proper signature would be:
>
> def jin(a: Iterable[Optional[str]], sep=“ “):
> # …
>
> > Why do you (ab)use compress for that?
> Well, it seems that it is subjective. To
On Tue, Sep 14, 2021 at 11:58 PM wrote:
>
> Hi all,
>
> I was wondering on whether there is any interest in introducing a
> "plus-minus" operator:
>
> Conceptually very simple; instead of:
>
> upper, lower = a + b, a - b
>
> use instead:
>
> upper, lower = a +- b
>
> In recent
On Tue, Sep 14, 2021 at 11:30 PM wrote:
>
> I think I implemented __eq__ but not __hash__ and it broke the golden rule of
> x == y => x is y i,.e. hash(x) == hash(y)
>
Not sure what you're referring to there. The rule regarding hashes is
that if x == y, then hash(x) == hash(y). Identity doesn't
On Mon, Sep 13, 2021 at 1:37 AM Serhiy Storchaka wrote:
>
> 12.09.21 17:28, Guido van Rossum пише:
> > This is cool.
> >
> > AFAIK pytest does something like this. How does your implementation differ?
>
> What pytest does is awesome. I though about implementing it in the
> standard compiler since
On Sun, Sep 12, 2021 at 10:49 PM Ram Krishna wrote:
>
> I guess having subclass for implementation errors to distinguish will be very
> helpful, Typeerror has become very generic and finding solution is like
> searching a needle in haystack for the new developers.
>
> Eg- TypeError: ‘int’
On Fri, Sep 10, 2021 at 12:28 AM Randolf Scholz
wrote:
>
> Hey,
>
> I noticed that writing a class with a classmethod `__eq__`, it does not work
> as expected:
>
> ```python
> class ANY:
> @classmethod
> def __eq__(cls, other):
> return True
>
> assert ANY == 2 # succeeds
>
On Tue, Sep 7, 2021 at 1:36 AM Finn Mason wrote:
>
> Thank you for testing that. I dug through the change log, and found bpo-12022:
> https://bugs.python.org/issue12022
> It has been fixed in 3.11, but not mentioned in the What's New document.
> Should it be?
>
If it was indeed a side effect of
On Mon, Sep 6, 2021 at 9:37 AM Finn Mason wrote:
>
> Hello all,
>
> In Python 3.10 and 3.11, exception tracebacks are being greatly improved. I
> noticed that there's nothing related to a fairly common (in my personal
> experience) cryptic traceback relating to the `with` statement:
>
> >>>
On Sat, Sep 4, 2021 at 6:06 AM Kevin Mills wrote:
> If we don't cheat by comparing expressions to expression lists, the two are
> fairly analogous. `f(t)` means pass the tuple to the function, and `d[t]`
> means use the tuple as a key. `f(*t)` means break up the tuple and pass each
> element
On Fri, Sep 3, 2021 at 7:35 PM Steven D'Aprano wrote:
>
> On Fri, Sep 03, 2021 at 03:43:03PM +1000, Chris Angelico wrote:
>
> > Yes, although I'd love to have a good term for "there is only ever one
> > object of this type AND VALUE", rather than "there is o
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,
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:
> >&g
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:
> >
> > [...]
> >
> >
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
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 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
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 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
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
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
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
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 othe
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
>
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
>
>
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'm
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
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
>
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 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
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 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
>
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 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
>
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
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,
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 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 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
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
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.
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, ...],
>>
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 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
> > > backwa
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
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 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
701 - 800 of 2585 matches
Mail list logo
