[Python-ideas] New Web Interface Library For Python?

[Abdur-Rahmaan Janhangeer]

Greetings list,

Here is a nobody proposing something to be picked
up by more skilled people.

The urllib deprecation thread is scary for many reasons.
I cannot just ignore it as it affects me as a noob user.
The security issues makes one think if we continue shipping
something that always has known open holes,
can we sleep soundly?

On the other hand, removing the library completely is
weird. How can programming be fun if it does not
provide 'internet'-related libraries? Heu, should users
start diving into C stuffs?

Mere patches will work but seeing advances in
3rd party libraries, one think that to have something
comparable in the stdlib seems a big task.
A minimal library will work but is it the solution?

I had the opportunity to get some ideas about how
the asyncio implementation went. Folks who had
really amazing async experience helped, even wrote PEPs.
I think setting up a workgroup with experienced
urllib devs and 3rd party library authors will be very productive.
It might be true that the days of batteries included are over,
but, it might be more true that space is cheap, the
world moves fast and more effort is required than it ever was.
The way forward will be deprecating urllib in the real
sense of the world until it's peacefully asleep,
all while introducing a new library.

If we go the minimal version route, it might be a good idea
to introduce umbrella libraries. Libraries maintained by core devs,
but not included in the stdlib. This allows the stdlib
to be leaner, more straight to the point. On installation
python can have a command to install those extra libs.

Proposing this on -ideas as i no longer understand what
the original thread is about. And as stated often,
i avoid this module of the stdlib because of its
non elegent API. If something's no longer used by
normal users, it is maybe the time to do something
complete and elegent about it.

-- A noob Python user who wants his favourite
language to be as good as possible

Q: Why not post on the original thread?
A: Two core ideas in here: viz proposal to set up a
workgroup and the umbrella libraries. As such it feels
more natural to post on -ideas than -dev
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7IE7JO2ZL4KHD53NKOZ2Z526YXLJ6EL4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Generics alternative syntax

[Abdur-Rahmaan Janhangeer]

*Your audience is really in the Typing SIG.  Happy hunting!Steve*

Until I read that line I thought I was reading Typing-SIG

I was saying cool for once I found a discussion I completely follow,
but dear me, it turned out to be -ideas. Btw every time I read discussions
on Typing-SIG I'm like: sigh, what's happening. Else OP is a Typing-SIG
regular.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YNFNU2SJ5FTVOAGUXI4DM5FDWH655VM2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding sortedconatiners to Python or merge the ideas?

[Abdur-Rahmaan Janhangeer]

Oh hoping over to read. I glanced but have not yet read it in details ...

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5RVC3LA3WYVCXCVWJANOZRVFJXXITMHB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding sortedconatiners to Python or merge the ideas?

[Abdur-Rahmaan Janhangeer]

Fine discussion but i wonder how it ended up over there.
Hoping over. Thanks for pointers!

On Thu, 3 Feb 2022, 21:23 Damian Shaw,  wrote:

> This was very recently discussed at length:
> https://mail.python.org/archives/list/python-...@python.org/thread/YB2JD477TKPB2HTXDW6ZXUBD6NFFFHHJ/#YB2JD477TKPB2HTXDW6ZXUBD6NFFFHHJ
>
> Damian (he/him)
>
> On Thu, Feb 3, 2022 at 11:51 AM Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
>> Greetings,
>>
>> This library* seems to be used by many people for some treemap operations.
>> Would it be a good idea to include it in upcoming versions? Leetcode
>> has it by default for the lack of a similar something in Python. I did
>> not check,
>> but it seems other languages cater to structures better.
>>
>> * http://www.grantjenks.com/docs/sortedcontainers/
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Abdur-Rahmaan Janhangeer
>> about <https://compileralchemy.github.io/> | blog
>> <https://www.pythonkitchen.com>
>> github <https://github.com/Abdur-RahmaanJ>
>> Mauritius
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/ASMXPU6O2NDZG32MQFMYQKCKTFKET4FE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VM2QRXQ54FZPSA5UZ7PKNYRDUKBEDLDM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/366R73DELGJGVQP3VAPITXYI77BTTANH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Adding sortedconatiners to Python or merge the ideas?

[Abdur-Rahmaan Janhangeer]

Greetings,

This library* seems to be used by many people for some treemap operations.
Would it be a good idea to include it in upcoming versions? Leetcode
has it by default for the lack of a similar something in Python. I did not
check,
but it seems other languages cater to structures better.

* http://www.grantjenks.com/docs/sortedcontainers/

Thanks.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ASMXPU6O2NDZG32MQFMYQKCKTFKET4FE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Take two -- PEP 671 proof-of-concept implementation

[Abdur-Rahmaan Janhangeer]

> Still interested in coauthors who know CPython internals. That hasn't
changed.

Should have been included since first mail. But this peaked my interest to
dive into
the C source

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CY5OWXHOPNSBTEGLN4YSJIAIO2LRQQ26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

[Abdur-Rahmaan Janhangeer]

Greetings, this use case interests me.

Is anyone interested in coauthoring this with me? Anyone who has

> strong interest in seeing this happen - whether you've been around the
> Python lists for years, or you're new and interested in getting
> involved for the first time, or anywhere in between!
>


Did you find a co-author yet? If not i apply.

Yours,

Abdur-Rahmaan Janhangeer

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TAKOKKIZIKOA27JY6H4QTP5JROY6HENT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making imports callable

[Abdur-Rahmaan Janhangeer]

Just amazing!!!

Noted it down
https://www.pythonkitchen.com/python-making-imports-callable/

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IPYSM4GOOBMAVSHZ774HDKGKS6KNDRWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Making imports callable

[Abdur-Rahmaan Janhangeer]

Sorry not if name == main, basically

if module is being imported:
__file__.callable = True

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7BNX3PATUD3PPMNZGGNZT4AV2RDCHG6L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Making imports callable

[Abdur-Rahmaan Janhangeer]

Greetings list,

Let's say i import module1


import module1

can we do


module1()

straight out of the box?

If not i propose something like

if __name__ == '__main__':
__file__.callable = True

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SENV4MEVA5QW2YFC4WDOY6X2REMX77GM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Abdur-Rahmaan Janhangeer]

Greetings list,

Looking at the examples, I'm not sure how well this would play out
in the context of just using variables, though:

s = a - s
s = a / c
s = a ~ p

By adding such operators we could potentially make math functions
compatible with strings by the way of duck typing, giving some
really weird results, instead of errors.

Well, i think that since everything in Python is an object, this example can
apply to anything. Like you need to put it in context. It's not a problem
per se.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YP2ANQJOZT4N2FREMHFH57M53F6UTFWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Abdur-Rahmaan Janhangeer]

Greetings list,

Just a funny Reddit quote:

(.NET 5 minimal APIs are even easier, and I swear .NET starts
 to feel more like Python to me all the time, especially since
they removed the need for a Main method).

https://www.reddit.com/r/flask/comments/q0u6ci/scaling_flask_apis_for_highthrougput_scenarios/

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6EELSM3GUJBVNYRJLRBVNS77BDTGRLMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Abdur-Rahmaan Janhangeer]

Greetings list,

> I disagree that "it teaches a lot about how Python works" is a good
reason to keep things the way they are. If you applied this principle more
broadly, it would seem to be an argument in favour of complexity in most
situations, that would imply we should keep syntactic sugar to a bare
minimum at all times.

Well, when giving superpowers like the decorator pattern, this is a case
for it. My case is not against syntactic sugar.
My main problem is: "The simplification idea is to coerce Python to use
patterns forged elsewhere."

Like does Python need to provide official support for a main function?

It's best put into Steven's words:

> I don't think it is a good idea to give programmers coming from other
languages the false impression that Python behaves the same as the
language they are familiar with, when it doesn't. The entrypoint to
Python scripts is not main(), it is the top of the module.

eidt: forgot to reply all

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FG2Q3HX2BVIV6MOBKCIU5XPXO6TSMDOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Abdur-Rahmaan Janhangeer]

Greetings list,

I am -1 on this proposition.

I can relate that if name == main is very confusing to teach.
However, it teaches a lot about how Python works.
If you know Python it is very clear. So if it's confusing, you
wrongly taught Python (I myself was in this situation)

The simplification idea is to coerce Python to use patterns forged
elsewhere.
The tools are here if you wish to use it.

But, specifically pointing a pattern for it and adding additional layers to
make it
work is an enforcement of the main function. Something python is not bound
to
and does not need to run.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VHZK76RSXE3WIL2ZJ75WHCZ5OWQPE2QL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constants in Python (constant name binding)

[Abdur-Rahmaan Janhangeer]

Greetings,


On Tue, May 25, 2021 at 8:13 PM Chris Angelico  wrote:

> Remember: The thing that you declare Final will, some day, need to be
> changed. Probably as part of your own test suite (you do have one of
> those, right?). With MyPy, you could tell it not to validate that
> line, or that file. With a naming convention, you can explain the need
> for the change with a comment. How are you going to override the
> language feature?


It might seem that i am trolling, but i am not

> How are you going to override the
language feature?

By just removing the constant keyword?

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4DJWUN63BXFF52TFLPEJ24KTE6SNODUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add support for private variables, methods and functions in Python

[Abdur-Rahmaan Janhangeer]

Greetings,

>  In fact, this is almost a
purely cooperative game.

This sums it up the difference between secrets and the private
use case. I was echoing the  sentiments of the thread. The
mere putting of private does not ensure complete isolation. It's
for developers to understand that they should not directly access
the variable. This highlights the approach of Python that if it's for
humans,
better twerk it for that usecase.

> That's clear evidence of conflict, not cooperation.

The intended use is cooperation. If the consumers wish to go into uncharted
territory, they take their responsibility!

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RHECV4TMCJOW7BBARKET4OSP64BBCJQK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce constant variables in Python

[Abdur-Rahmaan Janhangeer]

Greetings,

Just a light-hearted note, if ever the idea is taken seriously,

variable: constant = 10

seems more pythonic to me.

constant variable = 10 opens the doors for

int x = 5 etc

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S2CTGF562UST4DM22HO7SLZ3EEWG544G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add support for private variables, methods and functions in Python

[Abdur-Rahmaan Janhangeer]

Greetings list,

This whole thread reminds me of a comment of
Miguel Grinberg i remember somewhere when discussing
secrets. Some go for .env some for env variables but he suggested
focusing the attention on not letting people getting access to the
server instead of trying to be clever about hiding secrets.
The whole thread echoes sentiments in the same direction.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B4EF67Q5JFDJGYSIUR6CYVZEPC4QAY2R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings list,

Created thread + summary:

https://discuss.python.org/t/changing-the-theme-of-the-python-docs-styling/8621

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XSPVP7WP3EOPPI3T364YGHWE5JBX6PWH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings list, Julien Palard responded with the following:

















*Hi Abdur,> However, I feel that the style is a bit bland and off putting>
for newcomers. I suggest we consider changing the theme> to a crisper and
cleaner look. I find docs such as Masonite> really enjoyable to
read: https://docs.masoniteproject.com/
<https://docs.masoniteproject.com/>> <https://docs.masoniteproject.com/
<https://docs.masoniteproject.com/>>Glad you asked!Lot of work is currently
being done to enhance the
theme:- https://github.com/python/python-docs-theme/pull/46
<https://github.com/python/python-docs-theme/pull/46>-
https://github.com/python/python-docs-theme/pull/44
<https://github.com/python/python-docs-theme/pull/44>-
https://github.com/python/docs-community/issues/1
<https://github.com/python/docs-community/issues/1>feel free to participate
and help there.*

