Nick Coghlan wrote:
> Donovan Baarda wrote:
>
>>As I see it, a lambda is an anonymous function. An anonymous function is
>>a function without a name.
>
>
> And here we see why I'm such a fan of the term 'deferred expression'
> instead of 'anonymous function'.
But isn't a function just a defer
Donovan Baarda wrote:
> I must admit I ended up deleting most of the "alternative to lambda"
> threads after they flooded my in box. So it is with some dread I post
> this, contributing to it...
I must admit you are right. And I will stop defending my proposal
because it seems to create nothin
Do we have *any* known use cases where we would actually run bytecode
that was suspicious enough to warrant running a well-formedness check?
In assessing security risks, the PEP notes, "Practically, it would be
difficult for a malicious user to 'inject' invalid bytecode into a PVM
for the purposes
Introducing a new set of duplicate type names and deprecating old ones
causes a certain amount of disruption. Given the age of the types
module, the disruption is likely to be greater than any potential
benefit that could be realized. Plenty of people will have to incur the
transition costs, but
> I use XML-RPC as the communications protocol between an Apache web server
> and a middleware piece that talks to a MySQL database. The web server
> contains a mixture of CGI scripts written in Python and two websites written
> in Mason (Apache+mod_perl). Performance is fine. Give either of the
Simon> XML is simply not suitable for database appplications, real time
Simon> data capture and game/entertainment applications.
I use XML-RPC as the communications protocol between an Apache web server
and a middleware piece that talks to a MySQL database. The web server
contains a mixt
> [Donovan Baarda]
> > As I see it, a lambda is an anonymous function. An anonymous
function
> is
> > a function without a name. We already have a syntax for a
function...
> > why not use it. ie:
> >
> > f = filter(def (a): return a > 1, [1,2,3])
[Me]
> This approach is entirely too obvious. If
At 06:50 PM 6/18/2005 -0600, Neil Schemenauer wrote:
>On Sat, Jun 18, 2005 at 06:24:48PM -0400, Phillip J. Eby wrote:
> > So, I think I've got this sorted out, assuming that I'm not doing
> > something hideously insane by having 'has_finalizer()' always
> > check tp_del even for non-heap types, and
[Donovan Baarda]
> As I see it, a lambda is an anonymous function. An anonymous function
is
> a function without a name. We already have a syntax for a function...
> why not use it. ie:
>
> f = filter(def (a): return a > 1, [1,2,3])
This approach is entirely too obvious. If we want to be on th
Simon Wittber <[EMAIL PROTECTED]> wrote:
> > Why this discussion of yet another serialization format?
>
> Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
> XML can be bloated, and XML+gzip is quite slow.
>
> Do size,speed, and security features have to mutually exclusive? No,
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > Kay Schluehr <[EMAIL PROTECTED]> wrote:
> >> The arrow is a straightforward punctuation for function definitions.
> >> Reusing existing keywords for different semantics seems to me as a kind
> >> of inbreeding.
> >
> >
On Sat, Jun 18, 2005 at 06:24:48PM -0400, Phillip J. Eby wrote:
> So, I think I've got this sorted out, assuming that I'm not doing
> something hideously insane by having 'has_finalizer()' always
> check tp_del even for non-heap types, and defining a tp_del slot
> for generators to call close() in.
Donovan Baarda wrote:
> As I see it, a lambda is an anonymous function. An anonymous function is
> a function without a name.
And here we see why I'm such a fan of the term 'deferred expression'
instead of 'anonymous function'.
Python's lambda expressions *are* the former, but they are
emphati
> Why this discussion of yet another serialization format?
Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
XML can be bloated, and XML+gzip is quite slow.
Do size,speed, and security features have to mutually exclusive? No,
that possibly is why people have had to invent their
Kay Schluehr wrote:
> Josiah Carlson wrote:
>
> > Kay Schluehr <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Maybe anonymus function closures should be pushed forward right now
> not only syntactically? Personally I could live with lambda or several
> >> of the alternative syntaxes listed on the w
BJörn Lindqvist wrote:
> Would it also be possible for the PEP-maintainers not to accept PEPs
> that are obvious jokes unless thedate is April I?
I believe this is the current policy. Why do you think the PEP editor
works differently?
Regards,
Martin
__
Gustavo Niemeyer wrote:
> Before sending the message I thought, "let's see how much time it
> takes until someone mentions the right place to deliver the message".
> Adding that address to the PyPI page itself would be valueable, and
> will probably save python-dev from further misinformed reporter
One more note; I tried changing generators to set their gi_frame to None
whenever the generator finishes normally or with an error; this eliminated
most of the reference cycles, and I was able to make test_generators work
correctly with only 3 explicit close() calls, for the "fun" tests that use
*cough*
Would it also be possible for the PEP-maintainers not to accept PEPs
that are obvious jokes unless thedate is April I?
*uncough*
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
I've just submitted patch 1223381 (http://python.org/sf/1223381), which
implements code and test changes for:
* yield expressions
* bare yield (short for yield None)
* yield in try/finally
* generator.send(value) (send value into generator; substituted for PEP
342's next(arg))
* generator.throw(
Argh! My email client's shortcut for Send is Ctrl-E, which is the same as
end-of-line in the editor I've been using all day. Anyway, the problem is
that it seems to me as though actually checking for tp_del is too
aggressive (conservative?) for generators, because sometimes a generator
object
At 05:50 PM 6/18/2005 -0400, Phillip J. Eby wrote:
>Working on the PEP 342/343 generator enhancements, I've got working
>send/throw/close() methods, but am not sure how to deal with getting
>__del__ to invoke close(). Naturally, I can add a "__del__" entry to its
>methods list easily enough, but t
Working on the PEP 342/343 generator enhancements, I've got working
send/throw/close() methods, but am not sure how to deal with getting
__del__ to invoke close(). Naturally, I can add a "__del__" entry to its
methods list easily enough, but the 'has_finalizer()' function in
gcmodule.c only ch
> > PyPI seems to be out of space:
>
> FYI, python-dev is not a good place to send messages like this. Please
> use [EMAIL PROTECTED] (I've already notified the appropriate
> parties.)
Before sending the message I thought, "let's see how much time it
takes until someone mentions the right place
On Sat, Jun 18, 2005, Gustavo Niemeyer wrote:
>
> PyPI seems to be out of space:
FYI, python-dev is not a good place to send messages like this. Please
use [EMAIL PROTECTED] (I've already notified the appropriate
parties.)
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft
PyPI seems to be out of space:
% ./setup.py register --show-response
running register
Using PyPI login from /home/niemeyer/.pypirc
---
Error...
There's been a problem with your request
psycopg.ProgrammingError: ERROR: could
[Raymond Hettinger]
> > > I recommend that the proposed syntax be altered to be more
parallel
> > > with the existing for-loop syntax to make it more parsable for
both
> > > humans and for the compiler.
[Michael Hudson]
> > Although all your suggestions are improvments, I'm still -1 on the
PEP.
On 6/18/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>
> > I recommend that the proposed syntax be altered to be more parallel
> > with the existing for-loop syntax to make it more parsable for both
> > humans and for the compiler.
>
> Although a
Why this discussion of yet another serialization format? The wire-encoding
for XML-RPC is quite stable, handles all the basic Python types proposed in
the proto-PEP, and is highly interoperable. If performance is an issue,
make sure you have a C-based accelerator module like sgmlop installed. I
[Raymond Hettinger]
> > I think it unwise to allow x to be any expression. Besides altering
> > existing semantics, it leads to code redundancy and to a fragile
> > construct (where the slightest alteration of any of the expressions
> > triggers a silent reversion to O(n) behavior).
[Gerrit Holl]
Hi,
Raymond Hettinger wrote:
> I think it unwise to allow x to be any expression. Besides altering
> existing semantics, it leads to code redundancy and to a fragile
> construct (where the slightest alteration of any of the expressions
> triggers a silent reversion to O(n) behavior).
What would
At 04:55 PM 6/18/2005 +0300, Oren Tirosh wrote:
>On 6/18/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
> > It turns out that making 'next(EXPR)' work is a bit tricky; I was going to
> > use METH_COEXIST and METH_VARARGS, but then it occurred
> The RFE suggests that "the protocol is specified in the documentation,
> precisely enough to write interoperating implementations in other
> languages". If interoperability with other languages is really the
> issue, use an existing format like JSON.
JSON is slow (this is true of the python vers
Please don't invent new serialization formats. I think we have enough
of those already.
The RFE suggests that "the protocol is specified in the documentation,
precisely enough to write interoperating implementations in other
languages". If interoperability with other languages is really the
issue,
Keith Dart <[EMAIL PROTECTED]> writes:
> I am very concernced about something. The following code breaks with 2.4.1:
>
> fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
>
> Where RTC_RD_TIME = 2149871625L
>
> In Python 2.3 it is -2145095671.
Well, you could always use "-2145095671"...
> Actually, thi
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I recommend that the proposed syntax be altered to be more parallel
> with the existing for-loop syntax to make it more parsable for both
> humans and for the compiler.
Although all your suggestions are improvments, I'm still -1 on the PEP.
Cheer
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> I've been looking at this area partly to try and understand this bug:
>>
>> [ 1163563 ] Sub threads execute in restricted mode
>>
>> but I'm not sure the whole idea of multiple interpreters isn't
>> inherently doomed :-
Josiah Carlson wrote:
> Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>
>> Maybe anonymus function closures should be pushed forward right now
not only syntactically? Personally I could live with lambda or several
>> of the alternative syntaxes listed on the wiki page.
>>
>
>
>
>
>> But as
Raymond Hettinger wrote:
> Also, I recommend tightening the PEP's motivation. There are only two
> advantages, encoding and readability. The former is only a minor gain
> because all it saves is a function call, an O(1) savings in an O(n)
> context. The latter is where the real benefits lay.
Th
Guido van Rossum wrote:
>On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>
>>IIRC, there was a decision to not implement phase C and to keep the
>>trailing L in representations of long integers.
>>
>>
>
>Actually, the PEP says phase C will be implemented in Python 3.0 and
>that's
I recommend that the proposed syntax be altered to be more parallel with
the existing for-loop syntax to make it more parsable for both humans
and for the compiler. Like existing for-statements, the target
expression should immediately follow the 'for' keyword. Since this is
known to be a range a
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Maybe anonymus function closures should be pushed forward right now not
> only syntactically? Personally I could live with lambda or several
> of the alternative syntaxes listed on the wiki page.
> But asking for a favourite syntax I would skip the "def"
Nick Coghlan wrote:
> Guido van Rossum wrote:
>
>>>Recommend accepting just the basic PEP which only targets simple,
>>>obvious cases. The discussed extensions are unattractive and should be
>>>skipped.
>>
>>
>>-1. The "unary colon" looks unPythonic to me.
>>
>
>
> Step 1 would be to require pa
43 matches
Mail list logo
