Re: [Python-Dev] Fwd: Re: [Python-3000] Removing functions from the operator module
Hi Collin, On Wed, Mar 07, 2007 at 11:53:45PM -0600, Collin Winter wrote: bool() and abs() aren't syntax, so I would never look in operator. abs() is not syntax but bool() is part of every syntactic construction that takes a truth value argument (if, while, and, ...) 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
[Python-Dev] pydoc II
Hi, There was a thread some weeks ago about work on pydoc, with the admitted aim of proposing something as an upgrade to the current pydoc. We had a number of suggestions, on this very list or privately, and we looked into having something that would not only retain the capabilities of the current pydoc but facilitate customization when it comes to formatting the help, or process the docstrings. Looking at things, and implementing along to see how it would look like, we are coming to something that looks very much like a new implementation... and before going further I would like to ensure that that does not mean an automatic no way. The obvious question is why change something that is working ?, and the answer is as simple as although pydoc is a very helpful, there are a number of functionalities that appeared wished so much that other modules appeared. What is proposed here is along the line of the same but more extensible. The pydoc envisioned is both a library for extracting documentation, as well as few standalone applications using that library (a documentation browser, an interactive console help... just like pydoc currently has). A prototype is being worked on, and I have been looking at code and/or functionalities in pydoc, epydoc, pydoctor, and ipython (for the interactive console), and there a lot of nice things in all these efforts. The name of the game is now to have something that likely to offer the best of all (although it can be an easy way to get no one happy in the end). Hopefully someone kept reading up to here... Some of the key points so far: library: - ability to browse documentation inside module/package files without loading them - ability to browse documentation attached to live (that is loaded) objects - documentation API that is independent of whether the object is loaded or not - low-energy barrier for adding support for other-than-plain-text docstrings - features like searching objects by name, or by content in their doctring applications: - HTML server to consult the documentation for installed packages - interactive console to consults the documentation for installed and/or loaded objects - generation of HTML documentation How does this sound so far ? Laurent ___ 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] pydoc II
On 3/11/07, Laurent Gautier [EMAIL PROTECTED] wrote:[...] A prototype is being worked on, and I have been looking at code and/or functionalities in pydoc, epydoc, pydoctor, and ipython (for the interactive console), and there a lot of nice things in all these efforts. The name of the game is now to have something that likely to offer the best of all (although it can be an easy way to get no one happy in the end). Hopefully someone kept reading up to here... Some of the key points so far: library: - ability to browse documentation inside module/package files without loading them Most importantly, we also need the reserve: ability to attach external documentation to modules/packages without increasing their size. For instance, one of the reasons no one ever bothered to add pydoc documentation to PyGTK (beyond a few docstrings that can be generated in runtime) is that the entire documentation for PyGTK would be far too large to place directly into the module readonly data segment. Documentation should be able to live in another file, separate from the module source code, and loaded on demand. Loading the pydoc file should be preferably done through read-only memory mapping a file. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ 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] pydoc II
2007/3/11, Gustavo Carneiro [EMAIL PROTECTED]: On 3/11/07, Laurent Gautier [EMAIL PROTECTED] wrote: [...] A prototype is being worked on, and I have been looking at code and/or functionalities in pydoc, epydoc, pydoctor, and ipython (for the interactive console), and there a lot of nice things in all these efforts. The name of the game is now to have something that likely to offer the best of all (although it can be an easy way to get no one happy in the end). Hopefully someone kept reading up to here... Some of the key points so far: library: - ability to browse documentation inside module/package files without loading them Most importantly, we also need the reserve: ability to attach external documentation to modules/packages without increasing their size. I suspect that this will sparkle a long thread about python documentation system, but I will comment nevertheless while trying to avoid being caught in the middle. Well this sort of thing is technically feasible, and when I am looking solely at pydoc the deal for me is how can it be made easily and as little hackish as possible. For instance, one of the reasons no one ever bothered to add pydoc documentation to PyGTK (beyond a few docstrings that can be generated in runtime) is that the entire documentation for PyGTK would be far too large to place directly into the module readonly data segment. Documentation should be able to live in another file, separate from the module source code, and loaded on demand. Loading the pydoc file should be preferably done through read-only memory mapping a file. Well, that's an interesting idea... and the structure we start having could see something along those lines implemented. Being something non-standard for the time being, that would be something that the maintainer of the module having that particular request would take care of. (the deal with pydoc would be to make plugging that in easy) Instructions to use that other-documentation through pydoc could be included in the top-level docstring for the pygtk module for example... how does this sound ? L. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ 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] pydoc II
Gustavo Carneiro [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Most importantly, we also need the reserve: ability to attach external | documentation to modules/packages without increasing their size. Perhaps use .pd for the extension tjr ___ 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] datetime module enhancements
At 5:45 PM +1300 3/11/07, Greg Ewing wrote: Jon Ribbens wrote: What do you feel next Tuesday plus 12 hours means? ;-) I would say it's meaningless. My feeling is that subtracting two dates should give an integer number of days, and that is all you should be allowed to add to a date. Apple's old MacOS had a very flexible LongDateRecord and date utilities. Nearly anything one could do to a date had a useful meaning. Perhaps Python should be different, but I've found Apple's date calculations and date parsing to be very useful, in a Pythonic sort of way. From old New Inside Macintosh, _Operating System Utilities_, Ch. 4 Date, Time, and Measurement Utilities: Calculating Dates - In the date-time record and long date-time record, any value in the month, day, hour, minute, or second field that exceeds the maximum value allowed for that field, will cause a wraparound to a future date and time when you modify the date-time format. * In the month field, values greater than 12 cause a wraparound to a future year and month. * In the day field, values greater than the number of days in a given month cause a wraparound to a future month and day. * In the hour field, values greater than 23 cause a wraparound to a future day and hour. * In the minute field, values greater than 59 cause a wraparound to a future hour and minute. * In the seconds field, values greater than 59 cause a wraparound to a future minute and seconds. You can use these wraparound facts to calculate and retrieve information about a specific date. For example, you can use a date-time record and the DateToSeconds and SecondsToDate procedures to calculate the 300th day of 1994. Set the month field of the date-time record to 1 and the year field to 1994. To find the 300th day of 1994, set the day field of the date-time record to 300. Initialize the rest of the fields in the record to values that do not exceed the maximum value allowed for that field. (Refer to the description of the date-time record on page 4-23 for a complete list of possible values). To force a wrap-around, first convert the date and time (in this example, January 1, 1994) to the number of seconds elapsed since midnight, January 1, 1904 (by calling the DateToSeconds procedure). Once you have converted the date and time to a number of seconds, you convert the number of seconds back to a date and time (by calling the SecondsToDate procedure). The fields in the date-time record now contain the values that represent the 300th day of 1994. Listing 4-6 shows an application-defined procedure that calculates the 300th day of the Gregorian calendar year using a date-time record. Listing 4-6 Calculating the 300th day of the year PROCEDURE MyCalculate300Day; VAR myDateTimeRec: DateTimeRec; mySeconds: LongInt; BEGIN WITH myDateTimeRec DO BEGIN year := 1994; month := 1; day := 300; hour := 0; minute := 0; second := 0; dayOfWeek := 1; END; DateToSeconds (myDateTimeRec, mySeconds); SecondsToDate (mySeconds, myDateTimeRec); END; The DateToSeconds procedure converts the date and time to the number of seconds elapsed since midnight, January 1, 1904, and the SecondsToDate procedure converts the number of seconds back to a date and time. After the conversions, the values in the year, month, day, and dayOfWeek fields of the myDateTimeRec record represent the year, month, day of the month, and day of the week for the 300th day of 1994. If the values in the hour, minute, and second fields do not exceed the maximum value allowed for each field, the values remain the same after the conversions (in this example, the time is exactly 12:00 A.M.). Similarly, you can use a long date-time record and the LongDateToSeconds and LongSecondsToDate procedures to compute the day of the week corresponding to a given date. Listing 4-7 shows an application-defined procedure that computes and retrieves the name of the day for July 4, 1776. Note that because the year is prior to 1904, it is necessary to use a long date-time record. -- TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.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] datetime module enhancements
On Sun, Mar 11, 2007 at 11:02:39AM -0500, Tony Nelson wrote: Apple's old MacOS had a very flexible LongDateRecord and date utilities. Nearly anything one could do to a date had a useful meaning. Perhaps Python should be different, but I've found Apple's date calculations and date parsing to be very useful, in a Pythonic sort of way. Python world has excellent mxDateTime that does a very good job of date parsing and date/time arithmetic! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] datetime module enhancements
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote: I see you snipped without response my request to back up your claim that assuming that a date() is a datetime() with a time of midnight will clearly break that logic. Am I to assume you cannot back it up? I was trying to minimize the extent of this already too long thread, assuming you could go do the reading I referred you to if you were really interested in the answer. I still encourage you to read the reference, but for your sake, here's a brief example of temporal logic that would break:: We know that: date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1) And under your definition date(2006, 1, 1) *Is Simultaneous With* datetime(2006, 1, 1, 0, 0, 0) But that's a contradiction because datetime(2006, 1, 1, 0, 0, 0) *Does Not Include* datetime(2006, 1, 1, 0, 0, 1) Hope that helps, STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens schrieb: I see you snipped without response my request to back up your claim that assuming that a date() is a datetime() with a time of midnight will clearly break that logic. I've another idea. Date and datetime objects are compared by date. The date object for a given date is always smaller than the datetime for the same day - even for midnight. The date 2007-01-02 is smaller than 2007-01-02 00:00:00 but larger than 2007-01-01 24:00:00. date(2007, 1, 2) datetime(2007, 1, 2, 0, 0, 0) True date(2007, 1, 2) datetime(2007, 1, 1, 24, 0, 0) True date(2007, 1, 2) == datetime(2007, 1, 2, 0, 0, 0) False date(2007, 1, 2) in datetime(2007, 1, 2, 0, 0, 0) TypeError(...) datetime(2007, 1, 2, 0, 0, 0) date(2007, 1, 2) TypeError(...) datetime(2007, 1, 2, 0, 0, 0) date(2007, 1, 2) TypeError(...) datetime(2007, 1, 2, 0, 0, 0) == date(2007, 1, 2) False datetime(2007, 1, 2, 0, 0, 0) in date(2007, 1, 2) True ___ 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] Backports of standard library modules
Please forgive me if this has already been discussed -- I only recently started paying any attention to this list. Many versions of python include new standard library modules that could (or often do already) work fine with previous versions. Some of the modules are brand-new, written explicitly for the standard library, and others are preexisting modules that, by community consensus, are added to the library. It seems that once a new library module is added, if it doesn't rely heavily on new core language features, it should also be added for previous versions. Obviously, it doesn't make sense to re-release an old version of Python just because a new library is available (or even to include the new library in the old version), but it might make sense to have a separate package of extras or backported modules that is re-released for prior versions whenever a new (compatible) module is added to the standard library. Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Regards, Pat ___ 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] datetime module enhancements
On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote: Jon Ribbens schrieb: I see you snipped without response my request to back up your claim that assuming that a date() is a datetime() with a time of midnight will clearly break that logic. I've another idea. Date and datetime objects are compared by date. The date object for a given date is always smaller than the datetime for the same day - even for midnight. I really don't understand what the problem is with having a date() behave like a proper temporal interval. The only person complaining about that interpretation acknowledged that for his purposes, it would be better than the status quo. And I have yet to see a use case where being consistent with temporal interval logic is a problem. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
On 3/11/07, Steven Bethard [EMAIL PROTECTED] wrote: On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote: I've another idea. Date and datetime objects are compared by date. The date object for a given date is always smaller than the datetime for the same day - even for midnight. I really don't understand what the problem is with having a date() behave like a proper temporal interval. The only person complaining about that interpretation acknowledged that for his purposes, it would be better than the status quo. And I have yet to see a use case where being consistent with temporal interval logic is a problem. I do not really understand proper temporal intervals. But I am interested what temporal interval logic has to say about this problem: def get_most_recent_articles(articles, cutoff_date): recent_articles = [] for article in articles: if article.datetime_posted cutoff_date: recent_articles.append(article) return recent_articles Would temporal interval logic make it so an article with datetime(2007, 1, 1, 0, 0, 0) be included, if cutoff_date was date(2007, 1, 1)? What about articles with datetimes (2007, 1, 1, 0, 0, 1) and (2007, 1, 2, 0, 0, 0) respectively? I believe that temporal interval logic has to include at least the last two examples in recent_articles, otherwise it would be highly annoying. -- mvh Björn ___ 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] Backports of standard library modules
On 3/11/07, Patrick Maupin [EMAIL PROTECTED] wrote: Please forgive me if this has already been discussed -- I only recently started paying any attention to this list. Many versions of python include new standard library modules that could (or often do already) work fine with previous versions. Some of the modules are brand-new, written explicitly for the standard library, and others are preexisting modules that, by community consensus, are added to the library. It seems that once a new library module is added, if it doesn't rely heavily on new core language features, it should also be added for previous versions. Obviously, it doesn't make sense to re-release an old version of Python just because a new library is available (or even to include the new library in the old version), but it might make sense to have a separate package of extras or backported modules that is re-released for prior versions whenever a new (compatible) module is added to the standard library. Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. A problem with doing this is whether this will put any extra burden on python-dev. It's fine if people want to pull out of the stdlib, package them, and do that work, but in no way should we have to maintain version compatibility or worry about backporting fixes once the package is released. I would personally rather have an informal package done to completely avoid these issues. That way no one feels obliged to keep doing this after every release. -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] datetime module enhancements
On 3/11/07, BJörn Lindqvist [EMAIL PROTECTED] wrote: I do not really understand proper temporal intervals. But I am interested what temporal interval logic has to say about this problem: def get_most_recent_articles(articles, cutoff_date): recent_articles = [] for article in articles: if article.datetime_posted cutoff_date: recent_articles.append(article) return recent_articles Thanks for being concrete here. =) Would temporal interval logic make it so an article with datetime(2007, 1, 1, 0, 0, 0) be included, if cutoff_date was date(2007, 1, 1)? No, datetime(2007, 1, 1, 0, 0, 0) is not *after* date(2007, 1, 1), it is *included* within it. If you want an article with that datetime to be included, you should be comparing against datetime(2006, 12, 31, 23, 59, 59) or date(2006, 12, 31). What about articles with datetimes (2007, 1, 1, 0, 0, 1) No. For the same reason as above. and (2007, 1, 2, 0, 0, 0) respectively? Yes. I believe that temporal interval logic has to include at least the last two examples in recent_articles, otherwise it would be highly annoying. Could you elaborate? Right now, to get the results you want with your code, you have to compare against datetime(2006, 12, 31, 23, 59, 59). How is comparing against date(2006, 12, 31) any worse? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module enhancements
Jon Ribbens wrote: Robert Brewer [EMAIL PROTECTED] wrote: One solution that just occurred to me -- and that skirts the issue of choosing an interpretation -- is that, when comparing date and datetime objects, the datetime's .date() method is called and the result of that call is compared to the original date. +1 ...and it's a decision that can be made independently of how to add or subtract dates. I don't like it. It sounds suspiciously like when comparing integers and floats, discard the non-integer portion of the float and then compare as integers. ...which can happen quite often, depending on your domain's requirements for significant digits. Integers and floats are numbers, not units, so a more proper analogy would have been, it sounds like when comparing feet and inches, divide inches by 12 and discard any remainder. Which, again, can happen quite often. But even feet and inches aren't a good analogy, because people don't say, six-foot-three is six feet. But they *do* say, is it Thursday right now? quite often, and expect a yes-or-no answer, not cannot compute. A slightly better analogy would be armies and platoons: when you compare armies (on almost any scale except size), you can't say an army is more or less than a platoon in that same army. The platoon is (part of) the army and the army is (made of) the platoons. So order is important only at a given level of granularity: Army1 = [P1, P2, P3] Army2 = [Px, Py, Pz] sorted([Army1, Army2, P1, P2, P3, Px, Py, Pz]) [Army1, P1, P2, P3, Px, Py, Army2, Pz] ...that is, it doesn't matter where Army2 appears, as long as it's in the second half of the list. Note that the platoons can still be ordered relative to other platoons in the same army. Likewise, when comparing dates to date-times (but not when adding them), the mental model of dates and times acts more like nested sets than continuous functions: Date1 = Datetimes(1, 2, 3) Date2 = Datetimes(x, y, z) sorted([Date1, Date2, ...]) [Date1, T1, T2, T3, Tx, Ty, Date2, Tz] ...and the above can be achieved by: class nested_datetime(datetime): def __cmp__(self, other): if isinstance(other, datetime): return datetime.__cmp__(self, other) elif isinstance(other, date): return cmp(self.date(), other) raise TypeError Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ 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] datetime module enhancements
Steven Bethard [EMAIL PROTECTED] wrote: I was trying to minimize the extent of this already too long thread, assuming you could go do the reading I referred you to if you were really interested in the answer. There's nothing to be gained by being patronising. I still encourage you to read the reference, but for your sake, here's a brief example of temporal logic that would break:: We know that: date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1) Oh dear. You've fallen at the first hurdle. We do not know that. You are assuming the answer you want and then using it as an axiom. Your justification for this assumption was the whole point of my question, but you have again failed to answer. I don't know how much clearer I can make this, given that I have explicitly mentioned it several times already. Hope that helps, No, it doesn't. Seriously, please try and understand this. I get that you wish Python datetime was the ultra-complete temporal logic module you want it to be. Good for you. I sympathise. If it was, I would agree with you. But it isn't. It's a simple module for dealing with calendar dates and times, not intervals in time. It makes pragmatic assumptions about what people mean when they use date arithmetic. They might not be the assumptions you want, but then it's probably not the module you want. ___ 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] datetime module enhancements
On 3/11/07, Jon Ribbens [EMAIL PROTECTED] wrote: [snark] It makes pragmatic assumptions about what people mean when they use date arithmetic. They might not be the assumptions you want, but then it's probably not the module you want. Please find or write a package that makes the assumptions you want, since datetime clearly isn't the module you want. Anyone desperate to discuss the nuances and finer points of dates and time algebras in Python, take it to python-ideas. Collin Winter ___ 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] Backports of standard library modules
On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote: If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Isn't this PEP 297? This does raise an interesting question, though, since I'm about to get into PEP authorship myself. Have I missed an official way to propose alternatives or resurrect a languishing PEP? I'd like very much to propose to obsolete PEP 355 with twisted's FilePath object that I've previously discussed, but ... does that mean adding text to 355? writing a new PEP and referencing it? Also, the language/library evolution PEP I would like to write is basically an expanded version of PEP 5, but that is apparently moribund (and not followed, according to MvL). Above all, how can I help to motivate timely yea-or-nay decisions from the BDFL or his chosen consultants? PEP 1 seems to defer all of these questions to emailing the PEP editor; is that really the best way to go? ___ 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-3000 upgrade path
I wrote two versions of the dict views refactoring. One that turns d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()). This one is pretty robust except if you have classes that emulate 2.x-style dicts. But it generates ugly code. So I have a light-weight version that leaves d.keys() alone, while turning d.iterkeys() into d.keys(). This generates prettier code but more buggy. I probably should have used the heavy-duty one instead. The ugliness is a virtue in this case as it stands out enough to motivate developers to review each case. The pretty/efficient version is tantamount to guessing, and effectively discards information in the transformation (here be dragons). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ 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] Backports of standard library modules
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote: If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Isn't this PEP 297? I'd say it's almost a subset of PEP 297. This does raise an interesting question, though, since I'm about to get into PEP authorship myself. Have I missed an official way to propose alternatives or resurrect a languishing PEP? I'd like very much to propose to obsolete PEP 355 with twisted's FilePath object that I've previously discussed, but ... does that mean adding text to 355? writing a new PEP and referencing it? The introduction to PEP 342 would be a good starting point; it was built on a number of prior PEPs. Above all, how can I help to motivate timely yea-or-nay decisions from the BDFL or his chosen consultants? PEP 1 seems to defer all of these questions to emailing the PEP editor; is that really the best way to go? From my own experience, the best way is tight, focused discussion that avoids or short-circuits interminable bikeshedding threads; see Ben North's exemplary work on the (ultimately rejected) PEP on dynamic attribute access syntax from February 2007 (http://mail.python.org/pipermail/python-dev/2007-February/, search for his name). Collin Winter ___ 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] datetime module enhancements
Collin Winter [EMAIL PROTECTED] wrote: Please find or write a package that makes the assumptions you want, since datetime clearly isn't the module you want. Datetime clearly *is* the module I want. It already makes the assumptions I want, I just want it to make them consistently. ___ 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] Backports of standard library modules
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Isn't this PEP 297? Thanks for pointing that out. I looked for a relevant PEP, but didn't notice this one. I think this is complementary, but (if I am reading it correctly) it is not exactly the same. The alternate search path is a necessary part of what I am suggesting, but the meat of my proposal (which Brett correctly discerned would require ongoing effort :) is that, when I go to the downloads page for Python 2.3, in addition to downloading Python, I could download all the compatible libraries which were included in later versions as a single installable file. When 2.6 comes out, this extras package would be upgraded to include any new modules in 2.6. Not a lot of fun for people who live on the bleeding edge, but very useful for people who are stuck with an older version for political or other reasons. Regards, Pat ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 380 open (-36) / 3658 closed (+65) / 4038 total (+29) Bugs: 965 open ( -9) / 6555 closed (+35) / 7520 total (+26) RFE : 272 open ( +4) / 253 closed ( +2) / 525 total ( +6) New / Reopened Patches __ Extension documentation for subclasses (2007-03-01) CLOSED http://python.org/sf/1671450 opened by Pete Shinners MultiCall bug crashing the config dialog (2007-03-02) CLOSED http://python.org/sf/1672481 opened by Tal Einat urllib2 requests history + HEAD support (2007-03-03) http://python.org/sf/1673007 opened by KDanilov aka koder README update: Bash default on ac OS X (2007-03-03) CLOSED http://python.org/sf/1673121 opened by Witten Mac OS X: libtool (2007-03-03) http://python.org/sf/1673122 opened by Witten change repr(...) from 'Ellipsis' to '...' (2007-03-04) CLOSED http://python.org/sf/1673355 opened by John Reese Identify modules to be built and not built (2007-03-04) CLOSED http://python.org/sf/1673619 opened by Skip Montanaro 'G' formatting doesn't catch same errors as 'g' (2007-03-04) http://python.org/sf/1673759 opened by Eric V. Smith Identify modules which couldn't be built (2007-03-04) CLOSED http://python.org/sf/1673619 reopened by loewis sq_ass_slice ignored if sq_slice not defined (2007-03-05) CLOSED http://python.org/sf/1674228 opened by ?iga Seilnacht Epoll wrapper (2007-03-06) http://python.org/sf/1675118 opened by TH Draft implementation for PEP 364 (2007-03-06) http://python.org/sf/1675334 opened by Barry A. Warsaw PEP 3114 -- next() - __next__() (2007-03-07) http://python.org/sf/1675363 opened by Georg Brandl Make PyComplex_AsCComplex use __complex__ (2007-03-07) http://python.org/sf/1675423 opened by Mark Dickinson Zipfile tweaks and test coverage improvement (2007-03-06) http://python.org/sf/1675424 opened by Alan McIntyre Use getaddrinfo() in urllib2.py for IPv6 support (2007-03-07) http://python.org/sf/1675455 opened by David Cantrell Refactor test_pty.py to use unittest. (2007-03-06) CLOSED http://python.org/sf/1675471 opened by Jerry Seutter [gzip] Performance for small reads and fix seek problem (2007-03-07) http://python.org/sf/1675951 opened by Florian Festi Remove dead code in typeobject's type_new() (2007-03-07) CLOSED http://python.org/sf/1675981 opened by ?iga Seilnacht Remove trailing slash from --prefix (2007-03-07) http://python.org/sf/1676135 opened by Björn Lindqvist New File I/O type for Python 3000, plus .h and unit tests (2007-02-28) CLOSED http://python.org/sf/1671314 reopened by collinwinter Add a PeriodicTimer to threading (2007-03-08) http://python.org/sf/1676820 opened by Björn Lindqvist Adding timeout to socket.py and httplib.py (2007-03-08) http://python.org/sf/1676823 opened by Facundo Batista Refactor test_popen2.py to use unittest. (2007-03-08) http://python.org/sf/1676994 opened by Jerry Seutter Support CREATE_SUSPENDED flag in subprocess.py for Win32 (2007-03-09) http://python.org/sf/1677688 opened by Chris Heller site.py small ?bug fix | change? (2007-03-10) http://python.org/sf/1677862 opened by KDanilov aka koder Efficient reverse line iterator (2007-03-10) http://python.org/sf/1677872 opened by Mark Russell Removal of Tuple Parameter Unpacking [PEP3113] (2007-03-10) http://python.org/sf/1678060 opened by Tony Lownds improve telnetlib.Telnet so option negotiation becomes easie (2007-03-10) http://python.org/sf/1678077 opened by Björn Lindqvist Refactor test_operations.py to use unittest. (2007-03-10) http://python.org/sf/1678088 opened by Jerry Seutter Adding a testcase for the bug in find_longest_match (2007-03-11) http://python.org/sf/1678339 opened by Denys Rtveliashvili A fix for the bug #1528074 [warning: quite slow] (2007-03-11) http://python.org/sf/1678345 opened by Denys Rtveliashvili Patches Closed __ Extension documentation for subclasses (2007-03-01) http://python.org/sf/1671450 closed by gbrandl MultiCall bug crashing the config dialog (2007-03-02) http://python.org/sf/1672481 closed by gbrandl README update: Bash default on Mac OS X (2007-03-03) http://python.org/sf/1673121 closed by gbrandl change repr(...) from 'Ellipsis' to '...' (2007-03-04) http://python.org/sf/1673355 closed by gvanrossum Use a set to keep interned strings (2006-06-16) http://python.org/sf/1507011 closed by loewis Add support for the If-Modified-Since header (2006-03-04) http://python.org/sf/1442867 closed by loewis N-d array interface for array object (2006-03-18) http://python.org/sf/1452906 closed by loewis Fix for win32 proxy bypass support (no_proxy) in urllib(2) (2005-03-01)
[Python-Dev] These csv test cases seem incorrect to me...
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to read/grok/modify/fix bugs in a Python
implementation than in the current mixed Python/C implementation.
* With alternative implementations of Python available (PyPy,
IronPython, Jython) it makes sense to have a Python version they can
use.
I'm far from having anything which will pass the current test suite, but in
diagnosing some of my current failures I noticed a couple test cases which
seem wrong. In the TestDialectExcel class I see these two questionable
tests:
def test_quotes_and_more(self):
self.readerAssertEqual('ab', [['ab']])
def test_quote_and_quote(self):
self.readerAssertEqual('a b', [['a b']])
It seems to me that if a field starts with a quote it *has* to be a quoted
field. Any quotes appearing within a quoted field have to be escaped and
the field has to end with a quote. Both of these test cases fail on or the
other assumption. If they are indeed both correct and I'm just looking at
things crosseyed I think they at least deserve comments explaining why they
are correct.
Both test cases date from the first checkin. I performed the checkin
because of the group developing the module I believe I was the only one with
checkin privileges at the time, not because I wrote the test cases.
Any ideas about why these test cases are in there? I can't imagine Excel
generating either one.
Thx,
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] These csv test cases seem incorrect to me...
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
Several other people have already done this. I will forward you their
e-mail address in a separate private e-mail.
I'm far from having anything which will pass the current test suite, but in
diagnosing some of my current failures I noticed a couple test cases which
seem wrong. In the TestDialectExcel class I see these two questionable
tests:
def test_quotes_and_more(self):
self.readerAssertEqual('ab', [['ab']])
def test_quote_and_quote(self):
self.readerAssertEqual('a b', [['a b']])
[...]
Any ideas about why these test cases are in there? I can't imagine Excel
generating either one.
The point was to produce the same results as Excel. Sure, Excel probably
doesn't generate crap like this itself, but 3rd parties do, and people
complain if we don't parse it just like Excel (sigh).
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
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] These csv test cases seem incorrect to me...
Andrew McNamara [EMAIL PROTECTED] wrote: The point was to produce the same results as Excel. Sure, Excel probably doesn't generate crap like this itself, but 3rd parties do, and people complain if we don't parse it just like Excel (sigh). The slight problem with copying Excel is that Excel won't parse its own CSV output. ___ 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] These csv test cases seem incorrect to me...
I'm far from having anything which will pass the current test suite,
but in diagnosing some of my current failures I noticed a couple test
cases which seem wrong. In the TestDialectExcel class I see these
two questionable tests:
def test_quotes_and_more(self):
self.readerAssertEqual('ab', [['ab']])
def test_quote_and_quote(self):
self.readerAssertEqual('a b', [['a b']])
Andrew The point was to produce the same results as Excel. Sure, Excel
Andrew probably doesn't generate crap like this itself, but 3rd parties
Andrew do, and people complain if we don't parse it just like Excel
Andrew (sigh).
(sigh) indeed.
Thanks,
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] [Csv] These csv test cases seem incorrect to me...
John IMHO these test cases are *WRONG* and it's a worry that they John work with the current csv module :-( That's my take on things as well, though as Andrew pointed out, given those invalid inputs Excel will produce those wacky outputs. I verified that on my Mac a few minutes ago. I'm inclined to just skip those tests in my Python version, but I can understand that for backwards compatibility the current module needs to grok them. 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] [Csv] These csv test cases seem incorrect to me...
On 12/03/2007 1:01 PM, [EMAIL PROTECTED] wrote:
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to read/grok/modify/fix bugs in a Python
implementation than in the current mixed Python/C implementation.
* With alternative implementations of Python available (PyPy,
IronPython, Jython) it makes sense to have a Python version they can
use.
I'm far from having anything which will pass the current test suite, but in
diagnosing some of my current failures I noticed a couple test cases which
seem wrong. In the TestDialectExcel class I see these two questionable
tests:
def test_quotes_and_more(self):
self.readerAssertEqual('ab', [['ab']])
def test_quote_and_quote(self):
self.readerAssertEqual('a b', [['a b']])
It seems to me that if a field starts with a quote it *has* to be a quoted
field. Any quotes appearing within a quoted field have to be escaped and
the field has to end with a quote. Both of these test cases fail on or the
other assumption. If they are indeed both correct and I'm just looking at
things crosseyed I think they at least deserve comments explaining why they
are correct.
Both test cases date from the first checkin. I performed the checkin
because of the group developing the module I believe I was the only one with
checkin privileges at the time, not because I wrote the test cases.
Any ideas about why these test cases are in there? I can't imagine Excel
generating either one.
Hi Skip,
'ab' can't be produced by applying minimalist CSV writing rules to
'ab'. A non-minimalist writer could produce 'ab', but certainly not
'ab'.
The second case is worse -- it's inconsistent; the reader is supposed to
remove the quotes from a but not from b???
IMHO these test cases are *WRONG* and it's a worry that they work with
the current csv module :-(
Regards,
John
___
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] [Csv] These csv test cases seem incorrect to me...
On 12/03/2007 1:41 PM, Andrew McNamara wrote: The point was to produce the same results as Excel. Sure, Excel probably doesn't generate crap like this itself, but 3rd parties do, and people complain if we don't parse it just like Excel (sigh). Let's put a little flesh on those a's and b's: A typical example of the first case is where a database address line contains a quoted house name e.g. Dunromin, 123 Main Street and the producer of the CSV file has not done any quoting at all. An example of the 2nd case is a database address line like this: C/o Mrs Jones, Dunromin, 123 Main Street and the producer of the CSV file has merely wrapped quotes about it without doubling the existing quotes, to emit this: C/o Mrs Jones, Dunromin, 123 Main Street which Excel and adherents would distort to two fields containing: 'C/o Mrs Jones, Dunromin' and ' 123 Main Street' -- aarrgghh!! People who complain as described are IMHO misguided; they are accepting crap and losing data (yes, the quotes in the above examples are *DATA*). Why should we heed their complaints? Perhaps we could consider a non-default dopey_like_Excel option for csv :-) BTW, it is possible to do a reasonable recovery job when the producer's protocol was to wrap quotes around the data without doubling existing quotes, providing there were an even number of quotes to start with. It just requires a quite different finite state machine. Cheers, John ___ 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] datetime module enhancements
Jon Ribbens wrote: Steven Bethard [EMAIL PROTECTED] wrote: We know that: date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1) Oh dear. You've fallen at the first hurdle. We do not know that. Translated into English, this is saying The 1st of January 2006 includes the time one minute past midnight on the 1st of January 2006. That doesn't seem a very controversial thing to believe. -- 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] [Csv] These csv test cases seem incorrect to me...
IMHO these test cases are *WRONG* and it's a worry that they work with the current csv module :-( Those tests are not wrong - they verify that we produce the same result as Excel when presented with those inputs, which was one of the design goals of the module (and is an important consideration for many of it's users). While you might find the Excel team's choices bizare, they are stable, and in the absence of a formal specification for CSV, Excel's behaviour is what most users want and expect. If you feel like extending the parser to optionally accept some other format, I have no problem. If you want to make this format the default, make sure you stick around to answer all the angry e-mail from users. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ 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] Folding test_operations in to test_dict
Jerry Seutter posted patch #1678088 yesterday, which converts test_operations over to use unittest and folds the resulting code into test_dict. It struck me as a good idea, because a) it gets away from output/-based tests, and b) test_operations tests certain dictionary operations, something that would seem at home in test_dict. Before I commit this, though, I want to ask: is there a reason test_operations is separate? I notice that it's listed in regrtest.py in the run these tests before everything else list, which made me think test_operations is on its own for a reason. Collin Winter ___ 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] Folding test_operations in to test_dict
On 3/11/07, Collin Winter [EMAIL PROTECTED] wrote: Jerry Seutter posted patch #1678088 yesterday, which converts test_operations over to use unittest and folds the resulting code into test_dict. It struck me as a good idea, because a) it gets away from output/-based tests, and b) test_operations tests certain dictionary operations, something that would seem at home in test_dict. Before I commit this, though, I want to ask: is there a reason test_operations is separate? I notice that it's listed in regrtest.py in the run these tests before everything else list, which made me think test_operations is on its own for a reason. svn log shows only one 'recent' checkin from last year. Prior to that there were only a few checkins and they are from 1992 (Guido) - 2001 (Tim). Seems like this file is just a historical relic that can go away. 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] fmod.c
Unless someone speaks up to save Python/fmod.c, I'll remove this file in a few days. Thanks Paul! n -- On 3/10/07, Paul Hankin [EMAIL PROTECTED] wrote: Hi all, Is there any need for Python/fmod.c any more? I can't see how it can be included because there's no test for fmod in the ./configure script and grepping all files in the tree for fmod.c finds nothing except a commented out line in PC/os2vacpp/makefile.omk If it is needed, it needs fixing as it gives the wrong answer for x=0 and y0. Eg: fmod(0, -1) returns 1 rather than 0. (The comment in fmod.c is correct: it should return f such that x = i*y + f for some integer i, st |f| |y| and f has the same sign as x). I'm happy to patch it, but I won't if it would be better just to remove the file. -- Paul Hankin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc II
Laurent Gautier wrote: - low-energy barrier for adding support for other-than-plain-text docstrings I'd be interested in discussing this offline (I might have already spoken to you about it before, but I don't remember who I spoke to.) I think I've mentioned before about DocLobster, which is my unpublished prototype of a subtle markup language that tries to embed semantic tags in the text, without causing the text to look like it has been marked up. -- Talin ___ 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