Since this is news to me and kind of relate to
what we have been discussing here, i'll have to go over and
understand to what extend (beyond responsiveness) the
current work is being done etc.

@Paul Bryan  Django did a refresh of their site 'recently'
https://docs.djangoproject.com/en/3.2/, they contacted someone
who has some design taste.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7ZRT5GVTWYEYISYA5XPNGYKDCQCLZ5UU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Time from someone clever with CSS in Sphinx may be all it takes.

Yes, agree , i am not suggesting other
docs systems but just reconsidering the style.

@Marc indeed raised the question of overall
consistency which i guess will be addressed one
day or the other. As for the wiki besides, look
there are many, many issues in terms of outdated
content.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WLKNFY52PSOQFK5TKPI2APTLDVLO3RSH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

 I can well imagine someone turning away from a language because the docs
felt old or badly styled.


One practical effect of it is people preferring
to read articles on other sites rather than
consult the docs first. One piece of docs that
is greatly explained is the sockets section. The part
i am referring to is in the how to section i think.
But i don't don't think much people read it first
before starting to program.
One site which balances aesthetics and great content
is the RealPython site.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HJJP6VXA7DWBXVP4DGFQ4VH2F3X7D2J6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Found the link i was referring to:
https://psg.com/r.clue.html

quote:

<>

@Rob Cliffe  I was saying that if you don't know
the flashy
terms it's an indication that you come from
a great time. Me myself i find myself no longer
wanting to go deep into networking or the Linux kernel
maybe because i no longer find myself near
the v0 or v1 of things. Why i find a reason to
dig deep is because of curiosity and to really
become good at something. It's not a granted
thing that if you are into computer science you'll
automatically be exposed to the core level.
When you see some new people in the field,
sometimes it makes you wonder why they no
longer take the care to know of fundamental things not taught.

The SaaS term comes not from the circle of
hackers[1].


[1] people who explore and experiment, not crackers or people who carry out
illegal activities
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DSXG7SSPY747EYJYWNKFEHIAEKVVIKUJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Woops i present my excuses list,
it seems english jokes in my country
don't play well overall.

I never intend to insult people nor insinuate
insults. @Rob Cliffe  normally when i have
old friends, i like to joke about how ancient
they are. A dinosaur in tech deserves respect. Like i was reading the other
day about
how the sysadmin changed over time. Some
old sysadmin were in close contact with kernels, compilers etc. Nowadays
due to the expansion of knowledge people don't
learn core topics but focus on the branches.
Maybe i should explain what i mean.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WLRBYRZRCOG5DZAZ3E74VVTCRKNHWT2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

I guess the difference is in a 'clean'
look. I kind of find the docs as a reminder of
some legacy software. The docs looks 'old'
I know it's vague and subjective but maybe
this rings with some more people.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EPBRQITMUOGDYLQJ4UOCXC4RYQSTKPA2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

  I read as far as the 4th sentence:
"Use it for your next SaaS!" [no link atached] What on earth (I wanted
to use a stronger expression) is an SaaS? I'd never heard of it. OK, Google
told we what it stood for, but I don't feel any the wiser.

Oh seems like you are a dinosaur needing some carbon
dating. Many people are interested in launching SaaS nowadays.
I'd say that you come from a different time as nowadays (at least
some times back, there was a SaaS craze) ^^.

I guess you are not much on LinkedIn or some similar platforms

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NSUTYF4HUQZS6K72D5JZPLJNW6CR6C5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

That was an upto the point, precise and deep answer.
Seems a design agency (who are Python programmers
themselves, else they miss a thing or two) might
do a nice job. Maybe what's missing is a design code (set
of rules for headers, links, buttons etc)

Well i subscribed to d...@python.org and waiting for mod approval,
Will raise it over there. Thanks for input.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NBBRICX5KVJBU77QB44MFAZL5KZ44KMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

Interesting, i don't remember getting answers from you
all this time i was posting to this list

Normally you'd expect Mr Chris quipping along these lines:
"Well you can have your *own* version of the docs locally,
just do this and that" or the 'regular' folks posting

> Great softwares are not
distinguished by docs crankiness and
unpleasantness.

That was intended to be humourous but if it hurts, i'm
sorry, next time posting i'll be sure to write a page-full of
respectful content. I withdraw my mail above and rephrase
it below:

Greetings list,

I have been reading the Python docs since long.
I have enjoyed it, it has great pieces of information.
You have how-tos, faqs etc. Really awesome to read.

However, I feel that the style is a bit bland and off putting
for newcomers. I suggest we consider changing the theme
to a crisper and cleaner look. I find docs such as Masonite
really enjoyable to read: https://docs.masoniteproject.com/

I do hope we can advance something along these lines.


Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Fri, Apr 30, 2021 at 10:34 AM Paul Bryan  wrote:

> A recipe to have an idea be marginalized or ignored:
>
> 1. Start by denigrating the work of others with pejoratives like "cranky"
> and "unpleasant".
> 2. Do not provide any support to back such a claim, or call out any
> specific usability issue.
> 3. Imply that the content is deficient, without qualification.
> 4. Point to something that you just seem to like better, without
> comparison.
> 5. (Probably) expect others to implement your idea. Your work here is done.
>
> Paul
>
> On Fri, 2021-04-30 at 10:06 +0400, Abdur-Rahmaan Janhangeer wrote:
>
> Greetings,
>
> A proposal to change the theme of the
> Python docs. Great softwares are not
> distinguished by docs crankiness and
> unpleasantness.
>
> Though what's more important is the
> content, nevertheless it can be made
> more enjoyable to read.
>
> The Masonite docs for example is quite
> nice:
> https://docs.masoniteproject.com/
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about <https://compileralchemy.github.io/> | blog
> <https://www.pythonkitchen.com>
> github <https://github.com/Abdur-RahmaanJ>
> Mauritius
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U4ISS6PKQCZ2E5U2VYFSXJN4V6IWVXGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

A proposal to change the theme of the
Python docs. Great softwares are not
distinguished by docs crankiness and
unpleasantness.

Though what's more important is the
content, nevertheless it can be made
more enjoyable to read.

The Masonite docs for example is quite
nice:
https://docs.masoniteproject.com/

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add venv activate command to the venv modules

[Abdur-Rahmaan Janhangeer]

@Christopher Barker 

You nailed it! I've used the conda activate command many times.
It should in theory be possible in Python

@Chris Angelico 

Yes mere shell commands passing via Py does not work,
maybe  a file way with results in current shell as @M.-A. Lemburg

points out, venv already generates the files. On windows it has an
activate.bat

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Jan 4, 2021 at 9:03 PM Christopher Barker 
wrote:

> I know nothing of the details, but I think the goal is to have the same
> command work (almost) everywhere, yes?
>
> That does not need to be a python script, however. In fact, it's nice if
> activating an environment is as fast as possible so firing up Python to do
> it is less than ideal.
>
> Anyway -- I'd encourage folks to look at conda -- it now provides a conda
> command that can activate on multiple plaatfroms the same way:
>
> conda activate env_name
>
> I don't know how many different shells that works with, but it at least
> hits the big few.
>
> "conda" used to be a python script but I'm pretty sure it's now some kind
> of custom executable that re-directs the commands, and I'm sure is
> different on different platforms.
>
> prior art and all that.
>
> -CHB
>
>
>
>
> On Mon, Jan 4, 2021 at 8:34 AM M.-A. Lemburg  wrote:
>
>> On 04.01.2021 15:45, Chris Angelico wrote:
>> > 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 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 script).
>> >
>> > You can, of course, simply run the Python executable from that venv,
>> > but activation is *by its nature* a shell feature, and will differ by
>> > shell.
>>
>> Something that would work is using the ssh-agent approach to
>> output shell commands which configure the environment:
>>
>> # For bash et al:
>> `python3 -c "print('export TEST=1')"`
>>
>> A new command:
>>
>> `python3 -m venv activate myenv bash`
>>
>> could do the trick.
>>
>> Of course, venv itself could also create the necessary
>> shell files in the bin/ dir. You'd then just need to
>> run:
>>
>> source myenv/bin/activate.sh
>>
>> (this is how virtualenv does this)
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Experts (#1, Jan 04 2021)
>> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
>> >>> Python Product Development ...https://consulting.egenix.com/
>> 
>>
>> ::: We implement business ideas - efficiently in both time and costs :::
>>
>>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>Registered at Amtsgericht Duesseldorf: HRB 46611
>>https://www.egenix.com/company/contact/
>>  https://www.malemburg.com/
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/7MOIJHJFQVVRL7GW4HY6E3V5X2CGHQX6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/447QJQ5XMRFA6TRDZJFDDYB2K4PRA6E4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3NEE5REKHMJATMCLADCXORUZC72JUX2B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add venv activate command to the venv modules

[Abdur-Rahmaan Janhangeer]

You just execute the appropriate shell commands via Python

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Jan 4, 2021 at 7:34 PM Chris Angelico  wrote:

> 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 script).
> >
> > You can, of course, simply run the Python executable from that venv,
> > but activation is *by its nature* a shell feature, and will differ by
> > shell.
> >
> > ChrisA
> >
> > It's somewhat easy
> >
> >
> > def activate_on_linux():
> > sys.subprocess([sys.executable, ...])
> >
>
> Not sure what this means. Can you elaborate?
>
> Also, "Linux" or "Windows" isn't really the thing. It needs to care
> about the shell, not the operating system.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/3BZZX3BTYDUB2P5MFYRYSXCD254HGIU3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R6YW27IV4DBZG5GT566ISXYN2DL6C7LA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add venv activate command to the venv modules

[Abdur-Rahmaan Janhangeer]

Errata: subprocess(['os', 'stuff', ...])

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SWOWJDRIQCCDYNRFLXU34OXNRMAJFXK6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add venv activate command to the venv modules

[Abdur-Rahmaan Janhangeer]

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 script).

You can, of course, simply run the Python executable from that venv,
but activation is *by its nature* a shell feature, and will differ by
shell.

ChrisA

It's somewhat easy


def activate_on_linux():
sys.subprocess([sys.executable, ...])

def activate_on_win():
sys.subprocess([sys.executable, ...])

def activate_on_mac():
sys.subprocess([sys.executable, ...])

def activate_on_solaris():
sys.subprocess([sys.executable, ...])

if sys.platform == linux:
activate_on_linux()

etc

I believe this is used somewhere else in CPython.
Recently sys.executable replaced python

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DCMG6SNAPS3NMQZZT3LDW4O6JQIOEFOK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add venv activate command to the venv modules

[Abdur-Rahmaan Janhangeer]

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

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CRGS2HA4VMVV3V2RAJJZFNZ7IZZCPQ4X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Make for/while loops nameable.

[Abdur-Rahmaan Janhangeer]

Greetings list,

I wonder if the issue should be named as:
introduce absolute break in Python

as if you have 5 nested loops (which you probably should not),
breaking loop_i won't do anything

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U6RIKIPRDCICSF6UGDQOXIDYVCHOYELQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Packaging Apps (Was Adding PyInstaller to the stdlib)

[Abdur-Rahmaan Janhangeer]

Greetings list,

> Then I would suggest starting a new thread,

