[Python-ideas] Re: Changing Package Representation On Shell

Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com | github Mauritius On Fri, Apr 3, 2020 at 2:21 AM Andrew Barnert wrote: > On Apr 2, 2020, at 13:35, Abdur-Rahmaan Janhangeer > wrote: > But nobody’s mentioned

[Python-ideas] Re: python interpreter docker builder

It should be possible to do rootless manylinux builds in containers with podman/buildah: https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/ Last I checked, rootless within rootless as you'd need for CI builds is problematic due to overlayfs within overlayfs not

[Python-ideas] Re: python interpreter docker builder

Probably, but I'm still convinced a sdk would be nice. Yes, I'm aware of manylinux. DEB/RP suffer from the fact that need to be "root" installed and manylinux needs docker to be used, so same issue. Thanks On Thu, 2 Apr 2020 at 20:55, Wes Turner wrote: > No, I think you might be doing it

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Christopher Barker writes: > On Thu, Apr 2, 2020 at 6:07 AM Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Yah, but you also get > > > > > outfile.seek(some_random_place) > > outfile += something > > > > Is that not exactly the same as what you can do

[Python-ideas] Re: python interpreter docker builder

No, I think you might be doing it wrong. FWIW, I haven't needed to compile CPython in 10 years (iot to build something other than CPython) because official builds of Conda, DEB, RPM, or Docker containers are generally sufficient. Are you familiar with the manylinux specs? I should've thought to

[Python-ideas] Re: python interpreter docker builder

