On 8-apr-2006, at 5:44, Guido van Rossum wrote:
> On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
>> Basic idea:
>>
>> [for ... in ...]+ if ...:
>> body
>>
>> A) it should be syntatically simple to parse.
>> B) it establishes a nice symetry with list comprehensions.
>
> Are you in caho
On 18-apr-2006, at 10:49, Guido van Rossum wrote:
> On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> The problem is that there's no way for Python to know
>> which class the method is "in", in the sense required
>> here.
>>
>> That could be fixed by giving functions defined inside
>> a class
On 1-mei-2006, at 4:10, Greg Ewing wrote:
>
>
>> we may as well go whole hog and take wxPython;
>
> I'd be disappointed if something like wxPython were chosen
> as the next "official" Python gui, for a lot of reasons --
> bloat, ugly and unpythonic API, non-native appearance and
> behaviour, dubi
On 8-mei-2006, at 2:55, Greg Ewing wrote:
Paul Moore wrote:
If the implication here is that there is *no* GUI in the Python
standard library, I'd be cautious of this (-0, probably). Things like
the pydoc server use a little GUI window.
There *isn't* currently any GUI in the core distributio
On 8-mei-2006, at 4:07, Bill Janssen wrote:
Aahz,
First of all, Mac users downloading a release get Tk automatically.
Good idea!
I run on a Mac, and don't download -- I use the pre-installed Python
on the Mac. And there's no Tk.
What version of OSX are you using? /usr/bin/python on 10.4
On 8-mei-2006, at 8:58, Talin wrote:
And *how* exactly would you implement your isFunction test
so as to detect the "naive, everyday concept of a function"
that you seem to want, in a way that does any better job
than the current callable()?
This 'isFunction' test that I am thinking of would
On 8-mei-2006, at 17:38, Fred L. Drake, Jr. wrote:
On Monday 08 May 2006 05:39, Ronald Oussoren wrote:
Yes there is. Some distributors are lame enough to think they know
better
and ship parts of the standard library seperately, but that's not
a valid
reason for removing parts o
On Wednesday, May 10, 2006, at 08:26AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If I understand your proposal correctly, this approach doesn't do anything
>> beyond what Java does, and is inferior to already-available adaptation and
>> interface systems for today's Python.
>
>Inferior is in
On Wednesday, May 10, 2006, at 12:24PM, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>
>> and then I find that
>> multiple-handler systems (e.g. gtk signals) tend
>> to hinder more than they help.
>
>Is there a production-ready GUI toolkit that *doesn't* have multiple handlers?
AFAIK Cocoa doesn't
On 11-mei-2006, at 8:45, Talin wrote:
> Josiah Carlson wrote:
>> Having identical behavior on all platforms is wonderful, I'm very
>> happy
>> for you and everyone else with a toolkit (programming language,
>> etc.) that
>> does the same. For the rest of us who cannot use PyQt for one
>> re
On 11-mei-2006, at 21:06, Jan Claeys wrote:
> Op ma, 08-05-2006 te 11:59 -0400, schreef Fred L. Drake, Jr.:
>> Yes, there is a good reason for Tkinter to be separate. There's
>> not a good
>> reason for distutils to be separate.
>
> Why would ordinary end-users of an application written in Pyt
On 30-mei-2006, at 19:49, Josiah Carlson wrote:
>
> "Steven Bethard" <[EMAIL PROTECTED]> wrote:
>>
>> On 5/30/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>> So, first step in my mind is settling if we want to add one more
>>> depth to
>>> the stdlib, and if so, how we want to group (not specif
On 31-mei-2006, at 9:00, Josiah Carlson wrote:
>
> Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>>
>>
>> On 30-mei-2006, at 19:49, Josiah Carlson wrote:
>>> Though I'm probably a bit strange in that I almost want a top level
>>> "py"
&
On 31-mei-2006, at 19:19, Antoine Pitrou wrote:
> Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :
>>
>> That might be true of http, but what about modules with a more
>> ambiguous name?
>
> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be name
On 1-jun-2006, at 13:29, Paul Moore wrote:
> On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> Why would a 3rd-party module be installed into the stdlib namespace?
>> net.jabber wouldn't exist unless it was in the stdlib or the
>> module's author
>> decided to be snarky and inject their mo
On 1-jun-2006, at 17:44, Brett Cannon wrote:
>
>
> On 6/1/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> On 1-jun-2006, at 13:29, Paul Moore wrote:
>
> > On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> >> Why would a 3rd-party module
On 2-jun-2006, at 20:53, Terry Reedy wrote:
"Aaron Bingham" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[me]
For the latter (2 above), I think those who want such mostly
agree in
principle on a mostly two-level hierarchy with about 10-20 short
names
for
the top-level, usi
On 6-jun-2006, at 11:51, Nick Coghlan wrote:
> Greg Ewing wrote:
>> tomer filiba wrote:
>>
>>> okay, i give up on read(n) returning n bytes.
>>
>> An idea I had about this some time ago was that read()
>> could be callable with two arguments:
>>
>>f.read(min_bytes, max_bytes)
>>
>> The two va
On Jul 19, 2006, at 6:31 PM, Guido van Rossum wrote:
> On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Andrew Koenig wrote:
>>
>>> I am uncomfortable about exposing the implementation this way, if
>>> only
>>> because it would require fixing the equivalence between callable
>>> () and
>>>
On Jul 20, 2006, at 3:26 AM, Greg Ewing wrote:
> Ronald Oussoren wrote:
>
>> Classic classes?
>
> I just checked, and it seems they've been fixed too:
> callable() and hasattr(obj, '__call_') give the same
> result -- true if and only if a __call__ method h
On 28-aug-2006, at 16:21, Edward C. Jones wrote:
>
> Brian Quinlan said:
>> It is my understanding that, in Python 3000, certain functions and
>> methods that currently return lists will return some sort of view
>> type
>> (e.g. dict.values()) or an iterator (e.g. zip). So certain usage
>> patt
On 30-aug-2006, at 7:26, Talin wrote:
> Guido van Rossum wrote:
>>
>> Regarding optimal buffer size, I've never seen a program for which 8K
>> wasn't optimal. Larger buffers simply don't pay off.
Larger buffers can be useful when doing binary I/O through stdio (at
least on linux). I've recentl
On Friday, September 08, 2006, at 02:30PM, Jean-Paul Calderone <[EMAIL
PROTECTED]> wrote:
>On Fri, 8 Sep 2006 00:26:55 -0700, Hasan Diwan <[EMAIL PROTECTED]> wrote:
>>On 08/09/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>>
>>>Perhaps it would be good to drop those magic numbers (0, 1, 2) for
On Friday, September 08, 2006, at 03:41PM, Jean-Paul Calderone <[EMAIL
PROTECTED]> wrote:
>On Fri, 08 Sep 2006 15:37:00 +0200, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>>
>>On Friday, September 08, 2006, at 02:30PM, Jean-Paul Calderone <[EMAIL
>>PROTECTED
On Sep 15, 2006, at 7:04 PM, Jim Jewett wrote:
On 9/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Jim Jewett wrote:
... would be necessary to at least *scan* the string when it
was first created in order to ensure it can be decoded without
errors
What happens today with strings? I th
On Sep 17, 2006, at 3:16 PM, Nick Coghlan wrote:
Andre Meyer wrote:
While I understand the difficulties in removing the GIL and the
potential negative effect on single-threaded applications I would
very
much encourage discussion to seriously consider removing the GIL
(maybe
optionally) in
On Sep 18, 2006, at 9:56 PM, Raymond Hettinger wrote:
* I doubt the anecdotal comments about Boehm GC with respect to
performance. It may be better or it may be worse. While I think the
latter is more likely, only an implementation patch will tell the
tale.
hear, hear ;-). Other anecdoti
On Sep 18, 2006, at 10:56 PM, Barry Warsaw wrote:
I don't know, I hate macros. :)
It's been a long while since I programmed on the NeXT, so Mac folks
here please chime in, but isn't there some Foundation idiom where
temporary Objective-C objects didn't need to be explicitly released
if their
On Oct 13, 2006, at 7:39 AM, Talin wrote:
Now that I've gotten your attention :)
Seriously, though, I am not proposing that there *never* be
additions to
the standard library -- instead, I simply want 'easy_install' to work
100% of the time, so that there's much less reason to add something
On Friday, October 13, 2006, at 08:26AM, Giovanni Bajo <[EMAIL PROTECTED]>
wrote:
>Talin wrote:
>
>> Seriously, though, I am not proposing that there never be additions
>> to the standard library -- instead, I simply want 'easy_install' to
>> work 100% of the time, so that there's much less rea
On Oct 15, 2006, at 12:59 AM, Greg Ewing wrote:
Ivan Krstić wrote:
That'd be nice. And on that note, for the love of confused masses
everywhere, can we please change the name of easy_install to
something
Python-specific, such as 'egg' or 'py_install'?
I don't think that easy_install supp
On Oct 16, 2006, at 6:48 AM, Martin v. Löwis wrote:
Greg Ewing schrieb:
Which it *shouldn't* have to do. Timestamp checking
is fundamental to any kind of build process. It
should be built into the very foundations of the tool,
not left for each extension to re-invent separately.
And indeed,
On Nov 1, 2006, at 8:07 PM, Josiah Carlson wrote:
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 08:32:08AM -0800, Josiah Carlson wrote:
p = path.normpath(path.join(__file__, os.pardir, os.pardir, "lib"))
What operating systems that Python currently supports doesn't
h
On Nov 2, 2006, at 5:21 PM, Paul Moore wrote:
On 11/1/06, Mike Orr <[EMAIL PROTECTED]> wrote:
[...] especially since both Mac and
Windows do the right thing with "/", "..", and "." now.
Not always:
D:\Data>dir C:/
Invalid switch - "".
And on Mac this depends on the API you use, if you use
On Nov 2, 2006, at 6:53 PM, Talin wrote:
Ronald Oussoren wrote:
On Nov 2, 2006, at 5:21 PM, Paul Moore wrote:
On 11/1/06, Mike Orr <[EMAIL PROTECTED]> wrote:
[...] especially since both Mac and
Windows do the right thing with "/", "..", and "." now.
On 14 Nov 2006, at 4:26 AM, George Sakkis wrote:
I honestly fail to understand your current objections. Is my analogy
with dictmixin flawed ? Would anything change if I named it
"itermixin" instead of iter or Iter ? I'm ok with the idea being
rejected, but at least I'd like to understand the
On 17 Nov 2006, at 8:22 PM, Bill Janssen wrote:
Greg Ewing wrote:
George Sakkis wrote:
And for two, not everyone feels comfortable with duck typing. People
who consider (for better or for worse) isinstance() safer than
hasattr()/getattr() would be accomodated too.
The trouble is that buil
On 29 Nov 2006, at 1:10 AM, Greg Ewing wrote:
BTW, another advantage of all this is that it provides a lot
more flexibility in the overall approach to implementing
the type object. For example, we might decide to move the
type slots into a separate memory block, so that the
type struct could
On 30 Nov 2006, at 1:34 AM, Greg Ewing wrote:
Ronald Oussoren wrote:
It is already possibly to extend the type struct in Python 2.3
and later
From Python?
No, from C.
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyr
On Dec 9, 2006, at 2:17 AM, Phillip J. Eby wrote:
> At 01:20 PM 12/9/2006 +1300, Greg Ewing wrote:
>> Talin wrote:
>>> In other words, the
>>> __metaclass__ statement would have a side-effect of replacing the
>>> locals() dict with a mapping object supplied by the metaclass.
>>
>> __metaclass__ i
On Dec 11, 2006, at 9:10 PM, Brett Cannon wrote:
On 12/10/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
Has anyone considered consolidating the module pairs that have both a
C and Python implementation? For example, pickle and cPickle and
StingIO and cStringIO. It seems like keeping both aro
On 16 Dec, 2006, at 22:39, Steven Bethard wrote:
The main issue for me is that I think that its important to
distinguish
between get/set operations that are done at class definition time,
and
get/set operations that are done later, after the class is created.
Why? Can you explain your
On 22 Dec, 2006, at 3:09, Brett Cannon wrote:
I am starting to compile the list of modules to suggest for removal
and I
noticed that there are still a large number for platform-specific
directories in Lib/. I was wondering if we should consider some
platforms
for removal.
The reason I am
On 14 Feb, 2008, at 23:21, Martin v. Löwis wrote:
>> The code that guesses the default stdout encoding isn't very good,
>> especially not on OSX. Suggestions are welcome.
>
> Unfortunately, Apple isn't very cooperative here. There is no way
> of determining the encoding of a Terminal.app window,
On 19 Feb, 2008, at 19:33, Guido van Rossum wrote:
Well, we're basically hoping that the folks who actually uses Python
to read and write text files containing non-ASCII characters on OSX
tell us what they want. At least that's where I am. Since I personally
still live in a nearly-ASCII world (
On 29 Apr, 2008, at 5:39, Bill Janssen wrote:
Nice job, Brett. I only have two concerns:
As you don't quite note, the Mac "ic" module is the interface to the
"Internet Configuration" system on the Mac. In particular, it's where
proxy information is drawn from. We need to have that replaceme
On 30 Apr, 2008, at 2:17, Brett Cannon wrote:
On Tue, Apr 29, 2008 at 3:03 PM, David Bolen <[EMAIL PROTECTED]>
wrote:
"Brett Cannon" <[EMAIL PROTECTED]> writes:
Also realize all of the right people have been consulted on this
stuff
(e.g., the web SIG about the urllib package). So please d
On 2 Jan, 2007, at 1:14, Brett Cannon wrote:
* buildtools
2.3
This one is still used by buildapplet (a mac specific tool/module).
However, see below for more on this.
* cfmfile
2.4
mac specific, I don't know if this works on OSX (Jack probably knows).
* macfs
2.3
Mac spe
On 3 Jan, 2007, at 22:07, Brett Cannon wrote:
On 1/3/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
On 2 Jan, 2007, at 1:14, Brett Cannon wrote:
>
> * buildtools
>2.3
This one is still used by buildapplet (a mac specific tool/module).
However, see below for more on t
On 4 Jan, 2007, at 6:30, Neal Norwitz wrote:
On 1/3/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
On 2 Jan, 2007, at 1:14, Brett Cannon wrote:
> * Mac
>+ applesingle
>- Undocumented.
>* AppleSingle is a binary file format for A/UX.
>
On Friday, May 25, 2007, at 03:03PM, "Steve Howell" <[EMAIL PROTECTED]> wrote:
>
>
>Remember, you and I have no disagreement whatsoever
>about what the Python code looks like. I look forward
>to seeing beautiful code written in French, Korean,
>etc. under PEP 3131, and I have not opposed anythin
On Tuesday, June 26, 2007, at 08:49PM, "Chris Spencer" <[EMAIL PROTECTED]>
wrote:
> I know this is probably futile, but I'm going to ask anyway.
>Since I have not the time (or ability) to code this, I am not even
>submitting a PEP. I'm throwing this out there on the wind.
> Since we
I've CC-ed Jack Jansen as he has maintained the Mac libraries for ages (from
way before OS9 was shiny and new).
On Wednesday, July 25, 2007, at 07:18AM, "Jeffrey Yasskin" <[EMAIL PROTECTED]>
wrote:
>I'm looking through a couple of the OS X tests and have run into the
>question of what to do wi
On 26 Jul, 2007, at 4:07, Greg Ewing wrote:
I initially thought that 'bytes'
was the appropriate type. Unfortunately, bytes is mutable, and I
think
it makes sense to hash these constants (and some code in aepack.py
does).
Is this another indication that we should have an
immutable version
On 27 Jul, 2007, at 5:38, Jeffrey Yasskin wrote:
I've sent the patch as http://python.org/sf/1761465 using Guido's
suggestion of using bytes, but I do philosophically prefer Talin's and
Ronald's suggestions.
On 7/25/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
I&
On 30 Oct, 2007, at 19:05, Brett Cannon wrote:
On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
2007/10/27, Bill Janssen <[EMAIL PROTECTED]>:
ISTR much of the plat-mac stuff was generated by Tools/bgen. If
so, that
would be the place to fix things.
Sure looks like generated code.
On 1 Nov, 2007, at 15:06, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
For what it is worth: I agree that most of the mac libraries, such as
the entire Carbon package, shouldn't be part of the standard library.
The reason for that is simple:
On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
I'm volunteering to keep improving PyObjC, but I won't promise that
PyObjC will be complete enough to replace the Carbon tree by the time
Python 3.0 goes into beta. Heck
On 1 Nov, 2007, at 22:51, Neal Norwitz wrote:
On Nov 1, 2007 7:31 AM, Ronald Oussoren <[EMAIL PROTECTED]>
wrote:
On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
I'm volunteering to keep improving PyObjC, but I w
On 1 Nov, 2007, at 18:24, Brett Cannon wrote:
On 11/1/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
On the bright side: Carbon is basicly dead: there will be no new
development on Carbon and it also not supported in 64-bit mode (at
least the GUI bits).
Unfortunately, the "gotcha" is that some
On 30 Nov, 2007, at 17:51, Christian Heimes wrote:
Eric Smith wrote:
And backporting __format__ and friends back to trunk is on my pending
list. The fact that upgrading to Leopard broke my compilation
environment isn't helping me out, unfortunately.
I've seen several bugs related to Mac OS
On 6 Dec, 2007, at 5:14, Brett Cannon wrote:
> As Guido stated in a recent email, the stdlib reorg is going to be the
> next big thing in Py3K-Land after a2 goes out the door. And since I
> stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
> several times before, I am the de-f
62 matches
Mail list logo