Long overdue i guess. My view on the topic is like
Mr Moore with the exception that i'm for native
capabilities to be in the stdlib. Since Zipapp does
not seem to go the C-extension route, i propose
a new tool that turn projects into independent executables

This solves the issue of Gui etc etc etc etc etc etc

Mr Moore's mail of Nov 24, 2020 has ton of ideas
and a lot of potential

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HWGQHOKW3IWFYIQ4ILMXNRH2MYSZX2E3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

On Mon, Nov 23, 2020 at 12:44 PM 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 the wild?
>
> I am quite confident that one of the most used, if controversial, Python
> applications in the wild is a zipapp on Linux systems.
>
> http://youtube-dl.org/
>


Zipapps are wildly popular in the forms of derivatives like Shiv archives
and pyex (used by Netfilix), a concrete hint that Zipapps need more works

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/64KEXNRNJ6LTDVAA3MZ3KBX52NDZWLKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PyInstaller funding

[Abdur-Rahmaan Janhangeer]

Greetings,

I suggest:

-- To setup PyInstaller funding via the PSF like the pallets does
can be a first step to something more concrete
-- To let the PSF take over the lib (requires the PSF and your approval)


Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Sun, Nov 22, 2020 at 5:38 PM Hartmut Goebel 
wrote:

> Am 19.11.20 um 10:29 schrieb M.-A. Lemburg:
>
> Since the project appears to be struggling a bit, it may be
> worthwhile having the project owners ask the PSF or major company
> users for a grant.
>
> I tried this without much success.
>
>- The PSF offered to retweet my tweets - antic and no much of a help.
>- Python Software Verband did not even answer (AFAIR)
>- Major companies did not even answer. Those two or three which did
>answer, are not willed to give money.
>
> --
> Regards
> Hartmut Goebel
>
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XOLWIJDEGX3OKDIC5LKEQSJCSX5EWNYL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3526D5SQHYCAJPQFH2BOYP7JROMLDSM3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

> 3. Executables forms other than "single file".
4. Support for C extensions.

@CHB, @Barnwell
I haven't replied in full to a previous email of Mr Moore,
but the no support for C extensions  is a crucial point
for packaging. If the stdlib has to support a packaging tool,
it has to not provide support for C extensions.

It has to do with the nature of Python. The indecisiveness of
to include or not C extensions halted the packaging issue.
Python is very backwards (in terms of packaging) compared
to where it should have been given it's maturity and adoption
index. C is not in the spirit of Python. Currently, the only tool
included in the stdlib for packaging is Zipapps. As such i am 100%
for Zipapps not to include C extensions and to be in a single file.
This is in the spirit of packaging for VM-based languages.
In other words we must enhance Zipapps as far as possible.
The branding of language X runs on billions of devices is as true
as it is for Python. We just have to enhance Zipapp more.

Notes:

- Single files: one must be aware has some severe limitations such
as you cannot pack sqlite dbs and save your changes. You can only
read data. This applies not only for Zipapps but also for .exe and even
jar files. You have to include the path to the resources. This is a
reasonable
choice. This is why many projects has the structure:

folder1/
folder2/
folder3/
main_compressed_entry_point

The resources are expressed as relative paths and the tool, much like
PyInstaller does, gives you your project with codefiles compressed while
keeping such a structure

- C extensions: Everybody is welcomed to find ideas on how to execute C
extensions while maintaining a Zipped state. In the lack of such a solution,
it's better to Zipapps to leave it out.

That's why including the ability to have native executables is a must for
Python.
Python is different from other languages in the sense that for a dynamic
lang, it
has close ties with C which gives it fearful powers.

To sum up:
For pure Py projects, use Zipapps.
For projects including C-extensions use the tool for native executables.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PU3ELETU7ZQXJ4LUE2ECFMQ3KWRXWIY5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings,

Finally 

What about native executables (without PyInstaller)?

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.

On Sun, 22 Nov 2020, 15:30 Hartmut Goebel, 
wrote:

> Hi,
> > What do you think of adding PyInstaller as an official
> > part of CPython? Among the different native exports
> > options, PyInstaller holds a nice track of clean delivery.
>
> PyInstaller maintainer here.
>
> IMHO this is not a good idea. I see no benefit for either the stdlib nor
> for PyInstaller.
>
> --
> Regards
> Hartmut Goebel
>
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MWPOEFLAPEQIKP4BTQCKTRW5OZDTDRQV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

> Use the simpler options until you can't use them. Then use the more
complicated options.

The only thing i don't trust Mr Chris on is packaging. His technical Py
views
are sound and great. I have the impression that concerning packaging the
view
is: we can do with what we have, no need to add more. When enhancing Zipapps
was proposed, if i remember correctly, the view was along the lines of:
"Why Zipapp
when you can double click on a Py file". Now concerning native executables,
the view
runs along the lines of "at least consider Zipapps".

>  I'm just saying that the
default should be to NOT bundle the interpreter, and you only reach
for a native executable if that doesn't work.

I have the impression that everybody talking about native executables here
were talking about an optional way of packaging apps which help people and
not as the preferred, standard and de facto way.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q52PIVXNAGK2II3Y3ZL2Z4EHRBWKFZUH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings all,

> I'm as steadfastly negative about browser apps as Chris A. is
about
native executables.  :-)

I realize this is an unpopular view, but I think the browser is a
terrible app platform.  It provides no user-configurable widget sets, so
every app looks the way the app "designer" came up with, rather than all
apps using a common look and feel.

Just a note here. Using desktop app the Qt framework for example
PyQt or PySide if you wish, provides ways of customising the render
with a simili-css language / restricted Css / undersupported Css. I've
done desktop apps which appear to be as good as browser apps. I
imitated web forms eg. by having only somewhat thick (5px) bottom borders
with white backgrounds.

As for widget sets well, many Qt elements are found to be actually composed
of other elements and as such is no different from say React components.
Though
I'm not sure Python 'applets' would have React components. Point is on
these two points
i don't really find a difference between web and desktop apps.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7DGGSYLZSMXMRV26H4KXLS6OVP6TF6AR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

While waiting to reply in full, just sharing this thread:
https://github.com/linkedin/shiv/issues/32
Shipping the Interpreter with Shiv

Barry Warsaw advocates PyOxidiser which ... requires rust
to be installed on whoever is deploying the app.

The accompanying article
https://www.scylladb.com/2019/02/14/the-complex-path-for-a-simple-portable-python-interpreter-or-snakes-on-a-data-plane/
is an interesting read

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZGXCU4JI2YYKTNGIKV2P64SSYTGCHDR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

Since the thread is revolving around Zipapps,
this thread might be useful:

https://mail.python.org/archives/list/python-ideas@python.org/thread/EMP4PMT7AHUJPLYD2DN4MXKCMGDK3QSO/

The elaboration by Andrew Svetlov gives a full idea of how
PyInstaller works. Not very clean for sure, though i have not
seen other approaches. On the other hands if the use case is
strong enough then it warrants it's use.

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 fundamental assumption about
zipapps:
that they remain zipped! shiv pyz files extract themselves on execution,
 for a myriad of reasons.

Considering the 3 enhancements proposed by Mr Moore, i'd say that
zipapps needs a tidbit twerking to be a great packaging solution.

A successful zip-based packaged format is the JAR (
https://en.wikipedia.org/wiki/JAR_(file_format)).
JSmooth is a tool for converting JARs into EXEs
https://en.wikipedia.org/wiki/JSmooth
Might give some leads

Though this thread suggests adding the natural abilities of turning python
projects into executables, doing so via zipapps is an option i haven't
considered.
And it does not seem like it's for tomorrow.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YB7UILS6ZWZZWTB2EOBQ7X4AEEJV5YLX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

> - Some people, including me, don't think at this point this is a good
idea to integrate PyInstaller in the Python code base.

The maintainer of Py2App said

> FWIW I don’t think that bundling any of these tools with Python is useful
at this time.

Which i overlooked as it was not the maintainer of PyInstaller speaking and
i did not
see any elaborattion

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FEFBAI26YDLC4I3WXN4NZNNPMN5IKDNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Summary up to now:

- Must ask permission to be integrated
- If integrated, tied to CPython's release cycle
- They can ask the PSF for grants
- It would be useful to cooperate on possible changes to CPython and the
packaging landscape to make it easier to write tools like this.
- Consider zipapp
- there could be something in the std-lib that allowed packaging into an
executable but with some limitations
- transforming zipapps into executables
https://docs.python.org/3/library/zipapp.html#making-a-windows-executable

As for Zipapp replacing native executables, well this is not really the
thread for it.

Well i think i'll try to contact the PyInstaller team to see what they say

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Thu, Nov 19, 2020 at 1:29 PM M.-A. Lemburg  wrote:

> Hi Abdur,
>
> On 19.11.2020 10:02, Abdur-Rahmaan Janhangeer wrote:
> > Before asking *us*, you ought to ask what the PyInstaller developers
> > think of the idea of:
> >
> > - relinquishing copyright to the PSF;
> > - operating under the control of the Python core developers and
> steering
> >   council, under their terms;
> > - releasing versions under the schedule of the Python interpreter;
> > - under CPython's rules about backwards compatibility and new
> features;
> >
> >
> > Thank you for your input Mr Steven.
> > If we go along the same lines, i should
> > begin checking whether anyone who replies
> > forms part of the SC or not, whether they
> > have the right or not to reply to this thread etc.
>
> I think you misunderstood Steven's questions.
>
> The PSF requires that contributors sign a contributor agreement for
> any code which goes into the stdlib (or Python in general).
>
> Since PyInstaller is GPLed, it cannot be added to the stdlib
> without the copyright owners giving the PSF permission to relicense
> the code under the PSF license (or any other open source license
> as per the contributor agreement).
>
> Only the copyright owners can make this call.
>
> Note that this does not mean "relinquishing" the copyright as
> Steven put it. The copyright owners keep their copyright. They
> only give permission specifically to the PSF to relicense the
> code.
>
> The other points Steve gave are important as well, since continuing
> the development of PyInstaller within the context of Python's stdlib
> means that they would have adhere to the processes we have for this.
>
> IMO, PyInstaller is a great tool, but adding it to the Python
> stdlib would not necessarily be an advantage, since it's development
> would then be tied to Python's release cycle, which reduces the
> flexibility the maintainers have in e.g. providing fixes quickly.
>
> Since the project appears to be struggling a bit, it may be
> worthwhile having the project owners ask the PSF or major company
> users for a grant.
>
> Cheers,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Nov 19 2020)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EFFD4JEW3KEMGCGTQCP4AOQKDY7FREPQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

> Suppose you distribute a .py script to a million people. Your script is
faulty due to a bug in the Python interpreter or std lib. But you don't
need to do anything to patch your script: you just tell people to
upgrade to the latest version of Python where the bug is fixed. Or you
say nothing at all, and when the user's get their mandatory OS-supported
upgrade, including Python, it fixes itself.

>From experience it's not the only source of bug.
I normally package apps with 3rd party libraries. Libs also can contain
bugs. Then along the same line i can tell people to upgrade the lib to
the desired version. This is true.

However it boils down to whether people want executables or not. The
purpose
many libs exist shows that there is a need for generating native executables
It's up to the developer i guess, how much Python-aware he wants the target
environment to be, considering that he has the ability to tune.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X2SUFEEDM4II2EVNOUR6UK3DDS7UW62R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

