Maurice LING [EMAIL PROTECTED] writes:
Python can then have a built-in mechanism to read the description file
and download the source codes and do the standard sudo python
setup.py install to install the library into site-package.
I don't like this - it would make Python depend on sudo being
Maurice LING [EMAIL PROTECTED] writes:
So if C extension API (or whatever that is really called) is stable,
the system admin can just copy all of /sw/lib/python2.3/site-packages
into /sw/lib/python2.4/site-packages and it should work. From what
you've said, it seems that this isn't possible.
Martin v. Löwis wrote:
Maurice LING wrote:
I've emailed to catelog-sig mailing list and is still waiting to hear
something. Currently, I have no idea of the structure of PyPI. I hope I
can hear from them soon and generate some starting points...
Posting questions is not the only way to find
Maurice LING wrote:
Now I understand that Python bytecodes are only dealing with pure python
source codes. However, the same question lies, how can it (set of
bytecodes) be made stable, like Java bytecodes, which are pretty stable?
Perhaps a better question will be, what techniques Java VM
Maurice LING wrote:
technicalities are wrong but situation remains unchanged.
For C modules, it is very likely that new versions of Python
will continue to break the ABI, by changing the layout of
structures.
The most straight-forward way to deal with it as a sysadmin
or user is to install
Maurice LING [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
From a technical perspective, I can accept that .pyc files are private
and temporary. To a certain extend, it does helps development cycle.
Every time I amend my source codes, I just run it without having to
consider
Martin v. Löwis wrote:
Maurice LING wrote:
technicalities are wrong but situation remains unchanged.
For C modules, it is very likely that new versions of Python
will continue to break the ABI, by changing the layout of
structures.
The most straight-forward way to deal with it as a sysadmin
or
Maurice LING [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
So my alternative solution is that PyPI have a mechanism to maintain what
had been installed in the site-package directory and to download the
libraries and install into the new site-package directory...
What do you
Maurice LING wrote:
So if C extension API (or whatever that is really called) is stable, the
system admin can just copy all of /sw/lib/python2.3/site-packages into
/sw/lib/python2.4/site-packages and it should work.
It would be counter-productive to make it stable, as this would render
Terry Reedy wrote:
I doubt anyone disputes that upgrades are more hassle than we would like.
My main point was that freezing CPython's technology is not the solution.
Any other upgrade helper that you can contribute will be welcome.
Terry J. Reedy
So there is no way of releasing a close-source
Martin v. Löwis wrote:
[automatically install a set of packages]
What do you think?
That would certainly be possible. Contributions are welcome.
Regards,
Martin
I've emailed to catelog-sig mailing list and is still waiting to hear
something. Currently, I have no idea of the structure of PyPI. I
Maurice LING wrote:
I doubt anyone disputes that upgrades are more hassle than we would
like. My main point was that freezing CPython's technology is not the
solution. Any other upgrade helper that you can contribute will be
welcome.
So there is no way of releasing a close-source
Maurice LING wrote:
I've emailed to catelog-sig mailing list and is still waiting to hear
something. Currently, I have no idea of the structure of PyPI. I hope I
can hear from them soon and generate some starting points...
Posting questions is not the only way to find answers. The source code
Maurice LING [EMAIL PROTECTED] writes:
I find this part of the story a nuisance, C components in 3rd party
modules... What are the C components compiled into? What are actually
so files?
Shared object files. They're executable code that can be linked into a
program at runtime. Like DLL's on
Maurice LING wrote:
All you have to do is convince the developers to declare the set of
bytecodes fixed, and they'd be stable. I don't think that will be
easy, as it removes one of the methods used to improve the performance
of Python. Since rebuilding the bytecode files is trivial (just invoke
Maurice LING [EMAIL PROTECTED] writes:
All you have to do is convince the developers to declare the set of
bytecodes fixed, and they'd be stable. I don't think that will be
easy, as it removes one of the methods used to improve the performance
of Python. Since rebuilding the bytecode files is
2. The current compilation scheme (compiling to bytecode as and when
it is needed) works well for scripting purposes but is less desirable
in commercial settings. Less distribution happens when it is used
purely for scripting purposes, such as system maintenance or tuning.
The solution with the
Maurice LING [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now I understand that Python bytecodes are only dealing with pure python
source codes.
Then stop blaming (machine-independent) CPython 'bytecodes' for any
problems you have with compiled-to-machine-language C
Maurice LING [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I think backward compatibility is good enough. A Java JAR file compiled
under for JVM 1.2 can still run in JVM 1.4. I don't think anyone will or
can expect forward compatibility, that will require godly powers...
One
Maurice LING [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
So there are currently 7 implementations or variations of the Python
language and you are suggesting I make another one?
Perhaps you missed the winkie ;-)
The Pacman (binary executable) that I played on a 286 a decade
The same *can* be said for some decade-old .py files. Certainly, most
everything written for 2.0 onward still works. The same will also be true
for .pyc files as long as you run them with their corresponding binary and
as long as the binary stills run.
However, .pyc files are private,
Maurice LING [EMAIL PROTECTED] writes:
5. Unstable bytecodes makes updating to a newer version of Python very
tedious and risk breaking old scripts, if they uses C modules.
Unstable bytecodes have nothing to do with these problems. The
current CPython installation process puts the python
Maurice LING [EMAIL PROTECTED] writes:
The idea of having to release the program or library as source files
does ring alarms in many executives in corporate world. Less freezing
the modules (which renders it platform dependent) or using Jython
(which is not possible when C extensions are
What can be done in PYAN is to encourage all 3rd party library
developers to centralize their libraries in it, which I think all will
gladly respond. All that is needed to be deposited in PYAN is a
description file, like the simplest setup.py file. All that is needed
in this description file is
Mike Meyer wrote:
Maurice LING [EMAIL PROTECTED] writes:
The idea of having to release the program or library as source files
does ring alarms in many executives in corporate world. Less freezing
the modules (which renders it platform dependent) or using Jython
(which is not possible when C
Maurice LING wrote:
Hi,
I've been using Python for about 2 years now, for my honours project
and
now my postgrad project. I must say that I am loving it more and more
now. From my knowledge, Python bytecodes are not back-compatible. I
must
say that my technical background isn't strong
I think the OP is confusing three different CPython implementation
features -- bytecodes, marshal format, and C API, all of which change
pretty slowly -- and a MS Windows/C (dis)feature.
CPython bytecodes only concern code written in Python but are mostly not a
concern because recompilation is
It is a nuisance. It's more of a nuisance when third part modules with
'c' components are compiled for the new version of python (a windows
specific problem).
I did find that the last upgrade forced me to evaluate which extensions
I actually used. The answer was 'a few less than I thought'. It
Hi,
I've been using Python for about 2 years now, for my honours project and
now my postgrad project. I must say that I am loving it more and more
now. From my knowledge, Python bytecodes are not back-compatible. I must
say that my technical background isn't strong enough but is there any
good
Maurice LING wrote:
Hi,
I've been using Python for about 2 years now, for my honours project and
now my postgrad project. I must say that I am loving it more and more
now. From my knowledge, Python bytecodes are not back-compatible. I must
say that my technical background isn't strong enough
30 matches
Mail list logo
