Re: module mailcap to be removed -- how to replace ?

Am Wed, Oct 26, 2022 at 02:47:31PM -0400 schrieb Sandro Tosi: > > Python 3.11 marks "mailcap" for removal in 3.13. The > > documentation speaks about "mimetypes" being a replacement, > > of sorts. > > > > However, I can't really see how "mimetypes" helps in > > replacing the functionality of

module mailcap to be removed -- how to replace ?

Dear list, Python 3.11 marks "mailcap" for removal in 3.13. The documentation speaks about "mimetypes" being a replacement, of sorts. However, I can't really see how "mimetypes" helps in replacing the functionality of "mailcap". Put another way: what is the suggested way of replacing that

Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'

Am Thu, Mar 17, 2022 at 01:00:40PM -0400 schrieb Sandro Tosi: > since it's not the first time you write to this list with a traceback > or error, asking for help, and the answer from here is generally > pretty straight-forward, i'm wondering why you were not able to find > the solution directly?

Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)

On Mon, Oct 15, 2018 at 09:40:27AM +, PICCA Frederic-Emmanuel wrote: > I found in the code a string with a ur'' > > This is the problematic line. > > I do not know if this is a valid string construction. Under Python 2 it is. Under Python 3 it is not. u'test' is valid but

Bug#823141: RFP: timeline -- An application to show events on a timeline

Hi, I have filed an RFP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823141 (I would rather name those WFP - Wish For Packaging, but, oh well) for a Python based timeline application http://thetimelineproj.sourceforge.net Contrary to the report it would need to be named,

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote: > > Ben Finney writes: > > > According to Robert's earlier message, that means the Distutils > > metadata file needs to be not in the application's private directory, > > but in a directory on the

Aw: Re: Python 2, Python 3, Stretch Buster

Also, if I implement new features I am not necessarily going to test them on python3 unless it somehow happens automatically. Running the test suite twice is not much of an option, though, because it already takes a lot of time to run, and doubling the time it takes just means that code is

Re: Python 2 d-d-a proposal

On Wed, Apr 15, 2015 at 04:27:51PM -0400, Paul Tagliamonte wrote: I'd like this to have the endorsement of the team, so, does anyone object to me asking people to not write new tools in Python 2 only (prefer alternative deps or porting), and only use Python 2 in very special curcumstances or

Re: Python 2 d-d-a proposal

With all this desire to drop Python 2 eventually -- there are packages, say gnumed-client, which simply cannot be ported to Python 3 ATM because important dependencies don't exist for Py 3, say pythonX-wxgtk. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD

Re: /usr/bin/django-admin in python-django

On Mon, Jul 21, 2014 at 10:17:20AM +1000, Brian May wrote: Not sure I understand it (that space in ' ''' seems to be important?), I would guess it creates a 3-quotes Python string embedded into a single-quote one: test = ' single-quotes string with: '''3-quotes-string''' embedded into it'

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 07:27:59AM +0200, RKI Andreas wrote: While it is tempting to slip in not strictly needed improvements into a bugfix it is usually - as is quite evident here - a road down which dragons live. Don't. Well, I didn't in the first place (look at 0.3.12 package). But

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote: - modify sys.path inside gnumed.py appropriately (which I disapprove of as it means moving platform specific code from platform specific layers into platform-agnostic Python code) This one is my favorite;

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 03:27:55PM +0200, Josselin Mouette wrote: I also tend to prefer solutions that look more robust, for example against existing PYTHONPATH variables. The rest is a matter of taste. This is (now) the relevant part in /usr/bin/gnumed: # packages which install the GNUmed

Re: [Help] Failed to apply new Python policy to GNUmed packages

That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. Well, you are trying to solve two things at once: 1) make the python -m calling convention work 2) move GNUmed modules to a private location While, yes, this WAS

Re: [Help] Failed to apply new Python policy to GNUmed packages

For what it's worth here is my concluding suggestion in that bug thread: - My suggestion would be: - call gnumed.py with the python -m ... option if that works - this would rid us of that hardcoded path - a great thing - leave modules where they are and GNUmed finds them by

Re: [Help] Failed to apply new Python policy to GNUmed packages

That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. Yes, that's recommended, but it's not a requirement. Anyway, you almost got it! (usr/share is not in PYTHONPATH), so they are not found when you try to import

Re: Problems using python-support

Just to add some information directly from a GNUmed developer: In prinzipe the wrapper script /usr/bin/gnumed does the following python /var/lib/python-support/python2.3/Gnumed/wxpython/gnumed.py This exits with the error message CRITICAL ERROR: Cannot load GNUmed Python modules !