Re: [Python-Dev] Module renaming and pickle mechanisms

[Georg Brandl]

Benjamin Peterson schrieb:


svnmerge is written in Python, so wouldn't it be possible to add
support for maintaining such renaming to that tool ?


svnmerge.py is mostly a wrapper over svn merge, and svn merge can't
handle it, so I don't think is easily possible.


I don't think that an administrative problem such as forward-
porting patches to 3.x warrants breakage in the 2.x branch.


I am a bit worried for the sanity of the Merger, though. Merges into
non-existent files are skipped automatically, so it doesn't make life
any easier.


Bazaar can handle renames
correctly.


So can dozens of other VCSs. Just to keep perspective.

Georg

___
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] Module renaming and pickle mechanisms

[Brett Cannon]

On Mon, May 19, 2008 at 12:26 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:

 M.-A. Lemburg wrote:
>
> Perhaps I have a misunderstanding of the reasoning behind
> doing the renaming in the 2.x branch, but it appears that
> the only reason is to get used to the new names. That's a
> rather low priority argument in comparison to the breakage
> the renaming will cause in the 2.x branch.

 I think this is the key point here. The possibility of breaking pickling
 compatibility never came up during the PEP 3108 discussions, so wasn't
 taken
 into account in deciding whether or not backporting the name changes was
 a
 good idea.

 I think it's pretty clear that the code needs to be moved back into the
 modules with the old names for 2.6. The only question is whether or not
 we
 put any effort into making the new stdlib organisation usable in 2.x, or
 just rely on 2to3 to fix it (note that the "increasing the common subset"
 argument doesn't really apply, since you can catch the import errors in
 order to try both names).
>>>
>>> Problem with this is it makes forward-porting revisions to 3.0 a PITA.
>>> By keeping the module names consistent between the versions merging a
>>> revision is just a matter of ``svnmerge merge`` with the usual
>>> 3.0-specific changes. Reverting the modules back to the old name will
>>> make forward-porting much more difficult as I don't think svn keeps
>>> rename information around (and thus map the old name to the new name
>>> in terms of diffs).
>>
>> svnmerge is written in Python, so wouldn't it be possible to add
>> support for maintaining such renaming to that tool ?
>>
>
> Don't know, possibly. But I am not about to try to figure out.
>
>> I don't think that an administrative problem such as forward-
>> porting patches to 3.x warrants breakage in the 2.x branch.
>>
>
> That's why I suggested changing pickle to deal with the rename, but
> obviously I am in the minority in that idea.
>
>> After all, the renaming was approached for Python 3.0 and not
>> 2.6 *because* it introduces major breakage.
>>
>> AFAIR, the discussion on the stdlib-sig also didn't include the
>> plan to backport such changes to 2.6. Otherwise, we would have
>> hashed them out there.
>>
>
> Never came up.
>
>>> Alexandre's idea of teaching pickle the mapping of old names to new
>>> might be the best solution. We could have a flag to pickle that
>>> deactivates the renaming. Otherwise we could bump the pickle version
>>> number so that the new number doesn't do the mapping while the old
>>> versions to the implicit module mapping.
>>>
>>> And as Greg and Glpyh have pointed out, this is a problem that might
>>> need to be addressed in the future with some changes to our
>>> serialization method (I have no clue how since I don't deal with
>>> pickle very much).
>>
>> It is possible to make pickle aware of the module renames, but
>> that doesn't solve problems with other forms of serialization
>> or use of the .__module__ attribute in general.
>>
>> Why can't we just provide a "from __future__ import renamed_modules"
>> which then provides all the new name to old name mappings in
>> some form (e.g. module proxies or whatever) and leave the
>> existing modules in 2.x untouched ?
>
> I have started a discussion on the stdlib SIG on how to handle this,
> so I will defer this discussion to there.
>

The decision was made (by me) to just revert all of the renames in
2.6. A note will be in the docs stating the rename, but otherwise 2to3
will be relied upon for all transitions from old names to new names.

I have updated the PEP to note about which modules need to be reverted
and the new steps to rename a module, and added/re-opened the
appropriate issues (all attached to issue 2775).

-Brett
___
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] Unaccompanied Patch

[Steve Holden]

Benjamin Peterson wrote:

On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:

On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:

Hi all,

I created a patch on 2007-08-15:
 http://bugs.python.org/issue1775025

I wonder, will it just stay in patches unnoticed until it has its very
own associated bug report to keep it company?

At the moment, I only see a doc patch.


Sorry, that didn't come out they way I wanted it to. I meant that the
doc patch will have to be converted to reST.



Well, looky here:

zipfile_62920.diff   grahamh, 2008-05-19 23:49  Updated + doc -> reST

That was quick. I'm not in a position to svn update were I am. Looks 
like someone's paying attention, though.


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] Addition of "pyprocessing" module to standard lib.

[Steve Holden]

Bill Janssen wrote:

On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:

If you can run a pure Python module
that does not depend on any C extension, then that platform has the
support needed to run Python.

This is certainly a point of view.  One that many end-users wouldn't
understand :-).

Perhaps, but it's clear-cut. Is OS X not properly supported because it
can't run the _winreg module? I just don't like labeling a platform as
unsupported just because ctypes doesn't compile on it.


I assume _winreg runs everywhere Python is said to run, and there's a
Windows registry to examine, so I think it's a different kettle of
fish.  ctypes doesn't run everywhere Python is said to run, and there
are dynamic libraries to call into.

I think it would be great if we could get some AIX, HP-UX, and Solaris
boxes for Thomas to work on.  What would motivate IBM, H-P, and Sun to
donate such gear?  Perhaps each of the companies have an office
somewhere that could help with this resource allocation?  For
instance, talking to the "AIX Collaboration Center" of IBM
([EMAIL PROTECTED])?

And these are all SYSV derivatives, aren't they?  So perhaps it's some
common fix for all three?

OK, I know people in Sun and possibly H-P I could ask, and I may have an 
arm or two to twist to get to IBM. But worst-case, what budget would the 
infrastructure committee need for the hardware and (more importantly) if 
the hardware materialized, would there be manpower to maintain the 
platforms as "Python supported"?


The more libraries that use ctypes to call into native functionality, 
the more important it becomes to have ctypes run, even if only to 
implement platform-specific functionality on the given platforms. I 
would like "being able to call a wide range of native libraries" to be a 
Python claim on all platforms, even when the native libraries are 
platform-proprietary.


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] Addition of "pyprocessing" module to standard lib.

