Re: [Python-Dev] GeneratorExit inheriting from Exception

On Sat, 2006-03-18 at 15:37 -0800, Brett Cannon wrote: > > Actually, this prompts me to write about an issue I have with PEP 352. > > I actually don't think it's necessary (yes, I know it's already in the > > tree). > > > > Much to personal pain and sprint time. Are you trying to make me shed >

Re: [Python-Dev] GeneratorExit inheriting from Exception

On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote: > Barry Warsaw wrote: > > > Exception > > +- KeyboardInterrupt > > +- GeneratorExit > > +- SystemExit > > +- StopIteration > > +- Error > > | +- ImportError > > | +- (etc.) > > | &g

Re: [Python-Dev] GeneratorExit inheriting from Exception

On Sun, 2006-03-19 at 17:31 +1000, Nick Coghlan wrote: > With PEP 352 (tweaked to move GeneratorExit out from under Exception): >- "except:" continues to mean catch everything >- "except Exception:" now does the right thing >- inheriting from Exception continues to be correct for user

Re: [Python-Dev] GeneratorExit inheriting from Exception

On Sun, 2006-03-19 at 19:18 -0800, Guido van Rossum wrote: > I have a problem with using Error as the focal point since so many > exceptions (user-defined or otherwise) aren't errors. I'm not sure that's totally true in practice. I think most user-defined exceptions are actually errors. Ideall

Re: [Python-Dev] GeneratorExit inheriting from Exception

On Mon, 2006-03-20 at 08:18 -0800, Aahz wrote: > -1 -- I occasionally use exceptions as a multi-loop break. That's a > perfectly valid Python practice, those exceptions should inherit from > Exception, and there should not be any warnings raised. Exactly! But they're not errors, so "except Exce

Re: [Python-Dev] GeneratorExit inheriting from Exception

On Mon, 2006-03-20 at 11:43 -0800, Michael Chermside wrote: > When you do, I'd like you to consider one change to the names. You are > proposing this: I'll keep this in mind, but won't comment further here for two reasons. I want to think about it some more (you throw, er raise some good points ;

Re: [Python-Dev] Python 3000 Process

On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > >Barry, if you could create that mailing list, please? > > And please mirror it on gmane the same way as this list is. Subscription requests have been made. -Barry signature.asc De

Re: [Python-Dev] Python 3000 Process

On Mon, 2006-03-20 at 20:06 -0800, Guido van Rossum wrote: > There's also a list for Python-3000-related checkins. Don't subscribe > to that one yet, it's very boring and uninteresting. Also, Barry > hasn't done the svn magic yet. :-) We're having a small problem on the svn box which requires Tho

[Python-Dev] svn checkins are now split

I believe I've figured out the magic to split checkin messages so that python/branches/p3yk goes to python-3000-checkins and everything else goes to python-checkins. Let me know if you notice any problems, and feel free to subscribe to whichever list(s) you're interested in. -Barry signature.a

Re: [Python-Dev] PySet API

Is it your intent to push for more use of the abstract API instead of the concrete APIs for all of Python's C data structures? Current API aside, are you advocating this approach for all new built-in types? Would you argue that Python 3.0's C API be stripped of everything but the abstract API and

Re: [Python-Dev] PySet API

On Tue, 2006-03-21 at 21:31 -0500, Raymond Hettinger wrote: > [Barry] > > Is it your intent to push for more use of the abstract API instead of > > the concrete APIs for all of Python's C data structures? Current API > > aside, are you advocating this approach for all new built-in types? > > Woul

Re: [Python-Dev] PySet API

On Tue, 2006-03-21 at 22:01 -0500, Raymond Hettinger wrote: > [Me] > > There is a semantic difference between > > code like s+=t and s.update(t). The former only works when t is a set > > and the latter works for any iterable. When the C code corresponds to > > the Python code, that knowledge is

Re: [Python-Dev] PySet API

On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote: > It was a trick question. Everyone is supposed to be attracted to the _next > version because it is shorter, faster, and takes less ref counting > management. > However, the _next version has a hard-to-find bug. The call to > PyObj

Re: [Python-Dev] PySet_Next (Was: PySet API)

On Sun, 2006-03-26 at 19:59 +0200, "Martin v. Löwis" wrote: > If it is similar to PyDict_Next, it will have PyObject** /input/ > variables, which are really meant as PyObject* /output/ variables. Yep, that's exactly what my posted patch does. > For the caller, a clear usage strategy follows from

