Package Details: python310 3.10.14-1

Git Clone URL: (read-only, click to copy)
Package Base: python310
Description: Next generation of the python high-level scripting language, version 3.10
Upstream URL:
Licenses: custom
Provides: python
Submitter: soh
Maintainer: soh
Last Packager: soh
Votes: 11
Popularity: 0.43
First Submitted: 2023-05-04 00:47 (UTC)
Last Updated: 2024-03-25 10:43 (UTC)

Dependencies (20)

Required by (12540)

Sources (1)

Latest Comments

1 2 3 Next › Last »

rammiah commented on 2024-03-25 12:52 (UTC)

@soh Thanks for your reply, I have changed to pyenv to manage my python versions, I use a x86_64, amd 6900hx.

soh commented on 2024-03-25 12:20 (UTC) (edited on 2024-03-25 12:21 (UTC) by soh)

@rammiah Hello, but I don't meet this error. Which CPU architecture do you use? I guess you are on non-x86_64?

rammiah commented on 2024-02-20 12:11 (UTC)

I met an error while upgrading:

configure: error:

Unknown float word ordering. You need to manually preset
ax_cv_c_float_words_bigendian=no (or yes) according to your system.

python312 fixed this by

  ./configure ax_cv_c_float_words_bigendian=no \

soh commented on 2024-02-17 11:42 (UTC)

@segFaultCreator Thanks, I've made such modifications.

soh commented on 2024-02-17 11:41 (UTC)

@TiD91 I simply follow suit of the official python package:

segFaultCreator commented on 2024-02-17 08:04 (UTC) (edited on 2024-02-17 08:05 (UTC) by segFaultCreator)

Hey, you can remove xorg-server-xvfb ttf-font dependencies and rempalce the last two lines of the build section by make EXTRA_CFLAGS="$CFLAGS".

Also, you can keep the signature A035C8C19219BA821ECEA86B64E628F8D684696D only as python 3.10 are signed with this one only.

I had to remove the {,.asc} from the source (inspired from the python-39 package), and it finally builds.

TiD91 commented on 2024-01-21 19:24 (UTC)

Why this needs to run xvfb-run?

This doesn't work on my WSL2.

MarsSeed commented on 2023-11-07 14:53 (UTC)

Anyhow, for now, please kindly remove 'python' from provides, just like in other python3* packages that are maintained by @rixx.

See reasoning behind the necessity of this in the comments on python38 page.

MarsSeed commented on 2023-11-07 14:49 (UTC) (edited on 2023-11-07 15:02 (UTC) by MarsSeed)

extra/gcc12 is not for gcc v1.2 but for v12. So that is an example in favor of my point for renaming this package to python3.x or python-3.x.

Originally, I suggested python-3.x, but maybe it would be best to use the python3.x pgkname format, in case other modules would need to be created.

I think the latter would lead to a more immediately recognizable grouping of what name part belongs to where. E.g.:

  • python3.8
  • python3.10
  • python3.13-setuptools
  • python3.8-setuptools57 (python v3.8, setuptools v57)
  • python3.9-pillow9.5 (python v3.9, pillow v9.5)

(Edit: adjusted examples and added two more)

soh commented on 2023-10-10 02:03 (UTC) (edited on 2023-10-10 02:14 (UTC) by soh)

@MarsSeed Thanks for your kind advice. You seem to also send this message to python39 and python38 packages. In my opinion, The python3X naming convention has come to existence for several years. It will make current users surprised and inconvenient if they use yay -Syu to upgrade their system. Also some official packages use naming convention like this too (without the -), e.g.:

We will not expect a python4 in the near future so I guess the three hundred and ten does not hampers the correction interpretation of version too much.

As for the provides field. I think the current one do follows the PKGBUILD on ArchWiki:

An array of additional packages that the software provides the features of (or a virtual package such as cron or sh). Packages providing the same item can be installed side-by-side, unless at least one of them uses a conflicts array. The version that the package provides should be mentioned (pkgver and potentially the pkgrel), in case packages referencing the software require one.

As for whether it is a drop-in replacement, in some sense, it is. It will give users great flexibility to rebuild all python-related packages against this specific version as long as there is no compatibility issues.