[Bill Janssen]

> On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> If you can run a pure Python module
> >> that does not depend on any C extension, then that platform has the
> >> support needed to run Python.
> >
> > This is certainly a point of view.  One that many end-users wouldn't
> > understand :-).
> 
> Perhaps, but it's clear-cut. Is OS X not properly supported because it
> can't run the _winreg module? I just don't like labeling a platform as
> unsupported just because ctypes doesn't compile on it.

I assume _winreg runs everywhere Python is said to run, and there's a
Windows registry to examine, so I think it's a different kettle of
fish.  ctypes doesn't run everywhere Python is said to run, and there
are dynamic libraries to call into.

I think it would be great if we could get some AIX, HP-UX, and Solaris
boxes for Thomas to work on.  What would motivate IBM, H-P, and Sun to
donate such gear?  Perhaps each of the companies have an office
somewhere that could help with this resource allocation?  For
instance, talking to the "AIX Collaboration Center" of IBM
([EMAIL PROTECTED])?

And these are all SYSV derivatives, aren't they?  So perhaps it's some
common fix for all three?

Bill
___
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] Addition of "pyprocessing" module to standard lib.

[Brett Cannon]

On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If you can run a pure Python module
>> that does not depend on any C extension, then that platform has the
>> support needed to run Python.
>
> This is certainly a point of view.  One that many end-users wouldn't
> understand :-).

Perhaps, but it's clear-cut. Is OS X not properly supported because it
can't run the _winreg module? I just don't like labeling a platform as
unsupported just because ctypes doesn't compile on it.

-Brett
___
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] Addition of "pyprocessing" module to standard lib.

[Bill Janssen]

> If you can run a pure Python module
> that does not depend on any C extension, then that platform has the
> support needed to run Python.

This is certainly a point of view.  One that many end-users wouldn't
understand :-).

Bill
___
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] buffer interface for C extensions

[Dan Lenski]

On Sun, 18 May 2008 22:59:05 +, Dan Lenski wrote:
> So here's what I don't understand.  Why doesn't the "t#" argument
> specifier support read-write buffers as well as read-only buffers? 
> Aren't read-write buffers a *superset* of read-only buffers??  Is there
> something I'm doing wrong or a quick fix to get this to work
> appropriately?

So... I've answered my own question on this.  I had a look in getargs.c, 
and apparently the "t#" argument specifier only accepts *character-based* 
readable buffers.

Is there any chance anyone of adding an argument specifier for readable 
buffers in general?  Say, "r#"?

Can anyone explain to me the rationale for having some data type support 
the readable buffer interface, but /NOT/ the character-based buffer 
interface?  I can't find any information that explains the fundamental 
distinction between the two... and I don't see why array('B') shouldn't 
support both.

Dan

___
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] Unaccompanied Patch

[Benjamin Peterson]

On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I created a patch on 2007-08-15:
>>  http://bugs.python.org/issue1775025
>>
>> I wonder, will it just stay in patches unnoticed until it has its very
>> own associated bug report to keep it company?
>
> At the moment, I only see a doc patch.

Sorry, that didn't come out they way I wanted it to. I meant that the
doc patch will have to be converted to reST.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Unaccompanied Patch

[Benjamin Peterson]

On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I created a patch on 2007-08-15:
>  http://bugs.python.org/issue1775025
>
> I wonder, will it just stay in patches unnoticed until it has its very
> own associated bug report to keep it company?

At the moment, I only see a doc patch.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Unaccompanied Patch

[Brett Cannon]

On Mon, May 19, 2008 at 3:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I created a patch on 2007-08-15:
>  http://bugs.python.org/issue1775025
>
> I wonder, will it just stay in patches unnoticed until it has its very
> own associated bug report to keep it company?

Being a patch does not mean it is ignore (actually, it raises the
chance it will be noticed). It's just that developer time is limited
and so someone has to just take enough interest in the patch to review
it, apply it, etc. We no longer distinguish issues between patches and
bugs; when a bug gets an attached patch we just set the proper
keyword. So creating a separate issue will just lead to it being
closed as being superceded by the patch.

-Brett
___
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] Module renaming and pickle mechanisms

[Brett Cannon]

On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:

 M.-A. Lemburg wrote:
>
> Perhaps I have a misunderstanding of the reasoning behind
> doing the renaming in the 2.x branch, but it appears that
> the only reason is to get used to the new names. That's a
> rather low priority argument in comparison to the breakage
> the renaming will cause in the 2.x branch.

 I think this is the key point here. The possibility of breaking pickling
 compatibility never came up during the PEP 3108 discussions, so wasn't
 taken
 into account in deciding whether or not backporting the name changes was
 a
 good idea.

 I think it's pretty clear that the code needs to be moved back into the
 modules with the old names for 2.6. The only question is whether or not
 we
 put any effort into making the new stdlib organisation usable in 2.x, or
 just rely on 2to3 to fix it (note that the "increasing the common subset"
 argument doesn't really apply, since you can catch the import errors in
 order to try both names).
>>>
>>> Problem with this is it makes forward-porting revisions to 3.0 a PITA.
>>> By keeping the module names consistent between the versions merging a
>>> revision is just a matter of ``svnmerge merge`` with the usual
>>> 3.0-specific changes. Reverting the modules back to the old name will
>>> make forward-porting much more difficult as I don't think svn keeps
>>> rename information around (and thus map the old name to the new name
>>> in terms of diffs).
>>
>> svnmerge is written in Python, so wouldn't it be possible to add
>> support for maintaining such renaming to that tool ?
>
> svnmerge.py is mostly a wrapper over svn merge, and svn merge can't
> handle it, so I don't think is easily possible.

I think MAL was suggesting add some property that kept track of
skipped merges or something.

>>
>> I don't think that an administrative problem such as forward-
>> porting patches to 3.x warrants breakage in the 2.x branch.
>
> I am a bit worried for the sanity of the Merger, though. Merges into
> non-existent files are skipped automatically, so it doesn't make life
> any easier.
>

It will either have to be done in 2.6 and the immediately
forward-ported or done in 3.0 and backported. I will follow the latter
IF I feel like bothering with the backport.

>
> Bazaar can handle renames
> correctly.

Yeah, yeah. One thing at a time.

-Brett
___
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] Unaccompanied Patch

[Graham Horler]

Hi all,

I created a patch on 2007-08-15:
  http://bugs.python.org/issue1775025

I wonder, will it just stay in patches unnoticed until it has its very
own associated bug report to keep it company?

