Re: [Python-Dev] Using logging in the stdlib and its unit tests
Glenn Linderman g.nevcal.com> writes: > Or what am I missing? That threads are not necessarily dedicated to apps, in a real world setting. Depending on the server implementation, a single thread could be asked to handle requests for different apps over its lifetime. So the only way of knowing which threads are currently servicing a particular app is to maintain a set of them. Regards, Vinay Sajip ___ 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 logging in the stdlib and its unit tests
Vinay Sajip yahoo.co.uk> writes: > > Glenn Linderman g.nevcal.com> writes: > > > Or what am I missing? > And one more thing: the filters for *both* apps are called for a given request. One will return True, the other will return False. Bear in mind that the intention of the post is to be didactic, so it's possible there are some improvements that could be made when implementing for production. Regards, Vinay Sajip ___ 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 logging in the stdlib and its unit tests
On 12/9/2010 12:26 AM, Vinay Sajip wrote:
Glenn Linderman g.nevcal.com> writes:
> Or what am I missing?
That threads are not necessarily dedicated to apps, in a real world setting.
Depending on the server implementation, a single thread could be asked to handle
requests for different apps over its lifetime. So the only way of knowing which
threads are currently servicing a particular app is to maintain a set of them.
Agreed, they are not necessarily dedicated to apps. But while they are
running the app, they have the appname in their thread local storage,
no?So if a thread has the appname in its thread local storage, is it
not servicing that app, at that moment? And if it is, why is that
insufficient? That is my question, and you've sidestepped it.
And one more thing: the filters for*both* apps are called for a given request.
One will return True, the other will return False.
Bear in mind that the intention of the post is to be didactic, so it's possible
there are some improvements that could be made when implementing for production.
OK, I just learned what "didactic" meant, so you've taught me something.
I understood that both filters would be called. I understood, that in
production, it would probably not be necessary to log messages to both
the app log and the global log, that the global log would be there just
for things that are not app-specific.
But I still don't see a need to maintain a set of threads running the
app in the app object, if the app keeps track of what app it is running,
in a spot that is accessible to the filter (which it seems to be). I
don't see how it is beneficial to keep track of two separate data
structures that could serve the same purpose.
I realize you designed this in 10 minutes, and probably took twice that
long to write it up, so didn't necessarily analyze it for efficiency.
But I'm asking for that analysis now, if there is any real need for the
app to track the set of threads, _for the purpose of the problem being
solved_? I understand there might be other reasons for which that might
be useful, but for the logging it simply seems to be inefficient
redundancy... and if it isn't, then I don't understand the example, yet,
and I'm trying to.
So since you hand-waved, instead of giving a straight answer, and then
maybe your second message was an attempt to back-pedal a bit, not sure,
I went ahead and downloaded your code, made changes to remove the set of
threads as outlined (see modified functions below), and it seems to run
just as correctly. I thought it was an obvious question, while trying to
understand the code, and maybe learn about the logger, and I guess I
have, a little. And maybe some other things too. Please further
explain if I am still missing something. Under what conditions of the
problem you were solving does the code below fail?
class InjectingFilter(logging.Filter):
def __init__(self, app):
self.app = app
def filter(self, record):
record.method = tlocal.request.method
record.ip = tlocal.request.ip
record.appName = tlocal.appName
return record.appName == self.app.name
# tname = threading.currentThread().getName()
# return tname in self.app.threads
class WebApp:
def __init__(self, name):
self.name = name
self.threads = set()
handler = logging.FileHandler(name + '.log', 'w')
f = InjectingFilter(self)
handler.setFormatter(formatter)
handler.addFilter(f)
root.addHandler(handler)
self.num_requests = 0
def process_request(self, request):
tlocal.request = request
tlocal.appName = self.name
# tname = threading.currentThread().getName()
# self.threads.add(tname)
self.num_requests += 1
try:
logger.debug('Request processing started')
webapplib.useful()
logger.debug('Request processing finished')
finally:
pass
# self.threads.remove(tname)
___
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 logging in the stdlib and its unit tests
Glenn Linderman g.nevcal.com> writes: > Agreed, they are not necessarily dedicated to apps. But while they > are running the app, they have the appname in their thread local > storage, no? So if a thread has the appname in its thread local > storage, is it not servicing that app, at that moment? And if it > is, why is that insufficient? That is my question, and you've > sidestepped it. Sorry, I didn't mean to side-step: it's just that when reading your earlier post (on the Web using Gmane), all the lines of Python in your post ran together, so I didn't quite see what you were getting at. Having looked at it more carefully, you're right: the threads set is not needed. You can just "return tlocal.appName == self.app.name". I missed that, so thanks for teaching me something, too :-) Regards, Vinay Sajip ___ 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] [Python-checkins] r86855 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py
On 09/12/2010 03:45, Éric Araujo wrote: Hello, Author: raymond.hettinger Date: Mon Nov 29 02:38:25 2010 New Revision: 86855 Log: Do not add an obsolete unittest name to Py3.2. Modified: python/branches/py3k/Lib/unittest/case.py -# Old name for assertCountEqual() -assertItemsEqual = assertCountEqual When we merge distutils2 back into the stdlib, our tests will have to work with stdlib unittest in 3.3 or unittest2 for older Pythons (we’ll still make standalone releases for them). unittest2 doesn’t have assertCountEqual, unittest in 3.2+ doesn’t have assertItemsEqual, what’s the plan for compatibility? unittest2 will continue to track changes in unittest. A 0.6.0 release is planned, with feature parity with the version of unittest in Python 3.2. Of course if you want to help that would be much appreciated. :-) All the best, Michael Foord Regards -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] futures API
Hello, I am looking forward to replacing a piece of code (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86) by the futures module which was announced in python 3.2 beta. I am a bit stuck with it, so I have a few questions about the futures: 1. Is the futures API frozen? 2. How hard would it be to return the tasks processed in an output queue to process/consume the results while they are returned? The code does not seem to be very open for monkey patching. 3. How hard would it be to add new tasks dynamically (after a task is executed) and have the futures object never complete? 4. Is there a performance evaluation of the futures code (execution overhead) ? Thanks, Thomas ___ 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] OpenSSL Vulnerability (openssl-1.0.0a)
On 2010/11/25 1:23, exar...@twistedmatrix.com wrote: Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't released yet. ;) It seems OpenSSL 1.0.0c out. http://openssl.org/news/secadv_20101202.txt > 02-Dec-2010: Security Advisory: ciphersuite downgrade fix > 02-Dec-2010: OpenSSL 1.0.0c is now available, including important > bug and security fixes > 02-Dec-2010: OpenSSL 0.9.8q is now available, including important > bug and security fixes ___ 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] The fate of transform() and untransform() methods
On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum wrote: > On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote: .. >> I believe MAL's thought was that the addition of these methods had >> been approved pre-moratorium, but I don't know if that is a >> sufficient argument or not. > > It is not. > > The moratorium is intended to freeze the state of the language as > implemented, not whatever was discussed and approved but didn't get > implemented (that'd be a hole big enough to drive a truck through, as > the saying goes :-). > > Regardless of what I or others may have said before, I am not > currently a fan of adding transform() to either str or bytes. > I would like to restart the discussion under a separate subject because the original thread [1] went off the specific topic of the six new methods (2 methods x 3 types) added to builtins shortly before 3.2 beta was released. [2] The ticket that introduced the change is currently closed [3] even though the last message suggests that at least part of the change needs to be reverted. Note that reverting part of the patch is not entirely trivial because new codecs' documentation refers to bytes.[un]transform() both in the docstrings and the library reference. I think it will be the best to revert r86934 and resume the discussion of adding this functionality to 3.3 when we won't be constrained by the language moratorium. I will write a separate message with my thoughts about adding bytes codecs in 3.3. Let's keep this thread focused on what has to be done for 3.2. [1] http://mail.python.org/pipermail/python-dev/2010-December/106353.html [2] http://svn.python.org/view?view=rev&revision=86934 [3] http://bugs.python.org/issue7475 ___ 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] The fate of transform() and untransform() methods
Alexander Belopolsky wrote: > On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum wrote: >> On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray >> wrote: > .. >>> I believe MAL's thought was that the addition of these methods had >>> been approved pre-moratorium, but I don't know if that is a >>> sufficient argument or not. >> >> It is not. >> >> The moratorium is intended to freeze the state of the language as >> implemented, not whatever was discussed and approved but didn't get >> implemented (that'd be a hole big enough to drive a truck through, as >> the saying goes :-). >> >> Regardless of what I or others may have said before, I am not >> currently a fan of adding transform() to either str or bytes. >> > > I would like to restart the discussion under a separate subject > because the original thread [1] went off the specific topic of the six > new methods (2 methods x 3 types) added to builtins shortly before 3.2 > beta was released. [2] The ticket that introduced the change is > currently closed [3] even though the last message suggests that at > least part of the change needs to be reverted. That's for Guido to decide. The moratorium, if at all, would only cover the new methods, not the other changes (readding the codecs and fixing the codecs.py module to work with bytes as well as Unicode), all of which were already discussed at length in several previous discussion, on tickets and on python-dev. I don't see much point in going through the same discussions over and over again. Fortunately, I'm on vacation next week, so don't have to go through all this again ;-) Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 09 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] The fate of transform() and untransform() methods
On 09/12/2010 15:03, M.-A. Lemburg wrote: Alexander Belopolsky wrote: On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum wrote: On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote: .. I believe MAL's thought was that the addition of these methods had been approved pre-moratorium, but I don't know if that is a sufficient argument or not. It is not. The moratorium is intended to freeze the state of the language as implemented, not whatever was discussed and approved but didn't get implemented (that'd be a hole big enough to drive a truck through, as the saying goes :-). Regardless of what I or others may have said before, I am not currently a fan of adding transform() to either str or bytes. I would like to restart the discussion under a separate subject because the original thread [1] went off the specific topic of the six new methods (2 methods x 3 types) added to builtins shortly before 3.2 beta was released. [2] The ticket that introduced the change is currently closed [3] even though the last message suggests that at least part of the change needs to be reverted. That's for Guido to decide. Well, Guido *already* said no to transform / untransform in the previous thread. Michael The moratorium, if at all, would only cover the new methods, not the other changes (readding the codecs and fixing the codecs.py module to work with bytes as well as Unicode), all of which were already discussed at length in several previous discussion, on tickets and on python-dev. I don't see much point in going through the same discussions over and over again. Fortunately, I'm on vacation next week, so don't have to go through all this again ;-) Cheers, -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] futures API
On Thu, Dec 9, 2010 at 04:26, Thomas Nagy wrote: > Hello, > > I am looking forward to replacing a piece of code > (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86) by the > futures module which was announced in python 3.2 beta. I am a bit stuck with > it, so I have a few questions about the futures: > > 1. Is the futures API frozen? It will be once Python 3.2 final is released. -Brett > 2. How hard would it be to return the tasks processed in an output queue to > process/consume the results while they are returned? The code does not seem > to be very open for monkey patching. > 3. How hard would it be to add new tasks dynamically (after a task is > executed) and have the futures object never complete? > 4. Is there a performance evaluation of the futures code (execution overhead) > ? > > Thanks, > Thomas > > > > > ___ > 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/brett%40python.org > ___ 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] futures API
On 09/12/2010 16:36, Brett Cannon wrote: On Thu, Dec 9, 2010 at 04:26, Thomas Nagy wrote: Hello, I am looking forward to replacing a piece of code (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86) by the futures module which was announced in python 3.2 beta. I am a bit stuck with it, so I have a few questions about the futures: 1. Is the futures API frozen? It will be once Python 3.2 final is released. Now that 3.2 beta 1 is out the api is effectively frozen though, the only changes that should be made are bugfixes unless you can convince the release manager that an api change is really *essential*. Michael -Brett 2. How hard would it be to return the tasks processed in an output queue to process/consume the results while they are returned? The code does not seem to be very open for monkey patching. 3. How hard would it be to add new tasks dynamically (after a task is executed) and have the futures object never complete? 4. Is there a performance evaluation of the futures code (execution overhead) ? Thanks, Thomas ___ 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/brett%40python.org ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] The fate of transform() and untransform() methods
Michael Foord wrote: > On 09/12/2010 15:03, M.-A. Lemburg wrote: >> Alexander Belopolsky wrote: >>> On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum >>> wrote: On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote: >>> .. > I believe MAL's thought was that the addition of these methods had > been approved pre-moratorium, but I don't know if that is a > sufficient argument or not. It is not. The moratorium is intended to freeze the state of the language as implemented, not whatever was discussed and approved but didn't get implemented (that'd be a hole big enough to drive a truck through, as the saying goes :-). Regardless of what I or others may have said before, I am not currently a fan of adding transform() to either str or bytes. >>> I would like to restart the discussion under a separate subject >>> because the original thread [1] went off the specific topic of the six >>> new methods (2 methods x 3 types) added to builtins shortly before 3.2 >>> beta was released. [2] The ticket that introduced the change is >>> currently closed [3] even though the last message suggests that at >>> least part of the change needs to be reverted. >> That's for Guido to decide. >> > > Well, Guido *already* said no to transform / untransform in the previous > thread. I'm not sure he did and asked for clarification (see attached email). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 09 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ --- Begin Message --- Guido van Rossum wrote: > On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote: >> On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky >> wrote: >>> On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray >>> wrote: >>> .. Please also recall that transform/untransform was discussed before the release of Python 3.0 and was approved at the time, but it just did not get implemented before the 3.0 release. >>> >>> Can you provide a link? My search for transform on python-dev came out with >> >> It was linked from the issue, if I recall correctly. I do remember >> reading the thread from the python-3000 list, linked by someone >> somewhere :) >> >>> http://mail.python.org/pipermail/python-dev/2010-June/100564.html >>> >>> where you seem to oppose these methods. Also, new methods to builtins >> >> It looks to me like I was agreeing that transform/untrasnform should >> do only bytes->bytes or str->str regardless of what codec name you >> passed them. >> >>> fall under the language moratorium (but can be approved on a >>> case-by-case basis): >>> >>> http://www.python.org/dev/peps/pep-3003/#case-by-case-exemptions >>> >>> Is there an effort to document these exceptions? I expected such >>> approvals to be added to PEP 3003, but apparently this was not the >>> case. >> >> I believe MAL's thought was that the addition of these methods had >> been approved pre-moratorium, Indeed. >> but I don't know if that is a >> sufficient argument or not. > > It is not. > > The moratorium is intended to freeze the state of the language as > implemented, not whatever was discussed and approved but didn't get > implemented (that'd be a hole big enough to drive a truck through, as > the saying goes :-). Sure, but those two particular methods only provide interfaces to the codecs sub-system without actually requiring any major implementation changes. Furthermore, they "help ease adoption of Python 3.x" (quoted from PEP 3003), since the functionality they add back was removed from Python 3.0 in a way that makes it difficult to port Python2 applications to Python3. > Regardless of what I or others may have said before, I am not > currently a fan of adding transform() to either str or bytes. How should I read this ? Do want the methods to be removed again and added back in 3.3 ? Frankly, I'm a bit tired of constantly having to argue against cutting down the Unicode and codec support in Python3. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ___
Re: [Python-Dev] The fate of transform() and untransform() methods
On Thu, Dec 9, 2010 at 10:03 AM, M.-A. Lemburg wrote:
> Alexander Belopolsky wrote:
..
>> The ticket that introduced the change is
>> currently closed [3] even though the last message suggests that at
>> least part of the change needs to be reverted.
>
> That's for Guido to decide.
>
The decision will probably rest with the release manager, but Guido
has clearly voiced his opinion. Note that I deliberately removed the
codecs part form the subject, so that we can focus on the fate of
{str,bytes,bytearray}.{transform,untransform} methods. I don't see
any dispute about the fact that adding these methods breaks the
moratorium or any suggestion that a case-by-case exception has been
approved for this particular case. I don't think there is an option
to keep these methods. The two available options are:
1. Revert r86934.
2. Revert C code changes, but keep the codecs and remove references to
transform/untransform from documentation.
___
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] futures API
On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote: Hello, I am looking forward to replacing a piece of code (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86 ) by the futures module which was announced in python 3.2 beta. I am a bit stuck with it, so I have a few questions about the futures: 1. Is the futures API frozen? Yes. 2. How hard would it be to return the tasks processed in an output queue to process/consume the results while they are returned? The code does not seem to be very open for monkey patching. You can associate a callback with a submitted future. That callback could add the future to your queue. 3. How hard would it be to add new tasks dynamically (after a task is executed) and have the futures object never complete? I'm not sure that I understand your question. You can submit new work to an Executor at until time until it is shutdown and a work item can take as long to complete as you want. If you are contemplating tasks that don't complete then maybe you could be better just scheduling a thread. 4. Is there a performance evaluation of the futures code (execution overhead) ? No. Scott Dial did make some performance improvements so he might have a handle on its overhead. Cheers, Brian Thanks, Thomas ___ 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/brian%40sweetapp.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] The fate of transform() and untransform() methods
Alexander Belopolsky wrote: > On Thu, Dec 9, 2010 at 10:03 AM, M.-A. Lemburg wrote: >> Alexander Belopolsky wrote: > .. >>> The ticket that introduced the change is >>> currently closed [3] even though the last message suggests that at >>> least part of the change needs to be reverted. >> >> That's for Guido to decide. >> > The decision will probably rest with the release manager, but Guido > has clearly voiced his opinion. FYI: Georg explicitly asked me whether I would have the patch ready for 3.2 and since I didn't have time to work on it, he volunteered to implement it, which I'd like to thank him for ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 09 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] transform() and untransform() methods, and the codec registry
On Mon, Dec 6, 2010 at 3:39 AM, M.-A. Lemburg wrote:
> Guido van Rossum wrote:
>> The moratorium is intended to freeze the state of the language as
>> implemented, not whatever was discussed and approved but didn't get
>> implemented (that'd be a hole big enough to drive a truck through, as
>> the saying goes :-).
>
> Sure, but those two particular methods only provide interfaces
> to the codecs sub-system without actually requiring any major
> implementation changes.
>
> Furthermore, they "help ease adoption of Python 3.x" (quoted from
> PEP 3003), since the functionality they add back was removed from
> Python 3.0 in a way that makes it difficult to port Python2
> applications to Python3.
>
>> Regardless of what I or others may have said before, I am not
>> currently a fan of adding transform() to either str or bytes.
>
> How should I read this ? Do want the methods to be removed again
> and added back in 3.3 ?
Given that it's in 3.2b1 I'm okay with keeping it. That's at best a
+0. I'd be -0 if it wasn't already in. But anyway this should suffice
to keep it in unless there are others strongly opposed.
> Frankly, I'm a bit tired of constantly having to argue against
> cutting down the Unicode and codec support in Python3.
But transform() isn't really about Unicode or codec support -- it is
about string-to-string and bytes-to-bytes transformations. At least
the transform() API is clear about the distinction between codecs
(which translate between bytes and string) and transforms (which keep
the type unchanged) -- though I still don't like that the registries
for transforms and codecs use the same namespace. Also bytes-bytes and
string-string transforms use the same namespace even though the
typical transform only supports one or the other. E.g. IMO all of the
following should raise LookupError:
>>> b'abc'.transform('rot13')
Traceback (most recent call last):
File "", line 1, in
File "/Users/guido/p3/Lib/encodings/rot_13.py", line 16, in encode
return (input.translate(rot13_map), len(input))
TypeError: expected an object with the buffer interface
>>> b'abc'.decode('rot13')
Traceback (most recent call last):
File "", line 1, in
File "/Users/guido/p3/Lib/encodings/rot_13.py", line 19, in decode
return (input.translate(rot13_map), len(input))
AttributeError: 'memoryview' object has no attribute 'translate'
>>> 'abc'.encode('rot13')
Traceback (most recent call last):
File "", line 1, in
TypeError: encoder did not return a bytes object (type=str)
>>> b''.decode('rot13')
''
The latter may be a separate bug; b''.decode('anything') seems to not
even attempt to look up the codec.
--
--Guido van Rossum (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] transform() and untransform() methods, and the codec registry
On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum wrote:
..
> string-string transforms use the same namespace even though the
> typical transform only supports one or the other. E.g. IMO all of the
> following should raise LookupError:
>
b'abc'.transform('rot13')
> Traceback (most recent call last):
> ..
> return (input.translate(rot13_map), len(input))
> TypeError: expected an object with the buffer interface
This is actually *very* misleading because
>>> 'abc'.transform('rot13')
'nop'
works even though 'abc' is not "an object with the buffer interface".
>>> memoryview('abc')
Traceback (most recent call last):
..
TypeError: cannot make memory view because object does not have the
buffer interface
___
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] transform() and untransform() methods, and the codec registry
On Thu, 9 Dec 2010 13:55:08 -0500
Alexander Belopolsky wrote:
> On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum wrote:
> ..
> > string-string transforms use the same namespace even though the
> > typical transform only supports one or the other. E.g. IMO all of the
> > following should raise LookupError:
> >
> b'abc'.transform('rot13')
> > Traceback (most recent call last):
> > ..
> > return (input.translate(rot13_map), len(input))
> > TypeError: expected an object with the buffer interface
>
> This is actually *very* misleading because
>
> >>> 'abc'.transform('rot13')
> 'nop'
>
> works even though 'abc' is not "an object with the buffer interface".
Agreed. It was already pointed out in the parent thread.
I would say my opinion on keeping transform()/untransform() is +0 if
these error messages (and preferably the exception type as well) get
improved. Otherwise we'd better revert them and add a more polished
version in 3.3.
Regards
Antoine.
___
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] transform() and untransform() methods, and the codec registry
Le 09/12/2010 19:42, Guido van Rossum a écrit : > Given that it's in 3.2b1 I'm okay with keeping it. That's at best a > +0. [...] > though I still don't like that the registries for transforms and > codecs use the same namespace. Also bytes-bytes and > string-string transforms use the same namespace even though the > typical transform only supports one or the other. E.g. IMO all of the > following should raise LookupError: [...] Although I’d regret not having transform/untransform in 3.2, I think there needs to be a discussion about this namespace issue before the new methods ship. Regards ___ 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] Can't compile regex module with Python 3.2
On 09/12/2010 05:57, Alexander Belopolsky wrote: On Thu, Dec 9, 2010 at 12:47 AM, "Martin v. Löwis" wrote: .. However, in Python 3.2b1 the library python32.lib contains only _PyUnicode_IsWhitespace, therefore breaking the build. Is this change intentional? If so, why does unicodeobject.h still do the mapping? Are you sure about this? It's not intentional (except in the limited ABI). this does seem to be intentional: $ svn log -r 84177 r84177 | amaury.forgeotdarc | 2010-08-18 16:44:58 -0400 (Wed, 18 Aug 2010) | 9 lines #5127: Even on narrow unicode builds, the C functions that access the Unicode Database (Py_UNICODE_TOLOWER, Py_UNICODE_ISDECIMAL, and others) now accept and return characters from the full Unicode range (Py_UCS4). The differences from Python code are few: - unicodedata.numeric(), unicodedata.decimal() and unicodedata.digit() now return the correct value for large code points - repr() may consider more characters as printable. http://svn.python.org/view?view=rev&revision=84177 I have it compiling now. ___ 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] transform() and untransform() methods, and the codec registry
On Thu, Dec 9, 2010 at 2:17 PM, Antoine Pitrou wrote:
> On Thu, 9 Dec 2010 13:55:08 -0500
> Alexander Belopolsky wrote:
..
>> This is actually *very* misleading because
>>
>> >>> 'abc'.transform('rot13')
>> 'nop'
>>
>> works even though 'abc' is not "an object with the buffer interface".
>
> Agreed. It was already pointed out in the parent thread.
> I would say my opinion on keeping transform()/untransform() is +0 if
> these error messages (and preferably the exception type as well) get
> improved. Otherwise we'd better revert them and add a more polished
> version in 3.3.
Error messages is only one of the problems. User confusion over which
codec supports which types is another. Why, for example rot13 works
on str and not on bytes? It only affects ASCII range, so isn't it
natural to expect b'abc'.transform('rot13') to work? Well,
presumably this is so because Caesar did not know about bytes and his
"cypher" was about character shuffling. In this case, should't it
also shuffle other code points assigned to Latin letters? Given how
"useful" rot13 is in practice, I feel that it was only added to
justify adding str.transform().
There are other problems raised on the issue and not addressed in the
tracker discussion. For example, both Victor and I expressed concern
about having builitn methods that do import behind the scenes.
Granted, this issue already exists with encode/decode methods, but
these are usable without providing an explicit encoding and in this
form do not have side-effects.
Another problem is that with str.transform(), users are encouraged to
write programs in which data stored in strings is not always
interpreted as Unicode. For example, when I see a 'n' in a string
variable, it may actually mean 'a' because it has been scrambled by
rot13. Again, rot13 is not a realistic example, but as users are
encouraged to create their own string to string codecs, we may soon
find ourselves in the same mess as we have with 2.x programs trying to
support multiple locales.
As far as realistic examples go, Unicode transformations such as case
folding, normalization or decimal to ASCII translation have not been
considered in str.transform() design. The
str.transform/str.untransform pair may or may not be a good solution
for these cases. One obvious issue being that these transformations
are often not invertible.
I admit I have more questions than answers at this point, but a design
that adds the same two methods to three builtin types with very
different usage patterns (str, bytes and bytearray) does not seem to
be well thought out.
The str type already has 40+ methods many of which are not well-suited
to handle the complexities inherent in Unicode. Rather than rushing
in two more methods that will prove to be about as useful as
str.swapcase(), lets consider actual use cases and come up with a
design that will properly address them.
___
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] kill_python on windows buildbots
Hirokazu Yamamoto writes: > Yes, but test can freeze. In that case, I'm worried that > (snip) > rt.bat # freeze here (will be halt by buildbot) > vcbuild & kill_python_d # Will this be called? > in test.bat. Yeah, you're right. It may be impossible to completely eliminate the risk of a process getting stuck without doing something external to the build process, so long as the first thing a new build tries to do is an svn checkout that will fail if the process is still running. Having the kill operation in clean.bat covers the vast majority of the common cases with a minimum change, so seems the simplest. -- David ___ 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] [Python-checkins] r87145 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Fri, Dec 10, 2010 at 2:41 AM, raymond.hettinger wrote: > @@ -588,7 +593,12 @@ > pointing to the original callable function. This allows wrapped functions > to > be introspected. It also copies :attr:`__annotations__` if defined. And > now > it also gracefully skips over missing attributes such as :attr:`__doc__` > which > - might not be defined for the wrapped callable. > + might not be defined for the wrapped callable: > + > + >>> callable(max) > + True > + >>> callable(20) > + False Placeholder example? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] futures API
On Dec 9, 2010, at 9:02 AM, Brian Quinlan wrote: > > On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote: > >> Hello, >> >> I am looking forward to replacing a piece of code >> (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86) by >> the futures module which was announced in python 3.2 beta. I am a bit stuck >> with it, so I have a few questions about the futures: >> >> 1. Is the futures API frozen? > > Yes. Yes, unless the current API is defective in some way. A beta1 release is a chance for everyone to exercise the new API and discover whether it is problematic in any real world applications. > >> 2. How hard would it be to return the tasks processed in an output queue to >> process/consume the results while they are returned? The code does not seem >> to be very open for monkey patching. > > You can associate a callback with a submitted future. That callback could add > the future to your queue. The would be a good example for the docs. > >> 3. How hard would it be to add new tasks dynamically (after a task is >> executed) and have the futures object never complete? > > I'm not sure that I understand your question. You can submit new work to an > Executor at until time until it is shutdown and a work item can take as long > to complete as you want. If you are contemplating tasks that don't complete > then maybe you could be better just scheduling a thread. > >> 4. Is there a performance evaluation of the futures code (execution >> overhead) ? > > No. Scott Dial did make some performance improvements so he might have a > handle on its overhead. FWIW, the source code is short and readable. From my quick read, it looks to be a relatively thin wrapper/adapter around existing tools. Most of the work still gets done by the threads or processes themselves. Think of this as a cleaner, more centralized API around the current toolset -- there is no deep new technology under the hood. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87145 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Dec 9, 2010, at 2:18 PM, Nick Coghlan wrote: > On Fri, Dec 10, 2010 at 2:41 AM, raymond.hettinger > wrote: >> @@ -588,7 +593,12 @@ >> pointing to the original callable function. This allows wrapped functions >> to >> be introspected. It also copies :attr:`__annotations__` if defined. And >> now >> it also gracefully skips over missing attributes such as :attr:`__doc__` >> which >> - might not be defined for the wrapped callable. >> + might not be defined for the wrapped callable: >> + >> + >>> callable(max) >> + True >> + >>> callable(20) >> + False > > Placeholder example? > Trivial function begets a trivial example :-) If you think it warrants more, I'm open to suggestions. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sWAPcASE Was: transform() and untransform() methods, and the codec registry
On Dec 9, 2010, at 12:29 PM, Alexander Belopolsky wrote: > > The str type already has 40+ methods many of which are not well-suited > to handle the complexities inherent in Unicode. Rather than rushing > in two more methods that will prove to be about as useful as > str.swapcase(), lets consider actual use cases and come up with a > design that will properly address them. It would make me happy if we could agree to kill or at least mortally wound str.swapcase().I did some research on what it is go for and found that it is a vestige of an old word processor command to handle the case where a user accidentally left the caps lock key turned-on. AFAICT using Google's code search, it has nearly zero value for Python scripts. It does have a cost however, the code search turned-up many cases where people were writing string like objects and included swapcase() just so they could match the built-in API. It's time for swapcase() to go the way of the dinosaurs. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87145 - python/branches/py3k/Doc/whatsnew/3.2.rst
On 12/9/2010 5:45 PM, Raymond Hettinger wrote: On Dec 9, 2010, at 2:18 PM, Nick Coghlan wrote: On Fri, Dec 10, 2010 at 2:41 AM, raymond.hettinger wrote: @@ -588,7 +593,12 @@ pointing to the original callable function. This allows wrapped functions to be introspected. It also copies :attr:`__annotations__` if defined. And now it also gracefully skips over missing attributes such as :attr:`__doc__` which - might not be defined for the wrapped callable. + might not be defined for the wrapped callable: + +>>> callable(max) + True +>>> callable(20) + False Placeholder example? Trivial function begets a trivial example :-) If you think it warrants more, I'm open to suggestions. I think the issue is that the section is talking about functools.wraps, the example is for callable(). ___ 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] [Python-checkins] r86855 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py
Le 09/12/2010 11:57, Michael Foord a écrit : > unittest2 will continue to track changes in unittest. A 0.6.0 release is > planned, with feature parity with the version of unittest in Python 3.2. All right. We’ll just run a sed over our tests and bump our required unittest2 version. Thanks for the answer. > Of course if you want to help that would be much appreciated. :-) I would if I could, but I have my own synchronization to take care of :) Best regards ___ 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] OpenSSL Vulnerability (openssl-1.0.0a)
Am 09.12.2010 13:49, schrieb Hirokazu Yamamoto: > On 2010/11/25 1:23, exar...@twistedmatrix.com wrote: >> Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't >> released yet. ;) > > It seems OpenSSL 1.0.0c out. > > http://openssl.org/news/secadv_20101202.txt > >> 02-Dec-2010:Security Advisory: ciphersuite downgrade fix >> 02-Dec-2010:OpenSSL 1.0.0c is now available, including > important > bug and security fixes >> 02-Dec-2010:OpenSSL 0.9.8q is now available, including > important > bug and security fixes I don't plan upgrading the Windows build before 3.2; I have already patched the OpenSSL copy that we use. 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] sWAPcASE Was: transform() and untransform() methods, and the codec registry
On 12/9/2010 5:54 PM, Raymond Hettinger wrote:
It would make me happy if we could agree to kill or at least mortally wound
str.swapcase(). I did some research on what it is go for and found
that it is a vestige of an old word processor command to handle
the case where a user accidentally left the caps lock key turned-on.
AFAICT using Google's code search, it has nearly zero value for
Python scripts. It does have a cost however, the code search turned-up
many cases where people were writing string like objects and included
swapcase() just so they could match the built-in API.
It's time for swapcase() to go the way of the dinosaurs.
+1, assuming the normal deprecation process.
If we're looking to reduce the number of methods on str, I wouldn't mind
seeing center() and zfill() also go away, since they're trivially
replaced by format().
>>> '3'.zfill(10)
'03'
>>> format('3', '>010')
'03'
>>> '3'.center(10)
'3 '
>>> format('3', '^10')
'3 '
>>> '3'.center(10, '-')
'3-'
>>> format('3', '-^10')
'3-'
Although I'll grant this the case for the demise of center() and zfill()
isn't as strong as for swapcase(). It's truly useless.
Eric.
___
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] Can't compile regex module with Python 3.2
Am 09.12.2010 06:57, schrieb Alexander Belopolsky: > On Thu, Dec 9, 2010 at 12:47 AM, "Martin v. Löwis" wrote: > .. >>> However, in Python 3.2b1 the library python32.lib contains only >>> _PyUnicode_IsWhitespace, therefore breaking the build. >>> >>> Is this change intentional? If so, why does unicodeobject.h still do >>> the mapping? >> >> Are you sure about this? It's not intentional (except in the limited ABI). > > this does seem to be intentional: Oops, right; I was confusing this issue 8654. Then going back to the OP: Why exactly does that break the build? There should be no problem - you shouldn't see _PyUnicodeUCS2_IsWhitespace anywhere in 3.2. 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] [Python-checkins] r87145 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Fri, Dec 10, 2010 at 8:54 AM, Eric Smith wrote: > On 12/9/2010 5:45 PM, Raymond Hettinger wrote: >> Trivial function begets a trivial example :-) >> >> If you think it warrants more, I'm open to suggestions. > > I think the issue is that the section is talking about functools.wraps, the > example is for callable(). Yeah, sorry about that - I should have been clearer as to what I was asking about. It looks like the callable example had been copied to get the formatting started for the updated functools.wraps example, but the actual example for the latter didn't get filled in. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] sWAPcASE Was: transform() and untransform() methods, and the codec registry
On Thu, 09 Dec 2010 18:10:38 -0500 Eric Smith wrote: > On 12/9/2010 5:54 PM, Raymond Hettinger wrote: > > It would make me happy if we could agree to kill or at least mortally wound > > str.swapcase(). I did some research on what it is go for and found > > that it is a vestige of an old word processor command to handle > > the case where a user accidentally left the caps lock key turned-on. > > AFAICT using Google's code search, it has nearly zero value for > > Python scripts. It does have a cost however, the code search turned-up > > many cases where people were writing string like objects and included > > swapcase() just so they could match the built-in API. > > > > It's time for swapcase() to go the way of the dinosaurs. > > +1, assuming the normal deprecation process. > > If we're looking to reduce the number of methods on str, I wouldn't mind > seeing center() and zfill() also go away, since they're trivially > replaced by format(). Well, it's only trivial when you know format()'s wicked mini-language by heart :/ center() is easy and obvious. zfill() is arguably a bit too specialized. Regards Antoine. ___ 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] Can't compile regex module with Python 3.2
On Wed, Dec 8, 2010 at 6:56 PM, MRAB wrote: > Is this change intentional? If so, why does unicodeobject.h still do > the mapping? > In 3.2b1, unicodeobject.h doesn't map _PyUnicode_IsWhitespace: http://svn.python.org/view/python/tags/r32b1/Include/unicodeobject.h?view=markup Do you have an old unicodeobject.h somehow? -- Daniel Stutzbach ___ 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] Can't compile regex module with Python 3.2
On 09/12/2010 23:35, Daniel Stutzbach wrote: On Wed, Dec 8, 2010 at 6:56 PM, MRAB mailto:pyt...@mrabarnett.plus.com>> wrote: Is this change intentional? If so, why does unicodeobject.h still do the mapping? In 3.2b1, unicodeobject.h doesn't map _PyUnicode_IsWhitespace: http://svn.python.org/view/python/tags/r32b1/Include/unicodeobject.h?view=markup Do you have an old unicodeobject.h somehow? Basically, yes. I'm already having to deal with 2.5, 2.6, 2.7 and 3.1, and there was a mismatch between older 3.2 files from the trunk downloaded a while back and the 3.2b1 .lib file. It all seems to be working now. ___ 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] API for the new sysconfig module
Does anyone know why this needed a separate module and so many accessor
functions?
ISTM it mostly could have been reduced to single call returning a nested
dictionary.
Raymond
from sysconfig import *
import json
def sysconf():
return dict(paths = get_paths(),
config_vars = get_config_vars(),
platform = get_platform(),
version = get_python_version(),
scheme_names = get_scheme_names(),
)
print(json.dumps(sysconf(), indent=2))
{
"config_vars": {
"EXE": ".exe",
"VERSION": "32",
"py_version_nodot": "32",
"exec_prefix": "C:\\Python32",
"platbase": "C:\\Python32",
"userbase": "C:\\Documents and Settings\\Raymond\\Application
Data\\Python",
"LIBDEST": "C:\\Python32\\Lib",
"py_version_short": "3.2",
"prefix": "C:\\Python32",
"base": "C:\\Python32",
"SO": ".pyd",
"projectbase": "C:\\Python32",
"BINLIBDEST": "C:\\Python32\\Lib",
"srcdir": "C:\\Python32",
"py_version": "3.2b1",
"abiflags": "",
"INCLUDEPY": "C:\\Python32\\Include",
"BINDIR": "C:\\Python32"
},
"platform": "win32",
"version": "3.2",
"scheme_names": [
"nt",
"nt_user",
"os2",
"os2_home",
"osx_framework_user",
"posix_home",
"posix_prefix",
"posix_user"
],
"paths": {
"platinclude": "C:\\Python32\\Include",
"platstdlib": "C:\\Python32\\Lib",
"platlib": "C:\\Python32\\Lib\\site-packages",
"purelib": "C:\\Python32\\Lib\\site-packages",
"stdlib": "C:\\Python32\\Lib",
"scripts": "C:\\Python32\\Scripts",
"include": "C:\\Python32\\Include",
"data": "C:\\Python32"
}
}
___
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] futures API
On Dec 9, 2010, at 2:39 PM, Raymond Hettinger wrote: On Dec 9, 2010, at 9:02 AM, Brian Quinlan wrote: On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote: Hello, I am looking forward to replacing a piece of code (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86 ) by the futures module which was announced in python 3.2 beta. I am a bit stuck with it, so I have a few questions about the futures: 1. Is the futures API frozen? Yes. Yes, unless the current API is defective in some way. A beta1 release is a chance for everyone to exercise the new API and discover whether it is problematic in any real world applications. 2. How hard would it be to return the tasks processed in an output queue to process/consume the results while they are returned? The code does not seem to be very open for monkey patching. You can associate a callback with a submitted future. That callback could add the future to your queue. The would be a good example for the docs. I don't know what Thomas' use case is but I expect that taking the results of a future and asynchronously sticking it in another queue is not typical. Cheers, Brian 3. How hard would it be to add new tasks dynamically (after a task is executed) and have the futures object never complete? I'm not sure that I understand your question. You can submit new work to an Executor at until time until it is shutdown and a work item can take as long to complete as you want. If you are contemplating tasks that don't complete then maybe you could be better just scheduling a thread. 4. Is there a performance evaluation of the futures code (execution overhead) ? No. Scott Dial did make some performance improvements so he might have a handle on its overhead. FWIW, the source code is short and readable. From my quick read, it looks to be a relatively thin wrapper/adapter around existing tools. Most of the work still gets done by the threads or processes themselves. Think of this as a cleaner, more centralized API around the current toolset -- there is no deep new technology under the hood. 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/brian%40sweetapp.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
[Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)
On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou wrote:
> On Thu, 09 Dec 2010 18:10:38 -0500
> Eric Smith wrote:
>> If we're looking to reduce the number of methods on str, I wouldn't mind
>> seeing center() and zfill() also go away, since they're trivially
>> replaced by format().
>
> Well, it's only trivial when you know format()'s wicked mini-language by
> heart :/ center() is easy and obvious. zfill() is arguably a bit too
> specialized.
I've occasionally wondered if string formatting [1] and the struct
module [2] would benefit from format building functions that made them
easier to use without necessarily learning the cryptic mini-languages
off by heart.
For example, a "string.make_format_spec" function might have a signature like:
def make_format_spec(fill=None, align=None, sign=None, width=None,
precision=None, display_type='s', alternate=False, commas=False,
numeric_case=None)
"align" would accept not only the actual format symbols ('<', '>',
'=', '^'), but also the corresponding names ('left', 'right',
'numeric', 'center').
"numeric_case" would accept None, 'upper' or 'lower' (affecting the
formatting of hex and floating point values). If the stated numeric
case differs from that specified by the display type, raise a
ValueError. For an unspecified numeric case, the affected display
types would default to 'lower'.
Similarly, "display_type" would accept long names in addition to the
character codes:
's': 'str'
'b': 'binary'
'c': 'chr'
'd': 'int'
'o': 'octal'
'x', 'X': 'hex' (numeric case controls display of digits A-F)
'n': 'locale'
'e', 'E': 'exponent' (numeric case controls display of exponent as
well as infinite and NaN values)
'f', 'F': 'float' (numeric case controls display of exponent as well
as infinite and NaN values)
'g', 'G': 'general' (numeric case controls display of exponent as well
as infinite and NaN values)
'%': 'percent' (numeric case controls display of exponent as well as
infinite and NaN values)
There could also be a corresponding parse_format_spec that produced a
named tuple with the appropriate details.
Cheers,
Nick.
[1] http://docs.python.org/dev/library/string#format-specification-mini-language
[2] http://docs.python.org/dev/library/struct#format-strings
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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] API for the new sysconfig module
On Fri, Dec 10, 2010 at 10:18 AM, Raymond Hettinger wrote: > Does anyone know why this needed a separate module and so many accessor > functions? > ISTM it mostly could have been reduced to single call returning a nested > dictionary. Tarek will likely answer for himself, but I believe it is a matter of providing like-for-like replacements of existing distutils APIs, specifically: http://docs.python.org/dev/distutils/apiref.html#module-distutils.sysconfig The old way required source code available ability at runtime, the new sysconfig module captures everything it needs at build time. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] sWAPcASE Was: transform() and untransform() methods, and the codec registry
On Thu, Dec 9, 2010 at 2:54 PM, Raymond Hettinger wrote: > > On Dec 9, 2010, at 12:29 PM, Alexander Belopolsky wrote: > > The str type already has 40+ methods many of which are not well-suited > to handle the complexities inherent in Unicode. Rather than rushing > in two more methods that will prove to be about as useful as > str.swapcase(), lets consider actual use cases and come up with a > design that will properly address them. > > It would make me happy if we could agree to kill or at least mortally wound > str.swapcase(). I did some research on what it is go for and found > that it is a vestige of an old word processor command to handle > the case where a user accidentally left the caps lock key turned-on. > AFAICT using Google's code search, it has nearly zero value for > Python scripts. It does have a cost however, the code search turned-up > many cases where people were writing string like objects and included > swapcase() just so they could match the built-in API. > It's time for swapcase() to go the way of the dinosaurs. I fully admit the mistakes I made by introducing swapcase() and a few other weird string methods. It happened many eons ago; before they were string methods they were functions in the "string" module. At the same time I cannot bring up any enthusiasm for trying to kill these off. The cost of the deprecation process is probably more than the cost of keeping them around, if you integrate over the entire community for t -> infinity. I don't see them as harmful. We had our chance to kill them in Py3k, and we didn't. -- --Guido van Rossum (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] Using logging in the stdlib and its unit tests
On Tue, Dec 7, 2010 at 5:51 PM, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > Indeed - I was very surprised to find just now that calling
> > "logging.warn('Whatever')" is not the same as doing "log =
> > logging.getLogger(); log.warn('Whatever')".
>
> Don't know why you'd be surprised: it's been that way since logging was
> added to
> Python, and the logging.debug() etc. are documented as convenience methods
> for
> casual use in throwaway scripts, interactive sessions etc. The convenience
> is in
> that you don't need to specify a logger (the root logger is used) and that
> basicConfig() is called for you.
>
Hahaha. :) Well, I won't be suggesting to anyone at work that we throw away
our entire bazillion line codebase just because all of it happily relies on
logging.{debug,info,warn,error,exception} functions and all log messages go
through a single root logger.
I'd argue that anyone using a multi-logger hierarchy has already implemented
overkill and that the default for anyone wanting to log something should be
to simply call the above functions directly from the logging module.
This simplistic easy usage somewhat echo's Glenn's comment on this thread
about logging seeming way to daunting as presented today. It needn't be.
-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] Using logging in the stdlib and its unit tests
On Wed, Dec 8, 2010 at 9:51 AM, Glenn Linderman
> wrote:
> On 12/8/2010 4:15 AM, Vinay Sajip wrote:
>
> You're complaining about too much documentation?! Don't measure it by weight!
>
> On 12/8/2010 5:57 AM, Vinay Sajip wrote:
>
> Of course I understand I could be wrong
> about this, but I don't recall when a stdlib maintainer has said to me, "I
> want
> to start using logging in stdlib module XXX, but can't justify it because ..."
>
>
> So I'm a fairly new Python user, but 30 years programming experience.
>
> When I first looked at the Python logging facility (and again today, when I
> looked again), I found a simple example of debugging logging. Then a bunch
> of stuff about how to configure rotating logs. Then something about logging
> levels. And then a dissertation on the theory of loggers "The logging
> library takes a modular approach and offers the several categories of
> components: loggers, handlers, filters, and formatters." And I hadn't
> gotten through 10% of the documentation yet, per the scrollbar.
>
> My reaction the first time was "Sounds sophisticated and complex. I think
> I'll do something simpler for now, and maybe someday, when I have a spare
> week, I'll read the documentation and see if the benefits are worth the
> effort."
>
> OK, so now you've discovered that too much documentation can be a turn
> off... at least, if it is presented from the top to describe the
> sophistication of the facility, rather than how easy it is to use (if it is,
> I still haven't gotten to 10%, and I still don't know that).
>
Exactly. All I ever recommend people do is:
import logging
...
logging.warn('doing something a bit odd.')
...
for x in thing:
logging.debug('working on %r', x)
...
And be done with it. If they are controlling their __main__ they'll
probably want to call a common function to setup the log message formatting
and where it gets written to from there. Otherwise ignore that and leave
that up to the person using your library (directly, indirectly or otherwise)
to do that in their __main__ code.
For logging to be useful it needs to be dirt simple. The above is.
-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
