Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. Another option is to contact the Advanced Installer vendor and ask for a free license for the Python Software Foundation. This would mean that everybody in the world would still be able to build an installer without CRT, and only PSF would build the official one with CRT bundled. I personally don't see this as a show-stopper (does anyone ever build the .msi besides Martin?). I personally don't have any interest to spend any time on an alternative technology. The current technology works fine for me, and I understand it fully. Everybody in the world is able to build an installer today, also. However, I won't stop anybody else from working a switch to a different technology, either. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
A while ago I contacted Jukka Laurila from the Nokia developer board about IEEE 754 support on S60 phones. The information from Jukka may be useful for future reference. Christian Original Message Subject: Re: Python 2.6/3.0, IEEE 754 floating point semantics and S60 We've been battling with some float problems recently as well in the course of our 2.5 core porting. The principal problem has been imprecise floating point formatting/parsing routines which lead to the unfortunate case of not being able to roundtrip a Python float to string and back bit-exactly. I've been trying to get to the bottom of that problem and so far it seems like the root cause is a poorly written C library. Though on the other hand, no one from Symbian is yet to confirm to me that the software-emulated floating point routines correspond to anything like IEEE 754. Most S60 devices lack floating point hardware. The best guess is that the floating point support is IEEE 754'ish, with imprecise formatting and parsing routines in the standard library. -Jukka On 2.2.2008 3.54, ext Crys @ Developer Discussion Boards This is a message from Crys at Developer Discussion Boards ( http://discussion.forum.nokia.com/forum/index.php ). The Developer Discussion Boards owners cannot accept any responsibility for the contents of the email. To email Crys, you can use this online form: http://discussion.forum.nokia.com/forum/sendmessage.php?do=mailmemberu=187359 This is the message: Hallo jplauril! I'm a Python core developer. Mikko Ohtamaa said that I should contact you about this matter. Mark Dickinson and I are working on several math and floating point related enhancements for Python 2.6 and 3.0. The enhancements include better support for IEEE754 style NaN and INF, C99 math functions and consistent errors and return values across platforms. Can you give use some detailed information about how Nokia's S60 series processes and stores double precision floats? Information about Qtopia would be useful as well. See http://permalink.gmane.org/gmane.comp.python.devel/91591 Your's truly Christian Heimes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
Giovanni Bajo wrote: On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. When installing for all users, pythonxy.dll goes into system32. This, in turn, requires the CRT to be installed globally (which meant into system32 for VS6 and VS7.1, but means using SxS for VS 2008). It's necessary to install it into system32 so that PythonCOM can find it (alternatively, we could now also making it an SxS assembly). VS2008 adds another twist: assembly manifests. As a consequence of this technology, if Python 2.6 is installed just for me on Windows Vista (i.e. the CRT is next to the executable), it just won't work, because the extension modules (.pyd) can't find the CRT. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. I remain skeptical. You replace the need to learn MSI with the need to learn this tool, and not only to work around the limitations of MSI, but also around the limitations of the tool you have chosen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __import__ problems
Python programmers need to dynamically load submodules instead of
top-level modules -- given a string with module hierarchy, e.g.
'foo.bar.baz', access to the tail module 'baz' is required instead
of 'foo'.
Currently, the common hack for that is to use
modname = 'foo.bar.baz' mod = __import__(modname, {}, {}, [''])
This, however, is indeed an undocumented hack and, what's worse,
causes 'baz' to be imported twice, as 'baz' and 'baz.' (with tail
dot). The problem is reported in [1] and the idiom pops up in about
2000 (sic!) lines in Google Code Search [2].
There at least two workarounds:
* the getattr approach documented in [3]
* use __import__(modname, {}, {}, [modname.rsplit(., 1)[-1]])
As both of them are clumsy and inefficient, I created a simple patch
for __import__ [4] that adds yet another argument, 'submodule'
(maybe 'tail_module' would have been more appropriate) that caters
for that particular use case:
__import__('foo.bar.baz') # submodule=False by default
module 'foo' from 'foo/__init__.py'
__import__('foo.bar.baz', submodule=True)
module 'foo.bar.baz' from 'foo/bar/baz.py'
__import__('foo.bar.baz', fromlist=['baz'])
module 'foo.bar.baz' from 'foo/bar/baz.py'
---
While I was doing that, I noticed that the import_module_level()
function that does the gruntwork behind __import__ does not entirely
match the documentation [3].
Namely, [3] states the statement from spam.ham import eggs results in
__import__('spam.ham', globals(), locals(), ['eggs'], -1).
This is incorrect:
__import__('foo.bar', globals(), locals(), ['baz'], -1)
module 'foo.bar' from 'foo/bar/__init__.py'
i.e. 'bar' is imported, not 'baz' (or 'ham' and not 'eggs').
As a matter of fact, anything can be in 'fromlist' (the reason for
the API abuse seen in [2]):
__import__('foo.bar.baz', globals(), locals(),
... ['this_is_a_bug'], -1)
module 'foo.bar.baz' from 'foo/bar/baz/__init__.py'
So, effectively, 'fromlist' is already functioning as a boolean that
indicates whether the tail or toplevel module is imported.
Proposal:
* either fix __import__ to behave as documented:
# from foo.bar import baz
__import__('foo.bar', fromlist=['baz'])
module 'foo.bar.baz' from 'foo/bar/baz/__init__.py'
# from foo.bar import baz, baq
__import__('foo.bar', fromlist=['baz', 'baq'])
(module 'foo.bar.baz' from 'foo/bar/baz/__init__.py',
module 'foo.bar.baq' from 'foo/bar/baq/__init__.py')
and add the 'submodule' argument to support the common
__import__ use case [4],
* or if that is not feasible, retain the current boolean behaviour
and make that explicit by renaming 'fromlist' to 'submodule' (and
require the latter to be a boolean, not a list).
Too bad I couldn't come up with this before, 3.0 would have been a
perfect opportunity to get things right (one way or the other).
---
References:
[1] http://bugs.python.org/issue2090
[2] http://google.com/codesearch?hl=enlr=q=__import__.*%5C%5B%27%27%5C%5D
[3] http://docs.python.org/library/functions.html#__import__
[4] http://bugs.python.org/issue4438
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __import__ problems
Mart Somermaa wrote: There at least two workarounds: * the getattr approach documented in [3] I can't comment on the rest, but the getattr seems overly complicated. If you need just the module, what's wrong with: __import__(modname) modobj = sys.modules[modname] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Thu, Nov 27 08 at 3:58:43PM +0100, Christian Heimes wrote: A while ago I contacted Jukka Laurila from the Nokia developer board about IEEE 754 support on S60 phones. The information from Jukka may be useful for future reference. OK, I want to weigh in here, but first I need a lil disclaimer: I'm a Symbian core developer and theoretically in a position to fix this kind of thing, but I am not speaking in an official capacity and nothing here should be taken to represent Symbian or Nokia etc etc blah blah :) Also, I'm not quite a floating point expert, but have had to deal with various issues in the past, and wrote some of our hardware floating point support code, so the below is my best guesses. We've been battling with some float problems recently as well in the course of our 2.5 core porting. The principal problem has been imprecise floating point formatting/parsing routines which lead to the unfortunate case of not being able to roundtrip a Python float to string and back bit-exactly. I've been trying to get to the bottom of that problem and so far it seems like the root cause is a poorly written C library. The formatting/parsing routines for floats are not imprecise, they just don't print enough digits to make roundtripping work. We only print 15 digits, because that's the most digits we can guarantee to calculate accurately. Working out the 16th and 17th digits requires that you have a higher-than-double-precision intermediate representation, which is not guaranteed, see below. So, I'd like to suggest that poorly written is not true. :) Though on the other hand, no one from Symbian is yet to confirm to me that the software-emulated floating point routines correspond to anything like IEEE 754. Most S60 devices lack floating point hardware. I think I might've actually been the one to receive these queries.. I did try to explain. We should be IEEE 754 compliant. We have a range of tests which attempt to prove this. If someone has a case demonstrating otherwise please let me know and I'll raise an issue. :) Floating point hardware makes it worse, though, not better: ARM's VFP floating point hardware has only single and double precision. Our software implementation uses 64 bit mantissas for intermediates, which is indeed enough to print 17 digits correctly, but on platforms where the VFP is enabled globally, there is no such higher intermediate precision and were we to try and print 17 digits some of them would be wrong. So, I'm not sure that it's actually possible for us to do better; maybe it is, maybe not. The best guess is that the floating point support is IEEE 754'ish, with imprecise formatting and parsing routines in the standard library. IEEE 754 doesn't include string formatting or parsing as far as I know, so I think this is irrelevant to whether we are compliant :) Does *any* standard actually promise that roundtripping will work, or is it just assumed? -- Torne Wuff [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
Torne, Many thanks for your input! IEEE 754 doesn't include string formatting or parsing as far as I know, so I think this is irrelevant to whether we are compliant :) I think IEEE 754 is relevant. :-) There's a section 5.6 in the original 1985 standard that's called something like: Binary - Decimal conversion that covers this. If I'm reading it right (and I'm far from sure that I am), it seems to say that for doubles one has to provide decimal output up to 17 significant digits, but that digits beyond the 17th don't have to be accurate. It also requires that the output is correctly rounded for some subrange of the range of all doubles, and there are weaker accuracy requirements for doubles outside this subrange. I think the updated 2008 version of the standard is somewhat stricter, requiring correct rounding for conversions to and from decimal in all cases. Does *any* standard actually promise that roundtripping will work, or is it just assumed? I believe that roundtripping is a consequence of the 'correct rounding' requirements in IEEE 754-2008, rather than a direct requirement. It might also be a consequence of the weaker IEEE 754-1985 requirements, but I'm not sure. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
Update: it looks like IEEE 754-1985 does require that roundtripping works, at least when the rounding mode is round-to-nearest. From section 5.6 again: When rounding to nearest, conversion from binary to decimal and back to binary shall be the identity as long as the decimal string is carried to the maximum precision specified in Table 2, namely, 9 digits for single and 17 digits for double. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Taint Mode in Python 3.0 RC3
Dear All, I found I needed support for taint mode in python and have done some work to realise this. It's by no means complete at this time, but I'm floating this idea on this group to see how much interest there is. The implementation is pretty simple: - an extra field in PyObject to maintain the taint status - a couple of extra functions __gettaint__() that returns the taint status and __settaint__(value) that sets the taint value, returning the previous status - an additional command-line flag -a and environment variable PYTHONIGNORETAINT that suppress taint checking - a few macros defined in Objects/object.h to support taint management - a new built-in exception, PyExc_TaintError, for reporting operations on tainted objects You can pick up the diff at http://www.cats-muvva.net/software/Python-taint-diff-3.0rc3.tar.bz2 This diff is ONLY for 3.0RC3. Given that I have only a limited understanding of the internals of Python (but it's very clearly written), I'm sure there are some behaviours I've overlooked. I have done very little testing at this point, but, at least, everything compiles! Regards Nicole King (aka CatsMuvva) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
I am not at all a windows person but I have used http://www.dennisbareis.com/makemsi.htm in the past to automate editing and tweaking some MSI files for testing. It can also be used to generate new ones. It looks like it would still require something to generate its own input description. Regardless, just wanted to offer the link so people are aware that it exists. I have no opinion on what actually gets used so long as its automated. -gps On Thu, Nov 27, 2008 at 7:24 AM, Martin v. Löwis [EMAIL PROTECTED]wrote: Giovanni Bajo wrote: On gio, 2008-11-27 at 00:29 +0100, Martin v. Löwis wrote: So, deducing from your reply, this merge module is a thing that allows to install the CRT (and other shared components)? Correct. More generally, a merge module is a something like an MSI library (.a). It includes a set of files and snippets of an installation procedure for them. OK. One question: why CRT doesn't get installed as regular files near to the python executable? That's how I usually ship it, but maybe Python has some special need. When installing for all users, pythonxy.dll goes into system32. This, in turn, requires the CRT to be installed globally (which meant into system32 for VS6 and VS7.1, but means using SxS for VS 2008). It's necessary to install it into system32 so that PythonCOM can find it (alternatively, we could now also making it an SxS assembly). VS2008 adds another twist: assembly manifests. As a consequence of this technology, if Python 2.6 is installed just for me on Windows Vista (i.e. the CRT is next to the executable), it just won't work, because the extension modules (.pyd) can't find the CRT. I proposed an alternatives because I read you saying: The tricky part really is when it breaks (which it does more often than not), in which case you need to understand msi.py, for which you need to understand MSI. Which means that maybe everybody *has tools* to build an installer today, but only a few people have the required knowledge to really do releases on Windows. So I believe that switching to an alternative that doesn't require full understanding of MSI and msi.py would probably low the barrier and allow more people to help you out. I remain skeptical. You replace the need to learn MSI with the need to learn this tool, and not only to work around the limitations of MSI, but also around the limitations of the tool you have chosen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] socket.c, _rbufsize
I've created http://bugs.python.org/issue4448 to track this issue. On Thu, Nov 27, 2008 at 6:50 AM, Kristján Valur Jónsson [EMAIL PROTECTED] wrote: I came across this in socket.c: # _rbufsize is the suggested recv buffer size. It is *strictly* # obeyed within readline() for recv calls. If it is larger than # default_bufsize it will be used for recv calls within read(). What I worry about is the readline() case. Is there a reason why we want to strictly obey it for that function? Note that in the documentation for _fileobject.read() it says: # Use max, disallow tiny reads in a loop as they are very inefficient. The same argument surely applies for readline(). The reason I am fretting about this is that httplib.py (and therefore xmlrpclib.py) specify bufsize=0 when createing their socket fileobjects, presumably to make sure that write() operations are not buffered but flushed immediately. But this has the side effect of setting the _rbufsize to 1, and so readline() calls become very slow. I suggest that readline() be made to use at least defaultbufsize, like read(). Any thoughts? Cheers, Kristján ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __import__ problems
Mart Somermaa wrote:
__import__('foo.bar', globals(), locals(), ['baz'], -1)
module 'foo.bar' from 'foo/bar/__init__.py'
i.e. 'bar' is imported, not 'baz' (or 'ham' and not 'eggs').
You're reading it wrong. 'baz' *is* imported, but 'bar' is returned from
the function call. You will find that the import statement generates
some additional opcodes to then do the assignment statements off the VM
stack.
This is stated explicitly in the documentation of __import__:
Note that even though locals() and ['eggs'] are passed in as
arguments, the __import__() function does not set the local variable
named eggs; this is done by subsequent code that is generated for the
import statement.
And as described later:
when using from spam.ham import eggs, the spam.ham subpackage must be
used to find the eggs variable.
i.e.
from foo.bar import baz
stack top = __import__('foo.bar', globals(), locals(), ['baz'], -1)
baz = stack top.baz
When there are multiple names being imported or an 'as' clause is
involved, I hope the reasons for doing it this way become more obvious:
from foo.bar import baz, bob
stack top = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
baz = stack top.baz
bob = stack top.bob
from foo.bar import baz as bob
stack top = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
bob = stack top.baz
There's a perfectly correct approach documented as part of the
__import__ docs that you referenced in your original email. If
developers decide not to use that approach and use an undocumented hack
instead, they have no right to complain when their code doesn't work
properly.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
All, and not to start flames, but I still do not understand why applink.c isn't included in python's main (conditionally) instead of expecting users, many of them novices, to do the build. ??? One reason is that I don't know what applink is, and why I should care about it. (I may have known in the past, but then I have forgotten since). Yeah, it's been a while for me too. As I recall, OpenSSL, a long while ago stopped, supporting some idiosyncrasies associated with Windows I/O and opted for a cleaner approach, that of requiring developers to link a small file, applink.c, into the app's main. applink.c is provided by the OpenSSL folks. This is a years old issue and while I periodically revisited and confirmed the problem remained (again as late as a month or two ago), all of this is from memory and I cannot tell you version numbers and the like. Before pursuing further, I should do virgin installs and test again. I'll report back my findings in a couple of days, either way. My thanks, Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __import__ problems
Nick Coghlan wrote:
i.e.
from foo.bar import baz
stack top = __import__('foo.bar', globals(), locals(), ['baz'], -1)
baz = stack top.baz
When there are multiple names being imported or an 'as' clause is
involved, I hope the reasons for doing it this way become more obvious:
from foo.bar import baz, bob
stack top = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
baz = stack top.baz
bob = stack top.bob
from foo.bar import baz as bob
stack top = __import__('foo.bar', globals(), locals(), ['baz', 'bob'], -1)
bob = stack top.baz
Thanks for clarifying this! I'd say the current wording of the docs is
non-obvious
in that regard and your examples would be a nice addition to them.
There's a perfectly correct approach documented as part of the
__import__ docs that you referenced in your original email. If
developers decide not to use that approach and use an undocumented hack
instead, they have no right to complain when their code doesn't work
properly.
There's a good reason for the hack -- the documented loop over components
+ getattr is both a bit ugly and inefficient (as is
fromlist=[modname.rsplit(., 1)[-1]]). The variant proposed by Hrvoje
Niksic:
__import__(modname)
mod = sys.modules[modname]
looks more appealing, but comes with the drawback that sys has to be
imported for
that purpose only.
As none of the variants is really in the spirit of Python's zen and the
use case
given a string of dotted module names, import the tail module is
really common,
I'd still say we should go with the flow and provide people what they
need explicitly
(i.e. something in the lines of http://bugs.python.org/issue4438 ) --
and disable
the hack on the same occasion (by the way, is there a reason why both
__import__('foo', fromlist=['invalid']) and __import__('foo',
fromlist=['']) don't raise
an error as of now?). This way the hacks will be eventually fixed in all
those 2000
lines listed in Google Code.
Perhaps 3.1 and 2.7 would be an appropriate chance for that?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Bugbee, Larry wrote: As I recall, OpenSSL, a long while ago stopped, supporting some idiosyncrasies associated with Windows I/O and opted for a cleaner approach, that of requiring developers to link a small file, applink.c, into the app's main. Could it not be linked into the openssl extension module instead? It's already assumed that Python extension modules are linked against the correct version of the runtime for the python.exe being used. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Taint Mode in Python 3.0 RC3
Dear All, Apologies that web site was not working earlier. I believe that I've now fixed it. The patch can still be found at http://www.cats-muvva.net/software/Python-taint-diff-3.0rc3.tar.bz2. CatsMuvva ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Mark Hammond wrote: The only conflict I see here is the requirement to install into \Program Files Doesn't that just mean that if an OEM decides to preinstall it, they need to put it in Program Files? They're at liberty to do that. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Martin v. Löwis wrote: All, and not to start flames, but I still do not understand why applink.c isn't included in python's main (conditionally) instead of expecting users, many of them novices, to do the build. ??? One reason is that I don't know what applink is, and why I should care about it. (I may have known in the past, but then I have forgotten since). Applink is roughly explained at http://www.openssl.org/support/faq.html#PROG2. The matter was discussed about half a year ago but no decision was made. See http://mail.python.org/pipermail/python-dev/2008-March/077424.html applink.c is just a table of integer constants to function pointers. It makes mixing of different CRTs secure. You'll get the idea after reading the file, Martin. A similar approach could be useful for Python, too. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Greg writes: Mark Hammond wrote: The only conflict I see here is the requirement to install into \Program Files Doesn't that just mean that if an OEM decides to preinstall it, they need to put it in Program Files? They're at liberty to do that. I'm not very familiar with the OEM process, but I believe the software is automatically installed after the first boot from MSI files supplied by the OEM partner (so technically, its not pre-installed at all). I don't know enough about how that works to know how easy it would be to override that option during installation - hopefully Gerald will fill us in with more details... [Hrm - looking closer at that HTML link I sent before, it says specifically Per-machine installs must install to Program Files by default in order to pass this test case - that seems pretty clear...] Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
