🌐 Mailman 3 August 2004 - Python-list - python.org

bsddb
by Ajay Brar Aug. 5, 2004

Aug. 5, 2004

hi! when i do an import bsddb, it tries do do an import _bsddb i looked around Python23\Lib but couldn't find any _bsddp file....or am i totally on the wrong track. the reason i am asking is, i am trying to port a Python app to a pocket pc and python release for pocket pc does not have bsddb module. thanks cheers -- Ajay Brar CS Honours 2004 Smart Internet Technology Research Group http://www.it.usyd.edu.au/~abrar1

4 3

Re: Decorator syntax (was Re: PEP 318 - PyFIT comments)
by Michael Ressler Aug. 5, 2004

Aug. 5, 2004

On 2004-08-04, Delaney, Timothy C (Timothy) <tdelaney(a)avaya.com> wrote: > Christopher T King wrote: > >> On 4 Aug 2004, Nick Vargish wrote: >> >>> I just don't know where else to voice my opinion on this matter, but >>> I absolutely hate the new decorator syntax. > > @classmethod > def func (args): > @attr = 1 > pass I'm just a dumb user of Python - I don't even program for a living, so there is no reason any of you should listen to me, but this @-syntax thing makes Python look like Perl. The reason I learned Python was that Perl looks like line noise to me, and I wanted a scripting language I could read. Please don't wreck a beautiful, readable language with this shortcut. Choose a word for it, not a symbol, please. Mike

3 2

Re: Confused about pep 318
by Edward K. Ream Aug. 5, 2004

Aug. 5, 2004

