Re: [Python-Dev] GSoC Student Introduction, again
> I've already wrapped all the Ttk functionality by now, and I will > complete the documentation till the first betas. > But as you know there isn't much people using (I know myself and a Tcl > guy) so I'm not sure if it would be acceptable to include this module > right into these betas, or would it be ? Should I start doing > something more/else ? No. My question really was whether you see any reason not to bundle Tk 8.5 with Python 2.6 (on Windows). Whether or not the Ttk API is exposed is a different matter - you might consider providing it as a distutils package. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC Student Introduction, again
2008/5/10 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> I've already wrapped all the Ttk functionality by now, and I will >> complete the documentation till the first betas. >> But as you know there isn't much people using (I know myself and a Tcl >> guy) so I'm not sure if it would be acceptable to include this module >> right into these betas, or would it be ? Should I start doing >> something more/else ? > > No. My question really was whether you see any reason not to bundle > Tk 8.5 with Python 2.6 (on Windows). No reasons that I'm aware of, Martin. I haven't tested it under Windows myself but given that it is not supposed to break tk 8.4 apps and I haven't experienced bugs here in Linux, I would say it is a safe bet to start bundling Tk 8.5 within the first betas. > Whether or not the Ttk API is > exposed is a different matter - you might consider providing it > as a distutils package. > > Regards, > Martin > Thanks, -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tool for converting %-formatting to .format()ing ?
On 2008-05-10 01:18, Martin v. Löwis wrote:
Is there a tool available that can convert 2.x code automagically
to the .format() method syntax ?
Just did a quick grep of our code base and it has some 2000 lines of code
that would need to be changed.
Why do you think this code needs to change?
I'd leave all the code as-is, and might not start using .format before
Python 3.2, unless some coding convention says I have to.
True, just wanted to know whether there is such a tool.
I personally like the %-notation a lot, mainly because it's more
or less the same as in C.
%i, %s and %r are by far the most used format characters in our code base.
Determining the position index and writing {0!s} or {0!r} instead
(which requires quite a finger dance on a German keyboard) doesn't
make .format() really attractive, IMHO.
Perhaps you're right and it's better to wait a few rounds of
refinements of .format() before jumping on that train :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 10 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] On quote styles
Moving from python-checkins and giving this topic a proper subject. The original thread started here with a checkin by Benjamin: http://mail.python.org/pipermail/python-checkins/2008-May/069181.html While Python doesn't have a char type (yet), I still find the distinction between 'c' and "abc" useful to show intent (especially given my C background and occasional but increasingly rare dip into the CPython implementation). I must admit though that I'm not as consistent with this as I used to be or would like to be. I guess that's because I'm lazy and the byte compiler doesn't enforce that style. I do prefer to use """ as the triple quote string delimiter because I find that for most of my uses it makes more sense as apostrophes tend to be the quote chars most frequently embedded in them (I don't do much, if any, HTML these days). This is, of course, all personal preference, and definitely not PEP-8-able. maybe-if-we--uncle-timmy-will-sort-it-out-ly y'rs, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On quote styles
[EMAIL PROTECTED] schrieb: Moving from python-checkins and giving this topic a proper subject. The original thread started here with a checkin by Benjamin: http://mail.python.org/pipermail/python-checkins/2008-May/069181.html While Python doesn't have a char type (yet), I still find the distinction between 'c' and "abc" useful to show intent (especially given my C background and occasional but increasingly rare dip into the CPython implementation). I must admit though that I'm not as consistent with this as I used to be or would like to be. I guess that's because I'm lazy and the byte compiler doesn't enforce that style. I do prefer to use """ as the triple quote string delimiter because I find that for most of my uses it makes more sense as apostrophes tend to be the quote chars most frequently embedded in them (I don't do much, if any, HTML these days). This is, of course, all personal preference, and definitely not PEP-8-able. maybe-if-we--uncle-timmy-will-sort-it-out-ly y'rs, I think some people use the two string literal types to distinguish between text (potentially translatable strings) and data. This way, it's much easier to add i18n later if needed. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On quote styles
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | Moving from python-checkins and giving this topic a proper subject. The | original thread started here with a checkin by Benjamin: | |http://mail.python.org/pipermail/python-checkins/2008-May/069181.html To me, those changes are all in the wrong direction and make the code *harder* to read. I tend to use 'hello' for constants and words and "Some original text" for words. I presume this is what Georg B. meant. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On quote styles
[EMAIL PROTECTED] wrote: While Python doesn't have a char type (yet), I still find the distinction between 'c' and "abc" useful to show intent (especially given my C background The way I tend to use them is that "xxx" is for data operated on by the program and seen by the user, and 'xxx' is for things that are only used internally, e.g. enumerated type values and attribute names for use by getattr(). I wouldn't like to see any guideline that said you should only use double quotes or something like that. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On quote styles
Greg> I wouldn't like to see any guideline that said you should only use Greg> double quotes or something like that. It might be useful to have a wiki page which identified some of the conventions people use. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On quote styles
Greg Ewing wrote: I wouldn't like to see any guideline that said you should only use double quotes or something like that. Nah, it was more a philosophical discussion prompted by a comment from me regarding my personal reasons for preferring different styles of quotes in certain situations. The various other comments that have come up is that this is one of the cases where having more than one way to do something is a benefit rather than a problem. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
I just realized that PEP 3108 was missing one proposal from the stdlib SIG (originally proposed by Facundo Batista) of copying the cgi.parse_qs() function over to the new urllib.parse module so that people no longer need to import the cgi module just for that one parsing function. Does anyone object if I update the PEP to include that change? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Trickery with moving urllib
There is going to be an issue with the current proposal for keeping around urllib. Since the package is to be named the same thing as the module, to handle the new name that means urllib.__init__ will need to gain the Py3K warning for the new name. But that doesn't quite work as the package's module will be imported automatically any time the module within the package is used. I see three solutions for dealing with this. 1. Have stubs for the entire urllib API in urllib.__init__ that raise a DeprecationWarning either specifying the new name or saying the function/class is deprecated. 2. Rename urllib to urllib.fetch or urllib.old_request to get people to move over to urllib.request (aka urllib2) at some point. 3. Ditch urllib completely and have people move to urllib.request directly from 2.6 going into 3.0. I was a fan of 3 in the stdlib SIG, but MAL argued well for 2 since so much code uses urllib (although I have always wondered how many *really* use urllib and how many could easily just move over to urllib2). The current solution of keeping around urllib's classes was a compromise, but I had not thought out the transition yet (and Jeremy Hylton will be running into this as he has volunteered to handle this). What do people think we should do? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module Is this the only module morphing into a package of the same name? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? On Sat, May 10, 2008 at 8:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I just realized that PEP 3108 was missing one proposal from the stdlib > SIG (originally proposed by Facundo Batista) of copying the > cgi.parse_qs() function over to the new urllib.parse module so that > people no longer need to import the cgi module just for that one > parsing function. Does anyone object if I update the PEP to include > that change? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? xml.sax.saxutils.escape() would be an appropriate replacement, though the location is a little funky. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
On Sat, May 10, 2008 at 11:43 PM, <[EMAIL PROTECTED]> wrote: > >Brett> There is going to be an issue with the current proposal for >Brett> keeping around urllib. Since the package is to be named the same >Brett> thing as the module > > Is this the only module morphing into a package of the same name? > No, it is not. The dbm package will have the same issue. -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I see three solutions for dealing with this. > > 1. Have stubs for the entire urllib API in urllib.__init__ that raise > a DeprecationWarning either specifying the new name or saying the > function/class is deprecated. > > 2. Rename urllib to urllib.fetch or urllib.old_request to get people > to move over to urllib.request (aka urllib2) at some point. > I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch). -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
