Re: [Python-Dev] file(file)
Terry Reedy schrieb: > | > We should also consider the semantics in more detail. Should the seek > | > position be shared between the two objects? What about buffering? > | > | That's definitely the hard part. But it's somewhat similar to > | "normal" mutable objects which are (I think always, right?) shallow > | copied when used in a constructor. > > But why, in the normal case, do you want a copy? It seems to me that is > thefile is a file rather than a string, then that is what you want, and you > are asking for > 'thefile = file(thefile)' to work just as the iter statement does. Consider the use case presented before: def foo(thefile): if type(thefile) == str: thefile = open(thefile) Now, if thefile is already a file object, you won't have to close it because it came from somewhere else. If thefile is a string, you'll have to close it at the end. Now, if file(fileobject) would return another file object created by something like os.dup(), you can do def foo(thefile): try: thefile = file(thefile) (...) finally: thefile.close() Georg ___ 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] [Python-3000] Warning for 2.6 and greater
[EMAIL PROTECTED] writes: > On 10:12 am, [EMAIL PROTECTED] wrote: > >>For practical reasons (we have enough work to be getting on with) PyPy >>is more-or-less ignoring Python 2.5 at the moment. After funding and >>so on, when there's less pressure, maybe it will seem worth it. Not >>soon though. > > I think I know what you mean from previous conversations, but the > context of the question makes the answer ambiguous. Are you > ignoring 2.5 in favor of 2.4, or 3.0? In favour of 2.4 -- the one that exists now :) Cheers, mwh -- > It might get my attention if you'd spin around in your chair, > spoke in tongues, and puked jets of green goblin goo. I can arrange for this. ;-)-- Barry Warsaw & Fred Drake ___ 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] [Python-3000] Warning for 2.6 and greater
Anthony Baxter schrieb: > There's a couple of ways I see it - we could add a "-3" command line > flag to enable 3.x compat, or maybe a from __future__ statement. > Although the latter would be a global thing, which is different to > how all existing from __future__s work, so probably not good. Neither does really work: if some package is rewritten to expect .items() to be an iterator, one would have to turn on that -3 option if using that package. OTOH, some other package used at the same time might expect just the opposite. > I don't see a path forward that doesn't involve something painful, > so long as 3.0 is going to be the clean break. There would be if there was some version which already had .items as an iterator, but still supported .iteritems as well. Let's call that version 2.99. It would be compatible with 2.6, but also with 3.0. Regards, Martin ___ 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] [Python-3000] Warning for 2.6 and greater
[EMAIL PROTECTED] schrieb: > It would certainly be possible to have: > >from __future__ import items_is_iter > > be the same as: > >__py3k_compat_items_is_iter__ = True > > and have the 2.x series' items() method check the globals() of the > calling scope to identify the return value of items() in that particular > context. Why do you think that this would be that certainly possible? I cannot imagine an efficient implementation. Regards, Martin ___ 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] [Python-3000] Warning for 2.6 and greater
[EMAIL PROTECTED] schrieb: >>There will certainly be demand for an asynchronous server in 3.0, > > To flip the question around: there might be a demand for Twisted in 3.0, > but will there be a demand for 3.0 in Twisted? It might just be easier > for everyone concerned to just continue maintaining 2.x forever. I have > yet to see a reason why, other than continued maintenance, 3.0 would be > a preferable development platform. Eventually, continued maintenance *will* be a concern to your users. Maybe not at 3.0, but perhaps at 3.2. Regards, Martin ___ 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] file(file)
On 13/01/2007 1.37, Brett Cannon wrote: > For security reasons I might be asking for file's constructor to be > removed from the type for Python source code at some point (it can be > relocated to an extension module if desired). Isn't there the wrong list then? I can't see how this can ever happen in the 2.x serie... -- Giovanni Bajo ___ 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] updating Misc/NEWS
I've noticed a bunch of changes recently without corresponding items added to Misc/NEWS. Can everyone update NEWS especially when fixing bugs or adding new features?If you have made recent checkins, it would be great if you could go back and update Misc/NEWS if you missed it the first time. Thanks, n ___ 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] C standard io library, flush/read/write problem
The other night i was watching a google techtalk about python 3000 and
Guido mentioned some problems with the C standard io library.
In particular he highlighted an issue with switching between reading
and writing without flushing and the fact that it caused serious
errors. Not that i dont think its a good idea to write a new io
library, but I wondered if it was the same problem ive encounted.
It only happens on windows that i know off, but the fix is simple...
Assuming you have a hanlde to the file called "Handle" and a Flush()
method, the following logic for read and write will allow you to
detect and prevent the problem.
Add this to the Read() method before reading takes place:
if ( Handle && (Handle->_flag & _IORW) && (Handle->_flag & (_IOREAD |
_IOWRT)) == _IOWRT )
{
Flush();
Handle->_flag |= _IOREAD;
}
Add this to the Write() method before writing takes place:
if ( Handle && (Handle->_flag & _IORW) && (Handle->_flag & (_IOREAD |
_IOWRT)) == _IOREAD )
{
Flush();
Handle->_flag |= _IOWRT;
}
Emerson
___
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] IOError errno=514 in time.sleep(1)
I've been tracking down an issue with some code sporadically raising IOError with errno=514 on "time.sleep(1)". time.sleep() is implemented with the select() system call, and on Linux this is sporadically returning errno=514 (ERESTARTNOHAND). This is on 2.6.9, though I've heard reports of it happening through 2.6.17, and my review of the code indicates that 2.6.19.1 (the latest kernel) is probably also going to act the same. Now, the header file where ERESTARTNOHAND is defined says that user-space should never see this errno. Clearly, that's not as true as it could be. I'm going to ask the LKML for more information about whether this should make it to user-space, but thought I'd bring it up here as well. Some options we have: Do nothing. (I like this one :-) Catch and ignore 514. (Only on Linux? Far-reaching implications, I don't like this one). Use the libc sleep() call for integer time.sleep() values? No guarantee that libc sleep() doesn't use select, though I've seen indications that it might use alarm. I haven't looked at the libc source. Try to make time.sleep() smarter in the face of errnos. Maybe try the sleep multiple times, check time.time() before and after the sleep to do multiple sleeps. Could possibly even fail over to using /dev/rtc if select fails? In general I'm reluctant to suggest a Python fix to this, but it's fairly unexpected for time.sleep() to raise an exception... Thoughts? Sean -- I think the net needs some Viagra today. It's just not performing... -- Mike Loseke, 2000 Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ 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] [Python-3000] Warning for 2.6 and greater
On 08:19 am, [EMAIL PROTECTED] wrote: >Georg Brandl schrieb: >>> If Python 3.0 was simply a release which removed deprecated features, >>> there would clearly be no issue. I would update my code in advance of >>> the 3.0 release to not use any of those features being removed, and >>> I'm all set. But that's not what I'm hearing. Python 3 is both adding >>> new ways to do things, and removing the older way, in the same >>> version, with no overlap. This makes me very anxious. >> >> It has always been planned that in those cases that allow it, the new way to >> do >> it will be introduced in a 2.x release too, and the old way removed only in >> 3.x. > >What does that mean for the example James gave: if dict.items is going >to be an iterator in 3.0, what 2.x version can make it return an >iterator, when it currently returns a list? > >There simply can't be a 2.x version that *introduces* the new way, as it >is not merely a new API, but a changed API. The API isn't changed. It's just dependent on its execution context in a confusing way. That difference right now is being reflected as "2.x VM" vs. "3.0 VM" but there are other ways to reflect it more explicitly. It would certainly be possible to have: from __future__ import items_is_iter be the same as: __py3k_compat_items_is_iter__ = True and have the 2.x series' items() method check the globals() of the calling scope to identify the return value of items() in that particular context. If the actual data structures of module dictionaries and stack objects are too expensive there are other, similar things that could be done at the C level. This implementation strategy is just the obvious thing that occurred to me after maybe 2 minutes of consideration. I'm sure someone more familiar with the internals of Python could come up with something better. ___ 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] C standard io library, flush/read/write problem
Emerson Clarke schrieb: > Add this to the Read() method before reading takes place: If you don't submit it as a patch to sf.net/projects/python, it is likely to get ignored. Regards, Martin ___ 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] IOError errno=514 in time.sleep(1)
Sean Reifschneider schrieb: > In general I'm reluctant to suggest a Python fix to this, but it's fairly > unexpected for time.sleep() to raise an exception... > > Thoughts? Unless there is a reproducible test case, no action should be taken. Once there is a test case, the specific action to take will become clearer. Regards, Martin ___ 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] buglet in long("123\0", 10)
What's wrong with this session? :-)
Python 2.6a0 (trunk:53416, Jan 13 2007, 15:24:17)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> int('123\0')
Traceback (most recent call last):
File "", line 1, in
ValueError: null byte in argument for int()
>>> int('123\0', 10)
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for int() with base 10: '123\x00'
>>> long('123\0')
Traceback (most recent call last):
File "", line 1, in
ValueError: null byte in argument for long()
>>> long('123\0', 10)
123L
>>>
--
--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] buglet in long("123\0", 10)
Guido van Rossum wrote:
>>> long('123\0', 10)
> 123L
Interesting - long_new goes through PyNumber_Long if no explicit base is
provided. That does a pre-check for embedded NULLs in the input string.
With an explicit base, however, PyLong_FromString is called directly.
Since that API takes a char* string, it stops at the first embedded NULL:
>>> long('123\0003', 10)
123L
>>> long('123\00032', 10)
123L
So 'long_from_string' in abstract.c already has this problem solved -
the helper function just needs to be moved into longobject.c so it can
be used for explicit bases as well.
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