>
> Before asking *us*, you ought to ask what the PyInstaller developers
> think of the idea of:
>
> - relinquishing copyright to the PSF;
> - operating under the control of the Python core developers and steering
>   council, under their terms;
> - releasing versions under the schedule of the Python interpreter;
> - under CPython's rules about backwards compatibility and new features;
>

Thank you for your input Mr Steven.
If we go along the same lines, i should
begin checking whether anyone who replies
forms part of the SC or not, whether they
have the right or not to reply to this thread etc.

Next time someone suggests a new feature
i would ask him why are you asking *us*?
ask the core devs as they will sponsor
and they will approve. I asked what you think
as a polite way of introducing the idea for
discussion and not to be taken in the
literal sense.
I combined the proposition and a viable candidate to get a clearer idea of
the proposal.

I like your inputs on the mailing list,
appreciate your presence (you seem
to be a landsmark of the list) but find
them a tidbit too spicy sometimes.
The points you brought forward undoubtedly stands good,
are to be considered, it's the choice of words
i guess.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TJPBNWGRA5FMZWC5TLDDOKQ7ERDYCUNU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

> The purpose of executables is to make it harder to apply bug fix
releases of Python? I thought that was an unwanted side effect.

I think you mis-understood me by me making myself not clear

I mean bundling this library: https://github.com/pyinstaller/pyinstaller
with CPython distributions. Not program executables

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DFF34FEJWZ6JVO2ZWPCB44IHOW2SZJQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,


> What's the advantage of having it as an official part, rather than
remaining a third-party tool?

Easy generation of executables. Installing a version of Python
gives you a complete suite

> Producing native executables is an attractive nuisance. It doesn't
actually prevent people from disassembling your code (many MANY people
seem to think that it does),

The purpose is to create a packed state, not obfuscation.
The ability to just run your program without worrying
about further installation

> it locks in a particular Python version,
it locks in an OS architecture, it locks in everything that you
shouldn't be locking in.

That's the purpose of executables.

> Putting that sort of thing into the standard
library will encourage people to use it when they really shouldn't.

Explanations appreciated

> Also, blessing one particular executable builder means that all others
become second-class citizens. Is PyInstaller so much better than
everything else?

It's quite good:
"PyInstaller freezes (packages) Python applications into stand-alone
executables, under Windows, GNU/Linux, Mac OS X, FreeBSD, Solaris
and AIX. "

This seems a more viable option than creating such a utility from
scratch

> It also would force PyInstaller to be released on exactly the same
cadence as the Python that it comes with. It would be impossible for
PyInstaller to release a hotfix between Python releases, or to add
features and functionality to an already-released Python version.

Same as all other integrated libs, though i do agree that with
executable generators you have to be more careful

Kind Regards,

Abdur-Rahmaan Janhangeer
about | blog
github
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4BACTMBDAKOMVUWFFMT3X244OXZWRM4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Adding PyInstaller to the standard library

[Abdur-Rahmaan Janhangeer]

Greetings list,

What do you think of adding PyInstaller as an official
part of CPython? Among the different native exports
options, PyInstaller holds a nice track of clean delivery.

Instead of the project battling for its survival as any other
project, if the community finds it useful enough, the devs
can get some peace of mind.

The stereotyped idea about languages like Python is that
they don't by default produce executables compared to let's
say Go. Adding the native ability to produce executables can
be a turning point for Python. In the process, PyInstaller might
become even better.

Sure it will need people who are well versed in at least 3 operating
systems to maintain the project. It will add to the testing load but
if it's worth it, it's worth it. Though for a good DevOps team, set up
is not a concern. However, having an executable makes the task easy
as you just ship a final product.

I don't exactly know how executables will interact with the WSGI protocol
but these concerns are for after and is an issue which does not concern
integrating a library per se.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MCIPDY7EJ52VLFKVHR3V724KKZPOWCDG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A new suggestion for Python

[Abdur-Rahmaan Janhangeer]

The dot has recently been used a lot

kotlin:

for loop 0..9

Js:

...array

.= seems cool enough

Btw i saw this on Kotlin's doc, the first time i see a direct reference
from one 'recent' language concerning another.

Kotlin's loops are similar to Python's. for iterates over anything that is
*iterable* (anything that has an iterator() function that provides an
Iterator object), or anything that is itself an iterator:

The for in loop influenced quite some langs which makes me think that the
spirit of Python as well as it's community is curiously awesome.

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BHJDX3VJTJJI6YE63ERNQCUVTH3DMXZQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

On Mon, 21 Sep 2020, 23:45 ,  wrote:

>
> Actually, it conveys in a very plain manner that David Mertz does not
> think your idea is a good one.
> Please stop being so dismissive of others' comments. It does not endear
> you to them.
>

This list is about discussing the idea,
not only stating an opinion. I know
i am not endearing people to me but i
prefer threads to remain short and on
topic which helps projects like these:
https://abdur-rahmaanj.github.io/pyfaq
The lists make great finds but it's more
difficult when many mails which don't
bring value to the discussion are present

I know that taking the pain to write a mail
is an act of great consideration but
maybe i don't have the tact to express
myself as deem ok. 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.

Kind regards,

Abdur-Rahmaan Janhangeer

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J3KVMNOW7IHBZ7NI2EA65SNYPDOTHO7F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

On Mon, 21 Sep 2020, 23:13 David Mertz,  wrote:

> This is a silly proposal with absolutely zero benefit, none that I can
> even see purported in the suggestion itself, let alone in reality.
>

Thank you for your thoughts but i guess
this mail does not add anything new
to the thread nor does it explain what
it intends to convey.

Kind regards,

Abdur-Rahmaan Janhangeer

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6HBKJI5L6A2ACRJYKYVXKYIMDYGJXJV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 10:52 PM David Lowry-Duda 
wrote:

>
> This is very well said. And I'll add that much of this remains in close
> analogy to RFCs.
>
>


>
> > Let's not waste everyone's time for zero benefit. Thanks.
>
> Indeed.
>

Thanks for your input. That's why i said:

> Saying 'Agile is the new gold' twice or twenty times does not effectively
make Agile the new gold.

If someone well said something and you would only +1 it,
it's better not to re-write it.

> I'm good if the thread dies
off without any further input than rebringing what has already been told.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XRCTRPM4Q6YJ2K5HR4NNNPYMOOWW7MNE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

On Mon, Sep 21, 2020 at 10:47 PM Chris Angelico  wrote:
>
>
> (This signature at the TOP of every post is just getting in the way,
> is there any way to move it to the bottom where it belongs?)


I use Gmail and the signature always floats. I don't remember putting it in
that
irritating place. Will try to find the setting that moves signatures after
replies. I manually deleted it in this mail.

>
> At what point does an informational PEP turn into a PAP? For instance,
> PEP 596 is currently "draft" - does that mean it isn't authoritative?

We must ask the one who formulated the wording:

(under consideration)

>
> On the web site, on Stack Overflow, on people's blogs, in published
> printed books, YouTube videos *everywhere*.

That you can't change. Take the Python wiki itself which still
contains PyQt4 which is obsolete by now and which i put on
my list to update it to it's equivalent PyQt5 when and if i get  the
time
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DEIAPRMRFDWHZOYVKFOZNOQ76B5DVGL2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 10:19 PM Chris Angelico  wrote:

> PEPs don't get updated as future requirements cause changes in the
> language. They remain as they were: the proposal. Changing the name
> because of a change in the PEP's metadata seems like a very backwards
> way to do things; among other things, it would lead people to consider
> "PAPs" to be somehow authorative while "PEPs" are not, which would
> leave informational and process PEPs in an awkward situation of being
> neither non-accepted nor accepted,


I referred PEP8, a meta-pep as PAP8 in the first mail itself and should
have
been one of the first tripping lines of the discussion. If such PEPs are
included
under PAPs, the 'authorative' point holds as it should be


>  Additionally, changing the *name* of a document
> means that every reference has to be changed,


I guess you mean on the website itself. It's a nice point which i was
expecting.
As with any change, some changes are expected and if i am not mistaken,
the source is some text documents and updating them means running  a script
over them locally.


> The only advantage you've offered is some relatively weak notion that
> it ceases to be a proposal once it's accepted, and since "PAP" would
> still have the word "Proposal" in it, you're not really even changing
> that.
>

>  All law projects remain law projects. But we
call law projects which has been accepted as law.


>
> Let's not waste everyone's time for zero benefit. Thanks.
>
> ChrisA
> PEP editor who really doesn't feel like trying to support two names
> for the same things
>

If we change even past accepted PEPs it's one name for one thing.
The thread dying off is in itself a sign  that the idea is weak and
does not hold much value. But if someone brings a point that would re-start
the discussion i think it's better to notify him. I'm good if the thread
dies
off without any further input than rebringing what has already been told.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MGYDRF53XW5D3BAZABWOE2LXMQJHCCNP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 10:00 PM Chris Angelico  wrote:

>
> Can you explain to us what we'd gain by having a complete name change
> once a PEP becomes accepted?
>

A proposal means a suggestion. People propose enhancement suggestions.
They were suggestions to the Python committee, but now they have been
accepted, carried forward and executed. They now have become documents
on which the language bases itself. All law projects remain law projects.
But we
call law projects which has been accepted as law.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IRDKE42PLECFNEHIHT25LZKPL74BEFLW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 9:55 PM Barry Scott  wrote:

> No they are saying that PEP and RFC are the same type of thing with the
> same
> type of users.
>

Any person saying this may refer to reasons on this thread saying that they
are not
and then he elaborates why he thinks those reasons are not worth it instead
of only
saying they are effectively like it.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4PDKGHSP2N4RPHZODDGURG2G3VAU6ENE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 9:23 PM Barry Scott  wrote:

>
> This is like RFC that can be draft, accepted or rejected.
> RFC's have not needed to change there names.
> I'd rather not have PEP's change there names either.
>
> As you say there is a Status in the PEP that is clear.
>
> I see that the RFC docs have more info like "obsoleted by"
> and "updated by" info.
>
> I work with RFC's all the time an appreciate the forward and
> backward references. So if I'm working on code that refers to
> an RFC I can check to see if it is still current for example.
>

The 3 last mails have not added much to the discussion.
Pinning down on RFC is like saying we'll give cat the same
food as catfish as they both do seem similar and we have not
found the need to change catfish food since we have been giving
them to catfish. I seem to think that people do read each and every
mail in an ongoing thread to know what has already covered so as
to elaborate and enrich the discussion but i have the impression i am wrong.
Saying 'Agile is the new gold' twice or twenty times does not effectively
make Agile the new gold.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LIR62OAXZLZ6PAE2ZCIKXZ35TUJI3JPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 8:41 PM David Lowry-Duda 
wrote:

> I see no reason why we should think about changing PEPs.
>

Please see first mail in the thread.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T45WB6RNPGPOFLMBJKB2DGWTO23TLLQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about | blog
github
Mauritius

On Mon, Sep 21, 2020 at 12:20 PM Paul Moore  wrote:
>
> On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer
>  wrote:

> >> I know that PEPs have different status as enumerated here
>
> I'm surprised you don't feel that "Rejected" status is worth capturing
> as well. And what about Provisional?

Accepted designates PEPs that have been been implemented and released.
Not as in ''Accepted; may not be implemented yet", even if it was the case, the
case still holds as the dividing line.

