On Tue, Apr 11, 2006 at 12:58:47AM -0400, Kendall Clark wrote:
> Hmm. Tastes vary, obviously. I don't consider using ? to signal
> boolean returning functions or methods to be random.
They look ugly in expressions:
if python.has_punctuation?() and someone.uses_it_often?:
print "Please don
Ian Bicking wrote:
> So I hear there's long been the ability to make multiple interpreters at
> the C level -- but this has never been exposed at the Python
> level.
I'm not sure it would help in this case, unless
there was no sharing of objects between the
interpreters, in which case you might
Kendall Clark wrote:
> I don't consider using ? to signal boolean
> returning functions or methods to be random.
Picking those two characters out of all the punctuation
symbols to be legal in identifiers is a fairly arbitrary
choice, given that most natural languages only use
letters in their w
Kendall Clark wrote:
> Well, some differences. In Ruby, for example, symbols are global in
> scope and strings aren't.
In Python, interning is global in scope, so intern('foo')
done in one module gives the same object as intern('foo')
done in another module. And since CPython automatically
inte
Kendall Clark wrote:
> Symbols would be a pretty picayune addition to the language, but the
> Ruby folks seem to get v. good mileage out of them for
> metaprogramming,
Because Ruby strings are mutable, you can't use
them as symbols the way you can in Python. The
languages are different enough
Steven Bethard wrote:
> This is potentially a Python 2.6 PEP, but it has some optional
> extensions for Python 3000 and may be relevant to the
> adaptation/overloading/interfaces discussion. It proposes a make
> statement such that:
> make :
>
> would be translated into the assignme
On Tue, 2006-04-11 at 10:47 +0400, Oleg Broytmann wrote:
> On Tue, Apr 11, 2006 at 12:58:47AM -0400, Kendall Clark wrote:
> > Hmm. Tastes vary, obviously. I don't consider using ? to signal
> > boolean returning functions or methods to be random.
>
>They look ugly in expressions:
>
> if pyt
On Tue, Apr 11, 2006 at 08:56:33AM -0400, Barry Warsaw wrote:
> > if python.has_punctuation?() and someone.uses_it_often?:
> >print "Please don't do it!"
> >
> That's what _p suffix is for. :)
T (: Hello, Lispers! ;)
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[E
On Apr 11, 2006, at 4:18 AM, Greg Ewing wrote:
> The only difference is a syntactic one -- whether you
> write it as 'foo' or something else like :foo.
Yeah, my point about signaling intent. (I forgot about automatic
interning, so thanks for that reminder.)
>> The other
>> difference (which y
Nick Coghlan wrote:
> Steven Bethard wrote:
>
>>This is potentially a Python 2.6 PEP, but it has some optional
>>extensions for Python 3000 and may be relevant to the
>>adaptation/overloading/interfaces discussion. It proposes a make
>>statement such that:
>>make :
>>
>>would be tra
Greg Ewing wrote:
> Kendall Clark wrote:
>>One thing I'd really like to see in Python 3000 is support for first-
>>class symbols,
>>
>> def web_dispatch("/bank-account", :GET, retrieve_account): pass
>
>
> class SymGen:
>
>def __getattr__(self, name):
> return intern(name)
>
> sy
On 4/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > This is potentially a Python 2.6 PEP, but it has some optional
> > extensions for Python 3000 and may be relevant to the
> > adaptation/overloading/interfaces discussion. It proposes a make
> > statement such that:
> >
Ian Bicking wrote:
> So I hear there's long been the ability to make multiple interpreters at
> the C level -- used by mod_python and presumably used in some other
> embedding situations -- but this has never been exposed at the Python
> level. I'm curious why that never happened? Merely inert
Greg Ewing wrote:
> Ian Bicking wrote:
>
>> So I hear there's long been the ability to make multiple interpreters at
>> the C level -- but this has never been exposed at the Python
>> level.
>
> I'm not sure it would help in this case, unless
> there was no sharing of objects between the
> inte
On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> A bit more than a year ago I blogged extensively about this. The only
> syntax that is acceptable to me is slightly different; the above would
> look like
>
> def fn(a: Seq, b: Index, c: Text = "default"): ...
>
> where Seq, Index and Text c
On 4/11/06, John Williams <[EMAIL PROTECTED]> wrote:
> I appologize if this has been suggested before, but what about this instead?
No.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[email protected]
Abstract: Module initialization currently has a few deficiencies.
There is no cleanup for modules, the entry point name might give
naming conflicts, the entry functions don't follow the usual
calling convention, and multiple interpreters are not supported
well. This PEP addresses these issues.
Mod
On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Oops. I guess you were arguing *against* the former;
> I (and perhaps others) misread your mail as arguing *for*
> the "a:0 proposed that before (unless I missed it).
> ... My confusion is why you would bring this up only to
> shoot it down
Barry Warsaw wrote:
> To be fair, I think Ruby stole the idea and syntax from Lisp. It's an
> interesting idea, but I'd like to understand exactly what you mean by "a
> Python symbol". Can you give more detail about your idea, perhaps as a
> pseudo-PEP?
I think it's as simple as the the LISP sym
On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> You had said there was some question of what kind of objects the type
> markers should be. I couldn't (and still can't) see any good reason
> for them to be anything but a way to ensure [to some level] that the
> argument is [in some way] appropr
On 4/10/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Are there other proto-PEPs being worked on? I would appreciate if the
> > authors would send me a note (or reply here) with the URL and the
> > status.
>
> This is the Backwards Incom
On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > It should mean neither. As I tried to say, the *only*
> > > semantics is that the value of the expression is
> > > accessible through the __signature__ attribute of
> > > the function. It is then up to the decorator to decide
>
On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't want to assign *any* semantics to the type markers;
> ... I'd like to be able to have a decorator that
> requires the convention of using concrete types
> (e.g. list, int, file) as type markers; calling these
> would be a mistake,
On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > [Guido]
> > > > It should mean neither. As I tried to say, the *only*
> > > > semantics is that the value of the expression is
> > > > accessible through the __signature__ attribute of
>
On 4/11/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I wish the community efforts for Python 3000 were focused more on
> practical things like the effects of making all strings unicode,
> designing a bytes datatype, a new I/O stack, and the view objects to
> be returned by keys() etc. These th
Neal Norwitz writes:
> Py3k is a great opportunity to upgrade the existing tests. We know
> they are incomplete and could do a better job testing. In some cases
> like this, where we are looking to revamp a module. It would be great
> to also beef up the tests. Hopefully a lot of that work, wil
On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > I don't want to assign *any* semantics to the type markers;
>
> > ... I'd like to be able to have a decorator that
> > requires the convention of using concrete types
> > (e.g. list, in
On 11/04/06 Michael Chermside said:
> There's a related change that I would love to see. Currently, we
> have a large number of unit tests, but we have made no attempt to
> distinguish between python language tests, and CPython implementation
> tests. If we made such a distinction, then PyPy, Jyth
On 4/11/06, Michael P. Soulier <[EMAIL PROTECTED]> wrote:
> On 11/04/06 Michael Chermside said:
>
> > There's a related change that I would love to see. Currently, we
> > have a large number of unit tests, but we have made no attempt to
> > distinguish between python language tests, and CPython imp
On Apr 11, 2006, at 2:18 PM, Martin v. Löwis wrote:
> I think it's as simple as the the LISP symbols, except when it comes
> to name binding.
Common Lisp symbols are a lot more complex in that they are not
globally unique, can be uninterned, can carry data, get automagically
upcased, have pr
So Guido asked for more concrete discussion of things like views. A
richer set of collections also fits in here, as for instance dict.keys()
would be a view with a collection interface not exactly like other
collections. I wrote up some notes, which I'll pass on.
So, I can imagine 3 attribute
On Tue, 11 Apr 2006, Michael Chermside wrote:
[...]
> There's a related change that I would love to see. Currently, we
> have a large number of unit tests, but we have made no attempt to
> distinguish between python language tests, and CPython implementation
> tests. If we made such a distinction,
Kendall Clark wrote:
> Thanks, Martin. That is, in fact, pretty much what I'd like to see in
> Py3K, modulo the issue about getattr.
The question is still: why? In Smalltalk, symbols are used to denote
names (methods/selector names and class names); this apparently isn't
your intention (and I do b
Guido van Rossum wrote:
> On 4/11/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> You had said there was some question of what kind of objects the type
>> markers should be. I couldn't (and still can't) see any good reason
>> for them to be anything but a way to ensure [to some level] that the
>> arg
Martin v. Löwis wrote:
> Kendall Clark wrote:
>
>>Thanks, Martin. That is, in fact, pretty much what I'd like to see in
>>Py3K, modulo the issue about getattr.
>
>
> The question is still: why? In Smalltalk, symbols are used to denote
> names (methods/selector names and class names); this appare
On 4/11/06, John J Lee <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Apr 2006, Michael Chermside wrote:
> [...]
> > There's a related change that I would love to see. Currently, we
> > have a large number of unit tests, but we have made no attempt to
> > distinguish between python language tests, and CPy
On Apr 11, 2006, at 4:09 PM, Ian Bicking wrote:
> Martin v. Löwis wrote:
>> Kendall Clark wrote:
>>> Thanks, Martin. That is, in fact, pretty much what I'd like to
>>> see in
>>> Py3K, modulo the issue about getattr.
>> the shift key either way (: is shift-.; " is shift-2).
>
> Symbols make it
On 4/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:[ Bold out-of-the-box thinking on modules by Martin ]
#define STATE PyModule_STATE(module_slot, struct state)
I wonder if standardization of the struct layout of 'struct state', and the naming scheme of 'struct state', 'module_slot' and 'STA
Thomas Wouters wrote:
> I wonder if standardization of the struct layout of 'struct state', and
> the naming scheme of 'struct state', 'module_slot' and 'STATE' would be
> desireable. The state and module_slot structs would be c-file-static, so
> naming conflicts shouldn't exist, and it would impro
> Well, if you were to create a hierarchy of proxy objects for "remoting"
> objects across different interpreters, you would get much better
> performance than if you used IPC. This would be similar to .NET
> AppDomains or Java Isolates.
Or you could use ILU, which works in-process...
Bill
__
Martin v. Löwis wrote:
> Well, if you were to create a hierarchy of proxy objects for "remoting"
> objects across different interpreters,
Then you have the problem of bulletproofing the
proxy objects, and somehow convincing yourself
that nothing other than proxy objects can leak
across.
--
Greg
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> I agree that such a test suite would be helpful. I don't think it
> should wait for Python 3000.
Possible plan:
Add 'spec' or 'specification' or 'language', 'implementation', and possibly
'support' subdirs to ...Lib/test. Put most test
[Martin v. Löwis]
> Abstract: Module initialization currently has a few deficiencies.
> There is no cleanup for modules, the entry point name might give
> naming conflicts, the entry functions don't follow the usual
> calling convention, and multiple interpreters are not supported
> well. This PEP
43 matches
Mail list logo
