Greg Ewing wrote:
> Fredrik Lundh wrote:
>
> > moving to (basic) C++ might also be a good idea (in 3.0, perhaps). is any-
> > one still stuck with pure C89 these days ?
>
> Some of us actually *prefer* working with plain C
> when we have a choice, and don't consider ourselves
> "stuck" with it.
Fredrik Lundh wrote:
> moving to (basic) C++ might also be a good idea (in 3.0, perhaps). is any-
> one still stuck with pure C89 these days ?
Some of us actually *prefer* working with plain C
when we have a choice, and don't consider ourselves
"stuck" with it.
My personal goal in life right no
Jason Orendorff wrote:
> I like these promises:
> - bytes(arg) works like array.array('b', arg)
> - bytes(arg1, arg2) works like bytes(arg1.encode(arg2))
+1. That's exactly how I think it should work, too.
> I dislike these promises:
> - bytes(s, [ignored]), where s is a str, works like ar
Bill Janssen wrote:
> I use it quite a bit for image processing (converting to and from the
> "data:" URL form), and various checksum applications (converting SHA
> into a string).
Aha! We have a customer!
For those cases, would you find it more convenient
for the result to be text or bytes in P
Nick Coghlan wrote:
> I wouldn't mind seeing one of the early ideas from PEP 340 being resurrected
> some day, such that the signature for the special method was "__next__(self,
> input)" and for the builtin "next(iterator, input=None)"
Aren't we getting an argument to next() anyway?
Or was tha
[1/24/06, Tim Peters]
>> ...
>> test_rude_shutdown() is dicey, relying on a sleep() instead of proper
>> synchronization to make it probable that the `listener` thread goes
>> away before the main thread tries to connect, but while that race may
>> account for bogus TestFailed deaths, it doesn't se
I made a few more minor revisions to the AST on the plane this
afternoon. I'll check them in tomorrow when I get a chance to do a
full test run.
* Remove asdl_seq_APPEND. All uses replaced with set
* Fix set_context() comments and check return value every where.
* Reimplement real arena for pyar
Zitat von Terry Reedy <[EMAIL PROTECTED]>:
> "
> 2.What can I do with the Express Editions?
> ...
> Evaluate the .NET Framework for Windows and Web development.
> "
> and this
>
> "
Yes, but also this:
"""4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions
[EMAIL PROTECTED] wrote:
> > it's about time that someone sat down and merged the string and unicode
> > implementations into a single "stringlib" code base (see the SRE sources for
> > an efficient way to do this in plain C). [1]
> [...]
> > 1) anyone want me to start working on this ?
>
> This w
Zitat von Fredrik Lundh <[EMAIL PROTECTED]>:
> it's about time that someone sat down and merged the string and unicode
> implementations into a single "stringlib" code base (see the SRE sources for
> an efficient way to do this in plain C). [1]
[...]
> 1) anyone want me to start working on this ?
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Note: This is just a thought - I haven't looked into the consequences
> of building with VC8 yet, e.g. from the list of pre-requisites,
> it's possible that .NET 2.0 would become a requirement.
>From the FAQ (see other
(manually cross-posting from comp.lang.python)
Ben Cartwright wrote:
> Your evidence points to some unoptimized code in the underlying C
> implementation of Python. As such, this should probably go to the
> python-dev list (http://mail.python.org/mailman/listinfo/python-dev).
> This tactic typi
"Benji York" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> http://msdn.microsoft.com/vstudio/express/default.aspx
>
> The express editions are only "free" until November 7th:
> http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing
One can keep using any
>From comp.lang.python:
[EMAIL PROTECTED] wrote:
> It seems to me that str.count is awfully slow. Is there some reason
> for this?
> Evidence:
>
> str.count time test
> import string
> import time
> import array
>
> s = string.printable * int(1e5) # 10**7 character string
> a = a
PEP 263 states that in Phase 2 the default encoding will be set to
ASCII. Although the PEP is marked final, this isn't actually
implemented. The warning about using non-ASCII characters started in
2.3. Does anyone think we shouldn't enforce the default being ASCII?
This means if an # -*- coding
Zitat von Fredrik Lundh <[EMAIL PROTECTED]>:
> to clarify, the guideline should be "does the new compiler version add some-
> thing important ?", rather than just "is there a new version ?"
In this specific case, the new thing added is the availability of Visual Studio
Express. Whether this is im
Facundo Batista wrote:
> After a small talk with Raymond, yesterday in the breakfast, I
> proposed in PyAr the idea of start to translate the Library Reference.
>
> You'll agree with me that this is a BIG effort. But not only big, it's
> dynamic!
>
> So, we decided that we need a system that prov
> if I could chose, I'd use the same compiler for at least one more release...
to clarify, the guideline should be "does the new compiler version add some-
thing important ?", rather than just "is there a new version ?"
___
Python-Dev mailing list
P
Zitat von Fredrik Lundh <[EMAIL PROTECTED]>:
> it also causes more work for those of us who provide ready-made Windows
> binaries for more than just the latest and greatest Python release.
>
> if I could chose, I'd use the same compiler for at least one more release...
I find this argument convin
M.-A. Lemburg wrote:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
>
> http://msdn.microsoft.com/vstudio/express/default.aspx
>
> I suppose thi
[Alex Martelli wrote]
> What I hear from the rumor mill (not perhaps a reliable source) is a
> bit discouraging about the stability of VS2005 (e.g. internal
> rebellion at MS in which groups which need to ship a lot of code
> pushed back against any attempt to make them use VS2005, and managed
> to
Neil Schemenauer wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>> Why was it decided that the unicode encoding argument should be ignored
>> if the first argument is a string? Wouldn't an exception be better
>> rather than give the impression it does something when it doesn't?
>
>From the PEP:
>
>
Zitat von "M.-A. Lemburg" <[EMAIL PROTECTED]>:
> > What I hear from the rumor mill (not perhaps a reliable source) is a
> > bit discouraging about the stability of VS2005 (e.g. internal
> > rebellion at MS in which groups which need to ship a lot of code
> > pushed back against any attempt to make
Alex Martelli wrote:
> On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Microsoft has recently released their express version of the Visual C++.
>> Given that this version is free for everyone, wouldn't it make sense
>> to ship Python 2.5 compiled with this version ?!
>>
>> http://msdn.m
Zitat von "M.-A. Lemburg" <[EMAIL PROTECTED]>:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
Not in my opinion. People have also commented that th
M.-A. Lemburg wrote:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
>
> http://msdn.microsoft.com/vstudio/express/default.aspx
The express edit
On Monday 27 February 2006 5:51 pm, Alex Martelli wrote:
> On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > Microsoft has recently released their express version of the Visual C++.
> > Given that this version is free for everyone, wouldn't it make sense
> > to ship Python 2.5 compiled with
On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
>
> http://msdn.microsoft.com/vstudio/express
Microsoft has recently released their express version of the Visual C++.
Given that this version is free for everyone, wouldn't it make sense
to ship Python 2.5 compiled with this version ?!
http://msdn.microsoft.com/vstudio/express/default.aspx
I suppose this would make compiling extensions
> If implementing a mime packer is really the only use case
> for base64, then it might as well be removed from the
> standard library, since 99.9% of all programmers will
> never touch it. Those that do will need to have boned up
I use it quite a bit for image processing (converting to and fr
On Sun, Feb 26, 2006 at 11:36:20PM -0600, Tim Peters wrote:
> The buildbot shows that the debug-build test_grammar is dying with a C
> assert failure on all boxes.
>
> In case it helps, in a Windows release build test_transformer is also failing:
All build/test failures introduced by the PEP 308
On 2/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I wouldn't mind seeing one of the early ideas from PEP 340 being resurrected
> some day, such that the signature for the special method was "__next__(self,
> input)" and for the builtin "next(iterator, input=None)"
>
> That would go hand in hand
Just van Rossum wrote:
> > If bytes support the buffer interface, we get another interesting
> > issue -- regular expressions over bytes. Brr.
>
> We already have that:
>
> >>> import re, array
> >>> re.search('\2', array.array('B', [1, 2, 3, 4])).group()
> array('B', [2])
> >>>
>
> Not su
Greg Ewing wrote:
> Raymond Hettinger wrote:
>> Code that
>> uses next() is more understandable, friendly, and readable without the
>> walls of underscores.
>
> There wouldn't be any walls of underscores, because
>
>y = x.next()
>
> would become
>
>y = next(x)
>
> The only time you w
Stephen J. Turnbull wrote:
> Greg> I'd be perfectly happy with ascii characters, but in Py3k,
> Greg> the most natural place to keep ascii characters will be in
> Greg> character strings, not byte arrays.
>
> Natural != practical.
That seems to be another thing we disagree about --
t
Alex Martelli wrote:
> We stole list comprehensions and genexps from Haskell
The idea predates Haskell, I think. I first saw it in
Miranda, and it may have come from something even
earlier -- SETL, maybe?
Greg
___
Python-Dev mailing list
Python-Dev@py
36 matches
Mail list logo
