Mailman 3 February 2003 - Python-Dev

Re: Gadfly in Python core
by Aaron Watters Feb. 11, 2003

Feb. 11, 2003

Hi Guido, Stuart, python-dev, Stuart was nice enough to forward this information to me and I would be delighted. I don't know exactly how to "transfer" a copyright, but I'd be happy to do it. Thanks for the interest! -- Aaron Watters (ps: I would have sent a more appropriate email yesterday, Stuart, but I was snowed under with work) Stuart Bishop wrote: > Hi. > > I don't know if you saw this thread or not on Python-dev: > http://mail.python.org/pipermail/python-dev/2003-January/032295.html > > Looks like Gadfly can go into the core Python distribution. One of the > outstanding issues is that of the licence, which concerned Guido: > http://mail.python.org/pipermail/python-dev/2003-January/032305.html > > Would you be interested in allowing the PSF to distribute Gadfly under > its own licence to simplify things? >

1 0

Re: GadflyDA in core? Or as add-on-product?
by Stuart Bishop Feb. 11, 2003

Feb. 11, 2003

On Wednesday, January 22, 2003, at 08:22 AM, Guido van Rossum wrote: >>>> My personal belief would be to include Gadfly in Python: >>>> - Provides a reason for the DB API docs to be merged into the >>>> Python library reference >>>> - Gives Python relational DB stuff out of the box ala Java, >>>> but with a working RDBMS as well ala nothing else I'm aware >>>> of. >>>> - Makes including GadflyDA in Zope 3 a trivial decision, since >>>> its size would be negligable and the DA code itself is >>>> already ZPL. >>> >>> Would you be willing to find out (from c.l.py) how much interest >>> there is in this? >> >> A fairly positive response from the DB SIG. The trick will be to fix >> the outstanding bugs or disable those features (losing the 'group >> by' and 'unique' SQL clauses), and to confirm and fix any departures >> from the DB-API 2.0 standard, as this would become a reference >> implementation of sorts. >> >> There is no permanent maintainer, as Richard Jones is in more of a >> caretaker role with the code. I'll volunteer to try and get the code >> into a Python release though. >> >> If fixes, documentation and tests can be organized by the end of >> January for alpha2, will this go out with Python 2.3 (assuming a >> signoff on quality by python-dev and the DB-SIG)? If not, Jim is >> back to deciding if he should include Gadfly with Zope3. > > Sorry for not responding before. I'm open for doing this, but you > should probably probe python-dev next before you start a big coding > project. How much C code is involved in Gadfly? If it's a lot, I'm a > lot more reluctant, because C code usually requires much more > maintenance (rare is the C source file that doesn't have some hidden > platform dependency). Gadfly comes with kjbuckets, which is written in C. The rest is Python. Gadfly uses the included kjbuckets for storage if it is available, but happily runs without it with a performance hit. So Jython gets a RDBMS implementation too. -- Stuart Bishop <zen(a)shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/

6 17

pickle me, Elmo?
by Paul F Dubois Feb. 11, 2003

Feb. 11, 2003

I read the new PEP about pickling with much interest and little comprehension. I'd like to comment then just by saying what I wish I could do and invite response as to whether the PEP will help do it. I would like to be able to: Save and restore a class definition Save and restore a function definition

6 9

RE: [Python-checkins] python/dist/src/Python bltinmodule.c,2.276,2.277
by Tim Peters Feb. 11, 2003

Feb. 11, 2003

[Jack Jansen] > ... > If you build with Apple's MPW compilers it probably is, but (a) these > compilers are horribly outdated and (b) it would take major surgery to > compile Python with MPW anyway, nowadays. In that case, can we remove the MPW #ifdef's from the Python core? Things like object.c's #ifdef MPW /* MPW C modf expects pointer to extended as second argument */ { extended e; fractpart = modf(v, &e); intpart = e; } #else fractpart = modf(v, &intpart); #endif and mathmodule.c's flea on the tip of the tail of the dog #ifdef MPW_3_1 /* This hack is needed for MPW 3.1 but not for 3.2 ... */ FUNC2(pow, power, "pow(x,y)\n\nReturn x**y (x to the power of y).") #else and acceler.c's germ on the aforemetioned flea's hindquarters: #ifdef MPW_881_BUG /* In 881 mode MPW 3.1 has a code generation bug which seems to set the upper bits; fix this by explicitly masking them off */ int temp; #endif And so on. These don't really improve maintainability <wink>.

2 1

vox populii illiterati
by Paul F Dubois Feb. 11, 2003

Feb. 11, 2003

I very much appreciate Guido putting forward a PEP on if expressions, but I must say the idea of letting c.l.p 'vote' on it is unwelcome. Voting only makes sense when an electorate is educated enough to properly understand the proposition and its consequences; the discussion so far makes clear that that isn't true. Programming languages need to be designed, not agglutinated. (Otherwise you get Perl and Fortran 2000 (:->) I think it is fair to say that being the head designer of a language can lead to frustration at times; I had to endure it on a much smaller scale and it was very hard to keep patiently explaining how the features had to fit together, and how they had to be both parseable and implementable and learnable, and that not every little difficulty is worth a language feature. In the cases of several of the features adopted recently, a quick inspection has initially led me to believe that the feature was not interesting but study showed that it was. I just don't think you can delegate this kind of study to a group that is mostly inexperienced even at programming much less language design. I want my BDFL. As Davy Crockett said, "Be sure you're right, then go ahead." Paul Dubois

