Mailman 3 December 2008 - Python-Dev

Re: [Python-Dev] Python-3.0, unicode, and os.environ
by Adam Olsen 08 Dec '08

08 Dec '08

On Sun, Dec 7, 2008 at 2:07 AM, Hagen Fürstenau <hfuerstenau(a)gmx.net> wrote: >> If the Unicode APIs only have correct unicode, sure. If not you'll >> get errors translating to UTF-8 (and the byte APIs are supposed to >> pass bad names through unaltered.) Kinda ironic, no? > > As far as I can see all Python Unicode strings can be encoded to UTF-8, > even things like lone surrogates because Python doesn't care about them. > So both the Unicode API and the binary API would be fail-safe on Windows. Python is broken and needs to be fixed. http://bugs.python.org/issue3672 http://bugs.python.org/issue3297 -- Adam Olsen, aka Rhamphoryncus

5 13

Re: [Python-Dev] Python-3.0, unicode, and os.environ
by Bugbee, Larry 07 Dec '08

07 Dec '08

There has been some discussion here that users should use the str or byte function variant based on what is relevant to their system, for example when getting a list of file names or opening a file. That thought process really doesn't do much for those of us that write code that needs to run on any platform type, without alteration or the addition of complex if-statements and/or exceptions. Whatever the resolution here, and those of you addressing this thorny issue have my admiration, the solution should be such that it gives consistent behavior regardless of platform type and doesn't require the programmer to know of all the minute details of each possible target platform. That may not be possible for a while, so interim solutions should be such that it minimizes later pain. If that means hiding "implementation details" behind a new function, so be it. Then, at least, the body of one's app is not burdened with this problem later when conditions change. I'm glad I'm not the only one with hard problems. ;-) Larry

8 8

distutils patches, request for review
by Tarek Ziadé 07 Dec '08

07 Dec '08

Hi, I am looking for a core developer to review a few patches for distutils. #1 is mandatory (it removes a bad bug) #2 is very nice to have #3 to #5 are test coverage and code beautication In order: 1. #4400 : the default generated .pypirc is broken. This patch fixes it: http://bugs.python.org/issue4400 2. #4394 : no need to store the password in pypirc anymore : using the prompt if not stored. http://bugs.python.org/issue4394 3. #2461 : more test coverage. http://bugs.python.org/issue2461 4. #3992 : removes custom log implementation -> uses logging instead. http://bugs.python.org/issue3992 5. #3985 : more cleanup. http://bugs.python.org/issue3985 6. #3986 : http://bugs.python.org/issue3986 Some of them are a few month old so I can refresh the patch on the current trunk(s) as soon as they are picked. Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0

Rewrite map for old URLs in place
by Georg Brandl 07 Dec '08

07 Dec '08

Hi, with a bit of delay I finally got around to creating a mod_rewrite map of the 2.5 URLs. URLs like http://docs.python.org/tut/node3.html will now point permanently to the new URL. Let me know if you find a problem. 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.

2 1

Re: [Python-Dev] "as" keyword woes
by Warren DeLano 07 Dec '08

07 Dec '08

> Date: Sat, 6 Dec 2008 12:13:16 -0800 (PST) > From: Carl Banks <pavlovevidence(a)gmail.com> > Subject: Re: "as" keyword woes > To: python-list(a)python.org > Message-ID: > > (snip) > > If you write a PEP, I advise you to try to sound less whiny and than > you have in this thread. > > (snip) Ehem, well, such comments notwithstanding, I thank everyone who responded to my latest post on this topic for taking my inquiry seriously, and for providing cogent, focused, well-reasoned feedback while not resorting to name-calling, to false accusations on top of baseless assumptions, or to explicit personal attacks on my competence, sincerity, experience, credibility, or form. To you especially, I am grateful for your input for your years of service to the community and to the noble ideals you embody in the Python project. May the rest of us (not just myself) be ashamed of our lesser conduct and learn from you exemplary performance. So to summarize, having assimilated all responses over the past several days (python-list as well as python-dev, for the newcomers), I now accept the following as self-evident: -> "as", as a Python keyword, is a here to stay: Love it or leave it. -> Likewise ditto for the GIL: if you truly need Python concurrency within a single process, then use a Python implementation other than CPython. Season's greetings to all! Peace. Cheers, Warren

1 0

Re: [Python-Dev] "as" keyword woes
by Warren DeLano 07 Dec '08

07 Dec '08

