On Thu, Dec 17, 2020 at 10:47 AM Greg Ewing wrote:
> A feature of Prothon was that a.b() and t = a.b; t() would do
> quite different things (one would pass a self argument and the
> other wouldn't).
>
> I considered that a bad thing. I *like* the fact that in Python
> I can use a.b to get a bound
On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky wrote:
> This is not some completely new restriction. For example, following
> already doesn't work in Python:
>
> class A:
> pass
>
> o = A()
> o.__add__ = lambda self, x: print("me called")
>
> o + A() # lambda above is never called
>
But the
On Mon, Dec 21, 2020 at 7:00 PM Paul Bryan wrote:
>
> I know this has come up in the past.
>
> Could the consensus have changed regarding bool's inheritance from int?
>
> This is not intuitive (to me), and recently bit me as a bug:
>
> Python 3.9.1 (default, Dec 13 2020, 11:55:53)
>
> [GCC 10.2.0]
On Mon, Dec 21, 2020 at 7:15 PM Paul Bryan wrote:
>
> Hmm, I see ints, floats and decimal.Decimal all produce the same hashes for
> integer values, so they also suffer the same fate in sets and dicts.
>
Yes, because they compare equal. (The hash is secondary to that.)
Since 1 == 1.0, they must b
On Tue, Dec 22, 2020 at 5:20 AM David Mertz wrote:
>
> On Mon, Dec 21, 2020 at 5:56 PM Paul Bryan wrote:
>>
>> I'm interested in knowing when (id(x), x) would be preferable over (type(x),
>> x).
>
>
> Something along these lines:
>
> >>> class Point:
> ... def __init__(self, x, y):
> ...
On Tue, Dec 22, 2020 at 5:59 AM David Mertz wrote:
>
> On Mon, Dec 21, 2020 at 6:32 PM Chris Angelico wrote:
>>
>> But the real question is: Why do points compare equal based on their
>> locations, if you need them to be independently stored in a set?
>> Logical
On Tue, Dec 22, 2020 at 11:52 AM Christopher Barker wrote:
>
> On Mon, Dec 21, 2020 at 3:37 PM Greg Ewing
> wrote:
>>
>> > However, that ship has sailed. I think it would have been minimally
>> > disruptive when True and False were first introduced,
>>
>> It would have been just as disruptive ba
On Wed, Dec 23, 2020 at 9:15 AM Steven D'Aprano wrote:
>
> On Mon, Dec 21, 2020 at 08:22:35AM +1100, Cameron Simpson wrote:
> > >is it so bad to use a subprocess?
> >
> > Yes. It is _really slow_, depends on external reaources which might not
> > be there, and subprocess brings other burdens too.
On Fri, Dec 25, 2020 at 9:30 AM Steven D'Aprano wrote:
> Perhaps a "sync on close" keyword argument to open? At least then it is
> always available and easily discoverable.
+1 (though this is really just bikeshedding)
> > 3. There are many ways to do this, and I think several of them could
> > b
On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing wrote:
>
> On 27/12/20 10:15 am, Christopher Barker wrote:
> > It does seem like ** could be usable with any iterable that returns
> > pairs of objects. However the trick is that when you iterate a dict, you
> > get the keys, not the items, which makes m
On Sun, Dec 27, 2020 at 1:15 PM Brendan Barnwell wrote:
>
> On 2020-12-26 18:03, Chris Angelico wrote:
> > On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing
> > wrote:
> >>
> >> On 27/12/20 10:15 am, Christopher Barker wrote:
> >> > It does seem like *
On Sun, Dec 27, 2020 at 1:25 PM Steven D'Aprano wrote:
> But the ctrl-L trick has no discoverability. It took me close to twenty
> years of using Linux before I discovered it, and I still don't remember
> to use it when I need it.
>
> Beginners and casual users aren't going to know ctrl-L, or stum
On Sun, Dec 27, 2020 at 1:45 PM Greg Ewing wrote:
>
> On 27/12/20 3:03 pm, Chris Angelico wrote:
> > But that would mean that a lot of iterables would look like mappings
> > when they're not.
>
> In the context of ** you're expecting a mapping, not a sequence.
&g
On Sun, Dec 27, 2020 at 4:30 PM Brendan Barnwell wrote:
> That said. . . I'm starting to wonder why not just create a new dunder
> called __items__ and have dict alias that to .items(). Then the
> **-unpacking protocol could use that and everything would be fine, right?
>
+0.95.
If we c
On Sun, Dec 27, 2020 at 4:26 PM Steven D'Aprano wrote:
>
> On Sun, Dec 27, 2020 at 02:00:00PM +1100, Chris Angelico wrote:
>
> > This is actually the exact part that I think should *not* happen, for
> > several reasons:
> >
> > 1) Stuff that exists interactiv
On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno wrote:
>
> I agree - the three builtin methods are almost the same (not sure if
> there is any difference at all),
Yes - they all check if the string matches a particular set of characters.
> while there is no trivial way to check for a valid
> fl
On Mon, Dec 28, 2020 at 9:55 AM Joao S. O. Bueno wrote:
> On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote:
> Sorry, I thought my message conveyed that I know "float" exists, and
> try/except is the current usable pattern (it is in the original posting
> anyway)
An
On Mon, Dec 28, 2020 at 7:45 PM Anton Abrosimov wrote:
>
> Steven D'Aprano wrote:
> > Why do you want something that isn't a mapping to be usable with mapping
> > unpacking?
>
> I think mapping is not `abc.Mapping` class only.
>
> What about:
> `Iterator[Tuple[str, int]]`
>
> ```
> @dataclass
> cl
On Wed, Dec 30, 2020 at 8:49 AM Brendan Barnwell wrote:
> To my mind, every time a change is made to Python behavior there must
> be a corresponding change to the main documentation describing the
> change. I would go so far as to say that the lack of such documentation
> updates should b
On Wed, Dec 30, 2020 at 9:57 AM Mike Miller wrote:
> Also, I'd argue the likelihood of a newbie clearing important work... is not
> very high.
>
Disputed on the basis of having seen it all too often :)
ChrisA
___
Python-ideas mailing list -- python-id
On Thu, Dec 31, 2020 at 3:13 PM Brendan Barnwell wrote:
>
> On 2020-12-29 15:01, Christopher Barker wrote:
> > along with a COMPLETE list of
> > the language features that make use of that protocol.
> >
> >
> > That is pretty much impossible -- that's kind of the point of a protocol
> > --
On Sat, Jan 2, 2021 at 7:56 AM Jonathan Fine wrote:
>
> Bravo, Jeff. I couldn't have chosen a better example.
>
> However, I'd expect large ints to be stored in two parts. A (class, pointer)
> pair which has fixed size. And memory referenced by the pointer, large enough
> to store the value of t
On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky wrote:
>
> Hello,
>
> There're tons of projects which introduce alternative braces
> (i.e. C-like) syntax for Python. Most of them are however not properly
> documented, and definitely not spec'ed for what they do.
>
> I wonder, does anyone here remem
On Tue, Jan 5, 2021 at 1:42 AM Abdur-Rahmaan Janhangeer
wrote:
>
> Greetings list,
>
> put simply,
>
> be able to use
>
> $ python -m venv venv_name activate
>
> To activate an env instead of having each platform have a way of
> handling it
>
Unfortunately, that wouldn't work. Activating a virtua
On Tue, Jan 5, 2021 at 1:52 AM Calvin Spealman wrote:
>
>
>
> On Mon, Jan 4, 2021 at 9:47 AM Chris Angelico wrote:
>>
>> On Tue, Jan 5, 2021 at 1:42 AM Abdur-Rahmaan Janhangeer
>> wrote:
>> >
>> > Greetings list,
>> >
>> &g
On Tue, Jan 5, 2021 at 2:29 AM Abdur-Rahmaan Janhangeer
wrote:
>
> Unfortunately, that wouldn't work. Activating a virtual environment
> means setting some env vars in the current shell, and Python is
> fundamentally unable to do that - it can only be done within the shell
> itself (by sourcing a
On Tue, Jan 5, 2021 at 2:37 AM Abdur-Rahmaan Janhangeer
wrote:
>
> You just execute the appropriate shell commands via Python
Try it. It won't work. See previous posts.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send
On Tue, Jan 5, 2021 at 9:05 AM Steven D'Aprano wrote:
>
> On Mon, Jan 04, 2021 at 01:38:23PM +0300, Paul Sokolovsky wrote:
> > Hello,
> >
> > There're tons of projects which introduce alternative braces
> > (i.e. C-like) syntax for Python.
>
> Got any examples of these projects? Preferably ones th
On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky wrote:
> And you seem to have 2nd level miss about this miss. I'm not the 1st
> asking about braces in Python, hundreds of people embraced braces
> (sorry for the pun) in Python for decades (references are in other
> messages of this thread). Apparent
On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky wrote:
> There were good reasons to not have string interpolation in the core
> language for decades then - KABOOM - there's string interpolation. You
> see a pattern yet? No? Oh, let's just keep watching.
Do you have evidence from the language itsel
On Wed, Jan 6, 2021 at 12:01 AM Paul Sokolovsky wrote:
> Anyway, this went offtopic wrt to the original subject.
> [chomp loads of drivel]
Yep, nothing more in this thread. Time to let it die a quiet death.
ChrisA
___
Python-ideas mailing list -- pytho
On Wed, Jan 6, 2021 at 9:17 AM lasizoillo wrote:
>
> Sorry, but if I'm understanting the point is to make one-liners. For example,
> if I want to do something like:
>
> $ env | grep "^XDG"
>
> In one python one liner like
>
> $ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value
On Wed, Jan 6, 2021 at 9:27 PM Steven D'Aprano wrote:
> I'm glad that things like Perl one-liners, obfuscated C, and
> sewerage treatment works exist...
:)
> Multi-statment anonymous functions are, in my opinion, overrated, and a
> (slight) code smell. If your lambda is so complex it requires mo
On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky wrote:
> In that regard, as of 3.9, CPython, has absolutely atrocious REPL
> support for its own syntax. It's just barely possible at all to type
> multi-line statement, but doing that as painful as hell, and after
> typing, editing is not possible.
>
On Sat, Jan 9, 2021 at 10:21 AM Steven D'Aprano wrote:
> Not every trivial combination of functions needs to be given a built-in
> or standard library solution. Especially not if doing so will break
> backwards compatibility.
>
> "I had three numbers in a tuple, and wanted half of twice the first
On Sun, Jan 10, 2021 at 12:29 AM Oscar Benjamin
wrote:
> I haven't ever wanted to reverse a chain but I have wanted to be able
> to reverse an enumerate many times:
>
> >>> reversed(enumerate([1, 2, 3]))
> ...
> TypeError
>
> The alternative zip(range(len(obj)-1, -1, -1), reversed(obj)
On Sun, Jan 10, 2021 at 4:51 AM Stephen J. Turnbull
wrote:
>
> Joseph Martinot-Lagarde writes:
>
> > One remark about this : .tar.gz files are the exception rather than
> > the rule, and AFAIK maybe the only one ?
>
> Not really. stem.ext -> stem.ext.zzz where zzz is a compression
> extension i
On Mon, Jan 11, 2021 at 4:42 AM Alex Prengère wrote:
>
> Hello,
> Today I had a quite simple need, I am unsure about the best way to do it, and
> saw a possible improvement for the timeit module.
>
> I have about 30 Python scripts and I want to measure precisely their
> execution times, without
On Mon, Jan 11, 2021 at 6:06 AM Paul Moore wrote:
>
> On 2021-01-10 at 18:38:12 +0100,
> Alex Prengère wrote:
> > 3. Use timeit. The scripts have no side effects so repeating their
> > execution the way timeit does, works for me. The only issue is that,
> > as far as I know, timeit only allows st
On Thu, Jan 14, 2021 at 10:07 PM Paul Sokolovsky wrote:
> The question then: what are the best practices in *declarative* syntax
> to achieve the same effect in Python? (but of course, unlike Ruby,
> there should be explicit syntactic marker that we augment existing
> class, not redefine it).
Eas
On Tue, Jan 19, 2021 at 8:58 AM Random832 wrote:
>
> On Tue, Jan 5, 2021, at 17:17, lasizoillo wrote:
> > Sorry, but if I'm understanting the point is to make one-liners. For
> > example, if I want to do something like:
> >
> > $ env | grep "^XDG"
> >
> > In one python one liner like
> >
> > $ pyt
On Fri, Jan 22, 2021 at 5:21 AM Neil Girdhar wrote:
>
> I've seen this proposed here before. The general idea is that some iterator
> transformations (like enumerate) should return sequences when they're applied
> to sequences. I think it's good idea, but it adds complexity and work, which
>
On Fri, Jan 22, 2021 at 5:44 AM Neil Girdhar wrote:
>
> On Thu, Jan 21, 2021 at 1:26 PM Chris Angelico wrote:
> >
> > On Fri, Jan 22, 2021 at 5:21 AM Neil Girdhar wrote:
> > >
> > > I've seen this proposed here before. The general idea is that s
On Fri, Jan 22, 2021 at 8:31 AM Neil Girdhar wrote:
> It's possible for reversed(enumerate(...)) to just work if enumerate
> of a sequence were to return a sequence view. Then you would also get
> all the other sequence operations for free like enumerate(...)[23:27],
> len(enumerate(...)), etc.
On Fri, Jan 22, 2021 at 11:10 AM Random832 wrote:
>
> On Thu, Jan 21, 2021, at 18:48, Chris Angelico wrote:
> > Note that slicing is NOT easy. The proposed semantics for a reversed
> > enumeration would make slicing extremely odd.
>
> What proposed semantics? You were t
On Fri, Jan 22, 2021 at 11:48 AM Neil Girdhar wrote:
> If enumerate(some_sequence) returns a sequence view, iterating over
> that sequence view does not advance it—just like how DictViews are not
> altered by iteration. Same thing if reversed(some_sequence) returns a
> sequence view.
Then that's
On Sat, Jan 23, 2021 at 12:37 PM Inada Naoki wrote:
> ## 1. Add `io.open_text()`, builtin `open_text()`, and
> `pathlib.Path.open_text()`.
>
> All functions are same to `io.open()` or `Path.open()`, except:
>
> * Default encoding is "utf-8".
> * "b" is not allowed in the mode option.
I *really* d
On Sat, Jan 23, 2021 at 9:04 PM Inada Naoki wrote:
>
> On Sat, Jan 23, 2021 at 10:47 AM Chris Angelico wrote:
> >
> >
> > Highly dubious. I'd rather focus on just moving to UTF-8 as the
> > default, rather than bringing in a new function - especially with such
On Sat, Jan 23, 2021 at 11:34 PM Stephen J. Turnbull
wrote:
> > I'd rather focus on just moving to UTF-8 as the default, rather
> > than bringing in a new function - especially with such a confusing
> > name.
>
> I expect there are several bodies of users who will experience that as
> quite obn
On Sun, Jan 24, 2021 at 2:31 AM Barry Scott wrote:
> I think that you are going to create a bug magnet if you attempt to auto
> detect the encoding.
>
> First problem I see is that the file may be a pipe and then you will block
> until you have enough data to do the auto detect.
>
> Second problem
On Sun, Jan 24, 2021 at 2:46 PM Matt Wozniski wrote:
> 2. At the same time as the deprecation is announced, introduce a new
> __future__ import named "utf8_open" or something like that, to opt into the
> future behavior of `open` defaulting to utf-8-sig or utf-8 when opening a
> file in text mo
On Sun, Jan 24, 2021 at 9:13 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > Can anyone give an example of a current in-use system encoding that
> > would have [ASCII bytes in non-ASCII text]?
>
> Shift JIS, Big5. (Both can have bytes < 128 insi
On Mon, Jan 25, 2021 at 12:33 AM Steven D'Aprano wrote:
>
> On Sat, Jan 23, 2021 at 03:24:12PM +, Barry Scott wrote:
>
> > I think that you are going to create a bug magnet if you attempt to auto
> > detect the encoding.
> >
> > First problem I see is that the file may be a pipe and then you w
On Mon, Jan 25, 2021 at 3:55 AM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > Right, but as long as there's only one system encoding, that's not
> > our problem. If you're on a Greek system and you want to decode
> > ISO-8859-9 text, you
On Fri, Feb 5, 2021 at 10:17 AM Ben Rudiak-Gould wrote:
> 'L' could be argued to be unnecessary if there's a simple way to achieve the
> same thing with the encoding parameter (which currently there isn't).
>
I'd rather work that one out the opposite way, having
encoding="locale" (or encoding="s
On Fri, Feb 5, 2021 at 10:46 AM Ben Rudiak-Gould wrote:
>
>
>
> On Thu, Feb 4, 2021 at 3:29 PM Chris Angelico wrote:
>>
>> With "t", it takes/gives Unicode objects, but with "b" it uses bytes.
>
>
> Sure, in Python 3, but not in Python 2, or
On Sat, Feb 6, 2021 at 12:51 AM Matt del Valle wrote:
>
> Unfortunately, [lazy importers are] fundamentally incapable of dealing with
> 'from x import y' syntax, because this is always loaded eagerly by the Python
> interpreter.
>
This is because it's fundamentally hard.
> With the increasingl
On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky wrote:
> And looking back now, that seems like intentionally added accidental
> gap in the language (https://en.wikipedia.org/wiki/Accidental_gap).
> Similar to artificially limiting decorator syntax, which was already
> un-limited. But seems, there'r
On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:
>
> While we're on the subject of assignment expression limitations, I've
> occasionally wanted to write something like
>
> try:
> return a_dict[key]
> except KeyError:
> return (a_dict[key] := expression to construct value)
That's what the
On Sat, Feb 6, 2021 at 8:54 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Sat, 6 Feb 2021 17:26:00 +1100
> Chris Angelico wrote:
>
> > On Sat, Feb 6, 2021 at 5:21 PM Random832
> > wrote:
> > >
> > > While we're on the subject of assignment expr
t;
> > > try:
> > > return a_dict[key]
> > > except KeyError:
> > > return (a_dict[key] := expression to construct value)
>
> On Sat, Feb 6, 2021, at 01:26, Chris Angelico wrote:
> >
> > That's what the __missing__ method is
On Mon, Feb 8, 2021 at 6:04 PM David Mertz wrote:
>
> There's a reason that never in the last 3800 years since Proto-Sinaitic was
> the first human script to approximately represent phonemes, has text EVER
> been set at more than 80 characters as a widespread convention.
>
What did they use as
On Tue, Feb 9, 2021 at 6:39 PM Hans Ginzel wrote:
>
> Please, consider class(obj) to return obj.__class__
> consistenly with dir(), vars(), repr(), str(),…
>
> >>> class c: pass
> >>> o = c()
> >>> o.__class__
>
> >>> class(o)
>File "", line 1
> class(o)
> ^
> SyntaxError: inva
On Fri, Feb 12, 2021 at 1:01 AM Henry Harutyunyan
wrote:
> this is fine as long as you need to use that filter for once. But if you want
> to reuse it you either need to create the iterator every time specifying the
> filter function, or save the function in a var and create the filter with
> t
On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky wrote:
> ... And on the 2nd thought, that won't work. The reason it works in JS
> is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" means
> "compare a tuple for greater-or-equal".
Should be safe actually - "=>" is not a valid comparison
On Fri, Feb 12, 2021 at 7:57 PM Brendan Barnwell wrote:
>
> On 2021-02-11 03:24, J. Pic wrote:
> > Hi all,
> >
> > Lambdas can be defined as such:
> >
> > w = lambda: [12]
> > x = lambda y: len(y)
> >
> > I'd like to propose the following:
> >
> > w = (): [12]
> > x = (y): len(y)
> >
> > Or even a
On Sun, Feb 14, 2021 at 9:33 AM Christopher Barker wrote:
>
> On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell
> wrote:
>>
>>
>> The only thing that would be better than lambda is a less confusing
>> keyword.
>
>
> Is this really what this is all about? removing that word? I do think tha
On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano wrote:
> We should not choose the more confusing, error-prone solution out of
> fear of being different. Python is already different from Javascript in
> every regard:
>
Is it really?
> - the basic execution model is different;
Don't know what you
On Sun, Feb 14, 2021 at 11:26 PM Abdulla Al Kathiri
wrote:
>
> My idea was that in the case of partial matching or full matching without
> passing the guard, the binding names has some sort of self destruction and
> return to the previous state. Using different variable names would resolve
> th
On Mon, Feb 15, 2021 at 5:28 PM Steven D'Aprano wrote:
> In the first case, => will forever be fighting against the much stronger
> memory trace of >= (I think we can agree that comparisons will be more
> common than anonymous functions). People's muscle-memory will type >=
> when they want the ar
On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
> Still think that "object()" should be writable since this seems like an
> arbitrary restriction (+SimpleNamespace is no builtin and at least I
> would use object() for fast PoCs or dirty hackery). But I guess there's
> been discussion around t
On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote:
>
> From other thread:
>
> On Wed, Feb 17, 2021 at 5:19 AM Chris Angelico wrote:
>>
>> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
>> > Still think that "object()" should be writa
On Thu, Feb 18, 2021 at 8:53 AM Brendan Barnwell wrote:
>
> On 2021-02-17 11:21, Chris Angelico wrote:
> > Okay. Let's start bikeshedding. If SimpleNamespace were to become a
> > builtin, what should its name be? It needs to be short (obviously),
> > but not TOO short
On Thu, Feb 18, 2021 at 1:00 PM Christopher Barker wrote:
>
> > On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
>>
>> >> Still think that "object()" should be writable since this seems like an
>> >> arbitrary restriction
>
> ...
>>
>> But I guess there's been discussion around this already.
On Thu, Feb 18, 2021 at 1:59 PM Ben Rudiak-Gould wrote:
>
> On Wed, Feb 17, 2021 at 6:12 PM Chris Angelico wrote:
>>
>> But if object() could get arbitrary attributes, then __slots__ wouldn't work.
>
>
> It seems to me that all you'd have to do is add a li
On Thu, Feb 18, 2021 at 5:25 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote:
>
> > > I would personally love for SimpleNamespace to get a shorter name
> > > and become a built-in.
> >
On Thu, Feb 18, 2021 at 9:57 PM Steven D'Aprano wrote:
>
> On Thu, Feb 18, 2021 at 06:21:19AM +1100, Chris Angelico wrote:
>
> > > I would personally love for SimpleNamespace to get a shorter name and
> > > become a built-in.
> > >
> >
> > Ok
On Mon, Feb 22, 2021 at 1:11 PM Brendan Barnwell wrote:
>
> On 2021-02-17 11:21, Chris Angelico wrote:
> > Okay. Let's start bikeshedding. If SimpleNamespace were to become a
> > builtin, what should its name be? It needs to be short (obviously),
> > but not TOO short
On Mon, Feb 22, 2021 at 6:08 PM Paul Sokolovsky wrote:
> One explanation why SimpleNamespace is not in "collections" is because
> ... it's not a collection. One of the basic traits of any collection is
> that it "contains" things, and thus it can be directly iterated over to
> traverse those conte
On Mon, Feb 22, 2021 at 6:27 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Mon, 22 Feb 2021 15:51:37 +1100
> Chris Angelico wrote:
>
> []
>
> > In my mind, the current front-runners are:
> >
> > * namespace
>
> > * ns
> > * thing
> >
On Tue, Feb 23, 2021 at 10:10 AM Stestagg wrote:
> So Python has identified that a function 'do_thing' is being called
> incorrectly, but /where/ is do_thing defined? This problem gets much harder
> if there are multiple definitions of 'do_thing' in the codebase, as alluded
> to in the origin
On Tue, Feb 23, 2021 at 12:14 PM Soni L. wrote:
>
> Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the
> same as not bool. Hopefully nobody actually relies on this but
> nevertheless, it would be a backwards-incompatible change so the whole
> deprecation warnings and whatnot w
On Tue, Feb 23, 2021 at 5:33 PM Paul Sokolovsky wrote:
> Because that's the right analogy of what happens with a function - in
> the function "prolog", there's a series of assignments:
> "formal_paramX = actual_argX". Conceptually, those *are* in the
> function context (or you would not be able to
On Wed, Feb 24, 2021 at 4:13 AM Richard Damon wrote:
> As far as between % or .format(), I think the documentation is fairly
> clear that the % method is 'old' and if not 'formally' deprecated, is no
> longer considered the 'obvious' way to do it (even if some people will
> still do it that way fo
On Wed, Feb 24, 2021 at 4:59 AM Paul Sokolovsky wrote:
> Without getting to the root cause, there will be only workarounds of
> different level of ugliness. For example, any reasonable JIT would
> implement proper semantics - param checking *inside* functions (just
> like the C code does now).
Wh
On Thu, Feb 25, 2021 at 4:28 AM Barry Scott wrote:
>
>
>
> On 23 Feb 2021, at 22:10, Steven D'Aprano wrote:
>
> There are exactly 2**4 = 16 boolean operators of two variables. Python
> only supports two: `and` and `or`. Plus a single unary operator `not`
> (out of four possible unary operators).
On Thu, Feb 25, 2021 at 5:05 AM Richard Damon wrote:
>
> On 2/24/21 12:34 PM, Chris Angelico wrote:
> > On Thu, Feb 25, 2021 at 4:28 AM Barry Scott wrote:
> >>
> >>
> >> On 23 Feb 2021, at 22:10, Steven D'Aprano wrote:
> >>
> >>
On Tue, Mar 2, 2021 at 5:03 AM wrote:
>
> Currently, the only way to concatenate an integer to a bytes object is by
> converting the integer to bytes with a function call before concatenating.
> And there is no way to make a mutable bytes object without a function call.
>
> I propose an array-ty
On Thu, Mar 4, 2021 at 7:57 AM George Harding
wrote:
> I think it might be cleaner to also allow an __exclude_all__ variable which
> will exclude some members from being imported.
>
> If both were defined I would imagine __exclude_all__ being applied second.
You could implement that yourself:
_
On Thu, Mar 4, 2021 at 9:57 AM Brendan Barnwell wrote:
>
> On 2021-03-03 14:06, Chris Angelico wrote:
> > You could implement that yourself:
> >
> > __all__ = {n for n in globals() if not n.startswith("_")} - __exclude_all__
>
> Sort of. That wil
On Sat, Mar 6, 2021 at 9:47 AM Ethan Furman wrote:
>
> On 3/5/21 12:41 PM, Caleb Donovick wrote:
> >
> > > __all__ = (Class.__name__, func.__name__, ...)
> > >
> > > So I have to put it at the end of the module. I do this because if I
> > > change the class or function name and I forget to cha
On Tue, Mar 9, 2021 at 9:15 PM Ben Avrahami wrote:
> raw_value : str = input()
> # suppose we want to convert raw_value to an int, but leave it as an
> arbitrary falsish value if raw_value is an empty string, we can now do this
> in the following ways:
> # annotate value as a union (type hint is
On Fri, Mar 12, 2021 at 8:10 AM Matt del Valle wrote:
>
> I don't really have any knowledge of the Python interpreter's internals so
> I'm afraid any suggestions of mine on implementation details are going to be
> shots in the dark.
>
> That said, my intuition tells me that something similar to
On Fri, Mar 12, 2021 at 8:24 AM Paul Bryan wrote:
>
> Probably one of countless examples of performing lazy imports, for precisely
> the reason of preventing circular imports:
> https://github.com/fondat/fondat-core/blob/main/fondat/lazy.py
>
In the case of circular imports, at what point should
On Sat, Mar 13, 2021 at 3:28 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> For exmaple, if I have a multiline list like this:
>
> x = [
> 1,
> 2
> ]
>
> and add a new element to the end, then I end up with the diff including
> the 2 even though I didn't change the
On Sat, Mar 13, 2021 at 1:46 PM Peter Ludemann wrote:
> It's not clear to me what surprising behaviors there would be. Javascript
> seems to do OK with optional semicolons - presumably its algorithm is similar
> to what BCPL used. (Or perhaps the surprising behaviors are trivial compared
> to t
On Fri, Mar 19, 2021 at 10:46 AM Cameron Simpson wrote:
>
> I know that range(start,end,stride) will produce what I'd want from
> iter(slice(start,end,stride)), but wouldn't it be reasonable for a slice
> itself to be iterable?
>
> Yes, only one obvious way and all that, but inside eg __getitem__
), but wouldn't it be reasonable for a slice
> >> > itself to be iterable? [...]
>
> >On Thu, Mar 18, 2021 at 6:09 PM Chris Angelico
> >wrote:
> >> What if the start is positive and the end is negative? What values should
> >> i get?
>
> On 18Mar2021 1
On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould wrote:
>
> In the "Object Lifetime" section you say "registers should be cleared upon
> last reference". That isn't safe, since there can be hidden dependencies on
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
>
On Mon, Mar 22, 2021 at 3:14 PM Guido van Rossum wrote:
>
> On Sun, Mar 21, 2021 at 3:35 PM Chris Angelico wrote:
>>
>> On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould wrote:
>> >
>> > In the "Object Lifetime" section you say "registers shoul
1 - 100 of 2716 matches
Mail list logo
