Re: [Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?
On Fri, Feb 6, 2009 at 11:38 PM, Lisandro Dalcin wrote: > Done, http://bugs.python.org/issue5175 Thank you! Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] yield * (Re: Missing operator.call)
Guido van Rossum wrote: It would be way too confusing to have "a different form of call" with totally different semantics that nevertheless used the same *terminology* as is used for regular calls. I expect you're right, so I won't argue for calling it "call" any more. I'd still like to find a good name for it, though. The other important thing is that my proposed construct should be usable as an expression, and its value should be whatever is returned by the called generator when it exits. E.g. if we continue spelling it "yield *" for the moment, then def f(): v = yield *g() print v def g(): yield 42 return "spam" for x in f(): pass should end up printing "spam". Would you entertain the idea of a "yield *" expression with those semantics? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
On Sat, Feb 7, 2009 at 10:04 AM, Greg Ewing wrote: > def f(): >v = yield *g() >print v > > def g(): >yield 42 >return "spam" Function g violates the current limitation that generators can't return with a value. So can g only be used using "yield *" then, or would that limitation be removed? - Willem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are property descriptors intended to be immutable?
On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum wrote: > On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher wrote: >> ...because they're not quite :). Should I file this as a bug report? > > No, this is just how it works. I hope they aren't documented as immuable? Not that I know of :). But the individual properties of the descriptor are all read-only and that the implementations of setter, getter and deleter return new objects instead of mutating and returning the old descriptor. So it seemed a little odd that there was just one way remaining in which the object could be mutated. (I'm a recent convert to the joys of immutability. :) -- Curt Hagenlocher [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are property descriptors intended to be immutable?
On Sat, Feb 7, 2009 at 9:41 AM, Curt Hagenlocher wrote: > On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum wrote: >> On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher >> wrote: >>> ...because they're not quite :). Should I file this as a bug report? >> >> No, this is just how it works. I hope they aren't documented as immuable? > > Not that I know of :). But the individual properties of the > descriptor are all read-only and that the implementations of setter, > getter and deleter return new objects instead of mutating and > returning the old descriptor. So it seemed a little odd that there > was just one way remaining in which the object could be mutated. You're basically using an "API" that wasn't meant to be invoked directly. I don't particularly care that properties can be mutated, but I don't really care that they should be 100% immutable either. IMO it's enough that the APIs that exist to be used explicitly don't modify the property in place; getter and friends return a new object so that you can override or extend a property in a subclass, and there obviously you don't want to mutate the base class. In the balance I'd say that the "backdoor" you found is probably harmless, and perhaps someone can find a good use for it, so I'm disinclined to "fix" this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
We already have yield expressions and they mean something else... On Sat, Feb 7, 2009 at 1:04 AM, Greg Ewing wrote: > Guido van Rossum wrote: > >> It would be way too confusing to have "a different form of call" with >> totally different semantics that nevertheless used the same >> *terminology* as is used for regular calls. > > I expect you're right, so I won't argue for calling > it "call" any more. > > I'd still like to find a good name for it, though. > The other important thing is that my proposed construct > should be usable as an expression, and its value > should be whatever is returned by the called generator > when it exits. E.g. if we continue spelling it > "yield *" for the moment, then > > def f(): >v = yield *g() >print v > > def g(): >yield 42 >return "spam" > > for x in f(): >pass > > should end up printing "spam". > > Would you entertain the idea of a "yield *" expression > with those semantics? > > -- > Greg > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE reading IDLESTARTUP or PYTHONSTARTUP on restart
I have a small change (shown below) to PyShell.py in idlelib that
causes the subprocess interpreter to read IDLESTARTUP or
PYTHONSTARTUP each time it restarts. To me this would make IDLE much
more useful for myself and students I teach. It isn't quite clear
what behavior to install with the enabling patch, so I would like
some feedback before submitting it. The main question is:
Shouldn't IDLE always read IDLESTARTUP (if defined) or PYTHONSTARTUP
(if IDLESTARTUP is not defined and PYTHONSTARTUP is) when it starts
rather than that requiring a command-line switch as it does now? This
is the behavior of python, and I don't see why it should be any
different for IDLE. More importantly, there is no convenient way to
say "and read my startup file" when double-clicking the IDLE icon.
(I'm on a Mac. On Windows the -s switch could be added to an icon for
IDLE, but that's still awkward.)
Secondary questions;
If IDLE is changed to read a startup file, should the -s switch be
dropped altogether? If so, should a -q switch be added (as with
emacs) to start without loading the startup file? I think yes to both.
When the subprocess interpreter is restarted should it look in the
environment for the current values of IDLESTARTUP and PYTHONSTARTUP,
or should IDLE store those values in a property of the subprocess
interpreter when first started and have restart go directly to the
saved path even if the value of IDLESTARTUP or PYTHONSTARTUP has
changed since IDLE had been started. I think restart should go to the
path as it was when IDLE was started and ignore subsequent changes.
Or at least the reststart should notice the change and present a
dialog asking the user to choose between the old path and the new one.
The diff modifies PyShell by copying the four lines of code that load
IDLESTARTUP or PYTHONSTARTUP from where they appear in the initial
startup code and adding to where the subprocess interpreter writes
"RESTART" to the console.
@@ -434,6 +434,10 @@
console.write(halfbar + ' RESTART ' + halfbar)
console.text.mark_set("restart", "end-1c")
console.text.mark_gravity("restart", "left")
+filename = os.environ.get("IDLESTARTUP") or \
+ os.environ.get("PYTHONSTARTUP")
+if filename and os.path.isfile(filename):
+self.execfile(filename)
console.showprompt()
# restart subprocess debugger
if debug:___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
Willem Broekema wrote: Function g violates the current limitation that generators can't return with a value. So can g only be used using "yield *" then, or would that limitation be removed? The limitation would be removed, in the interests of making it easier to use generators as coroutines. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
All of this debate is moot without the foundation of a common library on which we would be building these coroutines. Any proposal of a specific coroutine syntax is worthless without a time and community tested coroutine implementation, which would be subject to the same rigerous inclusion requirements as any other 3rd party library. Only then, some time in the future, would any argument about a specific syntax be worth real consideration. Let's not jump the shark. On Sat, Feb 7, 2009 at 3:16 PM, Greg Ewing wrote: > Willem Broekema wrote: > >> Function g violates the current limitation that generators can't >> return with a value. So can g only be used using "yield *" then, or >> would that limitation be removed? > > The limitation would be removed, in the interests > of making it easier to use generators as coroutines. > > -- > Greg > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
Time to move to this to python-ideas, folks. On Sat, Feb 7, 2009 at 12:26 PM, Calvin Spealman wrote: > All of this debate is moot without the foundation of a common library > on which we would be building these coroutines. Any proposal of a > specific coroutine syntax is worthless without a time and community > tested coroutine implementation, which would be subject to the same > rigerous inclusion requirements as any other 3rd party library. Only > then, some time in the future, would any argument about a specific > syntax be worth real consideration. > > Let's not jump the shark. > > On Sat, Feb 7, 2009 at 3:16 PM, Greg Ewing > wrote: >> Willem Broekema wrote: >> >>> Function g violates the current limitation that generators can't >>> return with a value. So can g only be used using "yield *" then, or >>> would that limitation be removed? >> >> The limitation would be removed, in the interests >> of making it easier to use generators as coroutines. >> >> -- >> Greg >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com >> > > > > -- > Read my blog! I depend on your acceptance of my opinion! I am interesting! > http://techblog.ironfroggy.com/ > Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str() on memoryview of bytearray failing on py3k
Hi all, I'm not sure if the following is a bug I should report or simply an artifact of the implementation and/or simply the way things work on py3k: % py30 -c "str(memoryview(bytearray((1,2,3" Traceback (most recent call last): File "", line 1, in TypeError: __str__ returned non-string (type bytes) Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str() on memoryview of bytearray failing on py3k
Mark Hammond gmail.com> writes: > >I'm not sure if the following is a bug I should report or simply an > artifact of the implementation and/or simply the way things work on py3k: > [...] It's a bug. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
Guido van Rossum wrote: We already have yield expressions and they mean something else... They don't have a "*" in them, though, and I don't think the existing meaning of yield as an expression would carry over into the "yield *" variant, so there shouldn't be any conflict. But if you think there will be a conflict, or that the similarity would be too confusing, maybe the new construct should be called something else. I'm open to suggestions. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] yield * (Re: Missing operator.call)
On 01:00 am, [email protected] wrote: Guido van Rossum wrote: We already have yield expressions and they mean something else... They don't have a "*" in them, though, and I don't think the existing meaning of yield as an expression would carry over into the "yield *" variant, so there shouldn't be any conflict. But if you think there will be a conflict, or that the similarity would be too confusing, maybe the new construct should be called something else. I'm open to suggestions. I'm *already* regretting poking my head into this particular bike shed, but... has anyone considered the syntax 'yield from iterable'? i.e. def foo(): yield 1 yield 2 def bar(): yield from foo() yield from foo() list(bar()) -> [1, 2, 1, 2] I suggest this because (1) it's already what I say when I see the 'for' construct, i.e. "foo then *yield*s all results *from* bar", and (2) no new keywords are required. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str() on memoryview of bytearray failing on py3k
On 8/02/2009 10:21 AM, Antoine Pitrou wrote: Mark Hammond gmail.com> writes: I'm not sure if the following is a bug I should report or simply an artifact of the implementation and/or simply the way things work on py3k: [...] It's a bug. http://bugs.python.org/issue5182 Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