To distribute python binaries (interpreter + extensions) on linux one need to compile it using the lowest common denominator (eg. some linux distro really old, like rhel6). Later when a user need to build an extension that might not be possible (because the running host might not have a compatible

[Python-ideas] Re: python interpreter docker builder

So you want to import from / call into what would be in $prefix/lib & $prefix/include? How is the SDK archive use case different from the package archive use case? On Thu, Apr 2, 2020, 8:32 PM Antonio Cavallo wrote: > Yes, I'm aware of those.. providing an application wouldn't be what I have >

[Python-ideas] Re: python interpreter docker builder

Yes, I'm aware of those.. providing an application wouldn't be what I have in mind. The point would be providing a python sdk, similar to what node/java/.net provide. something it would possible to build upon. Those are distributed as stand alone "zip" to the general public. On Thu, 2 Apr 2020

[Python-ideas] Re: python interpreter docker builder

Would e.g. pyinstaller or constructor solve the problem? https://pyinstaller.readthedocs.io/en/stable/ > PyInstaller bundles a Python application and all its dependencies into a single package. The user can run the packaged app without installing a Python interpreter or any modules. PyInstaller

[Python-ideas] Re: python interpreter docker builder

Not quite, my hope is to have a python tarball similar to the "Windows x86 embeddable zip file" but for linux. Similar to miniconda but for plain python, or sort of python "sdk", if that makes sense. Thanks PS. I didn't know about the core workflow, thanks On Thu, 2 Apr 2020 at 19:55, Wes

[Python-ideas] Re: Changing Package Representation On Shell

IDK what you'd grep for in these; if it's not there you could send a PR that adds more greppable keywords or cross-:ref:'s the sys.displayhook docs like this: :func:`sys.displayhook` https://docs.python.org/3/library/sys.html#sys.displayhook

[Python-ideas] Re: Changing Package Representation On Shell

On Fri, Apr 03, 2020 at 08:00:38AM +1100, Steven D'Aprano wrote: > But I can tell you that this will 99.99% be rejected. And if it is > accepted, I can tell you that the first time you get hit by a massive > wall of text from a package docstring in an exception or some other use > of

[Python-ideas] Re: python interpreter docker builder

https://devguide.python.org/buildbots/ These run in Docker containers: - https://github.com/python/cpython/blob/master/.travis.yml - https://github.com/conda-forge/python-feedstock/blob/master/recipe/build.sh These are all of the current builds; are you proposing another?

[Python-ideas] Re: Changing Package Representation On Shell

On Thu, Apr 02, 2020 at 07:18:47PM +0400, Abdur-Rahmaan Janhangeer wrote: > Out of curiosity how did you learn about sys.displayhook? 20+ years of using Python, experimenting at the interpreter, reading the documentation, blog posts, etc. I have no idea *specifically* where I learned it. I

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello, On Fri, 3 Apr 2020 09:34:44 +1100 Chris Angelico wrote: > On Fri, Apr 3, 2020 at 9:20 AM Paul Sokolovsky > wrote: > > But not exactly. Let me humbly explain what's really a cost. It's > > looking at PyObject_HEAD > > https://swenson.github.io/python-xr/Include/object.h.html#line-78 > >

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Fri, Apr 3, 2020 at 9:20 AM Paul Sokolovsky wrote: > But not exactly. Let me humbly explain what's really a cost. It's > looking at PyObject_HEAD > https://swenson.github.io/python-xr/Include/object.h.html#line-78 > (damn, that's Python2 source, stupid google), and seeing that it's at > least:

[Python-ideas] python interpreter docker builder

Hi is there any interest (or anyone has done it before), building the python interpreter using docker? The basic idea is building the toolchain (gcc) and on top of that the python interpreter. On mac/linux it can build natively, but it can use docker to target linux from mac/windows. Thanks

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello, On Fri, 3 Apr 2020 08:44:23 +1100 Chris Angelico wrote: > On Fri, Apr 3, 2020 at 8:26 AM Paul Sokolovsky > wrote: > > > > Hello, > > > > On Wed, 1 Apr 2020 21:25:46 -0400 > > Kyle Stanley wrote: > > > > > Also, on the point of memory usage: I'd very much like to see some > > > real

[Python-ideas] Re: Changing Package Representation On Shell

On Apr 2, 2020, at 13:35, Abdur-Rahmaan Janhangeer wrote: > >> On Thu, Apr 2, 2020 at 8:15 PM Andrew Barnert wrote: >> >> Why should modules break all of that, and be different from strings, tuples, >> functions, classes, etc.? > > python-ideas is for ideas without worrying about

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Apr 1, 2020, at 20:59, Steven D'Aprano wrote: > > Nevertheless, you do make a good point. It may be that StringIO is not > the right place for this. That can be debated without dismissing the > entire idea. I think it’s worth separating the two. There is a legitimate desire for a “better”

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On 02/04/2020 22:24, Paul Sokolovsky wrote: Hello, On Wed, 1 Apr 2020 21:25:46 -0400 Kyle Stanley wrote: Paul Sokolovsky wrote: Roughly speaking, the answer would be about the same in idea as answers to the following questions: [snip] I would say the difference between this proposal so far

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello, On Wed, 1 Apr 2020 20:05:33 -0700 Andrew Barnert wrote: > On Apr 1, 2020, at 14:47, Paul Sokolovsky wrote: > > > >> At the moment, the > >> message is relatively clear - "build a list and join it" (it's very > >> rare that anyone suggests StringIO currently). > > > > I don't know

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Fri, Apr 3, 2020 at 8:26 AM Paul Sokolovsky wrote: > > Hello, > > On Wed, 1 Apr 2020 21:25:46 -0400 > Kyle Stanley wrote: > > > Also, on the point of memory usage: I'd very much like to see some > > real side-by-side comparisons of the ``''.join(parts)`` memory usage > > across Python

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello, On Wed, 1 Apr 2020 21:25:46 -0400 Kyle Stanley wrote: > Paul Sokolovsky wrote: > > Roughly speaking, the answer would be about the same in idea as > > answers to the following questions: > > [snip] > > I would say the difference between this proposal so far and the ones > listed are

[Python-ideas] Re: Changing Package Representation On Shell

On Fri, Apr 03, 2020 at 12:28:36AM +0400, Abdur-Rahmaan Janhangeer wrote: > This means we have a __repr__ option in packages (Without Steven's snippet > above)? There is no "hook" in the package file structure where you can customize the repr. It is built into the module type. Once loaded,

[Python-ideas] Re: Changing Package Representation On Shell

Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com | github Mauritius On Fri, Apr 3, 2020 at 12:34 AM Chris Angelico wrote: > > You can mess with anything on a module if you subclass ModuleType and > stick your one

[Python-ideas] Re: Changing Package Representation On Shell

This prints modname.__doc__ / help(modname) / inspect.getdoc(modname) with IPython / Jupyter + ipykernel: >>> modname? This prints something like inspect.getsource(modname) >>> modname?? https://ipython.readthedocs.io/en/stable/interactive/python-ipython-diff.html#accessing-help

[Python-ideas] Re: Changing Package Representation On Shell

Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com | github Mauritius On Thu, Apr 2, 2020 at 8:15 PM Andrew Barnert wrote: > > Why should modules break all of that, and be different from strings, > tuples,

[Python-ideas] Re: Changing Package Representation On Shell

On Fri, Apr 3, 2020 at 7:30 AM Abdur-Rahmaan Janhangeer wrote: > > > Kind Regards, > > Abdur-Rahmaan Janhangeer > compileralchemy.com | github > Mauritius > > > On Thu, Apr 2, 2020 at 9:52 PM Brett Cannon wrote: >> >> >> That's what help() is for. The __repr__ is meant to help during development

[Python-ideas] Re: Changing Package Representation On Shell

Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com | github Mauritius On Thu, Apr 2, 2020 at 9:52 PM Brett Cannon wrote: > > That's what help() is for. The __repr__ is meant to help during > development with some

[Python-ideas] Re: Changing Package Representation On Shell

On Thu, Apr 2, 2020 at 8:22 AM Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > Thanks for the snippet, > > Was wondering if given as a package option, > we might display the module's help info. > That's what help() is for. The __repr__ is meant to help during development with some

[Python-ideas] Re: Changing Package Representation On Shell

On Apr 1, 2020, at 23:47, Abdur-Rahmaan Janhangeer wrote: > > Let's say i have a package. > > >>> import package > >>> package > '> > > would it be nice to be able to change the repr of the package to > > >>> package > package something > some message > I don’t think so.

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Thu, Apr 2, 2020 at 6:07 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Christopher Barker writes: > > > The funny thing is, in this thread, while I dont really see the need for > > adding += to StringIO to make a string builder, I kind of like the idea > of > >

[Python-ideas] Re: Changing Package Representation On Shell

Thanks for the snippet, Was wondering if given as a package option, we might display the module's help info. Out of curiosity how did you learn about sys.displayhook? Thanks. Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com | github

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

I'm assuming here that the goal is to make string building easier, better, and/or more discoverable, and that the io.StringIO discussion is just one way to achieve this. For example, I don't think (but maybe I'm wrong) that "must be a file-like object" is a goal here. If that's not the goal,

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Christopher Barker writes: > The funny thing is, in this thread, while I dont really see the need for > adding += to StringIO to make a string builder, I kind of like the idea of > adding += to the File protocol -- for all file-like objects. I like the > compactness of: > > with

[Python-ideas] In defense of TOOWTDI [was: ... StringIO += operator]

Steven D'Aprano writes: > Unfortunately, and with the greatest respect to Tim Peters, in > practice that's not how it is used, *particularly* the "One Way" > kaon, which is almost invariably used as a thought-terminating > cliche. You've done this rant before. It wasn't persuasive then.

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

(Folks, sorry for letting this spam slip through! It was reasonably clever compared to most of the stuff we get :) best, —titus > On Apr 2, 2020, at 12:49 AM, gstindianews.i...@gmail.com wrote: > > ya that's what I also get for quickly whipping something up and not > testing it. Good catch

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

ya that's what I also get for quickly whipping something up and not testing it. Good catch from the end. I found another similar at https://gstindianews.info. But you get the idea - a simple wrapper around a list is going to be way better than a wrapper around StringIO. i jayesh

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Here's a very readable way to concatenate strings using "+=" on lists: >>> l = [] >>> l += ['abc'] >>> l += ['abc'] >>> l += ['abc'] >>> l += ['abc'] >>> s = ''.join(l) >>> s 'abcabcabcabc' Probably not exactly what Paul had in mind, but it's beginners friendly. The string version, with O(N²)

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Thu, Apr 2, 2020 at 5:58 PM Steven D'Aprano wrote: > > On Thu, Apr 02, 2020 at 03:37:34PM +1100, Chris Angelico wrote: > > On Thu, Apr 2, 2020 at 3:27 PM Steven D'Aprano wrote: > > > Or maybe that's just an argument that no solution is going to solve > > > *every* problem. What do we do about

[Python-ideas] Re: Changing Package Representation On Shell

On Thu, Apr 02, 2020 at 10:44:02AM +0400, Abdur-Rahmaan Janhangeer wrote: > Let's say i have a package. > > >>> import package > >>> package > '> > > would it be nice to be able to change the repr of the package to > > >>> package > package something > some message > > > ? I

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Thu, Apr 02, 2020 at 03:37:34PM +1100, Chris Angelico wrote: > On Thu, Apr 2, 2020 at 3:27 PM Steven D'Aprano wrote: > > Or maybe that's just an argument that no solution is going to solve > > *every* problem. What do we do about people who write this: > > > > buf = f'{buf}{substring}' > >

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Thu, 2 Apr 2020 at 04:59, Steven D'Aprano wrote: > > On Wed, Apr 01, 2020 at 09:25:46PM -0400, Kyle Stanley wrote: > > > While I agree that it's sometimes okay to go outside the strict bounds of > > "only one way to do it" > > The Zen of Python was invented as a joke, not holy writ, and as a

[Python-ideas] Changing Package Representation On Shell

After a question i asked on python-list, Let's say i have a package. >>> import package >>> package '> would it be nice to be able to change the repr of the package to >>> package package something some message ? Thanks! Kind Regards, Abdur-Rahmaan Janhangeer