On Tue, 24 Mar 2020 at 09:41, Rhodri James wrote:
>
> On 24/03/2020 01:13, Oleg Broytman wrote:
> > IMO the issue is in not following the best practices. Distribute wheels
> > or freezed binaries, not just drop scripts unto users.
>
> For most circumstances, that is not a practical answer.
On Tue, 24 Mar 2020 at 11:39, Eric V. Smith wrote:
> Cygwin should make it easier to have Windows look like Unix, not harder.
In my experience, only if you use Cygwin for everything (so I agree,
Frédéric should probably install cygwin Python). Integrating native
applications and Cygwin isn't
On Tue, 5 May 2020 at 07:22, Christopher Barker wrote:
> In any case, you seem to making the argument that a few of us are putting
> forward: yes, a flag on zip() is likely to get more use than a function in
> itertools. Thanks for the support :-)
I'd like to add my voice to the people saying
On Sat, 9 May 2020 at 10:13, Ram Rachum wrote:
>
> Here's an idea I've had. How about instead of this:
>
> itertools.islice(iterable, 7, 20)
>
> We'll just have:
>
> itertools.islice(iterable)[7:20]
>
>
> Advantages:
> 1. More familiar slicing syntax.
> 2. No need to awkwardly use None when
On Sat, 2 May 2020 at 12:19, Steven D'Aprano wrote:
> - Is there a need for it? Granted.
> - Is it complicated to get right? No.
This one, I'll query. Until someone (probably you) mentioned it, I
didn't think of using zip_longest to do this - probably because I was
locked into thinking about the
On Thu, 3 Sep 2020 at 18:06, haael wrote:
> Only objects of globally defined classes are picklable:
>
> class Global:
> pass
>
> picklable = Global()
>
> def f():
> class Local:
> pass
> return Local
>
> Local_here = f()
>
On Tue, 15 Sep 2020 at 06:54, David Mertz wrote:
>
> Thanks so much Ben for documenting all these examples. I've been frustrated
> by the inconsistencies, but hasn't realized all of those you note.
>
> It would be a breaking change, but I'd really vastly prefer if almost all of
> those
On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
wrote:
>
> Ben Rudiak-Gould writes:
>
> > 1./0. is not a true infinity.
>
> Granted, I was imprecise. To be precise, 1.0 / 0.0 *could* be a true
> infinity, and in some cases (1.0 / float(0)) *provably* is, while
> 1e1000 *provably* is not a
On Tue, 15 Sep 2020 at 10:29, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
> > On Tue, 15 Sep 2020 at 08:12, Stephen J. Turnbull
> > wrote:
> > > Ben Rudiak-Gould writes:
>
> > > > 1./0. is not a true infinity.
>
> > > Gran
On Tue, 15 Sep 2020 at 16:48, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you
> > divide "one" by "zero" the only plausible interpretation - if you
> > allow
On Thu, 15 Oct 2020 at 19:14, Ram Rachum wrote:
>
> Your use case is valid, there are times in which I'd like a strong reference
> to be kept. But there are also lots of times I want it to not be kept. Then I
> would offer this feature as a flag `weakref=True` with a default of `False`.
> What
On Mon, 12 Oct 2020 at 14:51, Stephen J. Turnbull
wrote:
>
> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of
> ordinals, but it should work I think).
I don't think it does. The ordinals are based on the idea of
On Fri, 16 Oct 2020 at 08:42, Ram Rachum wrote:
>
> That's similar to my use case. Big mutable object (right now a state in a
> multi-agent simulation) with lots of methods that I want to cache.
Thanks all for the explanation of use cases.
In this specific example, if you're caching methods
On Fri, 16 Oct 2020 at 20:43, Jonathan Crall wrote:
>
> @Chris Angelico If you are more application focused, or trying to get a
> scientific result, and you don't care too much about the reusability of your
> scripts, then I can see the validity of this use case. But I would not want
> to
Wes, you seem to just be throwing out a load of questions, to all of
which my answer is "I don't know" (and usually "I don't care either").
Do you have an actual proposal here, and if so could you state it
clearly and in the form of a description, not a question, please? I'm
struggling to find
On Sat, 22 Aug 2020 at 13:08, Oz wrote:
>
> Hi Everyone,
>
> I really like how go parses durations:
>
> ```
> hours, _ := time.ParseDuration("10h")
> complex, _ := time.ParseDuration("1h10m10s")
> micro, _ := time.ParseDuration("1µs")
> // The package also accepts
On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > Furthermore, I'd be very, very strongly opposed to having x[i,
> > default=d] be a way of supplying a default result if i isn't present
> > in *any* subscriptable clas
On Wed, 26 Aug 2020 at 15:12, Ricky Teachey wrote:
> Objection 1: Slowing Things Down
>
> The INTENDED EFFECT of the changes to internals will be as Jonathan Fine
> described: every time a subscript operation occurs, this new dunder attribute
> gets investigated on the class, and if it is not
On Fri, 28 Aug 2020 at 13:26, David Mertz wrote:
> As a side note, I don't really get why everyone else thinks a try/except is
> the most natural approach while a ternary seems more obvious to me for this
> situation. But it kinda connects to me liking list.get() better, I think...
> since
On Sat, 29 Aug 2020 at 05:53, Ricky Teachey wrote:
>
> On Fri, Aug 28, 2020 at 10:10 PM Steven D'Aprano wrote:
>> So let me see if I have this. You want to add a special dunder method
>> which, if it exists, is automatically called by the interpreter to
>> preprocess the subscript before
On Sat, 29 Aug 2020 at 15:12, Ricky Teachey wrote:
> Here's one reason I find a new dunder or dunders compelling that I haven't
> seen anyone respond to directly:
>
> I can write functions that define named arguments, and if I pass them
> positionally, they get assigned the right name
On Sat, 29 Aug 2020 at 18:04, Jonathan Fine wrote:
>
> Paul Moore wrote:
>
>> But you don't give any reason why you'd want to do that. Why are you
>> using subscript notation rather than a simple function call?
>
>
> Good point. Consider
> >>> def f
On Thu, 27 Aug 2020 at 16:21, David Mertz wrote:
>
> On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull
> wrote:
>>
>> They're going to get one, is my reading of the "named indicies"
>> thread. That is, it looks to me very likely that index notation
>> (`x[i]`) is going to support keyword
On Mon, 24 Aug 2020 at 09:59, Alex Hall wrote:
>
> On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote:
>>
>> On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote:
>> > But thus brings up a broader question:
>> >
>> > Why not allow slice syntax as an expression everywhere? Everywhere I’ve
>> >
On Fri, 25 Sep 2020 at 13:46, Samuel Colvin wrote:
>
> Sorry I probably wasn't clear enough in what I was suggesting.
>
>>
>> The main question here is why using a hint or a decorator should be
>> better than a simple documentation.
>
>
> For the same reason type hints are better than
On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote:
> Why? Do you really think you can enumerate EVERY possible way that
> something might fail?
Rust does a surprisingly good job of that, actually. But the point is
that Python is not Rust, and the infrastructure Rust uses to allow it
to manage
On Fri, 25 Sep 2020 at 18:28, Samuel Colvin wrote:
>> There's also the problem that you've explicitly acknowledged, that
>> exception hints are *always* going to be inaccurate, in stark contrast
>> to type hints which are expected to be correct when used.
>
> We should draw a distinction between
On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote:
> There may be practical difficulties in sticking exceptions into
> annotations. Annotations already can be pretty long and bulky. But if
> you are okay with functions documenting that they might raise a certain
> exception, then *in principle*
On Mon, 21 Sep 2020 at 21:07, Abdur-Rahmaan Janhangeer
wrote:
> On python lists since
> i have been following them, i prefer
> threads die than having it continue just
> for the sake of it continueing, like the
> present thread is doing.
If you prefer the thread to die if people are not
On Thu, 17 Sep 2020 at 20:07, Chris Angelico wrote:
>
> On Fri, Sep 18, 2020 at 4:55 AM Alex Hall wrote:
> >
> > On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico wrote:
> >>
> >> The only time you can safely mutate locals() is when you're at top
> >> level and it's the same as globals().
> >
> >
On Sat, 19 Sep 2020 at 04:06, Paolo Lammens wrote:
>
> I also wanted to add:
>
> If
>
> @a, b, c
> def func(): ...
>
> was prohibited (i.e. you must use parentheses) because [it looks like] it
> doesn't make any sense, shouldn't be also the case that any expression with
> spaces should
On Wed, 23 Sep 2020 at 11:09, David Mertz wrote:
> It's hard to see where packaging would have any advantage with brotli or zstd
> over lzma. XZ is more widely used, and package size seems to dominate speed.
> There are definitely some intermediate compression levels where both brotli
> and
On Wed, 23 Sep 2020 at 08:08, Paul Sokolovsky wrote:
> In the meantime, why can't you use modules on PyPI/github/wherever
> else?
There are significant use cases where 3rd party modules are not easy
to use. But let's not get sucked into that digression here.
The point of this request is that
On Thu, 17 Sep 2020 at 13:38, Dennis Sweeney
wrote:
>
> TL;DR: I propose the following behavior:
>
> >>> s = "She turned me into a newt."
> >>> f"She turned me into a {animal}." = s
> >>> animal
> 'newt'
Something very similar to this already exists on PyPI:
On Thu, 17 Sep 2020 at 14:12, Chris Angelico wrote:
> Assigning to an f-string is VERY tempting. It doesn't quite sit right
> with me (f-strings feel like literals, even though they aren't, and it
> doesn't make sense to assign to a string literal) - but I do like the
> concept. If it existed in
Also, I routinely write scripts that have no `if __name__ ==
'__main__'` line at all, they just run - no-one should ever import
them, so it makes no difference. And I exit (in multiple places) using
`raise SystemExit("reason")`.
My point being that yes, there are *lots* of ways of writing Python
I suspect it's because zip() is actually a class constructor, so
argument zero is self...
Paul
On Wed, 20 May 2020 at 10:10, Neil Girdhar wrote:
>
> I'm just curious, but is it usual for errors to be one-based rather than
> zero-based? If I do zip(*iterables, strict=True), then "argument 1 is
On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer
wrote:
> That's why the references exist, so that you look the details up. But knowing
> at a glance the status of a PEP immediately changes the perception of the
> text at hand
You are very optimistic that people will remember to make this
On Thu, 22 Oct 2020 at 03:16, David Mertz wrote:
>
> To bring it back to a concrete idea, here's how I see things:
>
> The idea of f-string-like assignment targets has little support. Only Chris,
> and maybe the OP who seems to have gone away.
> The idea of a "scanning language" seems to garner
On Fri, 23 Oct 2020 at 10:18, Marco Sulla wrote:
>
> On Fri, 23 Oct 2020 at 09:39, Steven D'Aprano wrote:
>>
>> Using PEP 634 syntax, I could write:
>>
>>
>> def method(self, **kwargs):
>> {'spam': spam, 'eggs': eggs, **kw} = **kwargs
>> process(spam, eggs)
>>
On Fri, 23 Oct 2020 at 06:59, Henk-Jaap Wagenaar
wrote:
>
> On Fri, 23 Oct 2020 at 06:35, Random832 wrote:
>>
>> Does anyone else remember when xkcd first mentioned python? The main selling
>> point it had for it [and the one that was actually literally true, vs
>> 'import antigravity' which
On Tue, 20 Oct 2020 at 20:16, Chris Angelico wrote:
> What's the mechanism by which a venv announces its parent, and does
> this work correctly if the binary is invoked directly? Currently, if
> you invoke /.../.../.../env/bin/python3, it will use the lib directory
> from that venv; with this
On Tue, 20 Oct 2020 at 17:04, Steven D'Aprano wrote:
>
> In general, Python bindings are *all or nothing* -- either all the
> targets get bound, or none of them.
I wonder if this could work with the proposed pattern matching
statement. The current proposal doesn't allow it, but maybe a future
On Thu, 22 Oct 2020 at 11:39, Hans Ginzel wrote:
>
> On Thu, Oct 22, 2020 at 08:31:34PM +1100, Steven D'Aprano wrote:
> >> cursor.execute(f"INSERT INTO {table} VALUES (1, '{}');")
> >> SyntaxError: f-string: empty expression not allowed
> >
> >Escape the braces by doubling them:
> >f"INSERT
On Thu, 22 Oct 2020 at 13:36, Chris Angelico wrote:
>
> On Thu, Oct 22, 2020 at 8:22 PM Steven D'Aprano wrote:
> >
> > On Wed, Oct 21, 2020 at 07:17:21PM -0700, Guido van Rossum wrote:
> >
> > > Hmm, if the above is acceptable, maybe f-strings are still the logical
> > > next
> > > step, since
On Wed, 22 Jul 2020 at 10:54, Stestagg wrote:
>
> I'm (weakly) +1 for the concept of for..else being confusing, weird, and
> somehow not quite suitable/useful for many use-cases where it feels like it
> should.
>
> I'm -1 for each of the suggested improvements that I've understood so far.
>
> I
On Wed, 22 Jul 2020 at 13:18, Mathew Elman wrote:
>> Ones that retain else on loops are bad because
>> they end up providing two (typically equally confusing) ways of doing
>> things.
>
> I don't think this is the case. I agree that adding an alternative to `else`
> just to have an alternative
On Fri, 7 Aug 2020 at 09:26, Kazantcev Andrey wrote:
>
> The problem in this code
>
> lib.py
> ```
> from json import dumps
>
> def some_func():
> # do something
> res = dumps(...)
> # do something
> ```
>
> I wish dump and load themselves could take parameters from somewhere else,
>
On Fri, 7 Aug 2020 at 09:56, Brendan Barnwell wrote:
> > Have a read of the PEP's rejection notice at the top. To revive the
> > PEP, the objections to it need to be solved.
>
> It seems that the rationale that was used in the PEP was fairly
> narrowly focused on the comparison with
On Fri, 7 Aug 2020 at 16:21, David Mertz wrote:
>
> On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell wrote:
>>
>> It seems that the rationale that was used in the PEP was fairly
>> narrowly focused on the comparison with things like dict.get() and the
>> idea of EAFP. A somewhat broader
On Fri, 7 Aug 2020 at 16:32, Alex Hall wrote:
> Paul, do you want to write `[s for s in strings if
> (packaging.specifiers.SpecifierSet(s) except
> packaging.specifiers.InvalidSpecifier: False)]`? That's a mouthful.
No, I would (obviously?) use some from ... imports to simplify it. But
even
On Fri, 7 Aug 2020 at 22:46, Ricky Teachey wrote:
>
> This was inspired by a tweet today from Brandon Rhodes. I looked for
> something like it on the mypy issues page and didn't find anything.
>
> Would it make good semantic sense- and be useful- to specify valid numerical
> ranges using slices
On Thu, 13 Aug 2020 at 22:22, Stefano Borini wrote:
>
> On Mon, 6 Apr 2020 at 09:40, Steve Barnes wrote:
> >
> > As an aside I have a perfect example to back up what Paul is saying below.
> > I work for a large corporation where developers are permitted to install
> > python modules on their
On Mon, 3 Aug 2020 at 08:26, Dominik Vilsmeier wrote:
>
> On 02.08.20 15:36, Sebastian M. Ernst wrote:
>
> > Hi all,
> >
> > yet another (possibly bad?) idea from day-to-day work ...
> >
> > I occasionally need to import a lot of "stuff" from certain modules. The
> > "stuff" is usually following
On Fri, 10 Jul 2020 at 15:23, Jonathan Fine wrote:
> With hindsight, I can see your difficulty. The original idea is to extend the
> syntax so that
> >>> m = MyMap()
> >>> m[1, 2, 3, a=4, b=5] = 'foobar'
> is allowed in some future version of Python.
>
> Python's syntax already allows:
>
On Fri, 10 Jul 2020 at 13:47, Stestagg wrote:
> The intent of my statement was: The current implementation of dict does not
> allow any reasonable implementation of dict_keys/dict_values/dict_items with
> O(1) index behaviour. I.e. the performance scalability of any future changes
> to the
On Fri, 10 Jul 2020 at 14:26, Stestagg wrote:
>
> All valid points, I'd recommend catching up on the entire thread, it'll be a
> lot quicker than re-iterating them here.
I have been reading the thread (admittedly skimming). I've seen
nothing yet to suggest that there's a useful change to Python
On Fri, 10 Jul 2020 at 11:54, Jonathan Fine wrote:
> Let's proceed. We continue to use d = Dummy(). Given that
>>>> key = d[1, 2, 3, a=4, b=5]
> is allowed, what should we be able to say about the key. Clearly it should be
> an instance of a class, and there should be a way of creating
On Mon, 13 Jul 2020 at 18:42, Barry Scott wrote:
> On 13 Jul 2020, at 05:55, Christopher Barker wrote:
>
> well, sure, though I have to say that I think that that's an unfortunate
> confusing thing about python dicts. IN fact, I doubt there are many uses at
> all for dict.keys() -- most uses
On Fri, 10 Jul 2020 at 17:45, Steven D'Aprano wrote:
> I must admit I like the look of this, but I don't know what I would use
> it for.
It feels very much like the sort of "here's some syntax that might
match someone's mental model of something" that is common in languages
that focus on
On Wed, 17 Jun 2020 at 10:44, artem6191 wrote:
>
> So yeah, we can "if : return", but why not?
That's the wrong question. The correct question is "why is this
needed, and is the need sufficiently pressing to justify the change to
the language?"
You're talking about allowing "return EXPR if
On Tue, 16 Jun 2020 at 11:53, Stéfane Fermigier wrote:
> the "batteries included" argument was a huge selling points years ago (when
> Aaron Watters wrote "Internet Programming With Python", for instance) but I
> think the situation has changed quite a bit since then.
For some
On Sun, 14 Jun 2020 at 08:16, Stephen J. Turnbull
wrote:
> That could be checked by MyPy, without global dataflow analysis.
"MyPy can check this" is a good point that I hadn't considered (I've
not used mypy much myself, yet).
As Chris A says, I'd be inclined to see how far we can get with
On Wed, 10 Jun 2020 at 08:30, Steven D'Aprano wrote:
> Given Python's execution model where we have statements and functions, I
> think that it is a feature that they have different syntax. If I see
> words separated by spaces:
>
> import math
> del spam
> while condition
> if obj
On Sat, 13 Jun 2020 at 13:54, artem6191 wrote:
>
> This operator will allow to send arguments to function only by certain values.
> Example:
>
> def some_function(a > (1, 2,3), b):
># Some code
> some_function(1, 2)
> some_function(4, 2) # Error "Value '4' is not allowed for argument 'a'"
On Fri, 24 Jul 2020 at 16:15, Gábor Bernát wrote:
>
> Hello, I'd like to bring to your attention
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta
> Shashkova:
>
> I would like to have a lazy repr evaluation for the objects! Sometimes users
> have many really large
On Fri, 24 Jul 2020 at 16:43, Gábor Bernát wrote:
>
> While I agree the implementation on how to represent in limited space the
> object should be the responsibility of the project that provides objects of
> long size, I think it's a language-behaviour material what type of solution
> we want
On Fri, 24 Jul 2020 at 02:18, Rob Cliffe via Python-ideas
wrote:
> The upholders of the status quo regularly provide gallant explanations of why
> "else" is perfectly natural, even intuitive.
> The fact is, it isn't. If it were, it wouldn't *need* to be repeatedly
> explained by gurus to
On Fri, 14 Aug 2020 at 13:12, Jonathan Fine wrote:
> Anyone who is experimenting with keyword keys would, I think, appreciate
> having something they can use straight away. Thus, I think, any use case for
> PEP 472 is also a use case for the general keyword class I'm suggesting. No
> use cases
On Thu, 7 Jan 2021 at 12:18, Paul Sokolovsky wrote:
> On Thu, 7 Jan 2021 22:59:41 +1100
> Chris Angelico wrote:
>
> > On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky
> > wrote:
> > > Well, I don't write PEPs. I write "pseudoPEPs". Wrote 2 so far: "+="
> > > operator for io.BytesIO/StringIO and
On Mon, 30 Nov 2020 at 08:29, Paul Sokolovsky wrote:
>
> Hello,
>
> On Mon, 30 Nov 2020 08:11:07 +
> Paul Moore wrote:
>
> > On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky
> > wrote:
> > > On the other hand, block-scoped variables are implemented in:
&
On Mon, 30 Nov 2020 at 08:03, Paul Sokolovsky wrote:
> On the other hand, block-scoped variables are implemented in:
>
> * C
> * C++
> * Java
> * Rust
> * Lua
> * JavaScript (not by default, as opt-in)
> * Scheme
> * Common Lisp (as opt-in)
> * ML
> * Ocaml
> * Haskell
> * very long list of other
On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou wrote:
>
> On Mon, 23 Nov 2020 08:09:07 +0000
> Paul Moore wrote:
> >
> > But it's not as limiting as you suggest - it *does* preclude most
> > scientific use (because of numpy etc) but (for example) a large number
> >
On Thu, 3 Dec 2020 at 11:07, Jonatan wrote:
>
> Hi, sometimes I do nested loops and I want to break specific loop,
> outer/inner etc.
> I need to do an ugly thing with for..else and it's annoying.
>
> It'd be nice if we could do so:
> for i in range(10) as loop_i:
> for j in range(i, i + 10)
On Tue, 24 Nov 2020 at 07:47, Christopher Barker wrote:
> indeed I am. But also, where I need this sort of thing is for desktop GUIs
> (wxPython in my case), another heavy user of compiled extensions.
>
> I'm still confused what the point is of a zipapp, if it can't be a proper
> point and
On Tue, 1 Dec 2020 at 15:55, Paul Sokolovsky wrote:
> I also forgot to mention very important point in the intro: when you
> read this proposal, please don't think about "CPython". That for sure
> will send you the wrong vibes. Think about "Python". ;-)
By which you mean "CPython and all other
On Thu, 10 Dec 2020 at 17:48, Gregory Szorc wrote:
> So one can make the argument that this one-off behavior of PathFinder
> undermines the ability to easily distribute Python applications and that in
> turn undermines the value of Python in the larger ecosystem. My opinion is
> the harm
On Thu, 19 Nov 2020 at 22:55, Greg Ewing wrote:
>
> On 20/11/20 11:32 am, Chris Angelico wrote:
> > It's very
> > tempting to think "oh, I could just make it easier for my users, and
> > then they don't have to think about anything". But what happens when
> > there's a security patch for Python?
On Fri, 20 Nov 2020 at 08:55, Chris Angelico wrote:
>
> On Fri, Nov 20, 2020 at 6:06 PM Brendan Barnwell
> wrote:
> > You've mentioned this objection at least twice now and I still don't
> > see it having any real relevance. All kinds of programs have bugs and
> > vulnerabilities.
On Fri, 20 Nov 2020 at 09:12, Steven D'Aprano wrote:
>
> On Thu, Nov 19, 2020 at 11:24:32PM +, Paul Moore wrote:
>
> > I'm not sure about an installer. To me that means integrating with
> > system "installed apps" mechanisms. But I *would* support buildi
On Fri, 20 Nov 2020 at 13:47, Greg Ewing wrote:
>
> I've seen this sort of thing in other app bundlers too, e.g.
> last time I looked py2app and py2exe had a bunch of special casing
> for various libraries.
>
> This is quite a big problem, IMO. It makes these tools very
> flakey.
>
> What is it
On Fri, 20 Nov 2020 at 10:55, Abdur-Rahmaan Janhangeer
wrote:
> After the above thread I contacted a number of Zipapp-related persons
> including the author of Shiv ( Loren Carvalho ) who was kind enough to reply.
> Along the conversation he stated that
>
> > In fact, shiv itself sort of breaks a
On Fri, 20 Nov 2020 at 15:44, Ricky Teachey wrote:
>
> I was reading the pyinstaller thread and had this idea but didn't want to
> hijack.
>
> Maybe a wild idea, and very possible totally impractical or hopelessly
> complex, but: could the existing pypi infrastructure be leveraged into a set
>
On Thu, 19 Nov 2020 at 07:42, Stéfane Fermigier wrote:
> But cooperation between the PyInstaller team and the Python Packaging
> Authority, if this doesn't happen already, could probably help.
It doesn't, but that is simply because the PyInstaller team have never
reached out *asking* to be
On Thu, 19 Nov 2020 at 15:03, Mathew Elman wrote:
>
> Perhaps there could be something in the std-lib that allowed packaging into
> an executable but with some limitations, as a toy example: only supporting
> the std-lib dependencies. There is some precedence for minimal
> implementations
>>> from itertools import islice
>>> a = (i for i in range(0, 100, 10))
>>> next(islice(a, 5, None))
Paul
On Tue, 17 Nov 2020 at 15:37, Joao S. O. Bueno wrote:
>
> Although that is not a pattern I recall I had needed, but for the first item
> in a generator,
> I recognize it is more
On Tue, 17 Nov 2020 at 22:19, Oscar Benjamin wrote:
> It would be nice if islice gave an object that supported slicing so
> that you could spell it like:
>
>for x in islice(a)[5:]:
>
> I find it hard to decipher the meaning of the arguments to islice
> compared to reading a normal slice
On Sun, 22 Nov 2020 at 11:32, Hartmut Goebel
wrote:
>
> Am 20.11.20 um 11:01 schrieb Paul Moore:
> > 1. Add the ability for zipapp to prepend a launcher for Windows, so
> > zipapps can be built that "run natively" on Windows (Unix and MacOS
> > don't nee
On Mon, 23 Nov 2020 at 03:37, Christopher Barker wrote:
>
> On Sun, Nov 22, 2020 at 6:34 AM Paul Moore wrote:
>> 4. Support for C extensions.
>
> That last one if VERY limiting :-(
Correct. But it's ultimately an OS limitation - you can't run a shared
library dir
Also, virtualenv is distributed as a zipapp these days.
Paul
On Mon, 23 Nov 2020 at 08:44, Steven D'Aprano wrote:
>
> On Sun, Nov 22, 2020 at 07:37:35PM -0800, Christopher Barker wrote:
>
> > I'm curious about zipapp -- I've heard of it, but never tried to use it --
> > does it get much use in
On Mon, 23 Nov 2020 at 10:39, Mathew Elman wrote:
>
> I would argue this sounds like a case for a "python_runner", i.e. a
> lightweight python vm that can run python apps, e.g. zipapps. Something like
> the blender_runner for blender. Making it explicitly an app that runs via
> some other
On Mon, 23 Nov 2020 at 11:32, Mathew Elman wrote:
> I imagine there would be a way to have an install install the runner if there
> is not one on the machine, and use the existing one if there is, and creating
> a venv in either case. Meaning that using the equivalent of an embedded JRE
>
On Thu, 22 Oct 2020 at 14:44, Chris Angelico wrote:
> Returning a dict
> would be FAR less convenient for the most common cases, but as you
> say, it'd be the fallback for when you need dynamic parsing.
If you're that sure that direct assignment to locals would be a killer
feature (I'm not, but
On Sun, 10 Jan 2021 at 19:24, Chris Angelico wrote:
>
> 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
> > > e
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 statements as input parameters,
> not the whole script, like for
On Sat, 9 Jan 2021 at 13:29, Oscar Benjamin wrote:
> The argument to reversed either needs to be a sequence with __len__
> and __getitem__ or an object with a __reversed__ method that returns
> an iterator. The arguments to chain have to be iterables. Every
> sequence is an iterable so there is a
On Mon, 25 Jan 2021 at 20:02, Christopher Barker wrote:
> using a system setting as a default is a really bad idea in this day of
> interconnected computers.
I'd mildly dispute this. There are (significant) downsides with the
default behaviour being system-dependent, yes, but there are *also*
On Tue, 12 Jan 2021 at 19:28, Sebastian Kreft wrote:
>
> Actually you can get the cache data from the python version, for that you
> need to force the use of the python version of functools
"as private as you can get" != "private" :-)
I had a feeling there would be a way to do it, but wasn't
On Tue, 12 Jan 2021 at 17:04, Steven D'Aprano wrote:
> My use-case is debugging functions that are using an LRU cache,
> specifically complex recursive functions. I have some functions where:
>
> f(N)
>
> ends up calling itself many times, but not in any obvious pattern:
>
> f(N-1),
On Tue, 12 Jan 2021 at 17:16, Christopher Barker wrote:
>
> Is the implementation of lru_cache too opaque to poke into it without an
> existing method? Or write a quick monkey-patch?
>
> Sorry for not checking myself, but the ability to do that kind of thing is
> one of the great things about a
501 - 600 of 793 matches
Mail list logo