> Honestly, if it's not clear from context whether someone is talking
> about an existing language feature (i.e., an accepted PEP) or an open
> proposal (or, for that matter, a proposal that got abandoned, or a
> rejected idea, etc) then they probably aren't explaining themselves
> very clearly anyway. Maybe just ask them to clarify if you don't want
> to check for yourself?

Not always possible if eg in writing or not worth a mail if few
searches can be made
The question does not arise if one can always find it on his own.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5RT3KQYIFG6OA5T53IZRQKQEYCI4NHI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about | blog
github
Mauritius

On Mon, Sep 21, 2020 at 11:46 AM Steven D'Aprano  wrote:
>
> On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:
>
> > > How would this work in practice? After a PEP is accepted, are we
> > > supposed to go back through all the references to it and change them all
> > > to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if
> > > they are unsure whether it is accepted or not?
> >
> >
> > For future PEPs. People have to remember that after PEP x you have PEPs and
> > 'PAP's
>
> No, for future PEPs you will still have to look for "PEP x" as well,
> because they won't be created in the accepted state. So there will be
> discussion of the PEP under "PEP". Most of the discussion will be
> prior to acceptance, so most references will be under "PEP" and
> hardly anything under "PAP".

By future PEPs i mean future PEP naming, Not about PEP referencing


> If you don't look it up, knowing that it is accepted doesn't tell you
> much. Why would I care that PEP 12345 is accepted, if I don't know what
> PEP 12345 is about?

When someone talks about PEP 12345, they give details etc e.g:

> PEP 345 talks about introducing type this and that

unless you are robots, the person will give some background info
but the above though not saying anything wrong does not tell whether
or not it's an accepted PEP, whether you can form further opinions or not

> > > I would expect that, if you know the context of the discussion and the
> > > nature of the PEP, anyone with a good knowledge of Python should be able
> > > to make a good guess of whether it was accepted or not.
> >
> >
> > I quote the first mail:
> >
> > > ... you need to be a PEP historian
>
> Not always. You often just need to know Python.

It depends on what you mean by know

> Surely you can tell the difference between features that are in the
> existing language like nested scopes, the walrus operator, or the
> secrets module, and features that aren't, like the directive operator,
> the list.uniq method, and int for loops, without looking them up?
>
> In my opinion, "accepted versus not accepted" is one of the least
> important and least informative parts of a PEP.

By accepted it means the PEP made a significant change in the
Python language.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GN6KBY5C7FJW6RVEZTMUBCP6XZIKWQ53/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

On Mon, Sep 21, 2020 at 11:13 AM Greg Ewing  wrote:
>
>
> There's precedent for *not* doing that kind of thing.
> "RFC" stands for "Request For Comment", and it stays that
> way long after it has become adopted as a standard!


Maybe they have not thought of doing it and also, request for comments is
like the first mail on python-ideas:

> RFCs cover many aspects of computer networking, including protocols, 
> procedures, programs, and concepts, as well as meeting notes, opinions, and 
> sometimes humor

PEPs are different. They are concrete documents with rationales,
illustrations and now
with sponsors


> Maybe posts to the Python lists could be passed through a
> filter that looks for PEP references and adds information to
> them.
>
> E.g. if someone typed "PEP 9876" into a post it might get
> replaced by "PEP 9876 - Add turboencabulation module to stdlib
> (Rejected)".

It would also be great to add member details like:

Bumble Cee (Core dev)(61 201 karma)

---

[1] https://www.ietf.org/standards/rfcs/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4U3GNPH6OPX5J75QG2BTCJMMEXSF5CHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Sep 21, 2020 at 11:01 AM Steven D'Aprano 
wrote:

> On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:
> > Greeting lists,
> >
> > I am thinking of proposing to name accepted PEPs as PAPs
> > namely: Python Accepted Proposals.
>
> I immediately think of these:
>
> https://www.merriam-webster.com/dictionary/pap
>
> https://www.mayoclinic.org/tests-procedures/pap-smear/about/pac-20394841


**laughs** nice point, it depends on your dictionary:

https://dictionary.cambridge.org/dictionary/english/pap gives
food that is soft and has little taste or as short for paparazzi

Also let's say we found another better replacement, let's see the below
point


> How would this work in practice? After a PEP is accepted, are we
> supposed to go back through all the references to it and change them all
> to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if
> they are unsure whether it is accepted or not?


For future PEPs. People have to remember that after PEP x you have PEPs and
'PAP's

Personally, I don't think that encoding the acceptance status in the ID
> is very useful. There's so much more about the PEP that doesn't get
> encoded in the ID, like *what it is about*. For example, if somebody
> mentioned PEP 450, or PAP 450, to me, I would have no clue what it was,
> and I wrote it! (I had to look it up to see what the number was.)
>

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

I would expect that, if you know the context of the discussion and the
> nature of the PEP, anyone with a good knowledge of Python should be able
> to make a good guess of whether it was accepted or not.


I quote the first mail:

> ... you need to be a PEP historian


> For example,
> Python doesn't have a "directive" statement, so PEP 244 "The directive
> statement" is probably not accepted. But Python does have nested scopes,
> so PEP 227 "Nested Scopes" is probably accepted.


I quote the first mail:

> I know that PEPs have different status as enumerated here
<https://www.python.org/dev/peps/>

There are no PEPs as ' is probably accepted.', the status is enumerated
above


> I don't think that changing the second to PAP 227 adds enough useful
> information to outweigh the nuisance and inconvenience of having two
> ways to refer to PEPs.
>

2 ways for past PEPs and 1 way for future PEPs
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F4HZI4MYX4HJ452K5R6GA2VMVSMIPJP6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Naming Accepted PEPs as PAPs

[Abdur-Rahmaan Janhangeer]

Greeting lists,

I am thinking of proposing to name accepted PEPs as PAPs
namely: Python Accepted Proposals.

Hence if we say PAP8 we know it's an accepted proposal.

Backstory:

I quoted V. Stinner in this
<https://dev.to/abdurrahmaanj/the-zen-of-python-as-related-by-masters-1p9i>
for PEP 608 <https://www.python.org/dev/peps/pep-0608/>, he told me
by the way it was not accepted. This got me thinking that to know
accepted peps on reading or hearing of it without seeing the status,
you need to be a PEP historian. But, if on the other hand you see
PEP 0608, you instantly know it has not been accepted and when
you hear of PAP 561 you know it is an accepted PEP

I know that PEPs have different status as enumerated here
<https://www.python.org/dev/peps/> but at least
such a naming would make a clear distinction.

Curious to hear your thoughts ^^

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MQWM42U3BWLFONQW7JLQHEVDFBMMK3BU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] Re: Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Abdur-Rahmaan Janhangeer]

Threads like these are meaningless, does not provide any learning
value and is nowhere near the single vs double quote thread.

It opens the gap for people who are not concerned about development
jump in the game shifting the focus away while nurturing a culture of thrash
I mean you tend to ignore threads from python-dev and python-ideas which
is not probably why you subscribed in the first place

This is not the first time i am saying that you can fly around the world on
official
Python mailing lists. But it's regrettable that it's the first time i am
seeing people
telling that they should educate others and things like that. It can be
based on the
argument and circle around it but personal attacks are off limit

If this was a Github issue, i don't think you list moderators would have
dragged it
around that much. Worst case scenario, someone would have been pinged and
the issue taken care of. A PR or closing and you are done.

I raised the issue of closing a mail thread before and the impractical
nature of
it was discussed but maybe warnings and continued posting after the warning
results in ban can be enforced

And it's annoying that it got dragged to two mailing lists. I respect
Python people
and i am always eager to follow some C code discussions, deprecating this C
API
etc. It's a new world for me.

Maybe active list members should sign a convention or a vetting process can
be setup
before we can discuss it on the lists. Not ideal but might be useful.

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy <https://compileralchemy.github.io/> | blog
<https://abdur-rahmaanj.github.io/>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Mon, Jun 29, 2020 at 8:11 PM David Mertz  wrote:

> The commit message is simply silly. It introduces numerous contentious and
> false claims that have nothing whatsoever to do with the small wording
> change. It misunderstands how language, culture, history, and indeed white
> supremacism, work.
>
> I would recommend amending the commit message.
>
> The underlying change itself is reasonable, and to my mind a small
> improvement. There was unnecessary specificity in using Strunk and White as
> reference, and not, say, William Zinsser's _On Writing Well_, which is
> almost as well known. In the concrete, it would be exceedingly rare for
> these to provide conflicting advice on a specific code comment.
>
> On Mon, Jun 29, 2020 at 7:34 AM Richard Damon 
> wrote:
>
>> On 6/29/20 6:22 AM, Nathaniel Smith wrote:
>> > and describes the
>> > old text as a "relic", which is another way of saying that the
>> > problems were only there by historical accident, rather than by anyone
>> > intentionally keeping it there.
>>
>> I would say that say that I have seen the term "relic" being used as a
>> 'weaponized' word to imply that the old thing WAS there intentionally as
>> a repressive measure. I am not saying that this usage was intended to be
>> used that way, but just as the old wording was taken as offensive to
>> some due to implication, I can see that message as offensive to others
>> due to implication, all because some people are easy to offend.
>>
>> --
>> Richard Damon
>> ___
>> Python-Dev mailing list -- python-...@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-...@python.org/message/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> Python-Dev mailing list -- python-...@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-...@python.org/message/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B426T6LT3TAFJHDNWBBAEWPTZKAFEM2K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
Mauritius


On Fri, Apr 3, 2020 at 4:04 AM Steven D'Aprano  wrote:

> ...
> Personally, I might make and use a display hood to show the first line
> of a module docstring.
>

That's another idea to make the default repr show a part of the docstring
or a complete customisation ...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WPJCCV57XEUQBDOQR66K6A2ZOEAHTNYQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
Mauritius


On Fri, Apr 3, 2020 at 3:55 AM Steven D'Aprano  wrote:

> 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 didn't remember the name of the hook, but I knew it existed, so I ran
> dir(sys) to get a list of objects in the sys module, then tested it to
> make sure it did what I thought it did.
>

Thanks! Learning some internals is always interesting!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GQXZPIOTG4WSEUDBFNCESZCJZOLFEIW5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
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 implementation here. Nobody’s saying you can’t have
> this because it would be too hard to implement.
>
...
> That’s not about implementation; that’s about the key idea in your
> proposal.
>

Ah ok i misunderstood.


> That’s not an example.
>

Well i meant that there was no known module example if the feature did not
exist yet.


> Show us a module that you’d like to have a custom repr, and show us what
> you’d like that custom repr to be, and show us that it looks good in other
> contexts (a traceback, printing out sys.modules, etc.), or why it’s so good
> in the REPL that it overcomes the cost of being less good in those
> contexts. You may well have examples that are good enough. But if you don’t
> show us your examples, we can only use our own imagination, and obviously
> none of us are imagining anything nearly good enough to be worth it. Which
> is our failure, not yours—but you want this implemented, and if nobody
> backs your proposal because nobody imagines how useful it would be, you’re
> not going to get it.
>

Well it's about having the ability to change the default <'long line where
module is found'>.
I find it ugly as the default representation of a package. If it's the
default, maybe it can be changed/customised.
Same spirit like the repr of an object is <__main__.A object at
0x0048E4D8>, but it can be customised.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MCFLEPRRFYXPR4YNUSPANSEY3CPKT7DK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
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 into sys.modules. However, I'm not going to give you
> the code, because I don't believe in helping people to do bad things
> :) Use help, not repr.
>

 Oh you mean subclassing, modifying then assigning your module to the
