Adam Olsen wrote:
> My assumption is these would become errors in 3.x. bytes(str) is only
> needed so you can do bytes(u"abc".encode('utf-8')) and have it work in
> 2.x and 3.x.
I think the proposal for bytes(seq) to mean bytes(map(ord, seq))
was meant to be valid for both 2.x and 3.x, on the gro
Greg Ewing wrote:
> If the protocol has been sensibly designed, that shouldn't
> happen, since everything up to the coding marker should
> be ascii (or some other protocol-defined initial coding).
XML, for one protocol, requires you to restart over. The
initial sequence could be UTF-16, or it coul
Neal Norwitz wrote:
> What do people think about that? There are still a lot of features we
> want to add. Is this ok with everyone? Do you think it's realistic?
My view on schedules is that they need to exist, whether they are
followed or not. So having one is orders of magnitude better than
h
Hi,
2 questions:
- is (c)ElementTree still planned for inclusion ?
- isn't the current implementation of itertools.tee (cache of previous
generated values) incompatible with the new possibility to feed a
generator (PEP 342) ?
Regards
Neal Norwitz a écrit :
> Attached is the 2.5 rele
Bob Ippolito wrote:
> ** The exception is scripts. Scripts go wherever --install-scripts=
> point to, and AFAIK there is no means to ensure that the scripts from
> one egg do not interfere with the scripts for another egg or anything
> else on the PATH. I'm also not sure what the uninstalla
As per Neal's prodding email, here is a thread to discuss where we
want to go with the C AST to Python stuff and what I think are the
core issues at the moment.
First issue is the ast-objects branch. Work is being done on it, but
it still leaks some references (Neal or Martin can correct me if I
On 2/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > (I wonder if maybe they should be an error in 2.x as well. Source
> > encoding is for unicode literals, not str literals.)
>
> Source encoding applies to the entire source code, including (byte)
> string literals, com
> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> James Y Knight wrote:
>> Nice and simple.
M> Albeit, too simple.
M> The above approach would basically remove the possibility to
M> easily create bytes() from literals in Py3k, since literals in
M> Py3k create U
Travis E. Oliphant wrote:
> 3) A new C-API function PyNumber_Index will be added with signature
>
>Py_ssize_t PyNumber_index (PyObject *obj)
>
There's a typo in the function name here. Other than that, the PEP looks
pretty much fine to me.
About the only other quibble is that it co
> We still need a release manager. No one has heard from Anthony.
It is the peak of the summer down here. Perhaps he is lucky enough
to be enjoying it away from computers for a while?
=Tony.Meyer
___
Python-Dev mailing list
Python-Dev@python.org
htt
Guido van Rossum wrote:
> If bytes support the buffer interface, we get another interesting
> issue -- regular expressions over bytes. Brr.
We already have that:
>>> import re, array
>>> re.search('\2', array.array('B', [1, 2, 3, 4])).group()
array('B', [2])
>>>
Not sure whether to bla
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 the
> original version used.
I don't understand why this is an issue. If Python code
Bob Ippolito wrote:
> On Feb 14, 2006, at 4:17 PM, Guido van Rossum wrote:
>> (Why would you even think about views here? They are evil.)
>
> I mention views because that's what numpy/Numeric/numarray/etc.
> do... It's certainly convenient at times to have that functionality,
> for example, t
On Tue, 14 Feb 2006 12:31:07 -0700, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
>On Mon, Feb 13, 2006 at 08:07:49PM -0800, Guido van Rossum wrote:
>> On 2/13/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
>> > "\x80".encode('latin-1')
>>
>> But in 2.5 we can't change that to return a bytes o
On Tue, Feb 14, 2006 at 09:32:09PM -0800, Bill Janssen wrote:
> We (the pythonmac-sig mailing list) seem to have converged (almost --
> still talking about the logo) on a new download page for MacPython, to
> replace the page currently at
> http://www.python.org/download/download_mac.html. The str
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 the
>> original version used.
>
> I don't understand why this
On Tue, Feb 14, 2006 at 09:58:46PM -0800, Neal Norwitz wrote:
> We need to ensure that PEPs 308, 328, and 343 are implemented. We
> have possible volunteers for 308 and 343, but not 328. Brett is doing
> 352 and Martin is doing 353.
I can volunteer for 328 if no one else wants it, I've messed w
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
> what's wrong with it. I believe that may need a change to the compiler
> whether the mo
Guido van Rossum wrote:
> But somehow I still like the 'open' verb. It has a long and rich
> tradition. And it also nicely conveys that it is a factory function
> which may return objects of different types (though similar in API)
> based upon either additional arguments (e.g. buffering) or the
> e
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 the python.org redesign; 301 permanent redirect is *not*
> g
Greg Ewing wrote:
> Ron Adam wrote:
>
>> My first impression and thoughts were: (and seems incorrect now)
>>
>> bytes(object) -> byte sequence of objects value
>>
>> Basically a "memory dump" of objects value.
>
> As I understand the current intentions, this is correct.
> The bytes constru
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
>> what's wrong with it. I believe that may need a change to
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 something dear to my heart, although I obviously would like
On 2/15/06, 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
On Wed, 15 Feb 2006 00:34:35 -0800
Brett Cannon <[EMAIL PROTECTED]> wrote:
> As per Neal's prodding email, here is a thread to discuss where we
> want to go with the C AST to Python stuff and what I think are the
> core issues at the moment.
>
> First issue is the ast-objects branch. Work is bei
> "Fred" == Fred L Drake, <[EMAIL PROTECTED]> writes:
Fred> On Tuesday 14 February 2006 22:34, Greg Ewing wrote:
>> Seems to me this is a case where you want to be able to change
>> encodings in the middle of reading the stream. You start off
>> reading the data as ascii, and
I am reluctantly posting here since this is of less intense interest than other
things being discussed right now, but this is related to the areclose proposal
that was discussed here recently.
The following discussion ends with things that python-dev might want to
consider in terms of adding a
Adam Olsen wrote:
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
+1 for two functions.
My choice would be open() for binary and opentext() for text. I don't
find that backwards at all: the text function is going to be more
different from the current open() function then th
[Smith]
> The following discussion ends with things that python-dev might want to
> consider in terms of adding a function that allows something other than the
> default 12- and 17-digit precision representations of numbers that str() and
> repr() give. Such a function (like nice(), perhaps name
> 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 something dear to my heart, although I obviously woul
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.
>
> MacOSX seems to be the only system so far that h
Thomas Wouters wrote:
>On Tue, Feb 14, 2006 at 09:32:09PM -0800, Bill Janssen wrote:
>
>
>>We (the pythonmac-sig mailing list) seem to have converged (almost --
>>still talking about the logo) on a new download page for MacPython, to
>>replace the page currently at
>>http://www.python.org/downlo
I am still -1 on the ast-objects branch. It adds a lot of boilerplate
code and its makes complicated what is now simple. I'll see if I can
get a rough cut of the marshal code ready today, so there will be a
complete implementation of my original plan.
I also think we should keep the transformati
On Wed, Feb 15, 2006, Thomas Wouters wrote:
>
> I can volunteer for 328 if no one else wants it, I've messed with the import
> mechanism before (and besides, it's fun.) I've also written an unfinished
> 308 implementation to get myself acquainted with the AST code more.
> 'Unfinished' means that it
On Feb 15, 2006, at 7:19 AM, Fuzzyman wrote:
> [snip..]
>
> I personally like the move towards all unicode strings, basically
> any text where you don't know the encoding used is 'random binary
> data'. This works fine, so long as you are in control of the text
> source. *However*, it leaves
A problem that I pointed out with the proposed areclose() function is that it
has within it a fp comparison. If such a function is to have greater utility,
it should allow the user to specify how significant to consider the computed
error. A natural extension of being able to tell if 2 fp number
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
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 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
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 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
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, 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 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
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 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
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 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 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
> 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
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
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
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,
[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
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
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
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
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/
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
[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
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
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
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 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, 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/)
_
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'
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
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
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.
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.
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
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
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,
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
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 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
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 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,
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 136 matches
Mail list logo
