Re: [Python-Dev] on Python's tests (and making them better)
Guilherme Polo schrieb: 2008/6/6 Ron Adam [EMAIL PROTECTED]: Martin v. Löwis wrote: How does 1 directory scale when one day you have possibly thousands of tests? I find this a theoretical question. It took 18 years to arrive at 500 test files. Assuming a linear growth, we get 1000 tests in 2025, and 2000 tests in 2060. People can worry about reorganizing them then. Personally I'd like to see packages have their own test directory. This keeps things related to each other together. Top level modules of course would have their tests in the top level test directory as they are now. I really dislike having a test directory inside a python package. You have my -1 on that idea. I'm also not in favor of this, especially since you still need a wrapper in Lib/test to make them execute. However, I can understand package maintainers wanting everything in one place. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] on Python's tests (and making them better)
Personally I'd like to see packages have their own test directory. That's a good idea, and it is already implemented for several packages. This keeps things related to each other together. Top level modules of course would have their tests in the top level test directory as they are now. Indeed. 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
Re: [Python-Dev] Location of uname in os.py
Can anyone give me an idea as to where the function uname is located in os? This question is out-of-scope for python-dev; please use python-list instead when asking how something is currently implemented. However, there is an easy answer, so I'll give it anyway: it's implemented in Modules/posixmodule.c:posix_uname. Finding out why it still shows up in os is left as an exercise for the reader. 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
Re: [Python-Dev] on Python's tests (and making them better)
I think, and this is just my opinion, that if you are forced to do a linear search through the entire test suite in order to find the file you want, that perhaps the test suite needs a tad better organisation. Perhaps. However, if the linear search is then replaced with a recursive one, nothing is gained. 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] Python bug day (was Re: New Developer)
On Fri, 6 Jun 2008, Facundo Batista wrote: [...] Next week we'll have a Python Bug Weekend [3], it's a good moment to gain speed. [...] [3] http://wiki.python.org/moin/PythonBugDay That page says the next bug day will be on Sat, June 21st-22nd 2008, which is in two weeks' time. Has that plan changed? John ___ 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] on Python's tests (and making them better)
On Fri, Jun 6, 2008 at 6:19 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: (just to test your own intuition: when reversed() got added, was that more of a language change than when sys.meta_path got added?) I would say they were both core language changes. Anyway, I will happily drop this part of this proposal, since it such a small part. Regards, Martin -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] wrt the beta deadline and freelist management
On Wed, Jun 4, 2008 at 7:32 PM, Andrew MacIntyre [EMAIL PROTECTED] wrote: There are 2 disparate approaches to clearing/compacting free lists for basic types: - APIs of the form Pytype_ClearFreeList() called from gc.collect() [class, frame, method, tuple unicode types]; - APIs of the form Pytype_CompactFreeList() called from sys._compact_freelists() [int float types]; Both approaches are new for 2.6 3.0. The patch at http://bugs.python.org/issue2862 is geared towards bring the int/float free list management into line with the others. The patch at http://bugs.python.org/issue3029 adds free list management to the dict, list set types. The value of this is probably minor, and this patch is thus not significant in its own right other than for consistency. However Raymond's comment to issue 3029 that the management routines shouldn't be public APIs is IMO important ( I happen to agree). It would be nice to reduce the 2 approaches to one. I would rather the gc.collect() approach, as this seems to be more obvious to many users who have gone looking for free list management in prior versions, however my opinion isn't particularly valuable on this. Can this be resolved for 2.6/3.0? I agree with the gc.collect approach taken in your issue2862 patch. Barring any objections, I suggest we accept it and will commit it in the next couple days. -gps ___ 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] ABC issues
Guido van Rossum schrieb: On Mon, May 26, 2008 at 11:59 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: * The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc. Curious to hear what Guido thinks about this one. A nice use of the Mapping ABC is to be able to get 3.0 behaviors. I thought that was the whole point of all these backports. If the ABC gets altered, then it just makes the 2-to-3 conversion harder. It's wrong if the ABC doesn't describe the behavior of actual implementations; that is its primary purpose, the mixin class is a nice side benefit. We could make the incompatible mixin classes available separately though, if you think they're useful. * The 2.6 UserDict is not registered as a mapping. Since the API's are not currently the same, it makes sense that UserDict is not registered. If the Mapping ABC does get changed, only IterableUserDict should get registered. A regular UserDict does not comply. Fair enough. I recomment to fix the Mapping ABC and register IterableUserDict. As a followup: - The Mapping fix is in http://bugs.python.org/issue3057. - Registering IterableUserDict is now in SVN. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Different cpu python code usage between embedded mode and standalone mode
Hi list,
First Hello to all, I have a serious problem for understand some results
when I'm comparing cpu usages between same python code in embedded mode and
standalone mode ( python name_script.py )
This last months I have been writing a program in c like to mod_python for
embedding python language, it's a middleware for dispatch and execute python
batch programs into several nodes. Now I'm writing some python program for
test how scale this into several nodes and comparing with standalone
performance.
I found a very strange problem with one application named md5challenge, this
aplication try to calculate the max number md5 digest in several seconds,
md5challenge use a simple signal alarm for stop program when time has
passed. This is the code of python script
_nrdigest = 0
_const_b = 20
_f = None
_signal = False
def handler_alrm(signum, frame):
global _signal
global _nrdigest
global _f
_signal = True
def try_me():
global _nrdigest
global _f
global _signal
_f = open(/dev/urandom,r)
while _signal is not True:
buff = _f.read(_const_b)
md5.md5(buff).hexdigest()
_nrdigest = _nrdigest + 1
if _f is not None :
_f.close()
# Define entry point with one input variable
# req is a instance of Request object, usefull members of this object are:
# req.input is a dictionary with input.xml variables
# req.constants is a dictionary with constants defined into signature.xml
# req.output is void dictionary for full with output variables
# req.config is a dictionary with config values take from namespace
# req.apdn_pid is a pid of aplication
def main( req ):
global _nrdigest
signal.signal(signal.SIGALRM, handler_alrm)
signal.alarm(req.input['time'])
try_me()
req.output['count'] = _nrdigest
return req.OK
if __name__ == __main__:
# test code
class test_req:
pass
req = test_req()
req.input = { 'time' : 10 }
req.output = { 'ret' : 0, 'count' : 0 }
req.OK = 1
main(req)
print Reached %d digests % req.output['count']
When I try to run this program in standalone into my Pentium Dual Core
md5challenge reached 1.000.000 milion keys in 10 seconds but when i try to
run this code in embedded mode md5challenge reached about 200.000 more keys
!!! I repeat this test many times and always wins embedded mode !!!
What's happen ?
Also I tested to erase read dependencies from /dev/random, and calculate all
keys from same buffer. In this case embedded mode win always also, and the
difference are more bigger !!!
The alarm time expires in both case in 10 seconds.
Thks to all, can anybody help to me for understand this results ?
--
Pau Freixes
Linux GNU/User
___
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] Different cpu python code usage between embedded mode and standalone mode
This is not an issue for python-dev, but I have to ask: what do you
mean by embedded mode?
On Sat, Jun 7, 2008 at 10:14 AM, Pau Freixes [EMAIL PROTECTED] wrote:
Hi list,
First Hello to all, I have a serious problem for understand some results
when I'm comparing cpu usages between same python code in embedded mode and
standalone mode ( python name_script.py )
This last months I have been writing a program in c like to mod_python for
embedding python language, it's a middleware for dispatch and execute python
batch programs into several nodes. Now I'm writing some python program for
test how scale this into several nodes and comparing with standalone
performance.
I found a very strange problem with one application named md5challenge, this
aplication try to calculate the max number md5 digest in several seconds,
md5challenge use a simple signal alarm for stop program when time has
passed. This is the code of python script
_nrdigest = 0
_const_b = 20
_f = None
_signal = False
def handler_alrm(signum, frame):
global _signal
global _nrdigest
global _f
_signal = True
def try_me():
global _nrdigest
global _f
global _signal
_f = open(/dev/urandom,r)
while _signal is not True:
buff = _f.read(_const_b)
md5.md5(buff).hexdigest()
_nrdigest = _nrdigest + 1
if _f is not None :
_f.close()
# Define entry point with one input variable
# req is a instance of Request object, usefull members of this object are:
# req.input is a dictionary with input.xml variables
# req.constants is a dictionary with constants defined into signature.xml
# req.output is void dictionary for full with output variables
# req.config is a dictionary with config values take from namespace
# req.apdn_pid is a pid of aplication
def main( req ):
global _nrdigest
signal.signal(signal.SIGALRM, handler_alrm)
signal.alarm(req.input['time'])
try_me()
req.output['count'] = _nrdigest
return req.OK
if __name__ == __main__:
# test code
class test_req:
pass
req = test_req()
req.input = { 'time' : 10 }
req.output = { 'ret' : 0, 'count' : 0 }
req.OK = 1
main(req)
print Reached %d digests % req.output['count']
When I try to run this program in standalone into my Pentium Dual Core
md5challenge reached 1.000.000 milion keys in 10 seconds but when i try to
run this code in embedded mode md5challenge reached about 200.000 more keys
!!! I repeat this test many times and always wins embedded mode !!!
What's happen ?
Also I tested to erase read dependencies from /dev/random, and calculate all
keys from same buffer. In this case embedded mode win always also, and the
difference are more bigger !!!
The alarm time expires in both case in 10 seconds.
Thks to all, can anybody help to me for understand this results ?
--
Pau Freixes
Linux GNU/User
___
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] Mini-Pep: Simplifying the Integral ABC
I recommend switching back to __int__ and int; even in 2.5, these are expected to return either an int or a long as required. There's no need to mess with __long__ at all. On Fri, Jun 6, 2008 at 8:25 PM, Jeffrey Yasskin [EMAIL PROTECTED] wrote: Well, it seems like Integral instances should be able to be passed to either int() or long(), so __long__ should probably stay. I have no idea why I didn't include __int__, but its absence was probably the only reason __index__ calls long() instead of int(). On Fri, Jun 6, 2008 at 3:23 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; maybe he remembers? I'm guessing that adding __long__ was done since 2.6 supports it, and the removal of __int__ was an oversight. I also think that there's no reason to change __index__ to call long(); int() will automatically return a long as needed. Maybe changing __long__ back to __int__ is also harmless. On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: From: Guido van Rossum [EMAIL PROTECTED] Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ -- --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
[Python-Dev] Deprecate parser's ast functions?
The parser module exports each function and type twice, once with AST in the name, once with ST. Since AST now has a different meaning for Python code compilation, I propose to deprecate the ast variants in 2.6 and remove them in Python 3000. (Also, all keyword arguments are called ast, that cannot change in 2.6 but should in 3.0.) I'm at the moment changing the documentation of parser to only refer to the st variants anymore. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Modules for 2.6 inclusion
On 6 Giu, 13:27, Georg Brandl [EMAIL PROTECTED] wrote: - setuptools BDFL pronouncement for inclusion in 2.5: http://mail.python.org/pipermail/python-dev/2006-April/063964.html I'd like to see more interest about this issue since it's a real shame that the current distutils is not even able to solve dependencies and has such a poor integration with Pypi. Having a *valid* distribution tool like setuptools integrated with Python would be the first step to have one of the most important things Python is currently missing finally available: a centralized archive of softwares like Perl CPAN or Ruby Gems. IMHO this should be put on top of the TODO list and I'm honestly surprised it raised so little clamor so far. --- Giampaolo http://code.google.com/p/pyftpdlib ___ 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] Modules for 2.6 inclusion
Guilherme Polo schrieb: I created an issue 1 week ago (http://bugs.python.org/issue2983) suggesting the addition of the ttk module to lib-tk, and to the new tkinter package. Is there any chance to this be accepted for Python 2.6 ? This may be a good thing to have since it can show that Tkinter is not as dead (and dead ugly) as many people think it is. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] pep8ity __future__
Hi, That's just a flaming-sword thread but I want to mention it nonetheless :-) Basically I propose getting rid of __future__._Feature.getMandatoryRelease() in favour of __future__._Feature.mandatory. That's backwards compatibile and much more pythonic. Getters/Setters are considered unpythonic and the getting rid of all that Java-like naming sounds like a good idea to me :) If threading/processing gets a pep8ified API with 2.6, why not __future__? Proposed patch: http://paste.pocoo.org/show/64512/ Regards, Armin ___ 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
