On Tue, 21 Apr 2020 at 17:53, Serhiy Storchaka wrote:
>
> 21.04.20 19:35, Paul Moore пише:
> > Hence my suggestion that maybe it's not so much an
> > (actionable) exception that people want as an assertion.
>
> What do you mean by assertion? Raising an AssertionError?
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 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 Thu, 7 May 2020 at 01:07, Christopher Barker wrote:
> 3) Add a ternary mode flag to zip
> zip(*iters, mode = ('shortest' | 'equal' | 'longest'), fillvalue=None)
You missed
itertools.zip_longest(*iters, fillvalue=None)
from this one. Unless you're proposing to drop itertools.zip_longest,
the
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 you're
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
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
s
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'"
def
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
(exten
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 people/situations
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 CONDI
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 di
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 su
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 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 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 allowin
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 c
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 is
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 lesse
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 objec
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 t
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 a
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 things
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 justifica
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 wit
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 de
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 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 t
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
>> > tr
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 p
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 arg
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
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 "n
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 passing
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 automatica
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
> >>
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()
> unpicklab
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 OverflowE
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 true
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.
>
> > > Granted, I
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, 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:
https://pypi.org/proje
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
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 b
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 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 intereste
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 Pyt
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 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 documentatio
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 c
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 t
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, 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
*or
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 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 whe
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 insta
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 any
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
enh
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 pla
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 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 IN
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 t
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 y
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 wa
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)
>> super().
>>> 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 complicated
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 expres
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 invo
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 exist
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? A
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. Ther
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
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 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 ab
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 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 ne
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 dire
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 th
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 engin
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
> would
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 click
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 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 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 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 i
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 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 infli
On 30 August 2016 at 04:19, Ken Kundert wrote:
> Do you think there is no value to be able to naturally read and write numbers
> with SI scale factors from Python? Or is your issue with something about my
> proposal?
Ken,
Answering these questions from my perspective (and thanks for taking
note o
On 30 August 2016 at 21:34, Ken Kundert wrote:
> So, given all this, I would like to make the following recommendations:
> 1. No action should be taken.
> 2. The main justification to modifying float() was to make it consistent with
>the extended Python language. Without extension 1, this just
On 31 August 2016 at 05:08, Ken Kundert wrote:
> Auto-scaling is kind of the point. There is really little need for a special
> mechanism if your going to specify the scale factor yourself.
>
> >>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, 50e3))
> Attenuation = -13.7 dB at 5
On 1 September 2016 at 19:44, Shane Hathaway wrote:
> Sometimes I fix unbalanced parentheses incorrectly. Here's something I
> might type. There should be another closing parenthesis in the middle:
>
> def update(names, value):
> (dbsession.query(Table1)
> .filter(Table1.nam
On 7 September 2016 at 10:28, Hugh Fisher wrote:
> Firstly, the interpreter will need to have type checking built in.
> Just about every intro book and tutorial for Python says how great it
> is that you don't have an edit-save-compile cycle, just fire up the
> Python interpreter and start typing.
On 7 September 2016 at 22:31, Hugh Fisher wrote:
> The average programmer such as myself will expect that if I write code
> specifying the type of a variable or whatever it should *do
> something*. It's code, I wrote it, it should be interpreted.
Reading the documentation should correct that mist
On 8 September 2016 at 10:34, Arek Bulski wrote:
> That wont work because I would have to type the expression that is used as
> argument twice in a test. I need shuffled. Enough said.
You've probably spent way more time debating shuffled here than you
would have needed to add a shuffled function
On 8 September 2016 at 10:46, Hugh Fisher wrote:
> Annotations look like code, they're mixed in with names and operators
> and literals and keywords, and all the standard syntax and semantic
> checks are applied.
Apologies - I was thinking you were referring to variable annotations
(and even ther
301 - 400 of 896 matches
Mail list logo
