Re: [Python-Dev] User's complaints
Hi Jeroen, On Thu, Jul 13, 2006 at 02:02:22PM +0200, Jeroen Ruigrok van der Werven wrote: He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. There are various simple ways to do this; the one I'm using from time to time is the extendabletype metaclass from: http://codespeak.net/svn/pypy/dist/pypy/annotation/pairtype.py Example: class A: __metaclass__ = extendabletype def f(...): ... Somewhere else: class __extend__(A): def g(...): ... FWIW the above 30-lines file also contains a fast double-dispatch multimethod implementation :-) A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi Bob, On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote: @main def whatever(): ... It would probably need to be called something else, because main is often the name of the main function... Ah, but there is theoretically no name clash here :-) @main # - from the built-ins def main(): # - and only then set the global ... Just-making-a-stupid-point-and-not-endorsing-the-feature-ly yours, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Jul 17, 2006, at 11:25 AM, Armin Rigo wrote: Hi Bob, On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote: @main def whatever(): ... It would probably need to be called something else, because main is often the name of the main function... Ah, but there is theoretically no name clash here :-) @main # - from the built-ins def main(): # - and only then set the global ... Just-making-a-stupid-point-and-not-endorsing-the-feature-ly yours, Of course it *works*, but it's still overriding a built-in... Who knows when assignment to main will become a SyntaxError like None ;) -bob ___ 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] User's complaints
On 7/12/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: On 7/5/06, Neal Norwitz [EMAIL PROTECTED] wrote: For example, we heard grumblings about the releases coming too often. Once we went to an 18 month release schedule, there was minimal complaining. It should be fairly safe to assume this silence means people think we are doing a good job. What are the things that could be fixed that would silence the most number of user's complaints? I frequent a lot of IRC channels either devoted to Python or heaving people use Python a lot next to my own use so I think I can, hopefully, give some comments. Of course, things are highly subjective. Jeroen, Thank you very much for your feedback. It helps. The release cycle is not bothering people from what I gather, especially not given the fact that the world is still changing when it comes to things like XML. What is bothering people is how you have to reinstall all your site-packages when you go from one major version to another. I understand this might be a difficult problem to tackle, but I can also understand the hassle if people have more than 10-15 modules installed. If it's pure python, why don't people just copy everything under site-packages after installing? They could/should run compileall after that to recompile the .pyc files. With 2.5 on 64-bit machines, C extension modules *must* be recompiled due to lots of internal changes. One thing you didn't mention that I've heard from time to time is the stdlib should be improved. For example, cleaning up old modules. Though I'm not really sure everyone has the same thing in mind when it comes to improving the stdlib. Another point is how the module documentation is very terse in a lot of areas. Especially when it concerns what kind of exceptions a particular function can/will raise. As a professional, part-time, technical writer I wonder how to best tackle the entirety of the documentation we have. (Note that this is in no way any jibe towards Fred Drake, since I bet it's quite a bulk of documentation to work with/on every time.) Also it can get quite confusing when you need the introductory manual, when the language reference and when the module documentation. Do you think you could help with the doc? How can we get people, especially tech writers, interested in improving the doc? Most people agree it's important, but few make time to really improve the doc. We've talked about making it easier for people to contribute to the docs, perhaps adding something like a wiki/comments. Do you think that would help? Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. I'm not sure I understand your point. Can you provide more info about what you dislike/expect instead? I'll ask around and see what people are reporting to me as their top 3 or 5 Python complaints though. Great. Thanks! n ___ 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] User's complaints
On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. It is not beautiful but very useful. In Python 3000 we can replace it with: @main def whatever(): ... to mark this function as main function if module executed directly. -- bye by Wolfgang ___ 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] User's complaints
On Thu, 13 Jul 2006, Wolfgang Langner wrote: On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. It is not beautiful but very useful. In Python 3000 we can replace it with: @main def whatever(): ... to mark this function as main function if module executed directly. Why not simply: def __main__(): ... or even pass in the command-line arguments: def __main__(*args): ... Having to 'import sys' to get at the command-line arguments always seemed awkward to me. 'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged. -- ?!ng ___ 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] User's complaints
On 7/13/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 7/12/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: Thank you very much for your feedback. It helps. With apologies in advance if my own level of understanding is, of course, lacking of advanced constructs. If it's pure python, why don't people just copy everything under site-packages after installing? They could/should run compileall after that to recompile the .pyc files. With 2.5 on 64-bit machines, C extension modules *must* be recompiled due to lots of internal changes. I wasn't even aware of the compileall step, can you elaborate since this is the first time I see it being mentioned. One thing you didn't mention that I've heard from time to time is the stdlib should be improved. For example, cleaning up old modules. Though I'm not really sure everyone has the same thing in mind when it comes to improving the stdlib. How do you envision cleaning up old modules? Do you think you could help with the doc? How can we get people, especially tech writers, interested in improving the doc? Most people agree it's important, but few make time to really improve the doc. We've talked about making it easier for people to contribute to the docs, perhaps adding something like a wiki/comments. Do you think that would help? Wiki/comments are useful, sure, the only problem is that if you have to sift through every single page to spot a useful comment it is not helping. I never liked PHP's comment system to take an example. Personally, but that's just me of course, I prefer a periodic evaluation of comments and reintegration of said comments into the documentation itself. I've been looking at Python's docstrings in the main codebase and that use alone is inconsistent, some areas feature a lot of docstrings, some have none. But with alone docstrings you will not cut it I think. I hope to get around in the coming time to work up some documentation changes/patches and submit these. [if __name__ == __main__:] I'm not sure I understand your point. Can you provide more info about what you dislike/expect instead? Not the above construct at least. :) To me it just feels like a kludge, perhaps due to the fact that the rest of Python just flows from your fingers when writing/programming. Perhaps one could even get away with it in the form of: def __main__(): ...main program... Some other complaints/wishes from a hard core pythonista: - There's no support for real macros. - Writable closures would be nice. - Open classes would be nice. -- Jeroen Ruigrok van der Werven ___ 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] User's complaints
On Jul 13, 2006, at 12:37 AM, Wolfgang Langner wrote:
On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote:
Things that struck me as peculiar is the old:
if __name__ == __main__:
whatever()
This is so out of tune with the rest of python it becomes a nuisance.
It is not beautiful but very useful.
In Python 3000 we can replace it with:
@main
def whatever():
...
to mark this function as main function if module executed directly.
It would probably need to be called something else, because main is
often the name of the main function... but you could write such a
decorator now if you really wanted to.
def mainfunc(fn):
if fn.func_globals.get('__name__') == '__main__':
# ensure the function is in globals
fn.func_globals[fn.__name__] = fn
fn()
return fn
@mainfunc
def main():
print 'this is in __main__'
-bob
___
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] User's complaints
Ka-Ping Yee wrote: On Thu, 13 Jul 2006, Wolfgang Langner wrote: On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote: Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. It is not beautiful but very useful. In Python 3000 we can replace it with: @main def whatever(): ... to mark this function as main function if module executed directly. Why not simply: def __main__(): ... or even pass in the command-line arguments: def __main__(*args): ... Having to 'import sys' to get at the command-line arguments always seemed awkward to me. 'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged. +1, seems a lot more elegant than if __name__ == '__main__' Regards, -- Aaron Bingham Senior Software Engineer Cenix BioScience GmbH ___ 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] User's complaints
Wolfgang Langner wrote: @main def whatever(): ... This seems like replacing one unpythonic feature with another. (I *still* can't get used to that @ syntax -- it looks like an intruder from Rubyland...) -- Greg ___ 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] User's complaints
Aaron Bingham wrote: Ka-Ping Yee wrote: Why not simply: def __main__(): ... or even pass in the command-line arguments: def __main__(*args): ... Having to 'import sys' to get at the command-line arguments always seemed awkward to me. 'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged. +1, seems a lot more elegant than if __name__ == '__main__' Just to clarify, I was writing in support of Ping's suggestion of def __main__() or def __main__(*args). The decorator-based solution is ugly. Regards, -- Aaron Bingham Senior Software Engineer Cenix BioScience GmbH ___ 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] User's complaints
Jeroen Ruigrok van der Werven wrote: - Open classes would be nice. What do you mean by open classes? Python classes already seem pretty open to me, by the standards of other languages! -- Greg ___ 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] User's complaints
Armin On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was. It's also in Misc/NEWS . Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability. Armin Surely everybody should read and think carefully about each Armin (longish) NEWS file for each software package whenever they Armin update their machines or switch to one with newer software than Armin they last used. I'll add one further point here. I exchanged a couple emails with Greg Black. What happened to him was that some of his customers upgraded their operating systems and got Python 2.4 in the bargain. His software started throwing off errors. At that point he read the NEWS file and saw the problem. He clearly wasn't fully master of the environment in which his customers ran his software, so I think it's understandable that he was caught by surprise by this change. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Neal I agree, but some of this responsibility has to fall to users. Neal Sometimes these breakages are bugs, pure and simple. Our tests Neal don't catch everything. This is why it's really, really important Neal to get as many alpha/beta testers as possible. Had the issues Neal been brought up before 2.4 was released, we could have addressed Neal them. You're of course preaching to the choir here. Somehow we need to do a better job convincing the Python-using public to pay attention to alphas and betas, especially software consultants like Greg Black. Another area where this particular process broke down was that there simply wasn't already a test case for the fairly common case of calling strftime with a six-zeroes pad to format a simple date. Had it been there already, it would have been discovered when Brett added the range checks. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Jul 13, 2006, at 2:02 AM, Greg Ewing wrote: Jeroen Ruigrok van der Werven wrote: - Open classes would be nice. What do you mean by open classes? Python classes already seem pretty open to me, by the standards of other languages! I'm guessing he's talking about being like Ruby or Objective-C where you can add methods to any other class in the runtime. Basically we'd have that if the built-in classes were mutable, but that just really encourages fragile code. The big problem you run into with open classes is that you end up depending on two libraries that have a different idea of what the foo method on string objects should do. Adding open classes would make it easier to develop DSLs, but you'd only be able to reasonably do one per interpreter (unless you mangled the class in a with block or something). -bob ___ 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] User's complaints
[EMAIL PROTECTED] wrote: He clearly wasn't fully master of the environment in which his customers ran his software, so I think it's understandable that he was caught by surprise by this change. a programmer that's surprised that code that relies on undocumented behaviour might behave differently if run on a different platform ? *that's* surprising. /F ___ 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] User's complaints
Bob Ippolito wrote: What do you mean by open classes? Python classes already seem pretty open to me, by the standards of other languages! I'm guessing he's talking about being like Ruby or Objective-C where you can add methods to any other class in the runtime. wouldn't a standard multiargument dispatch mechanism solve this, for most (all?) practical use cases. (and while we're at it, wouldn't a standard multiargument dispatch be nice replacement for the instance-oriented lookup we're using today? dispatching on a single value is so last century ;-) /F ___ 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] User's complaints
He clearly wasn't fully master of the environment in which his customers ran his software, so I think it's understandable that he was caught by surprise by this change. Fredrik a programmer that's surprised that code that relies on Fredrik undocumented behaviour might behave differently if run on a Fredrik different platform ? *that's* surprising. Not necessarily. He may not have realized his customers were going to upgrade their operating systems or that the upgrades would involve a new version of Python. Not everyone tracks every Python release. In this case, a) Python 2.4 had been out long enough to turn up in a new (presumably Linux) OS release, and b) since Mr. Black appears to program in Python for a living he should probably have been more attentive to new releases. Maybe Mr. Black hadn't gotten around to testing his software with 2.4 yet. Maybe the software was written on-site for a client and he didn't have access to it to even test in his own environment. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi Bob, On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: Adding open classes would make it easier to develop DSLs, but you'd only be able to reasonably do one per interpreter (unless you mangled the class in a with block or something). The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). He understands the implications of allowing open classes (import vs. no import changes semantics, etc.). Personally, he doesn't care *too* much about newbie safety since he's not a newbie. To quote verbatim: give me the big guns :-) And while we're at it, he also stated: [...] add multiple dispatch to your list of improvements for Python. I hope this clarifies it a bit for other people. -- Jeroen Ruigrok van der Werven ___ 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] User's complaints
Jeroen Ruigrok van der Werven wrote: Hi Bob, On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: Adding open classes would make it easier to develop DSLs, but you'd only be able to reasonably do one per interpreter (unless you mangled the class in a with block or something). The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). I'm somewhat confused as to how Python's classes aren't open. Sure, types like the builtin types that don't have a __dict__ aren't open because there isn't anywhere to put the extensions, but metaclassing lets you do whatever you want to any other class: def extends(orig_cls): if not hasattr(orig_cls, __dict__): raise TypeError(Cannot extend %r % cls) class ExtendMeta(type): def __new__(mcl, name, bases, ns): if len(bases) != 1: raise TypeError(Can only extend single class) if bases[0] is object: return type.__new__(mcl, name, bases, ns) for key, value in ns.iteritems(): if key not in (__metaclass__, __dict__): setattr(orig_cls, key, value) return orig_cls class ExtendCls(object): __metaclass__ = ExtendMeta return ExtendCls class A1(object): ... def method1(self): ... print Hi, I'm method 1! ... class A2(extends(A1)): ... def method2(self): ... print Hi, I'm method 2! ... x = A1() x.method1() Hi, I'm method 1! x.method2() Hi, I'm method 2! y = A2() y.method1() Hi, I'm method 1! y.method2() Hi, I'm method 2! A1 is A2 True Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Nick Coghlan wrote: The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). I'm somewhat confused as to how Python's classes aren't open. Sure, types like the builtin types that don't have a __dict__ aren't open because there isn't anywhere to put the extensions, but metaclassing lets you do whatever you want to any other class: you don't even need metaclass trickery to deal with the define a single class in multiple modules problem; just use multiple inheritance to bring all the component classes together. /F ___ 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] User's complaints
Fredrik Lundh wrote: Nick Coghlan wrote: The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). I'm somewhat confused as to how Python's classes aren't open. Sure, types like the builtin types that don't have a __dict__ aren't open because there isn't anywhere to put the extensions, but metaclassing lets you do whatever you want to any other class: you don't even need metaclass trickery to deal with the define a single class in multiple modules problem; just use multiple inheritance to bring all the component classes together. I didn't mean to say that I thought what I posted was a sensible thing to do - I was mainly curious as to how close I could get to Ruby's class extension syntax by using metaclasses (with the answer being very, IMO). If someone really wants to extend a Python class, they can just define a function that does what they want and assign it to whatever method names on whatever mutable classes they feel like. No fancy syntax needed :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Somebody whose name doesn't matter (it's not about him) wrote: When some of us first saw what PEP 3000 suggested we were thinking: shit, there goes Python. [...] And later in the same message the same person wrote: Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. This is an illustration of the dilemma of maintaining a popular language: Everybody hates change (me too!) but everybody also has one thing that's bothering them so much they absolutely want it to be changed. If you were to implement all those personal pet peeves, you'd get a language that's more different from Python than Python is from Fortran. So where's the middle ground? I believe it's established without a doubt that in biological evolution, changes comes in spurts: A species may change hardly at all for millions of years, and then suddenly, due to not quite understood mechanisms, it starts to change rapidly until a completely new species (or several) has evolved, which again remains stable for a long time. I don't want to adopt this time scale for Python (:-), but I do think it's useful to think of language evolution as a kind of fractal movement -- at every time scale, there are small jumps and the occasional large jump. Python 2.2 was a fairly large jump (new-style classes, iterators, generators, decorators). Python 3000 will be the largest jump so far. There will be larger jumps yet in the distant future. But in between, there will be long periods of (relative) stability. Will it hurt? You bet! But for many species, sooner or later it's evolve or become extinct. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Jul 13, 2006, at 5:02 AM, Jeroen Ruigrok van der Werven wrote: Hi Bob, On 7/13/06, Bob Ippolito [EMAIL PROTECTED] wrote: Adding open classes would make it easier to develop DSLs, but you'd only be able to reasonably do one per interpreter (unless you mangled the class in a with block or something). The person whose 'complaints' I was stating says that DSLs (Domain Specific Languages for those who, like me, were confused about the acronym) are a big part of what he is after and one per interpreter is fine by him. He also realises that the application(s) he needs them for might be unusual. He doesn't specifically need the builtin types to be extendable. It's just nice to be able to define a single class in multiple modules. Even C++ allows this to some extent (but not as much as he'd like). He understands the implications of allowing open classes (import vs. no import changes semantics, etc.). Personally, he doesn't care *too* much about newbie safety since he's not a newbie. To quote verbatim: give me the big guns :-) And while we're at it, he also stated: [...] add multiple dispatch to your list of improvements for Python. I hope this clarifies it a bit for other people. Well, if this person really weren't a newbie then of course they'd know how to define a metaclass that can be used to extend a (non- built-in) class from another module. They'd probably also know of two or three different implementations of multiple dispatch (or equivalent, such as generic functions) available, and could probably write their own if they had to ;) The only valid complaint, really, is that built-in classes are read- only. I doubt anyone wants to change that. If they want to write things in the style of Ruby, why not just use it? -bob ___ 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] User's complaints
Fredrik Lundh wrote: (and while we're at it, wouldn't a standard multiargument dispatch be nice replacement for the instance-oriented lookup we're using today? dispatching on a single value is so last century ;-) That's highly debatable, and as I'm sure you remember, has been highly debated. :-) -- Greg ___ 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] User's complaints
Jeroen Ruigrok van der Werven wrote: It's just nice to be able to define a single class in multiple modules. It *seems* nice until you want to track down which source file the definition of some method comes from. Those used to the one huge global namespace of C and C++ likely don't see this as a problem. But since I've come to appreciate the benefits of Python's module system, I don't want to go back to that nightmare. -- Greg ___ 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] User's complaints
Greg == Greg Ewing [EMAIL PROTECTED] writes: Greg Jeroen Ruigrok van der Werven wrote: It's just nice to be able to define a single class in multiple modules. Greg It *seems* nice until you want to track down which Greg source file the definition of some method comes Greg from. Greg Those used to the one huge global namespace of Greg C and C++ likely don't see this as a problem. But Greg since I've come to appreciate the benefits of Greg Python's module system, I don't want to go back Greg to that nightmare. While I think there are good arguments both ways, I don't think that finding source definitions of methods or classes counts as one - let alone as a nightmare. Tools like tags (in vi and emacs and lisp environments) work quickly and accurately, are easy to use (one keystroke in vi and M-. or similar in emacs to go to a defn, and then a tags pop to come back), work in an identical way on many source languages, and they have been around for literally decades. That's to say nothing of IDE or CASE tools that support finding definitions, callers, etc. Regards, Terry ___ 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] User's complaints
On 7/13/06, Jeroen Ruigrok van der Werven [EMAIL PROTECTED] wrote:
If it's pure python, why don't people just copy everything under
site-packages after installing? They could/should run compileall
after that to recompile the .pyc files. With 2.5 on 64-bit machines,
C extension modules *must* be recompiled due to lots of internal
changes.
I wasn't even aware of the compileall step, can you elaborate since
this is the first time I see it being mentioned.
python -mcompileall -h
It's in the stdlib. It is used by the build process to recursively
traverse directories and compile all the .py files into .pyc (or .pyo)
files. So if you wanted to copy everything from site-package in 2.4
to 2.5, you could do something like:
cp -r /usr/lib/python2.{4,5}/site-packages
/usr/bin/python2.5 -mcompileall -d /usr/lib/python2.5/site-packages
That should really be all that's required. It of course doesn't verify
the packages are correct or that you still want to keep all the files.
This generally works for .so's too. However a warning will be
generated each time you import the .so since it was built on an old
version of Python.. On 2.5 in 64-bit systems, this will definitely
not work.
One thing you didn't mention that I've heard from time to time is the
stdlib should be improved. For example, cleaning up old modules.
Though I'm not really sure everyone has the same thing in mind when it
comes to improving the stdlib.
How do you envision cleaning up old modules?
For me, manually. Do you still need moduleX? There's no way for a
computer to tell you the answer, it depends on what you will use with
the new version of Python.
n
___
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] User's complaints
[EMAIL PROTECTED] wrote: The way I used to format dates using time.strftime does indeed no longer work. Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) '2005-06-04' Is there any specific reason you couldn't write %d-%02d-%02d % (2005, 6, 4) (i.e. not use strftime at all)? It seems strange to fake a time tuple just to use that function, in particular if the time formatting should not use any locale-specific output. I don't actually run into this problem as I've pretty much converted to use datetime in new code. I also realize that's not documented as the way it should be done, but I'm fairly certain it was common usage before the datetime module came along. Still, it is a bit annoying that the (undocumented, but I think de facto) commonly used idiom no longer works. I guess this was caused by this change: /* Checks added to make sure strftime() does not crash Python by indexing blindly into some array for a textual representation by some bad index (fixes bug #897625). No check for year since handled in gettmarg(). */ So this was changed in response to a bug report about a crash. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) '2005-06-04' Martin Is there any specific reason you couldn't write Martin %d-%02d-%02d % (2005, 6, 4) Martin (i.e. not use strftime at all)? Sure, but that was just me being lazy typing at the interactive prompt. %Y-%m-%d is just about the only date format I can ever remember without consulting the strftime(3) man page. ;-) Suppose I had used time.strftime(%b %d, %Y, (2005, 6, 4) + (1,)*6) 'Jun 04, 2005' instead (switching to the all-ones default that still works)? Martin So this was changed in response to a bug report about a crash. Yeah, but it broke common (at the time) usage. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi Brett, On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was. It's also in Misc/NEWS . Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability. Surely everybody should read and think carefully about each (longish) NEWS file for each software package whenever they update their machines or switch to one with newer software than they last used. Or if they cannot bother, surely they should read at least Python's? I guess I'm going to side with Greg Black on his blog entry. Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much. Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much. I agree, but some of this responsibility has to fall to users. Sometimes these breakages are bugs, pure and simple. Our tests don't catch everything. This is why it's really, really important to get as many alpha/beta testers as possible. Had the issues been brought up before 2.4 was released, we could have addressed them. Basically, if you care about these things, test before we release. That way the issues can be addressed. If you don't care enough to test and get bitten by a problem, quit whining, you had your chance. I have no sympathy for someone who is only willing to whine after the fact, but unwilling to do any work. That's really not helpful. n -- PS People do this all the time in politics too. They complain about someone, when they couldn't even be bothered to vote. ___ 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] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Brett,On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was.It's also in Misc/NEWS .Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability.Surely everybody should read and think carefully about each (longish) NEWS file for each software package whenever they update their machinesor switch to one with newer software than they last used.Or if they cannot bother, surely they should read at least Python's? Obviously I don't expect people to read all of the docs; I know I don't. But when something I am using starts to act differently in a program (and especially a programming language), I do do at least a little investigating. I don't expect people to read Misc/NEWS upfront, but if something suddnely starts to act differently I would expect them to at least try to figure it out and hopefully report a bug if it is one. I guess I'm going to side with Greg Black on his blog entry.Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much.As Neal said, we are not perfect; bugs happen. If we all gave up on a piece of software after two bugs we would not be able to turn our computers. =) -Brett ___ 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] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry. I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Black complained about (or almost the same; maybe my problem was setting the month and day to zero and formatting only the time :-) and tried to convince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; and I didn't fight it further then. Do I remember this correctly? Does anybody else recall? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On 7/12/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry.I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Blackcomplained about (or almost the same; maybe my problem was setting themonth and day to zero and formatting only the time :-) and tried toconvince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; andI didn't fight it further then. Do I remember this correctly? Doesanybody else recall?My recollection is that we found a way to cause a crash if improper values were used. We never said 0s were allowed in the docs and that it could mask bugs if you did use them and we supported them ( e.g., setting 0 for January instead of 1 if you were thinking in terms of indexing at the time). So we said that values should be within the proper range and not above or below them.The python-dev Summary coverage can be found at http://www.python.org/dev/summary/2004-02-01_2004-02-29/#time-strftime-now-checks-its-argument-s-bounds .-Brett ___ 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] User's complaints
On 7/12/06, Brett Cannon [EMAIL PROTECTED] wrote: On 7/12/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry. I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Black complained about (or almost the same; maybe my problem was setting the month and day to zero and formatting only the time :-) and tried to convince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; and I didn't fight it further then. Do I remember this correctly? Does anybody else recall? My recollection is that we found a way to cause a crash if improper values were used. We never said 0s were allowed in the docs and that it could mask bugs if you did use them and we supported them ( e.g., setting 0 for January instead of 1 if you were thinking in terms of indexing at the time). So we said that values should be within the proper range and not above or below them. The python-dev Summary coverage can be found at http://www.python.org/dev/summary/2004-02-01_2004-02-29/#time-strftime-now-checks-its-argument-s-bounds Thanks for confirming memory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Thursday 13 July 2006 14:46, Guido van Rossum wrote: Thanks for confirming memory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again? I already said yes for 2.5. Brett, can you work up a patch? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] User's complaints
On 7/12/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Thursday 13 July 2006 14:46, Guido van Rossum wrote: Thanks for confirmingmemory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again?I already said yes for 2.5. Brett, can you work up a patch? Yep, it's on my todo list and will get done. Might have to wait until next week, though (if that is okay), since my girlfriend is leaving town Sunday and thus I will have a ton more time after that. -Brett ___ 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] User's complaints
On 7/5/06, Neal Norwitz [EMAIL PROTECTED] wrote: For example, we heard grumblings about the releases coming too often. Once we went to an 18 month release schedule, there was minimal complaining. It should be fairly safe to assume this silence means people think we are doing a good job. What are the things that could be fixed that would silence the most number of user's complaints? I frequent a lot of IRC channels either devoted to Python or heaving people use Python a lot next to my own use so I think I can, hopefully, give some comments. Of course, things are highly subjective. When some of us first saw what PEP 3000 suggested we were thinking: shit, there goes Python. It incredibly felt like Python's best measures were being dumbed down. The release cycle is not bothering people from what I gather, especially not given the fact that the world is still changing when it comes to things like XML. What is bothering people is how you have to reinstall all your site-packages when you go from one major version to another. I understand this might be a difficult problem to tackle, but I can also understand the hassle if people have more than 10-15 modules installed. Another point is how the module documentation is very terse in a lot of areas. Especially when it concerns what kind of exceptions a particular function can/will raise. As a professional, part-time, technical writer I wonder how to best tackle the entirety of the documentation we have. (Note that this is in no way any jibe towards Fred Drake, since I bet it's quite a bulk of documentation to work with/on every time.) Also it can get quite confusing when you need the introductory manual, when the language reference and when the module documentation. Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. PS. One thing I tend to talk to users about is stability of the interpreter. When I talk about crashing the interpreter, the most common first reaction I get is you can crash the interpreter? How do you do that? I take that answer as a good sign. :-) I've come relatively late to the Python scene, but ever since 2.2 I never once managed to crash the interpreter. I'll ask around and see what people are reporting to me as their top 3 or 5 Python complaints though. -- Jeroen Ruigrok van der Werven ___ 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] User's complaints
A.M. Kuchling [EMAIL PROTECTED] writes: On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote: didn't draw much applause. It certainly gave me the impression that many changes in Python are advocated and welcomed by only a small fraction of users. The benefits of changes are usually clear, but I don't think the costs of changes are fully assessed. python-dev considers the cost of changes to CPython's implementation, but I don't think the cost changes to Jython, IronPython, or PyPy are taken into account here. I don't want to attempt to speak for Armin, but I don't think that was quite the point he was trying to make. The cost of implementation isn't really that high -- most of the changes from 2.3 to 2.4 were implemented for PyPy in about a week and we have implementations of most of the 2.5 features already, and you can also consider the decorators discussion where each of the proposed syntaxes had solid tested implementations. At least from my POV, the cost of bad design, whether through simple lack of sufficient thought or aggregation of features into cruft, is much much higher. PyPy probably has enough representatives here who would squawk if something was difficult, but I don't think Jython or IronPython do. People implementing Python should accept the fact that Python is a changing language, IMHO. I think if we assessed those costs fully, the bar for changes to the language would be a good deal higher. I think if you assessed these other costs fully, the bar would be higher still. Cheers, mwh -- This is the fixed point problem again; since all some implementors do is implement the compiler and libraries for compiler writing, the language becomes good at writing compilers and not much else! -- Brian Rogoff, comp.lang.functional ___ 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] User's complaints
On 7/5/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 7/4/06, Guido van Rossum [EMAIL PROTECTED] wrote: From actual users of the language I get more complaints about the breakneck speed of Python's evolution than about the brokenness of the current language. Guido, I'm really interested in your perspective here. I assume you hear far more average complaints from Joe Random User. Can you help give the rest of us an idea about the top 10 complaints/problems people have? I realize this will be subjective, that's ok. Perhaps we should try to focus our energies on some of these issues. Well here's one I stumbled across the other day. I don't know if it's legit, but it's still bad PR: http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html For the impatient, he's not at all bothered about the lack of obscure language feature X. cheers ___ 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] User's complaints
Michael Well here's one I stumbled across the other day. I don't know Michael if it's legit, but it's still bad PR: Michael http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html Michael For the impatient, he's not at all bothered about the lack of Michael obscure language feature X. The way I used to format dates using time.strftime does indeed no longer work. Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) '2005-06-04' Python 2.4 or 2.5: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) Traceback (most recent call last): File stdin, line 1, in ? ValueError: day of year out of range time.strftime(%Y-%m-%d, (2005, 6, 4) + (1,)*6) '2005-06-04' I don't actually run into this problem as I've pretty much converted to use datetime in new code. I also realize that's not documented as the way it should be done, but I'm fairly certain it was common usage before the datetime module came along. Still, it is a bit annoying that the (undocumented, but I think de facto) commonly used idiom no longer works. (In fact, it always bothered me a bit that I had to even provide the unused values.) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On 7/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Michael Well here's one I stumbled across the other day. I don't knowMichael if it's legit, but it's still bad PR:Michael http://www.gbch.net/gjb/blog/software/discuss/python-sucks.htmlMichael For the impatient, he's not at all bothered about the lack ofMichael obscure language feature X. That whole entry is a little overblown. I mean the guy has a single issue with a change and he gives up on the language after only the second one? Try using any language that is under active development and show me stuff that won't break. I think it shows how hard we work to not break things that this guy only got bit twice, and at least the second time was minor and had a legit reason for the change. The way I used to format dates using time.strftime does indeed no longerwork. Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6)'2005-06-04'Python 2.4 or 2.5: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6)Traceback (most recent call last):File stdin, line 1, in ?ValueError: day of year out of range time.strftime (%Y-%m-%d, (2005, 6, 4) + (1,)*6)'2005-06-04'That was done to fix buffer overflow issues when libc implementations didn't do bound checks on the arguments to strftime() and would index too far ( e.g., setting the month as 20 indexes too far and setting to 0 can be an issue as well since the array indexing for the month name will be January, and thus will most likely do ``mon - 1`` to get the index into the array). I don't actually run into this problem as I've pretty much converted to use datetime in new code.I also realize that's not documented as the way itshould be done,It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was. It's also in Misc/NEWS . Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability. but I'm fairly certain it was common usage before thedatetime module came along.Still, it is a bit annoying that the (undocumented, but I think de facto) commonly used idiom no longer works.As I said, stability called for the need to make the change. It was discussed on python-dev when it came up. (In fact, it always bothered me a bit that I had to even provide the unusedvalues.) That would probably be fine to add in 2.6 . Should be a huge issue. You could also change the function to detect values of 0 when provided and then automatically use defaults in those cases that are within the proper range. -Brett ___ 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] User's complaints
Brett That whole entry is a little overblown. Well, sure. Think of it as a bug report with attitude. ;-) Brett That was done to fix buffer overflow issues when libc Brett implementations didn't do bound checks on the arguments to Brett strftime() and would index too far... That special case could simply be recognized and converted into one that works couldn't it? Documented or not, I believe it was the standard idiom for formatting just a date before 2.4. http://python.org/sf/1520914 Keep or toss as you see fit. Seems like breakage that could have been avoided to me though. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Hi, On Tue, Jul 04, 2006 at 04:49:13PM -0700, Neal Norwitz wrote: On 7/4/06, Guido van Rossum [EMAIL PROTECTED] wrote: From actual users of the language I get more complaints about the breakneck speed of Python's evolution than about the brokenness of the current language. I'd like to report another (subjective) experience in favor of the Python is complete enough already camp, from last year's EuroPython, during Guido's keynote. He announced he accepted two of the major 2.5 PEPs: the 'yield' extension, and I think the 'with' statement. This didn't draw much applause. It certainly gave me the impression that many changes in Python are advocated and welcomed by only a small fraction of users. I cannot be objective here, though, being myself firmly of the impression that there are only so many syntactic features you can put in a language before it stops being elegant and starts promoting obscure code... PS. One thing I tend to talk to users about is stability of the interpreter. When I talk about crashing the interpreter, the most common first reaction I get is you can crash the interpreter? How do you do that? I take that answer as a good sign. :-) Indeed :-) Getting some more python-dev discussions about Lib/test/crashers/*.py would be nice too, though. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote: didn't draw much applause. It certainly gave me the impression that many changes in Python are advocated and welcomed by only a small fraction of users. The benefits of changes are usually clear, but I don't think the costs of changes are fully assessed. python-dev considers the cost of changes to CPython's implementation, but I don't think the cost changes to Jython, IronPython, or PyPy are taken into account here. PyPy probably has enough representatives here who would squawk if something was difficult, but I don't think Jython or IronPython do. I think if we assessed those costs fully, the bar for changes to the language would be a good deal higher. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
Not to mention the cost to documentation and books everywhere -- updating our own docs is only the tip of the iceberg. And then updating the users' brains is an even bigger job... (Though at least it is highly parallellizable. :-) --Guido On 7/10/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote: didn't draw much applause. It certainly gave me the impression that many changes in Python are advocated and welcomed by only a small fraction of users. The benefits of changes are usually clear, but I don't think the costs of changes are fully assessed. python-dev considers the cost of changes to CPython's implementation, but I don't think the cost changes to Jython, IronPython, or PyPy are taken into account here. PyPy probably has enough representatives here who would squawk if something was difficult, but I don't think Jython or IronPython do. I think if we assessed those costs fully, the bar for changes to the language would be a good deal higher. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