20 41

Unicode filenames
by Just van Rossum Feb. 10, 2003

Feb. 10, 2003

MacOSX fully supports unicode filenames (utf-8 is used throughout), and I'm tempted to set Py_FileSystemDefaultEncoding to "utf8" for OSX. Jack pointed me to a long thread about unicode filenames that took place on python-dev last year, but I can't deduce from it whether there are any disadvantages of setting Py_FileSystemDefaultEncoding. Setting it seems to work wonderful. However, I'm a bit surprised that os.listdir() doesn't return unicode strings. Is that because it would break too much code? BTW. if I try to create a file with an 8-bit filename which is _not_ valid utf-8, I get a strange error: >>> f = open("\xff", "w") Traceback (most recent call last): File "<stdin>", line 1, in ? IOError: invalid mode: w >>> This exception is thrown when errno is EINVAL, which apparently can also mean that the filename arg is bad. Not sure if we can fix this. Just

4 7

Adding Japanese Codecs to the distro
by M.-A. Lemburg Feb. 10, 2003

Feb. 10, 2003

Hisao SUZUKI has just recently uploaded a patch to SF which includes codecs for the Japanese encodings EUC-JP, Shift_JIS and ISO-2022-JP and wants to contribute the code to the PSF. The advantage of his codecs over the ones written by Tamito KAJIYAMA (http://www.asahi-net.or.jp/~rd6t-kjym/python/) lies in the fact that Hisao's codecs are small (88kB) and written in pure Python. This makes it much easier to adapt the codecs to special needs or to correct errors. Provided Hisao volunteers to maintain these codecs, I'd like to suggest adding them to Python's encodings package and making them the default implementations for the above encodings. Ideal would be if we could get Hisao and Tamito to team up to support these codecs (I put him on CC). Adding the codecs to the distribution would give Python a very good argument in the Japanese world and also help people working with XML or HTML targetting these locales. Thoughts ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

10 37

thunks
by Guido van Rossum Feb. 10, 2003

Feb. 10, 2003

I still don't have time to read this thread :-(, but I had a new idea that I'd like to fly here. If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it: Thunk blending in: [<variable> =] <expression>: <block> Thunk introducing a new local scope: [<variable> =] <expression> lambda: <block> (Never mind the ugly things I've said about lambda in the past. :-) I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells. Adding formal parameters to the second case would go like this: [<variable> =] <expression> lambda <arguments>: <block> One concern I have in both cases: I think there are use cases for wanting more than one block. Glyph's example wants to define various callbacks for a remote call, and this would need multiple blocks. I think the syntax for this would have to use some kind of keyword-based continuation, e.g. [<variable> =] <expression> lambda: <block> and <expression> lambda: <block> ... Disclaimer: this is a half-baked idea. --Guido van Rossum (home page: http://www.python.org/~guido/)

29 74

bitwise operators and lambdas
by Jack Diederich Feb. 10, 2003

Feb. 10, 2003

I don't expect action or consensus on these, but I thought I get them on record by posting 1) move bitwise operators to a package and deprecate them from the language as special syntax 2) use pipes as shorthand for lambdas re: 1) bitwise operators bitwise OR is used on 61 lines in Lib/ out of 70k+ lines. There is nothing inheritly un-pythonic about bitwise operators but they don't really come up much in a high level language like python. They just seem 'extra' esp since we spell || as 'or' and && as 'and'. sets are about the only thing to usefully define __xor__ and its kind. re: 2) lambda shorthand Most people hate lambdas, but I like em. They would beat listcomps in readability if it weren't for the clunky appearance of the string 'lambda' everywhere they are used. People seem to like list comps over filter/map mainly because they save keystrokes. old shorthand lambda:foo() ||foo() lambda x:foo(x) |x|foo(x) l = [x.guy for (x) in blah] l = map(|x|x.guy, blah) l = [x for (x) in blah if x < 7] l = filter(|x|x < 7, blah) l = [x.guy for (x) in blah if x.guy < 7] l = map(|x|x.guy, filter(|x|x.guy < 7, blah)) I also like the passing-something-on implication of using a pipe character. Plus I like the left-to-right reading of map/filter over listcomps. dreaming-of-pytohn-3k-ly, -jackdied

3 2

UNREF invalid object
by Gustavo Niemeyer Feb. 10, 2003

Feb. 10, 2003

Hello! I've been playing with the bz2module to remove the file inheritance, as requested. While doing so, I've got the "UNREF invalid object" error when trying to run PyObject_Del(), inside a dealloc function, on an object which is not "externally" accessible (it's part of the class structure only, and has obj->ob_refcnt == 1, as expected). I'll replace the PyObject_Del() by Py_DECREF() which fixes the problem and feels more elegant to me anyway. OTOH, I wouldn't like to get over the problem without knowing what's really happening. Is this a common problem pattern? Thanks! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

2 2