[Python-Dev] Proposal: from __future__ import unicode_string_literals
Eric Smith wrote: > It's not implementable because the work has to occur in ast.c (see > Py_UnicodeFlag). It can't occur later, because you need to skip the > encoding being done in parsestr(). But the __future__ import can only > be interpreted after the AST is built, at which time the encoding has > already been applied. There are some radical things you could do to > work around this, but it would be a gigantic change. Oh, ! > Pretty much. And even if it were possible, I don't see the point in > doing it. The point is this: http://regebro.wordpress.com/2008/03/22/why-python-26-and-30-compatibility-would-be-a-very-good-thing/ Basically, the 2to3 strategy on large codebases supported by a wide set of developers isn't likely to be maintanable, and without a gradual path forward, 3.0 isn't likely to be adopted in some parts of the Python community. Worst case this splits the efforts of the community into two groups, which would be damaging to Python as a whole. Howver: If 2.6 doesn't support this it's not the end of the world. Because if it turn out to be necessary, a 2.7 that does could always be released. I don't know about other large codebases like Twisted, but the Zope/Plone world isn't likely to even try moving to 3.0 any time soon after it's final release, so since it's complicated you can probably wait with this support until it turns out to be needed. M.-A. Lemburg wrote: > Could we point them to a special byte-code compiler such as Andrew > Dalke's python4ply: ??? I'm not sure what this means... :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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] Distutils patches review request
Hi, I would like to make request for a review of three patches: #2385: fixes a run_setup bug, and adds a test_core module, that can be used later to improve core.py coverage (http://bugs.python.org/issue2385) #2461: adds a test_util.py to distutils, to cover util.py. It does not cover byte_compile yet, but others are covered. (http://bugs.python.org/issue2461) #1858 (http://bugs.python.org/issue1858): - makes .pypirc support multiple servers (see http://wiki.python.org/moin/EnhancedPyPI) - superseeds #1741 (see http://bugs.python.org/issue1741) - superseeds #2166 ( see http://bugs.python.org/issue2166) - adds unit tests for upload and register (test_upload, test_register) Best regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.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] Proposal: from __future__ import unicode_string_literals
On Sun, Mar 23, 2008 at 8:37 AM, Lennart Regebro <[EMAIL PROTECTED]> wrote: > Eric Smith wrote: > > It's not implementable because the work has to occur in ast.c (see > > Py_UnicodeFlag). It can't occur later, because you need to skip the > > encoding being done in parsestr(). But the __future__ import can only > > be interpreted after the AST is built, at which time the encoding has > > already been applied. There are some radical things you could do to > > work around this, but it would be a gigantic change. > > Oh, ! > I don't believe this to be true (we can simply store the source encoding information (which it might already be) and translate the *use* of string literals into unicode(literal, encoding).) But I still think this is a bad idea. Using the same codebase for 3.0 and 2.6 will leave you with inefficient and fragile code in one of the two codebases -- quite likely both. I know, I've tried. I don't see how it improves maintainability to leave your source full of forward- and backward-compatibility hacks. 3.0 was meant to be a clean break. Please treat it as such. Yes, that means you can't run the same source tree in two different Python versions -- too bad. It means adding a compilation-style step to one of the two Python versions -- too bad. It's quite easily automated, as proven by the vast majority of programming languages out there, which need such a step anyway. > > Howver: If 2.6 doesn't support this it's not the end of the world. > Because if it turn out to be necessary, a 2.7 that does could always > be released. I don't know about other large codebases like Twisted, > but the Zope/Plone world isn't likely to even try moving to 3.0 any > time soon after it's final release, so since it's complicated you can > probably wait with this support until it turns out to be needed. > That was always the assumption, and also the idea for 2.6 and 2.7. I would much rather 3.0 isn't widely accepted for a few years longer than that it be cluttered with backward compatibility crap, and even rather than that widely used code be riddled with such. But it's up to Guido in the end. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] r61796 - in python/trunk: Doc/library/random.rst Lib/random.py Lib/test/test_random.py Misc/NEWS
> +## triangular > + > +def triangular(self, low, high, mode): > +"""Triangular distribution. > + > +Continuous distribution bounded by given lower and upper limits, > +and having a given mode value in-between. > + > +http://en.wikipedia.org/wiki/Triangular_distribution > + > +""" > +u = self.random() > +c = (mode - low) / (high - low) > +if u > c: > +u = 1 - u > +c = 1 - c > +low, high = high, low > +return low + (high - low) * (u * c) ** 0.5 > + Would it be worth having default values on the parameters for this? def triangular(self, low=0, high=1, mode=None): u = self.random() if mode is None: c = 0.5 else: c = (mode - low) / (high - low) if u > c: u = 1 - u c = 1 - c low, high = high, low return low + (high - low) * (u * c) ** 0.5 At the very least, supporting mode=None would be convenient when you want a symmetric triangular distribution - having to calculate the median, pass it in as the mode, then have the function reverse that to get 0.5 seems a little wasteful. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] How we can get rid of eggs for 2.6 and beyond
On Sat, Mar 22, 2008 at 09:13:24PM +0100, "Martin v. L?wis" wrote: > Unfortunately no. I was looking for it, but couldn't find it. He > mentioned a website with a "call for action", but I couldn't find > that, either :-( We're working on the video, but I think it'll be a few weeks before things start to get posted. --amk ___ 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] State of N-dimensional array interface
Hi Mike. Travis is the best person to discuss the status of the buffer APIs. Cheers, n On Sat, Mar 22, 2008 at 2:50 PM, Mike Sullivan <[EMAIL PROTECTED]> wrote: > What is the current state of the N-D Array Interface proposal > (http://numpy.scipy.org/array_interface.shtml). Some work was done on > this in an earlier Summer of Code, but it seems to never have been > included. Does anybody know what state that work is in and what > prevented it's inclusion? > > (I am interested in completing this as a Summer of Code project. I > posted about this on the SOC list, and received a suggestion to try > asking python-dev.) > > -- > Mike Sullivan > ___ > 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/nnorwitz%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond
On Mar 22, 5:13 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Unfortunately no. I was looking for it, but couldn't find it. He > mentioned a website with a "call for action", but I couldn't find > that, either :-( As I tried to reply (in a message that is waiting for moderation), the site seems to be http://www.toolness.com/wp/?p=23 ___ 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] How we can get rid of eggs for 2.6 and beyond
A.M. Kuchling wrote: > On Sat, Mar 22, 2008 at 09:13:24PM +0100, "Martin v. L?wis" wrote: >> Unfortunately no. I was looking for it, but couldn't find it. He >> mentioned a website with a "call for action", but I couldn't find >> that, either :-( > > We're working on the video, but I think it'll be a few weeks before > things start to get posted. Could you ask him whether he can put his slides online then, somewhere? Same for the other speakers, I guess. 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] Proposal: from __future__ import unicode_string_literals
On Sun, Mar 23, 2008 at 2:13 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > That was always the assumption, and also the idea for 2.6 and 2.7. I would > much rather 3.0 isn't widely accepted for a few years longer than that it be > cluttered with backward compatibility crap, and even rather than that widely > used code be riddled with such. But it's up to Guido in the end. Sure but this is a bit misleading. The risk isn't that 3.0 is not widely accepted quickly. The risk is that the community splits in two. And the suggestion is not for backwards compatibility in 3.0, but forwards compatibility in 2.6. So the question is rather: Do you want to disk a community split, or add forwards compatibility? But as I noted, if it turns out to be necessary to add that forwards compatibility, it's always possible to do a 2.7 that has it. I have loads of experience in writing code for evolving APIs, this is how things have been done in the Zope community for years. It's not a problem. It does not lead to fragile code. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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] How we can get rid of eggs for 2.6 and beyond
ajaksu wrote: > On Mar 22, 5:13 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Unfortunately no. I was looking for it, but couldn't find it. He >> mentioned a website with a "call for action", but I couldn't find >> that, either :-( > > As I tried to reply (in a message that is waiting for moderation), the > site seems to be http://www.toolness.com/wp/?p=23 Thanks! That's the one. (hopefully, this one gets through the moderation) 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] Making sys.py3k_warning writable
On Sat, Mar 22, 2008 at 2:58 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Steven Bethard wrote: > > Right now, test_py3kwarn only runs if the test suite is run using the > > -3 command line flag to Python. So for most regrtest runs (e.g. the > > buildbots) this test will never be run. > > For the buildbots, it would be easy to turn -3 on, though. Right now, running the test suite with -3 spews a load of warnings since there is a lot of code that hasn't been updated for even simple things like ``dict.has_key``. Would turning the -3 flag on make it too hard to diagnose problems? If people don't think so, I'm happy to have it turned on. I did find a minor bug in the test suite when I turned it on and ran the full regrtest. On Sat, Mar 22, 2008 at 3:29 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: [http://bugs.python.org/issue2458] Thanks for putting that together! Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Making sys.py3k_warning writable
> Would turning the -3 flag on make it too hard to diagnose problems? Yes. I don't think it should be turned on regularly in the tests until they regularly are quiet under -3. 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] Backport of bytearray type and io module
Hello! I've successfully back ported the bytearray type and the io module from 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm down to four failing byte tests and one failing io test. The failing byte tests are all related to pickling and subclassing. I like to get the remaining tests fixed for the upcoming release in a week. Please checkout the branch and help me figure out the remaining issues. Christian [1] svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-bytearray ___ 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] Fixing code that produces -3 warnings in the Python 2.6 stdlib
On Sun, Mar 23, 2008 at 3:02 PM, "Martin v. Löwis" wrote: [talking about running the buildbots using the -3 flag to issue Py3K warnings] > Yes. I don't think it should be turned on regularly in the tests until > they regularly are quiet under -3. So the plan is to silence all Py3K warnings in the Python 2.6 stdlib? I'd like to see this happen, but I vaguely remembered some people being against this idea, so I'd like to make sure. For what it's worth, I started an issue for this earlier: http://bugs.python.org/issue2402 Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Proposal: from __future__ import unicode_string_literals
> So the question is rather: Do you want to disk a community split, or > add forwards compatibility? I don't think the risk is big. As far as people start saying "I will only support Python 3", or saying "I will not support Python 3" - that's fine. In the former case, people can still continue to use the old versions of the software (assuming we are talking about open source here), and continue to use those with 2.x. They won't get all the new features, and perhaps that is a reason for them to move to 3.x. In the latter case, people relying on the library either have to stay with 2.x until all their dependencies get ported, or they will have to contribute 3.x ports themselves to the developers. In some cases, this may cause a fork of the project, but I guess these cases are rare (and occur only if the maintainer is not cooperative in at least incorporating patches even if its for stuff he doesn't care about). So in short: no, the risk that the community splits is very small. When people contribute code, it's not because of care about the community, but because of their own needs. That's how open-source software works. 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] Fixing code that produces -3 warnings in the Python 2.6 stdlib
Steven Bethard wrote: > On Sun, Mar 23, 2008 at 3:02 PM, "Martin v. Löwis" wrote: > [talking about running the buildbots using the -3 flag to issue Py3K warnings] >> Yes. I don't think it should be turned on regularly in the tests until >> they regularly are quiet under -3. > > So the plan is to silence all Py3K warnings in the Python 2.6 stdlib? I don't know; I don't have this plan. I'm only saying that it shouldn't be turned on in the test suite if it triggers a lot of noise. 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] Making sys.py3k_warning writable
>> Would turning the -3 flag on make it too hard to diagnose problems? Martin> Yes. I don't think it should be turned on regularly in the tests Martin> until they regularly are quiet under -3. Maybe regrtest should gain a -3 flag. All it would have to do is restart itself moving the -3 from after regrtest to before it. Skip ___ 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] Making sys.py3k_warning writable
skip> Maybe regrtest should gain a -3 flag. All it would have to do is skip> restart itself moving the -3 from after regrtest to before it. Ehh... That didn't seem like such a great idea about 10 seconds after I hit send. Adding a test3 target to Makefile.pre.in is a lot easier. Skip ___ 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] Proposal: from __future__ import unicode_string_literals
On Sun, Mar 23, 2008 at 10:45 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > So the question is rather: Do you want to disk a community split, or > > add forwards compatibility? > > I don't think the risk is big. As far as people start saying "I will > only support Python 3", or saying "I will not support Python 3" - that's > fine. No, it isn't. That's the whole thing. It isn't fine. > In the latter case, people relying on the library either have to stay > with 2.x until all their dependencies get ported, or they will have > to contribute 3.x ports themselves to the developers. You are still only seeing this as a case of libraries with a small number of people developing them and making regular well defined releases. That is not how the world I am talking about looks. I repeat: I have no doubt the 2to3 approach works well in that case, if you want to support both 2.6 and 3.0. > So in short: no, the risk that the community splits is very small. No, it is a significant risk. Don't brush it away. We do NOT end up having a 2.x python world and a 3.x python world. The community doesn't have the resources to maintain momentum in a language if the energy is divided in half. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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] Proposal: from __future__ import unicode_string_literals
> You are still only seeing this as a case of libraries with a small > number of people developing them and making regular well defined > releases. That is not how the world I am talking about looks. Can you give me examples of such software? Are you perhaps talking about closed source software? 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] Making sys.py3k_warning writable
So, regarding -3 warnings in the 2.6 test code, should they be fixed or not? Skip ___ 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] Making sys.py3k_warning writable
On Sun, Mar 23, 2008 at 6:21 PM, <[EMAIL PROTECTED]> wrote: > > So, regarding -3 warnings in the 2.6 test code, should they be fixed or > not? I think we should introduce a decorator and/or a context manager in test_support like this: def silence_py3k(func): def decorator(*args, **kwargs): sys.disablepy3kwarning() func(*args, **kwargs) sys.enablepy3kwarning() return decorator Of course, this depends on my patch in issue 2458. I think we could also do it with warnings.simplefilter. > > > Skip > > ___ > 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/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson ___ 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] r61709 - python/trunk/Doc/library/functions.rst python/trunk/Doc/library/future_builtins.rst python/trunk/Doc/library/python.rst
What is the precise specification of the builtin "print" function. Does it call "str", or does it just behave as if the builtin str had been called? In 2.5, the print statement ignores any overrides of the str builtin, but I'm not sure whether a _function_ should -- and I do think it should be specified. -jJ On 3/21/08, georg.brandl <[EMAIL PROTECTED]> wrote: > New Revision: 61709 == > +++ python/trunk/Doc/library/functions.rst Fri Mar 21 20:37:57 2008 > @@ -817,6 +817,33 @@ ... > +.. function:: print([object, ...][, sep=' '][, end='\n'][, file=sys.stdout]) ... > + All non-keyword arguments are converted to strings like :func:`str` does ___ 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] Proposal: from __future__ import unicode_string_literals
On Mon, 24 Mar 2008 00:14:13 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >> You are still only seeing this as a case of libraries with a small >> number of people developing them and making regular well defined >> releases. That is not how the world I am talking about looks. > >Can you give me examples of such software? Are you perhaps talking >about closed source software? I'm not sure what software he was talking about. I can say that for the work I do on both Twisted and Divmod software, I'd be quite happy to see this feature. As either part of a migration path towards 3k _or_ as a feature entirely on its own merits, this would be very useful to me. I'm a bit curious about why Thomas said this sort of thing results in fragile code. Twisted has been using __future__ imports for years and they've never been a problem. Twisted currently supports Python 2.3 through Python 2.5, and the only thing that's really difficult about that is subtle changes in library behavior, not syntax. I'm also curious about why Lennart thinks that this would only be relevant for large projects with lots of developers making regular releases. Sure, I'd use it in that scenario, but that's because it's a subset of "all development". ;) Jean-Paul ___ 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] windows standard [was: PEP 365 (Adding the pkg_resources module)]
Terry Reedy > The standard (and to me, preferable) way of dealing > with such things is to have an 'installation manager' > that can reinstall as well as delete and that has a > check box for various things to delete. This is what > Python needs. Paul Moore: > I'd dispute strongly that this is a "standard". > It may be preferable, but I'm not sure where you > see evidence of it being a standard. When I install a large program (such as developer tools, or python itself) on Windows, I expect a choice of "default" or "custom". When I choose custom, I expect a list of components, which can be chosen, not chosen, or mixed (meaning that it has subcomponents, only some of which are chosen). The whole thing only shows up once in Add/Remove programs. If I select it, I do get options to Change or Repair. These let me change my mind on which subcomponents are installed. If I install python and then separately install Zope, it may or may not make sense for Zope to be listed separately as a "program" to Add or Remove. It does not make sense (to me anyhow) have several individual packages within Zope each listed independently at the Windows level. (Though, to be fair, many (non-python) applications *do* make more than one entry.) -jJ ___ 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
