<steve+comp.lang.pyt...@pearwood.info> wrote:
>> Latest version has a simpler, cleaner API, and works on PyPy (and
>> hopefully the other implementations as well ;), as well as CPython.
>>I don't generally click on arbitrary links to find out whether or not the
>>link is something that interests me enough to click on it.
> Can't really call a cheese shop link arbitrary. It's in the best place
> it could be for providing info about the package.
True, but Steven's point still stands, that announcements of this
nature are far more readable when they open with a one-sentence
statement of what the package _is_.
On Fri, 20 Jul 2012 19:56:59 -0700, Temia Eszteri wrote:
>>I don't generally click on arbitrary links to find out whether or not
>>the link is something that interests me enough to click on it.
> Can't really call a cheese shop link arbitrary. It's in the best place
> it could be for providing info about the package.
You've missed the point. Why should I bother to click on it at all, PyPI or not, if I'm going to find it is a library for something I don't care about? If the developer of the library doesn't write a few words to tell people what his library does when making an announcement, or what improvements there are from the previous release, he's going to struggle to attract even those users who *would* be interested, if only they knew about it.
This mailing list is about helping our fellow Python developers improve their skills and solve problems. That doesn't just mean *coding* problems, it also means helping them to write better documentation and promote their software better.
For every person like me who takes the time out to gently remind the developer that we aren't mind-readers and don't know WTF he's talking about, there are a thousand who just move on, and he's just lost 99% of his potential user-base. Since he's taken the time out to make a public announcement, I assume he would like people to use his software. If not, why bother making the announcement at all?
Unless the software is so well-known that everybody knows what it is, failure to mention what the software does gives the impression that:
1) the software is so niche, or so ill-thought out, that the developer *can't* describe it succinctly;
2) the developer has such poor communication skills that trying to get support will be a nightmare;
3) that he just doesn't give a monkey's toss for anyone else's time
or all three. Ethan is a good, helpful member of this community, and
so I'm pretty sure that neither 2) nor 3) are true, but others may get
the wrong impression.
Here are a few randomly selected examples of good release announcements:
>>>I don't generally click on arbitrary links to find out whether or not the
>>>link is something that interests me enough to click on it.
>> Can't really call a cheese shop link arbitrary. It's in the best place
>> it could be for providing info about the package.
>True, but Steven's point still stands, that announcements of this
>nature are far more readable when they open with a one-sentence
>statement of what the package _is_.
>ChrisA
If I wanted to counter his whole point, I would've quoted his whole
post. ;P Yes, the post to the newsgroup is rather oblique, but the
cheese shop is hardly arbitrary.
Steven D'Aprano wrote:
> On Fri, 20 Jul 2012 16:59:21 -0700, Ethan Furman wrote:
>> Getting closer to a stable release.
> Excellent! That's fantastic news! I've been waiting for a stable release > of dbf for months! I just have one question.
> What is dbf?
:)
dbf (also known as python dbase) is a module for reading/writing
dBase III, FP, VFP, and soon Clipper, .dbf database files. It's
an ancient format that still finds lots of use.
It even reads and writes memo fields -- something which none of the other modules do (which is why I wrote this one -- I needed that! ;).
It supports unicode, and returns all fields as native Python types:
Character --> unicode
Date --> datetime.date
Logical --> bool/None
Memo --> unicode
Numeric --> int/float depending on field definition
If a field is uninitialized (Date, Logical, Numeric) then None is returned for the value.
Tables are accessible as lists; Records are accessible as lists, dicts, and objects ( attribute access ).
On Sat, 21 Jul 2012 13:30:40 +1000, Simon Cropper wrote:
> Works with PyPy, OK.
> Hopefully works with other implementations, Hm, what does this mean?
I guess that Ethan means that his library definitely works with PyPy and CPython, because he has tested it on those, and that he expects that it will work with Stackless, Jython, IronPython, and any other compliant Python interpreter, but hasn't tested on them.
> Works or hopefully works with CPython -- which is it?
I agree that the sentence is unclear, but my reading of it is that it works on CPython.
<steve+comp.lang.pyt...@pearwood.info> wrote:
> Unless the software is so well-known that everybody knows what it is...
I've yet to meet ANY piece of software that's like that. Even with
releases of CPython (arguably the primary point of this list) it
wouldn't hurt to give an explanation, and certainly with other
Pythons, it'd help a lot (PyPy and Jython are probably guessable, but
I wouldn't bet on anyone knowing what "IronPython" is without a
summary).
> Here are a few randomly selected examples of good release announcements:
Steven D'Aprano wrote:
> This mailing list is about helping our fellow Python developers improve > their skills and solve problems. That doesn't just mean *coding* > problems, it also means helping them to write better documentation and > promote their software better.
Indeed it is, and your reminder is appreciated. Hopefully my followup-post was more explanatory.
> Unless the software is so well-known that everybody knows what it is, > failure to mention what the software does gives the impression that:
> 1) the software is so niche, or so ill-thought out, that the developer > *can't* describe it succinctly;
Nah -- just the end of a long week, needed to go get my daughter, and wanted it out there for those few who actually need the bug fixes (which I neglected to mention).
> 2) the developer has such poor communication skills that trying to get > support will be a nightmare;
My support is pretty good. :)
> 3) that he just doesn't give a monkey's toss for anyone else's time
See point one.
> or all three. Ethan is a good, helpful member of this community, and
> so I'm pretty sure that neither 2) nor 3) are true, but others may get
> the wrong impression.
Thank you. The project is kinda niche, but very useful if you happen to be in that niche.
> Here are a few randomly selected examples of good release announcements:
On Sat, Jul 21, 2012 at 6:02 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> Works with CPython 2.4 - 2.7. (Tested)
Have you considered supporting 3.2/3.3 at all? It's often not
difficult to make your code compatible with both. Or is there some
dependency that is locked to 2.X?
Chris Angelico wrote:
> On Sat, Jul 21, 2012 at 6:02 PM, Ethan Furman <et...@stoneleaf.us> wrote:
>> Works with CPython 2.4 - 2.7. (Tested)
> Have you considered supporting 3.2/3.3 at all? It's often not
> difficult to make your code compatible with both. Or is there some
> dependency that is locked to 2.X?
I'll support 3.3+, but not with the same code base: I want to use all the cool features that 3.3 has! :)
On Sun, Jul 22, 2012 at 4:15 AM, Ethan Furman <et...@stoneleaf.us> wrote:
> I'll support 3.3+, but not with the same code base: I want to use all the
> cool features that 3.3 has! :)
The trouble with double-codebasing is that you have double
maintenance. But sure. So long as your time isn't under great
pressure, it can be quite effective.
Recommendation: Figure out a way to minimize double-handling of
things. One way might be to have source control manage it for you -
apply a patch to your 3.3+ source tree, then merge it into your 2.4+
tree and see if it applies cleanly. I dunno how successful that'd be,
but I really dread the idea of maintaining, unassisted, two identical
projects in two dialects of the same language. Recipe for burnout I'd
predict.
> dbf (also known as python dbase) is a module for reading/writing
> dBase III, FP, VFP, and soon Clipper, .dbf database files. It's
> an ancient format that still finds lots of use.
Other than the caring for the ancient legacy data, it is still widely used in GIS, because shapefiles (http://en.wikipedia.org/wiki/Shapefile) are based on it.
I have been using http://sourceforge.net/projects/harbour-project/ for years where a guy called Przemyslaw Czerpak has written an absolutely bullet proof implementation of NTX and CDX for DBF. Maybe it will interest you.
> I have been using http://sourceforge.net/projects/harbour-project/ for
> years where a guy called Przemyslaw Czerpak has written an absolutely
> bullet proof implementation of NTX and CDX for DBF. Maybe it will
> interest you.
> I have been using http://sourceforge.net/projects/harbour-project/ for > years where a guy called Przemyslaw Czerpak has written an absolutely > bullet proof implementation of NTX and CDX for DBF. Maybe it will > interest you.
Ethan Furman wrote:
> Alex Strickland wrote:
>> "Not supported: index files":
>> I have been using http://sourceforge.net/projects/harbour-project/ for >> years where a guy called Przemyslaw Czerpak has written an absolutely >> bullet proof implementation of NTX and CDX for DBF. Maybe it will >> interest you.
> I'll check it out, thanks!
Unfortunately his code is GPL'ed, so I can't use it. :(
Chris Angelico wrote:
> On Sun, Jul 22, 2012 at 4:15 AM, Ethan Furman <et...@stoneleaf.us> wrote:
>> I'll support 3.3+, but not with the same code base: I want to use all the
>> cool features that 3.3 has! :)
> The trouble with double-codebasing is that you have double
> maintenance. But sure. So long as your time isn't under great
> pressure, it can be quite effective.
Once I get dbf.py to 1.0 release, it will enter maintenance/bug-fix-only mode, and I'll start on the 3.3+ version.
The 1.0 release will have the final API, support for Clipper tables, hopefully support for auto-incrementing fields, maybe support for .idx files, plus everything there now.
.cdx files (and maybe .idx files) will have to wait for the 3.3+ version.