> As in many other software efforts, the code has moved along a bit > faster than the documentation (after all, what's more fun to do?). ... > Guido indicated there that he brought up the topic at > EuroPython in his keynote talk and entertained discussion from the floor. > Based upon that discussion he decided to go with the @-decorator syntax. Well, this isn't good. We are talking about a basic design document here. I feel like I have been kept in the dark; my previous relative silence is hardly evidence of my agreement. How is it possible to pretend that people agree with a proposal that DOES NOT EXIST? I am -10 on pep 318 now: this process amounts to a rigged election. I might become neutral in the future once the hood is removed from over the candidate's head :-) > I believe the only significant differences from a pure functional > documentation standpoint to apply to the PEP are the syntax Why is something "spectacular" like the '@' sign is needed? Presumably there is some problem with the compiler? Has anyone suggested something like: from __future__ import annotation as annotate annotate.accepts(int, (int,float)) instead of: @accepts(int, (int,float)) Clearly, with enough work the Python compiler could recognize this. Yes, it's a special case, but so what? This would avoid most problems with reserved words or keywords. And it would be in the spirit of letting modules encapsulate most major features. Edward P.S. The more I think of this proposal, the more unhappy I become. In fact, this proposal may have a most unfortunate effect on Leo's future, for two reasons: 1. Although Leo handles constructs like @accepts, it does so by generating lines like this: #@verbatim @accepts(int, (int,float)) So _Leo_ has no problem, but Leo's users will likely complain that more cruft has been added to their files. 2. Leo presently supports the following directives: @ (followed by one or more whitespace characters) @all, @asis, @c, @code, @color, @comment, @delims, @doc, @encoding, @end_raw, @file, @first, @header, @ignore, @killcolor, @language, @last, @lineending, @nocolor, @noheader, @noref, @nosent, @nowrap, @others, @pagewidth, @path, @quiet, @raw, @root, @root-code, @root-doc, @silent, @tabwidth, @terse, @thin, @unit, @verbose, @wrap Worse, Leo allows plugins to define their own directives. There is already a plugin that defines @wiki. Furthermore, @run, @test and @suite are also used in special contexts. What happens when another Python @x construct conflicts with one of these directives or some other directive? I'm starting to wonder whether Python is a snake or a gorilla :-) Yes, Python does have the right to use '@'. But I would hope that GvR would choose not to do so. I was always under the impression that the clear statement in the Reference Manual that at signs are invalid everywhere (except in comments and strings) was a clear signal of an intention to keep those symbols for other valid purposes. I am extremely unhappy that this may not be so. P.P.S. I did respond earlier to the requested survey, saying in brief that I had no problems with 318 provided that '@' signs did not become a part of the syntax. I have received no reply from anyone. There is no way somebody could construe my previous statements as approval. EKR -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

1 0

Perl's Crypt::PasswdMD5
by Bart Nessux Aug. 5, 2004

Aug. 5, 2004

Does Python have anything similar to Perl's Crypt::PasswdMD5??? I read about the crypt module... but it only does DES. Any plans to add md5 or other digests to it in the future?

5 4

Re: Modern dead-tree Python resources
by Nelson Minar Aug. 4, 2004

Aug. 4, 2004

Like others, I like Python in a Nutshell. Dive into Python is a new book out by an excellent author http://diveintomark.org/archives/2004/07/18/dive-into-python You can read it online too: http://diveintopython.org/

1 0

RE: RE: Finding all time periods for a given interval within a daterange
by Robert Brewer Aug. 4, 2004

Aug. 4, 2004

I wrote: > Look at my 'recur' module and see if it fits your requirements: > > http://www.aminus.org/rbre/python/index.html Tim Churches: > How is the above code licensed? Me: > Anything on that page is public domain. Use it as you see fit. Tim: > Would you be so kind as it include a note in the actual code > to that effect? Copyright needs to be explicitly waived in most > countries these days (unlike previously when copyright needed > to be explicitly claimed). Sure thing. Give me a couple of days. FuManChu

1 0

Re: RE: Finding all time periods for a given interval within a daterange
by Tim Churches Aug. 4, 2004

Aug. 4, 2004

Robert Brewer <fumanchu(a)amor.org> wrote: > > Tim Churches wrote: > > On Thu, 2004-08-05 at 03:09, Robert Brewer wrote: > > > Look at my 'recur' module and see if it fits your requirements: > > > > > > http://www.aminus.org/rbre/python/index.html > > > > > > Start with the Recurrence class and play with it--then dig > > deeper if you > > > need to. > > > > Robert, > > > > How is the above code licensed? > > Anything on that page is public domain. Use it as you see fit. Would you be so kind as it include a note in teh actual code to that effect? Copyright needs to be explicitly waived in most countries these days (unlike previously when copyright needed to be explicitly claimed). Thanks, Tim C

1 0

Re: Decorator syntax (was Re: PEP 318 - PyFIT comments)
by David Eppstein Aug. 4, 2004

Aug. 4, 2004

In article <mailman.1162.1091660561.5135.python-list(a)python.org>, "Delaney, Timothy C (Timothy)" <tdelaney(a)avaya.com> wrote: > Besides, @ could possibly be reused for function attributes, meaning > it's less "wasted" - there's also an obvious correlation in that both > decorators and function attributes operate on the function object: > > @classmethod > def func (args): > @attr = 1 > pass > > Tim Delaney Hey, an actual reason for the restricted syntax in the current decorator implementation: it makes it less likely that @decorators will conflict with potential other @syntaxes such as this @attribute one. -- David Eppstein Computer Science Dept., Univ. of California, Irvine http://www.ics.uci.edu/~eppstein/

1 0

eric3 completion
by grv575＠hotmail.com Aug. 4, 2004

Aug. 4, 2004

This is the only IDE that looks very useable on linux of everything I've looked at (and not to start a dev environment war) but one thing that is troublesome is the word completion. There is a user-contributed script to parse all the dll and py files to make a list of functions & attributes for each namespace, but it doesn't pick up some things like file.seek() and datetime.today(). The script complains that no source files found, yet other built-ins like open() are picked up. Any guidelines on how to get all the default stuff working for code completion?

3 3

RE: Decorator syntax (was Re: PEP 318 - PyFIT comments)
by Delaney, Timothy C (Timothy) Aug. 4, 2004

Aug. 4, 2004

Christopher T King wrote: > On 4 Aug 2004, Nick Vargish wrote: > >> I just don't know where else to voice my opinion on this matter, but >> I absolutely hate the new decorator syntax. > > I wish PEPs had a method through which votes could be cast, for or > against the PEP (or parts of it), not unlike Bugzilla bugs. At least The last vote was an unmitigated disaster. And there appears to be no more agreement on the correct syntax for decorators. The difference is that decorator syntax will have significant benefits for a certain class of project. > democratic input. Either way, I really wish he would hold off on > decorators until there's a consensus on them, rather than forcing > them in amidst all the disagreements surrounding them. There are significant projects that will greatly benefit from decorator syntax - for example, PyObjC. Personally, I don't overly like the new syntax - I much preferred def func (args) [decorators] - and I would have preferred not to "waste" @ for them, but I can definitely live with the decision. Some usable decorator syntax is IMO more important than none. Besides, @ could possibly be reused for function attributes, meaning it's less "wasted" - there's also an obvious correlation in that both decorators and function attributes operate on the function object: @classmethod def func (args): @attr = 1 pass Tim Delaney

1 0