modified one.
Well this proposal is about doing it at the time of writing packages.

About the help thing, it's more about customisation, help is an idea
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WLMLUK6SYARWLT332BDU4GD6SOE7BJPN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
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, functions, classes, etc.?
>

python-ideas is for ideas without worrying about implementations unless
it's about some glaring breaking changes


> The str, which you get from print(package), might be a different story. If
> there’s a representation of a module that’s more useful to end users than
> the repr, even if it’s not as good for debugging, the str should use that
> representation. But is there? What would the message be? How would the
> module specify it? And how it would be useful for the end user to see that
> message?
> ...
> I may be misinterpreting something about the goals of your proposal. If
> so, I apologize—but it would really help if you give a real example: some
> known module, what message you think it should include in its repr, where
> you plan to print out that repr, how you’d like to specify it within the
> module source, etc.
>

Well as for example from known module, the proposal is all about
introducing the __repr__ option in modules.
If i understood well it does not seem to exist. As for purpose, well a
friendlier representation of a package.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RMTQAIKNFOZET7HCJY7V5PKEK4WWLLXB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
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 succinct representation of the object (hence why they
> typically have an identifier to help tell equal objects apart). Including
> docstrings and such is not a goal for the repr and would make it no longer
> succinct.
>

This means we have a __repr__ option in packages (Without Steven's snippet
above)?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EIS67LTCZOXC475DKN323NA4XVKMFCCB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

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 <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
Mauritius


On Thu, Apr 2, 2020 at 11:07 AM Steven D'Aprano  wrote:

> 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 don't know, would it be nice? For what purpose? What will the message
> be? Where does the message come from?
>
> The Python shell just prints the repr() of the object. If you want it to
> print something different, you can install a custom display hook:
>
> py> from types import ModuleType
> py> def thingy(obj):
> ... if isinstance(obj, ModuleType):
> ... print("module %s is amazing!" % obj.__name__)
> ... print("...and Python is great!")
> ... else:
> ... print(repr(obj))
> ...
> py> sys.displayhook = thingy
> py> 'hello'
> 'hello'
> py> math
> module math is amazing!
> ...and Python is great!
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RBOUOF6XETNU7XP4ZNAG2YRTVFNYDRW5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HSQR43GXIR4TNONPBF2ACMSBMC6SROQA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Changing Package Representation On Shell

[Abdur-Rahmaan Janhangeer]

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
compileralchemy.com <https://www.compileralchemy.com> | github
<https://github.com/Abdur-rahmaanJ/>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BYMWLKV3EQSKGFXGDW7QGKMRYJTGP346/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Wed, Jan 8, 2020 at 8:08 PM Christopher Barker 
wrote:

>
>
>> Maybe we can have a PYZ directory where the
>> packages for each app are extracted then it's not
>> a global dump but more specific
>>
>
> I'm not sure how that differs from a .shiv directory, which is not global.
>

Just a quick note on that. A global directory has the side effect
mentionned in Shiv's
readme:

>  If you create many utilities with shiv, you may want to occasionally
clean this directory.

As with many packages mixed in, you can have unwanted side-effects. Being
more specific
might be

Shiv/
app1/
package1
app2/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GCPIKGWS7O4CXLBJSPQ42O6Z5Z4T2LHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Thu, Jan 9, 2020 at 10:53 PM Paul Moore  wrote:

> On Thu, 9 Jan 2020 at 18:15, Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
Maybe I'm missing something, but the draft which you link to has a lot of
> discussion of how jar files and apk files work, and their features, but
> almost nothing about what problems people using Python currently have, that
> the proposal could solve. And if I ignore the parts about signing and
> bundling cross-platform dependencies (which I've already said I think you
> should drop until the basics are sorted out) there seems to me to be almost
> nothing left in the way of a concrete proposal.
>
> I'd strongly suggest that you re-formulate your proposal as a series of
> one or more sets of:
>
>   * Description of a problem that Python users currently face
>   * Review of currently available solutions, and how they fall short
>   * Details of what you propose, and how that improves on the current
> options
>
> At the moment, it's very hard to tell what you're actually suggesting, and
> what benefits you think will be gained.
>
> For what it's worth, I agree that the current options for bundling Python
> applications are not ideal. But to move forward, I want to see specifics,
> not just a generalised "things aren't great, we should throw more
> technology at the problem and it will help (somehow)" proposal with no
> actual plan of action.
>
>
Not negative at all, i'm going to do it. Further up in the thread Mr. Barry
Scott proposed the reviewing
of available solutions and further up i put it in the todo list. I'm doing
it, just that there's no way of putting
a Python thread to "stop mode - author addressing issues". As people talk i
think best to reply than them
waiting ^^_
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Y2VMDY3TDWJTTTFOGRTHM6G5VEUF73X3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Thu, Jan 9, 2020 at 3:29 PM Paul Moore  wrote:
>

Thanks Mr. Paul Moore, co-author of PEP441 for contributing
to the discussion. Enchanté, as you say in French 


> But you haven't explained what problem adding metadata would solve.

Writing here at the same time for more points below asking for what
problem adding metadata solves. Well to begin with, the Python community
still views zip archives as mere zip archives. In the Python Be Bold - Draft
thread on the Python list i listed different ways in which zip archives are
being
used in ways that are more than just archives.

I have taken Java as an example (you can refer to the draft here
)
as Python
shares some similarities in having a VM, having bytecodes and being labelled
as a cross-platform language. The draft shows different ways in which we can
improve a mere Zip archive to the level where more ambitious projects might
be built. I have also described the signing mechanism of .jars etc

Having metadata in zip archives is one baby step on using archives as apps.

The current thread being a spinoff of this
 and
that

thread, it is recommended
that before coming to this thread, people go through these threads, see the
conclusions reached on some aspects. Reading this draft by itself raises
many
whys which i'll just copy paste to answer

> You can already bundle (pure Python) dependencies, just use pip
> install --target to place them in a directory alongside your
> application, add some code in your app to set sys.path, and bundle the
> whole lot in a zipapp. Many people do this already. So if what you're
> proposing is to make that process easier, then great, but you're not
> explaining things very well,

<> That's precisely it. Many people
do it which shows that there's a need, many tools have been built
but this proposal proposes to make dependencies bundling 'official',
enabling python to ease the process. As i said earlier:

<>


> And yet again, you haven't explained how these additional features
> will solve problems that users are actually encountering. Sure, it's
> easy to say "security will avoid problems with malicious code" - but
> what specific attacks are people finding to be an issue, and how will
> your proposed solution address them? (You say you're still
> investigating signing - I'd suggest dropping that part of your
> proposal for now if you don't know how it will work yet).

Referring to your below part of "that's your mistake" i think yes
it's a good idea


> There's discussion because no-one can work out what problem you're
> trying to solve, not because your proposal includes a number of
> aspects.

The discussion has been over signing and cross-platforming


> Maybe that was a mistake :-) Start small, and then build on your
> success once the first part is done.

Ok will do!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KRFDTUH547R5ZZF2VBQGFDQ7SH5UJ3KJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Thu, 9 Jan 2020, 12:38 Chris Angelico,  wrote:

>
> So you're offering no real benefits (since you have to be online to
> verify the app), and you pay the price of bundling everything. Great.
>

If you've read the thread, i'm saying i did not
propose a concrete signing solution since i'm
still looking into it. Those were some ideas
that came with Mr. Andrew's discussion


But what's the point? Why not just use pip the way we already can?
>
What is the actual benefit?
>

Those concerns should be addressed to the
author of PEP441

Brilliant. So now every software author has to continually maintain
> the app and monitor all OSes for new releases. What happens if the
> author isn't on it instantly? What if it takes him/her a couple of
> months, or even a year or two, to get around to releasing an update?
>

If we go that route yes, same as an executable
that won't work on a new Mac update

So far, I have seen zero benefits to this zipapp enhancement.


>From reading 3 threads, i get the idea that
you don't see the benefits of bundling
dependencies in a zipapp

- and figure out what problem you're actually solving here.
>

To quote the FaQ:

This proposal is not solving any problem at all
--
This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp
had an aim. This proposal aims at helping zipapp better accompplish it's
aim.

This proposal explores the next level of zipapps. The enhancements are 2
folds:

- Adding meta details
- Bundling dependencies

But i choose to go even further by attempting to
explore security features and exploring the option of
cross-platforming. That's why there is much discussion
over it

I could've played the safe route and just propose
adding meta data and bundle dependencies
producing Os-specific zips.

Nobody has objection to the two above,
there are prototypes with the above
features which work.
Before i forget about the hard questions completely and just propose the
safe part, i wanted to push it as far as i can.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ESFPQKGDNMKAH5MZMW34JXMB4DKIXDF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club | github
Mauritius

On Thu, Jan 9, 2020 at 9:10 AM Andrew Barnert  wrote:
>
> On Jan 8, 2020, at 12:04, Abdur-Rahmaan Janhangeer  
> wrote:
>
> OK, but I don’t see how any scheme that looks like any of the usual ones 
> could be adapted to work.
>
> The whole point of code signing is that I know that you signed the app with a 
> key that nobody else has access to, and nobody has changed the app since then 
> (plus additional stuff, but this is the relevant part). If that new zip B is 
> built on the fly on my machine by normal user software, it can only be signed 
> with a key that’s available to normal user software on my machine. Which 
> includes malicious software that wants to modify and re-sign the zip. (I’m 
> assuming you can’t rely on being online at this point.)

Being online for checking is normally how you do it. Machine-based have the
problems you stated.

Now you'd be asking why dependencies have to be offline while sigining
online. Well pulling dependencies from pip is like a normal python project.
The zip advantage would just be a smaller code base. The app-like idea
is to just run a file, not worrying about dependencies.


> The env idea is to be retained, the thread was
> asking where would the cache directory be located.
>
>
> Why is that a problem? Most platforms have a standard location for putting 
> cache directories. Those that don’t, you just have to use something hardcoded.
>

Just a question. Not saying it's  a problem.

> More importantly, how does your solution make anything easier? Bundling the 
> cache back up into another zipfile and then trying to figure out where that 
> zipfile is

Was proposing the generated zipfile is in the same folder as the
original zipfile

Another idea is to have a cross-platform code-base only zip.
In the info file we can have target os. We need to specify
this only in the case of c-based libs. It will then generate
the required zips bundled with libs for that os.

main zip -> zip for win, zip for mac, zip for linux

> Or maybe it’s fine to not solve it. Mac-specific apps often have to be 
> updated when a new macOS comes out, so if platform-agnostic apps also often 
> have to be updated when a new anything comes out, maybe that’s no big deal?

It's on the software author to ship a new release.

>
>> But there’s a bigger problem than just distribution. Some extension modules 
>> are only extension modules for speed, like numpy. But many are there to 
>> interface with C libraries. If my app depends on PortAudio, distributing the 
>> extension module as wheels is easy, but it doesn’t do any good unless you 
>> have the C library installed and configured on your system.
>
>
> Oh that's a user problem,
>
>
> OK, but it seems like if you’re not solving it, you don’t really have 
> portable apps. An app that can run out of the box on every machine except 
> most Windows systems, or an audio app that runs on every machine but usually 
> only plays audio on Linux, etc., doesn’t seem very portable.
>
> Conda, py2exe, py2app, platforms’ package managers, etc. all do solve this 
> problem. Of course most of them don’t do so in a platform-agnostic way, which 
> makes it a lot easier… But still, why would I want to download the zipapp 
> instead of brew install or downloading a Mac-specific py2app app or something 
> else that will definitely work instead of only maybe working and otherwise 
> punting on it as a user problem that I have to figure out how to solve 
> myself? The fact that I can copy that same zipapp to a Windows box and then 
> figure out how to solve the same user problem on a different platform doesn’t 
> seem like a huge win.

