On Wed, 15 Feb 2006 18:57:26 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 2/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > So how about
>> > openbytes? This clearly links the resulting object with the bytes
>> > type, which is mutually reassuring.
>>
>> That
on 16.02.2006 06:59 Alex Martelli said the following:
> On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
>
>> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
>>
>>> Regarding open vs. opentext, I'm still not sure. I don't want to
>>> generalize from the openbytes precedent to openstr or
On 2/15/06, Arkadiusz Miskiewicz <[EMAIL PROTECTED]> wrote:
>
> Still few questions... one of developers/commiters reviews patch and commit
> it? Few developers has to review single patch?
One developer can review and commit a patch. Sometimes we request
more input from other developers or intere
Thomas Wouters <[EMAIL PROTECTED]> wrote:
>>> from __future__ import unicode_strings
>
>> Didn't we have a command-line option to do this? I believe it was
>> removed because nobody could see the point. (Or am I hallucinating?
>> After several days of non-stop discussing bytes that must be
>>
On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
> > On Wed, Feb 15, 2006 at 07:28:36PM +1000, Nick Coghlan wrote:
> >
> >> On the 'unusable AST' front, if AST transformation code creates illegal
> >> output, then the main thing is to raise an exception complaining about
I'm still catching up on the hundreds of python-dev messages from the
last couple of days, but a quick note first that I'm ok to do release
management for 2.5
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Brett Cannon wrote:
> >> One protects us from ending up with an unusable AST since
> >> the seralization can keep the original AST around and if the version
> >> passed back in from Python code is junk it can be tossed and
On 2/15/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 2/15/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> >
> > I haven't been following the AST stuff closely enough, but I'm not crazy
> > about putting access to this in the sys module. It seems like it
> > clutters that up with a name that will
On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
>
>> Regarding open vs. opentext, I'm still not sure. I don't want to
>> generalize from the openbytes precedent to openstr or openunicode
>> (especially since the former is wrong in 2.x
On 2/15/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
[SNIP]
> How about we arrange for some open space time at PyCon to discuss?
> Unfortunately, the compiler talk isn't until the last day and I can't
> stay for sprints. It would be better to have the talk, then the open
> space, then the sprint.
On 2/15/06, Alain Poirier <[EMAIL PROTECTED]> wrote:
> - isn't the current implementation of itertools.tee (cache of previous
> generated values) incompatible with the new possibility to feed a
> generator (PEP 342) ?
I'm not sure what you are referring to. What is the issue?
n
___
On 2/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> (is the xmlplus/xmlcore issue still an issue, btw?)
What issue are you talking about?
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On 2/15/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> I haven't been following the AST stuff closely enough, but I'm not crazy
> about putting access to this in the sys module. It seems like it
> clutters that up with a name that will be rarely used by the average
> Python programmer.
Agreed.
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
>
> > Also the pseudo-encodings ('hex',
> > 'rot13', 'zip', 'uu', etc.) generally scare me.
>
> I think these will have to cease being implemented as
> encodings in 3.0. They should really never have been
> in the first place.
I wo
On Wed, Feb 15, 2006, Bob Ippolito wrote:
> On Feb 15, 2006, at 6:35 PM, Aahz wrote:
>> On Tue, Feb 14, 2006, Guido van Rossum wrote:
>>>
>>> Anyway, I'm now convinced that bytes should act as an array of ints,
>>> where the ints are restricted to range(0, 256) but have type int.
>>
>> range(0, 255
Patch / Bug Summary
___
Patches : 399 open ( +8) / 3042 closed ( +4) / 3441 total (+12)
Bugs: 923 open ( +8) / 5553 closed (+13) / 6476 total (+21)
RFE : 209 open ( +0) / 198 closed ( +1) / 407 total ( +1)
New / Reopened Patches
__
urllib pr
Trent Mick wrote:
> On Windows you download an MSI (it ends up in your browser downloads
> folder), it starts the installation, and the end of the installation it
> starts the app for you.
Which then conveniently inserts a virus into my system.
No, thanks. (Okay up until that last bit, though.)
Jason Orendorff wrote:
> Also the pseudo-encodings ('hex',
> 'rot13', 'zip', 'uu', etc.) generally scare me.
I think these will have to cease being implemented as
encodings in 3.0. They should really never have been
in the first place.
--
Greg Ewing, Computer Science Dept, +---
Barry Warsaw wrote:
> If we go with two functions, I'd much rather hang them off of the file
> type object then add two new builtins. I really do think file.bytes()
> and file.text() (a.k.a. open.bytes() and open.text()) is better than
> opentext() or openbytes().
I'm worried about feeping creat
M.-A. Lemburg wrote:
> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
> renamed to str.openfile())
This seems wrong to me, because it creates an unnecessary
dependency of the bytes/str/unicode types on the file type.
These types should remain strictly focused on being just
containers
On 2/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So how about
> > openbytes? This clearly links the resulting object with the bytes
> > type, which is mutually reassuring.
>
> That looks quite nice.
>
> Another thought -- what is going to happen to os.open?
> Will it
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP number.
Also, there are probably silly typos, etc. Sorry.
Neil
PEP: XXX
Title:
On Feb 15, 2006, at 6:35 PM, Aahz wrote:
> On Tue, Feb 14, 2006, Guido van Rossum wrote:
>>
>> Anyway, I'm now convinced that bytes should act as an array of ints,
>> where the ints are restricted to range(0, 256) but have type int.
>
> range(0, 255)?
No, Guido was correct. range(0, 256) is [0,
On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote:
> On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
>
> > > from __future__ import unicode_strings
>
> > Didn't we have a command-line option to do this? I believe it was
> > removed because nobody could see the p
Guido van Rossum wrote:
> So how about
> openbytes? This clearly links the resulting object with the bytes
> type, which is mutually reassuring.
That looks quite nice.
Another thought -- what is going to happen to os.open?
Will it change to return bytes, or will there be a new
os.openbytes?
--
On Tue, Feb 14, 2006, Guido van Rossum wrote:
>
> Anyway, I'm now convinced that bytes should act as an array of ints,
> where the ints are restricted to range(0, 256) but have type int.
range(0, 255)?
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"19. A language
Greg Ewing wrote:
> I think you don't understand what an encoding is. Unicode
> strings don't *have* an encoding, because theyre not encoded!
> Encoding is what happens when you go from a unicode string
> to something else.
Ah.. ok, my mental picture was a bit off. I had this reversed somewhat.
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
> > from __future__ import unicode_strings
> Didn't we have a command-line option to do this? I believe it was
> removed because nobody could see the point. (Or am I hallucinating?
> After several days of non-stop discussing by
I don't think this message is on-topic for python-dev. There are lots
of great places to discuss the design of the python web site, but the
list for developers doesn't seem like a good place for it. Do we need
a different list for people to gripe^H^H^H^H^H discuss the web site?
Jeremy
On 2/15/0
On 2/15/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> I'm in the process of summarizing the dicussion on the bytes object
> and an idea just occured to me. Imagine that I want to write code
> that deals with strings and I want to be maximally compatible with
> P3k. It would be nice if I could
On Thu, 16 Feb 2006 00:36:35 + (UTC), Neil Schemenauer <[EMAIL PROTECTED]>
wrote:
>I'm in the process of summarizing the dicussion on the bytes object
>and an idea just occured to me. Imagine that I want to write code
>that deals with strings and I want to be maximally compatible with
>P3k.
On Thu, Feb 16, 2006, Fredrik Lundh wrote:
> Tim Parkin wrote:
>>
>> [...]
>
> no, you're not qualified. yet, someone gave you total control over the
> future of python.org, and there's no way to make you give it up, despite
> the fact that you're over a year late and the stuff you've delivered
On Wed, 15 Feb 2006 15:20:16 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I'm actually assuming to put this off until 2.6 anyway.
>
>On 2/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Thomas Wouters wrote:
>>
>> > > After reading some of the discussion, and seen some of the arguments,
I'm in the process of summarizing the dicussion on the bytes object
and an idea just occured to me. Imagine that I want to write code
that deals with strings and I want to be maximally compatible with
P3k. It would be nice if I could add:
from __future__ import unicode_strings
and have stri
On Thu, 2006-02-16 at 01:09 +0100, Fredrik Lundh wrote:
> (but will there be a 2.6? isn't it time to start hacking on 3.0?)
We know at least there will never be a 2.10, so I think we still have
time.
-Barry
signature.asc
Description: This is a digitally signed message part
__
Smith wrote:
> The problem with areclose(), however, is that it
> only solves one part of the problem that needs to be solved
> if two fp's *are* going to be compared: if you are going to
> check if a < b you would need to do something like
>
> not areclose(a,b) and a < b
No, no, no.
If
Guido wrote:
> I'm actually assuming to put this off until 2.6 anyway.
makes sense.
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Ron Adam wrote:
> I was presuming it would be done in C code and it will just need a
> pointer to the first byte, memchr(), and then read n bytes directly into
> a new memory range via memcpy().
If the object supports the buffer interface, it can be
done that way. But if not, it would seem to
Great! I'll mark the PEP as accepted. (Which doesn't mean you can't
update it if changes are found necessary.)
--Guido
On 2/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Just in case you haven't noticed, I just merged
> the ssize_t branch (PEP 353).
>
> If you have any corrections to the
I'm actually assuming to put this off until 2.6 anyway.
On 2/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > > After reading some of the discussion, and seen some of the arguments,
> > > I'm beginning to feel that we need working code to get this right.
> > >
> > > It
On 2/15/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> I'm intrigued by the encoding guessing techniques you envisage.
Don't hold your breath. *I* am not very interested in guessing
encodings -- I was just commenting on posts by others that mentioned
difficulties caused by this approach. My posit
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Anyway, we need a new PEP author who can take the current
> discussion and turn it into a coherent PEP.
I'm not sure that I have time to be the official champion. Right
now I'm spending some time to collect all the ideas presented in the
email message
Tim Parkin wrote:
> As for cutting edge, it's using twisted, restructured text, nevow, clean
> urls, xhtml, semantic markup, css2, interfaces, adaption, eggs, the path
> module, moinmoin, yaml (to avoid xml),
that's not cutting edge, that's buzzword bingo.
> something I don't think I would be qu
Fredrik Lundh wrote:
> Georg Brandl wrote:
>>If something like Fredrik's new doc system is adopted
>
> don't hold your breath, by the way. it's clear that the current PSF-sponsored
> site overhaul won't lead to anything remotely close to a best-of-breed python-
> powered site, and I'm beginning t
Guido van Rossum wrote:
> On 2/15/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
>> Forcing the programmer to be aware of encodings, also pushes the same
>> requirement onto the user (who is often the source of the text in question).
>>
>
> The programmer shouldn't have to be aware of encodings
Thomas Wouters wrote:
> > After reading some of the discussion, and seen some of the arguments,
> > I'm beginning to feel that we need working code to get this right.
> >
> > It would be nice if we could get a bytes() type into the first alpha, so
> > the design can get some real-world exposure in
On Wed, Feb 15, 2006 at 11:28:59PM +0100, Fredrik Lundh wrote:
> After reading some of the discussion, and seen some of the arguments,
> I'm beginning to feel that we need working code to get this right.
>
> It would be nice if we could get a bytes() type into the first alpha, so
> the design can
Guido van Rossum wrote:
> - it's probably too big to attempt to rush this into 2.5
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the
Just in case you haven't noticed, I just merged
the ssize_t branch (PEP 353).
If you have any corrections to the code to make which
you would consider bug fixes, just go ahead.
If you are uncertain how specific problems should be resolved,
feel free to ask.
If you think certain API changes shoul
Georg Brandl wrote:
> If something like Fredrik's new doc system is adopted
don't hold your breath, by the way. it's clear that the current PSF-sponsored
site overhaul won't lead to anything remotely close to a best-of-breed python-
powered site, and I'm beginning to think that I should spend my
We're all volunteers here, and we get a large volume of bugs.
Unfortunately, bugfixes are reviewed on a voluntary basis.
Are you aware of the standing offer that if you review 5 bugs/patches
some of the developers will pay attention to your bug/patch?
On 2/15/06, Arkadiusz Miskiewicz <[EMAIL PROT
On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
> Those are not pseudo-encodings, they are regular codecs.
>
> It's a common misunderstanding that codecs are only seen as serving
> the purpose of converting between Unicode and strings.
>
> The codec system is deliberately designed to be
Neal Norwitz wrote:
> Attached is the 2.5 release PEP 356. It's also available from:
> http://www.python.org/peps/pep-0356.html
>
> Does anyone have any comments? Is this good or bad? Feel free to
> send to me comments.
>
> We need to ensure that PEPs 308, 328, and 343 are implemented. We
>
On 2/15/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
> > Also the pseudo-encodings ('hex', 'rot13',
> > 'zip', 'uu', etc.) generally scare me.
>
> Those are not pseudo-encodings, they are regular codecs.
>
> It's a common misunderstanding that codecs are only seen as servin
Hi,
How bugfixes are handled?
I've posted a bug and a patch + test case for a quite common issue (see
google, problem mentioned on this ml) long time ago and nothing happened
with it
http://sourceforge.net/tracker/index.php?func=detail&aid=1380952&group_id=5470&atid=305470
Is anyone reviewing f
Thomas Wouters wrote:
> Although I've made it look like I have a working implementation, I haven't.
> I know exactly how to do it, though, except for the AST part ;) Once I
> figure out how to properly work with the AST code I'll probably write this
> patch whether it's a definite 'no' or not, just
On Wed, 2006-02-15 at 14:01 -0500, Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(),
> which works like this:
>
> # two equivalent things
> expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83,
Please, I don't much care about the fine points of the function's
semantics, but PLEASE rename that function to are_close. Every time I
see this subject in my email client I have to think for a few seconds
what the hell 'areclose' means. This time it's not just because of the
new PEP 8, 'areclo
On 2/15/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Well, I probably am, but that's not the reason. Reading has nothing
> to do with it.
Actually if you read binary data in text mode on Windows you also get
corrupt (and often truncated) data, unless you're lucky enough that
the binary data cont
Well, I probably am, but that's not the reason. Reading has nothing
to do with it.
The default mode (text) corrupts data on write on a certain platform
(Windows) by inserting extra bytes in the data stream. This bug
particularly exhibits itself when programs developed on Linux or Mac
OS X are th
On Wed, Feb 15, 2006 at 01:38:41PM -0500, Jim Jewett wrote:
> On 2/14/06, Neil Schemenauer wrote:
> > People could spell it bytes(s.encode('latin-1'))
>
> Guido wrote:
> > At the cost of an extra copying step.
>
> I asked:
> > ... why not just add some smarts to the bytes constructor?
>
> Guido
Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
> # two equivalent things
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227,
Martin v. Löwis wrote:
> > - is (c)ElementTree still planned for inclusion ?
>
> It is included already.
in the xml.etree package, in case someone's looking for it in the
usual place.
that is,
import xml.etree.ElementTree as ET
import xml.etree.cElementTree as ET
will work in any 2.5
Skip has mentioned in private email that he's not available to update
PEP 332. I've therefore rejected that PEP; the current ideas are
rather different so we might as well start a new PEP. Anyway, we need
a new PEP author who can take the current discussion and turn it into
a coherent PEP. I've tri
Georg Brandl wrote:
> If something like Fredrik's new doc system is adopted, it would be extremely
> convenient to refer someone to just
>
> docs.python.org/os.path.join
>
> without looking up how the page is actually named.
you could of course reserve a toplevel directory for that purpose; e.g.
On Tue, 14 Feb 2006 19:41:07 -0500, "Raymond Hettinger" <[EMAIL PROTECTED]>
wrote:
>[Guido van Rossum]
>> Somewhat controversial:
>>
>> - bytes("abc") == bytes(map(ord, "abc"))
>
>At first glance, this seems obvious and necessary, so if it's somewhat
>controversial, then I'm missing something.
Jeremy Hylton wrote:
> As I said in an earlier message, there's no need to have a separate
> domain to restrict queries to just the doc/current part of python.org.
> Just type
> "site:python.org/doc/current your query here"
>
> If there isn't any other rationale, maybe we can redirects
> docs.pyt
On 2/14/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Fred L. Drake, Jr. wrote:
>
> > The proper response in this case is often to re-start decoding
> > with the correct encoding, since some of the data extracted so far may have
> > been decoded incorrectly.
>
> If the protocol has been sensibly desi
Jeremy Hylton wrote:
> As I said in an earlier message, there's no need to have a separate
> domain to restrict queries to just the doc/current part of python.org.
> Just type
> "site:python.org/doc/current your query here"
>
> If there isn't any other rationale, maybe we can redirects
> docs.pyt
As I said in an earlier message, there's no need to have a separate
domain to restrict queries to just the doc/current part of python.org.
Just type
"site:python.org/doc/current your query here"
If there isn't any other rationale, maybe we can redirects
docs.python.org back to www.python.org?
Je
Guido van Rossum wrote:
> On 2/15/06, Tim Parkin <[EMAIL PROTECTED]> wrote:
>
>>Guido van Rossum wrote:
>>
>>>I have this worry too in the
>>>context of the python.org redesign; 301 permanent redirect is *not*
>>>going to help PageRank of the new page.)
>>Could you expand on why 301 redirects won'
On 2/15/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> The default behavior of the current open() in opening files as text is
> particularly grating.
Why? Are you perhaps one of those rare folks who read more binary data
than text?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
On 2/15/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> I've been thinking about generalization of the *args/**kwargs syntax for
> quite a while, and even though I'm pretty sure Guido (and many people) will
> consider it overgeneralization, I am finally going to suggest it. This whole
> idea is not
On 2/15/06, Tim Parkin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > (Now that I work for Google I realize more than ever before the
> > importance of keeping URLs stable; PageRank(tm) numbers don't get
> > transferred as quickly as contents. I have this worry too in the
> > context of
On Tue, 14 Feb 2006 15:13:25 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I'm about to send 6 or 8 replies to various salient messages in the
>PEP 332 revival thread. That's probably a sign that there's still a
>lot to be sorted out. In the mean time, to save you reading through
>all those
Jason Orendorff wrote:
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
This looks good, although it duplicates
expected_md5_hash = binascii.unhexlify('5c535024cac5199153e3834fe5c92e6a')
Regards,
Martin
___
Python-Dev mailing
[Greg Ewing wrote]
> It's not perfect, but it's still a lot better than the
> situation on any other unix I've seen so far.
Better than Unix, sure. But you *can* (and ActivePython does do) install
everything under:
/opt/$app_name/...
> > open DMG, don't run the app from here, drag it to your
Thomas Wouters wrote:
> I would personally prefer the AST validation to be a separate part of the
> compiler. It means the one or the other can be out of sync, but it also
> means it can be accessed directly (validating AST before sending it to the
> compiler) and the compiler (or CFG generator, or
Alain Poirier wrote:
> - is (c)ElementTree still planned for inclusion ?
It is included already.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote:
> Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
>> I'm disappointed that the various Linux distributions
>> still don't seem to have caught onto the very simple
>> idea of *not* scattering files all over the place when
>> installing something
Ron Adam <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Ron Adam wrote:
> >> b = bytes(0L) -> bytes([0,0,0,0])
> >
> > No, bytes(0L) --> TypeError because 0L doesn't implement
> > the iterator protocol or the buffer interface.
>
> It wouldn't need it if it was a direct C memory copy.
Y
Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
> # two equivalent things
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
I hope this will also be equivalent:
> expected_md5_hash = bytes.from_he
[Bob Ippolito wrote]
>...
> >/Library/Frameworks/Python.framework/...
> >/Applications/MacPython-2.4/... # just MacPython does this
>
> ActivePython doesn't install app bundles for IDLE or anything?
It does, but puts them under here instead:
/Library/Frameworks/Python.framework/Versi
On 2/15/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
># two equivalent things
>expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
>expected_md5_hash = bytes([92, 83,
Adam Olsen wrote:
> Making it an error to have 8-bit str literals in 2.x would help
> educate the user that they will change behavior in 3.0 and not be
> 8-bit str literals anymore.
You would like to ban string literals from the language? Remember:
all string literals are currently 8-bit (byte) st
Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106])
It's
> If we go with two functions, I'd much rather hang them off of the file
> type object then add two new builtins. I really do think file.bytes()
> and file.text() (a.k.a. open.bytes() and open.text()) is better than
> opentext() or openbytes().
+1.
The default behavior of the current open() in o
On 2/14/06, Neil Schemenauer wrote:
> People could spell it bytes(s.encode('latin-1'))
Guido wrote:
> At the cost of an extra copying step.
I asked:
> ... why not just add some smarts to the bytes constructor?
Guido wrote:
> ... the VM usually keeps an extra reference
> on the stack so the refc
On 2/15/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Barry Warsaw wrote:
> > On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> >
> >> Maybe a weird idea, but why not use static methods on the
> >> bytes and str type objects for this ?!
> >>
> >> E.g. bytes.openfile(...) and unicode.openfi
On Wed, 2006-02-15 at 19:02 +0100, M.-A. Lemburg wrote:
> Anyway, as long as we don't start adding openthis() and openthat()
> I guess I'm happy ;-)
Me too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
On Tue, 2006-02-14 at 21:24 -0800, Neal Norwitz wrote:
> We still need a release manager. No one has heard from Anthony. If
> he isn't interested is someone else interested in trying their hand at
> it? There are many changes necessary in PEP 101 because since the
> last release both python and
Barry Warsaw wrote:
> On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
>
>> Maybe a weird idea, but why not use static methods on the
>> bytes and str type objects for this ?!
>>
>> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
>> renamed to str.openfile())
>
> That's also not
On Wed, 2006-02-15 at 00:34 -0800, Brett Cannon wrote:
> I personally think we should choose an initial global access API to
> the AST as a starting API. I like the sys.ast_transformations idea
> since it is simple and gives enough access that whether read-only or
> read-write is allowed somethin
On Wed, Feb 15, 2006 at 10:29:38AM -0500, Jeremy Hylton wrote:
> Unfortunately, the compiler talk isn't until the last day and I can't
> stay for sprints. It would be better to have the talk, then the open
> space, then the sprint.
If you mean "Implementation of the Python Bytecode Compiler", tha
On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> Maybe a weird idea, but why not use static methods on the
> bytes and str type objects for this ?!
>
> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
> renamed to str.openfile())
That's also not a bad idea, but I'd leave off o
On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
> Regarding open vs. opentext, I'm still not sure. I don't want to
> generalize from the openbytes precedent to openstr or openunicode
> (especially since the former is wrong in 2.x and the latter is wrong
> in 3.0). I'm tempting to hold o
Guido van Rossum wrote:
> On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> If we went with longer names, a slight variation on the opentext/openbinary
>> idea would be to use opentext and opendata.
>
> After some thinking I don't like opendata any more -- often data is
> text, so the term is
On 2/15/06, Fuzzyman <[EMAIL PROTECTED]> wrote:
> Forcing the programmer to be aware of encodings, also pushes the same
> requirement onto the user (who is often the source of the text in question).
The programmer shouldn't have to be aware of encodings most of the
time -- it's the job of the I/O
On 2/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> If we went with longer names, a slight variation on the opentext/openbinary
> idea would be to use opentext and opendata.
After some thinking I don't like opendata any more -- often data is
text, so the term is wrong. openbinary is fine but lon
On Tue, 14 Feb 2006 15:14:07 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 2/14/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > As Phillip guessed, I was indeed thinking about introducing bytes()
>> > sooner than that, perhaps even in 2.5 (though I don't want
1 - 100 of 136 matches
Mail list logo
