Re: [Python-Dev] Evaluated cmake as an autoconf replacement
Hi, On Sun, Mar 29, 2009 at 10:21 AM, Jeffrey Yasskin wrote: > I've heard some good things about cmake — LLVM, googletest, and Boost > are all looking at switching to it — so I wanted to see if we could > simplify our autoconf+makefile system by using it. The biggest wins I > see from going to cmake are: > 1. It can autogenerate the Visual Studio project files instead of > needing them to be maintained separately > 2. It lets you write functions and modules without understanding > autoconf's mix of shell and M4. > 3. Its generated Makefiles track header dependencies accurately so we > might be able to add private headers efficiently. I am switching to cmake with all my python projects, as it is rock solid, supports building in parallel (if I have some C++ and Cython extensions), and the configure part works well. The only disadvantage that I can see is that one has to learn a new syntax, which is not Python. But on the other hand, at least it forces one to really just use cmake to write build scripts in a standard way, while scons and other Python solutions imho encourage to write full Python programs, which imho is a disadvantage for the build system, as then every build system is nonstandard. Ondrej ___ 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] str(container) should call str(item), not repr(item)
Hi,
as discussed before here:
http://mail.python.org/pipermail/python-3000/2008-May/013876.html
if you do:
>>> from decimal import Decimal
>>> a = Decimal(40)
>>> print a, a**2, a**3
40 1600 64000
>>> print [a, a**2, a**3]
[Decimal("40"), Decimal("1600"), Decimal("64000")]
>>> print {a: 3}
{Decimal("40"): 3}
>>> print {a: a**2}
{Decimal("40"): Decimal("1600")}
i.e. the str on list (and tuple and dict) calls repr() on the
elements, instead of str. This really seems to me like a bug. Because
if I wanted the repr() representation, I'd call repr() on the
list/tuple/dict. If I want a nice readable representation, I call
str(). That's the philosophy, no?
I understant there can be technical reasons why this cannot be made
into python 3.0, so why not 3.1? or 2.8?
If this cannot be made into python for some reason, how would you
suggest us we solve the following problem in sympy (symbolic
manipulation library):
>>> from sympy import Symbol, srepr
>>> x = Symbol("x")
>>> l = [x, x**2/2, x**3/3, x**4/4]
>>> str(l)
'[x, 1/2*x**2, 1/3*x**3, 1/4*x**4]'
>>> repr(l)
'[x, 1/2*x**2, 1/3*x**3, 1/4*x**4]'
>>> srepr(l)
"[Symbol('x'), Mul(Half(1, 2), Pow(Symbol('x'), Integer(2))),
Mul(Rational(1, 3), Pow(Symbol('x'), Integer(3))), Mul(Rational(1, 4),
Pow(Symbol('x'), Integer(4)))]"
As you can see, we currently have to hack our __repr__ to return the
same thing as __str__ so that things look nice in lists and
dictionaries. We provide the srepr() function that does what the
__repr__ should do instead. And as you can see, the result of srepr is
really not very readable, but it is easy to convert it back to a sympy
expression using eval. That's the purpose of repr(), no? However, you
cannot easily convert the str() back to an expression, because the
eval() doesn't know what "x" is.
One solution that we'll probably use is that we'll change our repr()
to the srepr output above, so str([x, x**2,...]) will not be pretty
and we'll use sys.displayhook to hook our own function into the
interactive session that overcomes this python behavior. This solves
the problem for interactive sessions, but it doesn't solve it if
people just call "print [x, x**2, ...]" inside their programs, for
example when debugging. Another option is to write a C extension
module that monkey patches the list class and changes the C pointer to
the (currently null) __str__ method to our own method. But I find it
very hackish and also it requires a C module.
I was discussing this with other people at EuroSciPy2008 and
everyone's first reaction that str(list) calls repr() on the elements
was that it's a bug. So was my reaction when I discovered that. So, I
think people find this highly unintuitive. So I just wanted to discuss
this more with core Python developers what you think about it and if
you also find this not very intuitive and if so, if there is any
chance to get this fixed.
Thanks,
Ondrej
___
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] Documentation Error for __hash__
> I strongly advise people interested in this topic to take a closer look > at the functionality that was added to address issue 2235. The "don't > inherit __hash__" behaviour has been backported from 3.0 and broke a > bunch of code, but the naive fix of reverting to the 2.5 behaviour > proceeded to make the 2.6 version of collections.Hashable completely > useless (since pretty much *everything* then claimed to be hashable, > including all of the container types in the standard library). > > After thrashing out those problems, the 2.6 behaviour ended up being: > - __hash__ is still inherited by default > - you can block inheritance explicitly by setting "__hash__ = None" in > the class definition or on the class object > - for a class defined in C, you can block __hash__ inheritance by > setting the tp_hash slot to PyObject_HashNotImplemented > - using one of the above approaches will cause hash(obj) to raise a > TypeError, as will calling the tp_hash slot directly > - unlike defining your own __hash__ method, using one of the above > techniques will also mean that isinstance(obj, collections.Hashable) > will also return False > - defining __eq__ and/or __cmp__ without defining __hash__ will lead to > a Py3k Warning being raised on the class definition when run with the -3 > switch > > The Python 3.0 behaviour is similar to the above, except that the > unconditional inheritance of __hash__ is gone. If you define __eq__ or > __cmp__ without defining __hash__, __hash__ will NOT be inherited from > the parent class - instead, it will be set to None. > > The documentation of all of this could definitely use a bit more work - > that's why I reopened 2235 in response to Michael's post. Couple months ago I was trying to figure out how __eq__, __cmp__, __hash__ and similar methods are called in Python and in which order and wrote a docs here: http://docs.sympy.org/python-comparisons.html Feel free to reuse any of it. I wrote it to myself, as I didn't find the official docs very clear. Ondrej ___ 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] Documentation Error for __hash__
>> Ondrej > > Ondrej, a patch that improves the official docs would be welcome and still > potentially make 2.6/3.0 That'd be awesome. I need to finish my thesis in the next couple days, so I'd welcome if anyone could just take it and put usefult things in. I could get to do it the next week the earliest. Ondrej ___ 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] Documentation Error for __hash__
Hi Georg! On Sat, Aug 30, 2008 at 11:09 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Ondrej Certik schrieb: >>>> Ondrej >>> >>> Ondrej, a patch that improves the official docs would be welcome and still >>> potentially make 2.6/3.0 >> >> That'd be awesome. I need to finish my thesis in the next couple days, >> so I'd welcome if anyone could just take it and put usefult things in. >> I could get to do it the next week the earliest. > > Doc patches are always accepted, and I intend to update the online 2.6 and > 3.0 docs continually even when the finals are released, so there is no > particular deadline you have to make. This is awesome, I didn't know you take care of the official docs too. I'll send the doc patches when I get to it, unless someone else does it before me. Ondrej ___ 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] effect of "exec" on local scope
Hi Terry,
On Wed, Oct 8, 2008 at 9:17 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Willem Broekema wrote:
>>
>> The issue came up while trying to get some Sympy code running on CLPython.
>>
>> class C:
>> exec "a = 3"
>> print locals()
>>
>> 1. Is it guaranteed that class C gets an attribute "a", i.e. that the
>> locals printed include {'a': 3}?
>> 2. It it (also) guaranteed if it were in a function scope?
>>
>> The complete syntax of exec is:
>> exec CODE in Y, Z
>> where Y, Z are optional.
>>
>> The documentation of "exec" says "if the optional parts are
>> omitted,the code is executed in the current scope." There are at least
>> two different interpretations:
>>
>> a. The code is executed in the current class scope, so the assignment
>> must have an effect on the class scope.
>>
>> b. The scope defaults to the local scope, by which is meant the
>> mapping returned by locals(), and of locals() the documentation says
>> that changes made to it may not influence the interpreter. (The
>> documentation of exec suggests using globals() and locals() as
>> arguments to exec, which seems hint at this interpretation.)
>>
>> The relevant documentation:
>> exec:
>> http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
>> locals: http://docs.python.org/library/functions.html#locals
>
> The 3.0 doc for exec() has this warning:
> "Warning
> The default locals act as described for function locals() below:
> modifications to the default locals dictionary should not be attempted. Pass
> an explicit locals dictionary if you need to see effects of the code on
> locals after function exec() returns."
>
> This implies interpretation b.
>
> However, is spite of the warning, class locals is a dict and locals() is
> that dict, so a is available for further use in class code.
>
> So the answer to question 1 for current CPython is yes.
>
> Whether that is guaranteed for all implementations and versions is another
> story.
>
> Functions are much trickier. The local namespace is not a dict, and
> modifying the locals() dict does not modify the namespace. The answer to 2.
> is No, not even now.
>
def f():
>exec('a=3')
>print(locals())
>return a
>
f()
> {'a': 3}
> Traceback (most recent call last):
> File "", line 1, in
>f()
> File "", line 4, in f
>return a
> NameError: global name 'a' is not defined
>
> But why then is 'a' printed in the second call to locals (the implied one in
> exec being the first)? It appears that a function or code object can have
> only only one repeatedly used shadow dict. The 3.0 (and 2.5) doc says
> "locals()
> Update and return a dictionary representing the current local symbol table."
> Note "update"; I had missed that before. To see this...
>
def g():
>a = locals()
>b = locals()
>return id(a), id(b), a,b
>
g()
> (20622048, 20622048, {'a': {...}}, {'a': {...}})
>
> Inserting "print(a['a'])" between the locals calls raises KeyError.
Thanks very much for the thorough answer. The reason for Willem's
question is this code that we currently have in sympy (see [1] for the
whole thread):
class Basic(AssumeMeths):
...
for k in AssumeMeths._assume_defined:
exec "is_%s = property(make__get_assumption('Basic', '%s'))" % (k,k)
Which works in CPython but fails in CLPython. From your answer it
seems to me that this code is not nice and we should not use it and
should rather use something like:
class Basic(AssumeMeths):
...
for k in AssumeMeths._assume_defined:
setattr(Basic, 'is_%s' % k, property(make__get_assumption('Basic', '%s' % k)))
which should work on all platforms. What do you think?
Ondrej
[1] http://code.google.com/p/sympy/issues/detail?id=1134
___
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] Using Cython for standard library?
On Tue, Nov 4, 2008 at 9:06 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> The project has made inclusion into Python's stdlib a goal right from the >> beginning. > > Ah, that changes my view of it significantly. If the authors want to > contribute it to Python some day, I'm looking forward to that (assuming > that they then close their official branch, and make the version inside > Python the maintained one). > > That is also independent of whether standard library modules get written > in Cython. I would expect that some may (in particular, if they focus on > wrapping an external library), whereas others might stay what they are > (in particular, when they are in the real core of the interpreter). I think it is also a good idea to write things using pure Python syntax in Cython, so that all other Python implementations, like Jython, Pypy, IronPython can just take it and run it in pure Python mode. Pure Python syntax means that the code runs in Python unmodified, but can also be compiled with Cython. Pure Python syntax was only recently added to Cython, so I guess it should be well tested first. What do you think? Ondrej ___ 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] Optimize Python long integers
On Tue, Nov 11, 2008 at 11:40 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On Tue, Nov 11, 2008 at 14:25, Victor Stinner <[EMAIL PROTECTED]> > wrote: >> >> There are some very interesting propositions (with patches!) to optimize >> Python int and long types (especially the long integers). > > Here's another one: http://code.python.org/loggerhead/users/twouters/intopt > -- integer inlining through pointer tagging trickery. In Python 2.6 it costs > 2-4% overall performance but increases integer arithmetic (in the range > [-0x4000, 0x4000) only) by 10-20% according to my rough measurements > (I haven't tried your benchmark yet.) I haven't ported it to 3.0 but it > should provide a bigger win there. It also breaks API compatibility in a few > ways: Py_TYPE(o) and Py_REFCNT(o) are no longer valid lvalues, and they and > Py_INCREF(o) and Py_DECREF(o) may all evaluate 'o' twice. And, worst of all, > it exposes the tagged pointers to third-party extensions, so anything not > doing typechecks with Py_TYPE(o) will likely cause buserrors. > > In retrospect, perhaps this is too controversial to be added to the list ;-) > I don't really expect this to be something CPython would want to use as-is, > although there may be use for tagged pointers in more controlled > environments (like function locals.) You might also try sympy (http://code.google.com/p/sympy/). Calculates 10**5 decima digits of pi: pure Python integers: $ MPMATH_NOGMPY=yes ipython In [1]: from sympy import pi In [2]: %time a=pi.evalf(10**5) CPU times: user 8.56 s, sys: 0.00 s, total: 8.56 s Wall time: 8.56 s gmpy integers: $ ipython In [1]: from sympy import pi In [2]: %time a=pi.evalf(10**5) CPU times: user 0.28 s, sys: 0.00 s, total: 0.28 s Wall time: 0.28 s So with gmpy, it is 30x faster. Ondrej ___ 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] RELEASED Python 3.0 final
On Thu, Dec 4, 2008 at 3:24 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Dec 3, 2008, at 9:13 PM, Dotan Cohen wrote: > >> On this page: >> http://www.python.org/download/releases/3.0/ >> >> The text "This is a proeuction release" should probably read "This is >> a production release". It would give a better first impression :) > > Fixed, thanks! I tried to find the documentation here: http://python.org/doc/ but clicking on the links: http://docs.python.org/whatsnew/3.0.html http://docs.python.org/3.0 gives me: 404 Not Found Ondrej ___ 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] I would like an svn account
> And I hope everyone realizes that they can speak up (publicly or > privately) about *anyone* in regards to whether they think they need > to lose their commit privileges for personal or coding reasons. I know > it's tough to speak out publicly about someone and their coding > abilities which is why I am trying to rationalize this for Victor > instead of just sitting quietly while he does or does not get > responses from people on whether he should get commit privileges. > Every time commit privileges are given out it is a leap of faith and > sometime the leap comes up short. I am not a core developer, but I was following this thread with interest. A little offtopic: it seems to me it is a flaw of svn, that it encourages the model of two classes of developers, those with a commit access (first class) and those without it (second class). Victor -- maybe you can try something like "git svn", so that you don't have to use the bugtracker and wait until someone reviews the patches? If I understood correctly, your main point is that using bugtracker for committing patches is very painful (I agree). But since patches should be reviewed anyways, imho just using better tools that make the workflow more fluent could solve the problem and remove the friction of deciding if someone is good enough to get a svn commit access. Ondrej ___ 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] I would like an svn account
On Sat, Jan 3, 2009 at 8:46 AM, "Martin v. Löwis" wrote: > [I don't want to get into another DVCS flamewar, but I just > can't let this go uncommented :-] >> (took me ~ 1 hour to get around >> without any previous encounter with git and I am no genius) > > I'm no genius, either, and I think that git is the most horrible > VCS that I ever had to use. The error messages are incomprehensible, > and it fails to do stuff that should be trivial (and indeed is trivial > in subversion). On this project, I spent 40% of the time fighting > git, 40% of the time fighting Perl, and was productive on 20% of the > time. IOW, I find the learning curve for git extremely steep. That is interesting, I had the opposite experience. :) http://ondrejcertik.blogspot.com/2008/12/experience-with-git-after-4-months.html Ondrej ___ 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] I would like an svn account
On Fri, Jan 9, 2009 at 1:48 AM, Giovanni Bajo wrote: > On Sun, 04 Jan 2009 18:50:09 +0900, Stephen J. Turnbull wrote: > >> "Martin v. Löwis" writes: >> >> > If "switching to a modern DVCS" means that users now need to start >> > compiling their VCS before they can check out Python, >> >> It doesn't mean that. All of the DVCS contenders have Windows and Mac >> OS installers (usually from 3rd parties, but working closely with the >> core). > > I'll notice that git-win32 is totally bad for any serious Windows > developers. At least 4 months ago which is the last time I tried it. > You'll have a very hard time persauding the experienced Windows > developers in this list that git-win32 is a good thing to use. Do you mean this one: http://code.google.com/p/msysgit/ or is git-win32 something else? Ondrej ___ 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
