[Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
Hi,
I posted this (by accident) off the list:
On 2012-11-14, at 23:43 , Chris Withers wrote:
On 14/11/2012 22:37, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
def xdict(**kwds):
return kwds
Hah, good call, this trumps both of the other options:
100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 0.548 0.533 0.55 0.577 0.539
100 loops, best of 5: 0.533 usec per loop
No, this just doesn't execute the right code:
def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)
...
import dis
dis.dis(md)
1 0 LOAD_FAST0 (kw)
3 RETURN_VALUE
4 LOAD_GLOBAL 0 (md)
7 LOAD_CONST 1 ('a')
10 LOAD_CONST 2 (1)
13 LOAD_CONST 3 ('b')
16 LOAD_CONST 4 (2)
19 LOAD_CONST 5 ('c')
22 LOAD_CONST 6 (3)
25 LOAD_CONST 7 ('d')
28 LOAD_CONST 8 (4)
31 LOAD_CONST 9 ('e')
34 LOAD_CONST 10 (5)
37 LOAD_CONST 11 ('f')
40 LOAD_CONST 12 (6)
43 LOAD_CONST 13 ('g')
46 LOAD_CONST 14 (7)
49 CALL_FUNCTION 1792
52 POP_TOP
Also:
Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit
(AMD64)] on win 32
Type help, copyright, credits or license for more information.
dict({1: foo}, **{frozenset([2]): bar})
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: keyword arguments must be strings
While:
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
dict({1: foo}, **{2: bar})
{1: 'foo', 2: 'bar'}
dict({1: foo}, **{frozenset([2]): bar})
{1: 'foo', frozenset([2]): 'bar'}
If you're worrying about global lookup, you should stop (in this case):
$ py -3.3 -m timeit -n 100 -r 5 -v -s def xdict(): return dict() xdict()
raw times: 0.477 0.47 0.468 0.473 0.469
100 loops, best of 5: 0.468 usec per loop
$ py -3.3 -m timeit -n 100 -r 5 -v -s def xdict(dict=dict):
return dict() xdict()
raw times: 0.451 0.45 0.451 0.45 0.449
100 loops, best of 5: 0.449 usec per loop
$ py -3.3 -m timeit -n 100 -r 5 -v -s def xdict(dict=lambda **kw:
kw): return dict() xdict()
raw times: 0.433 0.434 0.435 0.435 0.431
100 loops, best of 5: 0.431 usec per loop
$ py -3.3 -m timeit -n 100 -r 5 -v -s def xdict(dict=dict):
return {} xdict()
raw times: 0.276 0.279 0.279 0.277 0.275
100 loops, best of 5: 0.275 usec per loop
And using non-empty dicts doesn't change much and the first one is
roughly the sum of the latter two (as expected):
C:\Users\lrekuckipy -3.3 -m timeit -n 100 -r 5 -v -s def
xdict(dict=dict): return dict(a=1, b=2, c=3, d=4, e=5, f=6) xdict()
raw times: 1.72 1.71 1.71 1.71 1.71
100 loops, best of 5: 1.71 usec per loop
C:\Users\lrekuckipy -3.3 -m timeit -n 100 -r 5 -v -s def
xdict(dict=lambda **kw: kw): return dict(a=1, b=2, c=3, d=4, e=5,
f=6) xdict()
raw times: 1.01 1.01 1.01 1.01 1.01
100 loops, best of 5: 1.01 usec per loop
C:\Users\lrekuckipy -3.3 -m timeit -n 100 -r 5 -v -s def
xdict(dict=dict): return {'a': 1, 'b': 2, 'c': 3, 'd': 4, 'e': 5, 'f':
6} xdict()
raw times: 0.744 0.736 0.735 0.733 0.733
100 loops, best of 5: 0.733 usec per loop
I hope that this helps move python-dev's focus to some more useful discussion.
--
Łukasz Rekucki
___
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] Setting project home path the best way
When python is being run from a compile environment, it detects this by looking for Lib folders in directories above the one containing the executable. (I always thought that this special execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks. K -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way Hi friends, I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules. There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.' Problem: - I want to run any module inside the heirarchy from the command-line - this should work, regardless what my 'cwd' is - this should work with or without virtualenv. So far, things work fine with virtualenv, because sys.executable is in the project module tree. Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. . Question: How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that? Reason: I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree. Is this elegantly possible to deduce from the actually executed script file? Cheers - chris Sent from my Ei4Steve ___ 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/kristjan%40ccpgames.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] externals?
Okay, that means I need to re-install svn, cool. But I should mention that this needs to be mentioned in the core development FAQs, setting up and so forth. There is no mention of it there. Perhaps the unix makefiles get the proper version, but a windows developer has to fetch those externals manually. Also, is there any reason to keep this in svn? Why not check this in to HG, we need not worry about history, etc. K -Original Message- From: Benjamin Peterson [mailto:benja...@python.org] Sent: 13. nóvember 2012 15:04 To: Kristján Valur Jónsson Cc: Python-Dev (python-dev@python.org) Subject: Re: [Python-Dev] externals? Their still in svn as far I know. 2012/11/13 Kristján Valur Jónsson krist...@ccpgames.com: This may be a silly question, but haven‘t the python externals been moved to HG yet? I usually work on cpython without bothering with the externals, but I found today that I needed them. On Windows this is a bit of a bother. And I‘ve thrown away all my SVN stuff... K ___ 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/benjamin%40python.or g -- Regards, Benjamin ___ 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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
mar...@v.loewis.de wrote: It's faster than calling dict() because the dict code will create a second dictionary, and discard the keywords dictionary. Perhaps in the case where dict() is called with keyword args only, it could just return the passed-in keyword dictionary instead of creating another one? -- 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] [BUG] Trailing spaces in pretty-printed JSON
On 2012-10-14 02:06 +0800, Xavier Morel wrote: 1. Why didn't you report that on the tracker? Reported: http://bugs.python.org/issue16476 ___ 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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 8F7E41C98F for rep...@bugs.python.org; Thu, 15 Nov 2012 15:30:55 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Y2Q3g2PtxzRjv for rep...@bugs.python.org; Thu, 15 Nov 2012 15:30:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1352989855; bh=X+inBqLoRVfh7Gtof4lWQ3GKcOPuRIb4f6aeDmPB+Z0=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=bj7svLDU57Chaz18mDOtCNtAs4y0V8RO1R/xoKH8KOELcUKhqVHFdJPfiOKurVwc3 ZvP/i9O0oKNrXvACnjFnTi9Z9x8sW7kWvMxNKpWo4wQPwrXPn1RDhtRoIFZ9l98sbt P8zJS8xwXS592hm1od1ZadbKgEaSw2BERQ6c1zsI= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 15 Nov 2012 15:30:55 +0100 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for rep...@bugs.python.org; Thu, 15 Nov 2012 15:30:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue16144] Message-Id: 3y2q3g2ptxz...@mail.python.org Date: Thu, 15 Nov 2012 15:30:55 +0100 (CET) TmV3IGNoYW5nZXNldCBhOGNhMTQ5ODNhYjEgYnkgQW5kcmV3IFN2ZXRsb3YgaW4gYnJhbmNoICcz LjMnOgpJc3N1ZSAjMTYxNDQ6IEZpeCBtaXNsZWFkaW5nIHNlbnRlbmNlIGluIHJlZmVyZW5jZS9p bXBvcnQuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2E4Y2ExNDk4M2FiMQoKCk5l dyBjaGFuZ2VzZXQgOTk2MWEwZGFmY2M3IGJ5IEFuZHJldyBTdmV0bG92IGluIGJyYW5jaCAnZGVm YXVsdCc6Ck1lcmdlIGlzc3VlICMxNjE0NDogRml4IG1pc2xlYWRpbmcgc2VudGVuY2UgaW4gcmVm ZXJlbmNlL2ltcG9ydC4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvOTk2MWEwZGFm Y2M3Cg== ___ 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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
Greg Ewing, 15.11.2012 11:48:
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
dictionary instead of creating another one?
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
Stefan
___
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] performance of {} versus dict()
Stefan Behnel stefan_ml at behnel.de writes: Right. If that makes a difference, it's another bug. Stefan It's fixed, with, I will note, fewer lines of code than many messages in this thread: https://bitbucket.org/pypy/pypy/changeset/c30cb1dcb7a9adc32548fd14274e4995 Alex ___ 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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On 11/15/2012 9:58 AM, Stefan Behnel wrote:
Greg Ewing, 15.11.2012 11:48:
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
dictionary instead of creating another one?
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
I was thinking that CPython could check the ref count of the input
keyword dict to determine whether it is newly created and can be
returned or is pre-existing and must be copied. But it seems not so.
def d(**x): return sys.getrefcount(x)
import sys
d(a = 3)
2
d(**{'a': 3})
2
b = {'a': 3}
d(**b)
2
I was expecting 3 for the last one.
--
Terry Jan Reedy
___
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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On 15/11/2012 4:21pm, Terry Reedy wrote:
I was thinking that CPython could check the ref count of the input
keyword dict to determine whether it is newly created and can be
returned or is pre-existing and must be copied. But it seems not so.
def d(**x): return sys.getrefcount(x)
import sys
d(a = 3)
2
d(**{'a': 3})
2
b = {'a': 3}
d(**b)
2
I was expecting 3 for the last one.
Isn't it always newly created?
def f(**x): return x
...
b = {'a':3}
b is f(**b)
False
--
Richard
___
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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 5B78D1CC04 for rep...@bugs.python.org; Thu, 15 Nov 2012 19:24:19 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Y2WDz1BQtzRhX for rep...@bugs.python.org; Thu, 15 Nov 2012 19:24:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1353003859; bh=GDDVQWyvA249FMc1twsoY4VfCXH15D/J8oGHrHuD8Og=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=sMId1I1AgUhjGpLVNulgs6JADkCmjcEvAyX34oy66KWe8KvbSTNxig9wD53MNGnso vUA4DbpD2v2oRy/Udvmgn2Tqap/lZpo/RPxjT+eivdsvTWOpbFUE8401pNmG/f316p 4wis2s3IIGJv1jpw9e4fuBwbCi5iSDyB3HYYaKjI= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 15 Nov 2012 19:24:19 +0100 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for rep...@bugs.python.org; Thu, 15 Nov 2012 19:24:18 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue16481] Message-Id: 3y2wdz1bqtz...@mail.python.org Date: Thu, 15 Nov 2012 19:24:19 +0100 (CET) TmV3IGNoYW5nZXNldCBjNTc0Y2U3OGNkNjEgYnkgUmljaGFyZCBPdWRrZXJrIGluIGJyYW5jaCAn My4zJzoKSXNzdWUgIzE2NDgxOiBtdWx0aXByb2Nlc3Npbmcgbm8gbG9uZ2VyIGxlYWtzIHByb2Nl c3MgaGFuZGxlcyBvbiBXaW5kb3dzLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9j NTc0Y2U3OGNkNjEKCgpOZXcgY2hhbmdlc2V0IGNiNjEyYzVmMzBjYiBieSBSaWNoYXJkIE91ZGtl cmsgaW4gYnJhbmNoICdkZWZhdWx0JzoKSXNzdWUgIzE2NDgxOiBNZXJnZQpodHRwOi8vaGcucHl0 aG9uLm9yZy9jcHl0aG9uL3Jldi9jYjYxMmM1ZjMwY2IK ___ 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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 728881C884 for rep...@bugs.python.org; Thu, 15 Nov 2012 21:58:51 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Y2ZgH1WglzRlk for rep...@bugs.python.org; Thu, 15 Nov 2012 21:58:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1353013131; bh=OUB+ieZrhXLf00fS3ScDXJOs2fZdncpLHhVH8Mq4aG8=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=bxgo73yXi3M9v/34ihpVbL175HI0avNqRJ9ZZPR8RJ/Ebf+s6CLSY6KSFvEqsey6o k9VOuwgxEoJ6EPYG9b80rF0TfIkaPS/ly2PkD0oDeL2MONpJ/T+mCqEYegdK16I1mO QP53t81gJuW1rACwgBViWQfoGh0NTebNRHzjE2zw= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 15 Nov 2012 21:58:51 +0100 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for rep...@bugs.python.org; Thu, 15 Nov 2012 21:58:50 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue16469] Message-Id: 3y2zgh1wglz...@mail.python.org Date: Thu, 15 Nov 2012 21:58:51 +0100 (CET) TmV3IGNoYW5nZXNldCBhMmI1NGI2ZDk3NTkgYnkgTWFyayBEaWNraW5zb24gaW4gYnJhbmNoICdk ZWZhdWx0JzoKSXNzdWUgIzE2NDY5OiBGcmFjdGlvbihmbG9hdCgnbmFuJykpIGFuZCBGcmFjdGlv bihmbG9hdCgnaW5mJykpIG5vdyByYWlzZSBWYWx1ZUVycm9yIGFuZCBPdmVyZmxvd0Vycm9yIChy ZXNwLiksIG5vdCBUeXBlRXJyb3IuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2Ey YjU0YjZkOTc1OQo= ___ 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] Setting project home path the best way
Hi Kristjan, does that mean that your scheme simply works, without any config step necessary after I did my checkout? This would in fact be an interesting alternative to Python setup.py develop but I'm not sure if this is the same scheme on windows and Os X. Getting this part right was rather tricky, and I fear this is still an issue. Right now I think to just force my users to run the install step, since it is quite accepted in general. Still, I'd love to see a way with no action needed at all: write yout your structure, and it works as-is. Seems to be impossible without tricks. Cheers - chris Sent from my Ei4Steve On Nov 15, 2012, at 10:17, Kristján Valur Jónsson krist...@ccpgames.com wrote: When python is being run from a compile environment, it detects this by looking for Lib folders in directories above the one containing the executable. (I always thought that this special execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks. K -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way Hi friends, I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules. There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.' Problem: - I want to run any module inside the heirarchy from the command-line - this should work, regardless what my 'cwd' is - this should work with or without virtualenv. So far, things work fine with virtualenv, because sys.executable is in the project module tree. Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. . Question: How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that? Reason: I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree. Is this elegantly possible to deduce from the actually executed script file? Cheers - chris Sent from my Ei4Steve ___ 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/kristjan%40ccpgames.com winmail.dat ___ 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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
Stefan Behnel wrote:
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
It will -- the implementation of the function call opcode always
creates a new keyword dict for passing to the called function.
--
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] Generally boared by installation (Re: Setting project home path the best way)
Hi guys, I am bored of installing things. Bored of things that happen to not work for some minor reasons. Reasons that are not immediately obvious. Things that don't work because some special case was not handled. Things that compile for half an hour and then complain that something is not as expected. May it be a compiler, a library, a command like pip or easy-install, a system like macports or homebrew, virtualenv, whatsoever. These things are all great if they work. When they do not work, the user is in some real trouble. And he reads hundreds Of blogs and sites and emails, which all answer a bit of slightly related questions, but all in all - This is not how Python should work !! I am really bored and exhausted and annoyed by those packages which Pretend to make my life eadier, but they don't really. Something is really missing. I want something that is easy to use in all cases, also if it fails. Son't get me wrong, I like things like pip or virtualenv or homebrew. I just think they have to be rewritten completely. They have the wrong assumption that things work! The opposite should be the truth: by default, things go wrong. Correctness is very fragile. I am thinking of a better concept that is harder to break. I thin to design a setup tool that is much more checking itself and does not trust in any assumption. Scenario: After hours and hours, I find how to modify setup.py to function almost correctly for PySide. This was ridiculously hard to do! Settings for certain directories, included and stuff are not checked when they could be, but after compiling a lot of things! After a lot of tries and headaches, I find out that virtualenv barfs on a simple link like ./.Python, the executable, when switching from stock Python to a different (homebrew) version!! This was obviously never tested well, so it frustrates me quite a lot. I could fill a huge list full of complaints like that if I had time. But I don't. Instead, I think installation scripts are generally still wrong by concept today and need to be written in a different way. I would like to start a task force and some sprints about improving this situation. My goal is some unbreakable system of building blocks that are self-contained with no dependencies, that have a defined interface to talk to, and that know themselves completely by introspection. They should not work because they happen to work around all known defects, but by design and control. Whoever is interested to work with me on this is hereby honestly welcomed! Cheers - chris Sent from my Ei4Steve On Nov 15, 2012, at 10:17, Kristján Valur Jónsson krist...@ccpgames.com wrote: When python is being run from a compile environment, it detects this by looking for Lib folders in directories above the one containing the executable. (I always thought that this special execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks. K -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way Hi friends, I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules. There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.' Problem: - I want to run any module inside the heirarchy from the command-line - this should work, regardless what my 'cwd' is - this should work with or without virtualenv. So far, things work fine with virtualenv, because sys.executable is in the project module tree. Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. . Question: How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that? Reason: I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree. Is this elegantly possible to deduce from the actually executed script file? Cheers - chris Sent from my Ei4Steve ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)
On Nov 14, 2012, at 5:37 PM, Chris Withers wrote:
On 14/11/2012 10:11, mar...@v.loewis.de wrote:
Zitat von Chris Withers ch...@simplistix.co.uk:
a_dict = dict(
x = 1,
y = 2,
z = 3,
...
)
What can we do to speed up the former case?
It should be possible to special-case it. Rather than creating
a new dictionary from scratch, one could try to have the new dictionary
the same size as the original one, and copy all entries.
Indeed, Doug, what are your views on this? Also, did you have a real-world
example where this speed difference was causing you a problem?
No, not particularly. I noticed people using dict() and wondered what impact it
might have in a general case.
I don't know how much this would gain, though. You still have to
create two dictionary objects. For a better speedup, try
def xdict(**kwds):
return kwds
Hah, good call, this trumps both of the other options:
$ python2.7 -m timeit -n 100 -r 5 -v
{'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}
raw times: 1.45 1.45 1.44 1.45 1.45
100 loops, best of 5: 1.44 usec per loop
$ python2.6 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 2.37 2.36 2.36 2.37 2.37
100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n 100
-r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 0.548 0.533 0.55 0.577 0.539
100 loops, best of 5: 0.533 usec per loop
For the naive observer (ie: me!), why is that?
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
___
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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id DFD211C98E for rep...@bugs.python.org; Fri, 16 Nov 2012 03:39:49 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Y2kDj4Tk8zRb6 for rep...@bugs.python.org; Fri, 16 Nov 2012 03:39:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1353033589; bh=H41Haza/UPvj9B16qvXQtqjlb22jRmazur238MqAPOE=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=yz1YIEtIYuM3H9V1Ok0YJ/SDvU8xtO+cFOApgDH8jPRdxRS6z/CSdZ96bSY1cNFM7 4xxKY3LiUXipe439DPwEjxZr0HcsfX+2JdR4Pzf3OZmdopV6PEl8/twaIFoTHQMy8u dTwpZ7G4OJKCc2IeCq4e5Bl/TEvQvVT9NO8eoa3k= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 16 Nov 2012 03:39:49 +0100 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for rep...@bugs.python.org; Fri, 16 Nov 2012 03:39:49 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue15894] Message-Id: 3y2kdj4tk8z...@mail.python.org Date: Fri, 16 Nov 2012 03:39:49 +0100 (CET) TmV3IGNoYW5nZXNldCBiZDg1MzMxMWZmZTAgYnkgQnJldHQgQ2Fubm9uIGluIGJyYW5jaCAnZGVm YXVsdCc6Cklzc3VlICMxNTg5NDogRG9jdW1lbnQgd2h5IHdlIGRvbid0IHdvcnJ5IGFib3V0IHJl LWFjcXVpcmluZyB0aGUKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvYmQ4NTMzMTFm ZmUwCg== ___ 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] Setting project home path the best way
Are you familiar with executing directories having __main__.py as python scripts? Daniel Holth On Nov 15, 2012, at 4:43 PM, Christian Tismer tis...@stackless.com wrote: Hi Kristjan, does that mean that your scheme simply works, without any config step necessary after I did my checkout? This would in fact be an interesting alternative to Python setup.py develop but I'm not sure if this is the same scheme on windows and Os X. Getting this part right was rather tricky, and I fear this is still an issue. Right now I think to just force my users to run the install step, since it is quite accepted in general. Still, I'd love to see a way with no action needed at all: write yout your structure, and it works as-is. Seems to be impossible without tricks. Cheers - chris Sent from my Ei4Steve On Nov 15, 2012, at 10:17, Kristján Valur Jónsson krist...@ccpgames.com wrote: When python is being run from a compile environment, it detects this by looking for Lib folders in directories above the one containing the executable. (I always thought that this special execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405) Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it: site.py sitecustomize.py sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root. site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks. K -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer Sent: 11. nóvember 2012 20:31 To: python-dev@python.org Subject: [Python-Dev] Setting project home path the best way Hi friends, I have a project that has its root somewhere on my machine. This project has many folders and contains quite some modules. There is a common root of the module tree, and I want to use - either absolute imports - relative imports with '.' Problem: - I want to run any module inside the heirarchy from the command-line - this should work, regardless what my 'cwd' is - this should work with or without virtualenv. So far, things work fine with virtualenv, because sys.executable is in the project module tree. Without virtualenv, this is not so. But I hate to make settings like PYTHONPATH, because these are not permanent. . Question: How should I define my project root dir in a unique way, without setting an environment variable? What is the lest intrusive way to spell that? Reason: I'd like to make things work correctly and unambigously when I call a script inside the module heirarchy. Things are not fixed: there exist many checkouts In the file system, and each should know where to search its home/root in the tree. Is this elegantly possible to deduce from the actually executed script file? Cheers - chris Sent from my Ei4Steve ___ 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/kristjan%40ccpgames.com winmail.dat ___ 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/dholth%40gmail.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] Generally bored by installation
Hello, Christian!
On Fri, Nov 16, 2012 at 12:10:09AM +0100, Christian Tismer
tis...@stackless.com wrote:
I am bored of installing things.
Bored of things that happen to not work for some minor reasons.
Reasons that are not immediately obvious.
Things that don't work because some special case was not handled.
[a hot rant skipped]
Christian, I feel your pain. Everyone does, I am sure. Who among us
never cursed that dratted computers? Those dirty rotten things that
always hang due to bugs in drivers or whatnot, require constant
cleaning, mending, upgrading, repairing, debugging. Condemn that magical
mouse gestures, be cursed those magical incantations. Who in his normal
mind would ever think of writing things like
exec find . \( -type d \( -name CVS -o -name .svn -o -name .hg -o -name .git -o
-path ./.mozilla/\*/Cache/\* -o -path ./tmp/\* \) -prune \) -o -type f -exec
grep -I $@ '{}' \+ 2/dev/null
???!!!
Unfortunately, there is no escape. Remember that classical book The
Mythical Man-Month? Quoting Brooks, There is no silver bullet. Things
are becoming better but will never be absolutely perfect.
I would like to start a task force and some sprints about improving this
situation.
My goal is some unbreakable system of building blocks that are self-contained
with no dependencies, that have a defined interface to talk to, and that know
themselves completely by introspection.
They should not work because they happen to work around all known defects,
but by design and control.
Whoever is interested to work with me on this is hereby honestly welcomed!
I am sorry to disappoint you but I don't believe this could work.
Many single developers and teams -- small teams and huge companies,
commercial and non-commercial -- have tried the approach and failed.
Sometimes things work fine, some small projects look perfect... in
isolation... But every now and then they failed, especially when
combined. Try to connect a perfect project that measures distances in
inches with another perfect project that that measures distances in
centimeters -- and poof! your perfect satellite failed and dropped off
of the sky.
This will always happen. There is always pain for both users and
developers. And still people are not afraid to create bigger and more
complex projects -- and often they succeed.
The only sane approach in my humble opinion is evolution. Similar to
biological evolution. And biological evolution means huge birth rate,
adapting and huge death rate.
So write a lot of code, adapt it to your user's need and suffer a lot
of pain -- code death and all that. Try to lessen user's pain, but never
expect a piece of software to become perfect once, for all and forever.
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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