Thanks,
Graham
___
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] Importing bsddb 4.6.21; with or without AES encryption?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Trent Nelson wrote:
| I downloaded the source that includes AES encryption, for no reason
| other than it was first on the list.  I'm now wondering if we should
| only be importing the 'NC' source that doesn't contain any
| encryption?  Jesus, does pybsddb use any of the Berkeley DB
| encryption facilities?  Would anything break if we built the
| bsddb module without encryption?

Yes, pybsddb3 4.6.4 supports cryptography if the underlying Berkeley DB
library is crypto enabled.

In principle, you can compile BDB without crypto, and pybsddb3 should
work, but you would lose ability to open any DB formerly created using
page encryption or page checksum.

Export laws aside, we better compile with crypto :).

Details:
http://www.jcea.es/programacion/pybsddb_doc/dbenv.html#set_encrypt


- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
~   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSDIDWplgi5GaxT1NAQKaagP+Myn6t364B9cVMUtlKjTIX1LBZkkEG7SX
pv+hjUZ68r0Suw8SkhXnBbL2Ek3/yFhvNHH8qAZvEtRGsFGmKiNXccn9Ce3oy0me
rAYhuuICleAUJ8RO8FZz+sGK3SR4kITrqnGfMnG46u0rXDQy82NSRW2+uWz/D96d
U+X/wfV2HgQ=
=io+q
-END PGP SIGNATURE-
___
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] Module renaming and pickle mechanisms

[Benjamin Peterson]

On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:

 Perhaps I have a misunderstanding of the reasoning behind
 doing the renaming in the 2.x branch, but it appears that
 the only reason is to get used to the new names. That's a
 rather low priority argument in comparison to the breakage
 the renaming will cause in the 2.x branch.
>>>
>>> I think this is the key point here. The possibility of breaking pickling
>>> compatibility never came up during the PEP 3108 discussions, so wasn't
>>> taken
>>> into account in deciding whether or not backporting the name changes was
>>> a
>>> good idea.
>>>
>>> I think it's pretty clear that the code needs to be moved back into the
>>> modules with the old names for 2.6. The only question is whether or not
>>> we
>>> put any effort into making the new stdlib organisation usable in 2.x, or
>>> just rely on 2to3 to fix it (note that the "increasing the common subset"
>>> argument doesn't really apply, since you can catch the import errors in
>>> order to try both names).
>>
>> Problem with this is it makes forward-porting revisions to 3.0 a PITA.
>> By keeping the module names consistent between the versions merging a
>> revision is just a matter of ``svnmerge merge`` with the usual
>> 3.0-specific changes. Reverting the modules back to the old name will
>> make forward-porting much more difficult as I don't think svn keeps
>> rename information around (and thus map the old name to the new name
>> in terms of diffs).
>
> svnmerge is written in Python, so wouldn't it be possible to add
> support for maintaining such renaming to that tool ?

svnmerge.py is mostly a wrapper over svn merge, and svn merge can't
handle it, so I don't think is easily possible.
>
> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.

I am a bit worried for the sanity of the Merger, though. Merges into
non-existent files are skipped automatically, so it doesn't make life
any easier.


Bazaar can handle renames
correctly.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Addition of "pyprocessing" module to standard lib.

[A.M. Kuchling]

On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> Myself I would rather spend my energy to make ctypes more portable, within my
> skills and the platforms I have access to.

Someone could run Solaris x86 inside a hosted virtual machine and make
it available to the Python developers.  Is it possible to find similar
hosting for HP-UX and AIX?  Or might IBM or HP be willing to donate a
low-end machine to the PSF for porting use?

--amk

___
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] Symbolic errno values in error messages

[Georg Brandl]

Yannick Gingras schrieb:

"Alexandre Vassalotti" <[EMAIL PROTECTED]> writes:


So now I am not sure what OP is proposing.  Do you want to replace 21
with EISDIR in the above?


Yes, that's what I had in mind.



Then, check out EnvironmentError_str in Objects/exceptions.c. You
should be able import the errno module and fetch its errorcode
dictionary.


It wasn't as hard as I expected.  It's the first time that I play with
the Python C API; I didn't expect the API to be that high level.

I attached a patch to convert errno to its symbolic value when an
EnvironmentError is printed.  Should attach it to a ticket on
bugs.python.org?

I'm sure there is a style guide like PEP-8 for C code, feel free to
point me to it because my patch is probably not fully style compliant.

With Emacs, doing

 M-x c-set-style python

doesn't seems to do the right thing.  Are you all using a bunch of
shared settings in you .emacs files?


For new-style Python C files, this style definition works well:

(c-add-style
 "python-new"
 '((indent-tabs-mode . nil)
   (fill-column  . 78)
   (c-basic-offset   . 4)
   (c-offsets-alist  . ((substatement-open . 0)
(inextern-lang . 0)
(arglist-intro . +)
(knr-argdecl-intro . +)))
   (c-hanging-braces-alist . ((brace-list-open)
  (brace-list-intro)
  (brace-list-close)
  (brace-entry-open)
  (substatement-open after)
  (block-close . c-snug-do-while)))
   (c-block-comment-prefix . "* "))
 )

This is a very crude hook that auto-selects the C style depending on
whether it finds a line starting with tab in the first 3000 characters
in the file:

