>> Is threre any chance to fix this bug before releasing 2.5.2?
>> http://bugs.python.org/issue1736
>> It contains potential buffer overrun, I think this is somewhat important.
>> If multibyte support (CharNext) is not needed, I 'll rewrite the patch
>> gracefully.
>
> I'll leave that to MvL to d
On Jan 23, 2008 7:28 PM, ocean <[EMAIL PROTECTED]> wrote:
> Is threre any chance to fix this bug before releasing 2.5.2?
> http://bugs.python.org/issue1736
> It contains potential buffer overrun, I think this is somewhat important.
> If multibyte support (CharNext) is not needed, I 'll rewrite the
Is threre any chance to fix this bug before releasing 2.5.2?
http://bugs.python.org/issue1736
It contains potential buffer overrun, I think this is somewhat important.
If multibyte support (CharNext) is not needed, I 'll rewrite the patch
gracefully.
__
The O'Reilly Open Source Convention (OSCON) is accepting proposals for
tutorials and presentations. The submission period ends Feb 4.
OSCON 2008 will be in Portland, Oregon July 21-25. For more information
and to submit a proposal, see
http://conferences.oreilly.com/oscon/
--
Aahz ([EMAIL PROT
On 1/23/08, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> Gregory P. Smith schrieb:
> > The documentation for the struct module says:
> >
> > http://docs.python.org/dev/library/struct.html#module-struct
> >
> > "short is 2 bytes; int and long are 4 bytes; long long (__int64 on
> Windows)
> > is 8
Guido van Rossum wrote:
> On Jan 23, 2008 12:25 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Giampaolo Rodola' wrote:
Also, *nothing* should go into the 2.4 branch any more *except*
important security patches.
>> ^
>>> http://bugs.python.org/issue1745035
>>> I guess this one
> On Windows lots of modules are linked into the python main dll. The file
> PC/config.c contains a list of all modules. From the point of the
> maintainer it's much easier to link the modules into the main dll
> instead of creating standalone dlls. I also suspect that it's much
> faster because re
Gregory P. Smith schrieb:
> The documentation for the struct module says:
>
> http://docs.python.org/dev/library/struct.html#module-struct
>
> "short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows)
> is 8 bytes"
>
> and lists 'l' and 'L' as the pack code for a C long.
>
>
On Jan 23, 2008 12:25 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Giampaolo Rodola' wrote:
> >> Also, *nothing* should go into the 2.4 branch any more *except*
> >> important security patches.
> ^
> >
> > http://bugs.python.org/issue1745035
> > I guess this one should concern both 2.4
The documentation for the struct module says:
http://docs.python.org/dev/library/struct.html#module-struct
"short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows)
is 8 bytes"
and lists 'l' and 'L' as the pack code for a C long.
As its implemented today, the documentation i
Giampaolo Rodola' wrote:
>> Also, *nothing* should go into the 2.4 branch any more *except*
>> important security patches.
^
>
> http://bugs.python.org/issue1745035
> I guess this one should concern both 2.4 and 2.5 branches.
>
Egregious though the error may be I can't myself see tha
Jason wrote:
> Please note that NaN's are very funky and platform dependent. They
> depend on their underlying platform's C library for creation and
> display. On windows, "float('nan')" will cause an exception, as there
> are no valid string representations of NAN that can be converted to
> the
Thomas Heller wrote:
> Here is another typo (?) in the pep; I think it should be changed:
>
> Index: pep-3118.txt
> ===
> --- pep-3118.txt (revision 60037)
> +++ pep-3118.txt (working copy)
> @@ -338,7 +338,7 @@
>
> ``le
> Also, *nothing* should go into the 2.4 branch any more *except*
> important security patches.
http://bugs.python.org/issue1745035
I guess this one should concern both 2.4 and 2.5 branches.
On 23 Gen, 05:47, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> While the exact release schedule for 2.5
Travis Oliphant schrieb:
[...]
> I responded off list to this email and wanted to summarize my response
> for others to peruse.
>
> Basically, the answer is that the struct syntax proposed for
> multi-dimensional arrays is not intended to mimic how the C-compiler
> handles statically defined
On Jan 23, 2008 7:40 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
> In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
> do the heavy lifting. If someone is planning on implementing
> PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess
> I'll either do it mysel
In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
do the heavy lifting. If someone is planning on implementing
PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess
I'll either do it myself, or hack around it.
Is this on anyone's To Do list? I don't see
Travis,
Perhaps you can add this rationale to the PEP? It seems helpful and
might stave off future confusion.
--Guido
On Jan 23, 2008 8:17 AM, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Thomas Heller wrote:
> > Hi Travis,
> >
> > The pep contains this sample:
> >
> > """
> > Nested array
> >
I've been working on a project that renders PKG-INFO metadata in a
number of ways. I have noticed that fields with any indentation were
flattened out, which is being done in distutils.util.rfc822_escape.
This unfortunately means that you cant use reStructuredText formatting
in your long description
Thomas Heller wrote:
> Hi Travis,
>
> The pep contains this sample:
>
> """
> Nested array
> ::
>
> struct {
> int ival;
> double data[16*4];
> }
> """i:ival:
>(16,4)d:data:
> """
> """
>
> I think it is wrong and must b
On Jan 23, 2008 3:19 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Steven Bethard]
>
> >We've already lost this if anyone really wants to break it::
> >
> >>>> class C(object):
> >... def __iter__(self):
> >... return iter(xrange(3))
> >... def __contains__(sel
Hello,
Ralf Schmitt:
> > It's not an ugly hack, it's a well known feature. Add you don't have to
> > change a lot of places, too. It's sufficient to add the alias at the
> > entry point of your application (the script that starts your app). Once
> > the alias sys.modules]'mmap'] = ralfmmap is set,
On Jan 23, 2008 9:35 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> It's not an ugly hack, it's a well known feature. Add you don't have to
> change a lot of places, too. It's sufficient to add the alias at the
> entry point of your application (the script that starts your app). Once
> the al
Ralf Schmitt wrote:
>> Why do you want to overwrite the existing module instead of using a
>> different name like ralfmmap?
>>
>> import ralfmmap as mmap
>> sys.modules]'mmap'] = mmap
>>
>
> I thought about that (ugly hack) too. I would have to change the imports at
> a lot of places (and revert t
On Jan 23, 2008 9:01 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> >
> > What is the reason for mmap being a builtin module?
>
> On Windows lots of modules are linked into the python main dll. The file
> PC/config.c contains a list of all modules. From the point of the
> maintainer it's much e
Ralf Schmitt wrote:
> Hi all,
>
> I want to use the mmap module from python trunk with python 2.5.
> On Linux I can easily replace it, as it is a dynamically loaded module. On
> windows
> it is a builtin module and I fear that I must compile python on windows (or
> resort to some other ugly hack)
26 matches
Mail list logo
