Guido van Rossum schrieb:
Good catches.
On Thu, Dec 4, 2008 at 3:29 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
os.getcwdu() returns the current working directory as a bytes instance
getcwdb(), I suppose?
New binary literals, e.g.
Josiah Carlson schrieb:
On Sat, Nov 22, 2008 at 4:18 PM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Josiah Carlson josiah.carlson at gmail.com writes:
From what I understand of the memoryview when I tried to do the same
thing a few months ago (use memoryview to replace buffer in
Victor Stinner schrieb:
Le Monday 29 September 2008 18:45:28 Georg Brandl, vous avez écrit :
If I had to choose, I'd still argue for the modified UTF-8 as filesystem
encoding (if it were UTF-8 otherwise), despite possible surprises when a
such-encoded filename escapes from Python.
If I
Victor Stinner schrieb:
Hi,
After reading the previous discussion, here is new proposition.
Python 2.x and Windows are not affected by this issue. Only Python3 on POSIX
(eg. Linux or *BSD) is affected.
Some system are broken, but Python have to be able to open/copy/move/remove
files
Guido van Rossum schrieb:
On Tue, Sep 30, 2008 at 11:13 AM, Georg Brandl [EMAIL PROTECTED] wrote:
Victor Stinner schrieb:
On Windows, we might reject bytes filenames for all file operations: open(),
unlink(), os.path.join(), etc. (raise a TypeError or UnicodeError)
Since I've seen
Anand Balachandran Pillai schrieb:
Try this in Python 3.0 trunk.
import zlib
s='This is a string'
sc=zlib.compress(s)
sc
bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
zlib.decompress(sc)
bytearray(b'This is a string')
This is wrong behavior as
Georg Brandl schrieb:
Someone just wrote to the docs mailing list and reported that the itertools
documentation for Py3k contains this recipe:
def grouper(n, iterable, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(*args, fillvalue=fillvalue)
It is currently a syntax
There are some accepted PEPs that are, AFAIK, fully implemented.
There shouldn't be much work left to bring them to final state:
* 358 -- bytes object
* 370 -- per-user site-packages directory
* 371 -- multiprocessing
* 3101 -- adv. string formatting
* 3106 -- dict.keys() etc.
* 3116 -- new
In a debug-build 3k, do this (32-bit machine):
Python 3.0b2+ (py3k:65171M, Jul 21 2008, 20:08:20)
[GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
Type help, copyright, credits or license for more information.
a*10
instinstTraceback (most recent call last):
File stdin, line 1, in module
Someone just wrote to the docs mailing list and reported that the itertools
documentation for Py3k contains this recipe:
def grouper(n, iterable, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(*args, fillvalue=fillvalue)
It is currently a syntax error in 3k. There's
Barry Warsaw schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wow, I bet this one crept up on you as quickly as it did me!
We have our second planned beta releases for 2.6 and 3.0 tomorrow. As
usual I will start looking at blockers and buildbots tomorrow
afternoon (UTC-4 time) with
nirinA raseliarison schrieb:
why the following behavior:
b=b'thisisbytes'
b[0] == b't'
False
b[0]
116
i expected same thing as:
b.startswith(b't')
True
b[0:1] == b't'
True
b[0:1]
b't'
b[:1]
b't'
and this is a bit curious:
Antoine Pitrou schrieb:
3) Optional question: should be harmonize traceback formatting between built-in
reporting and reporting through traceback.py? Right now there is a small
discrepancy in code lines indentation, see:
With built-in reporting:
Traceback (most recent call last):
File
Guido van Rossum schrieb:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get
Antoine Pitrou schrieb:
Hi,
Georg Brandl g.brandl at gmx.net writes:
I would argue that the __enter__ and __exit__ behavior should be changed too.
The reason for the current behavior is this:
[...]
IOW, when with is compiled, the attributes are retrieved using bytecode.
It wouldn't
Guido van Rossum schrieb:
On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/6/13 Barry Warsaw [EMAIL PROTECTED]:
My proposal is this: I will spin another release this coming Wednesday, June
18. If we can get both the 2.6 and 3.0 buildbots green by then, and close
Guido van Rossum schrieb:
On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running
Nick Coghlan schrieb:
2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
the instance dictionary MAY have ill effects. (slots such as __enter__
and __exit__ that are looked up via normal attribute lookup in CPython
will fit into this category)
I would argue that the
Fixed in r64010. Thanks!
Georg
Carl Johnson schrieb:
Currently it states:
To solve these and similar dilemmas, the next section will propose
a metaclass for use with ABCs that will allow us to add an ABC as a
virtual base class (not the same concept as in C++) to any class,
including to
Amaury Forgeot d'Arc schrieb:
It seems that there are two problems here:
- First, there is a bug in the sys.flags structure: revision 62322
added a new flag in the underlying C structure, but did not increase
the number of fields visible from python code. This should be
corrected: in
Guido van Rossum schrieb:
On Mon, Jun 2, 2008 at 5:00 PM, Giovanni Bajo [EMAIL PROTECTED] wrote:
Python 3.0 defaults to -tt (error on inconsistent usage of tab and
spaces). Then: why is there still a -t and -tt command line option?
Is just a relic that should be removed?
Probably. Though
Stefan Behnel schrieb:
Hi,
I currently use a bunch of work-arounds for doctests in lxml's test suite to
make them work in Py3. I converted most tests to a mix of Py2 and Py3 syntax
(e.g. using both u'' and b'' literals), and most of the runtime work is done
using regular expressions that
Brett Cannon schrieb:
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then
again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Fred had the interesting suggestion of removing pydoc in Py3K based on
the thinking that
Hi,
Python 3.0's urllib.quote() and unquote() handle non-ASCII data strangely.
quote() encodes characters with codepoint 256 using latin-1, but others
using utf-8. unquote() decodes everything using latin-1.
Is the correct behavior to always use utf-8?
Georg
--
Thus spake the Lord: Thou
Hi,
there still is a plat-mac directory in Lib (though it's empty), and several
places in the tree refer to it. Also, quite a few libs/scripts/tools in the
Mac subdir refer to modules that were removed in Python 3.
Some Mac head will need to do some additional cleanup before final release
(I'd
Stefan Behnel schrieb:
Christian Heimes wrote:
Stefan Behnel schrieb:
M.-A. Lemburg wrote:
If you use PyBytes APIs, you expect to find PyBytes functions in
the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
In
Guido van Rossum schrieb:
On Sun, May 25, 2008 at 3:08 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Sun, May 25, 2008 at 12:21 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Hi,
I'll handle the PEP 3108 dbm package if nobody else is already at it.
I know I have not started the work.
Two
Guido van Rossum schrieb:
Or is there an expected future use case where the returned value would
be something in a *different* package?
There was in the past, with the now-defunct bsddb185 module which was
not used by anydbm.
Returning a module object would seem the least attractive version
Hi,
I'll handle the PEP 3108 dbm package if nobody else is already at it.
Two questions though:
* the whichdb() function returns strings that are module names. These
names won't be importable anymore in 3k. Should the return values
remain the same in 3k, or should whichdb() return the
paul bedaride schrieb:
I see the peps 3115 and 3129 about metaclass and class decorators.
I think that the pep 3129 need to be improved for show the way to declare
the decorator and not just the way to appy them.
I also wonder if we need this two things, and if that is not two way to
explain
M.-A. Lemburg schrieb:
On 2008-05-09 18:06, Guido van Rossum wrote:
On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-05-08 22:55, Terry Reedy wrote:
Functions that map unicode-unicode or bytes-bytes could be called
transcoders. Each type could be given a
The CGI module has some classes that are marked as backwards compatibility
only. They are not formally deprecated in the docs, but this can be done
for 2.6. Should we remove them in 3.0?
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number
Done in r63099.
Georg
Guido van Rossum schrieb:
+1
On 5/11/08, Georg Brandl [EMAIL PROTECTED] wrote:
The CGI module has some classes that are marked as backwards compatibility
only. They are not formally deprecated in the docs, but this can be done
for 2.6. Should we remove them in 3.0
Terry Reedy schrieb:
Given that we cannot depend on timely mail/news propagation or on exact
day-ahead scheduling of a freeze, a current freeze notice either from the
repository or on a .../dev/status page might work better.
Nobody is going to look at such a page before making a commit :)
Barry Warsaw schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 8, 2008, at 8:21 AM, Christian Heimes wrote:
Barry Warsaw schrieb:
This is exactly what I'm thinking about!
-1
A technical solution never solves a social problem. It's just going to
cause more social and technical
Guido van Rossum schrieb:
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl [EMAIL PROTECTED] wrote:
But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really
Brett Cannon schrieb:
[bcc to stdlib-sig]
After two false starts over the YEARS of trying to cleanup and
reorganize the stdlib, creating a SIG to get this going, having Guido
give the PEP the once-over over the past several days, and creating
two new bugs reports (issues 2715 and 2716), PEP
Humberto Diogenes schrieb:
Hi,
I started working on this ticket but I'm going to need some
clarifications, it's called Adapt pydoc to new doc system and says
only so that this doesn't get lost:
http://bugs.python.org/issue1883
Can someone give more directions on what really needs
Benjamin Peterson schrieb:
On Sat, Apr 26, 2008 at 1:49 PM, Facundo Batista
[EMAIL PROTECTED] wrote:
Which should the range() definition be, in your words?
A set of integers from start to stop skipping step.
[ ... ]
Set is definitely misleading -- it has no ordering.
Georg
--
Thus spake
Steven Bethard schrieb:
On Sat, Apr 12, 2008 at 8:26 AM, [EMAIL PROTECTED] wrote:
Nick That's exactly the problem though - while a 2to3 fixer can be
Nick written for a tiny subset of formatting calls (those that meet the
Nick constraints you gave)...
In my personal experience,
Anand Balachandran Pillai schrieb:
Still this seems like a bad thing to break backward compatibility with.
However I cannot really provide a use-case apart from what Benjamin
has said - Teaching. It is not a common use-case to equate ranges
in code and that is bad coding anyway.
Hopefully,
Guido van Rossum schrieb:
On Wed, Apr 2, 2008 at 3:03 PM, Amaury Forgeot d'Arc [EMAIL PROTECTED]
wrote:
On Wed, Apr 2, 2008 at 11:57 PM, Paul Prescod [EMAIL PROTECTED] wrote:
But does anyone else find it odd that the types of some things are
classes and the classes of some things are
Olivier Verdier schrieb:
On 26/03/2008, *Nick Coghlan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I think if I come across a keyword I didn't know in a language I was
learning, I'd look it up to find out what it means.
Yes but it doesn't look like a keyword, does
Thomas Heller schrieb:
Neal Norwitz schrieb:
The next releases of 2.6/3.0 are planned for April 2, just over a week
from now. There is much work that needs to be done. The buildbots
are in a pretty sad state and the gods are seeing too much red.
Benjamin Peterson schrieb:
Guido once said that he hadn't found a better name. Well, I think
that almost *any* name will do better! ;-) Especially a name that
emphasizes the fact that lambda construction are in fact functions.
This is what Guido repeats over and over again:
Amaury Forgeot d'Arc schrieb:
Ralf Schmitt wrote:
On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro [EMAIL PROTECTED] wrote:
On Thu, Mar 20, 2008 at 1:16 PM, Martin v. Löwis [EMAIL PROTECTED]
wrote:
However, it *is* common to install Python code before running it.
Not every time you
Martin v. Löwis schrieb:
It was proposed before, I don't know whether any implementation
on that has started.
I don't see anything in the bug tracker. I'd be willing to look at it,
if this is what we want to do.
Neither could I. I vaguely remember having people mention it, but
could
Neil Toronto schrieb:
Besides, as the SmugLispWeenies have noted, Python is becoming more like
Lisp all the time:
(setq obj '(an ex-parrot)) ; (AN EX-PARROT)
`(I have ,obj) ; (I HAVE (AN EX-PARROT))
`(I have ,@obj) ; (I HAVE AN EX-PARROT)
Only
(See also Issue 2298)
String/Unicode/Bytes handling in getargs.c is in dire need of some
love; also the docs need to be made consistent with the implementation
w.r.t. where a string/unicode is needed, whether null bytes are allowed,
etc.
Perhaps something for the PyCon sprint?
Georg
--
Thus
Martin v. Löwis schrieb:
After talking to Collin, I just committed a change to
2to3 to make it installable as an executable script
called 2to3.
To do so, I had to wrap all the top-level modules
into a package, and move the fixes and tests into
that package. Lacking a better name, I called
Guido van Rossum schrieb:
Thomas Wouters suggests some new syntax:
http://bugs.python.org/issue2292
a, b, *c = range(5)
*a, b, c = a, b, *c
a, b, c
([0, 1, 2], 3, 4)
[ *a, b, c ]
[0, 1, 2, 3, 4]
L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
[ *item for item in L ]
Dj Gilcrease schrieb:
On Fri, Feb 15, 2008 at 8:46 AM, Joel Bender [EMAIL PROTECTED] wrote:
How about a BNFish notation? Use brackets around optional parameters.
def test([arg1, [arg2,]] arg3):
...
If I understand right, positional only arguments would not be optional
in
Christian Heimes schrieb:
Georg Brandl wrote:
I would prefer a python3 alias analogous to the current python alias,
at least as long as Python 2.x is still in wide use.
Having to type python3.0 explicitly strikes me as unnecessarily verbose.
+1
As for module file name extensions, what
Greg Ewing schrieb:
Stephen J. Turnbull wrote:
Greg Ewing writes:
Also, if generator expressions had come first, we
would probably never have gotten list comprehensions.
I don't understand. A list comprehension is for when you know you're
going to want to work with the whole list.
christian.heimes schrieb:
Author: christian.heimes
Date: Sat Jan 26 23:09:42 2008
New Revision: 60333
Added:
python/branches/py3k/Lib/plistlib.py
- copied unchanged from r60150,
python/branches/py3k/Lib/plat-mac/plistlib.py
Log:
Copied plistlib.py from r60150
Eric Hanchrow schrieb:
On Ubuntu 7.10 Gutsy Gibbon:
Unfortunately I don't really know python, so am unable to debug this.
I checked out by doing
svn co http://svn.python.org/projects/python/tags/r30a2 py3k
Then I built python itself with no apparent trouble. But building the
Martin v. Löwis schrieb:
* you can parse things with parser.suite(), but not create an AST from
the parse result
* you can create an AST with an undocumented flag to compile(), but not
compile the resulting AST
The flag is documented, in the document referred to.
There are good
Brett Cannon schrieb:
On Jan 10, 2008 2:08 PM, Joe Angell [EMAIL PROTECTED] wrote:
Oh I see... forgive my ignorance but could you point me at some
documentation or a project that uses the c AST as you mentioned? Is
that done through some part of the C-API? I cannot find that in the
That's an oversight. I've corrected it now.
Guido van Rossum schrieb:
Why do have some note numbers a \ and others don't?
On Jan 6, 2008 9:39 AM, georg.brandl python-3000-checkins@python.org wrote:
Author: georg.brandl
Date: Sun Jan 6 18:39:49 2008
New Revision: 59789
Modified:
Christian Heimes schrieb:
Python 3.0a2 is out and some people are working on backports of Python
3.0 features to 2.6. Shouldn't we start to rename the new API functions
and files to their final names before we back merge code to 2.6?
I'm proposing to change the names and files as following.
Terry Reedy schrieb:
Noam Raphael [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| My use case is data manipulation in the interactive shell -
You could always override sys.displayhook in order to handle floats
differently.
It seems your real problem is that repr() rather than
Brett Cannon schrieb:
As Guido stated in a recent email, the stdlib reorg is going to be the
next big thing in Py3K-Land after a2 goes out the door. And since I
stuck my head out and wrote PEP 3108 and tried to spear-head a reorg
several times before, I am the de-facto junior dictator in
christian.heimes schrieb:
Modified: python/branches/py3k/Doc/glossary.rst
==
--- python/branches/py3k/Doc/glossary.rst (original)
+++ python/branches/py3k/Doc/glossary.rst Mon Dec 3 22:02:03 2007
@@ -400,7
We've made class.function return a function, but the unbound method machinery
is still alive. For example, you can still create unbound methods with
new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
that refers to unbound methods.
Should this go too?
Georg
--
Thus
Paul Moore schrieb:
On 04/11/2007, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm beginning to settle on the following:
1. concrete types: bytes (immutable) and bytearray (mutable)
bytearray seems a bit clumsy, but I can't think of anything better...
It's much better than buffer. Also I
Christian Heimes schrieb:
Guido van Rossum wrote:
- change PyString's repr() to return b'...'
- change PyBytes's repr() to return buffer(b'...')
- change parser so that b... returns PyString, not PyBytes
- rename bytes - buffer, str8 - bytes
A patch by Alexandre Vassolotti and Christian
Christian Heimes schrieb:
You mean 'formerly', not 'formally' :-) I prefer to just call these by
their C names (PyString) to be precise, as the C names aren't changing
(at least not yet ;-).
Oh, formerly ... right. The current state of the names is very
confusing. It's going to cost me
brett.cannon schrieb:
Author: brett.cannon
Date: Mon Oct 8 21:48:15 2007
New Revision: 58378
Modified:
python/branches/py3k/Lib/ftplib.py
Log:
Change the default encoding for ftplib.FTP to latin1 so that bytes can be in
the range of 255 instead of only 128.
Shouldn't FTP use bytes
Neil Schemenauer schrieb:
I guess the library overhaul hasn't really started it but it would
be nice if the pickle module could get some work. Today I'm trying
to efficiently store a class using pickle and the documentation is
making my head hurt. I don't think the documentation itself is
Alexandre Vassalotti schrieb:
Indexing
**Open Issue:** I'm undecided on whether indexing bytes and buffer
objects should return small ints (like the bytes type in 3.0a1, and
like lists or array.array('B')), or bytes/buffer objects of length 1
(like the str type). The latter
Arvind Singh schrieb:
I hope that Python gets a sorteddict and a
sortedset.
It doesn't make sense for Python to have sorteddict or sortedset. You
see, dict can have keys which cannot be ordered (keys can be
heterogeneous, in which case Py3K may raise TypeError; ordering doesn't
Marcin 'Qrczak' Kowalczyk schrieb:
and fails on print.
Already fixed. :)
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
Should the __future__ be cleaned out for 3k, or should all future imports
continue to work and do nothing?
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.
Guido van Rossum schrieb:
I'm guessing this is also wrong on the trunk then?
Yes - it's already fixed there :)
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
Are they useful enough to keep?
--
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
Noam Raphael schrieb:
As I see it, the only reason for the current status is the desire to
make x in dict equivalent to dict.has_key(x), since has_key is a
common operation and x in is shorter. But actually dict.has_key(x)
explains exactly what's intended, while x in dict isn't really clear
Thomas Heller schrieb:
IIUC, in py3k, classic classes do not exist any longer, so the __metaclass__
line
has no effect anyway. Is this behaviour intended?
It is another incarnation of special methods being looked up on the class,
not the instance. This was always the behavior with new-style
Noam Raphael schrieb:
On 9/4/07, Greg Ewing [EMAIL PROTECTED] wrote:
Noam Raphael wrote:
The default dict iterator should in principle be iteritems(), and not
iterkeys().
This was discussed at length back when in support was
added to dicts. There were reasons for choosing to do it
the
I've added a basic skeleton of documentation for the abc module, but it
would be nice if somebody proofread it and at add more from PEP 3119 if
desired.
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
While looking at documenting the dict view changes, I came across an
inconsistency in how the dict views' set-like operations are implemented:
with sets/frozensets, the operator versions only work if the other operand
is a set/frozenset, while the dict view operators allow any iterable.
Do we
Georg Brandl schrieb:
While looking at documenting the dict view changes, I came across an
inconsistency in how the dict views' set-like operations are implemented:
with sets/frozensets, the operator versions only work if the other operand
is a set/frozenset, while the dict view operators
Robin Stocker schrieb:
Paul Dubois schrieb:
Attached is a patch for changes to the tutorial. I made it by doing:
svn diff tutorial tutorial.diff
in the Doc directory. I hope this is what is wanted; if not let me know
what to do.
Unfortunately cygwin will not run Sphinx correctly even
Talin schrieb:
I just posted on the tracker a patch which adds extensive documentation
for PEP 3101 to the Python Library Reference. This includes:
str.format()
format()
__format__
Formatter
format string syntax
format specification mini-language
Two short issues:
* Shouldn't str.decode() be removed? Every call to it says
TypeError: decoding str is not supported.
* Using e.g. babc.find(a) gives SystemError: can't use str as char buffer.
This should be a TypeError IMO.
Georg
--
Thus spake the Lord: Thou shalt indent with four
Eric Smith schrieb:
Talin wrote:
I just posted on the tracker a patch which adds extensive documentation
for PEP 3101 to the Python Library Reference. This includes:
str.format()
format()
__format__
Formatter
format string syntax
format specification mini-language
Guido van Rossum schrieb:
Thanks, applied.
There's a lot more to bing able to run make html PYTHON=python3.0
successfully, isn't there?
Yes, there is; IMO it won't have to work for alpha1, but I'll work on this
during the next few weeks.
Georg
--
Thus spake the Lord: Thou shalt indent
[EMAIL PROTECTED] schrieb:
I ran 2to3 over the Doc/tools directory. This left a number of problems
which I initially began replacing manually. I then realized that it would
be better to tweak 2to3. A couple things I wondered about:
1. How are we supposed to maintain changes to
Bill Janssen schrieb:
I plan to spend some Real Time on those today and I think Bill is
going to meet up with me on #python-dev when the Californians wake up.
That's not working real well right now... IRC seems wedged for me.
Probably a firewall issue.
I've got to try a different
Paul Dubois schrieb:
FYI: docutils will require some modification of at least the io module,
to the extent that the ideal mode of fixing the current sources so that
a subsequent pass of 2to3 will do the job, is probably not possible (but
may be outside of this one file). I've made a report to
BJörn Lindqvist schrieb:
It is fantastic! Totally super work. I just have one small request;
pretty please do not set the font. I'm very happy with my browsers
default (Verdana), and Bitstream Vera Sans renders badly for me.
Okay, I've changed the stylesheet, it should go live on
Alexandre Vassalotti schrieb:
On 8/16/07, Neal Norwitz [EMAIL PROTECTED] wrote:
On 8/15/07, Georg Brandl [EMAIL PROTECTED] wrote:
Okay, I made the switch. I tagged the state of both Python branches
before the switch as tags/py{26,3k}-before-rstdocs/.
http://docs.python.org/dev/
http
[EMAIL PROTECTED] schrieb:
Alex The PEP abstract says this proposal will replace the '%' operator,
I hope this really doesn't happen. printf-style formatting has a long
history both in C and Python and is well-understood. Its few limitations
are mostly due to the binary nature of the %
Brett Cannon schrieb:
On 8/14/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I thought some more about the universal newlines situation, and I
think I can handle all the use cases with a single 'newline'
parameter. The use cases are:
(A) input use cases:
(1) newline=None: input with default
Brett Cannon schrieb:
On 8/14/07, Georg Brandl [EMAIL PROTECTED] wrote:
Now that the converted documentation is fairly bug-free, I want to
make the switch.
I will replace the old Doc/ trees in the trunk and py3k branches
tomorrow, moving over the reST ones found at
svn+ssh://svn.python.org
Georg Brandl schrieb:
Now that the converted documentation is fairly bug-free, I want to
make the switch.
I will replace the old Doc/ trees in the trunk and py3k branches
tomorrow, moving over the reST ones found at
svn+ssh://svn.python.org/doctools/Doc-{26,3k}.
Neal will change his
Now that the converted documentation is fairly bug-free, I want to
make the switch.
I will replace the old Doc/ trees in the trunk and py3k branches
tomorrow, moving over the reST ones found at
svn+ssh://svn.python.org/doctools/Doc-{26,3k}.
Neal will change his build scripts, so that the 2.6 and
Christian Heimes schrieb:
Georg Brandl wrote:
Infos for people who will write docs in the new trees can be found in the
new Documenting Python document, at the moment still available from
http://pydoc.gbrandl.de:3000/documenting/, especially the Differences
section at http://pydoc.gbrandl.de
neal.norwitz schrieb:
Author: neal.norwitz
Date: Sun Aug 12 02:43:29 2007
New Revision: 56940
Log:
Kill execfile(), use exec() instead
Modified: python/branches/py3k/Demo/scripts/newslist.py
===
--- python/branches/py3k/Demo/scripts/newslist.py
Neal Norwitz schrieb:
On 8/12/07, Georg Brandl [EMAIL PROTECTED] wrote:
neal.norwitz schrieb:
Author: neal.norwitz
Date: Sun Aug 12 02:43:29 2007
New Revision: 56940
Log:
Kill execfile(), use exec() instead
Modified: python/branches/py3k/Demo/scripts/newslist.py
Bill Janssen schrieb:
I don't like the behaviour of Python 3000 when we compare a bytes strings
with length=1:
b'xyz'[0] == b'x'
False
The code can be see as:
ord(b'x') == b'x'
False
or also:
120 == b'x'
False
Two solutions:
1. b'xyz'[0] returns a new bytes
1 - 100 of 228 matches
Mail list logo
