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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 Py_ClearFreeList() called from gc.collect() > [class, frame, method, tuple & unicode types]; > - APIs of the form Py_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 [email protected] 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 [email protected] 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
[email protected]
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
> [email protected]
> 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
[email protected]
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 >>> [email protected] >>> 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
