Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
Hi Martin,
Way back on Monday, 21 May 2007, you wrote:
This is an issue to be discussed for Python 2.6. I'm personally
hesitant to have the official build infrastructure deviate
from the layout that has been in-use for so many years, as a lot
of things depend on it.
I don't find the need to have separate object directories convincing:
For building the Win32/Win64 binaries, I have separate checkouts
*anyway*, since all the add-on libraries would have to support
multi-arch builds, but I think they don't.
...
* Re the x64 directory used by the PCBuild8 process. IMO, it makes
sense to generate x64 binaries to their own directory - my expectation
is that cross-compiling between platforms is a reasonable use-case,
and we should support multiple achitectures for the same compiler
version.
See above; I disagree.
[For additional context; the question was regarding where the output
binaries were created for each platform, and specifically if x64 build
should use something like 'PCBuild/x64']
I'm bringing this topic up again as I noticed the AMD64 builds for Python
2.6 create their output in the PCBuild/x64 directory, not directly into the
PCBuild directory. When I raised this with Christian, he also expressed a
desire to be able to cross-compile in the same directory structure and was
unaware of this discussion (but I made him aware of it :)
You made excellent points about how tools currently recognize the PCBuild
directory, and we can't break them, and I agree. I'd like to propose a
compromise that might be able to keep everyone happy.
The main problem I see with all platforms using 'PCBuild' is that in a
cross-compilation scenario, it is impossible for the distutils to determine
the location of the correct Python libraries to link with (stuff in its own
PYTHONHOME is no good; it's for the wrong platform). Obviously, we can
change the distutils so that the location of the correct libraries can be
specified, but that implies all other build systems that currently assume
PCBuild must also change to work in a cross-compilation scenario. While
those external tools *will* work today in a native build on x64, eventually
they may need to be upgraded to deal with cross-compilation - and this means
that all such tools will also be unable to automatically determine the
location of the libraries. They will all need to take the library dir as a
user-specified option, which seems a pain (eg, buildbots would seem to need
site-specific configuration information to make this work). If eventually
all such tools are likely to upgrade, it would be ideal if we can offer them
a way to upgrade so the correct libraries can be determined automatically,
as they can now for native builds.
My compromise proposal is this: Each platform builds in its own directory
(ie, PCBuild/x86_64, PCBuild/x86). Every single build configuration has a
post-build step that copies the result of the build to the PCBuild
directory. We then add an option to the distutils so that a cross-compile
platform can be specified and when it is, to use 'PCBuild/{platform}
instead of PCBuild, and we encourage other tools to use the same directory
should they want to support configure-less cross-compilation (if distutils
on the trunk is not still trying to maintain b/w compat, it should just
*always* look in PCBuild/{platform}, and I'd suggest py3k not bother with
PCBuild at all; build systems will be touched to upgrade to py3k, so that
change isn't painful. But I digress :)
The main advantage of the compromise is that it allows for the status quo to
remain in place - just continue to use separate source trees for each
platform, and only ever build a single platform in each tree, and tools are
free to have ways of specifying which directory should be used. The
official build process need not change. However, it also supports a way to
do cross-compilation in a way that build tools can *automatically* locate
the correct platform's libraries, and this will be particularly useful for
extension authors.
Would something like that be acceptable?
Thanks,
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] PEP: per user site-packages directory
I don't really understand what all this has to do with per user site-packages. Note that the motivation for having per user site-packages was to: * address a common request by Python extension package users, * get rid off the hackery done by setuptools in order to provide this. As such the PEP can also be seen as an effort to enable code cleanup *before* adding e.g. pkg_resources to the stdlib. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 22 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 On 2008-01-21 16:06, Nick Coghlan wrote: Steve Holden wrote: Christian Heimes wrote: Steve Holden wrote: Maybe once we get easy_install as a part of the core (so there's no need to find and run ez_setup.py to start with) things will start to improve. This is an issue the whole developer community needs to take seriously if we are interested in increasing take-up. setuptools and easy_install won't be included in Python 2.6 and 3.0: http://www.python.org/dev/peps/pep-0365/ Yes, and yet another release (two releases) will go out without easy access to the functionality in Pypi. PEP 365 is a good start, but Pypi loses much of its point until new Python users get access to it out of the box. I also appreciate that resource limitations are standing in the way of setuptools' inclusion (is there something I can do about that?) Just to hammer the point home, however ... Have another look at the rationale given in PEP 365 - it isn't the resourcing to do the work that's a problem, but the relatively slow release cycle of the core. By including pkg_resources in the core (with the addition of access to pure Python modules and packages on PyPI), we would get a simple, stable base for Python packaging to work from, and put users a single standard command away from the more advanced (but also more volatile) features of easy_install and friends. Cheers, Nick. ___ 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] PEP: per user site-packages directory
At 04:42 PM 1/22/2008 +0100, M.-A. Lemburg wrote: I don't really understand what all this has to do with per user site-packages. Note that the motivation for having per user site-packages was to: * address a common request by Python extension package users, * get rid off the hackery done by setuptools in order to provide this. Setuptools doesn't do any hackery for per-user site-packages, although its documentation does explain how to set up such a thing if you want it: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation http://peak.telecommunity.com/DevCenter/EasyInstall#mac-os-x-user-installation Meanwhile, note that having per-user site-packages directories doesn't eliminate the need to be able to have PYTHONPATH directories treated as site directories, which is hasn't been discussed at all. As such the PEP can also be seen as an effort to enable code cleanup *before* adding e.g. pkg_resources to the stdlib. Code cleanup of what? There's nothing in pkg_resources that would change for per-user site package directories, since pkg_resources doesn't do any installation work. ___ 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] PEP: per user site-packages directory
M.-A. Lemburg wrote: I don't really understand what all this has to do with per user site-packages. Note that the motivation for having per user site-packages was to: * address a common request by Python extension package users, * get rid off the hackery done by setuptools in order to provide this. As such the PEP can also be seen as an effort to enable code cleanup *before* adding e.g. pkg_resources to the stdlib. I guess it's a typical case of while you on it, can you fix the rest of the world, too?. People see that I invest a fair share of time into the PEP. So they hope I'm going to solve loosely connected issues, too. Personally I'm not going to solve every security issue with my PEP. I suggest that all the people, who were interested in security, come together and write another PEP. 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
[Python-Dev] misbehaving __contains__
i'm using python to create expression objects, for more intuitive usage as predicates, for instance: x = (Arg(0) 17) (Arg(1).foo == bar) instead of x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), foo), bar)) so now i can use x.eval(18, spam) and get the result of the expression. i'm doing it by overriding all the operators to return expression objects, instead of evaluating the result immediately. it works fine, but i encountered a problem with making __contains__ behave so. it turns out __contains__ coerces the return value into a bool. this might seem logical at first, but is not consistent with the result of the language. consider the following code: class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... f=Foo() f == 8 19 8 in f True as you can see, __eq__ does not coerces the result to bool, so why should __contains__ do that? i've looked at PySequence_Contains in objects/abstract.c, but i can't quite understand where the coercion is made. is because the function is typed as int? if so, i believe it should either be changed to PyObject, or have cmp_outcome (in ceval.c) not use this API directly, and rather return the result as it is returned from __contains__. i see no reason it should behave differently than __eq__ and the rest of comparison operators. -tomer ___ 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] misbehaving __contains__
My guess is that results from the bottom of cmp_outcome (ceval.c), The default case handles the PyCmp_EQ case via PyObject_RichCompare, which might not return Py_True or Py_False. But 'in' is handled inside the switch and is subject to the final statements: v = res ? Py_True : Py_False; Py_INCREF(v); return v Though, IANAPydev. C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tomer filiba Sent: Tuesday, January 22, 2008 11:27 AM To: python-dev@python.org Subject: [Python-Dev] misbehaving __contains__ i'm using python to create expression objects, for more intuitive usage as predicates, for instance: x = (Arg(0) 17) (Arg(1).foo == bar) instead of x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), foo), bar)) so now i can use x.eval(18, spam) and get the result of the expression. i'm doing it by overriding all the operators to return expression objects, instead of evaluating the result immediately. it works fine, but i encountered a problem with making __contains__ behave so. it turns out __contains__ coerces the return value into a bool. this might seem logical at first, but is not consistent with the result of the language. consider the following code: class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... f=Foo() f == 8 19 8 in f True as you can see, __eq__ does not coerces the result to bool, so why should __contains__ do that? i've looked at PySequence_Contains in objects/abstract.c, but i can't quite understand where the coercion is made. is because the function is typed as int? if so, i believe it should either be changed to PyObject, or have cmp_outcome (in ceval.c) not use this API directly, and rather return the result as it is returned from __contains__. i see no reason it should behave differently than __eq__ and the rest of comparison operators. -tomer ___ 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/cmason%40vcentertainme nt.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
Re: [Python-Dev] misbehaving __contains__
The issue is that the sq_contains slot is defined as returning an int, while the tp_richcompare slot is defined as returning a PyObject *. Your first opportunity for changing this will be Py3k. Please submit a patch! On Jan 22, 2008 11:26 AM, tomer filiba [EMAIL PROTECTED] wrote: i'm using python to create expression objects, for more intuitive usage as predicates, for instance: x = (Arg(0) 17) (Arg(1).foo == bar) instead of x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), foo), bar)) so now i can use x.eval(18, spam) and get the result of the expression. i'm doing it by overriding all the operators to return expression objects, instead of evaluating the result immediately. it works fine, but i encountered a problem with making __contains__ behave so. it turns out __contains__ coerces the return value into a bool. this might seem logical at first, but is not consistent with the result of the language. consider the following code: class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... f=Foo() f == 8 19 8 in f True as you can see, __eq__ does not coerces the result to bool, so why should __contains__ do that? i've looked at PySequence_Contains in objects/abstract.c, but i can't quite understand where the coercion is made. is because the function is typed as int? if so, i believe it should either be changed to PyObject, or have cmp_outcome (in ceval.c) not use this API directly, and rather return the result as it is returned from __contains__. i see no reason it should behave differently than __eq__ and the rest of comparison operators. -tomer ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] #! magic
On 2008-01-20 19:30, Christian Heimes wrote:
Yet another python executable could solve the issue, named pythons as
python secure.
/*
gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread
-Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o pythons2.6
pythons.c libpython2.6.a
*/
#include Python.h
int main(int argc, char **argv) {
/* disable some possible harmful features */
Py_IgnoreEnvironmentFlag++;
Py_NoUserSiteDirectory++;
Py_InteractiveFlag -= INT_MAX;
Py_InspectFlag -= INT_MAX;
return Py_Main(argc, argv);
}
$ ./pythons2.6
Python 2.6a0 (:59956M, Jan 14 2008, 22:09:17)
[GCC 4.2.1 (Ubuntu 4.2.1-5ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
import sys
sys.flags
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=-2147483647, interactive=-2147483647, optimize=0,
dont_write_bytecode=0, no_user_site=1, no_site=0, ingnore_environment=1,
Is this a copypaste error or a typo in the code ^ ?
tabcheck=0, verbose=0, unicode=0)
To make this even more secure, you'd have to package this up
together with a copy of the stdlib, but like mxCGIPython does
(or did... I have to revive that project at some point :-):
http://www.egenix.com/www2002/python/mxCGIPython.html
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 22 2008)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] misbehaving __contains__
On Jan 22, 2008 1:26 PM, tomer filiba [EMAIL PROTECTED] wrote: class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... f=Foo() f == 8 19 8 in f True There are many places in the C implementation where a slot returns an int rather than a PyObject. There other replies in this thread seem to support altering the signature of the slot to return a PyObject. Is this setting a precedent that _all_ slots should return a PyObject? Consider the following third behavior: class foo(object): ... def __len__(self): ... return 'foo' ... x = foo() len(x) Traceback (most recent call last): File stdin, line 1, in module TypeError: an integer is required -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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] misbehaving __contains__
On Jan 22, 2008 3:46 PM, Daniel Stutzbach [EMAIL PROTECTED] wrote: On Jan 22, 2008 1:26 PM, tomer filiba [EMAIL PROTECTED] wrote: class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... f=Foo() f == 8 19 8 in f True There are many places in the C implementation where a slot returns an int rather than a PyObject. There other replies in this thread seem to support altering the signature of the slot to return a PyObject. Is this setting a precedent that _all_ slots should return a PyObject? Consider the following third behavior: class foo(object): ... def __len__(self): ... return 'foo' ... x = foo() len(x) Traceback (most recent call last): File stdin, line 1, in module TypeError: an integer is required Possibly. I guess it depends on the use case. It would be nice to research this more, e.g. figure out how much code needs to be changed to make each of these possible changes, and how likely there will be a use case. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] misbehaving __contains__
[Daniel Stutzbach] There are many places in the C implementation where a slot returns an int rather than a PyObject. There other replies in this thread seem to support altering the signature of the slot to return a PyObject. Is this setting a precedent that _all_ slots should return a PyObject? I hope not. One cost of these hypergeneralizations is that it makes Python slower. Also, it makes it harder to write code when you can no longer count on simple predicates to return either True or False. [tomer filiba] i see no reason it should behave differently than __eq__ and the rest of comparison operators The rest of the equality operators were a special case to allow rich comparisons which were needed to implement some vector arithmetic idioms. It was thought that those use case had enough benefit to pay for the negative impacts: * making the language more complex * slowing everything down a bit. * complicating the underlying implementation * making the language more difficult to learn (rich operators are harder than cmp) Does making __contains__ return a PyObject have use cases that are worth those costs? It is reminiscent of the ill-fated proposals to overrride 'and', 'or', 'is', and 'is not'. A couple more questions about the proposal: If __contains__ returns 17 in Tomer's example, what would 8 not in f return? And, would we lose the nice relationship expressed by: for elem in container: assert elem in container It looks like changing the semantics would introduce some weirdness. Raymond ___ 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] misbehaving __contains__
On Jan 22, 2008 5:40 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: [Daniel Stutzbach] There are many places in the C implementation where a slot returns an int rather than a PyObject. There other replies in this thread seem to support altering the signature of the slot to return a PyObject. Is this setting a precedent that _all_ slots should return a PyObject? I hope not. [snip] And, would we lose the nice relationship expressed by: for elem in container: assert elem in container We've already lost this if anyone really wants to break it:: class C(object): ... def __iter__(self): ... return iter(xrange(3)) ... def __contains__(self, item): ... return False ... c = C() for item in c: ... print item in c ... False False False Of course, anyone who decides to break their container classes in that way is asking for trouble. ;-) STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] misbehaving __contains__
And, would we lose the nice relationship expressed by: for elem in container: assert elem in container [Steven Bethard] We've already lost this if anyone really wants to break it:: class C(object): ... def __iter__(self): ... return iter(xrange(3)) ... def __contains__(self, item): ... return False I think this is in the same category as writing a __hash__ that doens't match __eq__. It is explicitly shooting yourself in the foot. I'm more concerned about introducing an API where well-meaning attempts to code a __contains__ override will implicitly shoot the toes off of client code that innocently assumes a somewhat sensible invariant relation between looping over elements in a container and those elements being in the container. The code for sets and frozensets makes that assumption, for example. And, when the code does break, the errors will be darned hard to find. Raymond ___ 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] 2.5.2 release coming up
While the exact release schedule for 2.5.2 is still up in the air, I expect that it will be within a few weeks. This means that we need to make sure that anything that should go into 2.5.2 goes in ASAP, preferably this week. It also means that we should be very careful what goes in though -- and we should be paying particular attention to stability on all platforms! Fortunately it looks like quite a few 2.5 buildbots are green: http://python.org/dev/buildbot/2.5/ I propose that anything that ought to go into 2.5.2 (or should be reviewed for suitability to go into it) should be marked urgent in the tracker, *and* have its version set to (or include) Python 2.5. Also, *nothing* should go into the 2.4 branch any more *except* important security patches. If we're doing a security release, it'll most likely be a source-only release, and it will differ from 2.4.4 only in that it will have some new security patches defined. A reminder: 2.5.2 should only get bugfixes, new features. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] 2.5.2 release coming up
On Jan 22, 2008 8:47 PM, Guido van Rossum [EMAIL PROTECTED] wrote: While the exact release schedule for 2.5.2 is still up in the air, I expect that it will be within a few weeks. This means that we need to make sure that anything that should go into 2.5.2 goes in ASAP, preferably this week. It also means that we should be very careful what goes in though -- and we should be paying particular attention to stability on all platforms! Fortunately it looks like quite a few 2.5 buildbots are green: http://python.org/dev/buildbot/2.5/ I propose that anything that ought to go into 2.5.2 (or should be reviewed for suitability to go into it) should be marked urgent in the tracker, *and* have its version set to (or include) Python 2.5. Also, *nothing* should go into the 2.4 branch any more *except* important security patches. If we're doing a security release, it'll most likely be a source-only release, and it will differ from 2.4.4 only in that it will have some new security patches defined. A reminder: 2.5.2 should only get bugfixes, new features. If Guido felt like dragging the time machine out he would catch his mistake and have that say NO new features. -Brett ___ 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] Rational approximation methods
On Jan 20, 2008 5:54 PM, Tim Peters [EMAIL PROTECTED] wrote: What would be useful is a method that generates (i.e., a generator in the Python sense) the (continued fraction) convergents to a rational. People wanting specific constraints on a rational approximation (including, but not limited to, the two you identified) can easily build them on top of such a generator. I think that's significantly better than my two proposals. (Looking back at the issue, I see that Mark mentioned this possibility too and I just didn't understand him.) I'll plan on implementing that, along with the documentation Mark suggested, unless there are objections. Thanks! Jeffrey ___ 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] 2.5.2 release coming up
Brett Cannon writes: On Jan 22, 2008 8:47 PM, Guido van Rossum [EMAIL PROTECTED] wrote: A reminder: 2.5.2 should only get bugfixes, new features. If Guido felt like dragging the time machine out he would catch his mistake and have that say NO new features. What, nothing about Read my lips? ___ 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] #! magic
M.-A. Lemburg wrote: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=-2147483647, interactive=-2147483647, optimize=0, dont_write_bytecode=0, no_user_site=1, no_site=0, ingnore_environment=1, Is this a copypaste error or a typo in the code ^ ? It's a typo in the code. It's already fixed in the trunk but it was not fixed in the 370 branch. 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
[Python-Dev] why is mmap a builtin module on windows?
Hi all, I want to use the mmap module from python trunk with python 2.5. On Linux I can easily replace it, as it is a dynamically loaded module. On windows it is a builtin module and I fear that I must compile python on windows (or resort to some other ugly hack) What is the reason for mmap being a builtin module? Regards, - Ralf ___ 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
