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.
___
Python-3000 mailing list
Python-3000@pyth
Functions that map unicode->unicode or bytes->bytes could be called
transcoders. Each type could be given a .transcode method to go along with
but contrast with .encode or .decode.
tjr
___
Python-3000 mailing list
Python-3000@python.org
http://mail
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| 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 .transcode method to go along
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Guido van Rossum wrote:
|
| > Really? Don't you think it's pretty obvious that b.transform("gzip")
| > compresses and b.untransform("gzip") decompresses? Or that
| > b.transform("base64") generates base64 format?
|
| Well,
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Motivation: When was the last time you used a gzip compression
| option (ie. yes there are options, but do you use them in the
| general use case) ? Can you write code that applies UU encoding
| without looking up the d
"Atsuo Ishimoto" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yes. My question is "Which do you feel comfortable, printing collect
| glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
| characters, but I had feeling that western people prefer hex-escaped
| ASCII
|
| - Add ``isprintable()`` method to the string type. ``str.isprintable()``
| return True if ``repr()`` should escape the characters in the string,
| False otherwise.
Is not this backwards? Isprintable to me mean should *not* escape.
___
Python-
"Manuel Kaufmann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Hi, I'm Manuel Kaufmann (aka humitos) and I'm student of "System
Engenieer" in
| Santa Fé (Capital) Argentina.
|
| I met Python in the "1º Jornadas de Python en Santa Fé" three years ago,
and
| I'm happy with it. Ho
"Manuel Kaufmann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| El Sunday 25 May 2008 21:22:43 Terry Reedy escribió:
| > Hi Manuel,
| > This list (Python 3000 devel) is for discussion of development of a
| > *future* version of Python, primarily by the de
Guido van Rossum wrote:
I think this would be a mistake by default --
> being able to read the
source *easily* (i.e. without any specific tools) is part of Python's
success.
For startup and import speed (and self-contained distributions),
do not we only need a zip of the .pyc files?
Not hav
1. Non-issue to me, real issues to some.
2. Wrong group, expecially if you want dissenting opinions ;-).
3. print: 3.0 normal 'file = xxx' is visually prettier than 2.x
idiosyncratic line-noisy '>> xxx'. I also prefer new 'except TypeError
as t' to old 'except TypeError,t' since latter falsel
Oleg Broytmann wrote:
Less stat calls in exchange for seeking in the zip "filesystem" plus
decompression. IWBN if someone shows real numbers...
Decompression time is balanced, probably more than balanced, by shorter
disk reading times. In the last twenty years, cpus have speed up much
Only if you didn't know that b'' is an alternative to bytes(). The b''
notation is so much more compact and so much more helpful that I
really don't want to go back to it. We will somehow have to deal with
this through education and documentation.
http://bugs.python.org/issue3220
Improve Bytes
Guido van Rossum wrote:
On Sat, Jun 28, 2008 at 1:45 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Several posters (including a certain GvR) in the bug tracker (*) have been
baffled by an apparent bug where the re.IGNORECASE flag didn't imply
case-insensitivity for non-ASCII characters. It tur
nirinA raseliarison wrote:
Exception in Tkinter callback
Traceback (most recent call last):
File "/root/Py3kb1/lib/python3.0/tkinter/__init__.py", line 1409,
in __call__
return self.func(*args)
File "/root/Py3kb1/lib/python3.0/idlelib/MultiCall.py", line 165,
in handler
r = l[i]
WinXP 3.0
lib2to3 has grammar3.0.0.alpha.4.pickle
was nothing updated for the beta?
or did grammar3.0.0.beta.a.pickle only make 2.6b1?
I cannot find any doc in the libref (it would belong, I believe, in
Development Tools). Intentional? Not done yet?
tjr
__
Martin v. Löwis wrote:
Terry Reedy wrote:
WinXP 3.0
specifically .0b1
lib2to3 has grammar3.0.0.alpha.4.pickle
What do you mean by "has"?
The standard sense of 'directory has file'
Directory of C:\Program Files\Python30\Lib\lib2to3
06/19/2008 10:57 PM
Martin v. Löwis wrote:
I really need to know the exact sequence of actions
done to this folder. One possible explanation is that
you installed alpha4, then upgraded to beta1.
.0a3 to .0a4 to .0b1.
I do not know how to run 2to3 and do not remember trying to do so.
pickle.load(...) failed say
Antoine Pitrou wrote:
> Carl Johnson carlsensei.com> writes:
>> This raises the question, do we need both a ``break`` statement and
>> ``raise StopIteration``?
>> Can the former just be made into syntatic sugar
>> for the later? Or is this the hobgoblin of a little mind?
Yes, no, and ??.
One
Nick Coghlan wrote:
Carl Johnson wrote:
Certainly, it's an inconsistency compared to generator expressions,
but is it a bug? I know that Python 3000 is making it so that list
comprehension variables don't leak anymore, so I take it that the goal
is to have them be more similar to generator e
Greg Ewing wrote:
Adam Olsen wrote:
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.
Would you do that only for genexps, or for generators
in general?
For me, the former. For generators in gen
Mark Dickinson wrote:
In any case, if you're interested in getting these in to 2.7/3.1 (it's too
late for 2.6/3.0) then I'd suggest opening a feature request at
bugs.python.org. (And assign it to me, if you like.)
I'm interested also. Done and done.
http://bugs.python.org/issue3366
__
Guido van Rossum wrote:
I don't see how this can be fixed, because there's no way for
the list() constructor to know where the StopIteration is coming
from.
Sounds like a good analysis to me. No bug here. Move along, nothing to see here!
I decided a couple of days ago that the easiest 'fix
http://bugs.python.org/issue3400
dis / Python Bytecode Instructions doc is missing entries for
UNPACK_EX
STORE_LOCALS
LOAD_BUILD_CLASS
MAKE_BYTES
which appear in dis.opname (3.0 version).
Based on examples, I suggested that the UNPACK_SEQUENCE entry be followed by
UNPACK_EX(bytepair)
Used for s
I, for my part, prefer the latter solution (b). Example: a student,
having (interactively) produced some design using some turtle t =
Turtle() decides spontaneously to change backgroundcolor. s = Screen();
s.bgcolor("pink") should do this for her -
My perhaps naive view is that students shou
PL wrote:
Hi
I'm new to the list. Sorry if this has been discussed before, but I
didn't notice it.
Is it possible for the Windows installer to install to some other
directory than the root (i.e., somewhere else apart from C:\Python25 as
2.5 does).
That is the default. You are free to put
Nick Coghlan wrote:
(I deliberately pronounce daemon as day-mon though, so I don't forget
how to spell it - perhaps pronouncing it as dee-mon makes it harder to
remember the order of the 'a' and the 'e'?)
If it is just the specific typo as 'deamon' that concerns people, adding
a property spec
Guido van Rossum wrote:
On Mon, Sep 29, 2008 at 8:55 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
Le Monday 29 September 2008 19:06:01 Guido van Rossum, vous avez écrit :
I know I keep flipflopping on this one, but the more I think about it
the more I believe it is better to drop those
Guido van Rossum wrote:
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 no objection
Terry Reedy wrote:
Guido van Rossum wrote:
I'm not sure either way. I've heard it claim that Windows filesystem
APIs use Unicode natively. Does Python 3.0 on Windows currently
support filenames expressed as bytes? Are they encoded first before
passing to the Unicode APIs? Using wha
Martin v. Löwis wrote:
Guido van Rossum wrote:
However
the *proposed* behavior (returns bytes if the arg was bytes, and
returns str when the arg was str) is IMO sane, and no different than
the polymorphism found in len() or many builtin operations.
My concern still is that it brings the bytes
I have seen a couple of objections to leaving unbound methods naked (as
functions) when retrieved in 3.0. Here is a plus.
A c.l.p poster reported that 2.6 broke his code because the addition of
default rich comparisons to object turned tests like hassattr(ob,
'__lt__') from False to True. Th
Mark Seaborn wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
I have seen a couple of objections to leaving unbound methods naked (as
functions) when retrieved in 3.0. Here is a plus.
A c.l.p poster reported that 2.6 broke his code because the addition of
default rich comparisons to
Mark Seaborn wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
Mark Seaborn wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
I have seen a couple of objections to leaving unbound methods naked (as
functions) when retrieved in 3.0. Here is a plus.
A c.l.p poster reported that 2.6 br
Nick Coghlan wrote:
(added Michael to the CC list)
It isn't object that has grown an __lt__ method, but type. The extra
check Michael actually wants is a way to make sure that the method isn't
coming from the object's metaclass, and the only reliable way to do that
is the way collections.Hashabl
James Y Knight wrote:
FWIW: Qt works fine with undecodeable filenames, and it too uses unicode
strings everywhere in its API. I looked into what it does, and found
that it uses your (Martin)'s original idea for solving this: it stores
undecodeable bytes as characters from 0x10fe00 to 0x10feff
Guido van Rossum wrote:
On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
So, we need to come up with a new release schedule for Python 3.0. My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0 rc 2
19-Nov-2008 3.0 rc 3
03-Dec-2008 3.0 final
Given what still needs to be
Glenn Linderman wrote:
My understanding of the Posix file names is that any byte values are
valid except "/" and null. Is this a correct understanding?
The UTF-8b proposal seems to translate from a non-UTF-8 byte stream to a
Unicode character stream. Call the original byte stream FOO. The
Bill Janssen wrote:
Victor Stinner <[EMAIL PROTECTED]> wrote:
Note: imaplib and nntplib have no test :-(
The examples in the manual should serve as a basis for a doctest.
I'm concerned about the lack of test suites for these modules. They
basically go untested unless someone sets up a serv
Over the years, people have complained about the difficulty of finding
the meaning of symbols used in Python syntax. So ... I wrote a
Python 3 Symbol Glossary
http://code.google.com/p/xploro/downloads/list
There are .txt and .odt versions. The first is usable, the second is
nicer if you have
M.-A. Lemburg wrote:
Why was the special case for None being "smaller" than all other
objects in Python removed from Python 3.0 ? (see object.c in Py2.x)
For one thing, it is only smallest when it controls the comparison.
>>> class c(object):
... def __lt__(s,o): return True
...
>>> cc = c()
Guido van Rossum wrote:
No, no, no! *Eventually* Python 3.0 will just be "python". Until
then, it needs to be "python3.0".
I think you should consider changing the installation policy to
installing each file with its own pythonx.y name and alias exactly one,
the system default, as 'python'.
Martin v. Löwis wrote:
Currently on Windows, python3.0 is installed as just plain 'python'.
This already causes problems when I want to choose 2.5 or 3.0. In my
quick start list, I have two entries which both say "Python (command
line)" with the *same* icon.
What is a quick start list, and ho
Roger Binns wrote:
The problem is that unless you are clairvoyant you have no way of
knowing about this change. Even in rc3 the documentation shows the old
(wrong) way:
http://docs.python.org/dev/3.0/extending/newtypes.html
PyObject_HEAD_INIT is documented:
http://docs.python.org/dev/3.0
This is not a binary images list or group ;-)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The case for changing 'for' is weakest, for sure.
As I understand the proposal, the rationale for restricting the exception
target is the autodeletion, which is obviously bug-prone if applied to
pre-existing struc
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Um, you're not taking 2.6 into consideration here. Remember that there
has
| to be a way to spell all these APIs in 2.6 that will still work in 3.0.
| IMO, this seems sufficient reason to keep sys.exc_info() around,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| FWIW, I've updated PEP 358 (the bytes object) to more closely reflect
| my plans for it, showing the preservation of most string methods. It
| should be updated on the website in a few minutes.
|
| If someone would l
"Ka-Ping Yee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On the consistency argument: sorted(somelist) calls copy(somelist).sort,
not copy(somelist).__sort__. But I don't expect to see this change
proposed.
| Transition Plan
| ===
|
| Two additional transformati
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Can I suggest that next() and __next__() be dropped entirely and that
iterators just be made callable.
Can you do that without making the call a regular, slow call each time?
Or at least without adding a lookup of '__call__' each tim
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
|
| > One of the virtues, and as I recall, design purposes, of .next calls is
to
| > be fast. After the first call, execution jumps directly into the
| > pre-existing stack f
"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| >From the checked-in version,
|
| """
| Two additional transformations will be added to the 2to3 translation tool
[3]:
|
|* Method definitions named next will be renamed to __next__.
|* Explicit calls to the ne
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Barry Warsaw wrote:
|
| > We already have an established, community accepted implementation of
| > interfaces,
|
| Really? Which one is that?
I was wondering too. Has there been a concrete PEPed proposal that I
missed?
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
FWIW, I agree that class definition meta-information should go in the
header rather that the body. To me, metaclass=mymeta at the top is much
prettier than __metaclass__ = mymeta in the body. It will also make it
"Nicko van Someren" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On 14 Mar 2007, at 23:08, Guido van Rossum wrote:
| > IOW, the only thing I'm unsure about is whether int('0012', 0) should
| > return 10 or complain like eval('0012') would. Perhaps it's best to
| > say that int('0
"Stephen Hansen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On 3/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
| >
| > I'm neutral about the choice between 0o, 0c or 0t.
|
|
| Interested Lurker Opinion: Can it be a "small" character? 0x1 leaps out
for
| me because of the
"Patrick Maupin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The update includes issues discussed to date, plus the support of
| uppercase on input of binary and hex, e.g. '0O123'.
|
| It was pointed out to me that, since I suggested upper/lowercase was
| an issue for another PE
"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Quoting from the commit message for r51533, which removed the default
ordering:
|
| What's the status on this? FWIW, I would like to see __cmp__ stay as a
| fallback measure if __eq__, __ne__, __lt__, etc aren't define
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| But can this work? It might end up calling cmp() on two incomparable
| objects. For __lt__ etc. that might be the right answer, but for
| __eq__ it is *not* -- the default __eq__ and __ne__ *must* compare
| object id
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yes, but dictionaries had an explicit ordering in dict_compare() which
was
| deleted.
Is dict_compare something added in 2.5? It is neither a builtin or dict
method in 2.4.
In any case, this point is that dict order
"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| No comments at all. :( Did I send the mail to the wrong list?
No, perhaps everyone did as I did, and assumed someone else would answer
;-)
| Either or, I still would like to know what the py3k rules are for
| repai
Terry Reedy schrieb:
| > In any case, this point is that dict ordering is as arbitrary as
ordering,
| > for instance, a dict and a string. Since Guido stopped the experiment
of
| > totally ordering all objects when complex nums were added, consistency
| > suggests that all fake
"Aahz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| IIRC, there was some discussion about removing single-line blocks like
| this one in 3.0:
|
|if foo: bar()
|
| However, I can't find any discussion about making it happen, and it's
| not in PEP 3099. Guido, does this need a
"Jim Jewett" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
|Functions (including methods) often want access to themselves,
|usually for a private storage location.
Or for true recursion. At present, a function has to 'hope' that its
definition name is not rebound.
tjr
"Daniel Stutzbach" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Sort O(n log n) O(n log n)
Tim Peters' list.sort is, I believe, better than nlogn for a number of
practically important special cases. I believe he documented this in the
code comme
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> Thus, when someone is offered something, they may say, "I'll pass",
| > meaning they are declining to act. Ergo, to "pass" in Python is to
| > decline to give up the opportunity to act.
The person being quoted m
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On 01/05/2007 12.52, Martin v. Löwis wrote:
| Isn't this already blacklisted in PEP 3099?
In today's Pep Parade post, he implies no.
"PEP: Supporting Non-ASCII identifiers (Martin von Loewis)
I'm on record as not liki
and hence '=' will not become an operator and hence '=' will not become
overloadable.
(unless, of course, Guido has revised previous rejections).
Came up again today on c.l.p. Surprised not alread in PEP.
tjr
___
Python-3000 mailing list
Python-30
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > and hence '=' will not become an operator and hence '=' will not become
| > overloadable.
|
| Actually, '=' *is* overloadable in most cases,
It
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| At 08:43 PM 5/9/2007 -0600, Steven Bethard wrote:
| Yeah, and the dilemma is that if I go back and add in all the
| examples and clarifications that have come up in these threads, it's
| going to be even bigger. Ditto
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| That's a red herring.
That is how I felt when you dismissed my effort to make your proposal more
useful and more acceptable to some (by addressing transliteration) with the
little molehill problem that Norwegians
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
| While there has been a lot of discussion as to whether to accept PEP
| 3131 as a whole, there has been little discussion as to the specific
| details of the PEP. In particular, is it generally agreed that the
| Unicode character
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I'm not aware of an algorithm that
| can do transliteration for all Unicode characters.
Were you proposing to allow all Unicode characters in Python names?-)
| Therefore, I cannot add transliteration into the PEP.
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Guido van Rossum wrote:
|
| > Last call for discussion! I'm tempted to reject this -- the ability to
| > generate optimized code based on the shortcut semantics of and/or is
| > pretty important to me.
|
| Please don't be
"Jason Orendorff" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| PEP 3100 still isn't clear on the fate of these guys, except that
| reduce() is gone.
|
| How about moving all three to the functools module instead?
The current reduce is broken due to being a mashing together of tw
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| How should an "ireduce" work? The result is not a sequence which could be
| returned lazily.
It would generate the sequence of partial reductions (potentially
indefinately).
list(ireduce(summer, 0, range(5)) = [0, 1, 3
"Chris Monson" <[EMAIL PROTECTED]> wrote in message | Leaving (old PEP
number) in place as a stripped down PEP that just points to
| the new number: +1
Good idea. And new number = next available. Special PEP numbers should be
for special PEPs.
tjr
_
"John S. Yates, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Tue, 3 Jul 2007, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
|
| >However, I'm rejecting it on the basis that code so complicated to
| >require this feature is very rare.
|
| I assume that you are familiar wit
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Georg is correct. A list comprehension like:
|
| [(x * y) for x in seq1 for y in seq2]
|
| expands to the following in 2.x (% prefixes the compiler's hidden
| variables):
|
| %n = []
| for x in seq1:
| for y in s
Reference Implementation
If this PEP is accepted, the author will provide a reference
implementation of the new classes in pure Python (that can run in
CPython, PyPy, Jython and IronPython) and a second one optimized for
speed in Python and C, suitable for inclusion in th
Someone asked if Py3 would get a "real" or "pure" bool type (one not
subclassing int). [The usual complaints and rehash about current bool
ensured.] I believe (and said so) that this is a settled question. If so,
please add a line under Standard types
* bool will continue to subclass int.
tj
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
By the way, I recently came across a use case for @around that I
hadn't mentioned before. I'm in the process of re-implementing
RuleDispatch's expression features in PEAK-Rules, and as I was
defining the rules for inter
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Nick Coghlan wrote:
| > Py3k strings are unicode, so returning a string would mean you just
have
| > to encode it again using the ascii codec to get the bytes to put on the
| > wire.
|
| I still believe that producing a s
"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|def __bool__(self):
|"""True if self != 0."""
|return self != 0
Could this be a Number rather than Complex method?
---
| There is no built-in rational type
Floats constitu
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| In short, having read up to the beginning of Exact vs. Inexact Classes,
my
| suggestion is to delete the unrealizable 'real' class
Less than a minute after hitting Send, I realized that one
"Noam Raphael" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The reasoning is simple: Iteration over an object usually gets all the
| data it contains. A dict can be seen as an unordered collection of
| tuples (key, value), indexed by key. So, iteration over a dict should
| yield
"Nicholas Bastin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yeah, my point was mostly an aside to anyone that might have
| questioned my earlier results of a 2.3x slowdown on integer-sized
| values because I used 1. A quick switch to 200 netted the exact same
| results,
Curr
"Sascha Peilicke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| is or has there been any discussion about stackless and py3k?
No. C. Tismer has focused his current efforts on PyPy.
___
Python-3000 mailing list
Python-3000@python.or
"Mathieu Fenniak" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| method (for pickling subclass instances). I was going to upload this
| to the SF patch manager, but it appears to be closed to permit only
| project members access.
Because SF is only an archive now.
We are now usin
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Changing the mode between text and binary is not feasible (since it
| would have to change the class). But it is perfectly acceptable to use
| sys.std{in,out}.buffer if you need to write a binary transparent
| filter
"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On 9/20/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
|| >
| > I have fixes for the following:
...
| > I'll post a patch later today.
|
| Thanks for the help! This brings up a policy question: For patches
| like the one I'
| @validate_proxy
| proxy = "http://user:[EMAIL PROTECTED]:port/"
|
| be a syntactical sugar for:
| proxy = validate_proxy("http://user:[EMAIL PROTECTED]:port/")
Sorry, to me, this is syntactical pepper -- or worse ;-)
tjr
___
Python-3000 mailing
"Michael Urman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| If there's not something straightforward to put in the ... below that
| would allow simple iteration and processing of all files passed on the
| command line, preferably interchangeably on both unix (where filenames
|
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|
| Well, if we wanted "x" and b"x" to compare unequal instead of raising
| an exception, we could just define it that way (it was that way until
| just before 3.0a1). But we're explicitly defining it to raise a
| Type
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Until just before 3.0a1, they were unequal.
I think it valuable that in the language as delivered, 'o==p' (as well as
'bool(o)' )always return True or False. Both make reasoning about code
easier since one does n
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Brett Cannon wrote:
| > +1 from me.
|
| Looks good to me too: +1
|
| I wouldn't mind seeing some iteration-in-C bit-bashing operations in
| there eventually, but they aren't needed on the first pass, and even
| being abl
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > If orig_data were mutable (the new buffer, as proposed in the PEP),
would
| > not
| >
| > for i in range(len(orig_data)):
| > orig_data[i] &= 0x1F
| >
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| > > > As I work on these.. Should the mutable PyBytes_ (buffer) objects
implement
| > > > the following methods inplace and return an additional reference to
self?
| >
| > > > .capitalize(), .center(), .expandtabs
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| I'd love a better term. It seems we could use several new names:
|
| 1. a new name for what PEP 3137 calls buffer
The definining difference is mutability or editability, so 'mubytes' or
'ebytes'.
| 2. a new name
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Shorah!
|
| I've started to work on a pyvm module patch today. The new
| module is going to contain low level interfaces to Python's VM and some
| low level types, too. So far my first version contains only a bunch o
101 - 200 of 202 matches
Mail list logo