Re: [Python-Dev] PySet_Next (Was: PySet API)

On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote: > We have a perfectly good way to iterate with PyIter_Next(). It may take a > couple of extra lines, but it is easy to get correct and has no surprises. > It > seems that the only issue is that Barry says that he refuses to use the

Re: [Python-Dev] PySet_Next (Was: PySet API)

On Sun, 2006-03-26 at 21:50 +0200, "Martin v. Löwis" wrote: > I don't know what specific application Barry has in mind, but I'm > sure he can get it right (although it might be an interesting experiment > to test that theory :-) In general, I would expect that people find > it easier to get code i

Re: [Python-Dev] PySet API

On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote: > Still, PyObject_Clear(s) would be better. Although not ideal, in the interest of compromise, I could support this option. There's a problem with this though: I don't think you want to be able to clear a frozen set. My PySet_Clear()

Re: [Python-Dev] PySet API

On Mon, 2006-03-27 at 10:20 -0500, Raymond Hettinger wrote: > Why don't we expose _PySet_Next() for Barry and leave it out of the public > API > for everyone else. Just so I understand exactly what you mean by "leave it out of the public API", let me ask: are you saying you don't want to documen

Re: [Python-Dev] PySet API

On Mon, 2006-03-27 at 23:21 +0200, "Martin v. Löwis" wrote: > Raymond Hettinger wrote: > > Why don't we expose _PySet_Next() for Barry and leave it out of the public > > API > > for everyone else. > > That is stupid. If Barry wants a "private" PySet_Next function, he can > just implement it hims

Re: [Python-Dev] improving quality

On Tue, 2006-03-28 at 18:00 +1100, Anthony Baxter wrote: > On Tuesday 28 March 2006 17:53, Neal Norwitz wrote: > > In order to do the best possible job and avoid silly errors, there > > shouldn't be any checkins which could change behaviour that do not > > include a test. I'm not talking about upd

Re: [Python-Dev] pysqlite for 2.5?

On Tue, 2006-03-28 at 17:59 +1100, Anthony Baxter wrote: > This came up before (back in October 2004!) but didn't go anywhere > since, AFAICR. Do we want to consider including pysqlite in Python > 2.5? It's the only DB adaptor that I'd really consider suitable for > shipping with the distributio

Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch

