Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
-Travis
PEP: ###
Title: Allowing any object to be used for slicing
Version: $Revision 1.1$
Last Modified:
I'm wondering if it's just foolish consistency (to quote a PEP 8) that is
calling for the dropping of in preference of only !=. I've used the former
since the beginning in everything from basic, fortran, claris works, excel,
gnumeric, and python. I tried to find a rationale for the
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X is an object implementing
Eric Nieuwland wrote:
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X is
Eric Nieuwland wrote:
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
-1
I've detailed my reasons here:
On 2/8/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jiwon Seo wrote:
Then, is there any chance anonymous function - or closure - is
supported in python 3.0 ? Or at least have a discussion about it?
That discussion appears to be closed (or, not really: everybody
can discuss, but it likely
On Wed, 2006-02-08 at 15:14 +0100, Valentino Volonghi aka Dialtone
wrote:
On Wed, Feb 08, 2006 at 01:23:26PM +, Donovan Baarda wrote:
I believe that Twisted does pretty much this with it's deferred stuff.
It shoves slow stuff off for processing in a separate thread that
re-syncs with
Donovan Baarda wrote:
Here I think you meant that medusa didn't handle computation in separate
threads instead.
No, I pretty much meant what I said :-)
Medusa didn't have any concept of a deferred, hence the idea of using
one to collect the results of a long computation in another thread
On Feb 9, 2006, at 3:41 AM, Smith wrote:
I'm wondering if it's just foolish consistency (to quote a PEP 8)
that is calling for the dropping of in preference of only !=.
I've used the former since the beginning in everything from basic,
fortran, claris works, excel, gnumeric, and
On 2/9/06, Neil Hodgson [EMAIL PROTECTED] wrote:
Greg Ewing:
But that won't help when you need to deal with third-party
code that knows nothing about Python or its wrapped file
objects, and calls the CRT (or one of the myriad extant
CRTs, chosen at random:-) directly.
Can you
On Thu, Feb 09, 2006 at 07:39:06AM -0500, Barry Warsaw wrote:
I've long advocated for keeping as I find it much more visually
distinctive when reading code.
+1. And, two years ago, in his PyCon keynote, Guido forgot to say was
going away, so I think Barry and I are completely in our rights
[Andrew Koenig]
Might I suggest that at least you consider using hint instead of
cue?
...
Greg I agree that hint is a more precise name.
Ditto. In addition, we already have queues. Do we really need to use a
homonym that means something entirely different? (Hint:
Hmm. Can you give real-world examples (of existing code) where you
needed this?
Jiwon Apparently, simplest example is,
Jiwon collection.visit(lambda x: print x)
Sure, but has several other people have indicated, statements are not
expressions in Python as they are in C (or in
On Thu, 2006-02-09 at 13:12 +0100, Fredrik Lundh wrote:
Donovan Baarda wrote:
Here I think you meant that medusa didn't handle computation in separate
threads instead.
No, I pretty much meant what I said :-)
Medusa didn't have any concept of a deferred, hence the idea of using
one
Adam Olsen wrote:
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
-1
I've detailed my reasons here:
Hint seems like the standard terminology in the field. I don't think
it makes sense to invent our own terminology without some compelling
reason.
Jeremy
On 2/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[Andrew Koenig]
Might I suggest that at least you consider using
On 2/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Greg I agree that hint is a more precise name.
Ditto. In addition, we already have queues. Do we really need to use a
homonym that means something entirely different? (Hint: consider the added
difficulty for non-native English
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Might I suggest that at least you consider using hint instead of
cue?
...
Greg I agree that hint is a more precise name.
Ditto. In addition, we already have queues. Do we really need to use a
homonym that means
Ditto. In addition, we already have queues. Do we really need to
use a homonym that means something entirely different? (Hint:
consider the added difficulty for non-native English speakers).
Guido Right. As a non-native speaker I can confirm that for English
Guido
[Raymond Hettinger]
[Armin Rigo]
BTW the reason I'm looking at this is that I'm considering adding
another undocumented internal-use-only method, maybe __getitem_cue__(),
that would try to guess what the nth item to be returned will be. This
would allow the repr of some iterators to
Neil Hodgson wrote:
The postgres example is strange to me as I'd never consider passing
a FILE* over a DLL boundary. Maybe this is a Unix/Windows cultural
thing due to such practices being more dangerous on Windows.
In the specific example, Postgres has a PQprint function that can
print a
Jiwon Seo wrote:
Apparently, simplest example is,
collection.visit(lambda x: print x)
Ok. I remotely recall Guido suggesting that print should become
a function.
It's not a specific example though: what precise library provides
the visit method?
which currently is not possible. Another
Neil Hodgson wrote:
But that won't help when you need to deal with third-party
code that knows nothing about Python or its wrapped file
objects, and calls the CRT (or one of the myriad extant
CRTs, chosen at random:-) directly.
Can you explain exactly why there is a problem here? Its
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
-Travis
PEP: ###
Title: Allowing any object to be
Hint seems like the standard terminology in the field. I don't think
it makes sense to invent our own terminology without some compelling
reason.
Okay, I give, hint wins.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, 09 Feb 2006 17:39:31 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Jiwon Seo wrote:
Apparently, simplest example is,
collection.visit(lambda x: print x)
Ok. I remotely recall Guido suggesting that print should become
a function.
Even so, that one is so
Enough already.
As has clearly been proven, lambda is already perfect.
***
To those folks attempting to propose alternate syntax (e.g. x - y):
this is the wrong thread for that (see subject). Seriously, I've seen
lots of proposals that just change the syntax, and none of them are so
much better
On Thu, 09 Feb 2006 17:39:31 +0100, \Martin v. Löwis\ [EMAIL PROTECTED]
wrote:
It's not a specific example though: what precise library provides
the visit method?
I'll provide my own usecase right now which is event driven programming of
any kind (from GUI toolkits, to network
On Thu, 9 Feb 2006 09:54:59 -0600, [EMAIL PROTECTED] wrote:
Ditto. In addition, we already have queues. Do we really need to
use a homonym that means something entirely different? (Hint:
consider the added difficulty for non-native English speakers).
Guido Right. As a
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
Excellent! I was just going over the 2.5 schedule with Neal
On 2/9/06, Brett Cannon [EMAIL PROTECTED] wrote:
2) Change the ISINT macro in ceval.c to accomodate objects with the
index slot defined.
Maybe the macro should also be renamed? Not exactly testing if
something is an int anymore if it checks for __index__.
Have you looked at the
On 2/9/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
COM really solves all problems people might have on Windows.
Taken deliberately out of context, that sounds rather like a claim
even Microsoft itself wouldn't make. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 2/7/06, Mark Edgington [EMAIL PROTECTED] wrote:
Ok, perhaps the notation could be improved, but the idea of the
semaphore in the patch is Does it run inside of a multithreaded
environment, and could its push() functions be called from a different
thread?
The long-term fate of
On 2/9/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/9/06, Brett Cannon [EMAIL PROTECTED] wrote:
2) Change the ISINT macro in ceval.c to accomodate objects with the
index slot defined.
Maybe the macro should also be renamed? Not exactly testing if
something is an int
On Thu, 09 Feb 2006 16:41:10 +1300, Greg Ewing [EMAIL PROTECTED] wrote:
My thought on lambda at the moment is that it's too VERBOSE.
If a syntax for anonymous functions is to pull its weight,
it needs to be *very* concise. The only time I ever consider
writing a function definition in-line is
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
I'm a little confused. Is your opposition solely due to the fact that
you think float's __int__ method ought to raise exceptions and the
apply_slice code should therefore use the __int__ slot?
In theory I can understand this reasoning.
On Thu, 09 Feb 2006 01:00:22 -0700, Travis Oliphant [EMAIL PROTECTED] wrote:
Abstract
This PEP proposes adding an sq_index slot in PySequenceMethods and
an __index__ special method so that arbitrary objects can be used
in slice syntax.
Rationale
Currently integers and long integers
On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote:
In the past, the protocol for aqcuiring a PEP number has been to ask
the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I
believe that we could simplify this protocol to avoid necessary
involvement of the PEP
Bengt Richter wrote:
1) Replace lambda args: value with
args - value
or something equivalently concise, or
Yet another bike shed color chip:
!(args:expr) # == lambda args:expr
and
!(args::suite) # == (lambda args::suite)
Please drop it. Guido pronounced on it, it is _not_
Bengt Richter wrote:
How about if SLICE byte code interpretation would try to call
obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case?
I believe that this is pretty much exactly what I'm proposing. The
apply_slice and assign_slice functions in ceval.c are called
Bengt Richter wrote:
How about if SLICE byte code interpretation would try to call
obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case?
I believe that this is pretty much what I'm proposing (except I'm not
proposing to use the __int__ method because it is already
Martin v. Löwis:
COM really solves all problems people might have on Windows.
COM was partly just a continuation of the practices used for
controls, VBXs and other forms of extension. Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should
Martin v. Löwis:
Not sure whether this was a serious suggestion.
Yes it is.
If pythonxy.dll
was statically linked, you would get all the CRT duplication
already in extension modules. Given that there are APIs in Python
where you have to do malloc/free across the python.dll
boundary,
Paul Moore:
This has all been thrashed out before, but the issue is passing
CRT-allocated objects across DLL boundaries.
Yes, that was the first point I addressed through wrapping CRT objects.
At first glance, this is a minor issue - passing FILE* pointers across
DLL boundaries isn't
On 2/9/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote:
In the past, the protocol for aqcuiring a PEP number has been to ask
the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I
believe that we could simplify this
Attached is an updated PEP for 357. I think the index concept is better
situated in the PyNumberMethods structure. That way an object doesn't
have to define the Sequence protocol just to be treated like an index.
-Travis
PEP: 357357357
Title: Allowing any object to be used for slicing
Neil Hodgson wrote:
If pythonxy.dll
was statically linked, you would get all the CRT duplication
already in extension modules. Given that there are APIs in Python
where you have to do malloc/free across the python.dll
boundary, you get memory leaks.
Memory allocations across DLL boundaries
Neil Hodgson wrote:
At first glance, this is a minor issue - passing FILE* pointers across
DLL boundaries isn't something I'd normally expect people to do - but
look further and you find you're opening a real can of worms. For
example, Python has public APIs which take FILE* parameters.
So
Looks good to me. Only change I might make is mention why __int__
doesn't work sooner (such as in the rationale). Otherwise +1 from me.
-Brett
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Attached is an updated PEP for 357. I think the index concept is better
situated in the
Guido van Rossum wrote:
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
BTW do you also still want to turn ZeroDivisionError into a warning
(that is changed into an error by default)? That idea shared a slide
and I believe it was discussed in the same meeting you I and some
others
On 2/9/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Guido seemed accepting to this idea about 9 months ago when I spoke to
him. I finally got around to writing up the PEP. I'd really like to
get this into Python 2.5 if possible.
-1
Martin v. Löwis:
Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should Python?
Do you really not know? Because of API that happens to be defined
the way it is.
It was rhetorical: Why should Python be inferior to VB?
I suppose the
On 2/9/06, Valentino Volonghi aka Dialtone [EMAIL PROTECTED] wrote:
Let's consider this piece of code (actual code that works today and uses
twisted for convenience):
def do_stuff(result):
if result == 'Initial Value':
d2 = work_on_result_and_return_a_deferred(result)
Neil Hodgson wrote:
I suppose the answer (hmm, am I allowed to anser my own rhtorical
questions?) is that it was originally developed on other operating
systems and the Windows port has never been as much of a focus for
most contributors.
That's certainly the case. It is all Mark Hammond's
On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote:
Looks good to me. Only change I might make is mention why __int__
doesn't work sooner (such as in the rationale). Otherwise +1 from me.
I have a slight reservation about the name. On the one hand it's clear the
canonical use will
On Fri, Feb 10, 2006, Thomas Wouters wrote:
I have a slight reservation about the name. On the one hand it's clear the
canonical use will be for indexing sequences, and __index__ doesn't look
enough like __int__ to get people confused on the difference. On the other
hand, there are other
[Bengt, on lambda :: suite]
Since you probably won't stop until I give you an answer: I'm really
not interested in a syntactic solution that allows multi-line lambdas.
I don't think the complexity (in terms of users needing to learn them)
is worth it. So please stop (as several people have
Guido van Rossum wrote:
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote:
This is very close to acceptance. I think I'd like to see the patch
developed and submitted to SF (and assigned to me) prior to
acceptance.
Copyright
This document is placed in the public domain
If you
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
...
The patch adds a new API function int PyObject_AsIndex(obj).
This was not specifically in the PEP but probably should be. The name
could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero
slot example to help write
On 2/9/06, Alex Martelli [EMAIL PROTECTED] wrote:
Shouldn't that new API function (whatever its name) also be somehow
exposed for easy access from Python code? I realize new builtins are
unpopular, so a builtin 'asindex' might not be appropriate, but
perhaps operator.asindex might be. My main
Thomas Wouters wrote:
On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote:
Looks good to me. Only change I might make is mention why __int__
doesn't work sooner (such as in the rationale). Otherwise +1 from me.
I have a slight reservation about the name. On the one hand it's
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
I have a slight reservation about the name. On the one hand it's clear the
canonical use will be for indexing sequences, and __index__ doesn't look
enough like __int__ to get people confused on the difference. On
On Thu, 9 Feb 2006 16:27:35 -0800, Guido van Rossum [EMAIL PROTECTED] wrote:
[Bengt, on lambda :: suite]
Since you probably won't stop until I give you an answer: I'm really
not interested in a syntactic solution that allows multi-line lambdas.
I don't think the complexity (in terms of users
Brett == Brett Cannon [EMAIL PROTECTED] writes:
Brett On 2/9/06, Barry Warsaw [EMAIL PROTECTED] wrote:
Maybe we can amend your rules to those people who both have
commit privileges and have successfully submitted a PEP before.
PEP virgins should go through the normal process.
Noticed that various socket tests are failing today, WinXP, Python trunk:
test_socket_ssl
Exception in thread Thread-27:
Traceback (most recent call last):
File C:\Code\python\lib\threading.py, line 444, in __bootstrap
self.run()
File C:\Code\python\lib\threading.py, line 424, in run
[EMAIL PROTECTED] wrote:
Lambdas are expressions. Statements can't be embedded in expressions. That
statements and expressions are different is a core feature of the language.
That is almost certainly not going to change.
Although print may become a function in 3.0, so that this
particular
On Thu, 2006-02-09 at 19:10 -0500, Jim Jewett wrote:
Logically, = means the same as or =
does not mean the same as or ; it might just mean that
they aren't comparable. Whether that is a strong enough reason
to remove it is another question.
Visually, == looks very symmetrical and
Valentino Volonghi aka Dialtone wrote:
when some_operation_that_results_in_a_deferred() - result:
if result == 'Initial Value':
when work_on_result_and_return_a_deferred(result) - inner_res:
print inner_res
else:
print No work on result
Thomas Wouters wrote:
I have a slight reservation about the name. ... On the other
hand, there are other places (in C) that want an actual int, and they could
use __index__ too.
Maybe __exactint__?
--
Greg Ewing, Computer Science Dept, +--+
University of
Guido van Rossum wrote:
To those people who believe that lambda is required in some situations
because it behaves differently with respect to the surrounding scope
than def: it doesn't, and it never did. This is (still!) a
surprisingly common myth. I have no idea where it comes from; does
Tim Peters wrote:
I _suspect_ that rev 42253 introduced these problems. For example, that
added:
+ /* Guard against socket too large for select*/
+ if (s-sock_fd = FD_SETSIZE)
+ return SOCKET_INVALID;
to _ssl.c, and added
+/* Can we call select() with this
Add a nb_index slot to PyNumberMethods, and a corresponding
__index__ special method. Objects could define a function to
place in the sq_index slot that returns an appropriate
I presume 'sq_index' should also be 'nb_index'
___
Python-Dev
[Tim]
... FD_SETSIZE is the maximum number of distinct fd's an fdset can
hold, and the numerical magnitude of any specific fd has nothing to do
with that in general (they may be related in fact on Unix systems that
implement an fdset as a big bit vector -- but Windows doesn't work
that way,
74 matches
Mail list logo
