[EMAIL PROTECTED] wrote:
> In my case it's
>
> Fn-Shift-F3 / O
>
> though I note now that my Mac supports Shift-Option-O as well. In any case,
> neither is all that straightforward,
What we need here is APL-style overstrikes, so you can type
an O with a / on top of it. :-)
This would also
On 4/27/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
join()it's time to make this a builtin. the "it's the separator that's doing thejoining" idea is silly and unintuitive, and should be fixed.I disagree, and I believe that would be a big mistake to change it.
-- Thomas Wouters <[EMAIL PROTECTED]>
If you want to get my general opinion; -1 on all of your recommendations.
In each part, I describe why.
Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> 1. l[:] syntax for shallow copy.
Note that [:] doesn't necessarily copy. It certainly is the case for
Python lists, strings, tuples, and uni
Collin Winter wrote:
> One of the things that's always puzzled me about Python 2.x is why any
> of the following raise a TypeError:
>
> Given a function "def foo(a, b, c=None)",
>
>> foo(4)
>> foo(4, 5, 6, 7)
>> foo(4, 5, b=6)
>> foo(4, 5, d=6)
>
> all raise TypeErrors, as do several other class
Thomas Wouters wrote:
> > join()
> >
> > it's time to make this a builtin. the "it's the separator that's doing
> > the
> > joining" idea is silly and unintuitive, and should be fixed.
>
>
> I disagree, and I believe that would be a big mistake to change it.
big mistake?
can anyone point to one
Short version: +1 for the first point (but for different reasons), -1 for the
rest. Use cases for advanced slicing operations are not provided by the
standard library, but by Numpy's sophisticated data manipulation capabilities.
Alexander Belopolsky wrote:
> 1. l[:] syntax for shallow copy.
I
On 5/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> > join()> >> > it's time to make this a builtin. the "it's the separator that's doing> > the> > joining" idea is silly and unintuitive, and should be fixed.
>>> I disagree, and I believe that would be a big mistake to chang
This has probably been proposed before, here goes anyhow.
instead of:
class TheLarch(deciduous)
__metaclass__ = KindsOfTrees
could we have this syntax:
class[KindsOfTrees] TheLarch(deciduous):
pass
more real examples:
class[interface] iterable: pass
class[Pers
Thomas Wouters wrote:
> > can anyone point to one other example where "call method on
> > literal" is used in Python ?
>
> It doesn't matter.
it doesn't matter to you when the preferred way to do things don't look
like Python code?
> Either case is confusing, one way or another, as Tim has
> alr
Bill Birch wrote:
>class[KindsOfTrees] TheLarch(deciduous):
> pass
I'd prefer not to put anything between 'class' and
the name being defined. Maybe
class TheLarch(deciduous) [KindsOfTrees]:
...
--
Greg
___
Python-3000 mailing lis
Josiah Carlson wrote:
> Ultimately, PyGUI is essentially a wrapper of native or near-native
> widgets into a common interface. wxPython is exactly the same thing,
Are you sure? Last time I looked at wxWindows, it seemed more
like it re-implemented everything its own way.
I might be wrong, but i
Thomas Wouters wrote:
> It doesn't matter. Either case is confusing, one way or another, as Tim
> has already argued. Changing it would be a big mistake. If you want me
> to come with more comprehensive arguments (other than what Tim already
> covered), please come with more comprehensive argume
Josiah Carlson wrote:
> Also, it would require shipping a Python GTK binding, which would
> basically necessitate shipping GTK+ with Python.
Keep in mind that PyGUI is still very much a work in progress.
My eventual goal is for each implementation to depend only on
what is provided natively by th
Nick Coghlan wrote:
> What if the join() builtin had a similar signature to min() & max(), and the
> separator was a keyword only argument?
+0.5 (clever)
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/py
Nick Coghlan wrote:
> Thomas Wouters wrote:
>> It doesn't matter. Either case is confusing, one way or another, as Tim
>> has already argued. Changing it would be a big mistake. If you want me
>> to come with more comprehensive arguments (other than what Tim already
>> covered), please come with
Le lundi 01 mai 2006 à 10:57 +0200, Fredrik Lundh a écrit :
> Thomas Wouters wrote:
>
> > > join()
> > >
> > > it's time to make this a builtin. the "it's the separator that's doing
> > > the
> > > joining" idea is silly and unintuitive, and should be fixed.
> >
> >
> > I disagree, and I believe
Bill Janssen wrote:
> 1) I'd add some kind of standard analog value control class,
You're in luck - I've just almost-finished adding a Slider control.
> 2) There needs to be some kind of combobox multiple-value choice
> widget
Yes, there are several more controls like this that I would
li
Le lundi 01 mai 2006 à 23:08 +1200, Greg Ewing a écrit :
> Are you sure? Last time I looked at wxWindows, it seemed more
> like it re-implemented everything its own way.
>
> I might be wrong, but if wxWindows is just a wrapper, why
> is it so huge?
I think it is huge because it has a lot of widge
> Thomas Wouters wrote:
> "I disagree, and I believe that would be a big mistake to change it."
seems to me that Thomas is right here ...
some remarks by a recent arrival at Python, my initial offset was
version 2.4.0: I think cleaning up things to ease newbie adaptation is
often misleading
I vi
On Thu, 27 Apr 2006 01:43 pm, Guido van Rossum wrote:
> Sorry for the belated response. Yes, I'd like to see this PEP. I'll
> probably eventually end up rewriting it :-), but right now I'm
> terribly overcommitted and really appreciate the help!!!
>
Rough draft is available for flames and comments
On 5/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bill Birch wrote:
>
> >class[KindsOfTrees] TheLarch(deciduous):
> > pass
>
> I'd prefer not to put anything between 'class' and
> the name being defined. Maybe
>
>class TheLarch(deciduous) [KindsOfTrees]:
> ...
This has usua
On 4/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Ok. I was only worried about your change in PEP 3099:
> "Python won't use Unicode characters for anything except string literals
> or comments."
> If that is only meant to say "this won't be introduced in Python 3",
> I'm fine with it.
Rig
On 4/29/06, Rudy Rudolph <[EMAIL PROTECTED]> wrote:
> One thing that has always bothered me about Python is the lack of in-out
> parameters. Python is such a wonderful object-oriented language, but it lacks
> this feature that nearly every language has. Maybe we can fix this in 3.0.
When I first s
> So you're really aiming at incorporating a gui-api for Python, so that it can
> be pointed at the backend of choice? Something similar to what the DB-api
> achieves for databases?
Yes, that's essentially what PyGUI already is. It doesn't attempt to
model directly any specific existing toolkit
> "Bill Janssen" <[EMAIL PROTECTED]> wrote
>
> a reply to my objection to his GUI proposal --
> that makes the proposal more sensible to me.
>
> I see you putting forth four propositions. My wording of them is:
>
> 1. Python 3 should (still) have a standard lib GUI system.
>
> 2a. TK/Tkinter
Greg Ewing writes:
> I'd like to see PyGUI or something like it become more widely
> used and maybe even included in the core one day, but it
> needs a lot more development first. Whether it will have
> reached a sufficient level of development by the time Py3k
> comes around remains to be seen.
I
> Not to mention that wxWidgets also includes a lot of non-GUI functions
> which are already provided in the Python stdlib.
This is a standard thing for toolkits designed for so-called base
languages (C, C++, Objective-C). That's one of the reasons they don't
really fit into higher-level language
> [Bill Janssen proposes we use Greg Ewing's PyGUI as the standard GUI
> framework in Py3K.]
I really like PyGUI. I have dabbled in a number of different GUI frameworks
over the years, and PyGUI is the only one where upon reading the
documentation I immediately thought "that's Pythonic!". (It's us
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
> But PyGUI is not complete. (Greg is one of the people who says this.) And
> I belive that it is just not ready to be the "blessed" Python GUI framework.
I'm suggesting a concerted effort to *make* it complete over the rest
of this year. Or, if that's for some reason not possible, to pick
some o
>>>set() == set{}
>>>set(x) # No braced equivalent
>>>set([x]) == set{x} # Ignoring list comprehensions
>>>set((x,)) == set{x}
>>>set((a, b, c)) == set{a, b, c}
>>>
>>>
>>I would rather stick to what we have than introduce two notations for
>>construction, call, subscripting, e
Bill Janssen wrote:
> > But PyGUI is not complete. (Greg is one of the people who says this.) And
> > I belive that it is just not ready to be the "blessed" Python GUI framework.
>
> I'm suggesting a concerted effort to *make* it complete over the rest
> of this year. Or, if that's for some reaso
Le lundi 01 mai 2006 à 09:59 -0700, Bill Janssen a écrit :
> Interesting. I never seem to use tree-views, but I do use graph
> views. I think the standard Python GUI should make it easy to build
> these kinds of things. Right now a graph view is fairly easy to build
> on top of a raw View.
As f
Martin v. Löwis wrote:
> It depends on the language you use to communicate. In English,
> it is certainly cumbersome to talk about Chinese identifiers.
> OTOH, I believe it is cumbersome to communicate about English
> identifiers in Chinese, either, because the speakers might
> not even know what
On 5/1/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> IOW, I recommend saving your big guns (alternative constructor syntaxes)
> for big problems whose solutions provide big rewards. Set literals are
> barely worth the brain power that has already been expended in this
> thread. If a set lit
On Mon, May 01, 2006 at 07:30:52PM +0200, Antoine Pitrou wrote:
> As far as I've seen by trying the demos and taking a quick glance at the
> source, PyGUI also lacks (from the top of my head):
> - list and combo boxes
> - list controls
> - icons in menus
> - menu hotkeys (e.g. Alt+F to open File me
Nick Coghlan gmail.com> writes:
>
> Short version: +1 for the first point (but for different reasons), -1 for the
> rest. Use cases for advanced slicing operations are not provided by the
> standard library, but by Numpy's sophisticated data manipulation capabilities.
>
I am glad you mentione
> If making PyGUI into the stdlib is important, a wiki or something could
> be opened to list the various issues people have with PyGUI.
Great idea.
Bill
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-
Antoine, thanks for looking more closely at this.
> PyGUI also lacks (from the top of my head):
> - list and combo boxes
Yes, in my message yesterday I noted that. I think only
drop-down/pop-up menu support is really necessary for this, and
there's already a menu class that could be mildly alter
>Does it support printing? wxPython/wxWidgets support cross-platform
> low-level (pixel by pixel) printing, preview with zoom...
It's currently got the low-level idea of an offscreen Pixmap into
which the app can draw by calling "with_canvas". The Pixmap captures
an image of the drawing, and
On 5/1/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> If you want to get my general opinion; -1 on all of your recommendations.
> In each part, I describe why.
>
> Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> > 1. l[:] syntax for shallow copy.
>
> Note that [:] doesn't necessarily copy.
I
Le lundi 01 mai 2006 à 11:44 -0700, Bill Janssen a écrit :
> > - list controls
>
> Not sure what you mean here.
A control which displays and allows to interact with several lines of
widgets (e.g. labels, images...).
For example a buddy list in an Instant Messaging client.
> > - menu hotkeys (e.g
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > Also, it would require shipping a Python GTK binding, which would
> > basically necessitate shipping GTK+ with Python.
>
> Keep in mind that PyGUI is still very much a work in progress.
> My eventual goal is for each implementat
"Alexander Belopolsky" <[EMAIL PROTECTED]> wrote:
> On 5/1/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > If you want to get my general opinion; -1 on all of your recommendations.
> > In each part, I describe why.
> >
> > Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> > > 1. l[:] syntax
Josiah Carlson wrote:
> wxPython, generally speaking, uses the 'native' widgets on the platforms
> it is being used on. In Windows, that means MFC.
not really. MFC is a bloated C++ layer built on top of Windows' real
native GUI.
(wxWindows 1.X was a bloated emulation of that layer; wxPython 2.
What's the point of this discussion? The (extended) slice notation
isn't going away.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Antoine> As far as I've seen by trying the demos and taking a quick
Antoine> glance at the source, PyGUI also lacks (from the top of my
Antoine> head):
...
Antoine> If making PyGUI into the stdlib is important, a wiki or
Antoine> something could be opened to list the variou
I'm running into something that may make me require parentheses around
lambda's argument list. Basically, I'm settled on the following syntax
for adding optional annotations (formerly known as type declarations
:-) to parameters definitions:
def foo(arg1name: typeexpr = defaultexpr, arg2: typeex
On Mon, May 01, 2006, Bill Janssen wrote:
>Antoine:
>>
>> You cannot assign a
>> global key shortcut to every command, while you can assign a local
>> hotkey to any menu item.
>
> This seems like creeping featurism to me. I can see the accessibility
> argument, but it is basically asking for the
Guido van Rossum wrote:
>I'm running into something that may make me require parentheses around
>lambda's argument list.
>
Are the parens always needed or will it depend on the surrounding
tokens? Adding extra parens feels a bit odd in the following situations:
databases = filter(lambda n
> since this is the Py3K list, why hurry ?
Because Guido seems to be hurrying. All those pitchforks outside his
office, I suppose.
> (for the record, I'd prefer a conceptual mix of HTML, PyGUI, WinForms,
> and WCK, plus Tkinter's binding model and Canvas. more about this some
> other day.)
Ple
Aahz writes:
> I use Windows, OS X, and Linux. In all cases, I
> strive to maximize my use of the keyboard and minimize my use of pointing
> devices.
Me too.
> I think it is entirely reasonable to expect that a GUI toolkit
> will at least make it straightforward to implement keyboard-based
> com
Yes, they will always be needed, except perhaps for an empty parameter
list; you may be able to write lambda: blah instead of lambda(): blah.
--Guido
On 5/1/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >I'm running into something that may make me require parenthe
Antoine, thanks for the explanations.
> A control which displays and allows to interact with several lines of
> widgets (e.g. labels, images...).
> For example a buddy list in an Instant Messaging client.
This seems like part of the application UI to me, not a toolkit issue.
> You cannot assign
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Before I get into my reply, I'm going to start out by defining a new
> > term:
> >
> > operationX - the operation of interpreting information differently than
> > how it is presented, generally by constructing a data stru
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > wxPython, generally speaking, uses the 'native' widgets on the platforms
> > it is being used on. In Windows, that means MFC.
>
> not really. MFC is a bloated C++ layer built on top of Windows' real
> native GUI.
I've
Bill Janssen <[EMAIL PROTECTED]> wrote:
> Antoine, thanks for the explanations.
>
> > A control which displays and allows to interact with several lines of
> > widgets (e.g. labels, images...).
> > For example a buddy list in an Instant Messaging client.
>
> This seems like part of the applicati
On 4/29/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I just read PEP 3002 and while I like most of what I see (thanks
> > Steven Bethard!) there's one section that stands out as problematic.
> [snip]
> > Rather than a version of Python
> > This seems like part of the application UI to me, not a toolkit issue.
>
> Um...no. Most client-side email applications allow you to view email in
> a particular folder as a 'threaded' and 'non-threaded' view. The
> 'non-threaded' view would be a list control, if I understand Antoine
> corre
Skip writes:
> This discussion is interesting, but runs the risk of getting a bit too
> detailed for this list. Maybe the gui-sig should be reactivated (with a
> stated goal of converging on a more Pythonic GUI for Py3k) or a pygui
> mailing list hosted on mail.python.org.
I think a PyGUI mailing
Folks, I've got a paper deadline looming, and helpful as this
discussion has been in my procrastination :-), I need to get back to it.
I'll take this thread up again next week, if no one else does.
Please feel free to send me mail in the meantime, and try a few things
with PyGUI -- let's see if it
Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > This seems like part of the application UI to me, not a toolkit issue.
> >
> > Um...no. Most client-side email applications allow you to view email in
> > a particular folder as a 'threaded' and 'non-threaded' view. The
> > 'non-threaded' view would
Given that strings are going to be unicode, will there be a "characters"
data type to go along with the "bytes" data type? And how is the bytes
data type different from the existing array type?
-- Talin
___
Python-3000 mailing list
[email protected]
On 4/30/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> for the record, this just appeared on comp.lang.python:
>
> hello everyone! I can't seem to find a function that combines a list of
> items into a string with a seperator between the individual elements..
>
> which, based on the law of
64 matches
Mail list logo