(defun c-select-style ()
  (save-excursion
(if (re-search-forward "^\t" 3000 t)
(c-set-style "python")
  (c-set-style "python-new"
(add-hook 'c-mode-hook 'c-select-style)

HTH,
Georg

___
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] Symbolic errno values in error messages

[Yannick Gingras]

"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Have you considered whether this works on all platforms? (E.g.
> Windows, or embedded non-Unix-based.)

Yes but I guess I didn't comment it properly.  The line

   printed_errno = errno_str ? errno_str : self->myerrno;

ensures that we gracefully fallback to numeric errno when here is no
symbolic value available.  The code is only invoked if there is an
errno value, which takes care of most non-Unix platforms.

-- 
Yannick Gingras
___
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] Module renaming and pickle mechanisms

[M.-A. Lemburg]

On 2008-05-19 21:26, Brett Cannon wrote:

It is possible to make pickle aware of the module renames, but
that doesn't solve problems with other forms of serialization
or use of the .__module__ attribute in general.

Why can't we just provide a "from __future__ import renamed_modules"
which then provides all the new name to old name mappings in
some form (e.g. module proxies or whatever) and leave the
existing modules in 2.x untouched ?


I have started a discussion on the stdlib SIG on how to handle this,
so I will defer this discussion to there.


Thanks.


But one thing that needs to be decided is if we are ever going to
allow ourselves to rename modules without a major version bump, and if
so how to deal with this problem. I would hope we don't have to wait
another eight years before there is another chance to shift things
around if it becomes apparent that some new package should be
introduced since 2to3 gives us a very nice way to handle the
mechanical aspect of porting code.


We could some kind of module aliasing support to Python.

Backporting name changes would then be a matter of loading
the right aliasing map into the older Python version.

This could probably be done by adding a line

if hasattr(sys, 'module_aliases'):
modname = sys.module_aliases.get(modname, modname)

to the __import__ implementation.

By turning .__module__ into a property and applying the same
aliasing there, we should be able to resolve most technical
issues with a renaming.

Alas, too late to change 2.4 and 2.5 :-/

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Addition of "pyprocessing" module to standard lib.

[Brett Cannon]

On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
>
>> On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> As long as the ctypes extension doesn't build on major Un*x platforms
>>> (AIX,
>>> HP-UX), I don't like to see ctypes dependend modules included into the
>>> stdlib. Please keep the stdlib as portable as possible.
>>>
>>
>> Nice in theory but ctypes already works on at least the top 3 popular
>> platforms.  Lets not hold Python's stdlib back because nobody who uses
>> IBM and HP proprietary stuff has contributed the necessary support.
>> Making nice libraries available for other platforms is a good way to
>> encourage people to either pitch in and add support or consider their
>> platform choices in the future.
>>
>> -gps
>>
>>
>
> It's not my platform choice, it's the choice of our customers. I'm not using
> these platforms just for fun (in fact it isn't fun compared to Linux or
> Windows).
>
> If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor
> compilers) would be an easy job, I'm sure it would have been done already.

Well, ctypes isn't simple. =)

> If more and more essential packages depend on ctypes, we should make a clear
> statement, that Python isn't supported any longer on platform/compiler
> combinations where libffi/ctypes doesn't build. This would give me arguments
> to drop support of our software on those platforms.

You are mixing the stdlib in with the language in terms of what is
required for Python to work, which I think is unfair. Just because
some part of the stdlib isn't portable to some OS does not mean Python
is not supported on that platform. If you can run a pure Python module
that does not depend on any C extension, then that platform has the
support needed to run Python. Everything else is extra (which is why
we have modules in the stdlib only available on specific platforms).

-Brett
___
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] Module renaming and pickle mechanisms

[Brett Cannon]

On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:

 Perhaps I have a misunderstanding of the reasoning behind
 doing the renaming in the 2.x branch, but it appears that
 the only reason is to get used to the new names. That's a
 rather low priority argument in comparison to the breakage
 the renaming will cause in the 2.x branch.
>>>
>>> I think this is the key point here. The possibility of breaking pickling
>>> compatibility never came up during the PEP 3108 discussions, so wasn't
>>> taken
>>> into account in deciding whether or not backporting the name changes was
>>> a
>>> good idea.
>>>
>>> I think it's pretty clear that the code needs to be moved back into the
>>> modules with the old names for 2.6. The only question is whether or not
>>> we
>>> put any effort into making the new stdlib organisation usable in 2.x, or
>>> just rely on 2to3 to fix it (note that the "increasing the common subset"
>>> argument doesn't really apply, since you can catch the import errors in
>>> order to try both names).
>>
>> Problem with this is it makes forward-porting revisions to 3.0 a PITA.
>> By keeping the module names consistent between the versions merging a
>> revision is just a matter of ``svnmerge merge`` with the usual
>> 3.0-specific changes. Reverting the modules back to the old name will
>> make forward-porting much more difficult as I don't think svn keeps
>> rename information around (and thus map the old name to the new name
>> in terms of diffs).
>
> svnmerge is written in Python, so wouldn't it be possible to add
> support for maintaining such renaming to that tool ?
>

Don't know, possibly. But I am not about to try to figure out.

> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.
>

That's why I suggested changing pickle to deal with the rename, but
obviously I am in the minority in that idea.

> After all, the renaming was approached for Python 3.0 and not
> 2.6 *because* it introduces major breakage.
>
> AFAIR, the discussion on the stdlib-sig also didn't include the
> plan to backport such changes to 2.6. Otherwise, we would have
> hashed them out there.
>

Never came up.

>> Alexandre's idea of teaching pickle the mapping of old names to new
>> might be the best solution. We could have a flag to pickle that
>> deactivates the renaming. Otherwise we could bump the pickle version
>> number so that the new number doesn't do the mapping while the old
>> versions to the implicit module mapping.
>>
>> And as Greg and Glpyh have pointed out, this is a problem that might
>> need to be addressed in the future with some changes to our
>> serialization method (I have no clue how since I don't deal with
>> pickle very much).
>
> It is possible to make pickle aware of the module renames, but
> that doesn't solve problems with other forms of serialization
> or use of the .__module__ attribute in general.
>
> Why can't we just provide a "from __future__ import renamed_modules"
> which then provides all the new name to old name mappings in
> some form (e.g. module proxies or whatever) and leave the
> existing modules in 2.x untouched ?

I have started a discussion on the stdlib SIG on how to handle this,
so I will defer this discussion to there.

But one thing that needs to be decided is if we are ever going to
allow ourselves to rename modules without a major version bump, and if
so how to deal with this problem. I would hope we don't have to wait
another eight years before there is another chance to shift things
around if it becomes apparent that some new package should be
introduced since 2to3 gives us a very nice way to handle the
mechanical aspect of porting code.

-Brett
___
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] Module renaming and pickle mechanisms

[Brett Cannon]

On Mon, May 19, 2008 at 9:22 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> Nick writes:

 M.-A. Lemburg wrote:
 > I don't think that an administrative problem such as forward-
 > porting patches to 3.x warrants breakage in the 2.x branch.
 >
 > After all, the renaming was approached for Python 3.0 and not
 > 2.6 *because* it introduces major breakage.
 >
 > AFAIR, the discussion on the stdlib-sig also didn't include the
 > plan to backport such changes to 2.6. Otherwise, we would have
 > hashed them out there.

 I think MAL is 100% correct here (and I expect Raymond will chime in to
 support him at some point as well).
>>>
>>> And until then, a +1 for MAL's position from me as well.  2.x should be
>>> quite conservative about such changes...
>>
>> I concur.
>
> And a "me too" post about being conservative by default as well.
>

