On 7/22/2011 5:17 PM, Ned Deily wrote:
In article,
Terry Reedy wrote:
This introduced the problem that upgrading to Python 3 is no longer a
single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3,
etc, but someone would have to make the new versions, but no one,
currently, has
In article ,
Terry Reedy wrote:
> This introduced the problem that upgrading to Python 3 is no longer a
> single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3,
> etc, but someone would have to make the new versions, but no one,
> currently, has the energy and interest to do t
On 7/22/2011 4:26 AM, Lars Gustäbel wrote:
On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote:
PS: I will be posting more warts very soon. This stdlib is a gawd
awful mess!
I do not agree. Although I come across one or two odd things myself from time
to time, I think the stdlib as a
On 7/22/2011 2:40 AM, rantingrick wrote:
On Jul 22, 12:45 am, Terry Reedy wrote:
Let me give some overall comments rather than respond point by point.
Python-dev is a volunteer *human* community, not a faceless corporation,
with an ever-changing composition (a very mutable set;-).
It is too
On Jul 22, 3:49 am, Lars Gustäbel wrote:
> One could get the impression that you are leading a grass-roots movement
> fighting a big faceless corporation. Instead, what you're dealing with is this
> warm and friendly Python community you could as well be a part of if you are a
> reasonable guy an
Oh, and:
On Sat, Jul 23, 2011 at 3:11 AM, rantingrick wrote:
> Will you be starting with the zipfile API migration?
>
Will you?
Rick, quit ranting and start coding. If you want things to happen, the
best way is to do them. If you make a post on the dev list WITH A
PATCH, or submit your patch on
On Sat, Jul 23, 2011 at 3:11 AM, rantingrick wrote:
> WWrong! It is more that just a MERE preference. Tarfile and zipfile
> are BOTH archive modules and as such should present a consistent API.
> I really don't care so much about the actual details AS LONG AS THE
> APIs ARE CONSISTENT!
Python and
On Jul 22, 3:26 am, Lars Gustäbel wrote:
> There is a reason why these two APIs are different. When I wrote tarfile
> zipfile had already been existing for maybe 8 years and I didn't like its
> interface very much. So, I came up with a different one for tarfile that in my
> opinion was more gener
On 07/22/2011 03:26 AM, Lars Gustäbel wrote:
On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote:
Tarfile is missing the attribute "fp" and instead exposes a
boolean "closed". This mismatching API is asinine! Both
tarfile and zipfile should behave EXACTLY like file objects
What do you
On 22/07/11 05:46, rantingrick wrote:
> PS: I will be posting more warts very soon. This stdlib is a gawd
> awful mess!
Please don't. Not here.
There's a wonderful bug tracker at python.org. Use that. That's where
this kind of thing belongs. And, please, be concise.
What's the point of shouting
On Thu, Jul 21, 2011 at 10:58:37PM -0700, rantingrick wrote:
> My hat is off to you Mr. Richardson. I've even considered creating my
> own clean versions of these two modules, because heck, it is not that
> difficult to do! However we must stop fixing these warts on a local
> level Corey. We MUST c
On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote:
> I may have found the mother of all inconsitency warts when comparing
> the zipfile and tarfile modules. Not only are the API's different, but
> the entry and exits are differnet AND zipfile/tarfile do not behave
> like proper file objec
Excerpts from rantingrick's message of Fri Jul 22 02:40:51 -0400 2011:
> On Jul 22, 12:45am, Terry Reedy wrote:
> > On 7/22/2011 12:48 AM, rantingrick wrote:
> > > On Jul 21, 11:13 pm, Corey Richardson wrote:
>
> > Hmm. Archives are more like directories than files. Windows, at least,
> > seems t
On Jul 22, 12:45 am, Terry Reedy wrote:
> On 7/22/2011 12:48 AM, rantingrick wrote:
> > On Jul 21, 11:13 pm, Corey Richardson wrote:
> Hmm. Archives are more like directories than files. Windows, at least,
> seems to partly treat zipfiles as more or less as such.
Yes but a zipfile is just a fil
On Jul 22, 12:05 am, Corey Richardson wrote:
> > >>> from archive import ZipFile, TarFile
> > >>> zf = ZipFile(path, *args)
> > >>> tf = TarFile(path, *args)
>
> I have nothing to do this weekend, I might as well either write my own or
> twist around the existing implementations in the hg repo.
On Fri, 2011-07-22 at 01:45 -0400, Terry Reedy wrote:
> On 7/22/2011 12:48 AM, rantingrick wrote:
> > On Jul 21, 11:13 pm, Corey Richardson wrote:
> >> Excerpts from rantingrick's message of Thu Jul 21 23:46:05 -0400 2011:
> >>
> >>> I may have found the mother of all inconsitency warts when compa
On 7/22/2011 12:48 AM, rantingrick wrote:
On Jul 21, 11:13 pm, Corey Richardson wrote:
Excerpts from rantingrick's message of Thu Jul 21 23:46:05 -0400 2011:
I may have found the mother of all inconsitency warts when comparing
the zipfile and tarfile modules. Not only are the API's different,
Excerpts from rantingrick's message of Fri Jul 22 00:48:37 -0400 2011:
> On Jul 21, 11:13pm, Corey Richardson wrote:
> > I agree, actually.
>
>
> Maybe i can offer a solution. A NEW module called "archive.py" (could
> even be a package!) which exports both the zip and tar file classes.
> However
On Jul 21, 11:13 pm, Corey Richardson wrote:
> Excerpts from rantingrick's message of Thu Jul 21 23:46:05 -0400 2011:
>
> > I may have found the mother of all inconsitency warts when comparing
> > the zipfile and tarfile modules. Not only are the API's different, but
> > the entry and exits are di
Excerpts from rantingrick's message of Thu Jul 21 23:46:05 -0400 2011:
>
> I may have found the mother of all inconsitency warts when comparing
> the zipfile and tarfile modules. Not only are the API's different, but
> the entry and exits are differnet AND zipfile/tarfile do not behave
> like prop
I may have found the mother of all inconsitency warts when comparing
the zipfile and tarfile modules. Not only are the API's different, but
the entry and exits are differnet AND zipfile/tarfile do not behave
like proper file objects should.
>>> import zipfile, tarfile
>>> import os
>>> os.path.ex
I may have found the mother of all inconsitency warts when comparing
the zipfile and tarfile modules. Not only are the API's different, but
the entry and exits are differnet AND zipfile/tarfile do not behave
like proper file objects should.
>>> import zipfile, tarfile
>>> import os
>>> os.path.ex
I may have found the mother of all inconsitency warts when comparing
the zipfile and tarfile modules. Not only are the API's different, but
the entry and exits are differnet AND zipfile/tarfile do not behave
like proper file objects should.
>>> import zipfile, tarfile
>>> import os
>>> os.path.ex
23 matches
Mail list logo
