[Python-Dev] Re: Python package funding through command-line
Hey, Thanks for letting me know about the open issue https://github.com/pypa/pip/issues/5970. I got a little confused earlier, I will try to avoid cross-posting in future. Apologies for replying late. Thanks On Thu, Dec 17, 2020, 11:32 PM Brett Cannon wrote: > This mailing list is for the development of Python. Pip development is > primarily discussed at https://discuss.python.org/c/packaging/14. But I > would also check their issue tracker as I believe they already have an > issue open about this (I think it's called `pip thanks`). > > On Thu, Dec 17, 2020 at 8:44 AM wrote: > >> Many open-source developers are committing to several projects, >> developing package (for Python). A fraction of developers might need funds >> for the continuing development of several projects and to pursue >> contributing. Sadly, there is no direct short way for donors to fund python >> package developers. There is no particular function in the python package >> installer(pip) and the site. >> >> A command-line argument(pip3 fund) for listing the funding pages of >> package developer for packages installed by them (global or pyenv), will >> help donors to reach such developers easily. The funding page can be the >> GitHub sponsor page, or PayPal redirect (control of the developer) >> >> Similar implementations include the "npm fund" command. This command >> retrieves information on how to fund the dependencies of a given project, >> released 4-5 months ago which has gained momentum. >> ___ >> Python-Dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/message/6Q5VJEYFJCMTYRZZFKCF5WN4SSHPPZ6N/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JD2XJOZXNJKIKX6ITKVNYBZHTEXOO5GI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-12-18 - 2020-12-25)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7554 ( +0)
closed 46925 (+68)
total 54479 (+68)
Open issues with patches: 3033
Issues opened (49)
==
#42634: Incorrect line number in bytecode for try-except-finally
https://bugs.python.org/issue42634 reopened by nedbat
#42676: zoneinfo uses locale depending functions for parsing
https://bugs.python.org/issue42676 opened by serhiy.storchaka
#42677: Support comments in argparse fromfile_prefix_chars files
https://bugs.python.org/issue42677 opened by nabelekt
#42678: [Enum] _sunder_ methods only looked up in the last Enum class
https://bugs.python.org/issue42678 opened by ethan.furman
#42679: Minor improvement in datetime.timestamp() docs
https://bugs.python.org/issue42679 opened by olvinroght
#42680: unicode identifiers not accessible or assignable through globa
https://bugs.python.org/issue42680 opened by outofculture
#42681: mistake in curses documentation
https://bugs.python.org/issue42681 opened by arbor
#42682: awaiting a wrapped asyncio.Task multiple times gives long, rep
https://bugs.python.org/issue42682 opened by lilydjwg
#42683: asyncio should handle keyboard interrupt while the event loop
https://bugs.python.org/issue42683 opened by paul.moore
#42684: Improvements to documentation for PyUnicode_FS{Converter,Decod
https://bugs.python.org/issue42684 opened by Antony.Lee
#42686: include built-in Math functions in SQLite to 3.35.0 of march 2
https://bugs.python.org/issue42686 opened by Big Stone
#42687: tokenize module does not recognize Barry as FLUFL
https://bugs.python.org/issue42687 opened by esoma
#42688: ctypes memory error on Apple Silicon with external libffi
https://bugs.python.org/issue42688 opened by erykoff
#42690: Aiohttp fails when using intel ax200 wireless card
https://bugs.python.org/issue42690 opened by JasperTecHK
#42692: Build fails on macOS when compiler doesn't define __has_builti
https://bugs.python.org/issue42692 opened by jmr
#42693: "if 0:" lines are traced; they didn't use to be
https://bugs.python.org/issue42693 opened by nedbat
#42694: Failed test_new_curses_panel in test_curses
https://bugs.python.org/issue42694 opened by serhiy.storchaka
#42696: Duplicated unused bytecodes at end of function
https://bugs.python.org/issue42696 opened by nedbat
#42698: Deadlock in pysqlite_connection_dealloc()
https://bugs.python.org/issue42698 opened by hydroflask
#42700: xml.parsers.expat.errors description of codes/messages is flip
https://bugs.python.org/issue42700 opened by goodmami
#42705: Intercepting thread lock objects not working under context man
https://bugs.python.org/issue42705 opened by mhmdkanj
#42707: Python uses ANSI CP for stdio on Windows console instead of us
https://bugs.python.org/issue42707 opened by u36959
#42710: Viewing pydoc API documentation
https://bugs.python.org/issue42710 opened by Faris Chugthai
#42712: Segmentation fault in running ast.literal_eval() with large ex
https://bugs.python.org/issue42712 opened by xxm
#42713: Segmentation fault in running eval() with large expression siz
https://bugs.python.org/issue42713 opened by xxm
#42714: Segmentation fault in running compile() with large expression
https://bugs.python.org/issue42714 opened by xxm
#42715: Segmentation fault in running exec() with large expression siz
https://bugs.python.org/issue42715 opened by xxm
#42716: Segmentation fault in running ast.parse() with large expressio
https://bugs.python.org/issue42716 opened by xxm
#42717: The python interpreter crashed with "_enter_buffered_busy"
https://bugs.python.org/issue42717 opened by xxm
#42719: Eliminate NOPs in the assembler, by emitting zero-width entrie
https://bugs.python.org/issue42719 opened by Mark.Shannon
#42721: Using of simple dialogs without default root window
https://bugs.python.org/issue42721 opened by serhiy.storchaka
#42722: Add --debug command line option to unittest to enable post-mor
https://bugs.python.org/issue42722 opened by Dominik V.
#42724: Change library name when building.
https://bugs.python.org/issue42724 opened by corentin.bolou27
#42725: PEP 563: Should the behavior change for yield/yield from's
https://bugs.python.org/issue42725 opened by BTaskaya
#42727: [Enum] EnumMeta.__prepare__ needs to accept **kwds
https://bugs.python.org/issue42727 opened by ethan.furman
#42728: Typo in documentation: importlib.metadata
https://bugs.python.org/issue42728 opened by sighingnow
#42730: TypeError/hang inside of Time.Sleep() when _thread.interrupt_m
https://bugs.python.org/issue42730 opened by AR-Kareem
#42731: Enhancement request for proxying PyString
https://bugs.python.org/issue42731 opened by Thrameos
#42733: [issue] io's r+ mode truncate(0)
https://bugs.python.org/issue42733 opened by ke2653
[Python-Dev] Enhancement request for PyUnicode proxies
I was directed to post this request to the general Python development community so hopefully this is on topic. One of the weaknesses of the PyUnicode implementation is that the type is concrete and there is no option for an abstract proxy string to a foreign source. This is an issue for an API like JPype in which java.lang.Strings are passed back from Java. Ideally these would be a type derived from the Unicode type str, but that requires transferring the memory immediately from Java to Python even when that handle is large and will never be accessed from within Python. For certain operations like XML parsing this can be prohibitable, so instead of returning a str we return a JString. (There is a separate issue that Java method names and Python method names conflict so direct inheritance creates some problems.) The JString type can of course be transferred to Python space at any time as both Python Unicode and Java string objects are immutable. However the CPython API which takes strings only accepts the Unicode type objects which have a concrete implementation. It is possible to extend strings, but those extensions do not allow for proxing as far as I can tell. Thus there is no option currently to proxy to a string representation in another language. The concept of the using the duck type ``__str__`` method is insufficient as this indices that an object can become a string, rather than "this object is effectively a string" for the purposes of the CPython API. One way to address this is to use currently outdated copy of READY to extend Unicode objects to other languages. A class like JString would be an unready Unicode object which when READY is called transfers the memory from Java, sets up the flags and sets up a pointer to the code point representation. Unfortunately the READY concept is scheduled for removal and thus the chance to address the needs for proxying a Unicode to another languages representation may be limited. There may be other methods to accomplish this without using the concept of READY. So long as access to the code points go through the Unicode API and the Unicode object can be extended such that the actual code points may be located outside of the Unicode object then a proxy can still be achieved if there are hooks in it to decided when a transfer should be performed. Generally the transfer request only needs to happen once but the key issue being that the number of code points (nor the kind of points) will not be known until the memory is transferred. Java has much the same problem. Although they defined an interface class "java.lang.CharacterArray" the actually "java.lang.String" class is concrete and almost all API methods take a String rather than the base interface even when the base interface would have been adequate. Thus just like Python has difficulty treating a foreign string class as it would a native one, Java cannot treat a Python string as native one as well. So Python strings get represented as CharacterArray type which effectively limits it use greatly. Summary: * A String proxy would need the address of the memory in the "wstr" slot though the code points may be char[], wchar[] or int[] depending the representation in the proxy. * API calls to interpret the data would need to check to see if the data is transferred first, if not it would call the proxy dependent transfer method which is responsible for creating a block of code points and set up flags (kind, ascii, ready, and compact). * The memory block allocated would need to call the proxy dependent destructor to clean up with the string is done. * It is not clear if this would have impact on performance. Python already has the concept of a string which needs actions before it can be accessed, but this is scheduled for removal. Are there any plans currently to address the concept of a proxy string in PyUnicode API? ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/BDJAQDPQMVCLCSB3CEM34VPAY666D3M3/ Code of Conduct: http://python.org/psf/codeofconduct/