I will update the PEP some time today. I think if we take MAL's idea
of doing the __dict__.update() trick and suppress the Py3K warnings
then it should be able to keep the warnings (it will require a very
specific filter). Otherwise the Py3K warnings will just have to go.

-Brett
___
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] Addition of "pyprocessing" module to standard lib.

[Thomas Heller]

Bill Janssen schrieb:
>> Hmm, perhaps the ctypes documentation could use a more prominent warning 
>> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), 
>> and that it may require the use of GCC rather than the vendor compiler 
>> on others (Solaris).
>> 
>> At the moment, I suspect some projects may be switching to using it 
>> without realising the implications for cross-platform portability.
> 
> I think it's a tad more problematic.  As other modules, both in and
> out of the standard library, move to use ctypes, it implies that
> *Python* isn't supported on those combinations.  Personally, that's
> fine with me (as long as there's a workaround for Solaris!), but I
> think that Ulrich is right in saying this should be more prominent.

I won't object if anyone adds this notice to the Python docs,
so please go ahead.  A table of platforms (on the wiki?) where ctypes
builds/works or does not may also be helpful.

Myself I would rather spend my energy to make ctypes more portable, within my
skills and the platforms I have access to.

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] Conditional For Statements

[Ryan Hitchman]

On Sun, May 21, 2006 at 17:38:49 CEST, Guido van Rossum  wrote
> ...
> Also, it would be a parsing conflict for the new conditional
> expressions (x if T else y).
> ...

That's all I needed to know.

Sorry, everyone, I'll try not to waste your time in the future.
___
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] Addition of "pyprocessing" module to standard lib.

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A.M. Kuchling wrote:
| Python development doesn't seem to have any volunteers who use AIX or
| HP-UX and can fix bugs on these platforms.  Searching bugs.python.org,
| I find about 20 open AIX issues, 4 or 5 HP-UX issues, 6 IRIX bugs, and
| about 15 Solaris bugs; but I don't know if any of the developers here
| use these platforms.  (There is a Solaris buildbot, at least.)

I develop under Solaris 10 x86. My environment is 64 bits, but my python
deployment/development in 32 bits. I could try 64 bits if asked for. I
can look at any Solaris related issue. Just ask.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
~   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSDGz2Jlgi5GaxT1NAQIx6wP+NudycEV/nkaCEGLUwnj5BP19urVURedj
x6Udb690/Hon/fv6tkplIw5pLramdv3hH8KKsxWr+kzrp4iHUZ7JPyItC0DBXImQ
3wRrV7Yhu1nVmFV2qm5Kdbu8+x7fCiWnzESLzQmIjEKQd0dlO2vStXUNmndoJ21h
pDwIW0bUriA=
=jbHH
-END PGP SIGNATURE-
___
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] Addition of "pyprocessing" module to standard lib.

[Bill Janssen]

> Hmm, perhaps the ctypes documentation could use a more prominent warning 
> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), 
> and that it may require the use of GCC rather than the vendor compiler 
> on others (Solaris).
> 
> At the moment, I suspect some projects may be switching to using it 
> without realising the implications for cross-platform portability.

I think it's a tad more problematic.  As other modules, both in and
out of the standard library, move to use ctypes, it implies that
*Python* isn't supported on those combinations.  Personally, that's
fine with me (as long as there's a workaround for Solaris!), but I
think that Ulrich is right in saying this should be more prominent.

Bill
___
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] Module renaming and pickle mechanisms

[Guido van Rossum]

On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Nick writes:
>>>
>>> M.-A. Lemburg wrote:
>>> > I don't think that an administrative problem such as forward-
>>> > porting patches to 3.x warrants breakage in the 2.x branch.
>>> >
>>> > After all, the renaming was approached for Python 3.0 and not
>>> > 2.6 *because* it introduces major breakage.
>>> >
>>> > AFAIR, the discussion on the stdlib-sig also didn't include the
>>> > plan to backport such changes to 2.6. Otherwise, we would have
>>> > hashed them out there.
>>>
>>> I think MAL is 100% correct here (and I expect Raymond will chime in to
>>> support him at some point as well).
>>
>> And until then, a +1 for MAL's position from me as well.  2.x should be
>> quite conservative about such changes...
>
> I concur.

And a "me too" post about being conservative by default as well.

I'm not sure how effective a "from __future__ import renamed_modules"
would be, since such future imports are meant to affect the semantics
of the *current* module only, whereas which name to use when pickling
a module reference is most likely a global choice. So perhaps some
other way to changing the default behavior globally would be more
appropriate. Assuming it's really the pickle module that needs to know
about this, how about making this a per-Pickler-instance flag? if you
wanted to write 3.0 compatible pickles you'd have to do something like

p = pikle.Pickler()
p.use_new_module_names(True)
pkl = p.dump()

We could supply an extra flag to the dump() and dumps() convenience
functions as well.

-- 
--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] Module renaming and pickle mechanisms

[Lennart Regebro]

On Mon, May 19, 2008 at 2:08 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Why can't we just provide a "from __future__ import renamed_modules"
> which then provides all the new name to old name mappings in
> some form (e.g. module proxies or whatever) and leave the
> existing modules in 2.x untouched ?

If I understand this correctly, the pickles would then be compatible
between 2.6 and 2.5, unless you did from __future__ import
renamed_modules, which would make the pickles compatible between 2.6
and 3.0. This sounds like the best solution to me, especially if the
old names are still available after the future import, as all that
would then be needed it to repickle all the pickles to convert from
2.5 to 3.0 pickles, right?

So, if I understood this correctly, that sounds like a perfect solution. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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] Module renaming and pickle mechanisms

[Raymond Hettinger]

Nick writes:

M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.
>
> After all, the renaming was approached for Python 3.0 and not
> 2.6 *because* it introduces major breakage.
>
> AFAIR, the discussion on the stdlib-sig also didn't include the
> plan to backport such changes to 2.6. Otherwise, we would have
> hashed them out there.

I think MAL is 100% correct here (and I expect Raymond will chime in to
support him at some point as well).


And until then, a +1 for MAL's position from me as well.  2.x should be
quite conservative about such changes...


I concur.


Raymond
___
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] oct and hex Py3k warnings

[Guido van Rossum]

