Re: [Python-Dev] string representation of range in 3.0
Hi Greg, On Wed, Apr 16, 2008 at 03:34:44PM +1200, Greg Ewing wrote: > > That's why I proposed <0, 1, ..., 9> for repr(range(10)). > > My worry is that this will lead a newcomer into thinking > this is some kind of valid expression syntax. What about the less confusing and more readily generalizable: It would also be helpful IMHO to use this kind of repr for most built-in iterators and iterables, instead of their mosty-useless default repr. A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote: > What about the less confusing and more readily generalizable: > > > > It would also be helpful IMHO to use this kind of repr for most built-in > iterators and iterables, instead of their mosty-useless default repr. I quite like this. But as a non-beginner, I'll freely admit that my intuitions are suspect :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]
-On [20080415 23:37], Ralf Schmitt ([EMAIL PROTECTED]) wrote: >The documentation for mmap.flush does not even mention a return value. Fixed in revision 62359. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ With a nuclear fire of Love in our Hearts, rest easy baby, rest easy... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]
On Wed, Apr 16, 2008 at 2:58 PM, Jeroen Ruigrok van der Werven < [EMAIL PROTECTED]> wrote: > -On [20080415 23:37], Ralf Schmitt ([EMAIL PROTECTED]) wrote: > >The documentation for mmap.flush does not even mention a return value. > > Fixed in revision 62359. > I think documenting this insanity is just insane and doesn't help much. Anyway, you can now close http://bugs.python.org/issue2122 as wontfix. Regards, - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unreachable code in mmapmodule.c?
Reading through Modules/mmapmodule.c to work on some documentation I
encountered this:
24 #ifndef MS_WINDOWS
25 #define UNIX
26 #endif
536 #ifdef MS_WINDOWS
537 return PyInt_FromLong((long) FlushViewOfFile(self->data+offset,
siz e));
538 #elif defined(UNIX)
539 /* XXX semantics of return value? */
540 /* XXX flags for msync? */
541 if (-1 == msync(self->data + offset, size, MS_SYNC)) {
542 PyErr_SetFromErrno(mmap_module_error);
543 return NULL;
544 }
545 return PyInt_FromLong(0);
546 #else
547 PyErr_SetString(PyExc_ValueError, "flush not supported on this
syst em");
548 return NULL;
549 #endif
The #else will never be reached, unless I read it wrongly?
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Once sent from the Golden Hall...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]
-On [20080416 15:20], Ralf Schmitt ([EMAIL PROTECTED]) wrote: >I think documenting this insanity is just insane and doesn't help much. >Anyway, you can now close http://bugs.python.org/issue2122 as wontfix. Why? I added documentation for the current way. I was not aware of the other thread's mention of this issue. When your patch goes in --and looking at it it makes sense to me-- I can easily adjust the documentation to reflect the new state. :) I can understand your apparent frustration at not having gotten someone to look over your issue, but please: relax. I cannot make source changes, only documentation. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ A kiss is a lovely trick designed by nature to stop speech when words become superfluous... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]
On Wed, Apr 16, 2008 at 3:29 PM, Jeroen Ruigrok van der Werven < [EMAIL PROTECTED]> wrote: > -On [20080416 15:20], Ralf Schmitt ([EMAIL PROTECTED]) wrote: > >I think documenting this insanity is just insane and doesn't help much. > >Anyway, you can now close http://bugs.python.org/issue2122 as wontfix. > > Why? > I added documentation for the current way. I was not aware of the other > thread's mention of this issue. When your patch goes in --and looking at > it > it makes sense to me-- I can easily adjust the documentation to reflect > the > new state. :) > > I can understand your apparent frustration at not having gotten someone to > look over your issue, but please: relax. I cannot make source changes, > only > documentation. > ok. makes sense. sorry, if I offended you. Regards, - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Wed, 16 Apr 2008, Paul Moore wrote: > On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote: >> What about the less confusing and more readily generalizable: >> >> >> >> It would also be helpful IMHO to use this kind of repr for most built-in >> iterators and iterables, instead of their mosty-useless default repr. > > I quite like this. But as a non-beginner, I'll freely admit that my > intuitions are suspect :-) I like this too. For iterators, though, would you always show the next couple of elements? The values "contained in" the iterator will change as the iterator iterates. Alternatively, the representation could be "frozen" to reflect the values originally pending in the iterator, but then the representation wouldn't show anything about the current state of the iterator. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On 16-Apr-08, at 9:37 AM, Isaac Morland wrote: > On Wed, 16 Apr 2008, Paul Moore wrote: >> On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote: >>> What about the less confusing and more readily generalizable: >>> >>> >>> It would also be helpful IMHO to use this kind of repr for most >>> built-in >>> iterators and iterables, instead of their mosty-useless default >>> repr. >> >> I quite like this. But as a non-beginner, I'll freely admit that my >> intuitions are suspect :-) > > I like this too. For iterators, though, would you always show the > next > couple of elements? The values "contained in" the iterator will > change as > the iterator iterates. Alternatively, the representation could be > "frozen" to reflect the values originally pending in the iterator, but > then the representation wouldn't show anything about the current > state of > the iterator. So would you mean something like: , <__main__.Foo instance at 0x83620>, ...> Or maybe: , <__main__.Foo instance at 0x83620>, ... > While I agree in theory, I'm not sure I like the looks of it in practise. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
Isaac Morland wrote:
> On Wed, 16 Apr 2008, Paul Moore wrote:
>
>> On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote:
>>> What about the less confusing and more readily generalizable:
>>>
>>>
>>>
>>> It would also be helpful IMHO to use this kind of repr for most built-in
>>> iterators and iterables, instead of their mosty-useless default repr.
>> I quite like this. But as a non-beginner, I'll freely admit that my
>> intuitions are suspect :-)
>
> I like this too. For iterators, though, would you always show the next
> couple of elements? The values "contained in" the iterator will change as
> the iterator iterates. Alternatively, the representation could be
> "frozen" to reflect the values originally pending in the iterator, but
> then the representation wouldn't show anything about the current state of
> the iterator.
You can't write nice repr's for arbitrary iterators, or things like
enumerate and friends that can operate on arbitrary iterator, because
you have no way to get at the 'first few' and 'the last' value.
You can only have a nice representation like that for iterables like
range which have random access to the underlying values. Note that range
is NOT an iterator in Py3k as it has no __next__ method (the same hold
trues for xrange in 2.x).
However, it would be really nice if collections.dict_keys,
collections.dict_items and collections.dict_values could provide a nice
repr implementation that was the rough equivalent of:
def full_repr(self):
contents = ', '.join(map(repr, self))
return "<%s: {%s}>" % (self.__class__.__name__, contents)
>>> d = dict(a=1, b=2, c=3)
>>> d
{'a': 1, 'c': 3, 'b': 2}
>>> full_repr(d.keys())
""
>>> full_repr(d.values())
''
>>> full_repr(d.items())
""
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Apr 16, 2008, at 5:15 AM, Armin Rigo wrote: > Hi Greg, > > On Wed, Apr 16, 2008 at 03:34:44PM +1200, Greg Ewing wrote: >>> That's why I proposed <0, 1, ..., 9> for repr(range(10)). >> >> My worry is that this will lead a newcomer into thinking >> this is some kind of valid expression syntax. > > What about the less confusing and more readily generalizable: > > > > It would also be helpful IMHO to use this kind of repr for most > built-in > iterators and iterables, instead of their mosty-useless default repr. > I think this is a great compromise. It is much more helpful to the beginner than range(0,10). This would also be a very simple change to the patch I already made :-) I think it works nicely for the dict_keys, dict_values, and dict_items objects also as the student will see: This reinforces that they will be iterating over tuples, which is much more helpful than a hexadecimal address. Since ordering is not important for dictionary objects I wonder whether the ending value(s) are even needed or whether the first two are enough to help the student get an idea of what the object contains. Brad > > A bientot, > > Armin. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/bonelake%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
Isaac Morland wrote: > On Wed, 16 Apr 2008, Paul Moore wrote: > >> On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote: >>> What about the less confusing and more readily generalizable: >>> >>> >>> >>> It would also be helpful IMHO to use this kind of repr for most built-in >>> iterators and iterables, instead of their mosty-useless default repr. >> I quite like this. But as a non-beginner, I'll freely admit that my >> intuitions are suspect :-) > > I like this too. For iterators, though, would you always show the next > couple of elements? The values "contained in" the iterator will change as > the iterator iterates. Alternatively, the representation could be > "frozen" to reflect the values originally pending in the iterator, but > then the representation wouldn't show anything about the current state of > the iterator. > If you consume values from the iterator to display them in the repr() where do you then propose to store them until the application wants them, and how do you distinguish between "real" and "repr" consumption of the values? "The next couple of elements" is a dangerous thing to use unless you don't mind them disappearing. And the last one's right out - you;d end up storing lists anyway! regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Wed, Apr 16, 2008 at 3:15 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > What about the less confusing and more readily generalizable: > > > > It would also be helpful IMHO to use this kind of repr for most built-in > iterators and iterables, instead of their mosty-useless default repr. We can't do this for iterators, since you can't print the values without consuming the iterator. Printing something shouldn't have a side effect on it. But for iterables (e.g. dict views) it should work fine, and if others can agree with this I'd be happy to accept patches. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Wed, Apr 16, 2008 at 6:58 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > > If you consume values from the iterator to display them in the repr() > where do you then propose to store them until the application wants > them, and how do you distinguish between "real" and "repr" consumption > of the values? "The next couple of elements" is a dangerous thing to use > unless you don't mind them disappearing. Not only that, but you'd have no idea what the performance consequences of accessing the "next" object might be. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Wed, 16 Apr 2008, David Wolever wrote: > On 16-Apr-08, at 9:37 AM, Isaac Morland wrote: >> On Wed, 16 Apr 2008, Paul Moore wrote: >>> On 16/04/2008, Armin Rigo <[EMAIL PROTECTED]> wrote: What about the less confusing and more readily generalizable: It would also be helpful IMHO to use this kind of repr for most built-in iterators and iterables, instead of their mosty-useless default repr. >>> >>> I quite like this. But as a non-beginner, I'll freely admit that my >>> intuitions are suspect :-) >> >> I like this too. For iterators, though, would you always show the next >> couple of elements? The values "contained in" the iterator will change as >> the iterator iterates. Alternatively, the representation could be >> "frozen" to reflect the values originally pending in the iterator, but >> then the representation wouldn't show anything about the current state of >> the iterator. > So would you mean something like: > , <__main__.Foo instance > at 0x83620>, ...> > Or maybe: > , <__main__.Foo instance at > 0x83620>, ... > > > While I agree in theory, I'm not sure I like the looks of it in practise. I was mostly responding to what I saw as a suggestion to change the representation of existing iterators. It's been pointed out in a previous reply to my message that obtaining values from a general iterator for use in the representation is problematic at best, and in general I don't think it can be done in an acceptable fashion, because I can imagine code depending on values not being obtained from an iterator before they are explicitly requested by next(). We wouldn't want a call to __repr__() to change the operation of the iterator, so any idea to pull two values and store them somewhere isn't generally acceptable. For some specific iterators which have access to all the underlying information, an informative representation is possible and frequently feasible. My question simply concerned what it would look like. Would it show the next couple of items, or the first couple of items (or something else)? Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
Following on from the success of previous sprint/bugfix weekends and sprinting efforts at PyCon 2008, I'd like to propose the next two Global Python Sprint Weekends take place on the following dates: * May 10th-11th (four days after 2.6a3 and 3.0a5 are released) * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released) It seems there are a few of the Python User Groups keen on meeting up in person and sprinting collaboratively, akin to PyCon, which I highly recommend. I'd like to nominate Saturday across the board as the day for PUGs to meet up in person, with Sunday geared more towards an online collaboration day via IRC, where we can take care of all the little things that got in our way of coding on Saturday (like finalising/preparing/reviewing patches, updating tracker and documentation, writing tests ;-). For User Groups that are planning on meeting up to collaborate, please reply to this thread on python-dev@python.org and let every- one know your intentions! As is commonly the case, #python-dev on irc.freenode.net will be the place to be over the course of each sprint weekend; a large proportion of Python developers with commit access will be present, increasing the amount of eyes available to review and apply patches. For those that have an idea on areas they'd like to sprint on and want to look for other developers to rope in (or just to communicate plans in advance), please also feel free to jump on this thread via python-dev@ and indicate your intentions. For those that haven't the foggiest on what to work on, but would like to contribute, the bugs tracker at http://bugs.python.org is the best place to start. Register an account and start searching for issues that you'd be able to lend a hand with. All contributors that submit code patches or documentation updates will typically get listed in Misc/ACKS.txt; come September when the final release of 2.6 and 3.0 come about, you'll be able to point at the tarball or .msi and exclaim loudly ``I helped build that!'', and actually back it up with hard evidence ;-) Bring on the pizza and Red Bull! Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
Trent Nelson wrote: > Following on from the success of previous sprint/bugfix weekends and > sprinting efforts at PyCon 2008, I'd like to propose the next two > Global Python Sprint Weekends take place on the following dates: > > * May 10th-11th (four days after 2.6a3 and 3.0a5 are released) > * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released) > > It seems there are a few of the Python User Groups keen on meeting > up in person and sprinting collaboratively, akin to PyCon, which I > highly recommend. I'd like to nominate Saturday across the board > as the day for PUGs to meet up in person, with Sunday geared more > towards an online collaboration day via IRC, where we can take care > of all the little things that got in our way of coding on Saturday > (like finalising/preparing/reviewing patches, updating tracker and > documentation, writing tests ;-). > > For User Groups that are planning on meeting up to collaborate, > please reply to this thread on python-dev@python.org and let every- > one know your intentions! > > I should be able to help organise and attend the London contribution. Personally I'd like to work on the documentation changes / clean-up for the unittest module discussed recently. Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On Wed, Apr 16, 2008 at 3:15 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: | > What about the less confusing and more readily generalizable: | > | > | > | > It would also be helpful IMHO to use this kind of repr for most built-in | > iterators and iterables, instead of their mosty-useless default repr. | | We can't do this for iterators, since you can't print the values | without consuming the iterator. Printing something shouldn't have a | side effect on it. But for iterables (e.g. dict views) it should work | fine, and if others can agree with this I'd be happy to accept | patches. Assuming we are discussing the output of str() rather that repr(), I think we should give Armin's idea a try for iterables that don't get the full display (as with lists, etc) but can harmlessly produce some values. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
On Wed, Apr 16, 2008 at 1:16 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > | On Wed, Apr 16, 2008 at 3:15 AM, Armin Rigo <[EMAIL PROTECTED]> wrote: > | > What about the less confusing and more readily generalizable: > | > > | > > | > > | > It would also be helpful IMHO to use this kind of repr for most > built-in > | > iterators and iterables, instead of their mosty-useless default repr. > | > | We can't do this for iterators, since you can't print the values > | without consuming the iterator. Printing something shouldn't have a > | side effect on it. But for iterables (e.g. dict views) it should work > | fine, and if others can agree with this I'd be happy to accept > | patches. > > Assuming we are discussing the output of str() rather that repr(), > I think we should give Armin's idea a try for iterables that don't get the > full display > (as with lists, etc) but can harmlessly produce some values. Why only str()? Note that the interactive prompt uses repr() to display values. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on having EOFError inherit from EnvironmentError?
On Mon, Apr 14, 2008 at 7:11 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > But what operations raise EOFError? Surely you're not using > raw_input()? It's really only there for teaching. > > There are quite a few things in Lib/ that raise EOFError on their own. Most look like reasonable uses. ftplib's getline() is likely the one raising it such that it is ever seen when using urrlib2. nntplib, telnetlib, xdrlib, getpass, aifc, chunk, sunau, gzip, & mailbox also raise it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
Guido van Rossum schrieb: > Why only str()? Note that the interactive prompt uses repr() to display > values. Does py3k still use the tp_print slot for the interactive prompt? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
No, tp_print is dead, unless I am terribly mistaken. (We didn't remove the slot because that would require updating every single static type initializer.) On Wed, Apr 16, 2008 at 2:39 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > > Why only str()? Note that the interactive prompt uses repr() to display > > values. > > Does py3k still use the tp_print slot for the interactive prompt? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on having EOFError inherit from EnvironmentError?
Guido van Rossum wrote: > You are unique in demanding this. Really? Nobody else wants a convenient way to distinguish program bugs from exceptions caused by external factors? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thoughts on having EOFError inherit from EnvironmentError?
Guido van Rossum wrote: > You are unique in demanding this. I'm not asking for anything to be changed (I've already agreed that EOFError can stay the way it is), just pointing out what I think is a legitimate use for custom EnvironmentError subclasses. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
On Wed, Apr 16, 2008 at 10:51:53AM -0700, Trent Nelson wrote: > Following on from the success of previous sprint/bugfix weekends and > sprinting efforts at PyCon 2008, I'd like to propose the next two > Global Python Sprint Weekends take place on the following dates: A great idea; thanks for organizing this! I've updated the wiki page at http://wiki.python.org/moin/PythonBugDay, so people can link to it, and added a news item on www.python.org. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
I worked up prototype implementation for dict_keys, dict_values, and
dict_items
Here's an example of what the output looks like:
>>> x = {chr(i):i for i in range(68,90)}
>>> x.keys()
>>> x.values()
>>> x.items()
>>>
comments?
Are there other objects in this family that I should look at?
Brad
On Apr 16, 2008, at 5:30 PM, Guido van Rossum wrote:
No, tp_print is dead, unless I am terribly mistaken. (We didn't remove
the slot because that would require updating every single static type
initializer.)
On Wed, Apr 16, 2008 at 2:39 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:
Guido van Rossum schrieb:
Why only str()? Note that the interactive prompt uses repr() to
display values.
Does py3k still use the tp_print slot for the interactive prompt?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/bonelake%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
Brad Miller wrote: > I wouldn't include the word "object" in any of these. Everything in Python is an object, so it's just space-wasting noise. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string representation of range in 3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Why only str()? Note that the interactive prompt uses repr() to display values. I was under the impression that for range, you still wanted to maintain the distinction between an evalable and a friendly representation. If not, then ok, but I would then almost wonder whether to have both functions -- until I remember the reason for two versions of string representation and your proposal (which I approve of) for both a full and abbreviated rep for classes. | ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
