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 possib
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
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 cod
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 a
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 h
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
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
cert
"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
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 use
"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
> con
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 mult
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
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 exte
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
1.
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
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 py
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, tempora
"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 de
One difference between Java and Python is this: Java bytecodes are, as I
understand it, part of the Java language definition. CPython bytecodes are
intentionally not part of the language at all. Except maybe fore PyPy,
other implementations do not use them. Jython translates Python source to
Terry Reedy wrote:
"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-l
"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...
"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 exten
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 c
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
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
co
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
compileall.py in the l
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'
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 beca
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
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
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 but
31 matches
Mail list logo