What i'm saying is that while it's true that for
example a lib is for interfacing with a C library
but it's beyond Python to make sure that the
C library is actually present on your machine.
This is a zipapp enancement which is a bundled
format. Native execs on the other hand include in
lots of os-specific stuffs that has no relation
whatsoever with Python.


At this point i need to

- See conda
- Come up with a viable online signing scheme.
According to me machine-based signing is just
not worth it.
- As Mr. Barry Scott suggested, cover the pros and
cons of existing zipapp based solutions
- As Mr. Christopher suggested, i need to come up
with demos. I'll code the demos
.. Of a wheels included zip
.. Of a zip that generates Os-specific zips
.. Of Mr. Andrew's pypi-based zips
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VXXGCJTGHEWOLFTL4DQWIUFZQDCOANY7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] [python-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Thu, 9 Jan 2020, 01:26 Barry Scott,  wrote:

>
>
> Also can we stop cross posting to 2 lists please.
>
> Pick one and keep the thread on it please.
>
> Barry
>

Since @James proposed it some mails back, we've been on python-ideas!


>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/65J4G4ITUQACPQV6UL67CETBUAJWLIS7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 22:08 Andrew Barnert,  wrote:

>
> But that generated zip B doesn’t have a trustable hash on it, so how can
> you execute it?
>

The issue of trust is solved by keys, i did
not propose something concrete as i'm
still looking into a viable scheme

If you keep this all hidden inside the zipapp system, where malicious
> programs can’t find and modify the generated zips, then I suppose that’s
> fine. But at that point, why not just install the wheels inside zip A into
> an auto-generated only-for-zip-A venv cache directory or something, and
> then just run zip A as-is against that venv?
>

The env idea is to be retained, the thread was
asking where would the cache directory be located.

require pretty frequent updates,


Well this proposal goes for dependendency
freezing. When an app is shipped, the packages are not expected to be
updated.
The author can ship another version with updated libs but the end user does
not worry
about packages updates


and it still only lets you run on systems that have wheels for all your
> dependencies.
>
> If you’re already doing an effective “install” step in building zip B out
> of zip A, why not make that step just use a requirements file and download
> the dependencies from PyPI? You could still run zip B without being online,
> just not zip A.
>
> Maybe you could optionally include wheels and they’d serve as a micro-repo
> sitting in front of PyPI, so when you’re dependencies are small you can
> distribute a version that works for 95% of your potential users without
> needing to do anything fancy but it still works for the other 5% if they
> can reach PyPI.
>

If you can have pypi that's just cool, but the
idea of using archives trends towards self-contained
apps

(But maybe it would be simpler to just use the zip B as a cache in the
> first place. If I download Spam.zipapp for Win64 3.9, that’s a popular
> enough platform that you probably have a zip B version ready to go and just
> ship me that, so it works immediately. Now, if I copy that file to my Mac
> instead of downloading it fresh, oops, wrong wheels, so it downloads the
> right ones off PyPI and builds a new zipapp for my platform—and it still
> runs, it just takes a bit longer the first time.


More ideas, did not consider online,
but if we do it's a very nice thing

I’m not sure this is a good idea, but I’m not sure trying to include every
> wheel for every platform is a good idea either…)
>

Maybe as Mr. Christopher says, i must
bring in some demos

But there’s a bigger problem than just distribution. Some extension modules
> are only extension modules for speed, like numpy. But many are there to
> interface with C libraries. If my app depends on PortAudio, distributing
> the extension module as wheels is easy, but it doesn’t do any good unless
> you have the C library installed and configured on your system.


Oh that's a user problem, it's the same as
Twisted requiring some C++ redistribuables
on windows. I got the impression that the name twisted was really well
named as i
found the library to be twisted for installation.
We were in the midst of our usergroup webscraping
presentation when the demo at hand required to install twisted. Some nasty
C++ redistribuable error
showed which slowed down the whole session. But that was a user side
requirement
not a lib side one.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NWN23FFTB646HFHQSRXHMK7PMGHRZJHI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 22:14 Rhodri James,  wrote:

> On 08/01/2020 18:08, many people wrote lots of stuff...
>
> Folks, could we pick one list and have the discussion there, rather than
> on both python-list and python-ideas?  Getting *four* copies of Andrew's
> emails is a tad distracting :-)
>

Choosing python-ideas. Thanks for pointing out.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HSDGI5YIHEYXMITIR5AXGIX4RGN5WN6U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 23:04 Brett Cannon,  wrote:

>
>
>
> That's under-specified. What hash algorithm was used? How are you going to
> specify it?
>

That was a sha256 demo.

But then I can modify the signatures of any of these files by regenerating
> them. Please trust me, this isn't simple to get right, especially if you
> are shipping the hashes with the file if you're trying to protect tampering
> versus just verifying a blip in a download.
>

Well i mentionned that

 The hash
value becomes the checking signature of the zipfile.

Meaning that it's just a structure to easily
verify the integrity of a file in depth. The end
hash becomes the verifying signature but
since we have the individual hashes as well
we can verify which file changed

I did not elaborate on signing as i'm still looking into it

That actually doesn't work. You cannot load an extension module from
> memory; it *must* be from disk so this doesn't solve the extension module
> problem.
>

Oh i mean physically generating another zip on disk (zip B) then executing
it.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3Z2JEB67EULKMNKUD7M5D4Q6GJNS6VUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 21:29 Andrew Barnert,  wrote:

>
> How does this solve the problem? A malicious program that could modify the
> hash inside the info file could even more easily modify the hash at the end
> of the zip.
>
> Existing systems deal with this by recognizing that you can’t prevent
> anyone from hashing anything they want, so you either have to store the
> hashes in a trusted central repo, or (more commonly–there are multiple
> advantages) sign them with a trustable key. If a malicious app modified the
> program and modified the hash, it’s going to be a valid hash; there’s
> nothing you can do about that. But it won’t be the hash in the repo, or
> it’ll be signed by the untrusted author of the malicious program rather
> than the trusted author of the app, and that’s why you don’t let it run.
> And this works just as well for hashes embedded inside an info file inside
> the zip as for hashes appended to the zip.
>

You are right, that's why i said:

 The hash
value becomes the checking signature of the zipfile.

>
Meaning the hash value at the end of the
zipfile becomes the hash by which we
identify the file and against which we check. That is for checking the
integrity of the app.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EQXAC2UYEFXTMF5AXWEE3ICD2NDMUL2V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 02:15 Barry,  wrote:

>
> Have a look at this write up about the horror that is zip file name
> handling.
>
> https://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/
>
> This has been a pain point at work.
>

Since zipapp did not touch the subject, i won't either
unless well, we can clearly come up with a solution.
If you can work out a solution for Python that
would be great!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ABNQEK46XMXGECX7A5IQZR3TQSOLWLXB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Wed, 8 Jan 2020, 11:09 Christopher Barker,  wrote:

>
> But a thought on that -- you may be able to accomplish something similar
> with conda, "conda constructor", and "conda run". -- or a new tool built
> from those. The idea is that the first time you ran your "app", it would
> install its dependencies, and then use them in an isolated environment. But
> if the multiple apps had the same dependencies, they would share them, so
> you wouldn't get major bloat on the host machine.
>

I guess it's time to dig more into anaconda, been
putting it off, will do.

but a wheel is just as big as the installed package (at least a zipped
> version) -- it's essentially the package compressed into a tarball.
>

I really hope C extentions would become redundent someday
in Python, which would make Python development real
Python dev.

The proposal at hand is maybe the best solution to a
hard nut case that most if not all solutions preferred to avoid

But: "Unlike “conventional” zipapps, shiv packs a site-packages style
> directory of your tool’s dependencies into the resulting binary, and then
> at bootstrap time extracts it into a ~/.shiv cache directory."
>

Maybe we can have a PYZ directory where the
packages for each app are extracted then it's not
a global dump but more specific

Why not that route? It would be nice to comment
on what is wrong with Shiv's mode of execution

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XVE37IEQZWN44JN2DVCWI556YAQ6DVSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club | github
Mauritius


On Wed, Jan 8, 2020 at 1:32 AM Brett Cannon  wrote:
>
>
> This would be a packaging detail so not something to be specified in the
stdlib.


Yes, the module opening the zip will look for it

>> - [  ] Signing mechanism
>>
>> Mechanisms can be added to detect the integrity of the app. App hash can
be
>> used to check if the app has been modified and per-file hash can be used
to
>> detect what part has been modified. This can be further enhanced if
needed.
>>
>> - [  ] Protecting meta data
>>
>> Metadata are not protected by basic signing. There existing ways to
protect
>> metadata and beyond [7]
>
>
> This can be tricky because people want signing in specific ways that vary
from OS to OS, case by case. So unless there's a built-in signing mechanism
the flexibility required here is huge.


Let's say we have a simple project

folder/
file.py
__main__.py

The first step is to include in the info file the file name and hashes

file.py: 5f22669f6f0ea1cc7e5af7c59712115bcf312e1ceaf7b2b005af259b610cf2da
__main__.py:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Then by reading the info file and hashing the actual file and comparing,
we can see which file was modified if any.

But now, a malicious program might try to modify the info file
and modify the hash. One way to protect even the metadata is
to hash the entire content

folder/
file.py # we can add those in a folder if needed
__main__.py
   infofile

Then after zipping it, we hash the zipfile then append the hash to the zip
binary

[zipfile binary][hash value]

We can have a zip file and yet another file stating the hash value but
to maintain a single file structure, the one described above is best.

Then when opening the zip file, we start reading upto the hash value. The
hash
value becomes the checking signature of the zipfile.

This forms a base on which more sigining mechanism can be added like
author keys

Since zipfiles are the same across OSes, this kind of approach supposedly
don't pose a problem

> Install the wheels where? You can't do that globally. And you also have
to worry about the security of doing the install implicitly. And now the
user suddenly has stuff on their file system they may not have asked for as
a side-effect which may upset some people who are tight on disk space
(remember that Python runs on some low-powered machines).

Yes, global folders also defeat the spirit.

Using the wheel-included zip (A), we can generate another zip file (B) with
the packages installed. That generated zip file is then executed.
Zip format A solves the problem of cross-platforming.
Normal solutions upto now like use solution B where you can't share
your zips across OSes.

As for space, it's a bit the same as with venvs. Zip format B is the
equivalent
of packages installed in venv.

Venv usage can be a hint as to when to use.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QMCN47RA5ICM3E4JAF4SWZPTOLQEERWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Wed, Jan 8, 2020 at 2:20 AM Barry  wrote:

>
> You are offing up a competitor against python wheels
>

This proposal proposes to inlcude python wheels in the archive


> Py2app, py2exe etc packagers.
>

Native executables are off the plate. This one deals with archive files.
But i
get the idea, thanks! Maybe you wanted to allude to projects like Shiv
<https://github.com/linkedin/shiv/> by
LinkedIn