On Sat, May 17, 2008 at 5:42 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> I know Guido has opposed adding Py3k warnings to oct and hex for
> "practical reasons," but I would like to make the case again.
>
> future_buitlins oct and hex will give you the correct Py3k behavior,
> but 2to3 can't convert old hex and oct usage to the new ones. That's
> why is would be helpful to warn about it and encourage people to
> import from future_builtins.

But the difference only matters for people who are parsing the output,
right? I think they'd find out soon enough. I'm still -1.

-- 
--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] Conditional For Statements

[Alex Martelli]

On Mon, May 19, 2008 at 5:33 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
   ...
 import this
> The Zen of Python, by Tim Peters
> ...
> There should be one-- and preferably only one --obvious way to do it.
>
> There should be ONE OBVIOUS way to do it, not "only one way".

The "only one way" phrasing is in the "Spirit of C" section of the ISO
C Standard `Rationale' (non-normative, but highly informative),
specifically in point four, "provide only one way to do an operation".
I contend that the somewhat different phrasing is somewhat accidental
and not particularly relevant: the *intent* of this *language design
guideline* is exactly the same (Tim was writing on his own, while the
C Standard was written by a committee, so it's hardly surprising that
the Standard's wording is drier and less funny than Tim's;-). IOW,
I've often argued that this is a deep commonality between the design
philosophy of C and Python (together with "trust the programmer" and
"keep the language small and simple", two more points in the "Spirit
of C" section) which makes them conceptually "closer" to each other
than C is to languages sharing more of its syntax, from C++ to
Javascript; it should be particularly easy to see the contrast with
languages deliberately designed to provide multiple equivalent
synonyms (such as foo.size and foo.length meaning the same thing in
Ruby) or going out of their way to provide multiple equivalent syntax
approaches for exactly the same semantics (such as Cobol's "ADD A TO B
GIVING C" and "C = A + B", or SQL's explicit [INNER] JOIN form and the
equivalent form where the inner join is left implicit in the WHERE
clause).

A design guideline is not a strict rule -- e.g., every C programmer
has met situations where a while statement, and a for statement with
some of the three subparts in the control clause omitted, can both
make sense, and of course every time you write within your loop some
"if(condition) continue" you wonder if in this case it might not be
better to instead use "if(!condition) { ... }" around the rest of the
loop's body, etc, etc -- so much for "only one way", as the various
ways to perform elementary operations can click together in a large
number of combinations and permutations; and adding "obvious" would
not help much either, since both alternatives can easily happen to be
"equally obvious". Python is just in the same situation. Nevertheless,
keeping the guideline firmly in mind (e.g., eschewing synonyms in APIs
you design that provide no added value beyond that of catering to
different tastes or to a meta-taste for variety over uniformity;-) is
still a helpful heuristic -- with or without the "obvious" word (i.e.,
whether you're working with C, which doesn't have the "obvious" in its
phrasing of the principle, or with Python, which does).

Alex
___
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] Conditional For Statements

[Nick Coghlan]

Ryan Hitchman wrote:

This would make the syntax closer to that of generators, which have
'for variable in iterable if condition', 


Incorporating the filter condition into the list comprehension syntax 
(and later into generator expressions) is necessary because they need to 
be written as a single expression. The same doesn't hold true for loop 
filters: it is quite possible to keep the looping and filtering concerns 
separated into different statements, and there's no compelling reason 
for merging them.



would improve code clarity by increased brevity


Increased brevity != improved code clarity (in fact, being too terse can 
obfuscate things - just look at Perl)


> not negating boolean expressions.

Except, of course, for those cases where it is easier to define the 
condition for items to skip than it is to define the condition for items 
to include.



Following are examples of current code with what the new code would
be, taken from the Python 3.0a5 tarball.


Using just the standard idiom of a separate if statement to do the 
filtering:


for (x, y), cell in self.cells.items():
if x <= 0 or y <= 0:
continue
# ...

for modname in modnames:
if not modname or '.' in modname:
continue
# ...

for w in wafter:
if dict.get(w):
continue
# ...

for K,V in items:
if V == "": continue
if K not in attrs: continue
# ...

for opensslFuncName in dir(_hashlib):
if opensslFuncName.startswith('openssl_'):
continue
# ...

I'm not really seeing how the readability of any of those examples is 
enhanced by being able to merge the filter condition into the first line 
of the for loop. The one example which was already written that way 
through the use of filter() is actually easy to read with the addition 
of the vertical whitespace needed for the idiomatic form.


The separate statement approach also scales far more cleanly to more 
complex filter conditions. For example, some code of mine includes a 
loop that looks like:


for name in dirnames:
if not os.path.exists(name):
continue
if not os.path.isdir(name):
continue
# Process named directory

This conveys the order of checks far more clearly than would be the case 
if the os.path calls were hidden on the end of the loop invocation.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Module renaming and pickle mechanisms

[Mark Hammond]

Nick writes:
> M.-A. Lemburg wrote:
> > I don't think that an administrative problem such as forward-
> > porting patches to 3.x warrants breakage in the 2.x branch.
> >
> > After all, the renaming was approached for Python 3.0 and not
> > 2.6 *because* it introduces major breakage.
> >
> > AFAIR, the discussion on the stdlib-sig also didn't include the
> > plan to backport such changes to 2.6. Otherwise, we would have
> > hashed them out there.
> 
> I think MAL is 100% correct here (and I expect Raymond will chime in to
> support him at some point as well).

And until then, a +1 for MAL's position from me as well.  2.x should be
quite conservative about such changes...

Cheers,

Mark

___
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] Symbolic errno values in error messages

[Yannick Gingras]

"Alexandre Vassalotti" <[EMAIL PROTECTED]> writes:

>>> So now I am not sure what OP is proposing.  Do you want to replace 21
>>> with EISDIR in the above?
>>
>> Yes, that's what I had in mind.
>>
>
> Then, check out EnvironmentError_str in Objects/exceptions.c. You
> should be able import the errno module and fetch its errorcode
> dictionary.

It wasn't as hard as I expected.  It's the first time that I play with
the Python C API; I didn't expect the API to be that high level.

I attached a patch to convert errno to its symbolic value when an
EnvironmentError is printed.  Should attach it to a ticket on
bugs.python.org?

I'm sure there is a style guide like PEP-8 for C code, feel free to
point me to it because my patch is probably not fully style compliant.

With Emacs, doing

 M-x c-set-style python

doesn't seems to do the right thing.  Are you all using a bunch of
shared settings in you .emacs files?

-- 
Yannick Gingras
Index: Objects/exceptions.c
===
--- Objects/exceptions.c	(revision 63365)
+++ Objects/exceptions.c	(working copy)
@@ -604,13 +604,32 @@
 EnvironmentError_str(PyEnvironmentErrorObject *self)
 {
 PyObject *rtnval = NULL;
+PyObject *errnomod = NULL;
+PyObject *errorcode_dict = NULL;
+PyObject *errno_str = NULL;
+PyObject *printed_errno = NULL;
 
+/* Extract the symbolic value for errno.  
+   Ex: use 'ENOTDIR' instead of 20 */
+if (self->myerrno) {
+errnomod = PyImport_ImportModule("errno");
+if (errnomod == NULL)
+	Py_FatalError("Can't import errno module.");
+   
+	errorcode_dict = PyObject_GetAttrString(errnomod, "errorcode");
+	if (errorcode_dict == NULL)
+	Py_FatalError("Can't access errorcode dict.");
+   
+	errno_str = PyDict_GetItem(errorcode_dict, self->myerrno);
+	printed_errno = errno_str ? errno_str : self->myerrno;
+}
+
 if (self->filename) {
 PyObject *fmt;
 PyObject *repr;
 PyObject *tuple;
 
-fmt = PyString_FromString("[Errno %s] %s: %s");
+fmt = PyString_FromString("[Errno=%s] %s: %s");
 if (!fmt)
 return NULL;
 
@@ -627,8 +646,8 @@
 }
 
 if (self->myerrno) {
-Py_INCREF(self->myerrno);
-PyTuple_SET_ITEM(tuple, 0, self->myerrno);
+Py_INCREF(printed_errno);
+PyTuple_SET_ITEM(tuple, 0, printed_errno);
 }
 else {
 Py_INCREF(Py_None);
@@ -654,7 +673,7 @@
 PyObject *fmt;
 PyObject *tuple;
 
-fmt = PyString_FromString("[Errno %s] %s");
+fmt = PyString_FromString("[Errno=%s] %s");
 if (!fmt)
 return NULL;
 
@@ -665,8 +684,8 @@
 }
 
 if (self->myerrno) {
-Py_INCREF(self->myerrno);
-PyTuple_SET_ITEM(tuple, 0, self->myerrno);
+Py_INCREF(printed_errno);
+PyTuple_SET_ITEM(tuple, 0, printed_errno);
 }
 else {
 Py_INCREF(Py_None);
@@ -688,7 +707,9 @@
 }
 else
 rtnval = BaseException_str((PyBaseExceptionObject *)self);
-
+
+Py_XDECREF(errnomod);
+Py_XDECREF(errorcode_dict);
 return rtnval;
 }
 
___
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] Module renaming and pickle mechanisms

[Terry Reedy]

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| M.-A. Lemburg wrote:
| > I don't think that an administrative problem such as forward-
| > porting patches to 3.x warrants breakage in the 2.x branch.
| >
| > After all, the renaming was approached for Python 3.0 and not
| > 2.6 *because* it introduces major breakage.
| >
| > AFAIR, the discussion on the stdlib-sig also didn't include the
| > plan to backport such changes to 2.6. Otherwise, we would have
| > hashed them out there.
|
| I think MAL is 100% correct here (and I expect Raymond will chime in to
| support him at some point as well).

For what little it's worth, I was surprised too that the 3.0 renames were 
backported as thr default versions.  It strikes me as possibly a 'bridge 
too far' ;-).

tjr



___
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] Conditional For Statements

[Steven D'Aprano]

On Mon, 19 May 2008 08:42:29 pm Lennart Regebro wrote:

> How was it again? "One and only one way"? :-)

Certainly not. What on earth gave you the idea that that ridiculous 
statement is a Python philosophy? I know some Perl developers like to 
contrast the supposed flexibility of Perl ("more than one way to do 
it") with the imagined poverty of Python, but that really is a silly 
claim to make about any Turing Complete language. If nothing else, any 
programming language that lets you perform arithmetic would not be so 
restrictive:

x = (1+2)*3 + 3*3

x = (3+2)*3 + 1*3

Which one should the compiler prohibit?

I strongly suggest that you look at the Zen of Python:

>>> import this
The Zen of Python, by Tim Peters
...
There should be one-- and preferably only one --obvious way to do it.

There should be ONE OBVIOUS way to do it, not "only one way".


-- 
Steven
___
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] Module renaming and pickle mechanisms

[Nick Coghlan]

M.-A. Lemburg wrote:

I don't think that an administrative problem such as forward-
porting patches to 3.x warrants breakage in the 2.x branch.

After all, the renaming was approached for Python 3.0 and not
2.6 *because* it introduces major breakage.

AFAIR, the discussion on the stdlib-sig also didn't include the
plan to backport such changes to 2.6. Otherwise, we would have
hashed them out there.


I think MAL is 100% correct here (and I expect Raymond will chime in to 
support him at some point as well).


Taking the time to fix out mistake may mean we need to do another alpha 
rather than being able to go into the betas as planned, but I think that 
would be a much better option than breaking any 2.x code that relies on 
__module__ staying the same across releases.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Module renaming and pickle mechanisms

[M.-A. Lemburg]

On 2008-05-18 22:24, Brett Cannon wrote:

On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:

M.-A. Lemburg wrote:

Perhaps I have a misunderstanding of the reasoning behind
doing the renaming in the 2.x branch, but it appears that
the only reason is to get used to the new names. That's a
rather low priority argument in comparison to the breakage
the renaming will cause in the 2.x branch.

I think this is the key point here. The possibility of breaking pickling
compatibility never came up during the PEP 3108 discussions, so wasn't taken
into account in deciding whether or not backporting the name changes was a
good idea.

I think it's pretty clear that the code needs to be moved back into the
modules with the old names for 2.6. The only question is whether or not we
put any effort into making the new stdlib organisation usable in 2.x, or
just rely on 2to3 to fix it (note that the "increasing the common subset"
argument doesn't really apply, since you can catch the import errors in
order to try both names).


Problem with this is it makes forward-porting revisions to 3.0 a PITA.
By keeping the module names consistent between the versions merging a
revision is just a matter of ``svnmerge merge`` with the usual
3.0-specific changes. Reverting the modules back to the old name will
make forward-porting much more difficult as I don't think svn keeps
rename information around (and thus map the old name to the new name
in terms of diffs).


svnmerge is written in Python, so wouldn't it be possible to add
support for maintaining such renaming to that tool ?

I don't think that an administrative problem such as forward-
porting patches to 3.x warrants breakage in the 2.x branch.

After all, the renaming was approached for Python 3.0 and not
2.6 *because* it introduces major breakage.

AFAIR, the discussion on the stdlib-sig also didn't include the
plan to backport such changes to 2.6. Otherwise, we would have
hashed them out there.


Alexandre's idea of teaching pickle the mapping of old names to new
might be the best solution. We could have a flag to pickle that
deactivates the renaming. Otherwise we could bump the pickle version
number so that the new number doesn't do the mapping while the old
versions to the implicit module mapping.

And as Greg and Glpyh have pointed out, this is a problem that might
need to be addressed in the future with some changes to our
serialization method (I have no clue how since I don't deal with
pickle very much).


It is possible to make pickle aware of the module renames, but
that doesn't solve problems with other forms of serialization
or use of the .__module__ attribute in general.

Why can't we just provide a "from __future__ import renamed_modules"
which then provides all the new name to old name mappings in
some form (e.g. module proxies or whatever) and leave the
existing modules in 2.x untouched ?

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Conditional For Statements

[Lennart Regebro]

On Mon, May 19, 2008 at 5:55 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Ryan Hitchman" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | I'd like to propose an addition to the for statement's syntax:
> |
> | for {variable} in {iterable} if {condition}:
> |{block}
> |
> | which is equivalent to
> |
> | for {variable} in {iterable}:
> |if not {condition}:
> |continue
> |{block}
>
> Is this different from
> for var in filter(lambda x: condition(x), iterable)):
> ?
>
> | and
> |
> | for {variable} in filter(lambda: {condition}, iterable):
> |{block}
>
> IDLE 3.0a5
 for i in filter(lambda i: i%2, range(10)):
>  print(i)
>
>
> 1
> 3
> 5
> 7
> 9

How was it again? "One and only one way"? :-)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
___
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] Addition of "pyprocessing" module to standard lib.

[Nick Coghlan]

Ulrich Berning wrote:
I'm trying to use the vendor specific compilers whenever possible, 
because using gcc puts in additional dependencies (libgcc), I want to 
avoid, and even if I could live with these dependencies, it's not easy 
to get/build the 'right' gcc version, if your software also depends on 
other big packages like Qt and PyQt.


I'm not using these platforms for my own pleasure (in fact, I would be 
happy if these platforms would disappear from the market), but as long 
as our customers use these platforms, we want to promise our software 
runs on those platforms.


I have no problem with the fact that ctypes doesn't build on those 
platforms because I don't use it, but if more and more essential 
packages depend on ctypes, I'm running into trouble. PyOpenGL is an 
example of an extension, that moved completely from C-Source (SWIG 
generated) to ctypes usage.


Hmm, perhaps the ctypes documentation could use a more prominent warning 
that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), 
and that it may require the use of GCC rather than the vendor compiler 
on others (Solaris).


At the moment, I suspect some projects may be switching to using it 
without realising the implications for cross-platform portability.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Addition of "pyprocessing" module to standard lib.

[Ulrich Berning]

Gregory P. Smith wrote:


On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
 


As long as the ctypes extension doesn't build on major Un*x platforms (AIX,
HP-UX), I don't like to see ctypes dependend modules included into the
stdlib. Please keep the stdlib as portable as possible.
   



Nice in theory but ctypes already works on at least the top 3 popular
platforms.  Lets not hold Python's stdlib back because nobody who uses
IBM and HP proprietary stuff has contributed the necessary support.
Making nice libraries available for other platforms is a good way to
encourage people to either pitch in and add support or consider their
platform choices in the future.

-gps

 

It's not my platform choice, it's the choice of our customers. I'm not 
using these platforms just for fun (in fact it isn't fun compared to 
Linux or Windows).


If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using 
vendor compilers) would be an easy job, I'm sure it would have been done 
already. If more and more essential packages depend on ctypes, we should 
make a clear statement, that Python isn't supported any longer on 
platform/compiler combinations where libffi/ctypes doesn't build. This 
would give me arguments to drop support of our software on those platforms.


Ulli

___
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] Addition of "pyprocessing" module to standard lib.

[Ulrich Berning]

Nick Coghlan wrote:


Ulrich Berning wrote:

More and more people tend to say "Runs on Un*x" when they really mean 
"Tested on Linux". Un*x is not Linux.



Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64 
machines amongst the main Python buildbots, to go along with the 
assorted OS X, Windows and Linux boxes - and as far as I know 
test_ctypes runs quite happily on all of them.


On the specific problems with AIX, HP-UX and ctypes, was it ctypes 
itself that was failing to build, or the underlying libffi?


Cheers,
Nick.


On HP-UX-11.00, HP ANSI C++ B3910B A.03.73, Python-2.5.2, I get
 configure: error: "libffi has not been ported to hppa2.0w-hp-hpux11.00."

On AIX-4.3.3, C for AIX Compiler Version 6, Python-2.5.2, I get
 "build/temp.aix-4.3-2.5/libffi/include/ffi.h", line 123.4: 1506-205 
(S) #error "no 64-bit data type supported"


On Solaris-10/x86, Sun C 5.8 Patch 121016-07 2007/10/03, Python-2.5.2, I get
 "build/temp.solaris-2.10-i86pc-2.5/libffi/include/ffitarget.h", line 
64: undefined symbol: FFI_DEFAULT_ABI


On Solaris-8/sparc, Sun C 5.8 2005/10/13, Python-2.5.2, I get
 "build/temp.solaris-2.8-sun4u-2.5/libffi/include/ffi.h", line 225: 
syntax error before or at: __attribute__


On IRIX-6.5, gcc-3.4.4, Python-2.5.2, ffi_closure is undefined, because 
only the old O32 binary format is supported, not the new N32/N64 format.


I'm trying to use the vendor specific compilers whenever possible, 
because using gcc puts in additional dependencies (libgcc), I want to 
avoid, and even if I could live with these dependencies, it's not easy 
to get/build the 'right' gcc version, if your software also depends on 
other big packages like Qt and PyQt.


I'm not using these platforms for my own pleasure (in fact, I would be 
happy if these platforms would disappear from the market), but as long 
as our customers use these platforms, we want to promise our software 
runs on those platforms.


I have no problem with the fact that ctypes doesn't build on those 
platforms because I don't use it, but if more and more essential 
packages depend on ctypes, I'm running into trouble. PyOpenGL is an 
example of an extension, that moved completely from C-Source (SWIG 
generated) to ctypes usage.


Ulli

___
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