Re: [Python-Dev] readd u'' literal support in 3.3?
On Tue, Dec 13, 2011 at 14:33, Laurence Rowe l...@lrowe.co.uk wrote: Could this manual work be cut down if there was a version of 2to3 that targeted the subset of the language that is compatible with both 2 and 3? Not really, but a 2to6, ie something that tries to keep Python 2 compatibility by using the six library, might be useful. //Lennart ___ 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] readd u'' literal support in 3.3?
On Tue, Dec 13, 2011 at 23:38, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: More specifically six [1] is the name of Benjamin Peterson's support package to help write code that works on both 2 and 3. So the idea is that the conversion isn't just a straight syntax conversion - but that it [could] generate code using this library. The thing is, the code you want to generate varies depending on whether you want to target 2.6+, or include 2.5 and earlier. Sure. This is different fixers, and then script to run it could have a parameter for version. I'd expect though that a 2to6 first targets 2.6+, and possibly never end up supporting 2.5 at all. I do realize there still is 2.4 out in the wild, but fewer and fewer people need to support it, and the effort to support it is much higher. String translation is also an open question. For some codebases, you want both u and to translate to a Unicode (either in Py3k or via the future import), but if a code base deals with WSGI-style native strings (by means of u for text, for native, b for binary), then the more appropriate translation is to use the future import and map them to , str() and b respectively. Yeah, that can't be done automatically. There is no generic way to determine if a string should be binary, unicode or native. ___ 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] [PATCH] Adding braces to __future__
On Sat, Dec 10, 2011 at 13:15, Ben Finney ben+pyt...@benfinney.id.au wrote: Guido van Rossum gu...@python.org writes: On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi man...@gmx.net wrote: IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN DISCUSSED BEFORE, REPLY THAT IT'S SIMPLY NOT GO'NNA HAPPEN, THAT WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE OR SOMETHING SIMILAR, JUST DON'T. Every single response in this thread so far has ignored this request. The request was completely unreasonable. As it basically said I will ignore everything everyone ever will say on this issue, and if you don't think I should do that, then you should ignore me, I find the request very reasonable. I wish more people would advertise that they not only know about the facts of the matter but completely ignore them. It's basically a big sign saying LALALALIMNOTLISTENING, which would shorten a lot of internet debates if it was more widely used. :-) //Lennart ___ 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] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 03:53, Guido van Rossum gu...@python.org wrote: Are you saying that with that future import, b... is still a Unicode literal? If I said that, this is not what I was trying to say. :-) //Lennart ___ 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] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 04:34, Barry Warsaw ba...@python.org wrote: Sorry, I don't understand this. What does it mean to be str in both versions? And why would you want that? It means that it's a str, that is a string of bytes, in Python 2, and a str, that is a string of Unicode characters, in Python 3. There are cases where you want this, for example not all libraries will accept both str and Unicode under Python 2. As for Unicode in Python 2 and str in Python 3, unadorned strings with the future import in Python = 2.6 does that just fine. Yes, but the future import will change this for *all* strings, making it impossible to have a string that is a str in both Python 2 and Python 3. For that reason, the future import is not enough as a solution (and I suspect, one major reason why I haven't actually seen any one using it). For most cases, using something like six's b() and u() has turned out to be a better solution. It's uglier than having u'' support in Python 3, but has the benefit that b() works also in Python 2.5. The problem comes when you aren't or can't be sure, i.e. you have objects that are sometimes one and sometimes the other. Such as email headers. In that case, you're kind of screwed. Python 2's str type let you cheat, but not without consequences. Those consequences are spelled UnicodeErrors and I'll be glad to be rid of them. Me too. ___ 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] readd u'' literal support in 3.3?
Slightly OT: The slowness of running 2to3 during install time can be fixed by not doing so, but instead running it when the distribution is created, including both Python 2 and Python 3 code in the distribution. http://python3porting.com/2to3.html#distribution-section There are no tools that support this at the moment though. I guess it would be cool if Distribute supported making these kinds of distributions... //Lennart ___ 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] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 17:38, Éric Araujo mer...@netwok.org wrote: When running 2to3 from a setup.py script, does it run on the whole codebase or only files that are found newer by the make-like timestamp-based dependency system? Only on the ones that are newer. But since at install time, that's all of them, it doesn't really help. :-) //Lennart ___ 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] readd u'' literal support in 3.3?
from future import unicode_literals is my fault. I'm sorry. It's pretty useless. It was suggested by somebody and I then supported it's adding, instead of allowing u'' which I suggested. But it doesn't work. One reason is that you need to be able to say This should be str in Python 2, and binary in Python 3, that should be Unicode in Python 2 and str in Python 3, and that over there should be str in both versions, and the future import doesn't support that. Adding u'' support solves the problem, but then again, so does having a b() and an u() method. I'm not sure of the utility of adding functionality to Python 3 that can be solved with six. //Lennart ___ 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] PEP 405 (proposed): Python 2.8 Release Schedule
On Wed, Nov 9, 2011 at 17:18, Amaury Forgeot d'Arc amaur...@gmail.com wrote: Hi, 2011/11/9 Barry Warsaw ba...@python.org I think we should have an official pronouncement about Python 2.8, and PEPs are as official as it gets 'round here. Do we need to designate a release manager? I volunteer. It's on my level of competence. //Lennart ___ 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] Status of the built-in virtualenv functionality in 3.3
+1 for env or sandbox or something else with box in it. pythonbox? envbox? boxenv? ___ 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] Implement Aspect-oriented programming
On Sat, Jun 11, 2011 at 10:29, Jiawei Li jiawei.h...@gmail.com wrote: For example, the logging module is not very useful right now, as it requires sprinkling small one-liners all over my code - not exactly ideal. Why not take a page from aspect-oriented programming and allow for injection of code with point cuts? I'm not sure why you would say this isn't allowed already... -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.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] [Python-checkins] peps: Add rules for indenting continuation lines.
On Fri, Jun 3, 2011 at 00:15, Barry Warsaw ba...@python.org wrote: On Jun 02, 2011, at 12:57 PM, Glenn Linderman wrote: On 6/2/2011 12:01 PM, Guido van Rossum wrote: Bingo. That's why. (Though you are missing some colons in your examples.:-) --Guido You operate as a good Python compiler :) Actually, this is a key insight, which I just mentioned in a private response to Steve. How about this for the rule: If the hanging line ends in a colon, then double-indent (or more-ly indented) seems appropriate. If not, then a single indent is sufficient. That handles cases like this, where double indent makes sense: def some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- if some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- and these cases where a single indent is fine: x = some_really_long_function_name( an_argument, another_argument, and_a_third_argument) foo(x) --- d = dict( a=1, b=2, c=3, d=4) return d Does that cover it? I like it. ___ 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] Why doesn't `functools.total_ordering` use the existing ordering methods?
On Mon, Apr 25, 2011 at 20:43, cool-RR cool...@cool-rr.com wrote: Hello, Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x y` it would do `not x y and not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it just does `y x`, which is problematic. For example if you have a class that is decorated by `total_ordering`, and implements only `__lt__` and `__eq__`, then trying to do `x y` will result in infinite recursion. Why not have `total_ordering` work in the way I suggested? This has been partly fixed for Python 3.2, although it can still happen if you compare two types that both use the total_ordering decorator. See http://bugs.python.org/issue10042 . -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.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] Drop OS/2 and VMS support?
Various people wrote: So please go ahead and add them to PEP 11. If you want to post the call for support to Python Insider, let me know off list and I will set you up with access. Doesn't it have more chances of succeeding if posted to comp.lang.python, simply? I say all of the above. It could be good to find a OS/2 and OpenVMS developer mailing list as well, and post it there. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug? Can't rebind local variables after calling pdb.set_trace()
Hasn't it always been like that? I tried with Python 2.3 now and it's the same. I have no memory of that actually changing an existing variable in any version of Python I've used. More testing turns out that this works: - print lv is , lv (Pdb) lv=2 (Pdb) c lv is 2 While this seem to reset is: - print lv is , lv (Pdb) lv=2 (Pdb) lv 1 (Pdb) c lv is 1 This is the same from Python 2.3 to 2.6. I thought is just was a lack of feature, that there for some reason was really hard to change the value of an existing variable from the debugger. I though that for ten years. It never occurred to me to change the variable and type c without first checking that the variable had changed... :-) It is however fixed in 2.7. - print lv is , lv (Pdb) lv=2 (Pdb) lv 2 (Pdb) c lv is 2 But this bug/lack of feature has been there as long as I can remember. :-) //Lennart ___ 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] Security implications of pep 383
On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi a.bad...@gmail.com wrote: Lennart is missing that you just need to use the same encoding + surrogateescape (or stick with bytes) for decoding the byte strings that you are comparing. You lost me here. I need to do this for what? //Lennart ___ 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] Security implications of pep 383
On Tue, Mar 29, 2011 at 23:17, Martin v. Löwis mar...@v.loewis.de wrote: I think the whole blacklist example is artificial. The string in the blacklist is actually a Chinese hello greeting, so it surely isn't the string being blacklisted. For proper blacklisting, you would likely use substring searches, case-insensitivity, transliterations, and perhaps even regular expressions and word stemming. Good point. //Lennart ___ 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] Security implications of pep 383
On Tue, Mar 29, 2011 at 22:40, Lennart Regebro rege...@gmail.com wrote:
The lesson here seems to be if you have to use blacklists, and you
use unicode strings for those blacklists, also make sure the string
you compare with doesn't have surrogates.
For that matter, what happens with combining characters?
'\N{LATIN SMALL LETTER O}\N{COMBINING DIAERESIS}' != '\N{LATIN SMALL
LETTER O WITH DIAERESIS}'
I guess the filesystem shouldn't treat these as the same (even though
they are), but what if some webservice does? I suspect you should
normalize both strings before comparing them in any blacklist, and
what happens with surrogates when you normalize?
//Lennart
___
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] Security implications of pep 383
The lesson here seems to be if you have to use blacklists, and you use unicode strings for those blacklists, also make sure the string you compare with doesn't have surrogates. //Lennart ___ 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 deprecations in Python 3, from a Python 2 perspective
On Sat, Mar 19, 2011 at 03:42, Nick Coghlan ncogh...@gmail.com wrote: 5. The parallel evolution of the 2.x and 3.x line meant that the first version of 2.x with the relevant warning was released only ~7 months or so before the version of 3.2 where the API was removed An additional issue that makes it particularly problematic for me is that this is a part of moving a whole framework, the Zope Component Architecture And Friends (aka the Bicycle toolkit) that contains a lot of hard to port projects like zope.testing and zc.buildout. This means that it's so far take three years of porting (starting with efforts to port Setuptools in 2008) and isn't done yet. It's extremely frustrating that in the middle of this porting effort the target changes, so things I *thought* was done and ported, are now suddenly not done anymore. It becomes a sisyphean task to port to Python 3, and I don't fancy myself ending up in such a boring part of hell. :-) If I had instead ignored Python 3 completely until this year, then I this wouldn't have been a problem. As a result it feels like early porters like me just got our fingers whacked. But it all comes down to what Guido mentioned in his fie-side chat (at least how I understood him): The pace of change for Python needs to slow down a bit, at least until the migration to Python 3 both for Python implementations and general use has been completed. //Lennart ___ 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 deprecations in Python 3, from a Python 2 perspective
On Fri, Mar 18, 2011 at 00:23, Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. That would be creating an insane burden on library developers. Besides, I've so far not have things break between micro releases, it must be very unusual. That said, when running Python 2.7 with -3 in preparation for a port, you should of course use the latest version, that has the most warnings. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 09:20, Martin v. Löwis mar...@v.loewis.de wrote: In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. That is a deprecation period of seven and a half months. If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. And 3.1 to 3.2? There is no major version break there. For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Yes, but we are now in a period of parallell support for Python 2 and Python 3. So it doesn't work like that. We need to support both Python 2 and Python 3 at the same time. Therefore, the deprecation period was seven and a half month, because it was impossible to support the new API before, and impossible to support the new API after, if you need to support both Python 2 and Python 3. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. This change conforms to PEP 5: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. It is too short, and so is 19 months, but this change does *not* conform. //Lennart ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mon, Mar 14, 2011 at 19:22, Reid Kleckner reid.kleck...@gmail.com wrote: I don't know how your code works, but handling either type from C seems very straightforward to me. You can simply use #ifdef Py_COBJECT_H to see if the cobject.h header was pulled into Python.h. Similarly for Py_CAPSULE_H. All you lose is that if you do get a PyCObject, there is no way of knowing if the void pointer is of the right type. Good to know. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** Surely, you must be joking. No. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 12:02, Martin v. Löwis mar...@v.loewis.de wrote: If you actually had been supporting 2.x and 3.x in parallel for the last two years, you would have had a deprecation period of 19 months and two releases. It's only if you are now migrating from 2 to 3 that you notice the breakage for the first time. The code in question was ported to Python 3 last year, before both 2.7 and 3.2. I noticed the API change now because it's gone from 3.2. That's how most API changes gets noticed: Things stop working. And that's OK. Deprecation periods are there to help you support multiple versions at the same time. Deprecation notices are helpful, of course, but in this case it doesn't help. Even if I had noticed the deprecation warning in 3.1, I wouldn't have been able to do anything about that, because 2.7 had then not been released, and the new API isn't supported in 2.6. I therefore could not have moved to the new API *because* I support both Python 2.x and 3.x I could have (and still can) support it by using compatibility macros or #ifdefs, sure. But you can do that without a deprecation period. So: without compatibility preprocessing I can no longer support 2.6. 2.7 came out seven and a half months before 3.2. Hence the deprecation period was in practice seven and a half months. Admittedly, in C with the preprocessing it's less of an issue, but the C-extensions is rapidly reaching a position where there seems to be as much compatibility macros as there is C code... :-) How long is this going to continue. What API's are going to be needlessly removed in Python 3.3? Could we please cool down with the backwards incompatibility? //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote: Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). No I'm not. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. Up until 3.2 that statement was not actually true. Python 2.x was very backwards compatible. The next time somebody tells me that Python isn't stable and breaks backwards compatibility all the time, and says that's why you should use Java, what can I now say? OK, it's just the C-API, but that excuse isn't going to fly... //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan ncogh...@gmail.com wrote: why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Apparently not, as the code already ran under Python 3.1. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote: Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. OK, fine. I'm stopping my efforts of porting the ZTK to Python 3 unless somebody pays me then, if that is the attitude from the core developers on this issue. Why should there be third-party libraries available for Python 3.2!? No need, if you want them you can find commercial support, apparently. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum gu...@python.org wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. //Lennart ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:58, Lennart Regebro rege...@gmail.com wrote: That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) I meant removed. ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. And so was I. I discovered it today. And personally, I don't mind being surprised. And I'm sorry I didn't have time to try out the zope.* packages that support Python 3 on 3.2, but then again the difference was supposed to be between 2.x and 3.x. I didn't expect 3.2 to suddenly be backwards incompatible. Of the eight packages that currently support 3.1 (in trunk), two packages do not compile, and one gets massive test failures (which may only be test failures, and not actual failures). That is *not* good. Perhaps there is a easy way to map the API's with #defines, but if this is the case, why was the change done in the first place? But the problem here is not the surprise. If I had known about this beforehand, that would only have helped, if I could have convinced others that the API shouldn't have been removed! The problem is the deprecation period! Many projects, not only the Zope Toolkit needs to support a lot of versions. The Zope component architecture currently supports 2.4, 2.5 and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can be dropped, but it definitely will be *years* until we can drop support for 2.6. But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. It can possibly be removed in 3.3, but better would be 3.4. It must be possible to support 3-4 releases of Python with the current release speed. We need to support python versions that are five years old or so. In fact the deprecation period should probably be somewhat similar to the security fix period. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] 3.2.0
On Thu, Feb 17, 2011 at 12:20, Antoine Pitrou solip...@pitrou.net wrote: Agreed. Although better to defer it to 3.3.0 at this point. +1.0.0 for that. Yes, it's confusing, but it's going to be even more confusing if it's called 3.2 sometimes and 3.2.0 sometimes. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] Python and the Unicode Character Database
2010/12/2 Stephen J. Turnbull step...@xemacs.org:
Because that works, but
print(T1234)
doesn't (it prints ASCII). You can't round-trip, but users will
want/expect that.
You should be able to round-trip, absolutely. I don't think you should
expect print() to do that. str(56) possibly. :)
That's an argument for it to be in a module, as you then would need to
send in a parameter on which decimal characters you want.
T1000 = float('一.◯◯◯')
That was already discussed here, and it's clear that unicode does not
consider these characters to be something you can use in a decimal
number, and hence it's not broken.
___
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] Porting Ideas
On Wed, Dec 1, 2010 at 20:17, Antoine Pitrou solip...@pitrou.net wrote: And I'm not sure what this package called Python is (“a high-level object-oriented programming language”? like Java?), but I'm pretty sure I've heard there's a Python 3 compatible version. Uhm... http://pypi.python.org/pypi/Python Anybody wanna remove that, or update it or something? :-) ___ 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 and the Unicode Character Database
On Tue, Nov 30, 2010 at 09:23, Stephen J. Turnbull step...@xemacs.org wrote:
Sure you can. In Python program text, all keywords will be ASCII
Yes, yes, sure, but not the contents of variables,
I see no reason not to make a similar promise for numeric literals.
Wait what, literas? The example was
float('١٢٣٤.٥٦')
Which doesn't have any numeric literals in them at all. Do that work?
Nope, it's a syntax error. Too badm that would have been cool, but whatever.
Why would this be a problem:
T1234 = float('١٢٣٤.٥٦')
T1234
1234.56
But this OK?
T١٢٣٤ = float('1234.56')
T١٢٣٤
1234.56
I don't see that.
Should we bother to implement ١٢٣٤.٥٦ as a literal equivalent to
1234.56? Well, not unless somebody askes for it, or it turns out to be
easy. :-) But that's another question.
___
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 and the Unicode Character Database
On Sun, Nov 28, 2010 at 21:24, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
While we have little choice but to follow UCD in defining
str.isidentifier(), I think Python can promise users more stability in
what it treats as space or as a digit in its builtins.
Why? I can see this is a problem if one character that earlier was
allowed no longer is. That breaks backwards compatibility. This
doesn't.
float('١٢٣٤.٥٦')
1234.56
is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.
*I* think it is more important. In python 3, you can never ever assume
anything is ASCII any more. ASCII is practically dead an buried as far
as Python goes, unless you explicitly encode to it.
def deposit(self, amountstr):
self.balance += float(amountstr)
audit_log(Deposited: + amountstr)
Auditor:
$ cat numbered-account.log
Deposited: ?.??
That log reasonably should be in UTF-8 or something else, in which
case this is not a problem. And that's ignoring that it makes way more
sense to log the numerical amount.
--
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.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] Continuing 2.x
2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com: Hello all. So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python? The answer would seem to be “one doesn’t”. But must it be that way? Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like. So it can be done, but the question is Why? -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 ___ 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] new buffer in python2.7
On Wed, Oct 27, 2010 at 12:36, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 27 Oct 2010 10:13:12 +0800
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Although 2.7 has the new buffer interface and memoryview
objects, these are widely not accepted in the built in modules.
That's true, and slightly unfortunate. It could be a reason for
switching to 3.1/3.2 :-)
It's rather a reason against it, as it makes supporting both Python 2
and Python 3 harder.
However, fixing this in 2.7 just means that you need to support 2.7x
or later only, so it's not a good solution.
I think using compatibility types is a better solution. I suggested
something like that for inclusion in six, but it was softly
rejected. :-)
Something like this, for example. It's a str in Python2 and a Bytes in
Python3, but it extends both classes with a consistent interface.
Improvements, comments and ideas are welcome.
bites.py:
import sys
if sys.version '3':
class Bites(str):
def __new__(cls, value):
if isinstance(value[0], int):
# It's a list of integers
value = ''.join([chr(x) for x in value])
return super(Bites, cls).__new__(cls, value)
def itemint(self, index):
return ord(self[index])
def iterint(self):
for x in self:
yield ord(x)
else:
class Bites(bytes):
def __new__(cls, value):
if isinstance(value, str):
# It's a unicode string:
value = value.encode('ISO-8859-1')
return super(Bites, cls).__new__(cls, value)
def itemint(self, x):
return self[x]
def iterint(self):
for x in self:
yield x
--
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.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] Continuing 2.x
2010/11/8 James Y Knight f...@fuhm.net: On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote: Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like. So it can be done, but the question is Why? To keep the batteries included? But they'll only be included in 2.7, which won't be used much, which defeats the purpose of including those batteries. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 ___ 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] Add aware local time support to datetime module
On Wed, Aug 4, 2010 at 19:46, Alexander Belopolsky alexander.belopol...@gmail.com wrote: [I've got no response from python-ideas, so I am forwarding to python-dev.] With addition of fixed offset timezone class and the timezone.utc instance [0], it is easy to get UTC time as an aware datetime instance: datetime.now(timezone.utc) datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc) However, if you want to keep time in your local timezone, getting an aware datetime is almost a catch 22. If you know your timezone UTC offset, you can do EDT = timezone(timedelta(hours=-4)) datetime.now(EDT) datetime.datetime(2010, 8, 3, 10, 20, 23, 769537, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000))) but the problem is that there is no obvious or even correct way to find local timezone UTC offset. [1] In a comment on issue #5094 (datetime lacks concrete tzinfo implementation for UTC), I proposed to address this problem in a localtime([t]) function that would return current time (or time corresponding to the optional datetime argument) as an aware datetime object carrying local timezone information in a tzinfo set to an appropriate timezone instance. This solution is attractive by its simplicity, but there are several problems: 1. An aware datetime cannot carry all information that system localtime() supplies in a time tuple. Specifically, the is_dst flag is lost. This is not a problem for most applications as long as timezone UTC offset and timezone name are available, but may be an issue when interoperability with the time module is required. 2. Datetime's tzinfo interface was designed with the idea that 2010-11-06 12:00 EDT + 1 day = 2010-11-07 12:00 EST, not 2010-11-07 12:00 EDT. It other words, if I have lunch with someone at noon (12:00 EDT) on Saturday the day before first Sunday in November, and want to meet again at the same time tomorrow, I mean 12:00 EST, not 24 hours later. With localtime() returning datetime with tzinfo set to fixed offset timezone, however, localtime() + timedelta(1) will mean exactly 24 hours later and the result will be expressed in an unusual for the given location timezone. An alternative approach is the one recommended in the python manual. [3] One could implement a LocalTimezone class with utcoffset(), tzname() and dst() extracting information from system mktime and localtime calls. This approach has its own shortcomings: 1. While adding integral number of days to datetimes in business setting, it is natural to expect automatic timezone adjustments, it is not as clearcut when adding hours or minutes. 2. The tzinfo.utcoffset() interface that expects *standard* local time as an argument is confusing to many users. Even the official example in the python manual gets it wrong. [4] 3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the repeated hour when local clock is set back in DST to standard time transition. As far as I can tell, the only way to resolve the last problem is to add is_dst flag to the datetime object, which would also be the only way to achieve full interoperability between datetime objects and time tuples. [5] The traditional answer to call for improvement of timezone support in datetime module has been: this is upto 3rd parties to implement. Unfortunately, stdlib is asking 3rd parties to implement an impossible interface without giving access to the necessary data. The impossibility comes from the requirement that dst() method should find out whether local time represents DST or standard time while there is an hour each year when the same local time can be either. The missing data is the system UTC offset when it changes historically. The time module only gives access to the current UTC offset. My preference is to implement the first alternative - localtime([t]) returning aware datetime with fixed offset timezone. This will solve the problem of python's lack of access to the universally available system facilities that are necessary to implement any kind of aware local time support. For all of the reasons you give above, I think it's a bad idea. :-) You need a proper time zone database to solve these issues, like pytz. Which incidentally solves the ambiguity problem as well. so the solution is pytz. :-) What pytz doesn't have (but dateutil.tz does) is a timezone object that uses the operating systems local timezone data, like /etc/localzone on unix. That could be interesting to include, possibly. Having a fixed time zone offset object for the localtime seems a bad idea. The problem it solves is easy to get around, but the problems created are not. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python
Re: [Python-Dev] bytes / unicode
On Tue, Jun 22, 2010 at 20:07, James Y Knight f...@fuhm.net wrote: Yeah. This is a real issue I have with the direction Python3 went: it pushes you into decoding everything to unicode early, even when you don't care -- Well, yes, maybe even if *you* don't care. But often the functions you need to call must care, and then you need to decode to unicode, even if you personally don't care. And in those cases, you should deocde as early as possible. In the cases where neither you nor the functions you call care, then you don't have to decode, and you can happily pass binary data from one function to another. So this is not really a question of the direction Python 3 went. It's more a case that some methods that *could* do their transformations in a well defined way on bytes don't, and then force you to decode to unicode. But that's not a problem with direction, it's just a missing feature in the stdlib. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] bytes / unicode
2010/6/21 Stephen J. Turnbull step...@xemacs.org: IMO, the UI is right. Something like the above ought to work. Right. That said, many times when you want to do urlparse etc they might be binary, and you might want binary. So maybe the methods should work with both? -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 02:02, Terry Reedy tjre...@udel.edu wrote: After reading the discussion in the previous thread, signed in to #python and verified that the intro message starts with a lie about python3. I also verified that the official #python site links to Python Commandment Don't use Python 3… yet. Well, it *should* say: If you need to ask if you should use Python 2 or Python 3, you probably are better off with Python 2 for the moment. But that's a bit long. :-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 18:20, Laurens Van Houtven l...@laurensvh.be wrote: 2.x or 3.x? http://tinyurl.com/py2or3 Wow. That's almost not an improvement... That link doesn't really help anyone choose at all. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] #Python3 ! ? (was Python Library Support in 3.x)
On Mon, Jun 21, 2010 at 23:26, Simon de Vlieger si...@ikanobori.jp wrote: That part of the topic will be replaced after all feedback is gathered on the new article Laurens provided at: http://python-commandments.org/python3.html as stated earlier in this thread. OK, great, I missed that! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] bytes / unicode
On Sun, Jun 20, 2010 at 23:55, Benjamin Peterson benja...@python.org wrote: There are not many tools for treating bytes as text. Well, what tools would you need that can be used also on bytes? Bytes objects has a lot of the same methods like strings do, and that will cover 99% of the cases. Most text tools assume that the text really is text, and much of it doesn't make sense unless you've converted it to Unicode first. But most of the things you would need to do, such as in a web-server doesn't really involve treating the text as something linguistic, but it's a matter of replacing and escaping and such, and that could be done while the text is in bytes form.But the tools for that exists... Is there some specific tool that is missing? -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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] Sumo
One worry with an official sumo distribution is that it could become an excuse for *not* putting something in the stdlib. Otherwise it's an interesting idea. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Sumo
OK, I had an idea here: How about that the people affected by difficulties in getting software approved got together to put together not a sumo-python, but a python-extras package? That package could include all the popular stuff, like SciPy, Numpy, twisted, distribute, buildout, virtualenv, pip, pytz, PIL, openid, docutils, simplejson, nose, genshi, and tons of others. That would be a big download. But here's the trick: You don't *have* to install them! Just bundle all of it. If licensing is a problem I guess you'd need to have permission to relicense them all to the Python license, which would be problematic. But otherwise having a team of people overseeing and bundling all this might not be that much work, and you'd avoid the bloat by not installing all of it. :-) Or would this not fool the company trolls? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Wed, May 26, 2010 at 06:22, Nick Coghlan ncogh...@gmail.com wrote: - download a futures module from PyPI and live with the additional dependency Why would that be a problem? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Wed, May 26, 2010 at 09:37, Paul Moore p.f.mo...@gmail.com wrote: It seems to me that if you've experienced the sort of culture that makes it a problem, Ah, it's a culture problem. In a heterogenous world, every action will benefit some and hurt some. Another arbitrary corporate ruleset could also mean you might be stuck on ancient python versions, and might not see a new module added to stdlib in 3.2 until 2015 or so. Some corporations go through a lot of trouble to prevent their employees from doing their job. Pythons core developers can not and should not let that hinder *them* from doing what is best for Python. Decisions on inclusion in stdlib must be made on what benefits Python and it's users in general. Since even small mistakes in a stdlib module will hurt far more people than having to having the module mature on PyPI until the worst API issues and bugs are ironed out, it's clear to me that letting a module mature on PyPI before inclusion is the better policy here, although how long obviously must be decided on a case by case basis. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Wed, May 26, 2010 at 02:10, Nick Coghlan ncogh...@gmail.com wrote: Those that say just put it on PyPI may not recognise the additional ... Just a note, so we don't get sidelined by misunderstandings: I don't think anybody said that. ;-) There are two issues here, one generic and one specific: Generic: Modules should go on PyPI first, for a time, to stabilize (and so they can be used in earlier versions of Python) before they end up in stdlib. I suspect everyone actually agrees on that (but I could be wrong). Specific:Has futures been long enough on PyPI, and is it stable? I'm staying out of that discussion. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Sun, May 23, 2010 at 11:39, Brian Quinlan br...@sweetapp.com wrote: This package eliminates the need to construct the boilerplate present in many Python applications i.e. a thread or process pool, a work queue and result queue. It also makes it easy to take an existing Python application that executes (e.g. IO operations) in sequence and execute them in parallel. It package provides common idioms for two existing modules i.e. multiprocessing offers map functionality while threading doesn't. Those idioms are well understood and already present in Java and C++. It can do that as a separate package as well. And not only that, it could then be available on PyPI for earlier versions of Python as well, making it much more likely to gain widespread acceptance. Could you be a little more specific about Guido's argument at PyCon? A module in stdlib has to be dead. After it's included in the stdlib it can not go through any major changes since that would mean loss of backwards incompatibility. Also, you can't fix bugs except by releasing new versions of Python. Therefore the API must be completely stable, and the product virtually bugfree before it should be in stdlib. The best way of ensuring that is to release it as a separate module on PyPI, and let it stabilize for a couple of years. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Sun, May 23, 2010 at 12:15, Brian Quinlan br...@sweetapp.com wrote: You could make the same argument about any module in the stdlib. Yeah, and that's exactly what I did. I doubt it. Simple modules are unlikely to develop a following because it is too easy to partially replicate their functionality. urlparse and os.path are very useful modules but I doubt that they would have been successful on PyPI. Are you saying your proposed module is so simple that anyone can easily replicate it with just a couple of lines of code? The good news in this case is that the same API has been used successfully in Java and C++ for years so it is unlikely that any major changes will need to be made. Good. Then the time it takes to mature on PyPI would be very short. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3148 ready for pronouncement
On Sun, May 23, 2010 at 13:29, Brian Quinlan br...@sweetapp.com wrote: Parts of it, yes. Just like I can replace most operations in os.path and urlparse with a few lines of code. Yeah, but parts of is not the question. I've read the PEP, and I do *not* know how to implement it. That means it's not a trivial module, so that argument doesn't hold up here, even if we accept it as valid (which I actually don't). I don't think any module in the stdlib is entirely trivial. Yes, even parsing an URL is non-trivial, as shown by the fact that the urlparse module apparently has a bug in it for urls like svn+ssh://foo.bar/frotz. ;-) Also, even trivial modules can be useful if you use them a lot. How would you define very short? That's not up to me to decide. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Fixing the GIL (with a BFS scheduler)
On Mon, May 17, 2010 at 15:05, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 17 May 2010 14:47:25 +0200 Lennart Regebro rege...@gmail.com wrote: On Mon, May 17, 2010 at 14:12, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 17 May 2010 08:28:08 +0200 Lennart Regebro rege...@gmail.com wrote: But the scheduler is so simplistic it ends up fighting with the OS scheduler, and a large amount of CPU time is used up switching instead of executing. This is already fixed with py3k. Are you referring to the New GIL? Yes. At has been shown, it also in certain cases will race with the OS scheduler, so this is not already fixed, although apparently improved, if I understand correctly. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Fixing the GIL (with a BFS scheduler)
On Tue, May 18, 2010 at 12:53, Antoine Pitrou solip...@pitrou.net wrote: Race is a strange term here and I'm not sure what you mean. The issue found out by Dave Beazley can't be reasonably described by this word, I think. OK, maybe race is the wrong word. But that doesn't mean the issue doesn't exist. Please read and understand the issue report mentioned by Nir before trying to make statements based on rumours heard here and there. Oh, so Dave Beazleys reports is a rumour now. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Fixing the GIL (with a BFS scheduler)
On Tue, May 18, 2010 at 14:52, Antoine Pitrou solip...@pitrou.net wrote: Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit : Please read and understand the issue report mentioned by Nir before trying to make statements based on rumours heard here and there. Oh, so Dave Beazleys reports is a rumour now. Your and other people's grandiloquent interpretation of them is. Now let me ask you a question: did you witness some of the effects mentioned here? Did it disturb the proper functioning one of your applications, programs or services? If yes, please be so kind as to explain how; it will be an useful datapoint. Bonus points if the issue affects Python 3.2, since that's really what Nir is talking about. If not, then do you have any valuable information to contribute to this discussion? I doubt anything I say can be less constructive than your rude comments. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Fixing the GIL (with a BFS scheduler)
On Sun, May 16, 2010 at 22:52, Victor Stinner victor.stin...@haypocalc.com wrote: I didn't followed last development around the GIL. Can you explain me why Python should have its own scheduler whereas each OS has already its own scheduler? Because the GIL locks and unlocks threads, in practice, it already have. But the scheduler is so simplistic it ends up fighting with the OS scheduler, and a large amount of CPU time is used up switching instead of executing. Having a proper scheduler fixes this. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Fixing the GIL (with a BFS scheduler)
On Mon, May 17, 2010 at 14:12, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 17 May 2010 08:28:08 +0200 Lennart Regebro rege...@gmail.com wrote: But the scheduler is so simplistic it ends up fighting with the OS scheduler, and a large amount of CPU time is used up switching instead of executing. This is already fixed with py3k. Are you referring to the New GIL? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Should we drop active support of OSF/1?
On Mon, May 3, 2010 at 06:57, Jesus Cea j...@jcea.es wrote: Would be enough to raise an ERROR at configure time if OSF test is positive?. To delete that intentional ERROR would be trivial. Oh really? I have no clue of how to do that. Doesn't like like a good deprecation to me. :) Is printing a warning not easily feasible in ./configure? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Enhanced tracker privileges for dangerjim to do triage.
On Tue, Apr 27, 2010 at 09:18, Georg Brandl g.bra...@gmx.net wrote: Am 26.04.2010 15:34, schrieb Lennart Regebro: Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :) Reviewing the checkins is not work, then? Well, yes, so OK, not half. But quite a lot of the checkins need to be bad for the amount of work the established commiters need to do per bug fixed to increase when you add a newbie. Yes, maybe the workload in total increases in the beginning, but that's because the newbie is actually fixing bugs, and as Stephen mentions, it's often itches no one else (read the established committers) cares about, because they didn't encounter that particular issue. I have a problem seeing that as a bad thing. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 08:33, Martin v. Löwis mar...@v.loewis.de wrote: There is a little risk. People doing triage can make two common mistakes, and both do happen in the Python tracker from time to time: a) they reject some contribution, even though a long-time contributor might have accepted it with modifications; sometimes this rejection happens for overly formal reasons, and b) they assign issues to someone who might be formally in charge, but is unlikely to act on the issue in a reasonable amount of time. Sure. But these errors can be fixed, just as a checkin can be reverted. That's what I mean with the risk being low, you can't make permanent damage. The Zope community gives commit access by recommendation. This works well. The easier it is to contribute, the more people contributes. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull step...@xemacs.org wrote: It is entirely *not* evident to me that it's too hard to get privileges in the Python development community (Python's development process works -- and it works really well by comparison to 99% of the processes out there). Well, that's true, all to often a project is controlled by a few developers with no intent of sharing access ever. Sure, but that's still *work*, and it's work for *somebody else*. Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :) As someone who does a lot more managing of shared resources than coding in the projects I'm active in, I disagree about the danger. Enthusiastic newbies can do a lot of minor damage in a short period of time, and cleaning that up is *work*. This danger is almost entirely mitigated by a small amount of mentoring -- which is precisely what the current process requires -- not only of the recomending party, but also of the existing workers. And I'm saying that the recommending party is enough. If an established developer says this guy will not fuck things up, then that is enough guarantee that he won't fuck things up. But it is a process change, and they should be comfortable with it. Of course. I'm just arguing for that this process change is correct, and that the current balance is wrong, and that a change is comfortable and safe. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 17:42, R. David Murray rdmur...@bitdance.com wrote: The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person Since the recommendation is based on the persons merit, I fail to see the difference. may feel (especially to the non privileged) like a kind of nepotism. (It's not what you contribute, it's who you know). That is only a problem if we break the rules for certain people. But this discussion isn't about breaking the rules, but changing them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] merit
On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou solip...@pitrou.net wrote: Lennart Regebro regebro at gmail.com writes: On Mon, Apr 26, 2010 at 17:42, R. David Murray rdmurray at bitdance.com wrote: The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person Since the recommendation is based on the persons merit, I fail to see the difference. In an open source community, merit relates to that community. We don't give Linus Torvalds all rights on the project just because we know (or assume ;-)) he is tremendously competent. Well, that's a blow against the merit-based position then. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Enhanced tracker privileges for dangerjim to do triage.
I'd say there is something wrong with the process. If a trusted developer can't get somebody more privilege on the tracker by saying that I trust this guy, then a new process is needed. That's it's too hard to get privileges in the Python development community has been evident too long, I think. There is one privilege that should be hard to get: Permanent delete. But being able to triage bugs isn't such a privilege. Heck, not even commit access is, because of someone makes something bad, you can back out the checkin. Giving people rights to a bugtracker or versioning system is not dangerous, and should not be hard. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Doctests REPORT_ONLY_FIRST_FAILURE ignored
On Wed, Apr 21, 2010 at 06:56, Lennart Regebro rege...@gmail.com wrote: If you set up any sort of report flag on the unit test itself, the default report flags given to the testrunner are ignored. This goes for all report flags, the REPORT_xDIFF and REPORT_ONLY_FIRST_FAILURE. I'd suggest that we do allow the testrunner to set REPORT_ONLY_FIRST_FAILURE by default even if the testcase has a REPORT_xDIFF flag. Why? Because it makes sense. :) The REPORT_xDFF flags makes sense both as parameters to a testrunner, and as flags on a testcase. You might want to permanently set diff flags on tests that generate output that warrants a diff if they fail. REPORT_ONLY_FIRST_FAILURE you would rarely set on a testcase. You don't want that on the testcase, as buildbots wouldn't see the subsequent fails, and developers might think it was only a minor issue. It is a flag you give to the testrunner to stop having the first failure scroll off screen. So you want it to work *always*. You don't want or expect it to stop working just because one testcase had a DIFF flag set. Right? Or did I miss something? If not, I'll provide a patch and put it in the bugtracker. I apparently didn't miss anything. :) Patch will arrive soon. :) ___ 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] Doctests REPORT_ONLY_FIRST_FAILURE ignored
If you set up any sort of report flag on the unit test itself, the default report flags given to the testrunner are ignored. This goes for all report flags, the REPORT_xDIFF and REPORT_ONLY_FIRST_FAILURE. I'd suggest that we do allow the testrunner to set REPORT_ONLY_FIRST_FAILURE by default even if the testcase has a REPORT_xDIFF flag. Why? Because it makes sense. :) The REPORT_xDFF flags makes sense both as parameters to a testrunner, and as flags on a testcase. You might want to permanently set diff flags on tests that generate output that warrants a diff if they fail. REPORT_ONLY_FIRST_FAILURE you would rarely set on a testcase. You don't want that on the testcase, as buildbots wouldn't see the subsequent fails, and developers might think it was only a minor issue. It is a flag you give to the testrunner to stop having the first failure scroll off screen. So you want it to work *always*. You don't want or expect it to stop working just because one testcase had a DIFF flag set. Right? Or did I miss something? If not, I'll provide a patch and put it in the bugtracker. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] [RELEASED] 2.7 beta 1
On Sat, Apr 10, 2010 at 20:52, Benjamin Peterson benja...@python.org wrote: On behalf of the Python development team, I'm merry Imagines Benjamin dancing folkdances on tables full of food to announce the first beta release of Python 2.7. Cool! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] [Distutils] Bootstrap script for package management tool in Python 2.7 (Was: Re: At least one package management tool for 2.7)
On Mon, Mar 29, 2010 at 09:30, anatoly techtonik techto...@gmail.com wrote: Therefore I still propose shipping bootstrap package that instruct user how to download and install an actual package management tool when users tries to use it. So far I know only one stable tool - `easy_install` - a part of `setuptools` package. We can't ship *A* bootstrap script until there is *A* package management tool in the Python world. Currently there are three. :) In short: The tools that exist are not ready yet. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] [Distutils] Bootstrap script for package management tool in Python 2.7 (Was: Re: At least one package management tool for 2.7)
On Mon, Mar 29, 2010 at 11:02, anatoly techtonik techto...@gmail.com wrote: distutils is not a `package management` tool, because it doesn't know anything even about installed packages With that definition, there are no packaga management tools for Python. So it's going to be pretty hard to ship one with 2.7. `pip` and `distribute` are unknown for a vast majority of Python users, so if you have a perspective replacement for `easy_install` - it can be said in bootstrap package message. There is no problem with packages that require `setuptools` either - they will require `setuptools` as dependency anyway. For now there are two questions: 1. Are they stable enough for the replacement of user command line `easy_install` tool? Yes. But that's the wrong question. The correct question is: Are they stable enough to be included in standard library. And the answer is no. 2. Which one is the recommended? Both. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] [Distutils] Bootstrap script for package management tool in Python 2.7 (Was: Re: At least one package management tool for 2.7)
2010/3/29 anatoly techtonik techto...@gmail.com: Ok. How about shipping bootstrap script only for `easy_install` tool for now? Since there are many who are of the opinion that easy_install isn't very good, and pip should be used instead, that would be a bad idea. Just drop it. 2.7 will not have a package management tool or bootstrap script to one, because there is currently not one that is good enough to be the standard. People are working on making the situation good enough, this debate is wasting their time. The end. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)
On Mon, Mar 29, 2010 at 16:21, anatoly techtonik techto...@gmail.com wrote: Just a thought about user story my customers would likely write if I shipped Python as a product: As a user, I think Python is suxx, because it makes its users suffer for a long time from packaging disorder. So fix it. Python is open source. It's created by it's users. If there is something you think it lacking, you step up and help make it better. But the packaging solution will not be ready for 2.7. It's a really hard problem. Your help is appreciated. Complaints are not. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 19, 2010 at 19:37, s...@pobox.com wrote: Lennart I would like if we could look into making a timezone module Lennart that works on Python 2.5 to 3.2 that uses system data... 2.5, 2.6 and 3.1 are completely off the radar screen at this point. The best you could hope for is that someone backports whatever is created for 2.7 or 3.2 and distributes it outside the normal distribution channel (say, as a patch on PyPI). My argument was that we should create a module distributed on PyPI, and once that's stable, move it into stdlib. The suggestions in this thread of moving things into stdlib has included a lot of new features, and are as such not stable. I'm worrying that adding such a thing to stdlib will do so in an unfinished state, and we'll just en up with yet another state of semi-brokenness. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 19, 2010 at 07:27, Stuart Bishop stu...@stuartbishop.net wrote: In any case, since you want to make a version that can be included and uses the timezone API, I guess that's a moot question until we have that version. :) As I understand it dateutil pretty much already provides what I'm describing. Well, pretty much yes. I don't know how good it is at using the system data without an Olsen database, but it shouldn't be too much work to add that, I guess. But that changes the topic from moving pytz to stdlib into moving dateutil.tz into stdlib. :) Personally I like pytz anal timezone support though, and dateutil.tz doesn't have that, and I still think it would be possible to have both in one system, but using different API-calls. Also, people have uttered negativities about datetime.tz, but they have never been able to say what they don't like about it. I would like if we could look into making a timezone module that works on Python 2.5 to 3.2 that uses system data, unless there is also a Olsen module installed, and that has all the features of both dateutil.tz and pytz, ie: 1. Support for the standard API. 2. A Pytz extended API. 3. Using the system data. 4. Using a separate Olsen database installable by normal Python means. 5. Perhaps a timezone name alias map? That could map both old Olsen names and Windows names. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 03:48, Michael Foord fuzzy...@voidspace.org.uk wrote: Some of the Linux distributions *already* patch pytz to use the system information, which they keep updated separately. Yes. And what problem does including pytz in the stdlib solve? That information is also available from the system on Mac OS and Windows. It is not available on Windows in any reasonable and useable form. It would seem to be very useful to have a version of pytz that defaults to using the system information if available, has a mechanism for using separate data for systems that don't provide the information or raises an error when neither system information nor separate data is available. Pytz has mechanisms for that, perhaps they should be more easily useable. Perhaps it should even default to using the system Olsen database if there is one. But the discussion was if it should be included in the standard library, and nobody still has explain what problem that would solve. If it doesn't solve a problem, it shouldn't be done, as it also is going to create problems, because everything does. :) The data could then still be available and released regularly without being tied to the Python release schedule. Which it already is. So no problem solved. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 11:29, Stuart Bishop stu...@stuartbishop.net wrote: I think a tzinfo implementation in the standard library that uses the system timezone database would be useful to a great many people, providing a standard way of mapping a string to a tzinfo instance. Well, that wouldn't work on Windows, which would be a bit strange. So yes, on some systems it would mean you now have pytz in the standard library, while you don't on others. That's going to cause problems, while it doesn't actually solve any problem except I need to install pytz, which isn't much of a problem. The number of frameworks requiring pytz as a dependency demonstrate this. They are going to still need to require pytz, or rather the data part of it. It is unfortunate that those strings would be platform specific. For most applications this doesn't matter - you are reading the key from a config file or allowing the user to select from a list of possible values. Well, the problem in finding your won timezone has been documented in one of the links I sent before. But that's another problems, solved by the tzfile/tzwin implementations discussed previously. As the pytz maintainer, this would help me solve a long standing problem. Currently, pytz tzinfo instances don't really follow the documented tzinfo interface (in order to allow localized datetime arithmetic to be always correct instead of good enough). This is a source of confusion to many users who don't need this level of accuracy. It would be great if the standard library provided a tzinfo implementation that was good enough for the vast majority of users, and for people who do care they can continue to use pytz.timezone() to retrieve the anal tzinfo implementation. Users will be happier as they will have fewer bugs in their code. The alternative for me is to eventually split pytz, somehow providing the simpler interface that works exactly as documented in the Python reference and the anal interface that works per the pytz README (in hindsight, it should have been this way from day 1). I understand the need for different API's but can't the extended part that doesn't behave like timezone be separate methods? I don't *mind* pytz in the standardlibrary, I just don't really see how it solves any problems, while I can see how it creates them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 13:41, anatoly techtonik techto...@gmail.com wrote: It will still require workarounds and bridges to make API in user scripts convenient, i.e. try: import pytz mydatetime = PytzDatetime() catch ImportError: mydatetime = ClassicDatetime() Only if you want to work both with and without pytz. So don't. Just require pytz. I don't see the problem with that. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 22:42, Martin v. Löwis mar...@v.loewis.de wrote: That's not true. The registry is readable by any user, and the format is fully documented. Yes, but they use non-standard locations, and afaik, pytz does not support it. If a stdlib pytz would use this you would have to use different timezone names for Unix and Windows. I don't think that's a good idea. Also, the windows data contains only current timezone data, so for calendars stretching back in time, the Olsen database would be preferable as it keeps history. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
But is the You don't have to install it really such a big problem so
that it's worth the other problems like platform incompatibilities and
such?
In any case, since you want to make a version that can be included and
uses the timezone API, I guess that's a moot question until we have
that version. :)
On Fri, Feb 19, 2010 at 05:59, Stuart Bishop stu...@stuartbishop.net wrote:
On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro rege...@gmail.com wrote:
On Thu, Feb 18, 2010 at 22:42, Martin v. Löwis mar...@v.loewis.de
wrote:
That's not true. The registry is readable by any user, and the format is
fully documented.
Yes, but they use non-standard locations, and afaik, pytz does not
support it. If a stdlib pytz would use this you would have to use
different timezone names for Unix and Windows. I don't think that's a
good idea.
Under Windows the only backend API I'm aware of we could use is tzwin and I
think any standard library inclusion would require this or something
similar. For the standard library, I think it would be great if you could do
'datetime.timezone(some_string)' and get a tzinfo instance suitable for most
use cases which seems no problem for tzwin to provide (platform default DST
information, simple interface with potentially incorrect localized datetime
arithmetic over DST transitions). It is unfortunate that the timezone
strings are platform specific, but I feel that is still better than end
users having to keep updating timezone databases or not supporting
non-zoneinfo systems at all. Even with pytz, the timezone strings are
version specific to an extent (we had a real issue where we updated pytz on
our web applications, which changed a preferred timezone name from
Asia/Calcutta to Asia/Kolkata per requests from our users and as a result
our wiki's exploded for some users as they where on separate boxes using a
different pytz release that didn't understand that timezone string).
It would also be trivial to always look up timezone information from
compiled zoneinfo files in a well known location if the system timezone
database cannot find the requested timezone information. So
datetime.timezone('US/Eastern') would work on Windows if you had installed
pytz (I'd update pytz to install its zoneinfo files into the blessed
location). Best of both worlds.
Also, the windows data contains only current timezone data, so for
calendars stretching back in time, the Olsen database would be
preferable as it keeps history.
Sure. I'm not saying pytz will disappear or become unmaintained for people
who need it. I believe most people who are using it now don't need it and
I'm sure there are real bugs in real code out there because of this, as
using pytz correctly requires reading and understanding the pytz
documentation.
If this is all too ambitious, tzinfo implementations in the standard library
for UTC and the current system timezone would be a step forward and solve
most real world use cases.
--
Stuart Bishop stu...@stuartbishop.net
http://www.stuartbishop.net/
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Tue, Feb 16, 2010 at 13:42, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tue, Feb 16, 2010 at 13:05, s...@pobox.com wrote: Maybe an alternate sprint idea would be to incorporate dateutil into the Python core: http://labix.org/python-dateutil Whoops... (just waking up - still need that first cup of coffee) While incorporating dateutil into the core would be nice (in my opinion at least), I was really thinking of pytz: http://pytz.sourceforge.net/ I think dateutil is fairly heavy for the stdlib, but I think pytz would be a very good candidate for inclusion. Without it, the timezone support in datetime is hardly usable. The timezone database is updated several times per year. You can *not* include it in the standard library. On Tue, Feb 16, 2010 at 16:43, Dirkjan Ochtman dirk...@ochtman.nl wrote: By using what the OS provides. The OS often does not. At least on Linux, the basic timezone data is usually updated by other means (at least on the distro I'm familiar with, it's updated quite often, too; through the package manager). I'm assuming Windows and OS X would also be able to provide something like this. The Windows timezone data sucks donkeyballs through a hose. Thus, if the timezone implementations from pytz was in the standard library, and the timezone data not, they would not be useable on Windows. So, no can do. Also, different Unices often have slightly different names and organisations of the Olsen database, which would create confusions and incompatibilities, so that's probably also not the best solution. == So, what to do? Use Pytz! == There is no need to stick Pytz in the standard library. It's available on PyPI, updated frequently, etc. What we can do is point to it from the documentation. But before that, it needs a fix. Pytz is great, but missing one thing: Wrappers for the current locale settings. This is necessary, because there is no way of realiably figuring out the current locale. See http://regebro.wordpress.com/2008/05/10/python-and-time-zones-part-2-the-beast-returns/ (and http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/ for other timezone issues). These kinds of wrappers exist in dateutils.tz. It would be great if that type of functionality could get into Pytz as well. A sprint to do this and fix the issues in the tracker should solve the issues, I think. There is no need to move things into the core. An Pytz could use more maintainers, Stuart tends not to answer emails, I assume this is because he is overw -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Add UTC to 2.7 (PyCon sprint idea)
On Wed, Feb 17, 2010 at 12:32, Lennart Regebro rege...@gmail.com wrote: These kinds of wrappers exist in dateutils.tz. It would be great if that type of functionality could get into Pytz as well. A sprint to do this and fix the issues in the tracker should solve the issues, I think. There is no need to move things into the core. An Pytz could use more maintainers, Stuart tends not to answer emails, I assume this is because he is overw Bloody gmail! I did NOT press send. Glah. Stuart tends not to answer emails, I assume this is because he is overworked, so more eyes on Pytz is probably a good idea. He is welcome to correct me if this is not so. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Add UTC to 2.7 (PyCon sprint idea)
On Wed, Feb 17, 2010 at 23:46, s...@pobox.com wrote: Lennart The timezone database is updated several times per year. You Lennart can *not* include it in the standard library. My guess is the data are updated several times per year, not the code. Can they not be separated? Yes, but that would mean we have an implementation in stdlib that relies on a dataset which may not exist. That is just going to be confusing. Moving pytz into the stdlib doesn't solve anything, really. So why do it? It's not like pytz is hard to install. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Executing zipfiles and directories (was Re: PyCon Keynote)
On Wed, Jan 27, 2010 at 14:23, David Lyon david.l...@pythontest.org wrote: We even get to install a python package directly from our browser using this scheme. I don't understand why anybody wouldn't want that. So, go ahead, make it happen. No one is stopping you. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Executing zipfiles and directories (was Re: PyCon Keynote)
On Wed, Jan 27, 2010 at 16:24, David Lyon david.l...@pythontest.org wrote: Think how useful it would be to ship Django or Plone from a zip box... Plone has installers, and is very easily installed on Windows, for those who want to try it. For real production installations you don't want that kind of installations for Plone or Django. And since Django is not an end-user product I fail to see how that would be useful to have an installer like that for it. I doubt distutils will be replaced. Too much time and effort has been spent on bandaids to keep it running. Somehow everything you ever write ends up saying that distutils should be scrapped and something else should be rewritten instead. Also, you are apparently the only one in the world who understands how it should be made. OK. Fine. Lets say that you are right. The get going, stop spending time on complaining and implement it the right way instead. Honestly. Less talk, more hockey. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Rich Comparison recipe wrong?
On Tue, Jan 26, 2010 at 09:15, Юлий Тихонов july.t...@gmail.com wrote: It looks like __cmp__, not __lt__ method. Oh, yeah, sorry. I copy/pasted code from my code where I use __cmp__, :) However, with this replacement test also falls into recursion. Told ya. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Rich Comparison recipe wrong?
If you look at the description of the rich comparison methods in the documentation: http://docs.python.org/reference/datamodel.html#object.__lt__ It refers to a recipe: http://code.activestate.com/recipes/576529/ However, that recipe will convert a __ge__(self, other) into a other self. So when you call self = other, you'll end up calling other self. So far, so good. But, the problem is another piece of text: A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. If you do this, what happens is that Python will try to swap the parameters around, so it will convert a self other into a other = self. And here we see the problem. If class A returns NotImplemented when compared to class B, and class B implements the recipe above, then we get infinite recursion, because 1. A() B() will call A.__lt__(B) which will return NotImplemented. 2. which will mean that Python calls B.__ge__(A) 3. Which B implements by doing A B 4. Start over at 1. Have I missed something, or is this recipe incomplete by not handling the NotImplemented case? If it is, I think the recipe should be changed to something that handles it. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Rich Comparison recipe wrong?
On Mon, Jan 25, 2010 at 14:34, Nick Coghlan ncogh...@gmail.com wrote: However, returning NotImplemented generally implies that A and B are *different* classes Which is exactly the case here. so I think this is more of a theoretical problem than a practical one. How so? The whole point of returning NotImplemented is to give the other class a go. But if that other class implements this recipe, you get infinite recursion. It seems to me that it means that this recipe is broken, as it doesn't handle the other class returning NotImplemented. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Rich Comparison recipe wrong?
On Mon, Jan 25, 2010 at 15:30, Nick Coghlan ncogh...@gmail.com wrote:
Ah, you mean the case where both classes implement the recipe, but know
nothing about each other and hence both return NotImplemented from their
root comparison?
Well, only one needs to return NotImplemented, actually.
OK, that sounds like a plausible real world problem with the recipe, but
I'm not sure how difficult it would be to fix.
I've failed. :-) I currently something like this instead:
class ComparableMixin(object):
def __lt__(self, other):
try:
return self.__cmp__(other) 0
except TypeError:
return NotImplemented
def __le__(self, other):
try:
return self.__cmp__(other) = 0
except TypeError:
return NotImplemented
def __gt__(self, other):
try:
return self.__cmp__(other) 0
except TypeError:
return NotImplemented
def __ge__(self, other):
try:
return self.__cmp__(other) = 0
except TypeError:
return NotImplemented
def __eq__(self, other):
try:
return self.__cmp__(other) == 0
except TypeError:
return NotImplemented
def __ne__(self, other):
try:
return self.__cmp__(other) != 0
except TypeError:
return NotImplemented
That does rely on a (deprecated) __cmp__ but it will never be called
directly anyway.
The __cmp__ is then implemented something like this:
def __cmp__(self, other):
try:
return (self.v other.v) - (self.v other.v)
except AttributeError:
raise TypeError('Can not compare %s and %s' %
(type(self), type(other))
Since this doesn't redirect any of the __xx__ methods to another
one, the problem goes away.
But it uses a lot of annoying try/excepts. Ideas for improvements would be nice.
--
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.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] Rich Comparison recipe wrong?
On Tue, Jan 26, 2010 at 02:56, Nick Coghlan ncogh...@gmail.com wrote:
Lennart Regebro wrote:
On Mon, Jan 25, 2010 at 15:30, Nick Coghlan ncogh...@gmail.com wrote:
Ah, you mean the case where both classes implement the recipe, but know
nothing about each other and hence both return NotImplemented from their
root comparison?
Well, only one needs to return NotImplemented, actually.
I'd like to see a test case that proved that. With two different types
and only one of them returning NotImplemented, the recursion should
terminate inside the one with the root comparison that can handle both
types.
It never gets to that root comparison, as several of that types
comparisons just refer back to the type who returns NotImplemented. To
solve it you need to never refer to the other type in your
comparisons. And as far as I see that makes it impossible to implement
full comparisons with only one operator implemented.
In short, the recipe assumes you never compare with other types, but
it doesn't check for it.
Test attached (assuming this list accepts attachements).
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
# By Christian Muirhead, Menno Smits and Michael Foord 2008
# WTF license
# http://voidspace.org.uk/blog
``total_ordering`` and ``force_total_ordering`` are class decorators for
Python 2.6 Python 3.
They provides *all* the rich comparison methods on a class by defining *any*
one of '__lt__', '__gt__', '__le__', '__ge__'.
``total_ordering`` fills in all unimplemented rich comparison methods, assuming
at least one is implemented. ``__lt__`` is taken as the base comparison method
on which the others are built, but if that is not available it will be
constructed from the first one found.
``force_total_ordering`` does the same, but having taken a comparison method as
the base it fills in *all* the others - this overwrites additional comparison
methods that may be implemented, guaranteeing consistent comparison semantics.
::
from total_ordering import total_ordering
@total_ordering
class Something(object):
def __init__(self, value):
self.value = value
def __lt__(self, other):
return self.value other.value
It also works with Python 2.5, but you need to do the wrapping yourself:
::
from total_ordering import total_ordering
class Something(object):
def __init__(self, value):
self.value = value
def __lt__(self, other):
return self.value other.value
total_ordering(Something)
It would be easy to modify for it to work as a class decorator for Python
3.X and a metaclass for Python 2.X.
import sys as _sys
if _sys.version_info[0] == 3:
def _has_method(cls, name):
for B in cls.__mro__:
if B is object:
continue
if name in B.__dict__:
return True
return False
else:
def _has_method(cls, name):
for B in cls.mro():
if B is object:
continue
if name in B.__dict__:
return True
return False
def _ordering(cls, overwrite):
def setter(name, value):
if overwrite or not _has_method(cls, name):
value.__name__ = name
setattr(cls, name, value)
comparison = None
if not _has_method(cls, '__lt__'):
for name in 'gt le ge'.split():
if not _has_method(cls, '__' + name + '__'):
continue
comparison = getattr(cls, '__' + name + '__')
if name.endswith('e'):
eq = lambda s, o: comparison(s, o) and comparison(o, s)
else:
eq = lambda s, o: not comparison(s, o) and not comparison(o, s)
ne = lambda s, o: not eq(s, o)
if name.startswith('l'):
setter('__lt__', lambda s, o: comparison(s, o) and ne(s, o))
else:
setter('__lt__', lambda s, o: comparison(o, s) and ne(s, o))
break
assert comparison is not None, 'must have at least one of ge, gt, le, lt'
setter('__ne__', lambda s, o: s o or o s)
setter('__eq__', lambda s, o: not s != o)
setter('__gt__', lambda s, o: o s)
setter('__ge__', lambda s, o: not (s o))
setter('__le__', lambda s, o: not (s o))
return cls
def total_ordering(cls):
return _ordering(cls, False)
def force_total_ordering(cls):
return _ordering(cls, True)
if __name__ == '__main__':
@total_ordering
class DuckTyper(object):
def __init__(self, v):
self.v = v
def __lt__(self, other):
return (self.v other.v) - (self.v other.v)
@total_ordering
class StrictComparator(object):
def __init__(self, v):
self.v = v
def __lt__(self, other):
if not isinstance(other, StrictComparator):
return
Re: [Python-Dev] PyCon Keynote
On Tue, Jan 26, 2010 at 06:27, David Lyon david.l...@pythontest.org wrote: Secondly, I never knew about it. Why did you say the process was like black magic when you didn't know about it? Is this a distutils option? No, it's new in Python 2.6, which Nick Coghlan clearly stated in the text you quoted before saying it was black magic. Maybe you should have read his mail before you answered it? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PEP 3146: Merge Unladen Swallow into CPython
My 2 cents: For environments like Plone that has a lot of code and uses a lot of memory the current speed increases is probaly not worth it if the memory increases as much as it does now. It would for almost all cases mean you need to skimp on data caching instead, which would probably slow down the sites more than speed them up. But of course, if in the future U-S would get that 4-5 times speedup, doubling the memory would not be an issue, IMO. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PyCon Keynote
Hmmm. A list of favorite restaurants? OK, more seriously: Your favourite python tools. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] PYTHON3PATH
On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt r...@brainbot.com wrote: The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier. What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] PYTHON3PATH
On Wed, Jan 13, 2010 at 21:08, Oleg Broytman p...@phd.pp.ru wrote: On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote: What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-) See http://phd.pp.ru/Software/dotfiles/init.py.html for an example. Cheese and fries! :-) Anyway, I don't see how this could pose any problems, because any user advanced enough to do these things will be advanced enough to understand what the problem is and fix it so it works under Python 3 too. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] [RELEASED] Python 2.7 alpha 2
On Tue, Jan 12, 2010 at 22:56, Martin v. Löwis mar...@v.loewis.de wrote: Maybe not, but the Distribute feature is there because IMO the distutils feature by itself isn't particularily useful. You need to write your own distutils extensions, in practice, and they are not trivial. I wouldn't say that. My Django port works with bare distutils (as does Django itself), and it works fine. That distribute had to redo it is only because setuptools *replaces* the build_py command, as does the 2to3 support in distutils. So only if you have a different build_py already, you can't use what is in distutils. Yeah, you are right, I misremembered. The actual additional feature is the support for the test command. Testing under Python 2 and 3 without it is annoying. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] [RELEASED] Python 2.7 alpha 2
This is what it says now: Python 2.7 is scheduled to be the last major version in the 2.x series before it moves into 5 years of bugfix-only mode. And during this discussion it has been noted that others than the core python team might pick up Python 2 and make releases. So maybe we can and this discussion by changing that line in future releases to be: Python 2.7 is scheduled to be the last major version in the 2.x series released by the Python Software Foundation before it moves into 5 years of bugfix-only mode. That doesn't exclude *others* making a Python 2.8 that could include all sorts of crazy features. :) This is mainly just to get the pointless discussion over with. The current Python core team don't want to make a 2.8, so that will not happen. Someone else might, but as Chris points out, they won't step up until they have to, which is probably at least two years from now. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] [RELEASED] Python 2.7 alpha 2
On Mon, Jan 11, 2010 at 10:06, Martin v. Löwis mar...@v.loewis.de wrote: I know you are just looking for a compromise, but this shouldn't be it: the PSF has deliberately stayed out of the actual Python engineering, so the release that Benjamin makes is not done by the PSF (but by Benjamin and his contributors :-). Hm. Yeah. That's right of course. I started with saying official, but then I thought official according to who?. :) So I changed it to mentioning PSF, but that doesn't work either. I guess the current writing as as good as it gets, unless we change scheduled to expected or something. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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] Improve open() to support reading file starting with an unicode BOM
On Mon, Jan 11, 2010 at 11:37, Walter Dörwald wal...@livinglogic.de wrote: UTF-8 might be a good choice No, fallback if there is no BOM should be the local settings, just as fallback is today if you don't specify a codec. I mean, what if you want to look for a BOM but fall back to something else? How far will we go with encoding special information in the codecs names? codec='BOM else UTF-16 else locale'? :-) BOM is not a locale, and should not be a locale. Having a locale called BOM is wrong per se. It should either be default to look for a BOM when codec=None, or a special parameter. If none of these are desired, then we need a special function that takes a filename or file handle, and looks for a BOM and returns the codec found or None. But I find that much less natural and obvious than checking the BOM when codec=None. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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] Improve open() to support reading file starting with an unicode BOM
On Mon, Jan 11, 2010 at 12:12, Lennart Regebro rege...@gmail.com wrote: BOM is not a locale, and should not be a locale. Having a locale called BOM is wrong per se. D'oh! I mean codec here obviously. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.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
