On Wed, Mar 01, 2006 at 12:17:16AM -0600, Tim Peters wrote:
These .py and .txt files don't have the svn:eol-style property set.
I'm not sure they all _should_, though.
My experience shows that if the developers use different OSes (our team
uses Linux and Windows) it helps very much to set
Hello,
should we perhaps switch to (careful use of) C++ in 3.0 ?
I can't see many advantages in moving to C++, but a lot of disadvantages:
- Size increase, especially when we start using templates
- Performance decrease
- Problems with name mangling together with dynamic loading and cross
On Tue, 2006-02-28 at 15:23 -0800, Bill Janssen wrote:
Greg Ewing wrote:
Bill Janssen wrote:
bytes - base64 - text
text - de-base64 - bytes
It's nice to hear I'm not out of step with
the entire world on this. :-)
Well, I can certainly understand the bytes-base64-bytes side of
On Feb 28, 2006, at 6:26 PM, Fredrik Lundh wrote:
should we perhaps switch to (careful use of) C++ in 3.0 ?
I hope not. It would make life more difficult for embedded/extended
users like ourselves because it would force us to link our
applications as C++ programs. That introduces lots of
Bill Janssen wrote:
Greg Ewing wrote:
Bill Janssen wrote:
bytes - base64 - text
text - de-base64 - bytes
It's nice to hear I'm not out of step with
the entire world on this. :-)
Well, I can certainly understand the bytes-base64-bytes side of
thing too. The text produced is specified as
d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
I'm reasonably sure I copied it on purpose, only with a name that isn't 100%
misleading as to what it does ;)
Heh. From the original Usenet posting that suggested the capability
that was
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Hye-Shik Chang wrote:
On 2/19/06, Walter Dörwald [EMAIL PROTECTED] wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Anyway, I've started implementing a patch that just adds
codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig,
UTF-16,
Nick Coghlan wrote:
All the unicode codecs, on the other hand, use encode to get from characters
to bytes and decode to get from bytes to characters.
So if bytes objects *did* have an encode method, it should still result in a
unicode object, just the same as a decode method does (because
Hi,
I've posted this question on comp.lang.python, but nobody seems to
conclude it is a bad idea, so I post it here.
http://groups.google.com/group/comp.lang.python/browse_frm/thread/6082dae1deef9161/88bb8a26750dd8c6?lnk=raothl=en#88bb8a26750dd8c6
Basically, should staticmethods be made
On Thursday 02 March 2006 01:48, Walter Dörwald wrote:
Any progress on this? I'd really like to get this into 2.5 and the
feature freeze is approaching fast!
Remember, the feature freeze is as of beta1. Hopefully the major new
features are all going to be in before alpha1, but they can
Anthony Baxter wrote:
On Thursday 02 March 2006 01:48, Walter Dörwald wrote:
Any progress on this? I'd really like to get this into 2.5 and the
feature freeze is approaching fast!
Remember, the feature freeze is as of beta1. Hopefully the major new
features are all going to be in before
Ron Adam writes:
While playing around with the example bytes class I noticed code reads
much better when I use methods called tounicode and tostring.
[...]
I'm not suggesting we start using to-type everywhere, just where it
might make things clearer over decode and encode.
+1
I always
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Hye-Shik Chang wrote:
On 2/19/06, Walter Dörwald [EMAIL PROTECTED] wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Anyway, I've started implementing a patch that just adds
codecs.StatefulEncoder/codecs.StatefulDecoder.
On 3/1/06, Nicolas Fleury [EMAIL PROTECTED] wrote:
Basically, should staticmethods be made callable so that the following
would not raise an exception:
class A:
@staticmethod
def foo(): pass
bar = foo()
There's workarounds, but it's really just about usability.
Zitat von Ulrich Berning [EMAIL PROTECTED]:
I can't see many advantages in moving to C++, but a lot of disadvantages:
There are a few advantages, though, mainly:
- increased type-safety, in particular for API that isn't type-checked
at all at the moment (e.g. PyArg_ParseTuple)
- more reliable
[EMAIL PROTECTED] wrote:
Zitat von Ulrich Berning [EMAIL PROTECTED]:
I can't see many advantages in moving to C++, but a lot of disadvantages:
There are a few advantages, though, mainly:
- increased type-safety, in particular for API that isn't type-checked
at all at the moment (e.g.
Huh... just joining here but surely you don't mean a text string that
doesn't use every character available in a particular encoding is
really bytes... it's still a text string...
No, once it's in a particular encoding it's bytes, no longer text.
As you say,
Keep these two concepts separate
Chermside, Michael wrote:
... I will say that if there were no legacy I'd prefer the tounicode()
and tostring() (but shouldn't itbe 'tobytes()' instead?) names for Python 3.0.
Wouldn't 'tobytes' and 'totext' be better for 3.0 where text == unicode?
--
-- Scott David Daniels
[EMAIL PROTECTED]
I wrote:
... I will say that if there were no legacy I'd prefer the tounicode()
and tostring() (but shouldn't itbe 'tobytes()' instead?) names for Python 3.0.
Scott Daniels replied:
Wouldn't 'tobytes' and 'totext' be better for 3.0 where text == unicode?
Um... yes. Sorry, I'm not completely
Just a quick question about the mechanics of replying to this list.
I am a subscriber to the list, however I much prefer readiing the list
archives on the web instead of having the postings delivered to my email
account. Because of this, I have delivery turned off in the mailing list
On 2/28/06, Terry Reedy [EMAIL PROTECTED] wrote:
Greg Ewing [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
And you don't think there are many different
types of iterables? You might as well argue
that we don't need len() because it only
applies to sequences.
Since you
On 2/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
I added webstats for all subsites of python.org:
http://www.python.org/webstats/
what's that Java/1.4.2_03 user agent doing? (it's responsible for
10% of all hits in january/february, and 20% of the hits today...)
On Wed, 2006-03-01 at 11:00 -0800, Talin wrote:
However, I would like to be able to reply to posts in such a way as to
have them appear in the appropriate place in the thread hierarchy. Since
I don't have the original email, I cannot reply to it directly; instead
I have to create a new,
Talin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Just a quick question about the mechanics of replying to this list.
I am a subscriber to the list, however I much prefer readiing the list
archives on the web instead of having the postings delivered to my email
account. Because
Steven Bethard wrote:
My only (mild) concern is that if staticmethod is going to get a
__call__, I think classmethod should probably get one too. Inside a
class this doesn't make much sense:
I agree, make sense or not, if @staticmethod def foo() and a simple
def foo(self) can all be called
On Wed, Mar 01, 2006 Brett Cannon wrote:
On 2/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
I added webstats for all subsites of python.org:
http://www.python.org/webstats/
what's that Java/1.4.2_03 user agent doing? (it's responsible for
10% of all hits
1. Maybe there should be a more obvious way to spell bytes([0])*N.
I went through bytes([0]*N) and bytes('\0'*N) before I realized
there was a memory-efficient way to do it.
1a. Likewise, slice-assignment nicely handles memmove(), but there's
no memset().
2. Having a plural noun as a type
On Wed, Mar 01, 2006, Jason Orendorff wrote:
3. I wrote a toy BytesIO class to go with the toy bytes object:
http://wiki.python.org/moin/BytesIO
(I hope this isn't considered wiki abuse -- it seemed as worthy and
relevant as most of what's in there.)
Au contraire! This is precisely why a
On Wed, Mar 01, 2006, Talin wrote:
However, I would like to be able to reply to posts in such a way as to
have them appear in the appropriate place in the thread hierarchy. Since
I don't have the original email, I cannot reply to it directly; instead
I have to create a new, non-reply email
On 3/1/06, Jack Diederich [EMAIL PROTECTED] wrote:
On Wed, Mar 01, 2006 Brett Cannon wrote:
On 2/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
I added webstats for all subsites of python.org:
http://www.python.org/webstats/
what's that Java/1.4.2_03
I just found that test_compiler fails on test_contextlib.py.
To reproduce the failure, run
from compiler import compileFile
compileFile(Lib/test/test_contextlib.py)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
some more thoughts about the bytes object:
1) it would be nice to have an trivial way to change a bytes object to an int /
long, and vice versa.
Rationale:
while manipulating binary data will happen mostly with bytes objects, some
operations are better done with ints, like the bit
On 3/1/06, Nicolas Fleury [EMAIL PROTECTED] wrote:
The problem is that even after explaining descriptors (which IMHO can be
a more advanced feature for newbies), you still need a workaround and
you might end up with (or call __get__):
class A:
def foo(): pass
bar = foo()
foo
Nick Coghlan wrote:
ascii_bytes = orig_bytes.decode(base64).encode(ascii)
orig_bytes = ascii_bytes.decode(ascii).encode(base64)
The only slightly odd aspect is that this inverts the conventional meaning of
base64 encoding and decoding,
-1. Whatever we do, we shouldn't design
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
There are a few advantages, though, mainly:
- increased type-safety, in particular for API that isn't type-checked
at all at the moment (e.g. PyArg_ParseTuple)
How would this be accomplished - by a function with a ton of optional
Bill Janssen wrote:
No, once it's in a particular encoding it's bytes, no longer text.
The point at issue is whether the characters produced
by base64 are in a particular encoding. According to
my reading of the RFC, they're not.
--
Greg Ewing, Computer Science Dept,
Ron Adam wrote:
While playing around with the example bytes class I noticed code reads
much better when I use methods called tounicode and tostring.
b64ustring = b.tounicode('base64')
b = bytes(b64ustring, 'base64')
I don't like that, because it creates a dependency
(conceptually,
Raymond Hettinger wrote:
[Greg Ewing]
And you don't think there are many different
types of iterables?
Um, I meant iterators and suspect you meant the same --
The same comment applies either way. Each type of iterable
usually has its own corresponding type of iterator.
YAGNI. The
[My apologies Greg; I meant to send this to the whole list. I really
need a list-reply button in GMail. ]
On 3/1/06, Greg Ewing [EMAIL PROTECTED] wrote:
I don't like that, because it creates a dependency
(conceptually, at least) between the bytes type and
the unicode type.
I only find half of
Zitat von Michael Urman [EMAIL PROTECTED]:
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
How would this be accomplished - by a function with a ton of optional
templated arguments?
That's how I would do it. Actually, I would have PyArg_ParseTuple
overloaded with different numbers of
Baptiste Carvello wrote:
while manipulating binary data will happen mostly with bytes objects, some
operations are better done with ints, like the bit manipulations with the
|~^
operators.
Why not just support bitwise operations directly
on the bytes object?
--
Greg Ewing, Computer
On 3/1/06, Brett Cannon [EMAIL PROTECTED] wrote:
But moving over to more attributes for how we access basic interfaces
seems great to me.
We shouldn't approach this as methods good, functions bad -- nor the
opposite, for that matter.
When all things are equal, I'd much rather do usability
Greg Ewing wrote:
Ron Adam wrote:
While playing around with the example bytes class I noticed code reads
much better when I use methods called tounicode and tostring.
b64ustring = b.tounicode('base64')
b = bytes(b64ustring, 'base64')
I don't like that, because it creates a
Guido van Rossum wrote:
str.join() is an interesting case...
Making it a
string method is arguably the right thing to do, since this operation
only makes sense for strings.
The type of such a polymorphic function is easily specified:
join(sequence[T], T) - T, where T is a string-ish
Thanks! This was due to a bug in the code for creating the AST for an
expr-less yield.
Fixed in r42772.
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I just found that test_compiler fails on test_contextlib.py.
To reproduce the failure, run
from compiler import compileFile
Here's the draft for the second half of January. First half of
February on its way soon. Any
suggestions/corrections/additions/comments welcome. Thanks! -TAM
=
Announcements
=
-
Google summer internships
-
Google is
Patch / Bug Summary
___
Patches : 382 open ( -3) / 3079 closed (+12) / 3461 total ( +9)
Bugs: 880 open (+16) / 5624 closed ( +3) / 6504 total (+19)
RFE : 211 open ( +0) / 201 closed ( +1) / 412 total ( +1)
New / Reopened Patches
__
PEP 357
On 1/24/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 1/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I ran Fredrik's listmodules script in my current sandbox and got a
deprecation warning for the regex module. According to PEP 4 it is already
obsolete. I saw nothing there about
Greg Ewing [EMAIL PROTECTED] wrote:
u = unicode(b)
u = unicode(b, 'utf8')
b = bytes['utf8'](u)
u = unicode['base64'](b) # encoding
b = bytes(u, 'base64') # decoding
u2 = unicode['piglatin'](u1) # encoding
u1 = unicode(u2, 'piglatin') # decoding
Your provided
Guido van Rossum wrote:
In which context did you find a need for defining a static method and
calling it inside the class definition? I'm guessing that what you're
playing dubious scoping games.
I'm not. I almost never use staticmethod actually. I find them not
very pythonic, in my humble
I spent most of my PyCon sprint time so far working on Evan Jones's
arena-freeing obmalloc patch:
http://www.python.org/sf/1123430
It's ready to test now! The work is on a branch:
svn+ssh://svn.python.org/python/branches/tim-obmalloc
Only obmalloc.c is changed in that branch, and you
51 matches
Mail list logo
