[Python-Dev] tracker issues? server error
trying to update a bug I get: Fri May 2 07:17:17 2008: An error occurred. Please check the server log for more infomation. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 08:26], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote: >It seems you don't want to identify whether the Windows installation is >a Win64 one, but whether the Python installation is, right? I think we can say with a reasonably certainty that if the Python installation is 64-bits the OS is 64-bits too. So yes, if we can identify the Python installation is 64-bits that would be helpful. >For this, you should use platform.architecture()[0] OK, thanks, that's useful, but please see my response to Mark about the why and why platform.architecture()[0] helps, but not fully though. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Tonight your soul sleeps, but one day you will feel real pain, maybe then you will see me as I am: a fragile wreck on a storm of emotion... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 07:57], Mark Hammond ([EMAIL PROTECTED]) wrote: >The best way I can find for the win32 API to tell you this is a combination >of the above and the IsWow64Process() (which returns True if you are a >32bit process on a 64bit platform) Support for IsWow64Process() is quite interesting in itself, so if you can add support for that, cool. :) >I'd be interested to know why you care though - ie, how will the behavior >of your programs depend on that? For Genshi I was mucking around with setuptools to create Windows eggs. My machine at home is an AMD64 box. I have Python 2.5 installed, which is 64 bits on Windows x64. On a normal Unix box an egg for a 32 bits system will result in something like Genshi-0.5dev_r847-py2.5-linux-i686.egg. On an 64-bits system we get Genshi-0.5dev_r847-py2.5-linux-x86_64.egg. This distinction is important since Genshi includes a _speedups.so which is compiled to either 32 or 64-bits. On a 64-bits Windows it will always create an egg with win32 in the name. So both a 32-bits and 64-bits Python will in the end create an egg with win32. So imagine creating a 64-bits egg with compiled _speedups and putting it on PyPI. Any 32-bits Python requesting Genshi will get the egg with 64-bits compiled binaries in it. I think it's obvious this is Not Good(tm). (I already raised the issue on distutils-sig, but it has remained unanswered thus far.) So from what I gather we have no unique way to refer to 32-bits or 64-bits Python aside from the semi-adequate platform.architecture()[0]. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Be yourself is all that you can do. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Guido van Rossum schrieb: > I like this, except one issue: I really don't like the .local > directory. I don't see any compelling reason why this needs to be > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > it from view, especially since the user is expected to manage this > explicitly. The directory name has been commented on by glyph in great length (again). Thanks glyph! I'm all on his side. The base directory for Python related files should be a dot directory in the root directory of the users home dir. I slightly prefer ~/.local/ over other suggestions but I'm also open to ~/.python.d/ Should I wait with the commit until we have agreed on a directory name or do you want me to commit the code now? > I might look at this later; but it seems to me to be a pure > optimization and thus not required to be in before the first beta. Correct, it's an optimization to enhance the memory utilization. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
> -On [20080502 07:57], Mark Hammond ([EMAIL PROTECTED]) wrote: > >The best way I can find for the win32 API to tell you this is a > combination > >of the above and the IsWow64Process() (which returns True if you are a > >32bit process on a 64bit platform) > > Support for IsWow64Process() is quite interesting in itself, so if you > can > add support for that, cool. :) OK - I'll make a patch for this tomorrow (unless someone pipes up suggesting it's not a great idea, or that ctypes should be used, etc) > >I'd be interested to know why you care though - ie, how will the > behavior > >of your programs depend on that? > > For Genshi I was mucking around with setuptools to create Windows eggs. > My machine at home is an AMD64 box. I have Python 2.5 installed, which is > 64 bits on Windows x64. > > On a normal Unix box an egg for a 32 bits system will result in > something like Genshi-0.5dev_r847-py2.5-linux-i686.egg. On an 64-bits > system we get > Genshi-0.5dev_r847-py2.5-linux-x86_64.egg. This distinction is > important since Genshi includes a _speedups.so which is compiled > to either 32 or 64-bits. Yeah - see recent changes to support cross-compilation in distutils - particularly http://bugs.python.org/issue2513, and a grep for 'plat_name' in Distutils/command might also help. > So from what I gather we have no unique way to refer to 32-bits or 64- > bits Python aside from the semi-adequate platform.architecture()[0]. >From the above, it's not clear what problem you have other than arranging for >setuptools to select the correct binaries and generate an egg with a >distinction in the filename. Ie, why isn't platform.architecture() (or >possibly distutils.util.get_platform) adequate to have setuptools "do the >right thing" in your examples? Unfortunately though, I don't know enough >about setuptools to suggest how this might happen. If you go this route, >please followup on the distutils list (I must have missed your message there >while I was on vacation) Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Guido van Rossum wrote: I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The "symmetry" with /usr/local/ is pretty weak, and certainly won't help beginning users. So it's the *name* you don't like rather than the invisibility? As a compromise, I'm okay with ~/Python/. I would like to be able to say that the user explicitly has to set an environment variable in order to benefit from this feature, just like with $PYTHONPATH and $PYTHONSTARTUP. But that might defeat the point of making this easy to use for noobs. Groan. Then everyone else realizes what a "great idea" this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm about +10 on invisibility, for the simple reason that "hiding the mechanism" is the right thing to do for naive users, who are the most likely to screw things up if given the chance and the most likely to be unaware of dot-name directories. If you don't like ~/.local/ then please consider ~/.private/ or ~/.personal/ or something else, but don't gratuitously add a visible subdirectory. On OS X I think we should put this somewhere under ~/Library/. Just put it in a different place than where the Python framework puts its stuff. Nothing to say about OS X. One day Windows might start to respect the "hidden dot" convention, but perhaps in the interim we could create a (Windows-hidden) ~/.private/? Assuming we could work out where to put it ;-) On Thu, May 1, 2008 at 8:25 PM, <[EMAIL PROTECTED]> wrote: [much good sense] regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Steve Holden schrieb: > Nothing to say about OS X. > > One day Windows might start to respect the "hidden dot" convention, but > perhaps in the interim we could create a (Windows-hidden) ~/.private/? > Assuming we could work out where to put it ;-) Windows and Mac OS X have dedicated directories for application specific libraries. That is ~/Library on Mac and Application Data on Windows. The latter is i18n-ed and called "Anwendungsdaten" in German. Fortunately Windows sets an environment var to the application data directory. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
-On [20080502 10:46], Mark Hammond ([EMAIL PROTECTED]) wrote: >OK - I'll make a patch for this tomorrow (unless someone pipes up >suggesting it's not a great idea, or that ctypes should be used, etc) Thanks. I am sure something like that might come in handy for our Python-using games developers. And other developers too. ;) >From the above, it's not clear what problem you have other than arranging >for setuptools to select the correct binaries and generate an egg with a >distinction in the filename. Ie, why isn't platform.architecture() (or >possibly distutils.util.get_platform) adequate to have setuptools "do the >right thing" in your examples? Unfortunately though, I don't know enough >about setuptools to suggest how this might happen. Sorry, my bad, yes, the platform.architecture() is helpful, the only problem is that I'd rather settle for a sort of standardized nomenclature for this. Both platforms use the win32 API, so would Windows XP be win32-32 and x64 be win32-64 or something like that? >If you go this route, please followup on the distutils list (I must have >missed your message there while I was on vacation) Will do, since there is another issue that makes using setuptools on 64-bits Windows non-working, at least where it concerns easy_install. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The taller the bamboo grows, the lower it bends. - Chinese saying ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 11:00], Christian Heimes ([EMAIL PROTECTED]) wrote:
>Windows and Mac OS X have dedicated directories for application specific
>libraries. That is ~/Library on Mac and Application Data on Windows. The
>latter is i18n-ed and called "Anwendungsdaten" in German. Fortunately
>Windows sets an environment var to the application data directory.
And Vista has C:\ProgramData\{vendor}\{application}, which is *not*
$APPDATA, but $ProgramData. $APPDATA points to
C:\Users\{user}\AppData\Roaming on Vista -- which is very different.
"Windows uses the Roaming folder for application specific data, such as
custom dictionaries, which are machine independent and should roam with the
user profile. The AppData\Roaming folder in Windows Vista is the same as the
Documents and Settings\username\Application Data folder in Windows XP."
I think that's different from what you meant above though, since I doubt
you'd want this (the libraries) to roam with the user.
See
http://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-9c96482f5353/Managing%20Roaming%20User%20Data%20Deployment%20Guide.doc
for more background.
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Seek not death in the error of your life: and pull not upon yourselves
destruction with the works of your hands...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: >Groan. Then everyone else realizes what a "great idea" this is, and we see >~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with >a comment market in its name), ~/Lisp/ and the rest? I don't think people >would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). But I agree with Steve that it should be a hidden directory. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae..? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should bytearray(b'a')[0] should 1-char or number?
# I tried to post this to bug tracker, but couldn't, so posted here... r62095 says >Fix and enable a skipped test: >with python 2.6, enumerating bytes yields 1-char strings, not numbers. > >Don't merge this into the py3k branch. This is true for bytes, but not for bytearray. >>> bytearray(b'a')[0] 97 [28493 refs] >>> b'a'[0] 'a' And this causes error on my environment like this. == FAIL: testDecoder (__main__.StatefulIncrementalDecoderTest) -- Traceback (most recent call last): File "test_io.py", line 629, in testDecoder self.assertEquals(d.decode(input, eof), output) AssertionError: u'o.i.a.b.c.d.' != u'abcd.' But strange, I cannot see this error on python.org buildbot. ??? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Jeroen Ruigrok van der Werven schrieb: > "Windows uses the Roaming folder for application specific data, such as > custom dictionaries, which are machine independent and should roam with the > user profile. The AppData\Roaming folder in Windows Vista is the same as the > Documents and Settings\username\Application Data folder in Windows XP." > > I think that's different from what you meant above though, since I doubt > you'd want this (the libraries) to roam with the user. In a matter of fact I *want* to roam the libraries. On the other hand this might become an issue if a user roams between a 32bit and 64bit system ... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Jeroen Ruigrok van der Werven wrote: -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: Groan. Then everyone else realizes what a "great idea" this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). But I agree with Steve that it should be a hidden directory. This sums up my opinion pretty well. Hidden by default, but easy to expose (e.g. via a local -> .local symlink) for the more experienced users that want it more easily accessible. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
On Friday 02 May 2008, Nick Coghlan wrote: > Jeroen Ruigrok van der Werven wrote: > > -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: > >> Groan. Then everyone else realizes what a "great idea" this is, and we > >> see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a > >> directory with a comment market in its name), ~/Lisp/ and the rest? I > >> don't think people would thank us for that in the long term. > > > > I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes > > sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly > > used if I look at my .files in $HOME). > > > > But I agree with Steve that it should be a hidden directory. > > This sums up my opinion pretty well. Hidden by default, but easy to > expose (e.g. via a local -> .local symlink) for the more experienced > users that want it more easily accessible. But you can't be serious about using such a generic word as "local" as the name??? At least include the letters "p" and "y" somewhere. Phil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 2, 2008, at 1:48 AM, [EMAIL PROTECTED] wrote: etc, though. In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system- installing them. I hate to send a "me too" messages, but I have to say Glyph is exactly right here. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBr75XEjvBPtnXfVAQIHAgP+JDpOymVEKfFvzZQZd8WtTpY6jsjvntAA 2J38LslMAXJSs3BcRBU/ELcbvTpr/JoEButktAQJCJpIhsmRTV0y3KcS/d/d+Sao 9V3ME2/yZ94qeQheB7jJIhfihNlC7VhG+CjSOMZrRZwm3k2drGGDdfdgGeSGZJOl B6uCEB0i0iI= =gup1 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should bytearray(b'a')[0] should 1-char or number?
On Fri, May 2, 2008 at 11:47 AM, ocean wrote: > # I tried to post this to bug tracker, but couldn't, so posted here... > > r62095 says > > >Fix and enable a skipped test: > >with python 2.6, enumerating bytes yields 1-char strings, not numbers. > > > >Don't merge this into the py3k branch. > > This is true for bytes, but not for bytearray. > > >>> bytearray(b'a')[0] > 97 > [28493 refs] > >>> b'a'[0] > 'a' > > And this causes error on my environment like this. > > == > FAIL: testDecoder (__main__.StatefulIncrementalDecoderTest) > -- > Traceback (most recent call last): > File "test_io.py", line 629, in testDecoder > self.assertEquals(d.decode(input, eof), output) > AssertionError: u'o.i.a.b.c.d.' != u'abcd.' > > But strange, I cannot see this error on python.org buildbot. The buildbots don't fail, because StatefulIncrementalDecoderTest is not listed in the run_unittest() call :-(. I found the cause of the problem: in io.py, TextIOWrapper.tell() calls decode() with a bytearray, without any reason it seems. I will take care of this tonight, if bugs.python.org is available. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
On 11:01 am, [EMAIL PROTECTED] wrote: On Friday 02 May 2008, Nick Coghlan wrote: This sums up my opinion pretty well. Hidden by default, but easy to expose (e.g. via a local -> .local symlink) for the more experienced users that want it more easily accessible. But you can't be serious about using such a generic word as "local" as the name??? At least include the letters "p" and "y" somewhere. To be clear, the directory being proposed for Python's use here is "~/.local/lib/pythonX.Y/site-packages", not just "~/.local". There's 1 "y" and 2 "p"s in there. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 14:49], Richard Boulton ([EMAIL PROTECTED]) wrote:
>So, on Ubuntu computers at least, it seems likely that a $HOME/.local/
>directory will already exist, with the beginnings of a unix style layout
>inside it.
On my Ubuntu 8 box:
[15:11] [EMAIL PROTECTED] (0) {0} % ls ~/.local
share
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
The only source of knowledge is experience...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Phil Thompson wrote: On Friday 02 May 2008, Nick Coghlan wrote: Jeroen Ruigrok van der Werven wrote: -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: Groan. Then everyone else realizes what a "great idea" this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). But I agree with Steve that it should be a hidden directory. This sums up my opinion pretty well. Hidden by default, but easy to expose (e.g. via a local -> .local symlink) for the more experienced users that want it more easily accessible. But you can't be serious about using such a generic word as "local" as the name??? At least include the letters "p" and "y" somewhere. As glyph noted, the idea is that the layout inside ~/.local would be modeled on that used inside /usr/local. A lot of that was thrashed out during the original PEP 370 discussions though - the current discussion relates purely to what would be visible to the user at the home directory level, so the internal layout of the .local directory hadn't really come up. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] warnings.showwarning (was Re: [Python-3000] Reminder: last alphas next Wednesday 07-May-2008)
On Thu, 1 May 2008 19:31:20 -0700, Brett Cannon <[EMAIL PROTECTED]> wrote:
[snip]
I just closed the release blocker I created (the
backwards-compatibility issue with warnings.showwarning() ). I would
like to add a PendingDeprecationWarning (or stronger) to 2.6 for
showwarning() implementations that don't support the optional 'line'
argument. I guess the best way to do it in C code would be to see if
PyFunction_GetDefaults() returns a tuple of length two (since
showwarning() already has a single optional argument as it is).
Hi Brett,
I'm still seeing some strange behavior from the warnings module, This
can be observed on the community buildbot for Twisted, for example:
http://python.org/dev/buildbot/community/trunk/x86%20Ubuntu%20Hardy%20trunk/builds/171/step-Twisted.zope.stable/0
The log ends with basically all of the warning-related tests in Twisted
failing, reporting that no warnings happened.
There is also some strange behavior that can be easily observed in the REPL:
[EMAIL PROTECTED]:~/Projects/python/trunk$ ./python
/home/exarkun/Projects/Divmod/trunk/Combinator/combinator/xsite.py:7: DeprecationWarning: the sets module is deprecated
from sets import Set
Python 2.6a2+ (trunk:62636M, May 2 2008, 09:19:41)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn("foo")
:1: UserWarning: foo # Where'd the module name go?
>>> def f(*a):
... print a
...
>>> warnings.showwarning = f
>>> warnings.warn("foo")
>>># Where'd the warning go?
Any ideas on this?
Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
I'm withdrawing my opposition in the light of the sheer number of words that have already been written with this. On Fri, May 2, 2008 at 1:30 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > > I like this, except one issue: I really don't like the .local > > directory. I don't see any compelling reason why this needs to be > > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > > it from view, especially since the user is expected to manage this > > explicitly. > > The directory name has been commented on by glyph in great length > (again). Thanks glyph! I'm all on his side. The base directory for > Python related files should be a dot directory in the root directory of > the users home dir. I slightly prefer ~/.local/ over other suggestions > but I'm also open to ~/.python.d/ > > Should I wait with the commit until we have agreed on a directory name > or do you want me to commit the code now? > > > > I might look at this later; but it seems to me to be a pure > > optimization and thus not required to be in before the first beta. > > Correct, it's an optimization to enhance the memory utilization. > > Christian > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Martin v. Löwis wrote: This leaves us with a few options: 5. Reuse/Abuse Num(object) for arbitrary constants. AFAICT, this should work out of the box. Eek. It *does* seem like Num would work out of the box, but would this be a good idea? What about *replacing* Num with Const? Might make optimizations specifically for numeric values slightly hairier, and semantically I think they might be different enough to warrant separate AST nodes despite the similarity in implementation at the compiler level. FWIW, I read Num as "numeric literal" and Const as "arbitrary constant", but that's probably only because I've seen the immediate need for constants with non-Num values in the process of writing the AST optimizer. 1. A new AST expr node for constant values for types other than Str/Num I imagine this to be something like Const(PyObject* v), which is effectively translated to a "LOAD_CONST v" by the compiler. This trades the purity of the AST for a little practicality. A "Const" node has no real source representation, it would exist solely for the purpose of injecting PyObject constants into the AST. I think this is the way to go. It doesn't violate purity: it is an *abstract* syntax, meaning that there doesn't need to be a 1:1 relationship to source syntax. However, it is still possible to reproduce source code from this Const node. I'm leaning toward this, too. It's dirt simple and quite clean to implement. I also don't worry about Jython conflicts. The grammar has a version number precisely so that you can refer to a specific version if you need to. Any Jython folk care to weigh in on this? If there are no major objections I think I'm going to forge ahead with an independant Const() node. Cheers, T ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should bytearray(b'a')[0] should 1-char or number?
On Fri, May 2, 2008 at 2:47 AM, ocean <[EMAIL PROTECTED]> wrote: > # I tried to post this to bug tracker, but couldn't, so posted here... Was this because you can't figure out how to get a username, or because it was down? It's up now; to create a username, use this form: http://bugs.python.org/[EMAIL PROTECTED] (most fields are optional :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Barry Warsaw wrote:
> Time is running short to get any new features into Python 2.6 and 3.0.
> The release after this one is scheduled to be the first beta release, at
> which time we will institute a feature freeze. If your feature doesn't
> make it in by then, you'll have to wait until 2.7/3.1. If there is
> something that absolutely must go into 2.6/3.0 be sure that there is a
> bug issue open for it and that the Priority is set to 'release
> blocker'. I may reduce it to critical for the next alpha, but we'll
> review all the release blocker and critical issues for the first 2.6 and
> 3.0 beta releases.
I tried to bump http://bugs.python.org/issue643841 ("New class special
method lookup change") up to release blocker, but the bug tracker still
appears to be a bit flaky (it keeps giving me an error when I try to
submit the change - unfortunately I can't submit anything about it to
the metatracker, because I've forgotten my password for it and the
metatracker is getting a connection refused when it tries to send the
reminder email :P).
Here's the comment I was trying to submit along with the bug priority
change:
"""Bumping the priority on this to release blocker for 3.0 - I think we
need to have a good answer for the folks who've written old-style
__getattr__ based auto-delegating classes before removing old-style
classes entirely in 3.0.
We could get away with ignoring the issue in the past because people had
the option of just using an old-style class rather than having to deal
with the difficulties of doing this with a new-style class. With 3.0,
that approach is being eliminated.
A ProxyMixin class written in Python would address that need (and
shouldn't be particularly hard to write), but I'm not sure where it
would go in the standard library."""
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (04/25/08 - 05/02/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1850 open (+29) / 12712 closed (+16) / 14562 total (+45) Open issues with patches: 560 Average duration of open issues: 711 days. Median duration of open issues: 1347 days. Open Issues Breakdown open 1827 (+29) pending23 ( +0) Issues Created Or Reopened (45) ___ bytes object wrongly exposes writeable buffer interface 04/25/08 CLOSED http://bugs.python.org/issue2692created theller IDLE doesn't work with Tk 8.5 04/25/08 http://bugs.python.org/issue2693created gregc patch msilib file names check too strict ? 04/26/08 http://bugs.python.org/issue2694created cdavid Ignore case when checking algorithm in urllib2 04/26/08 http://bugs.python.org/issue2695created zathras unicode string does not get freed --> memory leak? 04/26/08 CLOSED http://bugs.python.org/issue2696created ThurnerRupert Logging ancestors ignored after configuration04/26/08 CLOSED http://bugs.python.org/issue2697created acooke Extension module build fails for MinGW: missing vcvarsall.bat04/26/08 http://bugs.python.org/issue2698created kermode Exception name improperly indented 04/26/08 CLOSED http://bugs.python.org/issue2699created brett.cannon document PyNumber_ToBase 04/27/08 CLOSED http://bugs.python.org/issue2700created benjamin.peterson patch csv.reader accepts string instead of file object (duck typing go 04/27/08 http://bugs.python.org/issue2701created roysmith pickling of large recursive structures crashes cPickle 04/27/08 http://bugs.python.org/issue2702created cyhawk SimpleXMLRPCDispatcher.__init__ is not python2.4-backward-compat 04/27/08 http://bugs.python.org/issue2703created doko patch, patch IDLE: Patch to make PyShell behave more like a Terminal interfac 04/27/08 http://bugs.python.org/issue2704created serwy incompatible change to warnings.showwarning 04/27/08 CLOSED http://bugs.python.org/issue2705created exarkun datetime: define division timedelta/timedelta04/27/08 http://bugs.python.org/issue2706created webograph patch Tiny fix for os.walk docstring 04/28/08 http://bugs.python.org/issue2707created Yinon IDLE subprocess error04/28/08 http://bugs.python.org/issue2708created Kris tk.rst possibly wrong ? 04/28/08 http://bugs.python.org/issue2709created gpolo error: (10035, 'The socket operation could not complete without 04/28/08 http://bugs.python.org/issue2710created dhanlen error: (10035, 'The socket operation could not comple
Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
Thomas Lee wrote: > Martin v. Löwis wrote: >>> This leaves us with a few options: >>> >> >> 5. Reuse/Abuse Num(object) for arbitrary constants. >>AFAICT, this should work out of the box. >> >> > Eek. It *does* seem like Num would work out of the box, but would this > be a good idea? No. I suggested it just for completeness. > What about *replacing* Num with Const? Might make optimizations > specifically for numeric values slightly hairier, and semantically I > think they might be different enough to warrant separate AST nodes > despite the similarity in implementation at the compiler level. I think they should be separate. Const would be a mere addition; for compatibility with other uses of the AST, that's actually better than simultaneous removal of Num. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
> OK - I'll make a patch for this tomorrow (unless someone pipes up > suggesting it's not a great idea, or that ctypes should be used, etc) I'd like to pipe that up. It sounds like clutter of the sys module to me. Isn't there some environment variable you can look at? Some registry key? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
> Sorry, my bad, yes, the platform.architecture() is helpful, the only problem > is that I'd rather settle for a sort of standardized nomenclature for this. > Both platforms use the win32 API, so would Windows XP be win32-32 and x64 be > win32-64 or something like that? We settled that the architecture name is amd64. "64" is not enough, because it can't tell Itanium and AMD64 apart (which are both Win64). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On May 1, 2008, at 7:54 PM, Barry Warsaw wrote: Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me). I guess there's always $PYTHONUSERBASE, but I think I will not be alone. ;) Using ~/.local/ for user-managed content doesn't seem right to me at all, because it's hidden by default. If user-local package installs went to ~/ by default (~/bin/ for scripts, ~/lib/python/ or ~/lib/pythonX.Y/ for modules and packages), with a way to set an alternate "prefix" instead of ~/ using a distutils configuration setting, I'd be happy enough. I'd be even happier if there were no default per-user location, but a required configuration setting (in the existing distutils config locations) in order to enable per-user installation. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
> Windows and Mac OS X have dedicated directories for application specific
> libraries. That is ~/Library on Mac and Application Data on Windows.
In fact, I had to write code for this, and had to read the specs for each.
Here's the code (I've substituted Python for UpLib):
if sys.platform == 'darwin':
listdir = os.path.expanduser(os.path.join("~", "Library", "Application
Support", "org.python"))
elif sys.platform == 'win32':
if os.environ.has_key('APPDATA'):
listdir = os.path.join(os.environ['APPDATA'], 'Python')
elif os.environ.has_key('USERPROFILE'):
listdir = os.path.join(os.environ['USERPROFILE'], 'Application Data',
'Python')
elif os.environ.has_key('HOMEDIR') and os.environ.has_key('HOMEPATH'):
listdir = os.path.join(os.environ['HOMEDIR'], os.environ['HOMEPATH'],
'Python')
else:
listdir = os.path.join(os.path.expanduser("~"), 'Python')
else:
# pretty much has to be unix
listdir = os.path.expanduser(os.path.join("~", ".python"))
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 05:53 pm, [EMAIL PROTECTED] wrote: On May 1, 2008, at 7:54 PM, Barry Warsaw wrote: Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me). I guess there's always $PYTHONUSERBASE, but I think I will not be alone. ;) Using ~/.local/ for user-managed content doesn't seem right to me at all, because it's hidden by default. I don't understand your reason for saying this. Terms like "user" and "manage" are somewhat vague. What sort of experience are you hoping to provide what sort of user with this convention? I hope my earlier explanations were clear as far as the types of users. I believe that the management of ~/.local/ is a subtle question. It will largely be "managed" by simply telling distutils to put files there; I hope, implicitly. In my mind there are 2 types of users who will be "managing" it - newbies, who don't really know what's going on but want "cd mypackage-0.0.1; python setup.py install; python -c 'import mypackage'" (or perhaps even "easy_install mypackage") to work, and advanced users who want to be able to mix-and-match different versions of different packages. Advanced users might already have a PYTHONPATH management (virtual python, virtualenv, combinator, ~/.bashrc hacks, a directory full of symlinks) that already works for them, or be comfortable with inspecting a hidden directory, so ~/.local isn't a problem for them (i.e. us); newbies don't want to see the directory until they already know what's going on. I'd be even happier if there were no default per-user location, but a required configuration setting (in the existing distutils config locations) in order to enable per-user installation. If you're happier without this feature, then perhaps your tastes run counter to a useful implementation of it :). Why wouldn't you want it, though? PYTHONPATH still exists; you don't have to use it, personally. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Barry Warsaw wrote: I think of all the alternatives in PEP 3135, I'd probably prefer self.__super__.foo(), except that I'd call it self.super.foo(). I'm not sure that's sufficient. You need to be able to specify a class when using MI. I'd prefer self.super().foo(). self.super() would take one argument, the base class, optional iff self's class has only one base class. Not that it makes a lick of difference, /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Special offer! Ten code reviews
I'd like to get some more people trying out codereview.appspot.com, so I'm offering the first 10 people to submit a new patch there for my review to do the review by Monday. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 Suggestion: ast
2008/5/2 Georg Brandl <[EMAIL PROTECTED]>: > Paul Moore schrieb: > > Excuse my confusion over process, but if this is to go into 2.6, does > > that mean it needs to be ready before the first beta? Or is there a > > more relaxed schedule for the stdlib (and if so, what is the deadline > > for the stdlib)? > > > > The same question probably applies to the stdlib reorg... > > There is no feature freeze before the first beta. No, but new features aren't allowed *after* the first beta. That's what I'm asking, must the proposed ast module and the stdlib reorg be complete before the first beta (currently Jun 04, or about a month away)? Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Thu, May 1, 2008 at 11:41 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Some of you may have seen a video recorded in November 2006 where I > showed off Mondrian, a code review tool that I was developing for > Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped > that I could release Mondrian as open source, but it was not to be: > due to its popularity inside Google, it became more and more tied to > proprietary Google infrastructure like Bigtable, and it remained > limited to Perforce, the commercial revision control system most used > at Google. I was salivating over that video, so I'm really excited be able to try out something like it now. > Don't hesitate to drop me a note with feedback -- note though that > there are a few known issues listed at the end of the Help page. The > Help page is really a wiki, so feel free to improve it! My request at the moment is to let people use their real names for display; my email address does not at all resemble my name. -- Cheers, Benjamin Peterson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Fri, May 2, 2008 at 2:09 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Thu, May 1, 2008 at 11:41 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Some of you may have seen a video recorded in November 2006 where I > > showed off Mondrian, a code review tool that I was developing for > > Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped > > that I could release Mondrian as open source, but it was not to be: > > due to its popularity inside Google, it became more and more tied to > > proprietary Google infrastructure like Bigtable, and it remained > > limited to Perforce, the commercial revision control system most used > > at Google. > > I was salivating over that video, so I'm really excited be able to try > out something like it now. > > > > Don't hesitate to drop me a note with feedback -- note though that > > there are a few known issues listed at the end of the Help page. The > > Help page is really a wiki, so feel free to improve it! > > My request at the moment is to let people use their real names for > display; my email address does not at all resemble my name. I've noticed. Surely there's an interesting story there. :-) The feature request is on my TODO list. The design is a bit involved, since I'd have to ask people to register and maintain a userid -> nickname mapping; the Google Account API we're piggybacking on only gives you the email address. Once it's open sourced (Monday?) I'd love to see contributions like this! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Fri, May 2, 2008 at 4:25 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > My request at the moment is to let people use their real names for > > display; my email address does not at all resemble my name. > > I've noticed. Surely there's an interesting story there. :-) Maybe I tell you why next PyCon... One more question: What's the number on the upper right hand corner by my username? -- Cheers, Benjamin Peterson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker issues? server error
On Fri, May 2, 2008 at 12:17 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > trying to update a bug I get: > > Fri May 2 07:17:17 2008: An error occurred. Please check the server log for > more infomation. > Issues like this should go to the meta-tracker. Fail that, mail tracker-discuss. But I just created an issue without problems so that is at least working. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Fri, May 2, 2008 at 2:28 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > One more question: What's the number on the upper right hand corner by > my username? It's a debugging counter. It gets reset each time a new service instance is created. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Special offer! Ten code reviews
Guido van Rossum schrieb: > I'd like to get some more people trying out codereview.appspot.com, so > I'm offering the first 10 people to submit a new patch there for my > review to do the review by Monday. Oh gosh! As I read the title I was hoping for a free beer or a signed Guido photography for my heroes collection ... :) Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
Agreed, I tend to pick these out of style reviews at Google. On Fri, May 2, 2008 at 4:03 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > Some people write > somename = lambda args: expression > instead of the more obvious (to most people) and, dare I say, standard > def somename(args): return expression > > The difference in the result (the only one I know of) is that the code and > function objects get the generic name '' instead of the more > informative (in repr() output or tracebacks) 'somename'. I consider this a > disadvantage. > > In the absence of any compensating advantages (other than the trivial > saving of 3 chars), I consider the def form to be the proper Python style > to the point I think it should be at least recommended for the stdlib in > the Programming Recommendations section of PEP 8. > > There are currently uses of named lambdas at least in urllib2. This to me > is a bad example for new Python programmers. > > What do our style mavens think? > > Terry Jan Reedy > > > > > > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
+1 from me On May 2, 2008, at 7:03 PM, "Terry Reedy" <[EMAIL PROTECTED]> wrote: Some people write somename = lambda args: expression instead of the more obvious (to most people) and, dare I say, standard def somename(args): return expression The difference in the result (the only one I know of) is that the code and function objects get the generic name '' instead of the more informative (in repr() output or tracebacks) 'somename'. I consider this a disadvantage. In the absence of any compensating advantages (other than the trivial saving of 3 chars), I consider the def form to be the proper Python style to the point I think it should be at least recommended for the stdlib in the Programming Recommendations section of PEP 8. There are currently uses of named lambdas at least in urllib2. This to me is a bad example for new Python programmers. What do our style mavens think? Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8: Discourage named lambdas?
Some people write somename = lambda args: expression instead of the more obvious (to most people) and, dare I say, standard def somename(args): return expression The difference in the result (the only one I know of) is that the code and function objects get the generic name '' instead of the more informative (in repr() output or tracebacks) 'somename'. I consider this a disadvantage. In the absence of any compensating advantages (other than the trivial saving of 3 chars), I consider the def form to be the proper Python style to the point I think it should be at least recommended for the stdlib in the Programming Recommendations section of PEP 8. There are currently uses of named lambdas at least in urllib2. This to me is a bad example for new Python programmers. What do our style mavens think? Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On 2-May-08, at 4:03 PM, Terry Reedy wrote: Some people write somename = lambda args: expression instead of the more obvious (to most people) and, dare I say, standard def somename(args): return expression The difference in the result (the only one I know of) is that the code and function objects get the generic name '' instead of the more informative (in repr() output or tracebacks) 'somename'. I consider this a disadvantage. In the absence of any compensating advantages (other than the trivial saving of 3 chars), I consider the def form to be the proper Python style to the point I think it should be at least recommended for the stdlib in the Programming Recommendations section of PEP 8. There are currently uses of named lambdas at least in urllib2. This to me is a bad example for new Python programmers. What do our style mavens think? I'm not a style maven, but I'll put forward why I don't think this is bad style. Most importantly, these statements can result from sensible changes from what is (I believe) considered good style. For example, consider: registerCallback(lambda: frobnicate(7)) what if there are too places that the callback needs to be registered? registerCallback(lambda: frobnicate(7)) registerCallback2(lambda: frobnicate(7)) DRY leads to factoring this out into a variable in a straightforward manner: callback = lambda: frobnicate(7) registerCallback(callback) registerCallback2(callback) Another thing to consider is that the def() pattern is only possible when the bound variable has no dots. A common pattern for me is to replace an instances method with a lambda to add monitoring hooks or disable certain functionality: inst.get_foo = lambda: FakeFoo() This is not replacable in one line with a def (or without locals() detritius). Assuming this is good style, it seems odd that inst.get_foo = lambda: FakeFoo() is acceptible style, but get_foo = lambda: FakeFoo() isn't. (I also happen to think that the def pattern is less clear in some situations, but that speaks more to personal taste so isn't particularly relevant) -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Fred> If user-local package installs went to ~/ by default ... with a Fred> way to set an alternate "prefix" instead of ~/ using a distutils Fred> configuration setting, I'd be happy enough. +1 from me. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] AST Optimization: Branch Elimination in Generator Functions
The next problem that cropped up during the implementation of the AST code optimizer is related to branch elimination and the elimination of any code after a return. Within a FunctionDef node, we would (ideally) like to blow away If nodes with a constant - but false - test expression. e.g.: def foo(): if False: # ... stuff ... For most functions, this will cause no problems and the code will behave as expected. However, if the eliminated branch contains a "yield" expression, the function is actually a generator function - even if the yield expression can never be reached: def foo(): if False: yield 5 In addition to this, the following should also be treated as a generator even though we'd like to be able to get rid of all the code following the "return" statement: def foo(): return yield 5 Again, blowing away the yield results in a normal function instead of a generator. Not what we want: we need to preserve the generator semantics. Upon revisiting this, it's actually made me reconsider the use of a Const node for the earlier problem relating to arbitrary constants. We may be better off with annotations after all ... then we could mark FunctionDef nodes as being generators at the AST level to force the compiler to produce code for a generator, but eliminate the branches anyway. The other alternative I can think of is injecting a yield node somewhere unreachable and ensuring it doesn't get optimized away, but this seems pretty hacky in comparison. Any other ideas? Cheers, Tom ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
+1 For what it's worth from a newbie ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
> > OK - I'll make a patch for this tomorrow (unless someone pipes up > > suggesting it's not a great idea, or that ctypes should be used, etc) > > I'd like to pipe that up. I thought you might. > It sounds like clutter of the sys module to > me. Fair enough - but no more than getwindowsversion IMO (and it seems it would be used in similar situations to getwindowsversion, in terms of wanting to know fundamental characteristics of the OS.) But I don't personally care - although I added this to pywin32 some time ago, I decided to wait for someone else to request it before submitting it for inclusion in the core. > Isn't there some environment variable you can look at? > Some registry key? Not that I'm aware of. I've uploaded my patch as http://bugs.python.org/issue2745, and I've taken the liberty of adding you to the nosy list, incase you wish to reject it outright (but I'm likely to assume silence for a few weeks on a tracker issue means no serious objections - at least none so serious they can't be rectified by reverting the change) Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] AST Optimization: Branch Elimination in Generator Functions
The next problem that cropped up during the implementation of the AST code optimizer is related to branch elimination and the elimination of any code after a return. Within a FunctionDef node, we would (ideally) like to blow away If nodes with a constant - but false - test expression. e.g.: def foo(): if False: # ... stuff ... For most functions, this will cause no problems and the code will behave as expected. However, if the eliminated branch contains a "yield" expression, the function is actually a generator function - even if the yield expression can never be reached: def foo(): if False: yield 5 In addition to this, the following should also be treated as a generator even though we'd like to be able to get rid of all the code following the "return" statement: def foo(): return yield 5 Again, blowing away the yield results in a normal function instead of a generator. Not what we want: we need to preserve the generator semantics. Upon revisiting this, it's actually made me reconsider the use of a Const node for the earlier problem relating to arbitrary constants. We may be better off with annotations after all ... then we could mark FunctionDef nodes as being generators at the AST level to force the compiler to produce code for a generator, but eliminate the branches anyway. The other alternative I can think of is injecting a yield node somewhere unreachable and ensuring it doesn't get optimized away, but this seems pretty hacky in comparison. Any other ideas? Cheers, Tom ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On Fri, May 2, 2008 at 4:11 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > +1 from me +2 from me -- of all abuses of lambdas, this one's the worst. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On Sat, May 3, 2008 at 1:03 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > Some people write > somename = lambda args: expression > instead of the more obvious (to most people) and, dare I say, standard > def somename(args): return expression > > The difference in the result (the only one I know of) is that the code and > function objects get the generic name '' instead of the more > informative (in repr() output or tracebacks) 'somename'. I consider this a > disadvantage. > > In the absence of any compensating advantages (other than the trivial > saving of 3 chars), I consider the def form to be the proper Python style > to the point I think it should be at least recommended for the stdlib in > the Programming Recommendations section of PEP 8. > > There are currently uses of named lambdas at least in urllib2. This to me > is a bad example for new Python programmers. > > What do our style mavens think? +1. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
Mike Klaas wrote: ... A common pattern for me is to replace an instances method with a lambda to add monitoring hooks or disable certain functionality: inst.get_foo = lambda: FakeFoo() This is not replacable in one line with a def (or without locals() detritius). Assuming this is good style, it seems odd that inst.get_foo = lambda: FakeFoo() is acceptible style, but get_foo = lambda: FakeFoo() But surely, none of these are great style, and in fact the lambda lures you into using it. I'd propose a far better use is: inst.get_foo = FakeFoo or get_foo = FakeFoo --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On 2-May-08, at 11:23 PM, Scott David Daniels wrote: Mike Klaas wrote: ... A common pattern for me is to replace an instances method with a lambda to add monitoring hooks or disable certain functionality: inst.get_foo = lambda: FakeFoo() This is not replacable in one line with a def (or without locals() detritius). Assuming this is good style, it seems odd that inst.get_foo = lambda: FakeFoo() is acceptible style, but get_foo = lambda: FakeFoo() But surely, none of these are great style, and in fact the lambda lures you into using it. I'd propose a far better use is: inst.get_foo = FakeFoo or get_foo = FakeFoo Sorry, that was a bad example. It is obviously silly if the return value of the function is callable. -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
