🌐 Mailman 3 December 2001 - Python-list - python.org

RE: Forcing quote characters in repr(STRING), how?
by duncan＠NOSPAMrcp.co.uk April 12, 2002

April 12, 2002

"Tim Peters" <tim.one(a)home.com> wrote in <mailman.988841104.7613.python- list(a)python.org>: > [François Pinard] >> When using `repr()' on a string, Python automatically selects if it >> will use single or double quotes to enclose the produced >> representation of the string. Is there a clean way to force that >> choice to be, under user control, a particular quote character >> (either simple or double)? > > Not a clean way, nor even a dirty way: the logic is hardcoded. > Never say there isn't a dirty way. The following works, although I really wouldn't recommend it: def quote(s, dquote=0): """Return repr of the string argument forcing single or double quotes.""" if dquote: nasty="'\0" else: nasty='"\0' r = repr(nasty+s) bad = len(`nasty`)-1 r = r[0]+r[bad:] return r if __name__=='__main__': def test(s): print "single quote(%s) -> %s" % (`s`, quote(s, 0)) print "double quote(%s) -> %s" % (`s`, quote(s, 1)) test("ab'cd") test("ab'c\"d") test('ab"cd') -- Duncan Booth duncan(a)rcp.co.uk int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3" "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?

2 1

string compare question.Please Help!!!
by 张少驰 Feb. 16, 2002

Feb. 16, 2002

I have question about cmp function,follows: $python Python 2.2b1 (#1, Nov 21 2001, 10:24:36) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>cmp('10.66.73.78','10.0.0.0') 1 #the result 1 is my desire >>>cmp('10.66.73.78','10.255.255.255') 1 #the result isn't my desire,I want to #make '10.66.73.78' is less than '10.255.255.255', #I want to get 0,but it return 1 Where is my wrong? How to correct it? Thanks. Edward

4 3

Re: Is Stackless Python DEAD?
by claird＠starbase.neosoft.com Feb. 15, 2002

Feb. 15, 2002

In article <mailman.1009806401.11232.python-list(a)python.org>, Christian Tismer <tismer(a)tismer.com> wrote: >Well, it is a little late to answer this, but... > >Michael Hudson wrote: > > > Martin von Loewis <loewis(a)informatik.hu-berlin.de> writes: >... > >... > > >>- It adds a field nesting_level to the thread state, without > >> ever checking its value (it just counts the nesting level) > >> > > > > I imagine this was just for bragging with :) > > >Yes. I needed a way to track when and why there are still >recursions. At sme pahse I also had the idea to drive >decisions on this when I'm allowed to switch things, but >later I learned that this is the wrong way. Along with bragging rights, one of the not-obvious-but- easy-to-explain reasons to introspect on recursion depth is as a defense against denial-of-service (or more un- intentional) security hazards. If you're executing something dynamic enough to give a user a wedge into the execution stack, it's prudent, however crude it might seem, to impose resource limits. One engineering discovery is that recursion depth can be a useful resource to limit. . . . >I'm at a redesign for Stackless 2.2. I hope to make it simpler, >split apart Stackless and optimization, and continuations are >no longer my primary target, but built-in microthreads. Cool! . . . -- Cameron Laird <Cameron(a)Lairds.com> Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html

2 1

AttributeError: 'getopt' module has no attribute 'GetoptError'
by gustafl＠algonet.se Feb. 14, 2002

Feb. 14, 2002

I use Python 2.1 on Win98. Try to use the getopt module, but get the error in the subject line. What's wrong? My code: try: opts, args = getopt.getopt(sys.argv[1:], 'f:hcr') except getopt.GetoptError: usage() sys.exit(2) Another question about getopt: Are options optional by nature? You can't have a mandatory option? Regards, Gustaf Liljegren

4 6

How to generate XML
by Fabrizio Feb. 14, 2002

Feb. 14, 2002

Does anybody know if there are modules to generate XML? I know there is SAX, but it is only for parsing, isn't it? Thank. Fab

10 10

Re: PyFT and PIL
by kern＠myrddin.caltech.edu Feb. 12, 2002

Feb. 12, 2002

In article <mailman.987996754.9967.python-list(a)python.org>, "Chris Gonnerman" <chris.gonnerman(a)usa.net> writes: > Would someone be able to show a working example of PyFT drawing with > "correct" alpha transparency on a PIL pixmap image? This is the main > reason I took over the GD module... I have lots of TrueType fonts and > would like to use them to draw on pictures (i.e. website buttons etc.) > > I could probably figure it out, but I assume someone already has. A > Google search doesn't turn up anything useful (or I'm not doing it > right). Among other reasons, I updated PyFT to handle that gracefully. Because of unavailability of web space for some time, I had only semi-released it. It is now at http://starship.python.net/crew/kernr/source/PyFT-0.65.tar.gz It has a nice class-based wrapper around the nasty function calls. One does essentially the following: >>> f = Font('times', size=12, bold=0, italic=1) >>> rend = BaseRenderer(resolution=(96,96), aa=1) >>> rend.drawString(PIL_image, 'FooBar', x_pos, y_pos, f) and 'FooBar' will be rendered in 12-point, italic Times New Roman onto the PIL Image instance PIL_Image with the appropriate alpha mask. Just set up the font locations correctly at the beginning of the PyFT.py file. I have given up maintenance of PyFT since I've moved onto other things. Steve Alexander has offered to take it over. Of course, someone (not me) should write a new PyFT from scratch to wrap FreeType2. -- Robert Kern kern(a)caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

3 4

zope's acquisition inheritance
by Wostenberg Jan. 31, 2002

Jan. 31, 2002

This Smalltalker has been studying Zope, the Opensourced python product for internet deployment (see http://www.zope.org), to learn. It has an unusual model of interitance called acquisition, which blends class heiarchy with containment. Read http://www.zope.org/Members/Amos/WhatIsAcquisition for introduction. Basically "objects automatically gather. services from their containers.". Everything is potentially a collector-class, and if I drop objects into a collection, they inherit behavior from the container. Weird, but somehow natural in this Web environment which organises content around a tree-structured containment plan. Anybody heard of acquisition outside Zope, or is it a new contribution to OO modelling? -Alan

7 6

SQLBase - Support?
by Nicolas Keller Jan. 29, 2002

Jan. 29, 2002

Hi! I'm looking for a possibility to connect to a Gupta SQLBase Server with Python. As the application will run under Linux (and Zope for the frontend) I guess that it's not possible to use ODBC? Any hints? Thanks and merry xmas :) Nicolas Keller

4 3

eGenix extensions / GMP
by Duncan Smith Jan. 29, 2002

Jan. 29, 2002

I have recently installed the eGenix experimental extensions. This includes a Windows port of GMP 3.1.1. That works fine. But I would also like to use GMP via PyInline (or C++), but the C compiler doesn't seem to recognise that GMP is present. I have also downloaded the Windows port separately from http://www.lemburg.com/files/python/, but I'm not sure where to go from here. Anyone any idea how to sort this out (step by step)? Python 2.1, Visual Studio 6 on Win 2000. Thanks in advance. Duncan Smith

3 3

pep proposal : A date object for the standard library
by s.keim＠laposte.net Jan. 29, 2002

Jan. 29, 2002

hello, This is the first draft of a PEP to introduce a high level date class in python standard library. I have highlighted by [???] the points that I'm not sure. Of course that doesn't mean that the other sentences are true ;-) . Since I am not a brilliant English speaker, grammar would probably need a little refactoring too. PEP: XXX Title: Improving date time support in Python Version: Last-Modified: Author: s.keim(a)laposte.net (Sébastien Keim) Status: Active Type: Informational Created: 29-Nov-2001 Post-History: Abstract Date and Time computation is a bit of mess in almost every programming languages. This is mainly because calendars are a very irregular kind of data. In standard python, dates are defined with two formats: * os module use the POSIX format (elapsed time in seconds since the 1970-01-01) * a tupple is defined in the time module They are low level format, not really user-friendly. This PEP try to define an high level date protocol intended to ease date manipulation in Python. Rationale Fundamentally, a date is the coordinates of a point on the time axis. Calendars are just tools to express this notion with units more suitable for people. During the years people have tried to find a calendar representation that fit their feeling of naturals events. That mean that exist today dozens of calendars, even if the most used is the Gregorian one. This facts mandate several objectives for a python date module: - date arithmetic should be independent of the calendar presentation chosen. - since it's the most widely used, the standard date module should support the Gregorian calendar. - but because some specific applications could need another calendar convention, we shouldmake the creation of new calendar libraries as easy as possible. What exist today for Python A powerful mxDateTime tools already exist but this package is probably to complex to go on the standard distribution[3]. NormalDate define also a light date class[2]. AbstractDate class Many operations on dates, don't bother with the calendar used to process this date. So we can create an AbstractDate class that will define this operations. That mean that they will be allowed for any date objects that would inherit from this class. The first thing that we need is a way to share a date information between dates classes. It's important to define a common lingua for dealing with dates. This will allow the Python users to create several calendar related class without having to boring (to much) with conversions problems. This intermediate format could be defined as a floating point representing the modified juian day numbers[5]. This will be called MJD (Modified Julian Day) in the next part of the document. In this format, the integer part correspond to the number of elapsed days since the start of the day 1858-11-17 CE. Negatives numbers are allowed for date before 1858-11-17. The decimal component is the fraction of the day corresponding to hour minutes and seconds, expressed in GMT. This format has the following advantages: - date arithmetic is easy (number of days between two dates is trivial, the day of week need only to compute a modulo 7 ..) - floating representation allow to compute dates arbitrary far in the past, even if we lose precision. - we keep the better precision for current dates. - algorithms for conversion to Gregorian or Julian dates are well known. - it's a quite standard format. I feel this solution better than the POSIX convention to count the elapsed time in seconds because not all the days have the same length. About once every year or two there is an extra second, called a "leap second" added as the last second of the December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. In MJD format, this seconds won't accumulate for years to years. Each calendar classes should define: - MJD() : method that return the Modified Julian Day from the given date - from_MJD(n) : class method that return a date object from the Modified Julian Day n For converting the MJD in their own calendar protocol. AbstractDate class definition of the operations: - date1 < date2 (and <=, ==, >=, >, <>) - hash value - date + duration ==> date - date - duration ==> date - date - date ==> duration would only depend to from_MJD() and MJD() methods That mean that we will be able to do arithmetic between almost any date objects that would define this two methods. [???]since we deal with real numbers maybe we should define a minimal range where two dates are equals. I don't feel the need to introduce a new type for duration. Duration can be expressed as a floating point number of seconds. This give us all the arithmetic needed and this format is backward compatible with: * timeouts in the thread module * duration computed from dates of files expressed in epoch format(in the os module ) We can define a few numbers of constants: seconds = 1.0 minutes = 60.0 hours = 3600.0 days = 86400.0 weeks = 604800.0 We can't introduce higher constants because we deal here with absolute duration. Length of month or year isn't absolute but relative to the starting date. So relative duration is dependant of the calendar chosen. Default calendar classes AbstractDate class is intended to make the creation of calendar related classes as easy as possible. Netherless I don't think Python user would be happy to have to redefine their own calendar classes for common work on dates. According to the 80-20 rule, this PEP suggest to define for in the standard library a default date class intended to solve the most common date time problems. Default date classe should work with local time. User will have to create subclass for handling non-local times. It would be great if he had only twomethods to redefine, one to convert from GMT to local times, and one for the opposite operation. Because of daylight saving hours, this methods will have to know the empty date to compute, not only the time part. The default methods could use the built-in time module for computing time zone offset. [???] I don't know well the behavior of this module but I don't think it's clever enough to know when daylight saving was introduced in a given time zone. This could introduce errors when we compute dates in the past. [???] The high majority of platforms support the time module but what to do with the one which doesn't? Constructor: If no args current time is used to create the object If one arg ==> the object given in arg must define a MJD() method For more args, the following rule apply: date(year, month, day, hour=0, minute=0, seconds=0) Note that, you could have something like: >>> date(1858,11,17).MJD() -0.25 Where you was probably waiting for 0.0 This is because we use local time, and with your time zone offset, the 1858-11-17 0h00 can actually be something like 1858-11-16 18h00 GMT. [???] Any better way to handle both pure date (without specifying time) and local time zone without ambiguity? A factory function: time(hour, minute, seconds) will create a date object by using current year, month and day. Properties: day(*) month(*) year hour minute second week_day(*) Properties are new in python 2.2, they allow us to assign assessors methods to an attribute. That mean that: - x.day = value will call something like x.set_day(value) - value = x.day will call value = x.get_day() All of this properties return always a valid number, but can accept and process values that are not in the good range. This will allow powerful constructs like x.day += 10 (*) Theses properties use int as input but return a subtype of int that provide the following methods: -name() for sample 'monday' or 'january' -short_name() for sample 'mon' or 'jan' [???] What must be the behavior of x.week_day = Monday : - fix the day to the Monday of the current week - fix the day to the nearest Monday - or to the next (or previous) Monday [???] The returned value could maybe provide more functions for sample: x.month.length() could return the length of the month x.year.leap_year() x.day.year_count() n° of the day in the year But I think we can live without this for the moment. [???] Should we append a week property for dealing with num of weeks ? String formating: str(format=None) : return the date as string, format is a string like in the time.strptime function. (note: __str__ will call self.str()) from_str(value, format=None) : parse a string to create a date object [???] it would me more Pythonic to use the standard constructor to create a date object from string. But on the over hand class constructor is already rather complex. [???] It seems that the time.strptime function doesn't work well on all platforms. Maybe that in theses case we should provide an alternate function like in [4] And what should we do: always use the python function or only when the C one is broken? (then how to detect this?) [???] should we provide a set of predefined format strings (and which ones?)? At least me must define the format string used when format=None (the ISO notation?) localization: Date and time format are heavily related to localization for: (1) daylight saving and time zone (2) date formatting conventions (3) nouns of months and days (1) is currently handled by the time module (almost on my computer). (2) is probably related to locals module but I haven't seen something about it. (3) is dependant of a translation utility for python. I don't know if they are projects for this. For now we could probably just handle (1). But we should be careful to allow us to adopt (2) and (3) later without breaking user code. Backward compatibility issues: All of this can be written in pure python in a standalone module. So I don't note any compatibility problems directly related to this PEP. Since the date class use properties, class methods and built-in types inheritance, it will need Python 2.2. There is probably some changes to do in standard library to really fit the date classes. For sample the date objects currently returned by python modules could support the MJD() method. But this is out of the scope of this PEP. References [1] Calendar FAQ http://www.tondering.dk/claus/calendar.html [2] NormalDate module for Python http://starship.python.net/crew/jbauer/normaldate/ [3] mxDateTime module for Python http://www.lemburg.com/files/python/mxDateTime.html [4] strptime implementation in Python http://www.fukt.hk-r.se/~flognat/hacks/strptime.py [5] The julian day number http://serendipity.magnet.ch/hermetic/cal_stud/jdn.htm Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil fill-column: 70 End:

14 32