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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 31 May 2006 07:02:02 -0400
"Martin Blais" <[EMAIL PROTECTED]> wrote:
> I'd like to know what the policy is on the source code indentation for
> C code in the interpreter. At the Need-for-Speed sprints, there was
> consensus that there is a "n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 9 Jun 2006 09:54:29 -0700
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> Do enough people use Google Calendar or a calendar app that support
> iCal feeds that it would be useful for someone to maintain a Gcal
> calendar that has the various Pytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Jun 2006 13:08:52 -0400
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> While I won't claim to speak for the other authors, I would guess
> that they have the same reason for wanting that status as I do: to be
> able to maintain an external r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Jun 2006 15:12:20 -0400
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> Now, Barry's approach to the email package makes good sense to me,
> and I'd use it, except that SVN externals can't sync individual
> files. I'd have to create Lib/wsgi
On Jun 12, 2006, at 8:42 PM, Steve Holden wrote:
> Phillip J. Eby wrote:
> [...]
>> So, to summarize, it's all actually Tim's fault, but only in a
>> parallel
>> universe where nobody believes in unit testing. ;-)
>>
> I'm sorry to contradict you, but every issue of significance is
> already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
PCTotD (pre-coffee thought of the day):
On Jul 5, 2006, at 6:17 AM, Marek "Baczek" Baczyński wrote:
> 2006/7/5, Just van Rossum <[EMAIL PROTECTED]>:
>> Guido van Rossum wrote:
>>
>>> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
Did you a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 9:39 AM, [EMAIL PROTECTED] wrote:
>
> Barry> Clearly we need the "as if in" operator:
>
> Why not be more direct?
Sure, why not? :)
Then we can reserve the "as if" operator for those things that Guido
has rejected, but that
I've been looking at the API for sets.Set and built-in set objects in
Python 2.4.1 and I think I have found some minor inconsistencies.
Background: we have an object that is very similar to "sets" and we
originally modeled the API after sets.Set since we started with Python
2.3. Now I'm trying to
On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote:
> > If there are no objections, I propose to do the following (only in
> > Python 2.4 and 2.5):
> >
> > * Add set.union_update() as an alias for set.update().
>
> No. It was intentional to drop the duplicate method with the
> hard-to-u
+1 on @contextmanager
On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
> > __enter__(self):
> > __exit__(self, exc_type, exc_value, exc_traceback):
>
> These names should be changed to __beginwith__ and __endwith__.
-0. My fingers are too hardwired to writing "endswith", as in
On Thu, 2005-07-07 at 14:54, Guido van Rossum wrote:
> How would a PEP to *remove* this feature fare today?
Not well, I hope, although I suppose everything's up for debate in Py3K.
Yes, they're rarely used and there is an alternative, but I do find them
useful and succinct when they're needed.
On Thu, 2005-07-07 at 16:30, Brett Cannon wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem. He also hopes to make pstats
> faster to use. And if we are really l
On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:
> I compiled a list of some possible new context managers that could be
> added to the stdlib.
I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
purpose
On Mon, 2005-07-11 at 01:08, Bob Ippolito wrote:
> A better proposal would probably be another string prefix that means
> "dedent", but I'm still not sold. doc processing software is clearly
> going to have to know how to dedent anyway in order to support
> existing code.
OTOH, adding anot
On Mon, 2005-07-25 at 16:37, Edward C. Jones wrote:
> Is there a C API for the built-in type set? if not, why not?
Sadly, no. Because no one's written it yet...?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-De
On Thu, 2005-07-28 at 16:00, "Martin v. Löwis" wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS
+1
> , and on python.org instead of sf.net.
+0
I know that SF has promised svn access to projects for a long time now,
but I haven't heard anything from them in a
On Thu, 2005-07-28 at 16:20, Guido van Rossum wrote:
> I hope we're correctly estimating the effort required to manage the
> server and the users.
Yah, me too! ;)
We are building some experience with this though, having moved many of
the system files, and all of the web pages, to svn. So far,
On Thu, 2005-07-28 at 17:58, James Y Knight wrote:
> If you use the fsfs storage mechanism for subversion, it is somewhat
> simpler to verify that the repository is not compromised. Each commit
> is represented as a separate file, and thus old commits are never
> modified. Only new files are
On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:
> I'm definitely positive to a migration to Subversion, but I'd be really
> concerned about using plain text authentication mechanisms.
We won't use plain text, but we may (or, we currently do) use basic auth
over ssl. The security then is in t
On Thu, 2005-07-28 at 22:14, Tim Peters wrote:
> Ah, before I forget, "single repository" has worked very well for Zope
> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
> projects):
>
> http://svn.zope.org/
>
> Long URLs don't really get in the way in practice (rarely a
On Thu, 2005-07-28 at 22:59, Tim Peters wrote:
> Yup, me too -- between the two of us, we don't have enough fingers to
> count how many trunks, branches, and tags of ZODB and Zope I have to
> fiddle with.
I have a small inkling of your pain.
> They're all still copy, paste, tail-edit for me, and
On Fri, 2005-07-29 at 01:00, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > We won't use plain text, but we may (or, we currently do) use basic auth
> > over ssl. The security then is in the passwords, so we have to make
> > sure they're generated secu
On Fri, 2005-07-29 at 00:44, "Martin v. Löwis" wrote:
> - assignment of passwords. This I don't like about the current
> pydotorg setup - there should be a way to chose your own password;
> perhaps without involving an administrator.
> I could imagine a web form for password change, and admi
On Fri, 2005-07-29 at 17:19, "Martin v. Löwis" wrote:
> I believe this alone either won't work or won't be good enough (not
> sure which one): If you have /bin/false as login shell, and still
> manage to invoke /usr/bin/svnserve remotely, you can likely also
> invoke /usr/bin/cat /etc/passwd remot
On Fri, 2005-07-29 at 00:35, "Martin v. Löwis" wrote:
> It's also a convenience issue, and has social aspects. For example,
> firstname.lastname does not work quite well for me, either
> (martin.v.loewis or martin.von.loewis would work better; likewise
> guido.van.rossum?), other users prefer not
On Fri, 2005-07-29 at 17:32, "Martin v. Löwis" wrote:
> > Was this with the file-system back end? What is your current system?
>
> Yes, and it is a 3 GHz dual processor (although I don't think it uses
> two processors) with 1GB RAM (I believe RAM size matters a lot for
> this process; the older
On Fri, 2005-07-29 at 00:50, Christopher Petrilli wrote:
> Another thing to look at would be Trac, which we are in the process of
> moving to from the horrendous nightmare of Bugzilla. It's integration
> with SVN as well as Wiki is quite amazing.
Now's the time I pipe in to remind everyone that
On Fri, 2005-07-29 at 17:21, "Martin v. Löwis" wrote:
> Doesn't this give issues as *every* file the starts out renamed? e.g.
> what if you want "revision 100 of project/trunk/foo", but, at revision
> 100, it really was trunk/project/foo?
I think it only matters if you use urls. I working direct
On Fri, 2005-07-29 at 16:59, "Martin v. Löwis" wrote:
> Perhaps. Somebody would need to research the precise migration
> procedure. I once tried to move the Python CVS to Sunsite
> (or its successors), and gave up after half a year of getting
> nowhere; I'm personally not keen on repeating such an
On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
> Barry Warsaw wrote:
>
> >Public/private keys would be better, and if anybody knows how to set up
> >a Subversion server to use these without having to create accounts for
> >everyone, I think we (the pythong.org admi
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote:
> I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system. I
> know I'm not the only person with this experience. Sure, you can keep
> backups, and not really lose any work, bu
On Mon, 2005-08-08 at 19:29, Tim Peters wrote:
> > Currently with svn you have to manually specify those 9 to be sure to not
> > include the remaining one. With p4 you just say to check-in the whole tree
> > and then remove that one from the list give you in your editor with entering
> > the check
On Thu, 2005-08-11 at 20:51, Anthony Baxter wrote:
> So I'm currently planning for a 2.4.2 sometime around mid September. I figure
> we cut a release candidate either on the 7th or 14th, and a final a week
> later.
Cool. I'd like to commit the patches in this bug report:
https://sourceforge.n
On Tue, 2005-08-16 at 07:42, Michael Hudson wrote:
> The third set of people who count are pydotorg admins. I'm not really
> one of those either at the moment. While SF's CVS setup has it's
> problems (occasional outages; it's only CVS) it's hard to beat what it
> costs us in sysadmin time: zero
On Tue, 2005-08-16 at 15:18, Neil Schemenauer wrote:
> Another option would be to pay someone to maintain the SVN setup on
> python.org. Unfortunately, I guess that would require someone else
> to first create a detailed description of the maintenance work
> required and to process bids.
Again,
On Wed, 2005-08-17 at 12:37, Jeremy Hylton wrote:
> I'd like to see the builtin id() removed so that I can use it as a
> local variable name without clashing with the builtin name. I
> certainly use the id() function, but not as often as I have a local
> variable I'd like to name id.
Same here.
On Wed, 2005-08-17 at 18:57, Calvin Austin wrote:
> When was the last time someone thanked you for writing a test? I tried
> to think of the last time it happened to me and I can't remember. Well
> at Spikesource we want to thank you not just for helping the Python
> community but for your test
On Sun, 2005-08-21 at 09:12, "Martin v. Löwis" wrote:
> It turns out that svn+ssh with a single account has limitations:
> you can only set the tunnel user when you are using a restricted
> key. In PEP 347, the plan is that the current SF project admins
> get shell access to the pythondev account,
On Mon, 2005-08-22 at 11:18, [EMAIL PROTECTED] wrote:
> I'm completely confused about what, if anything, I need to send to you. I
> can already access the python.org website repository via svn. Will I
> automatically get access to the new Python source repository or do I need to
> send you pub k
On Mon, 2005-08-22 at 12:16, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > I think technically, the answer to that is "yes", you will automatically
> > get access to the source repo.
>
> At the moment, the answer actually is "no". For
On Tue, 2005-08-23 at 11:51, Fredrik Lundh wrote:
> Gareth McCaughan wrote:
>
> > It's valid C99, meaning "this is an unsigned long long".
>
> since when does Python require C99 compilers?
Why, since Python 3.0 of course!
-Barry
signature.asc
Description: This is a digitally signed message
On Wed, 2005-08-24 at 10:34, James Y Knight wrote:
> I would rather see "except:" be deprecated eventually, and force the
> user to say either except Exception, except BaseException, or even
> better, except ActualExceptionIWantToCatch.
I agree about bare except, but there is a very valid use
On Wed, 2005-08-24 at 12:38, "Martin v. Löwis" wrote:
> I personally dislike recording the execution path in
> local variables. This is like setting a flag in a loop
> before the break, and testing the flag afterwards.
> You can do this, but the else: clause of the loop is
> just more readable.
A
On Wed, 2005-08-24 at 15:15, Raymond Hettinger wrote:
> Hmm, that may not be a killer. I wonder if it is possible to treat
> BaseException as a constant (like we do with None) and teach the
> compiler to interpret it as catching anything that gets raised so that
> "except BaseException" will work
On Wed, 2005-08-24 at 22:33, A.M. Kuchling wrote:
> So, it's time to start considering it for inclusion in the standard
> library. This is a big change to a non-obscure module, so don't feel
> able to make this decision on my own.
>
> I believe the code quality is acceptable, but would appreciat
On Tue, 2005-08-30 at 11:27, Phillip J. Eby wrote:
> >So if partition() [or whatever it'll be called] could have an optional
> >second argument that defines the width of the 'cut' made, I would be
> >helped enormously. The default for this second argument would be
> >len(sep), to preserve the curr
On Tue, 2005-08-30 at 12:39, Michael Chermside wrote:
> Michael Hoffman writes:
> > Dare I ask whether the uncompiled versions [of re object methods] should
> > be considered for removal in Python 3.0?
> No flames here, but I'd rather leave them. The docs make it clear that
> the two sets of funct
On Tue, 2005-08-30 at 14:53, Fredrik Lundh wrote:
> Some kind of symmetry with get, probably. if
>
> d.get(x)
>
> returns None if x doesn't exist, it makes some kind of sense that
>
> d.setdefault(x)
I think that's right, and IIRC the specific detail about the optional
second argument
On Tue, 2005-08-30 at 16:46, Fredrik Lundh wrote:
> But I stumbled upon this little naming protocol
>
> Protocol: if you have a suggestion for a name for this function, mail
> it to me. DON'T MAIL THE LIST. (If you mail it to the list, that
> name is disqualified.) Don't explain me
On Thu, 2005-09-01 at 05:54, Nick Coghlan wrote:
> Oren Tirosh wrote:
> > * Replacing print with write/writeln
>
> I still hope to see this change to "make print a builtin instead of a
> statement". I'd hate to lose the one-line hello world example due to cruft
> like "from sys import stdout".
I
On Thu, 2005-09-01 at 10:58, Guido van Rossum wrote:
> [Reinhold Birkenfeld]
> > You'd have to enclose print arguments in parentheses. Of course, the
> > "trailing
> > comma" form would be lost.
>
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it
On Thu, 2005-09-01 at 17:49, Bob Ippolito wrote:
> That is absolutely true, print is becoming less and less useful in
> the context of GUI or web applications.
I know we're dinosaurs, but some of us still write console apps in
Python!
> Even in Just Debugging
> scenarios, you're probably b
On Thu, 2005-09-01 at 16:07, Guido van Rossum wrote:
> Another real problem with print is that, while the automatic insertion
> of spaces is nice for beginners, it often gets in the way,
OTOH, print's automatic space insertion is often the reason why I'll
reach for it instead of stream.write().
On Fri, 2005-09-02 at 00:40, Martin Blais wrote:
> Talking about cleanliness, I'm not sure which is cleaner::
>
> print >> sys.stderr, "This is a long sentence that I " \
> "had to cut in two."
>
> print("This is a long sentence that I "
> "had to cut in two.", stream=sys.std
On Fri, 2005-09-02 at 03:18, Paul F. Dubois wrote:
> Remove the print statementI laughed until my sides hurt. Hello? Try
> dating girls and talking to normal people, geek boys.
>
> We scientists still use these for debugging. We never 'move on' very far
> from the tutorial. The salient featu
On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
> With so many people expressing a gut response and not saying what in
> the proposal they don't like, it's hard to even start a response. Is
> it...
> - Going from statement to function?
So I ignored my visceral reaction against the proposal
On Sat, 2005-09-03 at 09:15, Paul Moore wrote:
> OK, how about a *single* builtin, named "print", which works something
> like Nick Coghlan's proposal (I'm happy to fiddle with the details,
So I've now read Nick's wiki page and here are my comments:
First, while I think you'll need two builtins,
On Sat, 2005-09-03 at 11:17, Guido van Rossum wrote:
> I see two different ways to support the two most-called-for additional
> requirements: (a) an option to avoid the trailing newline, (b) an
> option to avoid the space between items.
See a (very quick and very dirty ;) strawman that I just pos
On Sat, 2005-09-03 at 12:51, James Y Knight wrote:
> On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
>
> > So I think it's best to have two builtins:
> >
> > print(*args, **kws)
> > printf(fmt, *args, **kws)
>
> It seems pretty bogus to me
On Sat, 2005-09-03 at 14:42, Paul Moore wrote:
> I have to agree. While I accept that Barry has genuine use cases for
> the printf form, I don't quite see why %-formatting isn't enough. Is
> the print-plus-% form so much less readable and/or maintainable?
IMO, yes. I can't tell you how many time
On Sat, 2005-09-03 at 13:12, Martin Blais wrote:
> (defun python-abbrev-print ()
> "Help me change old habits."
> (insert "print()") (backward-char 1) t)
> (put 'python-abbrev-print 'no-self-insert t)
> (define-abbrev python-mode-abbrev-table "print" "" 'python-abbrev-print)
LOL! That's a gr
2501 - 2600 of 2704 matches
Mail list logo
