That's what I did on my first day :D
Setting up my dev environment for the first time, the 'run this to make sure it
is set up' script was failing. After walking the debugger through several 'this
should not happen' oddities, the developer that was helping me eventually
figured out I was running
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.
nk this is a great idea but out of scope.
This work should focus on build dependencies to avoid scope creep
4. `python_runtime_dependencies`: I believe this information is already
captured in PEP-631: Dependency specification in pyproject.toml based on PEP
508 (https://www.python.org/dev/peps/pep-0631/)
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 *
one
3) Beginners already have to learn about importing (eg "from math
import sin") and this is just one more importable.
> So that's the easy part: just agree with me and import it in site.py,
> wherever it happens to come from. *wink*
This is python-ideas! We don't "
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
Hello- This is a draft of a future PEP regarding capturing wheel build
dependencies in pyproject.toml. I am looking for any critique or input prior to
creating a PR against the PEP repository, Thank you!
Previous discussion can be seen here:
*
https://mail.python.org/archives/list/python-ideas@
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 -- [email protected]
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
Is anyone interested on commenting on the work above? I'm still looking for
someone to act as a Sponsor for this PEP. Thank You!
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https:
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
eager sequence", so
the only thing we don't easily have is "please return a lazy
sequence", and that's possible with about four lines of custom class.
Note that slicing is NOT easy. The proposed semantics for a reversed
enumeration would make slicing extremely odd.
>
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 <[email protected]> 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
1 - 100 of 3030 matches
Mail list logo
