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 c
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
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
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
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 -
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 look
Ron Adam wrote:
> 1. We can specify the operation and not be sure of the resulting type.
>
>*or*
>
> 2. We can specify the type and not always be sure of the operation.
>
> maybe there's a way to specify both so it's unambiguous?
Here's another take on the matter. When we're doing
Unicode
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
> comp
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-
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 c
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
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
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
[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 hal
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.
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
(conceptua
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, +
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
temp
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
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()
>
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 manipulation
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
http://mail.pyth
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/
> > >
>
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 e
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 wh
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 typ
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 f
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 ca
"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.
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,
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
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".
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
preference
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
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]
> 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 sepa
[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 momen
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 reliab
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. s
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.Stat
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 alwa
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 be
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 contin
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=raot&hl=en#88bb8a26750dd8c6
Basically, should staticmethods be made callabl
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 (beca
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.StatefulDecod
> >> 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
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"
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 o
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 byte
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 c
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
52 matches
Mail list logo
