[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
> 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 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()
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
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 o
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"
> rea
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 sym
[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
particu
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
> "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 th
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 use
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 differen
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
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
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
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 dom
On Fri, 10 Feb 2006 01:23:25 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote:
>> On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>> >Enough already.
>
[...some stuff snipped...]
>> Yes, but if you're
Guido van Rossum 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 needing to learn them)
> is worth it. So please
[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 already
On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote:
> On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >Enough already.
> Yes, but if you're an optimist, those years mean we're closer to the magic
> moment ;-)
Please stop. Discuss it elsewhere. I suggest
On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>Enough already.
>
>As has clearly been proven, lambda is already perfect.
>
[...]
>
>To those people still complaining that lambda is crippled because it
>doesn't do statements: First, remember that adding statement
>c
Smith asked:
> 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 !=.
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
On Thu, Feb 09, 2006 at 03:39:46PM -0800, Aahz wrote:
> Can you provide a couple of examples where you think you'd want __index__
> functionality but the name would be inappropriate?
Not really, or I wouldn't have had only a _slight_ reservation :) There are
many functioncalls and methodcalls tha
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
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
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 Hammon
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)
>
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 suppo
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
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
>
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
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.
>
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 DL
Neil Hodgson wrote:
>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 Python?
Do you really not know? Because of API that happen
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
Ver
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 th
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
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
> boundar
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 Pytho
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 alr
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 c
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 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 coor
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 lo
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 reason
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
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
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 asynco
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/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
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 N
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> Righ
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 frameworks/
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, =?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, tha
> 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
http://mail.pyth
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 ob
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?
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:
>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
[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
>> 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
<[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
> homony
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 Engl
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 consi
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 rea
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
>> 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 (
>> [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
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 r
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.
>
>C
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
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
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
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
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:
http://mail.python.or
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 ot
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
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 implem
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 dropping
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: $D
81 matches
Mail list logo
