Re: [Python-Dev] why is mmap a builtin module on windows?
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) > > 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 easier to link the modules into the main dll instead of creating standalone dlls. I also suspect that it's much faster because relocation is slow (see PC/dllbase_nt.txt). Martin or Mark can give you a better answer. 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 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is mmap a builtin module on windows?
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 easier to link the modules into the main dll > instead of creating standalone dlls. I also suspect that it's much > faster because relocation is slow (see PC/dllbase_nt.txt). Martin or > Mark can give you a better answer. > ok > > 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 the changes when we switch to python 2.6). (whereas on Unix I would only have to do install the new mmap module). - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is mmap a builtin module on windows?
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 the changes when we switch to python 2.6). > (whereas on Unix I would only have to do install the new mmap module). 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, every import mmap gets your ralfmmap. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is mmap a builtin module on windows?
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 alias sys.modules]'mmap'] = ralfmmap is set, every import mmap gets > your ralfmmap. Well, I have multiple scripts using multiple libraries using the new mmap objects. So, I would have to change those scripts (if I don't change the libraries), or change the libraries. And when I want to distribute my apps with bbfreeze (similar to py2exe), I also need to handle that import hackery. This is what I call ugly :) (at least in comparison to linux). Regards, - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is mmap a builtin module on windows?
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, every import mmap gets > > your ralfmmap. > > Well, I have multiple scripts using multiple libraries using the new mmap > objects. > So, I would have to change those scripts (if I don't change the libraries), > or change the libraries. And when I want to distribute my apps with bbfreeze > (similar to py2exe), I also need to handle that import hackery. This is > what I call ugly :) (at least in comparison to linux). You can also modify site.py and put the hack there. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] misbehaving __contains__
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__(self, item): > >... return False [snip] > I'm more concerned about introducing an API where well-meaning attempts to > code a __contains__ override will implicitly shoot the toes off of client > code that innocently assumes a somewhat sensible invariant relation between > looping over elements in a container and those elements being in the > container. The code for sets and frozensets makes that assumption, for > example. And, when the code does break, the errors will be darned hard to > find. well, i don't see how limiting __contains__ to returning booleans solves the problem you mentioned. what you're talking about is *semantics*, and that's always up to the programmer to get right. allowing __contains__ to return a FooBar object won't change that a bit -- but it will allow me to construct expression objects more easily. and, statements like if x in y: pass will work as expected, assuming the object returned by y.__contains__(x) has a proper __bool__/__nonzero__ method. we're just deferring the type-cast to the point it's actually needed. as per performance, i don't believe changing a slot method to return PyObject* instead of int would change anything... am i wrong? -tomer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
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 be changed to the following; is this correct?
>
> """
> Nested array
> ::
>
> struct {
> int ival;
> double data[16][4];
> }
> """i:ival:
>(16,4)d:data:
> """
> """
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 C-arrays (i.e. the pointer-to-pointers style
of multi-dimensional arrays). It is intended to handle the
contiguous-block-of-data style of multi-dimensional arrays that NumPy uses.
I wanted to avoid 2-d static arrays in the examples because it gets
confusing and AFAIK the layout of the memory for a double data[16][4] is
the same as data[16*4]. The only difference is how the C-compiler
translates data[4][3] and data[4].
The intent of the struct syntax is to handle describing memory. The
point is not to replicate how the C-compiler deals with statically
defined N-D arrays. Thus, even though the struct syntax allows
*communicating* the intent of a contiguous block of memory inside a
structure as an N-d array, the fundamental memory block is the
equivalent of a 1-d array in C.
So, I think the example is correct (and intentional).
-Travis O.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rfc822_escape doing the right thing?
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 (suggested in PEP345), or are limited to a set that doesn't require indentation (no block quotes, etc.). It looks like this behavior was intentionally added in rev 20099, but that was about 7 years ago - before reStructuredText and eggs. I wonder if it makes sense to re-think that implementation with this sort of metadata in mind, assuming this behavior isn't required to be rfc822 compliant. I think it would certainly be a shame to miss out on a good thing like proper (renderable) reST in our metadata. A quick example of what I mean: >>> rest = """ ... a literal python block:: ... >>> import this ... """ >>> print distutils.util.rfc822_escape(rest) a literal python block:: >>> import this should look something like: a literal python block:: >>> import this Is distutils being over-cautious in flattening out all whitespace? A w3c discussion on multiple lines in rfc822 [1] seems to suggest that whitespace can be 'unfolded' safely, so it seems a shame to be throwing it away when it can have important meaning. [1] http://www.w3.org/Protocols/rfc822/3_Lexical.html Thanks for any comments Stephen Emslie ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
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
> > ::
> >
> > struct {
> > int ival;
> > double data[16*4];
> > }
> > """i:ival:
> >(16,4)d:data:
> > """
> > """
> >
> > I think it is wrong and must be changed to the following; is this correct?
> >
> > """
> > Nested array
> > ::
> >
> > struct {
> > int ival;
> > double data[16][4];
> > }
> > """i:ival:
> >(16,4)d:data:
> > """
> > """
>
> 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 C-arrays (i.e. the pointer-to-pointers style
> of multi-dimensional arrays). It is intended to handle the
> contiguous-block-of-data style of multi-dimensional arrays that NumPy uses.
>
> I wanted to avoid 2-d static arrays in the examples because it gets
> confusing and AFAIK the layout of the memory for a double data[16][4] is
> the same as data[16*4]. The only difference is how the C-compiler
> translates data[4][3] and data[4].
>
> The intent of the struct syntax is to handle describing memory. The
> point is not to replicate how the C-compiler deals with statically
> defined N-D arrays. Thus, even though the struct syntax allows
> *communicating* the intent of a contiguous block of memory inside a
> structure as an N-d array, the fundamental memory block is the
> equivalent of a 1-d array in C.
>
> So, I think the example is correct (and intentional).
>
> -Travis O.
>
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is anyone porting PyNumber_ToBase to trunk?
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 it on Brett's spreadsheet at http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is anyone porting PyNumber_ToBase to trunk?
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 myself, or hack around it. > > Is this on anyone's To Do list? I don't see it on Brett's spreadsheet > at http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg I'm sure this is because nobody had thought of this detail until now. Just get started on it. Feel free to add it to the spreadsheet. (Anyone who needs an invite for editing the spreadsheet, let me know the email to which I should send it to -- either a gmail address or an email associated with a Google account. If you don't have a Google account yet, go here: https://www.google.com/accounts/NewAccount -- no gmail address needed!) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
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 C-arrays (i.e. the pointer-to-pointers style > of multi-dimensional arrays). It is intended to handle the > contiguous-block-of-data style of multi-dimensional arrays that NumPy uses. > > I wanted to avoid 2-d static arrays in the examples because it gets > confusing and AFAIK the layout of the memory for a double data[16][4] is > the same as data[16*4]. The only difference is how the C-compiler > translates data[4][3] and data[4]. > > The intent of the struct syntax is to handle describing memory. The > point is not to replicate how the C-compiler deals with statically > defined N-D arrays. Thus, even though the struct syntax allows > *communicating* the intent of a contiguous block of memory inside a > structure as an N-d array, the fundamental memory block is the > equivalent of a 1-d array in C. > > So, I think the example is correct (and intentional). Sorry, I do not think so. If you use a 2-d array in the example, you must describe it correctly. The difference between this pep and the old buffer interface is that the pep allows to describe both how the compiler sees the memory block plus the size and layout of the memory block, while the old buffer interface only describes single-segment memory blocks. And 'double data[16][4]' *is* a single memory block containing a 2-d array, and *not* an array of pointers. --- 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 @@ ``len`` the total bytes of memory the object uses. This should be the -same as the product of the shape array multiplied by the number of +same as the length of the shape array multiplied by the number of bytes per item of memory. ``readonly`` After all, imo there's a lot to do to fully implement the pep for python 2.6. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
> 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.2 is still up in the air, I > expect that it will be within a few weeks. This means that we need to > make sure that anything that should go into 2.5.2 goes in ASAP, > preferably this week. It also means that we should be very careful > what goes in though -- and we should be paying particular attention to > stability on all platforms! Fortunately it looks like quite a few 2.5 > buildbots are green:http://python.org/dev/buildbot/2.5/ > > I propose that anything that ought to go into 2.5.2 (or should be > reviewed for suitability to go into it) should be marked "urgent" in > the tracker, *and* have its version set to (or include) "Python 2.5". > > Also, *nothing* should go into the 2.4 branch any more *except* > important security patches. If we're doing a security release, it'll > most likely be a source-only release, and it will differ from 2.4.4 > only in that it will have some new security patches defined. > > A reminder: 2.5.2 should only get bugfixes, new features. > > -- > --Guido van Rossum (home page:http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
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 @@
>
> ``len``
> the total bytes of memory the object uses. This should be the
> -same as the product of the shape array multiplied by the number of
> +same as the length of the shape array multiplied by the number of
> bytes per item of memory.
>
> ``readonly``
While the original could be reworded ("product of the elements of the shape
array"), the amendment is incorrect. For a shape array like {4*5*6}, the number
of bytes is (4*5*6)*bytes_per_item, not 3*bytes_per_item.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] math and numerical fixes (was: When is min(a, b) != min(b, a)?)
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 special floating point value. Also, if you manage to create a nan
> under Windows, it displays as "1.#QNAN".
>
> Infinite values are also problematic. In almost all cases, it is far
> better to avoid infinite and NaN values.
CC to Python Dev
I've fixed that and enhanced the support for NaN and inf for 2.6 and
3.0. I'm working together with Mark on more NaN and inf related fixes
and he has fixed some numerical issues in the cmath module. We both hope
to get Python's math more sound and stable across platforms.
So far I got float('nan'), float('inf') and float('-inf') working on all
platforms. The math module got three new methods: isinf, isnan, copysign.
Additionally the trunk-math branch contains code for inverse hyberbolic
functions (acosh), log1p, Mark's fixes for complex math and more stuff.
For example operations on NaNs now return a NaN on all platforms (except
1**NAN which is defined as 1 and 0**NAN which is defined as 0). In 2.5
it depends on the platform whether a function raises an exception or
returns NaN.
Mark had the nice idea to introduce a thread local or global flag for
NaN support. Depending on a flag Python turns a NaN into an exception.
The feature needs a proper PEP. Maybe Mark has time to write a PEP in time.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
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 that a complete new release is justified simply to include a four-line patch in a single (not often-used?) module. If it were a buffer overflow it might be different (but that would pretty much have to involve a C component). Couldn't we just publicize the patch? I can't bring myself to believe that 1745035 is really "important" enough. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] struct module docs vs reality
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 is incorrect. On an LP64 host (pretty much any 64-bit linux, bsd or unixish thing) a long is 8 bytes. I assume this means there is existing code out there that expects the current not-as-documented behavior. There is also code out there that expects the documented behavior but behaves wrong when a 64bit Python is used. I assume I should just fix the documentation and anything in Lib that uses the struct module incorrectly (zipfile for example) rather than change the behavior? This is for http://bugs.python.org/issue1789 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
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 and 2.5 branches. > > > > Egregious though the error may be I can't myself see that a complete new > release is justified simply to include a four-line patch in a single > (not often-used?) module. If it were a buffer overflow it might be > different (but that would pretty much have to involve a C component). > > Couldn't we just publicize the patch? I can't bring myself to believe > that 1745035 is really "important" enough. It should go into 2.5 for sure. It should go into 2.4 at the discretion of the release manager. We *are* considering a pure-security-fixes source-only release of 2.4 (I wasn't 100% clear on that in my first mail in this thread). IMO DoS vulnerabilities are rarely worth getting excited about, unless they have the potential of bringing down a significant portion of the internet. This one doesn't. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module docs vs reality
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. > > As its implemented today, the documentation is incorrect. On an LP64 host > (pretty much any 64-bit linux, bsd or unixish thing) a long is 8 bytes. > > I assume this means there is existing code out there that expects the > current not-as-documented behavior. There is also code out there that > expects the documented behavior but behaves wrong when a 64bit Python is > used. > > I assume I should just fix the documentation and anything in Lib that uses > the struct module incorrectly (zipfile for example) rather than change the > behavior? +1 (actually +100) from me. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why is mmap a builtin module on windows?
> 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 relocation is slow (see PC/dllbase_nt.txt). Martin or > Mark can give you a better answer. Actually, that *is* the current answer. That plus a remark "Contributions are welcome, as long as they a) come with a clear, objective policy on what should go into pythonxy.dll and what not, and b) automate all aspects of adding modules that should not go into pythonxy.dll according to the policy." Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
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 should concern both 2.4 and 2.5 branches. >>> >> Egregious though the error may be I can't myself see that a complete new >> release is justified simply to include a four-line patch in a single >> (not often-used?) module. If it were a buffer overflow it might be >> different (but that would pretty much have to involve a C component). >> >> Couldn't we just publicize the patch? I can't bring myself to believe >> that 1745035 is really "important" enough. > > It should go into 2.5 for sure. It should go into 2.4 at the > discretion of the release manager. We *are* considering a > pure-security-fixes source-only release of 2.4 (I wasn't 100% clear on > that in my first mail in this thread). > > IMO DoS vulnerabilities are rarely worth getting excited about, unless > they have the potential of bringing down a significant portion of the > internet. This one doesn't. > Yes. There has to be a 2.5.2 release and there's no reason to exclude it from that. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module docs vs reality
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 bytes" > > > > and lists 'l' and 'L' as the pack code for a C long. > > > > As its implemented today, the documentation is incorrect. On an LP64 > host > > (pretty much any 64-bit linux, bsd or unixish thing) a long is 8 bytes. > > > > I assume this means there is existing code out there that expects the > > current not-as-documented behavior. There is also code out there that > > expects the documented behavior but behaves wrong when a 64bit Python is > > used. > > > > I assume I should just fix the documentation and anything in Lib that > uses > > the struct module incorrectly (zipfile for example) rather than change > the > > behavior? > > +1 (actually +100) from me. > > Thomas Ok, its a pretty big diff. Much of the standard library is completely broken when used on LP64 platforms. I added it to the bug. I'm running unit tests now. These fixes should go into 2.5.2. The diff could use some eyes on it, especially the Mac API stuff that I know nothing about but am assuming relies on 32bit values. http://bugs.python.org/issue1789 Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] REMINDER: OSCON 2008 Call for Proposals
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 PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
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 patch > gracefully. I'll leave that to MvL to decide; given that AFAIK msilib is only used to build the Python installer I'm not sure it's worth defending against malicious code -- it would be easier to simply remove it from an installation if you have reason to believe you might be executing malicious Python code. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
>> 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 decide; given that AFAIK msilib is only used > to build the Python installer I'm not sure it's worth defending > against malicious code -- it would be easier to simply remove it from > an installation if you have reason to believe you might be executing > malicious Python code. > I'll look into it. msilib is used in distutils (for bdist_msi), so it should get fixed. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
