Re: [Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
On 18 Jan 2008, 06:42:26, Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Thank you very much for the quick reply.
> >
> > I believe we have to close the file in order be able to read it in - in this
> > case to feed a unittest. I actually tried to read it in before closing it,
> > but (as I suspected) the data wasn't available.
> The mistake you made was to change the mode from the default "w+b". The
> following code works on both Windows and Linux:
>
> from tempfile import NamedTemporaryFile
> fid = NamedTemporaryFile(mode='w+b',
> suffix='.tmp',
> dir='.')
>
> fid.write('My temp file')
> fid.seek(0)
> data = fid.read()
> print data
> fid.close()
If you need to read the data by opening the file again (from unittest
code for example), then you need to call fid.flush() (no need for seeking).
Again, comp.lang.python, but I could not resist.
regards.
___
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] Initial Development
Hi, Apologies if it's not appropriate to send this email to the mailing list, however I am really really eager to contribute to the Python project (as a developer), and wondered whether anyone could advise me as to some entry-level tasks I could start out with. Thanks, Lorenzo Stoakes ___ 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] Initial Development
Lorenzo Stoakes wrote: > Apologies if it's not appropriate to send this email to the mailing > list, however I am really really eager to contribute to the Python > project (as a developer), and wondered whether anyone could advise me > as to some entry-level tasks I could start out with. We are having a bug day today. Please join us in #python-dev on irc.freenode.net 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
[Python-Dev] Is "0x" a valid token?
Python accepts 0x as an integer literal. Is this intended (the docs say otherwise, but int() and tokenize.py concur)? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Is "0x" a valid token?
On Jan 19, 2008 9:40 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Python accepts 0x as an integer literal. Is this intended (the docs > say otherwise, but int() and tokenize.py concur)? Definitely a bug. I see no use case for this. -- --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] Monkeypatching idioms -- elegant or ugly?
On 15 Jan 2008, at 15:37, Guido van Rossum wrote: > Second, a "metaclass" to add a number of methods (or other attributes) > to an existing class, using a convenient class notation: ... > class (): >__metaclass__ = monkeypatch_class >def (...): ... >def (...): ... >... In Objective-C it's perfectly common to extend existing classes using 'categories' and I have often found this idiom very useful. What is described here is basically categories for Python. I've implemented something like this before and I would be happy to see this added to the standard library and formalised. Nicko ___ 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] What to do for bytes in 2.6?
Guido van Rossum <[EMAIL PROTECTED]> wrote: > This may seem trivial (because we do all the work, and 2to3 just > leaves stuff alone), but having b"" and bytes as aliases for "" and > str in 2.6 would mean that we could write 2.6 code that correctly > expresses the use of binary data -- and we could use u"" and unicode > for code using text, and 2to3 would translate those to "" and str and > the code would be correct 3.0 text processing code. I like this solution because of its simplicity. Neil ___ 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] What to do for bytes in 2.6?
Neil Schemenauer wrote: > I like this solution because of its simplicity. I've implemented and submitted the feature yesterday: Python 2.6a0 (trunk:60048M, Jan 18 2008, 19:08:16) [GCC 4.2.1 (Ubuntu 4.2.1-5ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> b'a' 'a' >>> br'\a' '\\a' >>> bytes 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] What to do for bytes in 2.6?
Guido van Rossum <[EMAIL PROTECTED]> wrote: > bytes is an alias for str (not even a subclass) > b"" is an alias for "" One advantage of a subclass is that there could be a flag that warns about combining bytes and unicode data. For example, b"x" + u"y" would produce a warning. As someone who writes internationalized software, I would happly use both the byte designating syntax and the warning flag, even if I wasn't planning to move to Python 3. Neil ___ 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] Monkeypatching idioms -- elegant or ugly?
> In Objective-C it's perfectly common to extend existing classes using > 'categories' and I have often found this idiom very useful. What is > described here is basically categories for Python. I've implemented > something like this before and I would be happy to see this added to > the standard library and formalised. If they are like Smalltalk categories, then they are semantically different. For method categories, you group the methods by "functionality" or "purpose" or "intended audience", as the developer of a class. It is important that the category has a name, and the categories are part of the class' documentation. For monkey-patching classes, the grouping is "by application". The additional/changed methods are not written by the author of the class, but by the author of the application using the class. The name of the group is irrelevant, and the documentation (if any exists) documents it as an application-specific thing. In-between are the partial classes of C# and the way C classes get implemented: it is the implementor of the class who fragments the class into separate pieces of code, but not for the sake of the class clients, but for maintainability of the class itself (so that you can spread a large class over several source files). They use same implementation strategy; for integrating it into the standard library, I think the usage scenarios need to be considered more. I like to see all three scenarios supported; to support categories properly, you need to also have support in the reflection, in pydoc, and perhaps also in the online documentation (if standard library classes get split into categories). 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] What to do for bytes in 2.6?
On Jan 19, 2008 10:53 AM, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > Guido van Rossum <[EMAIL PROTECTED]> wrote: > > bytes is an alias for str (not even a subclass) > > b"" is an alias for "" > > One advantage of a subclass is that there could be a flag that warns > about combining bytes and unicode data. For example, b"x" + u"y" > would produce a warning. As someone who writes internationalized > software, I would happly use both the byte designating syntax and > the warning flag, even if I wasn't planning to move to Python 3. Yeah, that's what everybody thinks at first -- but the problem is that most of the time (in 2.6 anyway) the "bytes" object is something read from a socket, for example, not something created from a b"" literal. There is no way to know whether that return value means text or data (plenty of apps legitimately read text straight off a socket in 2.x), so the socket object can't return a bytes instance, and hence the warning won't trigger. Really, the pure aliasing solution is just about optimal in terms of bang per buck. :-) -- --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
[Python-Dev] Rational approximation methods
In the Rational class that I've recently checked into Python 2.6 (http://bugs.python.org/issue1682), it might be nice to provide a method that, given a particular rational number, returns a nearby number that's nicer in some way. I know of two reasonable behaviors for this operation. Since I don't know which is likely to be more useful, or even if either is useful enough to include in the first version of the module, I'm coming to you guys for advice. Both were implemented a while ago in http://svn.python.org/view/sandbox/trunk/rational/Rational.py?rev=40988&view=markup and are based on the continued fraction representation of the number (http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations). The first returns the closest rational whose denominator is less than a given integer. For discussion, we might call it .limit_denominator(), although I'm also looking for good names. This seems useful for computations in which you want to sacrifice some accuracy for speed. On the other hand, Decimal may fill the niche for fast-ish computation that surprises people less than float. The second returns the simplest rational within some distance. For instance, it'll prefer 22/7 over 333/106 if both are close enough. We might call it .simplest_within() for now. This seems useful for converting from float and displaying results to users, where we prefer readability over accuracy or have reason to believe that a simpler fraction might be more correct. What does the list think? Jeffrey ___ 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] Rational approximation methods
Jeffrey Yasskin wrote: > The second returns the simplest rational within some distance. For > instance, it'll prefer 22/7 over 333/106 if both are close enough. We > might call it .simplest_within() for now. This seems useful for > converting from float and displaying results to users, where we prefer > readability over accuracy or have reason to believe that a simpler > fraction might be more correct. You can use a mediant walk to get to two surrounding fractions w/ some limit, and then return the pair to let the caller choose. See http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52317 for an imperfect implementation. ___ 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] Bug Day outcome
Today's bug day was a great success. Experienced people like Georg, Facundo, and Gregory P. Smith participated, and we also had people who submitted their first patches, some of which got applied today, too. Hopefully we'll see those people again. As of this writing, 37 issues were closed today, leaving 1300 open. (I saved a search in Roundup to list the bugs closed today.) --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] Rational approximation methods
On Jan 19, 2008 3:06 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > In the Rational class that I've recently checked into Python 2.6 > (http://bugs.python.org/issue1682), it might be nice to provide a > method that, given a particular rational number, returns a nearby > number that's nicer in some way. I know of two reasonable behaviors > [...] > What does the list think? > I'm having trouble imagining a real use case for either of these methods. When I'm using Rational, it's almost certainly because I want exact arithmetic; if I'm getting results with huge denominators and numerators then either that's what I really want, or I probably shouldn't have been using Rational in the first place... The only semi-use case I see is providing some way for users to turn the float 1.1 into the rational 11/10, instead of Rational(2476979795053773L,2251799813685248L). So I'd say leave both these methods out for now---it would be easy enough to add them later if it turns out there's a real need. Just my 200/391 UK pennies :) Mark ___ 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] What to do for bytes in 2.6?
On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
>There is no way to know whether that return value means text or data
>(plenty of apps legitimately read text straight off a socket in 2.x),
IMHO, this is a stretch of the word "legitimately" ;-). If you're
reading from a socket, what you're getting are bytes, whether they're
represented by str() or bytes(); correct code in 2.x must currently do a
.decode("ascii") or .decode("charmap") to "legitimately" identify the
result as text of some kind.
Now, ad-hoc code with a fast and loose definition of "text" can still
read arrays of bytes off a socket without specifying an encoding and get
away with it, but that's because Python's unicode implementation has
thus far been very forgiving, not because the data is cleanly text yet.
Why can't we get that warning in -3 mode just the same from something
read from a socket and a b"" literal? I've written lots of code that
aggressively rejects str() instances as text, as well as unicode
instances as bytes, and that's in code that still supports 2.3 ;).
>Really, the pure aliasing solution is just about optimal in terms of
>bang per buck. :-)
Not that I'm particularly opposed to the aliasing solution, either. It
would still allow writing code that was perfectly useful in 2.6 as well
as 3.0, and it would avoid disturbing code that did checks of type("").
It would just remove an opportunity to get one potentially helpful
warning.
___
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] What to do for bytes in 2.6?
On Jan 19, 2008 5:54 PM, <[EMAIL PROTECTED]> wrote:
> On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
> >There is no way to know whether that return value means text or data
> >(plenty of apps legitimately read text straight off a socket in 2.x),
>
> IMHO, this is a stretch of the word "legitimately" ;-). If you're
> reading from a socket, what you're getting are bytes, whether they're
> represented by str() or bytes(); correct code in 2.x must currently do a
> .decode("ascii") or .decode("charmap") to "legitimately" identify the
> result as text of some kind.
>
> Now, ad-hoc code with a fast and loose definition of "text" can still
> read arrays of bytes off a socket without specifying an encoding and get
> away with it, but that's because Python's unicode implementation has
> thus far been very forgiving, not because the data is cleanly text yet.
I would say that depends on the application, and on arrangements that
client and server may have made off-line about the encoding.
In 2.x, text can legitimately be represented as str -- there's even
the locale module to further specify how it is to be interpreted as
characters.
Sure, this doesn't work for full unicode, and it doesn't work for all
protocols used with sockets, but claiming that only fast and loose
code ever uses str to represent text is quite far from reality -- this
would be saying that the locale module is only for quick and dirty
code, which just ain't so.
> Why can't we get that warning in -3 mode just the same from something
> read from a socket and a b"" literal?
If you really want this, please think through all the consequences,
and report back here. While I have a hunch that it'll end up giving
too many false positives and at the same time too many false
negatives, perhaps I haven't thought it through enough. But if you
really think this'll be important for you, I hope you'll be willing to
do at least some of the thinking.
I believe that a constraint should be that by default (without -3 or a
__future__ import) str and bytes should be the same thing. Or, another
way of looking at this, reads from binary files and reads from sockets
(and other similar things, like ctypes and mmap and the struct module,
for example) should return str instances, not instances of a str
subclass by default -- IMO returning a subclass is bound to break too
much code. (Remember that there is still *lots* of code out there that
uses "type(x) is types.StringType)" rather than "isinstance(x, str)",
and while I'd be happy to warn about that in -3 mode if we could, I
think it's unacceptable to break that in the default environment --
let it break in 3.0 instead.)
> I've written lots of code that
> aggressively rejects str() instances as text, as well as unicode
> instances as bytes, and that's in code that still supports 2.3 ;).
Yeah, well, but remember, while keeping you happy is high on my list
of priorities, it's not the only priority. :-)
> >Really, the pure aliasing solution is just about optimal in terms of
> >bang per buck. :-)
>
> Not that I'm particularly opposed to the aliasing solution, either. It
> would still allow writing code that was perfectly useful in 2.6 as well
> as 3.0, and it would avoid disturbing code that did checks of type("").
Right.
> It would just remove an opportunity to get one potentially helpful
> warning.
I worry that the warning wouldn't come often enough, and that too
often it would be unhelpful. There will inevitably be some stuff where
you just have to try to convert the code using 2to3 and try to run it
under 3.0 in order to see if it works. And there's also the concern of
those who want to use 2.6 because it offers 2.5 compatibility plus a
fair number of new features, but who aren't interested (yet) in moving
up to 3.0. I expect that Google will initially be in this category
too.
--
--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] Bug Day outcome
On Jan 19, 2008 5:14 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Today's bug day was a great success. Experienced people like Georg, > Facundo, and Gregory P. Smith participated, and we also had people who > submitted their first patches, some of which got applied today, too. > Hopefully we'll see those people again. > > As of this writing, 37 issues were closed today, leaving 1300 open. > (I saved a search in Roundup to list the bugs closed today.) Thanks Andrew, and everyone else who participated! I've been doing other things, but have seen the checkins go by and am very happy with the success of the day. To everyone who participated for the first time (raise your hand if you're not subscribed to python-dev yet :-) -- welcome, and I hope you'll be back for more! -- --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] What to do for bytes in 2.6?
On 04:26 am, [EMAIL PROTECTED] wrote:
On Jan 19, 2008 5:54 PM, <[EMAIL PROTECTED]> wrote:
On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
Starting with the most relevant bit before getting off into digressions
that may not interest most people:
Why can't we get that warning in -3 mode just the same from something
read from a socket and a b"" literal?
If you really want this, please think through all the consequences,
and report back here. While I have a hunch that it'll end up giving
too many false positives and at the same time too many false
negatives, perhaps I haven't thought it through enough. But if you
really think this'll be important for you, I hope you'll be willing to
do at least some of the thinking.
While I stand by my statement that unicode is the Right Way to do text
in python, this particular feature isn't really that important, and I
can see there are cases where it might cause problems or make life more
difficult. I suspect that I won't really know whether I want the
warning anyway before I've actually tried to port any nuanced, real
text-processing code to 3.0, and it looks like it's going to be a little
while before that happens. I suspect that if I do want the warning, it
would be a feature for 2.7, not 2.6, so I don't want to waste a lot of
everyone's time advocating for it.
Now for a nearly irrelevant digression (please feel free to stop reading
here):
Now, ad-hoc code with a fast and loose definition of "text" can still
read arrays of bytes off a socket without specifying an encoding and
get
away with it, but that's because Python's unicode implementation has
thus far been very forgiving, not because the data is cleanly text
yet.
I would say that depends on the application, and on arrangements that
client and server may have made off-line about the encoding.
I can see your point. I think it probably holds better on files and
streams than on sockets, though - please forgive me if I don't think
that server applications which require environment-dependent out-of-band
arrangements about locale are correct :).
In 2.x, text can legitimately be represented as str -- there's even
the locale module to further specify how it is to be interpreted as
characters.
I'm aware that this specific example is kind of a ridiculous stretch,
but it's the first one that came to mind. Consider
len(u'é'.encode('utf-8').rjust(5).decode('utf-8')). Of course
unicode.rjust() won't do the right thing in the case of surrogate pairs,
not to mention RTL text, but it still handles a lot more cases than
str.rjust(), since code points behave a lot more like characters than
code units do.
Sure, this doesn't work for full unicode, and it doesn't work for all
protocols used with sockets, but claiming that only fast and loose
code ever uses str to represent text is quite far from reality -- this
would be saying that the locale module is only for quick and dirty
code, which just ain't so.
It would definitely be overreaching to say all code that uses str is
quick and dirty. But I do think that it fits into one of two
categories: quick and dirty, or legacy. locale is an example of a
legacy case for which there is no replacement (that I'm aware of). Even
if I were writing a totally unicode-clean application, as far as I'm
aware, there's no common replacement for i.e. locale.currency().
Still, locale is limiting. It's ... uncomfortable to call
locale.currency() in a multi-user server process. It would be nice if
there were a replacement that completely separated encoding issues from
localization issues.
I believe that a constraint should be that by default (without -3 or a
__future__ import) str and bytes should be the same thing. Or, another
way of looking at this, reads from binary files and reads from sockets
(and other similar things, like ctypes and mmap and the struct module,
for example) should return str instances, not instances of a str
subclass by default -- IMO returning a subclass is bound to break too
much code. (Remember that there is still *lots* of code out there that
uses "type(x) is types.StringType)" rather than "isinstance(x, str)",
and while I'd be happy to warn about that in -3 mode if we could, I
think it's unacceptable to break that in the default environment --
let it break in 3.0 instead.)
I agree. But, it's precisely because this is so subtle that it would be
nice to have tools which would report warnings to help fix it.
*Certainly* by default, everywhere that's "str" in 2.5 should be "str"
in 2.6. Probably even in -3 mode, if the goal there is "warnings only".
However, the feature still strikes me as potentially useful while
porting. If I were going to advocate for it, though, it would be as a
separate option, e.g. "--separate-bytes-type". I say this as separate
from just trying to run the code on 3.0 to see what happens because it
seems like the most subtle and difficult aspect of the port to get
right; it would be nice