> Explain the benefits and weaknesses compared to the existing alternatives.
>

There are some projects similar to Shiv, will write a comparison.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UZOTD3G37SP2IR4DJV2EA72YFDKC6EIS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Tue, Jan 7, 2020 at 6:40 AM Christopher Barker 
wrote:

> I’m a bit unclear on how far this goes: is it just a bit more specific
> with more meta-data standards?
>

- More metadata
- Integrity check with hashing
- Protecting the meta data
- Bundling 3rd party packages

Or are you aiming for something that will run without a Python install?
>

Aie aie Mr. Christopher, zipapp requires a Python install

Other issues:
>
> Are you aiming for a bundle that can run on multiple platforms? If so,
> then it’ll have to have a way to bundle multiple compiled extensions and
> select the right ones at runtime.
>

According to the discussion on the Python, Be Bold thread, it became
clear that it will be a pain to generate and will have an unnecessary
size but sure this a most stable idea

Suggesting instead to include wheels. The wheels are installed. The
interpreter looks for packages in that app-specific folder

If this Is essentially just zipapp with the ability to bundle dependencies,
> then you could probably just do some sys.path hackery.
>

Could you please explain more. Thanks?

In any case, thus seems like something you could implement, and then see if
> people find it useful.
>

That's a nice idea to have a working demo. I'm not a security
expert but i'll try!

Anyone interested in this thread can view this tool
<https://github.com/linkedin/shiv> built by LinkedIn which
attempts dependencies bundling.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MTWR253GO6POTUYVXZUTKWZCUFGO7SCA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Tue, 7 Jan 2020, 01:57 Barry Scott,  wrote:

>
>
> Please cover the pro's and con's of the alernatives that have been raised
> as comments
> on this idea, as is usually done for a PEP style document.
>

Thanks, i don't have much experience writing peps and
if i don't bug you may i ask what "alternatives" refer to?

Also beware that zip file format does not include the encoding of the files
> that are in the
> zip file.


For the encoding of the contents, well since we are
packaging python code files, it's handling will be the same
as handling outside the zip file. It's handling is the
same as how zipapp handles things.

This means that for practical purposes only ASCII filenames are portable
> across
> systems. Is this limitation a problem for this proposal?
>

If we are talking about filenames, then i guess
ascii filenames are the way to go as you'd
unnecessarily break things otherwise.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RVGFMDP3PG6TXFQGH7ISRLYM4FS5CO64/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Note: draft simplified

Abstract
==

This extracts aims at proposing enhancements to the generated zipapp
executable

Rationale
===

One area where there remains some difficulty in Python is packaging for
end-user consumption. To that effect either the code is distributed in pure
Python form with installers [1] or native executables are built for each
target
Os [2]. Currently by default, Python does not provide such utilities. This
pro-
posal aims at finalising a Python-specific archive as the default VM exec-
utable built on zipapp.

In simple terms, it proposes to enhance zipapp from plain archive to
app-level
archive.

Advantages of archives
==

Archives provide a great way to publish software that needs to be
distributed as
a single file script but is complex enough to need to be written as a
collection of
modules [3]

You can use archives for tasks such as lossless data compression,
archiving,
decompression, and archive unpacking. [4] Adding capabilities like digital
signing is used to verify integrity and authenticity.

Zip archives as apps


If we are to treat zip archives as app, here are some recommended features

- [x] Main entry point

A main entry point specifies which file to launch. Zipapp already solves
this
problem by either having a __main__.py [5] or specifying the entry point at
the
commandline ENTRYPOINT_MODULE:ENTRYPOINT_FUNCTION [6]

- [  ] App info file

An info file can have info such as author name, archiving date, company name
etc.

- [  ] Signing mechanism

Mechanisms can be added to detect the integrity of the app. App hash can be
used to check if the app has been modified and per-file hash can be used to
detect what part has been modified. This can be further enhanced if needed.

- [  ] Protecting meta data

Metadata are not protected by basic signing. There existing ways to protect
metadata and beyond [7]

 - [x] Pure-Python 3rd party package bundling

In Python, as long as the 3rd party packages are pure-python packages, we
can bundle and use them [6]. The user can maybe just include a
requirements.txt

- [  ] C-based 3rd party packages

Zipapp by default was not meant to include packages at all.

<< The executable zip format is specifically designed for standalone use,
without needing to be installed. They are in effect a multi-file version of
a
standalone Python script >>

Though the previous point shows that this can be done. Now remains the
issue of C-based packages. Distributing wheels might be the answer [8].
A zip archive is supposed to be standalone. A possible  solution might be
to
include wheels and the wheels are installed in a site-packages folder.

When running such an app, the interpreter will check first if the
app-specific
site-packages folder is empty, if not, install the wheels. This provides
package-
freezing ability. The only downside is longer first-run time.

Only specifying packages to be installed is not an option as if you really
want
stand-alone apps, using the internet etc defeats the purpose.

FAQ


Why not a package manager?
---
The zipapp pep was introduced for a reason, for easing the running of
archives.
Maybe the package manager idea came from listening to people talking about
packaging and pex and comparing it with package-managers like homebrew
and concluded that pex and hence zipapp is not worth it and people would
better off not complicate their lives with some zip utility.

This proposal is not solving any problem at all
--
This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp
had an aim. This proposal aims at helping zipapp better accompplish it's
aim.


References

[1] https://pynsist.readthedocs.io/en/latest/

[2] https://www.pyinstaller.org

[3] https://www.python.org/dev/peps/pep-0441/

[4] https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html

[5] https://docs.python.org/3/library/zipapp.html

[6] https://gist.github.com/lukassup/cf289fdd39124d5394513a169206631c

[7] https://source.android.com/security/apksigning

[8] https://pythonwheels.com



Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EMP4PMT7AHUJPLYD2DN4MXKCMGDK3QSO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The "When" Keyword

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Sun, Dec 29, 2019 at 10:45 PM Antoine Rozo 
wrote:


> If I see a "when" keyword in a code, I will think that
> the body will be executed later, when the expression will be true.
>

Do you see an advantage having in such a  case?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TPSRIWVCQCKYZBFNKYM4TUEBU42OSNL4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The "When" Keyword

[Abdur-Rahmaan Janhangeer]

Adding a new keyword automatically assumes breaking code.

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius


On Sun, Dec 29, 2019 at 10:43 PM Nathan  wrote:

> This would break any code that uses “when” as a variable name.
>
> https://github.com/search?l=Python=when=Code
>
> On Sun, Dec 29, 2019 at 11:26 AM Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
>> Greetings list,
>>
>> I was wondering if adding the When keyword is a good idea.
>> Normally every when is theoretically an if as you can't be sure if the
>> event will 100% come to pass.
>>
>> if x == 5:
>> ...
>> else:
>> ...
>>
>> However, we use the when keyword in normal language. When you reach home,
>> phone me. When you pass this avenue, turn right etc. Using it in
>> programming might convey the intent of the programmer.
>>
>> when x == 5:
>> ...
>> else:
>> ...
>>
>> which still sells the idea of maybe if but hints away the expectation of
>> the author.
>>
>> Yours,
>>
>> Abdur-Rahmaan Janhangeer
>> pythonmembers.club <http://www.pythonmembers.club/> | github
>> <https://github.com/Abdur-rahmaanJ>
>> Mauritius
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUSHPYTKLL65V6BUN4MMKKJOXCIKO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZTZ3RHXXB5NWE6FGEIY7U7DBK5DTCMPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] The "When" Keyword

[Abdur-Rahmaan Janhangeer]

Greetings list,

I was wondering if adding the When keyword is a good idea.
Normally every when is theoretically an if as you can't be sure if the
event will 100% come to pass.

if x == 5:
...
else:
...

However, we use the when keyword in normal language. When you reach home,
phone me. When you pass this avenue, turn right etc. Using it in
programming might convey the intent of the programmer.

when x == 5:
...
else:
...

which still sells the idea of maybe if but hints away the expectation of
the author.

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUSHPYTKLL65V6BUN4MMKKJOXCIKO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Archiving Threads / Closing Threads

[Abdur-Rahmaan Janhangeer]

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

On Wed, 4 Dec 2019, 15:16 Rhodri James,  wrote:

>
> Which is a problem because...?
>
> --
> Rhodri James *-* Kynesim Ltd
>

An advantage. If the topic goes round several times, the mods closing the
topic freezes the thread so that the thread does not gets filled with
unnecessary details. Python threads are bit like a plane from Paris bound
for London via direct flight but which sometimes detours through Tokyo and
Manilla. In fact you might ask yourself HOW in the world are you in São
Paulo.

The proposed approached raises some issues such as people opening new
threads etc.

The idea behind is that list threads are gem mines for Python programmers.
If you've followed the thread as it was unspun, that's great. Else if you
are reading the archives, you have to untangle the right thread from a
mess.

Another advantage of the proposed idea might be to make programmers more
responsible by writing what is necessary and as in depth as possible.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RFIWPWFVZZKLCERY5H4MCHUKOG4XYFXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Archiving Threads / Closing Threads

[Abdur-Rahmaan Janhangeer]

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

On Wed, 4 Dec 2019, 07:38 Steven D'Aprano,  wrote:

> What problem are you trying to solve? Are we suffering under a burden of
> pople resurrecting old threads from ten years ago, or even a year ago?
>

Easy digging of threads.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NAAQSW5AOIBIRAZCDYCWQPCTFLQAVC2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Archiving Threads / Closing Threads

[Abdur-Rahmaan Janhangeer]

Ok posted it with the idea than mailman operated on python and the mods
were hackers enough to add functionalities.

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/74Q7J4MRPTDIH23P6DRPSR7N4W4N2MBN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Archiving Threads / Closing Threads

[Abdur-Rahmaan Janhangeer]

I suggest we find a way to close a mail thread. Obviously we can't stop
people from sending mails,  but, like when a mod sees the topic has been
juiced out, he closes the topic which practically means:

if mailman sees mails being sent to a topic closed by a mod, it does not
relay it to the list.

It is normally difficult to say when a topic has been juiced out (the
essentials have been said, with no new inputs). One might close the topic
prematuraly. So, a time-based automatic closing might be better. Example:
After 5 days, a topic is closed. A mod can extend the closing though.

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V4NS5DURPYVOAUJ7Q3A56UTBXPRKLYFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

[Abdur-Rahmaan Janhangeer]

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

On Mon, 2 Dec 2019, 23:55 Guido van Rossum,  wrote:

>
> Also, + is already overloaded enough (numbers, strings, sequences) and we
> don't need yet another, different meaning. The | operator should be known
> to most users from sets (which are introduced before dicts in the official
> Python tutorial).
>
> I don't particularly care about learnability or discoverability in this
> case -- I don't think beginners should be taught these operators as a major
> tool in their toolbox (let them use .update()), and for anyone wondering
> how to do something with a dict without access to the official docs,
> there's always help(dict). The natural way of discovering these would be
> through tutorials, reading of the library docs, or by reading other
> people's code, not by trying random key combinations in the REPL.
>

My feel about that is to favour the + operator. Technically | is better but
mimicking lists, + might sound better. It follows the general trend in Py.

<>

True, fits more of a "Python Tricks" session but sometimes according to the
audiance level it is tempting to just mention it since it's one line away.

<>

*smile*

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PJQLV6UJFUPWJFK4ROR67FJOWMRKBDAL/
Code of Conduct: http://python.org/psf/codeofconduct/