On Tue, 2006-03-28 at 10:13 +0200, Giovanni Bajo wrote: > Another option would be Bugzilla, which is proven to be stable, maintained > and used succesfully by large open source projects (like > GCC+RedHat+Binutils+Classpath). The infrastructure committee (of which I'm a member but not the chair)

Re: [Python-Dev] PySet API

On Tue, 2006-03-28 at 17:28 +1200, Greg Ewing wrote: > Barry Warsaw wrote: > > My PySet_Clear() raises a SystemError > > and returns -1 when the object is a frozen set. > > Isn't SystemError a bit drastic? TypeError would be > sufficient here, surely. Possi

Re: [Python-Dev] PySet API

On Mon, 2006-03-27 at 23:53 -0800, Raymond Hettinger wrote: > While I don't favor the proposed API, I think is essential that > you not be left hanging without good options. Thank you. So where does this leave us? BTW, Guido made a suggestion in private email (which he okayed to mention publicl

Re: [Python-Dev] PySet API

Excerpting... On Tue, 2006-03-28 at 14:07 +, Gareth McCaughan wrote: > * Simple API: > > API complexity is measured in brain cells, not in methods. > > * Ease of making mistakes: > > The Python API is absolutely stuffed with places where you can go wrong > by forgetting about subtle refcou

Re: [Python-Dev] pysqlite for 2.5?

On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote: > I'm happy to work with Gerhard to make this happen. Does it need a > PEP? I'd say "no", Agreed. pysqlite is solid and widely accepted, and AFAIK has no competition. > but only because things like ElementTree didn't, > either. Does it

Re: [Python-Dev] pysqlite for 2.5?

On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote: > On the plus side, it sounds like ASPW is a more general wrapping of SQLite, > which seems to me to lean in its favor for the stdlib, if it can also be > brought into DBAPI compliance. If there's some general uncertainty about which to a

Re: [Python-Dev] Class decorators

On Wed, 2006-03-29 at 00:01 -0500, Phillip J. Eby wrote: > For some reason, this doesn't bother me with functions. But then, I can't > remember how often I've actually needed to use two decorators on the same > function, or how many times a function decorator's arguments took multiple > lines

Re: [Python-Dev] pysqlite for 2.5?

On Wed, 2006-03-29 at 09:35 +0200, Gerhard Häring wrote: > In particular, I would then synchronize changes that have proven stable > in the standalone release to the Python core sqlite module. I think this > is how Barry does it with the email module, too. I do things a little differently, at l

Re: [Python-Dev] pysqlite for 2.5?

On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote: > My only concern about this is that it wouldn't be possible for other > authors to provide 3rd party packages as (for instance) db.mysqldb > because of the way package importing works. And I'd prefer > 'database.sqlite' rather than 'db.sq

Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch

On Wed, 2006-03-29 at 17:52 +0200, Fredrik Lundh wrote: > if this works well for Python 3000, the next step would be to ask them > if they're willing to host the 2.X tracker as well (and optionally the SVN > archive, as well). PSF might not be the Mozilla Foundation, but I'm sure > there's enough

Re: [Python-Dev] PySet API

On Tue, 2006-03-28 at 22:20 -0800, Raymond Hettinger wrote: > Barry, go ahead with PySet_Clear(). Cool thanks. I think we've also compromised on _PySet_Next(), correct? I'll follow up on PySet_Update() in a moment. -Barry signature.asc Description: This is a digitally signed message part

Re: [Python-Dev] PySet API

On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote: > The story is different for PySet_Update(). Defining it now could get in the > way > of possible future development for the module (the function may end-up taking > a > variable length argument list instead of a single argument). S

Re: [Python-Dev] PySet API

On Wed, 2006-03-29 at 19:34 -0500, Barry Warsaw wrote: > On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote: > > > The story is different for PySet_Update(). Defining it now could get in > > the way > > of possible future development for the module (the functio

Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch

On Wed, 2006-03-29 at 23:33 -0800, Neal Norwitz wrote: > I'm in favor of having Atlassian setup a system to be used for 3k. It > would be completely experimental and could be completely thrown away > which should be made clear to Atlassian if we were to do this. I > would use the system for eval

Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch

On Thu, 2006-03-30 at 09:55 +0200, Fredrik Lundh wrote: > so what's the advantage of a freely hosted Atlassian setup compared > to a freely hosted Trac setup ? Dunno. I'm sure both will accomplish the job and both will be better than the current situation. I've used Jira and Confluence for almo

Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch

On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote: > Perhaps that Jira is commercial, so it is out of the question for most > open-source Python applications. Sorry, I don't follow. Why is a commercial product out of the question for Python? -Barry signature.asc Description: This is a di

Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch

On Thu, 2006-03-30 at 16:20 +0200, Georg Brandl wrote: > I'm not saying it's out of the question for Python, I'm saying that it's > out of the question for most open-source projects, which don't have the > money or don't want to spend the money on a mere bug tracker, and that > this may be the rea

Re: [Python-Dev] PySet API

On Wed, 2006-03-29 at 23:09 -0500, Raymond Hettinger wrote: > Yes, _PySet_Next() is a good compromise for you and me -- it saves you from > writing a hack and saves my API from including a bug factory. The only issue > is > that Martin thinks it to be a crummy idea. Personally, I have no prob

Re: [Python-Dev] PySet API

On Thu, 2006-03-30 at 13:09 -0500, Raymond Hettinger wrote: > Please leave this one alone. I still need to work on this part of the API > and > do not currently have the spare clock cycles to do it right now. You don't > HAVE > to jam something in right away. Please let it continue to cook

Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared

On Fri, 2006-03-31 at 15:13 -0500, Terry Reedy wrote: > For about a week, I have been reading and occasionally posting to the new > pydev-3000 mailing list via the gmane mirror gmane.comp.lang.devel.3000. > Today, it has disappeared and was still gone after reloading their > newsgroup list. Was

Re: [Python-Dev] posixmodule.c patch- revision 43586

Tim Peters wrote: > > While we're at it, looks like all the 2.4 buildbots are failing > test_email today. > ___ > Anthony backported the patch that should fix this, so it should be showing up in 2.4 buildbots soon. -Barry

Re: [Python-Dev] The "i" string-prefix: I18n'ed strings

On Thu, 2006-04-06 at 11:48 -0400, Martin Blais wrote: > - This implies that we would have to introduce some way for these > strings to call a custom function at runtime. Yes, definitely. For example, in Mailman we bind _() not to gettext's _() but to a special one that looks up the translation

Re: [Python-Dev] The "i" string-prefix: I18n'ed strings

On Fri, 2006-04-07 at 13:29 +0200, Alexander Schremmer wrote: > Have you thought about simply writing _ = lambda x:x instead of N_ ...? > By doing that, you just need to care about one function (of course _ > doesn't translate in that case and you might need to del _ afterwards). That's essential

Re: [Python-Dev] The "i" string-prefix: I18n'ed strings

On Sat, 2006-04-08 at 00:45 +0200, "Martin v. Löwis" wrote: > *Never* try to do i18n that way. Don't combine fragments through > concatenation. Instead, always use placeholders. Martin is of course absolutely right! > If you have many fragments, the translator gets the challenge of > translating

Re: [Python-Dev] need info for externally maintained modules PEP

On Sat, 2006-04-08 at 14:47 -0700, Brett Cannon wrote: > - email This has an standalone release, but development and bug reports should all happen in the Python project. -Barry signature.asc Description: This is a digitally signed message part ___ P

Re: [Python-Dev] Raising objections (was: setuptools in the stdlib)

On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote: > I'm not sure how people would prefer this be handled. I don't think we > need to have a PEP for it - I don't see PEPs for ctypes, elementtree, > pysqlite or cProfile, either. Agreed. If modules like these have a solid history of use ou

Re: [Python-Dev] Raising objections (was: setuptools in the stdlib)

On Wed, 2006-04-19 at 02:06 -0400, Phillip J. Eby wrote: > > > >I agree. My one stupid nit is that I don't like the name > >'easy_install'. I wish a better, non-underscored word could be found. > > The long term plan is for a tool called "nest" to be offered, which will > offer a command-line i

Re: [Python-Dev] Raising objections (was: setuptools in the stdlib)

On Wed, 2006-04-19 at 18:26 +1200, Greg Ewing wrote: > I'd like to see a different approach taken to the design > altogether, something more along the lines of Scons. > Maybe it could even be an extension of Scons. As much as I like Scons, there's too much unpythonic magic going on there that I w

Re: [Python-Dev] Raising objections

On Thu, 2006-04-20 at 07:53 +0200, "Martin v. Löwis" wrote: > > Sometimes you _have_ to rewrite. I point to > > urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email. > > If I had the time, I would question each of these. Yes, it is > easier for the author of the new package to build "in

Re: [Python-Dev] Raising objections

On Thu, 2006-04-20 at 11:33 +0100, Guido van Rossum wrote: > Unfortunately, this is mixed in with some stuff that isn't part of > distutils' "core competency", like text utilities, process spawning, > and option parsing. These should (eventually, when the 2.1 > compatibility requirement is lifted)

Re: [Python-Dev] setuptools in 2.5.

On Thu, 2006-04-20 at 23:53 +0200, M.-A. Lemburg wrote: > There's really nothing wrong with the standard distutils > two step process: > > 1. download and unzip the source file > > 2. run "python setup.py install" The only thing I'll add (other than put me in the "just make it work and tell me

Re: [Python-Dev] setuptools in 2.5.

On Thu, 2006-04-20 at 19:43 -0400, Phillip J. Eby wrote: > >I may be way out of date with the state of the art these days, but in > >the past, I've had a difficult time making this work for Mailman. For > >example, at various times we've had to distribute our own email package > >and Asian codecs

Re: [Python-Dev] setuptools in 2.5.

Thanks for all the great information Phillip. On Thu, 2006-04-20 at 23:33 -0400, Phillip J. Eby wrote: > Anyway, that's a complete digression from the question you asked. As long > as Mailman doesn't depend on building something like Numeric or Twisted, > you can probably wrap it in easy_insta

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

On Wed, 2006-04-26 at 10:16 -0700, Guido van Rossum wrote: > So I have a very simple proposal: keep the __init__.py requirement for > top-level pacakages, but drop it for subpackages. This should be a > small change. I'm hesitant to propose *anything* new for Python 2.5, > so I'm proposing it for

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

Boy, threads here sure move fast when there's work to be done :). Although largely moot now, I'll follow up for posterity's sake. On Wed, 2006-04-26 at 10:59 -0700, Guido van Rossum wrote: > Oh, cool gray area. I propose that if there's no __init__.py it prints > '/sub1/sun2/' i.e. with a trailin

Re: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 03:36, "Martin v. Löwis" wrote: > I mostly agree with Fredrik. What good does removal of xmllib do? > It's not that it is causing any maintenance burden, so we could just > leave it in. Whether this means that we keep xmllib until P3k, I > don't know. > > As for PEP 4: I don

RE: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 05:40, Raymond Hettinger wrote: > * The number one current python complaint is the state of the standard > library: http://www.internetnews.com/dev-news/article.php/3441931 . > Some of this may just be the fruits of AMK's highly publicized journal > entry; however, I think t

Re: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 18:49, Brett C. wrote: > And as for the mention of dropping PEP 4, I agree with the running consensus > that it isn't needed thanks to the warning module. Do we need to have a more > formal vote to drop PEP 4, or should one the PEP maintainers just delete it? There's real

RE: [Python-Dev] Deprecated xmllib module

On Mon, 2004-12-06 at 07:44, Raymond Hettinger wrote: > We are trying to remove clutter, not keep it in perpetuity. Leaving the > docs means continuing to have to test it, field bug reports, be aware of > its existence, etc. > > Do not keep this on a respirator. Let it die in peace. Old docume

Re: [Python-Dev] Rewriting PEP4

On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote: Martin, +1 on everything you wrote, with one minor quibble. > Removal > === > If the module has been deprecated for atleast a year and atleast > a version, it can be removed. Removal should move it to old-libs > for pure Python modules; a

RE: [Python-Dev] Rewriting PEP4

On Tue, 2004-12-07 at 03:12, Raymond Hettinger wrote: > I'm concerned about the old email modules. They haven't been deprecated > and may stay around for a good while. However, some SF requests have > been passed over on the basis that the modules are supplanted and will > be phased out. I don'

Freezing Python (was Re: [Python-Dev] 2.4 news reaches interesting places)

On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote: > ISTR that for a long time, Visual Basic actually did the same thing. A few > magazines mentioned the fact, but nobody really cared. However, if this is > really a concern, bundle Pyrex as well. Both Pyrex and py2exe are > distutils-based,

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places

On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote: > For those who believe that a non-profit project should not do any > marketing, a reminder. If the perception about Python is one of a slow > language, it's much more difficult to find places where you can use > Python. In the long run, many of u

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places

On Wed, 2004-12-15 at 07:32, Nick Coghlan wrote: > about.python.org? > > And if someone ends up playing with the DNS server, maybe they could add > wiki.python.org while they're at it :) DNS changes have to go through pydotorg at python.org, since Thomas is the person currently able to add host

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Pythonmarshal.c, 1.79, 1.80

On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote: > Perhaps a rather quick Py2.4.1 would be in order. +1 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.o

RE: [Python-Dev] Please help complete the AST branch

On Mon, 2005-01-03 at 23:17, Tony Meyer wrote: > > Perhaps interested parties should take up the discussion on > > the compiler-sig. > > This isn't listed in the 'currently active' SIGs list on > - is it still active, or will it now be? If so, > perhaps it should be add

Re: [Python-Dev] Please help complete the AST branch

On Tue, 2005-01-04 at 11:17, Jeremy Hylton wrote: > That's fine with me. We had taken it to the compiler-sig when it > wasn't clear there was interest in the ast branch :-). Ok, then I'll leave compiler-sig where it is. -Barry signature.asc Description: This is a digitally signed message part

Re: [Python-Dev] Let's get rid of unbound methods

On Tue, 2005-01-04 at 18:01, Jack Jansen wrote: > But I'm more worried about losing the other information in an unbound > method, specifically im_class. I would guess that info is useful to > class browsers and such, or are there other ways to get at that? That would be my worry too. OTOH, we

Re: [Python-Dev] Let's get rid of unbound methods

On Wed, 2005-01-05 at 10:37, Glyph Lefkowitz wrote: > One approach I have taken in order to avoid copiously over-documenting > every super() using class is to decouple different phases of > initialization by making __init__ as simple as possible (setting a few > attributes, resisting the temptatio

Re: [Python-Dev] Let's get rid of unbound methods

On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote: > I think it would be reasonable to assign im_class only to functions > defined in class scope. The only serialization that would break in that > case is if your example had a 'del f' at the end. +1. If you're doing something funkier, then you

RE: [Python-Dev] Re: Subscribing to PEP updates

On Thu, 2005-01-06 at 11:33, Chermside, Michael wrote: > > Why not just subscribe to > > python-checkins and filter out everything *but* nondist/peps? > > But there are lots of people who might be interested in > following PEP updates but not other checkins. Pretty > much anyone who considers them

Re: [Python-Dev] Re: Subscribing to PEP updates

On Fri, 2005-01-07 at 10:05, Nick Coghlan wrote: > Barry Warsaw wrote: > > As an experiment, I just added a PEP topic to the python-checkins > > mailing list. You could subscribe to this list and just select the PEP > > topic (which matches the regex "PEP" in

RE: [Python-Dev] Re: Subscribing to PEP updates

On Mon, 2005-01-10 at 09:40, Michael Chermside wrote: > Barry writes: > > As an experiment, I just added a PEP topic to the python-checkins > > mailing list. You could subscribe to this list and just select the PEP > > topic (which matches the regex "PEP" in the Subject header or first few > > lin

RE: [Python-Dev] logging class submission

On Tue, 2005-01-11 at 12:58, Batista, Facundo wrote: > [Stephan Stapel] > > #- > There's a license issue here? > #- > #- I was given the advise to use this license. If this license > #- prohibts inclusion into Python, how should I re-license the code? > > I just was asking. Who gave you the ad

Re: [Python-Dev] redux: fractional seconds in strptime

On Fri, 2005-01-14 at 06:40, Alex Martelli wrote: > +1 -- I never liked the idea that 'time tuples' lost fractions of a > second. On platforms where that's sensible and not too hard, > time.time() could also -- unobtrusively and backwards compatibly -- set > that same attribute. I wonder if,

Re: [Python-Dev] Getting rid of unbound methods: patch available

On Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote: > If you want to make methods look more like functions, > the method object should become a subclass of the function > object (function + added im_* attributes). I have no personal use cases, but it does make me vaguely uncomfortable to lose im_cl

Re: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Mon, 2005-01-31 at 00:17, Guido van Rossum wrote: > > I had hoped for the core of p3k to be built for scratch [...] > > Stop right there. Phew! -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list P

RE: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Mon, 2005-01-31 at 00:00, Skip Montanaro wrote: > Raymond> I had hoped for the core of p3k to be built for scratch ... > > Then we should just create a new CVS module for it (or go whole hog and try > a new revision control system altogether - svn, darcs, arch, whatever). I've heard rumors

Re: [Python-Dev] Re: python/dist/src/Lib rfc822.py,1.78,1.79

On Tue, 2005-02-08 at 10:35, Guido van Rossum wrote: > This would have been caught if there was a unit test validating what > the documentation says. Why aren't there unit tests for this code? I > think we need to raise the bar for "wholistic" improvements to a > module: first write a unit test if

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Sat, 2005-02-12 at 08:37, A.M. Kuchling wrote: > The md5 module has been a standard module for a long time; making it > optional in the next version of Python isn't possible. We'd have to > require OpenSSL to compile Python. I totally agree. -Barry signature.asc Description: This is a dig

Re: [Python-Dev] UserString

On Mon, 2005-02-21 at 11:15, Guido van Rossum wrote: > Right. There are plenty of examples where LBYL is better, e.g. because > there are too many different exceptions to catch, or they occur in too > many places. One of my favorites is creating a directory if it doesn't > already exist; I always

Re: [Python-Dev] UserString

On Tue, 2005-02-22 at 11:16, Guido van Rossum wrote: > > Really? I do this kind of thing all the time: > > > > import os > > import errno > > try: > > os.makedirs(dn) > > except OSError, e: > > if e.errno <> errno.EEXIST: > > raise > > You have a lot more faith in the errno modul

Re: [Python-Dev] UserString

On Tue, 2005-02-22 at 19:14, Andrew McNamara wrote: > >> if e.errno <> errno.EEXIST: > >> raise > > > >You have a lot more faith in the errno module than I do. Are you sure > >the same error codes work on all platforms where Python works? It's > >also not exactly readable (except for ol

Re: [Python-Dev] Migrating to subversion

On Sun, 2005-03-06 at 14:16, "Martin v. Löwis" wrote: > I don't know whether anybody has done this before, > but I just tried to run cvs2svn on the Python repository. > The conversion took 7 hours, and the result is now > available at > > http://www.dcl.hpi.uni-potsdam.de/python/branches/ > > Bec

Re: [Python-Dev] rationale for the no-new-features approach

On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote: > So it's only fair that I write down my rationale for why I'm being anal > about the no-new-features approach. Comments are more than welcome - > ideally, after discussion, I'll put some more words in the bugfix PEP. I applaud your strictness Ant

Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents

On Wed, 2005-03-09 at 19:39, Tommy Burnette wrote: > I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict > implementation for the last 5-6 years in which insertion order is the > only order respected. I use it all over the place (in a code base of > ~60k lines of python code). > >

RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents

On Thu, 2005-03-10 at 01:29, Raymond Hettinger wrote: > Or the implementation can have a switch to choose between keep-first > logic or replace logic. This is what I meant by my previous follow up: while the concept of "an ordered dictionary" is nice and seemingly generic enough, in practice I su

Re: [Python-Dev] rationale for the no-new-features approach

On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote: > That way instead of multi-line "except NameError" tests all over the > place you can simply have one-liner boilerplate for every module in your > project: > > 'from py24compat import *' > > Easy to grep/sed for when you're ready to st

Re: [Python-Dev] Adding any() and all()

On Fri, 2005-03-11 at 06:43, Peter Astrand wrote: > Even though you can use them as variables (and shadow the builtins), you > will still get warnings from "pychecker". The code will also be harder to > read: When you see "all" in the middle of some code, you don't know if > it's referring to the

RE: [Python-Dev] Adding any() and all()

On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote: > I suspect that lambda will be the only bone of contention. The reduce() > function can be moved to the functional module. The map() and filter() > functions are already covered by the itertools module. I'm fine seeing reduce() eventually g

Re: [Python-Dev] Adding any() and all()

On Fri, 2005-03-11 at 12:40, M.-A. Lemburg wrote: > While I'm no fan of lambdas either, the removal would break too > much code (e.g. I have 407 hits in the code base I use regularly > alone). We /are/ talking Python 3000 here, right? I'm expecting all manner of code breakage in moving from Pyth

Re: [Python-Dev] Adding any() and all()

On Fri, 2005-03-11 at 14:29, Jim Jewett wrote: > Is that so bad? > > If you plan to use them often, then > > from itertools import any, every +1 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing l

Re: [Python-Dev] Faster Set.discard() method?

On Fri, 2005-03-18 at 01:19, Andrew McNamara wrote: > No, exceptions are fast at the C level - all they do is set a flag. The > expense of exceptions is saving a restoring python frames, I think, > which doesn't happen in this case. So the current implementation is > ideal for C code - clear and f

Re: [Python-Dev] using SCons to build Python

On Sun, 2005-03-27 at 20:55, Adam MacBeth wrote: > Has anyone ever considered using SCons to build Python? SCons is a > great build tool written in Python that provides some Autoconf-like > functionality (http://www.scons.org). It seems like this type of > self-hosting would be a great testament to

Re: [Python-Dev] Developer list update

On Tue, 2005-04-05 at 19:06, Fred Drake wrote: > Would anyone here object to renaming the file to developers.txt, though? +1, please! -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@pyt

RE: [Python-Dev] Developer list update

On Thu, 2005-04-07 at 10:58, Raymond Hettinger wrote: > Ben Gertzfield Ben did a lot of work on the i18n parts of the email package. I haven't heard from him in quite a while. > Ken Manheimer Ken's still around. I'll send you his current email address in a separate (pvt) message. -Barry

Re: [Python-Dev] Unified or context diffs?

On Wed, 2005-04-13 at 15:54, Brett C. wrote: > I thought at one point this question came up and the general consensus was > that > unified diffs were preferred? Back in the day, we preferred context diffs, and I think of the original Python core group, Guido was the last holdout. But IIRC, a fe

[Python-Dev] Inconsistent exception for read-only properties?

I've noticed an apparent inconsistency in the exception thrown for read-only properties for C extension types vs. Python new-style classes. I'm wondering if this is intentional, a bug, a bug worth fixing, or whether I'm just missing something. class other(object): def __init__(self, value):

Re: [Python-Dev] Inconsistent exception for read-only properties?

On Thu, 2005-04-14 at 23:46, Barry Warsaw wrote: > I've noticed an apparent inconsistency in the exception thrown for > read-only properties for C extension types vs. Python new-style > classes. I haven't seen any follow ups on this, so I've gone ahead and posted a patch,

<    1   2   3   4   5   6   7   8   9   10   >