> Date: Fri, 05 Dec 2008 22:22:38 -0800 > From: Dennis Lee Bieber <wlfraed(a)ix.netcom.com> > Subject: Re: "as" keyword woes > To: python-list(a)python.org > Message-ID: <bqadnTS6jM21h6fUnZ2dnUVZ_uydnZ2d(a)earthlink.com> > > I'm still in the dark as to what type of data could > even inspire the > use of "as" as an object name... A collection of "a" objects? In which > case, what are the "a"s? <G> Please let me clarify. It is not "as" as a standalone object that we specifically miss in 2.6/3, but rather, the ability to use ".as" used as a method or attribute name. In other words we have lost the ability to refer to "as" as the generalized OOP-compliant/syntax-independent method name for casting: new_object = old_object.as(class_hint) # For example: float_obj = int_obj.as("float") # or float_obj = int_obj.as(float_class) # as opposed to something like float_obj = int_obj.asFloat() # which requires a separate method for each cast, or float_obj = (float)int_obj # which required syntax-dependent casting [language-based rather than object-based]. Of course, use of explicit casting syntax "(float)" is fine if you're restricting yourself to Python and other languages which support casting, but that solution is unavailable inside of a pure OOP message-passing paradigm where object.method(argument) invocations are all you have to work with. Please note that use of object.asClassname(...) is a ubiqitous convention for casting objects to specific classes (seen in ObjectiveC, Java, SmallTalk, etc.). There, I assert that 'object.as(class_reference)' is the simplest and most elegant generalization of this widely-used convention. Indeed, it is the only obvious concise answer, if you are limited to using methods for casting. Although there are other valid domain-specific uses for "as" as either a local variable or attribute names (e.g. systematic naming: as, bs, cs), those aren't nearly as important compared to "as" being available as the name of a generalized casting method -- one that is now strictly denied to users of Python 2.6 and 3. As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name "object_name.as(...)" must necessarily conflict with a standalone keyword " as ". It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? Cheers, Warren

5 4

Re: [Python-Dev] Holding a Python Language Summit at PyCon
by jnoller＠gmail.com 06 Dec '08

06 Dec '08

On Dec 6, 2008 5:42pm, Brett Cannon <brett(a)python.org> wrote: > On Thu, Dec 4, 2008 at 17:02, Frank Wierzbicki wrote: > > > On Thu, Dec 4, 2008 at 3:16 PM, Brett Cannon wrote: > > >> On Thu, Dec 4, 2008 at 12:05, Frank Wierzbicki wrote: > > >>> On Wed, Dec 3, 2008 at 10:31 AM, AM Kuchling wrote: > > >>>> 14:00 - 15:30 > > >>>> ============= > > >>>> > > >>>> Two tracks: > > >>>> > > >>>> Cross-implementation issues: > > >>>> > > >>>> What do the various VMs want/need from CPython to help with their > > >>>> implementations? > > >>>> > > >>>> * Marking CPython-specific tests in the test suite? > > >>>> * Getting an implementation agnostic test suite for the Python language? > > >>>> * Separating the language tests and the pure Python part of the stdlib into > > >>>> a separate project? (Or publish them as a separate package.) > > >>>> * Transition plans for 3.0? > > >>>> > > >>>> Champion needed. > > >>> I would like to champion this one. > > >>> > > >> > > >> I told AMK this a while back, but might as well make it more public; I > > >> am up for chairing as well. > > > Brett, > > > > > > Are you saying you've already called the cross-implementation champion > > > role? > > > > No, I am saying I had told AMK I was interested in championing the > > session. He chose you, and that's that. One less thing for me to worry > > about. =) > > > > > If so I'm happy to defer or co-chair. > > > > Your call. I will definitely be there representing CPython as best as > > I can, so I will be making noise regardless of whether I am standing > > in front of the room or not. > > > > -Brett > Is heckling covered as an official obligation? :) -jesse

1 0

Where/how should I check this in?
by skip＠pobox.com 06 Dec '08

06 Dec '08

I have a change to check in from this issue: http://bugs.python.org/issue4483 It is a build error for _dbmmodule.c which was reported against Python 3.0 involving a change to the layout of symbols in libgdbm. (There is now a libgdbm_compat in some systems which holds the dbm_* symbols.) With one tweak I'm certain needs to be applied to both 2.6 and trunk. Do I just check it in on all three branches and run svnmerge block to keep it from being considered again? Thanks, Skip

1 0

Merging flow
by Jim Jewett 05 Dec '08

05 Dec '08

Nick Coghlan wrote: > For now it looks like we might have to maintain 3.0 manually, with > svnmerge only helping out for trunk->2.6 and trunk->py3k Does it make the bookkeeping horrible if you merge from trunk straight to 3.0, and then blocked svnmerged changes from propagating? -jJ

1 0

__import__ docs follow-up
by Georg Brandl 05 Dec '08

05 Dec '08

Hi, as a follow-up to the thread a few days ago, and the bug report, I've rewritten most of the __import__ docs. I've attached the suggested patch to the issue <http://bugs.python.org/issue4457>. I'd be glad for reviews. Also, I'd like to ask about opinions if this "winning idiom" (as a bug comment states) should be in it, instead of the getattr() helper function: >>> import sys >>> __import__('x.y.z') >>> mod = sys.modules['x.y.z'] 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.

2 1