be checked by the master process.
>
> I don't recall the exploits that Samuele once posted that caused the
> death of rexec.py -- does anyone recall, or have a pointer to the
> threads?
It was broken by the introduction of new-style classes:
http://mail.python.
; I think you could add "update json package to reflect the current
>> simplejson
>> version" (see http://bugs.python.org/issue4136).
>
> Also, I'm expecting that ordered dictionaries will be ready:
> http://www.python.org/dev/peps/pep-0372/
Thanks. I
rt to the release PEP, mark
> fixing it as a maybe though - with the associated PEP not even written
> yet, I obviously still have some work to do to get the semantic change
> approved by Guido and the rest of python-dev.
Ok. I've added it.
--
Regards,
Benjamin
___
for forward-porting it
> (do I generate a new patch against the py3k branch, or should it be
> applied to trunk and merged in?)
Patches to the trunk are fine.
As for the actual feature, I don't think it should hold up releases.
--
Regards,
Benjamin
_
l...@python.org
--
Regards,
Benjamin
___
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
>
> Anything else that should be done?
Have you considered naming? I would think that "odict" or
"ordereddict" would be more consistent with other collections names
especially "defaultdict".
--
Regards,
Benjamin
___
P
a bit too chaotic already to make a fair decision here. If we
> seriously consider a C implementation it would probably be a good idea to call
> it `odict`. C-Classes are usually lower cased as far as I can see.
I don't implementation language should determine naming.
--
Regards,
Benja
should be able to be implemented in
any language transparently.
> It is clear and explicit in its intention and doesn't make you try to
> remember what the o in odict stands for.
I agree and that's why I propose "ordereddict"
--
Regards,
Benjamin
__
ing the release around 16:00 UTC.
--
Regards,
Benjamin
___
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
fine with the typed out name as well, but I still would prefer lowercase
> to
> stay consistent with defaultdict/dict.
+1
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
2009/3/3 Daniel (ajax) Diniz :
> Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug
> fixes[2] for 3.1. By 'nominate' I mean 'group related issues together,
> offer tests, docs, patches and/or reviews as needed and
> ask-pretty-please-for-inclusio
case the old names and simply subclass
> the new names and have no issues with old code.
Yes, I'm already looking forward to Py4k now. :)
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
ing to do is deprecate it in 3.1 for removal in 3.2.
--
Regards,
Benjamin
___
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
2009/3/4 Tennessee Leeuwenburg :
> On my local checkout I notice a number of failing tests (test_fileio
> test_grp test_io test_urllib2_localnet). Is there anything that I should
> attempt to do regarding these?
Try "svn up". Those should be fixed now.
--
based on large, complex
> 3rd party libraries, libxml2 and libxslt.
And it depends on Cython, which is wonderful normally, but maybe
difficult to deal with in language evolution since we wouldn't have
direct control over the C sources.
--
Regards,
Benjamin
___
more information and downloads, see the Python 3.1 website:
http://www.python.org/download/releases/3.1/
See PEP 375 for release schedule details:
http://www.python.org/dev/peps/pep-0361/
Enjoy,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire p
2009/3/7 Gerard Flanagan :
> Benjamin Peterson wrote:
> On the release page, the bzip link says '3.0' not '3.1'.
That should be fixed now.
>
>> See PEP 375 for release schedule details:
>>
>> http://www.python.org/dev/peps/pep-0361/
That URL i
2009/3/9 Terry Reedy :
> Benjamin Peterson wrote:
>>
>>> You might also want to collect a list of serious changes that you want
>>> in this release; I know I/O in C is on the list (and without it I
>>> wouldn't consider it worth releasing) but there
hon.org/issue4136
...and it's already on the PEP. :)
--
Regards,
Benjamin
___
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
portant, but quite "serious" enough to warrant inclusion
in the PEP. (and not a feature) If you'd like it to block the release,
you can set the priority to "release blocker."
--
Regards,
Benjamin
___
Python-Dev mailing list
Pytho
underscores and are not documented.
>
> Is there any problem with modifying these in 2.7 and 3.1? I assume not, but
> I want to make sure it doesn't give anyone heartburn.
Certainly sounds fine with me.
--
Regards,
Benjamin
___
Python-Dev
implementation on a Python
implementation because of extensive type checking, I would be tempted
to mark those tests as implementation details.
However, in the case of this specific issue, I think rejecting bytes
purposefully is good because it avoids programming errors.
--
Re
from stdlib references.
Thanks so much for doing this! Personally, I think you should put it
in the language reference. (I think it deserves it's own file if it's
as big as I suspect it will be.) If I wanted to use importlib, I
wouldn't really want to slog through a in-depth d
actual assignment. I've not yet seen good use cases for
> operator.isub() for example.
I thought the point of the operator module (unlike most modules) was
to provide a comprehensive set of Python operators as functions for
consistency even if there usefulness was questionable.
ng on the core is admirable, I think gsoc would provide an
opportunity to port important Python libraries to 3.x. It's important
to remember that doing ports helps the core immensely by uncovering
2to3 and py3k bugs.
--
Regards,
Benjamin
___
Python-Dev ma
tact info on the
> wiki so potential students can hash out the details with them before
> applying.
--
Regards,
Benjamin
___
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
ion period opens next
> week. All the mentors for PSF read and review them and we assign mentors to
> them (often whatever mentor the student worked with to build the proposal).
>
> Do you want prospective students contacting the list or the mentor they're
> interested in working wi
2009/3/18 Arc Riley :
> On Wed, Mar 18, 2009 at 6:13 PM, Brett Cannon wrote:
>>
>> I would double-check Benjamin can do this since I don't think he will be
>> 18 by the time GSoC starts. The FAQ at
>> http://socghop.appspot.com/document/show/program/google/
2009/3/18 Antoine Pitrou :
>
>> class C() to class C(object)
>
> __metaclass__ = type
Or even better: just inherit from object in 3.0 and 2.x. :)
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
It seems Andrew will be doing "What's new in Python 2.7?" again, but
we don't seem to have a volunteer to do the 3.1 version? Would anyone
like to volunteer?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
ht
out the docs in sys).
It would be nice to have at least the sys docs backported to the trunk.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
2009/3/23 Antoine Pitrou :
> Guilherme Polo gmail.com> writes:
>>
>> Any chance you were not using the latest svnmerge when you did that
>> merge ? I've had problems like this when using older versions.
>
> Well, actually, Benjamin did the merge, so perhaps he c
http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
not that different:
#!/bin/sh
/data/repos/projects/hooks/mailer.py commit "$@"
/data/repos/projects/hooks/svn_buildbot.py --repository "$1"
--revision "$2" --bbport 9020 > /dev/null
/data/repos/projects/hooks/svn_buildbot.py --repository "$1"
-
ght still be
>> interersted in the exception handling changes ("except Foo as exc")?
>
> Sure, that's easily possible: run 2to3 -f
> some_fixer,other_fixer,this_fixer,that_fixer. You can get a full list
> of fixers using the --list-fixes option.
In addition you can use
ore
> components.
FWIW, I think it is unfortunately too late to make this change. We've
already released it as lib2to3 in the standard library and I have
actually seen it used in other projects. (PythonScope, for example.)
--
Regards,
Benjamin
__
es to deal with encodings. Perhaps somebody
would like to sprint on it?
--
Regards,
Benjamin
___
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
be likely to be accepted?
Generally debugging doesn't require good performance, so this is
definitely low priority. However, if you can contribute it, I don't
have a problem with it.
--
Regards,
Benjamin
___
Python-Dev mailing li
2009/4/1 Guido van Rossum :
> Tracing has other uses besides debugging though.
The OP said he wished to implement a C trace function for bdb.
Wouldn't that make it only applicable to debugging?
--
Regards,
Benjamin
___
Python-Dev mailing lis
where near my areas of
expertise, so I'll leave resolution of them to the experts. :)
--
Regards,
Benjamin
___
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
m, no will to do it,
> or no manpower?
Python doesn't need any more builtin exceptions to clutter the
namespace. Besides, what's wrong with just checking the errno?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.or
imes disregard the hint and try to allocate memory
> incrementally (correct for rule #1 or #2). However, in another code path it
> will throw a MemoryError immediately based on the hint (correct for rule
> #3).
Perhaps Raymond can shed some light on these.
--
Regards,
Benjamin
___
.2. This is the layout I would suggest:
Modules/
_io/
_io.c
stringio.c
textio.c
etc
>
> (unless the FLUFL wants to chime in)
>
> Benjamin-makes-boring-decisions-easy'ly yrs,
>
> Antoine.
mad-with-power'ly yours,
Benjamin
_
o leave it as is:
> a) never change a running system
> b) flat is better than nested
It doesn't make sense, though, to have the 8 files that make up the
_io module scattered around in a directory with scores of other ones.
--
Regards,
Benjamin
_
ntal
>>> exercise
>>> to try and get rid of the above one ;-)
>>>
>>> Assuming it breaks no tests, would there be objection to me committing
>>> the
>>> above change to the Python 3 trunk?
>>
>> That's up to Benjamin. Personally, I live
http://www.python.org/dev/peps/pep-0375/
Regards,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
3.1's only beta is planned for May 2nd, so that means you have exactly
28 days to get the amazing 3.1 features you have planned checked into
the py3k branch. There will be absolutely no new features after the
beta is released.
--
Regards,
Ben
*has* been fully
> implemented, it just hasn't been tested very well?
No, only simple linear bytes are supported.
>
> If so, writing some things that attempt to use it in
> non-trivial ways would be a useful thing to do.
--
Regards,
Benjamin
___
gt; It seems a bit strange and unhelpful though. Should we change the
> implementation
> so that the argument to peek() becomes the upper bound to the number of bytes
> returned?
+1 That sounds more useful.
>
> Thanks for your advice,
--
Regards,
Benjamin
_
2009/4/5 Alexandre Vassalotti :
> Off the top of my head, the following is needed for a successful migration:
...
> - Update the release.py script.
I'll do this.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@pyth
e nice to know where and how exactly this is used.
Basically it contains released versions of packages that some parts of
Python depend on. For example, Sphinx dependencies to build the docs
reside their. A simple script that downloads a tarball and extracts it
seems more elegant.
--
Regards,
nly takes slightly
longer than an svn checkout for me, and it only needs to be done
occasionally, so I have no problem with including all the history.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
and release them as separate projects
> (retaining the PSF license). Should I remove them from both the Python 2.x
> and 3.x trunks?
+1 to removing some of the old unused stuff from those directories.
--
Regards,
Benjamin
___
Python-Dev maili
few days, so maybe you just need a make distclean.
--
Regards,
Benjamin
___
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
cost of the second lookup is negligible because
of caching, but PyObject_Hash needn't be called two times. He's
working on a patch later today.
--
Regards,
Benjamin
___
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
gt;
> Keep in mind that intern() is called fairly rarely, mostly
> only at module load time. It may not be worth attempting
> to speed it up.
That's very important, though, for a command line tool for bazaar.
Even a few fractions of a second can make a difference in u
coverage" or "nose integration" with a severe lack specific details.
Especially the nose plugin one seems like very little work. (Running
default nose in the test directory in fact works fairly well.)
Another small nit is that they should address Python 2.x, too.
--
Regards,
2009/4/11 Chris Withers :
> Actually, this was gone on the py3k branch already.
>
> I've committed the fix to trunk, is there anything else I need to do?
Since it's not in py3k, I think not.
--
Regards,
Benjamin
___
Python-Dev mail
xt day or so.
Cool. Will you use svnmerge.py to integrate the branch? After having
some odd behavior merging the io-c branch, suggest you just apply a
patch to the py3k branch,
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://
ess...I think this is a doc bug but I'm completely
> unsure what would be a good fix.
I've added a like to the io module in the see also section of the file
and directory systems.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-
n3' instead of python? Perhaps I should have just filed
> this as an issue, but I'm not confident of the state of the plan to move to
> python3 as the official executable name.
That sounds correct. Please file a bug report.
--
Regards,
Benjamin
___
2009/4/18 Nick Coghlan :
> Benjamin Peterson wrote:
>> 2009/4/18 Mitchell L Model :
>>> Some library files, such as pdb.py, begin with
>>> #!/usr/bin/env python
>>> In various discussions regarding some issues I submitted I was told that the
>>&
s for your work,
Benjamin
___
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
json input and output unicode should be applied.
2009/4/20 Benjamin Peterson :
> The first (and only) beta of 3.1 is scheduled for less than 2 weeks
> away, May 2nd, and is creeping onto the horizon. There are currently 6
> blockers:
--
Reg
2009/4/20 Barry Warsaw :
> On Apr 20, 2009, at 6:37 PM, Ned Deily wrote:
>
>> In article
>> <1afaf6160904201509g2f5e784ah34c728732ca9b...@mail.gmail.com>,
>> Benjamin Peterson wrote:
>>>
>>> I forgot one: [...]
>>
>> What about #5756
2009/4/20 Ned Deily :
> In article
> <1afaf6160904201509g2f5e784ah34c728732ca9b...@mail.gmail.com>,
> Benjamin Peterson wrote:
>> I forgot one: [...]
>
> What about #5756 - idle, pydoc, et al removed from 3.1?
I just bumped priority and left a commen
cross-platform on a VCS is a major PITA, and
> py3k is currently not helping the situation.
You're concerns are valid, but I don't see anything in the PEP about
removing the bytes APIs.
--
Regards,
Benjamin
___
Python-Dev mailing list
Pyt
ng I should do in the code to generate a warning? Any pointers to
> examples would be great.
You can use PyErr_WarnEx().
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
. And a partner os.fsdecode() for
> string->bytes. That will save a lot of wheel respoking and probably make
> it easier for people to think about this.
some_path.encode(sys.getfilesystemencoding())
--
Regards,
Benjamin
___
Python-Dev mailing li
None to mean:-)
Time machine!
http://docs.python.org/dev/py3k/library/sys.html#sys.setfilesystemencoding
--
Regards,
Benjamin
___
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
Hi everyone!
In the interest of letting Martin implement PEP 383 for 3.1, I am
deferring the release of the 3.1 beta until next Wednesday, May 6th.
Thank you,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
gt; A - Accepted proposal
> -> R - Rejected proposal
> W - Withdrawn proposal
> -> D - Deferred proposal
> F - Final proposal
> -> A - Active proposal
> -> D - Draft proposal
> -> R - Replaced proposal
Yes, that makes more sense. Would you li
> svn: Can't find a temporary directory: Internal error
I get that, too. In addition, I can't ssh to dinsdale.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
What's the status of yield from? There's still a small window open for
a patch to be checked into 3.1's branch. I haven't been following the
python-ideas threads, so I'm not sure if it's ready yet.
--
Regards,
Benjamin
_
of his proposal at the time) and
> finagle it for b2. One problem though is that Greg's code is based on
> 2.6...
I don't believe the compiler has changed between 2.6 and the trunk, so
a patch against the trunk would probably not be too hard. I volunteer
to review it if it
2009/5/3 Greg Ewing :
> Benjamin Peterson wrote:
>>
>> What's the status of yield from? There's still a small window open for
>> a patch to be checked into 3.1's branch. I haven't been following the
>> python-ideas threads, so I'm not sure if it&
Some of my messages appear not to have gotten through.
--
Regards,
Benjamin
___
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
bsite:
http://www.python.org/download/releases/3.1/
See PEP 375 for release schedule details:
http://www.python.org/dev/peps/pep-0375/
Enjoy,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's co
bsite:
http://www.python.org/download/releases/3.1/
See PEP 375 for release schedule details:
http://www.python.org/dev/peps/pep-0375/
Enjoy,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's co
LOAD_ATTR instructions for these, so it uses the normal
lookup. The only way I can see to fix this is add a new opcode which
uses _PyObject_LookupSpecial, but I don't think we really care this
much. Opinions?
--
Regards,
Benjamin
___
Python-Dev mailing
s not the way it should be.
--
Regards,
Benjamin
___
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
2009/5/8 Daniel Stutzbach :
> On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson
> wrote:
>>
>> I've know hit __enter__ and __exit__. The compiler
>> generates LOAD_ATTR instructions for these, so it uses the normal
>> lookup. The only way I can see to fix thi
2009/5/8 Daniel Stutzbach :
> On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson
> wrote:
>>
>> Normally special methods use slots of the PyTypeObject struct.
>> typeobject.c looks up all those methods on Python classes correctly.
>> In the case of __enter__ and __
2009/5/8 Terry Reedy :
> Benjamin Peterson wrote:
>>
>> 2009/5/8 Daniel Stutzbach :
>>>
>>> On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson
>>> wrote:
>>>>
>>>> Normally special methods use slots of the PyTypeObject stru
2009/5/9 Terry Reedy :
> Benjamin Peterson wrote:
>
>>>>> __reduce__
>>>>> __setstate__
>>>>> __reversed__
>>>>> __length_hint__
>>>>> __sizeof__
>
>> No, it's easier to just use _PyObject_LookupSpecia
, if it's a callable that begins with __ and ends with __, it's a
special method.
--
Regards,
Benjamin
___
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
ll code be
implementation-independent as much as possible from the original
authors? Do all all changes against the stdlib have to be run against
several implementations? Should we sprinkle if switches all over the
codebase for different implementations, or should new support files be
added
ific parts,
> even for cpython and cpython maintains it's own things outside of stdlib. This
> would be in line with what we discussed at pycon I think, please correct me if
> I'm wrong.
I was not present, but that's my impression, too.
--
Regards,
Benjamin
being able to change the implementation. :)
--
Regards,
Benjamin
___
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
2009/5/20 Stephen J. Turnbull :
> Benjamin Peterson writes:
> > 2009/5/20 :
> >
> > > I suspect it's not really germane to this discussion but if the
> > > incref/decref functions were defined as inline would that effectively be
> > > like using
I haven't gotten emails for any of the commits I've done in the last
12 hours or so.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
nload/releases/3.1/
See PEP 375 for release schedule details:
http://www.python.org/dev/peps/pep-0375/
Enjoy,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's co
2009/6/2 Guido van Rossum :
> Benjamin, what would be involved in removing it? I suppose there's the
> module itself, some unit tests, and some docs. (I'm not asking you to
> remove it yet -- but I'm asking to look into the consequences, so that
> we can be sure t
added. Based on what I've seen of this discussion so far, I
> think that cure would at this time be worse than the disease.
I don't think he's suggesting adding more process yet, just in the
diagnosis phase.
--
Regards,
Benjamin
___
is not a good place for a module pending
uncertain, future changes.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
ess for you and people you know).
Thanks very much for doing this!
The PEP should talk about tracker migration. ie. how to handle
specifying revisions on multiple clones if we choose that path.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@
gt;
> But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in
> code for 3.2. Following this policy it would mean a feature freeze on trunk
> for an indefinite period of time.
And that's what we want to avoid, so we are discussing 3.2.
--
Regards,
Python, not
>> pet projects.
>
> True. Comp.lang.python might be a better place.
Actually, I think the Python community might be better off if he went
to comp.lang.perl.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.
n.org/download/releases/3.1/
See PEP 375 for release schedule details:
http://www.python.org/dev/peps/pep-0375/
Enjoy,
-- Benjamin
Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team and 3.1's co
BytesIO and StringIO have a getvalue() method.
--
Regards,
Benjamin
___
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
501 - 600 of 1550 matches
Mail list logo
