Re: [webkit-dev] Python

[Alicia Boya García]

On 08/12/2017 11:40 PM, Ryosuke Niwa wrote:
> On Fri, Aug 11, 2017 at 8:06 AM, Michael Catanzaro
>  wrote:
>> On Mon, Aug 7, 2017 at 10:56 AM, Carlos Alberto Lopez Perez
>>  wrote:
>>>
>>> That's a good thing.
>>>
>>> I believe all Linux distros we support have this, right?
>>> And all the scripts actually assume python2.7 (AFAIK).
>>>
>>> Would it work for everyone having as shebang :
>>>
>>> #!/usr/bin/env python2.7
>>>
>>> ?
>>
>>
>> So this is by far the easiest solution of those that have been proposed. I
>> think we should try this as a stopgap until macOS is fixed to provide a
>> python2 binary.
> 
> What's wrong with using that as the permanent solution until we make
> it Python3 compatible?
> 
> I don't think it's wise to assume /usr/bin/python2 will be added on
> Mac anytime soon.
> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

+1, python2.7 is well supported among different systems.

It would be desirable to move to Python 3 eventually, but that's an
endeavor that should not be taken lightly, as many things can break in
subtle ways.

--
Alicia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Ryosuke Niwa]

On Fri, Aug 11, 2017 at 8:06 AM, Michael Catanzaro
 wrote:
> On Mon, Aug 7, 2017 at 10:56 AM, Carlos Alberto Lopez Perez
>  wrote:
>>
>> That's a good thing.
>>
>> I believe all Linux distros we support have this, right?
>> And all the scripts actually assume python2.7 (AFAIK).
>>
>> Would it work for everyone having as shebang :
>>
>> #!/usr/bin/env python2.7
>>
>> ?
>
>
> So this is by far the easiest solution of those that have been proposed. I
> think we should try this as a stopgap until macOS is fixed to provide a
> python2 binary.

What's wrong with using that as the permanent solution until we make
it Python3 compatible?

I don't think it's wise to assume /usr/bin/python2 will be added on
Mac anytime soon.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Michael Catanzaro]

On Mon, Aug 7, 2017 at 10:56 AM, Carlos Alberto Lopez Perez 
 wrote:

That's a good thing.

I believe all Linux distros we support have this, right?
And all the scripts actually assume python2.7 (AFAIK).

Would it work for everyone having as shebang :

#!/usr/bin/env python2.7

?


So this is by far the easiest solution of those that have been 
proposed. I think we should try this as a stopgap until macOS is fixed 
to provide a python2 binary.


Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Adrian Perez de Castro]

Hi all,

What I have been doing is having a Python 2.7 virtualenv [1], which gets
automatically enabled (or disabled) when changing directory under (or out of)
the WebKit source tree by means of zsh-autoenv [2]. This way the “python”
binary is the one for Python 2.7 inside the virtualenv, and I do not need to
remember about doing any setup manually when navigating directories in the
shell.

On Mon, 7 Aug 2017 17:56:51 +0200, Carlos Alberto Lopez Perez 
 wrote:
> On 07/08/17 17:44, Andy Estes wrote:
> >>> last I checked, macOS did not provide a python2 binary either. I am 
> >>> hoping that has changed in the past few years. Has it?
> >> Nope.
> > macOS does have /usr/bin/python2.7, though.
>
> That's a good thing.

This would work for people using a virtualenv as well:

  WebKit % which python2.7
  /home/aperez/.virtualenvs/webkit/bin/python2.7
  WebKit %

> I believe all Linux distros we support have this, right?
> And all the scripts actually assume python2.7 (AFAIK).

Arch Linux has a “python2.7” binary system-wide, too. The default installation
done when building Python always creates:

  ${prefix}/bin/python2.7
  ${prefix}/bin/python2 -> python2.7
  ${prefix}/bin/python -> python2.7

So I would expect most systems which ship Python to have a “python2.7” binary.

Cheers,


---
[1] https://virtualenv.pypa.io/en/stable/
[2] https://github.com/Tarrasch/zsh-autoenv


pgp415GiH1LYh.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Michael Catanzaro]

On Mon, Aug 7, 2017 at 1:17 PM, Keith Miller  
wrote:
Out of curiosity, is this just about building or is part of the 
concern with development scripts?


Both.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Keith Miller]

Out of curiosity, is this just about building or is part of the concern with 
development scripts? 

AFAICT, we invoke all our python scripts by invoking $(PYTHON), which can be 
whatever path you need. I didn’t look too closely though...

Cheers,
Keith

> On Aug 7, 2017, at 6:47 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> As you're probably already aware, in Arch Linux /usr/bin/python has been a 
> symlink to /usr/bin/python3 for a long time now. In practice this means that 
> Arch users are not going to be able to use basically any of our Python 
> scripts, since our scripts use the shebang #!/usr/bin/env python but expect 
> it to be python2. This has not really been a problem until now because none 
> of Igalia's developers use Arch, and occasional contributions rarely need to 
> use the Python scripts. But our scripts have been broken this whole time, 
> since the Python maintainers have decided the only reasonable way to avoid 
> this problem is for scripts to explicitly specify either python2 or python3, 
> and we have not been doing that. To be clear: the problem is that 
> #!/usr/bin/env python is *python3* on some systems, but *python2* on others. 
> WebKit scripts incorrectly assume it is always python2. I say "incorrectly" 
> because the Python folks have ratified some bizarre standard for how to 
> handle this, PEP 394 [1], which states: "in preparation for an eventual 
> change in the default version of Python, Python 2 only scripts should either 
> be updated to be source compatible with Python 3 or else to use python2 in 
> the shebang line." Lovely.
> 
> Now Fedora is planning to switch /usr/bin/python to link to /usr/bin/python3 
> instead of /usr/bin/python2 [2]. Not for another three years, but many of us 
> (hi! :) use Fedora, so we're going to have to fix our scripts by then. This 
> could be really easy, or it could be really hard.
> 
> The really easy solution is to just replace #!/usr/bin/env python with 
> #!/usr/bin/env python2 everywhere. This will work on all Linux distros newer 
> than Red Hat Enterprise Linux 6 or thereabouts, which we definitely do not 
> care about anymore. It doesn't work in very old distros because they did not 
> provide /usr/bin/python2, only /usr/bin/python and very specific links like 
> /usr/bin/python2.6. That doesn't matter because we don't care about those old 
> systems anymore, but the problem is that last I checked, macOS did not 
> provide a python2 binary either. I am hoping that has changed in the past few 
> years. Has it? If so, I can upload a patch to do this simple find/replace and 
> we can all move on. If this is the case, yay! Stop reading now! Let me know. 
> We should do that!
> 
> But if not, we need to decide what to do among bad options:
> 
> * We could replace all our Python scripts that have shebangs with .in files, 
> and perform configure replacements at CMake/XCode configure time to generate 
> the scripts with the right python executable path. This would mean the 
> scripts would be generated into the WebKit build directory instead of the 
> source directory, so it will break those of us who have added Tools/Scripts 
> to our PATH. It's not clear how they would find the right resource paths in 
> the source directory, especially if using a build directory other than 
> WebKit/WebKitBuild. I'm not even sure if XCode can do configure replacements. 
> This would be a mess.
> * We could require Mac developers to install a python2 symlink somewhere in 
> PATH. Not really desirable, but possibly tolerable?
> * We could port all our Python scripts to python3 and use #!/usr/bin/env 
> python3, which will surely be unambiguous. But my understanding is that macOS 
> does not have python3, so it will need to be installed locally. I guess that 
> would be tolerable? Anyway, the main disadvantage here is we'd have to make 
> all our scripts work with python3. If WebKit was a Linux-only project, we 
> should definitely do that anyway, since major Linux distros no longer ship 
> python2 by default: it's something we install extra now. But if macOS is 
> sticking with python2, it would probably be undesirable to port our scripts 
> to python3.
> * We could make all our Python scripts compatible with both python2 and 
> python3, and maintain them this way forever. I really hope we can avoid this 
> option, since we'd be breaking these scripts all the time as we would all 
> surely not test one configuration or the other.
> 
> Any other ideas?
> 
> Michael
> 
> [1] https://www.python.org/dev/peps/pep-0394/
> [2] https://lwn.net/SubscriberLink/729366/1d3cd2dbaea7070b/
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Olmstead, Don]

There are automated tools that will update to Python 3 while keeping 
compatibility with Python 2.

There is future, http://python-future.org/automatic_conversion.html,  and 
modernizer, https://python-modernize.readthedocs.io/en/latest 

This came up in https://bugs.webkit.org/show_bug.cgi?id=170439 and it seemed 
like 2/3 compatibility would be the ideal solution.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Michael Catanzaro
Sent: Monday, August 7, 2017 8:13 AM
To: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Python

On Mon, Aug 7, 2017 at 8:47 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
>  This has not really been a problem until now because none of Igalia's 
> developers use Arch, and occasional contributions rarely need to use 
> the Python scripts.

I stand corrected: we have one developer who has been using an elaborate local 
hack [1] to get WebKit's python scripts to work. Wow

[1]
https://wiki.archlinux.org/index.php/python#Dealing_with_version_problem_in_build_scripts

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Michael Catanzaro]

On Mon, Aug 7, 2017 at 10:56 AM, Carlos Alberto Lopez Perez 
 wrote:

That's a good thing.

I believe all Linux distros we support have this, right?
And all the scripts actually assume python2.7 (AFAIK).

Would it work for everyone having as shebang :

#!/usr/bin/env python2.7

?


Um... that's really terrible, but I guess it should work, yes. Perhaps 
that's the path of least resistance for us.


Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Carlos Alberto Lopez Perez]

On 07/08/17 17:44, Andy Estes wrote:
>>> last I checked, macOS did not provide a python2 binary either. I am hoping 
>>> that has changed in the past few years. Has it?
>> Nope.
> macOS does have /usr/bin/python2.7, though.
> 

That's a good thing.

I believe all Linux distros we support have this, right?
And all the scripts actually assume python2.7 (AFAIK).

Would it work for everyone having as shebang :

#!/usr/bin/env python2.7

?



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Andy Estes]

> On Aug 7, 2017, at 8:41 AM, Andy Estes  wrote:
> 
> 
> 
>> On Aug 7, 2017, at 6:47 AM, Michael Catanzaro > > wrote:
>> 
>> last I checked, macOS did not provide a python2 binary either. I am hoping 
>> that has changed in the past few years. Has it?
> 
> Nope.

macOS does have /usr/bin/python2.7, though.

> 
> Andy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Andy Estes]

> On Aug 7, 2017, at 6:47 AM, Michael Catanzaro  wrote:
> 
> last I checked, macOS did not provide a python2 binary either. I am hoping 
> that has changed in the past few years. Has it?

Nope.

Andy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Michael Catanzaro]

On Mon, Aug 7, 2017 at 8:47 AM, Michael Catanzaro 
 wrote:
 This has not really been a problem until now because none of 
Igalia's developers use Arch, and occasional contributions rarely 
need to use the Python scripts.


I stand corrected: we have one developer who has been using an 
elaborate local hack [1] to get WebKit's python scripts to work. Wow


[1] 
https://wiki.archlinux.org/index.php/python#Dealing_with_version_problem_in_build_scripts


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Python

[Konstantin Tokarev]

07.08.2017, 16:47, "Michael Catanzaro" :
> Hi,
>
> As you're probably already aware, in Arch Linux /usr/bin/python has
> been a symlink to /usr/bin/python3 for a long time now. In practice
> this means that Arch users are not going to be able to use basically
> any of our Python scripts, since our scripts use the shebang
> #!/usr/bin/env python but expect it to be python2. This has not really
> been a problem until now because none of Igalia's developers use Arch,
> and occasional contributions rarely need to use the Python scripts. But
> our scripts have been broken this whole time, since the Python
> maintainers have decided the only reasonable way to avoid this problem
> is for scripts to explicitly specify either python2 or python3, and we
> have not been doing that. To be clear: the problem is that
> #!/usr/bin/env python is *python3* on some systems, but *python2* on
> others. WebKit scripts incorrectly assume it is always python2. I say
> "incorrectly" because the Python folks have ratified some bizarre
> standard for how to handle this, PEP 394 [1], which states: "in
> preparation for an eventual change in the default version of Python,
> Python 2 only scripts should either be updated to be source compatible
> with Python 3 or else to use python2 in the shebang line." Lovely.
>
> Now Fedora is planning to switch /usr/bin/python to link to
> /usr/bin/python3 instead of /usr/bin/python2 [2]. Not for another three
> years, but many of us (hi! :) use Fedora, so we're going to have to fix
> our scripts by then. This could be really easy, or it could be really
> hard.
>
> The really easy solution is to just replace #!/usr/bin/env python with
> #!/usr/bin/env python2 everywhere. This will work on all Linux distros
> newer than Red Hat Enterprise Linux 6 or thereabouts, which we
> definitely do not care about anymore. It doesn't work in very old
> distros because they did not provide /usr/bin/python2, only
> /usr/bin/python and very specific links like /usr/bin/python2.6. That
> doesn't matter because we don't care about those old systems anymore,
> but the problem is that last I checked, macOS did not provide a python2
> binary either. I am hoping that has changed in the past few years. Has
> it? If so, I can upload a patch to do this simple find/replace and we
> can all move on. If this is the case, yay! Stop reading now! Let me
> know. We should do that!
>
> But if not, we need to decide what to do among bad options:
>
>  * We could replace all our Python scripts that have shebangs with .in
> files, and perform configure replacements at CMake/XCode configure time
> to generate the scripts with the right python executable path. This
> would mean the scripts would be generated into the WebKit build
> directory instead of the source directory, so it will break those of us
> who have added Tools/Scripts to our PATH. It's not clear how they would
> find the right resource paths in the source directory, especially if
> using a build directory other than WebKit/WebKitBuild. I'm not even
> sure if XCode can do configure replacements. This would be a mess.
>  * We could require Mac developers to install a python2 symlink
> somewhere in PATH. Not really desirable, but possibly tolerable?
>  * We could port all our Python scripts to python3 and use
> #!/usr/bin/env python3, which will surely be unambiguous. But my
> understanding is that macOS does not have python3, so it will need to
> be installed locally. I guess that would be tolerable? Anyway, the main
> disadvantage here is we'd have to make all our scripts work with
> python3. If WebKit was a Linux-only project, we should definitely do
> that anyway, since major Linux distros no longer ship python2 by
> default: it's something we install extra now. But if macOS is sticking
> with python2, it would probably be undesirable to port our scripts to
> python3.
>  * We could make all our Python scripts compatible with both python2
> and python3, and maintain them this way forever. I really hope we can
> avoid this option, since we'd be breaking these scripts all the time as
> we would all surely not test one configuration or the other.

I think the latter option is quite feasible. The most widespread reason of
incompatibility with python3 is use of print operator instead of print()
function. I have a local patch that fixes these things, and it can be enforced 
by
style checker to keep new code compatible.

There are other issues, which are affecting just a few scripts (unfortunately 
they
are used in a build process). Those can be fixed once, and then we can rely on
python3 users to report incompatibilities. Anyway, these issues affect only code
that is already "legacy" in terms of python 2.7

>
> Any other ideas?
>
> Michael
>
> [1] https://www.python.org/dev/peps/pep-0394/
> [2] https://lwn.net/SubscriberLink/729366/1d3cd2dbaea7070b/
>
> ___
> webkit-dev mailing list
> 

Re: [webkit-dev] Python on the Tiger build bot

[鵜飼文敏]

I heard on #webkit that the Tiger bot has been on Python 2.5 for some time,
and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886 and
https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have consensus
to use Python 2.5 (or later) for webkit development environment.

I tried to land autoinstalled pywebsocket 0.5
https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on tiger
bot when launching websocket server as below.
Is python on the tiger bot still 2.3?
I'm wondering why the script raises SyntaxError at with-statement, although
it uses from __future__ import with_statement at the beginning of the same
file.
Doesn't python raise error when it tries to import with_statement, rather
than it sees with statement later?

Anyway, I just marked to skip websocket/tests on tiger for now, hoping
python2.5 is available on tiger bot soon.

This is log:
http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio
websocket/tests .Traceback (most recent call last):
  File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ?
import webkitpy.layout_tests.port.websocket_server as websocket_server
  File
/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py,
line 241
with codecs.open(self._pidfile, w, ascii) as file:
  ^
SyntaxError: invalid syntax

websocket/tests/bad-handshake-crash.html - failed
.
websocket/tests/bad-sub-protocol-control-chars.html - failed
.
websocket/tests/bad-sub-protocol-empty.html - failed
.
websocket/tests/bad-sub-protocol-non-ascii.html - failed
.
websocket/tests/bufferedAmount-after-close.html - failed
.
websocket/tests/close-on-navigate-new-location.html - failed
.
websocket/tests/close-on-unload-and-force-gc.html - failed
.
websocket/tests/close-on-unload-reference-in-parent.html - failed
.
websocket/tests/close-on-unload.html - failed
.
websocket/tests/cross-origin.html - failed
.
websocket/tests/error-detect.html - failed
.
websocket/tests/frame-length-longer-than-buffer.html - failed
.
websocket/tests/frame-length-skip.html - failed
.
websocket/tests/frame-lengths.html - failed
.
websocket/tests/handshake-error.html - failed
.
websocket/tests/handshake-fail-by-cross-origin.html - failed
.
websocket/tests/handshake-fail-by-sub-protocol-mismatch.html - failed
.
websocket/tests/httponly-cookie.pl - failed
.
websocket/tests/long-invalid-header.html - failed
.
websocket/tests/multiple-connections.html - failed

Exiting early after 20 failures. 17934 tests run.
762.46s total testing time
Traceback (most recent call last):
  File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ?
import webkitpy.layout_tests.port.websocket_server as websocket_server
  File
/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py,
line 241
with codecs.open(self._pidfile, w, ascii) as file:
  ^
SyntaxError: invalid syntax

--
ukai

On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote:


 On May 10, 2010, at 11:01 PM, Eric Seidel wrote:

  On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote:

 My feeling about requiring a higher Python version for Tiger remains
 this:

 I'd prefer that we provide an easy means to do the install of Python 2.6
 (ideally a single script you can run, and ideally without affecting the
 system copy), rather than making every Tiger developer figure it out on
 their own.
 http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

 For those of us who still need to support Tiger, it would be a huge
 hassle
 to have to figure out how to update Python manually to even run the
 layout
 tests. The fact that it's not a primary development platform doesn't mean
 that it's ok to add stumbling blocks to the development process. In fact,
 it
 kinda makes it less ok, because then it takes more work to shift gears
 when
 fixing a Tiger-specific bug.


 Provided:
 https://bugs.webkit.org/show_bug.cgi?id=38886

  At minimum, there should be instructions here, and ideally the install
 should be one step:
 http://webkit.org/building/tools.html


 Provided:
 https://bugs.webkit.org/show_bug.cgi?id=38822


 Yay thanks! (Will try to review these later if no one beats me.)

 Regards,
 Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Eric Seidel]

That error looks like its trying to use python  2.5.

Skipping the websocket tests on Tiger (manually at least) is bad.
Would be better to do it based on detected python.  Filed:
https://bugs.webkit.org/show_bug.cgi?id=39058
about doing just that.

-eric

On Thu, May 13, 2010 at 2:14 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.org wrote:
 I heard on #webkit that the Tiger bot has been on Python 2.5 for some time,
 and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886
 and https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have
 consensus to use Python 2.5 (or later) for webkit development environment.
 I tried to land autoinstalled pywebsocket
 0.5 https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on
 tiger bot when launching websocket server as below.
 Is python on the tiger bot still 2.3?
 I'm wondering why the script raises SyntaxError at with-statement, although
 it uses from __future__ import with_statement at the beginning of the same
 file.
 Doesn't python raise error when it tries to import with_statement, rather
 than it sees with statement later?
 Anyway, I just marked to skip websocket/tests on tiger for now, hoping
 python2.5 is available on tiger bot soon.
 This is log:
  http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio
 websocket/tests .Traceback (most recent call last):
   File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ?
     import webkitpy.layout_tests.port.websocket_server as websocket_server
   File
 /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py,
 line 241
     with codecs.open(self._pidfile, w, ascii) as file:
               ^
 SyntaxError: invalid syntax
 websocket/tests/bad-handshake-crash.html - failed
 .
 websocket/tests/bad-sub-protocol-control-chars.html - failed
 .
 websocket/tests/bad-sub-protocol-empty.html - failed
 .
 websocket/tests/bad-sub-protocol-non-ascii.html - failed
 .
 websocket/tests/bufferedAmount-after-close.html - failed
 .
 websocket/tests/close-on-navigate-new-location.html - failed
 .
 websocket/tests/close-on-unload-and-force-gc.html - failed
 .
 websocket/tests/close-on-unload-reference-in-parent.html - failed
 .
 websocket/tests/close-on-unload.html - failed
 .
 websocket/tests/cross-origin.html - failed
 .
 websocket/tests/error-detect.html - failed
 .
 websocket/tests/frame-length-longer-than-buffer.html - failed
 .
 websocket/tests/frame-length-skip.html - failed
 .
 websocket/tests/frame-lengths.html - failed
 .
 websocket/tests/handshake-error.html - failed
 .
 websocket/tests/handshake-fail-by-cross-origin.html - failed
 .
 websocket/tests/handshake-fail-by-sub-protocol-mismatch.html - failed
 .
 websocket/tests/httponly-cookie.pl - failed
 .
 websocket/tests/long-invalid-header.html - failed
 .
 websocket/tests/multiple-connections.html - failed
 Exiting early after 20 failures. 17934 tests run.
 762.46s total testing time
 Traceback (most recent call last):
   File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ?
     import webkitpy.layout_tests.port.websocket_server as websocket_server
   File
 /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py,
 line 241
     with codecs.open(self._pidfile, w, ascii) as file:
               ^
 SyntaxError: invalid syntax
 --
 ukai
 On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote:

 On May 10, 2010, at 11:01 PM, Eric Seidel wrote:

 On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote:

 My feeling about requiring a higher Python version for Tiger remains
 this:

 I'd prefer that we provide an easy means to do the install of Python
 2.6
 (ideally a single script you can run, and ideally without affecting the
 system copy), rather than making every Tiger developer figure it out on
 their own.
 http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

 For those of us who still need to support Tiger, it would be a huge
 hassle
 to have to figure out how to update Python manually to even run the
 layout
 tests. The fact that it's not a primary development platform doesn't
 mean
 that it's ok to add stumbling blocks to the development process. In
 fact, it
 kinda makes it less ok, because then it takes more work to shift gears
 when
 fixing a Tiger-specific bug.

 Provided:
 https://bugs.webkit.org/show_bug.cgi?id=38886

 At minimum, there should be instructions here, and ideally the install
 should be one step:
 http://webkit.org/building/tools.html

 Provided:
 https://bugs.webkit.org/show_bug.cgi?id=38822

 Yay thanks! (Will try to review these later if no one beats me.)

 Regards,
 Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Alexey Proskuryakov]

13.05.2010, в 06:15, Eric Seidel написал(а):

 That error looks like its trying to use python  2.5.
 
 Skipping the websocket tests on Tiger (manually at least) is bad.
 Would be better to do it based on detected python.  Filed:
 https://bugs.webkit.org/show_bug.cgi?id=39058
 about doing just that.

I don't think that skipping tests due to a different version of python 
installed is acceptable. Either new python should be installed, or tests should 
fail, silently ignoring them is wrong.

Better yet, run-webkit-tests should work with all versions of python that are 
shipped on supported Mac OS X versions.

Unless someone is going to update python on buildbots, rolling out the patch 
again seems to be the only option.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Maciej Stachowiak]

On May 10, 2010, at 11:01 PM, Eric Seidel wrote:

On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com  
wrote:
My feeling about requiring a higher Python version for Tiger  
remains this:


I'd prefer that we provide an easy means to do the install of  
Python 2.6
(ideally a single script you can run, and ideally without affecting  
the
system copy), rather than making every Tiger developer figure it  
out on

their own.
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

For those of us who still need to support Tiger, it would be a huge  
hassle
to have to figure out how to update Python manually to even run the  
layout
tests. The fact that it's not a primary development platform  
doesn't mean
that it's ok to add stumbling blocks to the development process. In  
fact, it
kinda makes it less ok, because then it takes more work to shift  
gears when

fixing a Tiger-specific bug.


Provided:
https://bugs.webkit.org/show_bug.cgi?id=38886

At minimum, there should be instructions here, and ideally the  
install

should be one step:
http://webkit.org/building/tools.html


Provided:
https://bugs.webkit.org/show_bug.cgi?id=38822


Yay thanks! (Will try to review these later if no one beats me.)

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Maciej Stachowiak]

On May 7, 2010, at 9:10 PM, Eric Seidel wrote:


2.  Additionally, Tiger seems mostly ignored by WebKit (note examples
like https://bugs.webkit.org/show_bug.cgi?id=38743).  No one develops
on Tiger to my knowledge (note mjs last night in #webkit noting how he
had no access to a Tiger machine, I certainly don't have access to
one).


I do have access to one at work, just not at home (I can only fit so  
many OS partitions on one laptop.)




I'm happy to add a brief note to the tools.html page noting that
python 2.5 is required and linking to a page.

Our scripts already print:
webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
support your current Python version (2.4.6).  The minimum supported
version is 2.5.

I'm happy to augment that warning to provide a download URL.

In short, I don't think Tiger (which appears legacy and
maintenance-mode only at this point) should hold hostage our script
development on all platforms.  We should simply update the bot and be
done with things. :)


My feeling about requiring a higher Python version for Tiger remains  
this:


I'd prefer that we provide an easy means to do the install of Python  
2.6 (ideally a single script you can run, and ideally without  
affecting the system copy), rather than making every Tiger developer  
figure it out on their own.

http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

For those of us who still need to support Tiger, it would be a huge  
hassle to have to figure out how to update Python manually to even run  
the layout tests. The fact that it's not a primary development  
platform doesn't mean that it's ok to add stumbling blocks to the  
development process. In fact, it kinda makes it less ok, because then  
it takes more work to shift gears when fixing a Tiger-specific bug.


At minimum, there should be instructions here, and ideally the install  
should be one step:

http://webkit.org/building/tools.html

I understand that Google is not interested in supporting Tiger, but  
please be kind to those of us who do have to support it (for now  
anyway).


Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Eric Seidel]

I am not certain as to which agreement you refer.  However, I can
understand that historically we viewed the python tools as less
essential than they appear to have become.

Just as we moved from CVS to SVN and at that time required all Tiger
machines to install an SVN package, so too today are an increasingly
large number of our scripts moving from depending on perl 5 to Python
2.5+.

I would appreciate assistance from the bot maintainer to update the
one Tiger machine, as it is the only machine which uses such an old
copy of Python.  All other operating systems/machines already use much
newer versions of Python.  The WebKit project requires Leopard's 2.5
python as a minimum installed version.

I will post a patch to update the tools.html page to note the
requirement shortly.

-eric

On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov a...@webkit.org wrote:

 I thought the agreement was that essential tools shouldn't add more 
 requirements on the installed tools. Is it not the case?

 - WBR, Alexey Proskuryakov


 06.05.2010, в 21:30, Eric Seidel написал(а):

 WebKitTools/Scripts/webkitpy python requires 2.5+.

 We'd like to be able to use python 2.5 on the Tiger build bot (for
 websocket tests among other things).

 Would someone be able to install a newer Tiger on that machine?

 Here is python 2.6.5 for the mac:
 http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg

 Thanks!

 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Chris Jerdonek]

[Re-sending from correct address]

On Fri, May 7, 2010 at 9:10 PM, Eric Seidel e...@webkit.org wrote:
 I'm happy to add a brief note to the tools.html page noting that
 python 2.5 is required and linking to a page.

A couple months ago I started a page that contains instructions on how
to upgrade:

http://trac.webkit.org/wiki/PythonGuidelines#UpgradingfromPython2.3orPython2.4

 Our scripts already print:
 webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
 support your current Python version (2.4.6).  The minimum supported
 version is 2.5.

 I'm happy to augment that warning to provide a download URL.

That message already contains an URL actually (as of 5 weeks ago):

test-webkitpy: WARNING  WebKit Python scripts do not support your
current Python version (2.4.6).  The minimum supported version is 2.5.
 See the following page to upgrade your Python version:

   http://trac.webkit.org/wiki/PythonGuidelines

--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Sam Weinig]

This was my understanding as well.

-Sam

On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov a...@webkit.org wrote:


 I thought the agreement was that essential tools shouldn't add more
 requirements on the installed tools. Is it not the case?

 - WBR, Alexey Proskuryakov


 06.05.2010, в 21:30, Eric Seidel написал(а):

  WebKitTools/Scripts/webkitpy python requires 2.5+.
 
  We'd like to be able to use python 2.5 on the Tiger build bot (for
  websocket tests among other things).
 
  Would someone be able to install a newer Tiger on that machine?
 
  Here is python 2.6.5 for the mac:
 
 http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
 
  Thanks!
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[David Levin]

On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov a...@webkit.org wrote:


 I thought the agreement was that essential tools shouldn't add more
 requirements on the installed tools. Is it not the case?


fwiw, that wasn't how I understood this thread:
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html

Note I expressed that opinion early in the thread here:
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10300.html
But the discussion went on from there and seem to indicate
that python 2.5 would be fine.

dave


 - WBR, Alexey Proskuryakov


 06.05.2010, в 21:30, Eric Seidel написал(а):

  WebKitTools/Scripts/webkitpy python requires 2.5+.
 
  We'd like to be able to use python 2.5 on the Tiger build bot (for
  websocket tests among other things).
 
  Would someone be able to install a newer Tiger on that machine?
 
  Here is python 2.6.5 for the mac:
 
 http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
 
  Thanks!
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Eric Seidel]

WebKit's gold-standard development system appears to be Leopard.  (I
would guess Snow Leopard, except the SL bots only finally turned green
about two weeks ago.)  Leopard's python is 2.5.1.

I agree that we should target making development as simple as possible
for the common/standard system.  I think WebKit does an excellent job
of this, although we could always do better.

However, for sub-standard systems (like Windows) we require a few
additional install steps (http://webkit.org/building/tools.html).
(Window's cygwin python is 2.5.5.)

1.  I think Python 2.3 is an example of a sub-standard system.

2.  Additionally, Tiger seems mostly ignored by WebKit (note examples
like https://bugs.webkit.org/show_bug.cgi?id=38743).  No one develops
on Tiger to my knowledge (note mjs last night in #webkit noting how he
had no access to a Tiger machine, I certainly don't have access to
one).

I'm happy to add a brief note to the tools.html page noting that
python 2.5 is required and linking to a page.

Our scripts already print:
webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
support your current Python version (2.4.6).  The minimum supported
version is 2.5.

I'm happy to augment that warning to provide a download URL.

In short, I don't think Tiger (which appears legacy and
maintenance-mode only at this point) should hold hostage our script
development on all platforms.  We should simply update the bot and be
done with things. :)

-eric


On Fri, May 7, 2010 at 11:29 AM, David Levin le...@chromium.org wrote:


 On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov a...@webkit.org wrote:

 I thought the agreement was that essential tools shouldn't add more
 requirements on the installed tools. Is it not the case?

 fwiw, that wasn't how I understood this
 thread: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html
 Note I expressed that opinion early in the thread
 here: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10300.html
 But the discussion went on from there and seem to indicate
 that python 2.5 would be fine.
 dave

 - WBR, Alexey Proskuryakov


 06.05.2010, в 21:30, Eric Seidel написал(а):

  WebKitTools/Scripts/webkitpy python requires 2.5+.
 
  We'd like to be able to use python 2.5 on the Tiger build bot (for
  websocket tests among other things).
 
  Would someone be able to install a newer Tiger on that machine?
 
  Here is python 2.6.5 for the mac:
 
  http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
 
  Thanks!
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Python on the Tiger build bot

[Alexey Proskuryakov]

I thought the agreement was that essential tools shouldn't add more 
requirements on the installed tools. Is it not the case?

- WBR, Alexey Proskuryakov


06.05.2010, в 21:30, Eric Seidel написал(а):

 WebKitTools/Scripts/webkitpy python requires 2.5+.
 
 We'd like to be able to use python 2.5 on the Tiger build bot (for
 websocket tests among other things).
 
 Would someone be able to install a newer Tiger on that machine?
 
 Here is python 2.6.5 for the mac:
 http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg
 
 Thanks!
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Chris Jerdonek]

On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote:
 That reminds me, we should turn off the 80-column limit on bugs.webkit.org -
 there's no need for it to hard-wrap your text.

Great, I was wondering about that.  I filed a report for that here:

https://bugs.webkit.org/show_bug.cgi?id=37792

Thanks,
--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Chris Jerdonek]

I wanted to add a couple comments and a question to this discussion.

On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote:

 I haven't contributed to WebKit's Python code yet, but I will say that I
 agree with Eric's sentiments here. 80-column limit is archaic and pointless.
 No one is developing WebKit on a vt220.

Note that there are contexts where the limit does come into play that the
user might not have as much control over, for example pasting into the body
of an e-mail or into the comment box in bugs.webkit.org.

Take a look at these two comments for example (which, incidentally, are
about crash logs rather than code):

https://bugs.webkit.org/show_bug.cgi?id=23558#c4
https://bugs.webkit.org/show_bug.cgi?id=36707#c1

So non-Python developers know, one argument for treating Python differently
(aside from PEP8) is that the language supports a syntax for continuing
lines to the next line that other languages don't (implied line continuation).

Finally, just to clarify, which parts of PEP8 are we discussing ignoring?
PEP8 has more specific guidelines for docstrings and how they should be
formatted.  For instance, it also contains this guideline in addition to
the blanket 79-character limit:  For flowing long blocks of text (docstrings
or comments), limiting the length to 72 characters is recommended.

--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Maciej Stachowiak]

On Apr 18, 2010, at 12:33 PM, Chris Jerdonek wrote:


I wanted to add a couple comments and a question to this discussion.

On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com  
wrote:


I haven't contributed to WebKit's Python code yet, but I will say  
that I
agree with Eric's sentiments here. 80-column limit is archaic and  
pointless.

No one is developing WebKit on a vt220.


Note that there are contexts where the limit does come into play  
that the
user might not have as much control over, for example pasting into  
the body

of an e-mail or into the comment box in bugs.webkit.org.


That reminds me, we should turn off the 80-column limit on bugs.webkit.org 
 - there's no need for it to hard-wrap your text. That being said,  
we've lived for years with the fact that C++ code may get wrapped  
badly in these contexts and it hasn't really been an issue.




Take a look at these two comments for example (which, incidentally,  
are

about crash logs rather than code):

https://bugs.webkit.org/show_bug.cgi?id=23558#c4
https://bugs.webkit.org/show_bug.cgi?id=36707#c1

So non-Python developers know, one argument for treating Python  
differently
(aside from PEP8) is that the language supports a syntax for  
continuing
lines to the next line that other languages don't (implied line  
continuation).


Finally, just to clarify, which parts of PEP8 are we discussing  
ignoring?
PEP8 has more specific guidelines for docstrings and how they should  
be
formatted.  For instance, it also contains this guideline in  
addition to
the blanket 79-character limit:  For flowing long blocks of text  
(docstrings

or comments), limiting the length to 72 characters is recommended.


I'm happy to let the people who hack on Python most decide whether a  
column limit is appropriate and if so which ones.


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Eric Seidel]

bike-shedding

I think 80 columns is a waste of time and hurts readability.

Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.

The optparse code which was recently re-wrapped is one example of 80c
fail.  Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.

That said.  I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping.  If the
consensus is 80c, I'll learn to deal. :)

The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).

I've chosen A. in the past.  Mostly to match my own personal bias I'm sure.

-eric

/bike-shedding

On Wed, Apr 14, 2010 at 5:02 PM, Dirk Pranke dpra...@chromium.org wrote:
 Hi all,

 As I'm sure the discussions in the webkit meeting over the past two
 days made clear, it looks like most of our non-C++ code is getting
 written in Python. Back in January, Adam Barth posted this thread [1]
 where I thought it was agreed we would attempt to follow PEP 8 ([2] -
 the standard Python style guide) faithfully.

 The one (somewhat) controversial aspect of that style guide is that it
 requires a 79-column wide line length.

 More recently, as part of implementing a style checker for Python code
 [3], some have advocated that we should not follow that particular
 restriction, because (a) the WebKit C++ style guide does not follow
 that restriction, and (b) there is a reasonable amount of Python code
 that does not follow the rule today and would have to be brought into
 compliance. In particular, it was asked that we disable the long-line
 check until at least the existing code was brought into compliance.

 As far as (b) goes, there are currently (as of r57510) 1533 long lines
 out of the 35,616 lines found under WebKitTools/Scripts/webkitpy,
 occurring in 120 out 193 .py files. Most of the files that have any
 long lines have less than five [4].

 As far as disabling the check goes, I rather firmly believe that if we
 wish to follow an ~80 column line-length limitation, the check needs
 to be on by default, or else those who aren't used to this convention
 will not follow it and the problem will get worse, not better (as
 evidenced by [5]).

 So, do we want to follow an 80-column limit for Python code, or not,
 and if we do, should we enforce the rule by default or not?

 If the concern is the existing code base I also (reluctantly)
 volunteer to fix the long lines, if that influences the decisions.
 Although I personally believe that code that is less than 80 columns
 wide is easier to read and easier to maintain for a variety of
 reasons, I mostly volunteer to do this because it's just not many
 lines of code and I believe that having style guidelines that aren't
 followed are a Very Bad Thing and hence the fact that we have existing
 violations is a bad reason in this case to argue for not following the
 rule.

 Note that I do not particularly wish to argue the merits of this
 particular style choice, just make (and document) a decision. It's a
 religious position and the interweb is littered with existing
 arguments pro and con that we would likely just rehash here. I raise
 the issue at all only because I had thought that we made a decision
 and then it was changed in relative obscurity in a bug, rather than
 after being discussed here, whch struck me as not the right way to do
 this sort of thing.

 -- Dirk

 [1] https://lists.webkit.org/pipermail/webkit-dev/2010-January/011423.html
 [2] http://www.python.org/dev/peps/pep-0008/
 [3] https://bugs.webkit.org/show_bug.cgi?id=33639
 [4] Stats:
 % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
 \*.py | wc -l  # 193 .py files
 % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
 \*.py | xargs wc -l  # 35,316 lines of code
 % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
 \*.py | xargs awk '{ if (length($0)  79) printf(%s:%d %s\n,
 FILENAME, FNR, $0);}' # all of the long lines
 % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
 \*.py | xargs awk '{ if (length($0)  79) printf(%s\n, FILENAME);}'
 | sort | uniq -c | wc -l # 120 files w/ long lines
 % find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
 \*.py | xargs awk '{ if (length($0)  79) printf(%s\n, FILENAME);}'
 | sort | uniq -c # distribution by file
 [5] https://bugs.webkit.org/show_bug.cgi?id=37586
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Maciej Stachowiak]

On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:


bike-shedding

I think 80 columns is a waste of time and hurts readability.

Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.

The optparse code which was recently re-wrapped is one example of 80c
fail.  Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.

That said.  I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping.  If the
consensus is 80c, I'll learn to deal. :)

The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).

I've chosen A. in the past.  Mostly to match my own personal bias  
I'm sure.


I haven't contributed to WebKit's Python code yet, but I will say that  
I agree with Eric's sentiments here. 80-column limit is archaic and  
pointless. No one is developing WebKit on a vt220.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[David Levin]

(I have contributed but not often.) I also agree with  80 columns hurts
readability.

It doesn't take much looking to show a
lothttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L135of
lineshttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L259
thathttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L305
demonstratehttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L326
thishttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/rebaseline_chromium_webkit_tests.py#L449.
However, I understand the desire to just take PEP8 whole. Once you decide to
throw away one item, why not argue about any other (I tend to think 80
columns is the only thing that should be thrown out.)

Sincerely,
dc86ed7c29395f2b0863967f5350dfca4151be9d

On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:

  bike-shedding

 I think 80 columns is a waste of time and hurts readability.

 Instead of being smart about when we wrap code, 80 adheres to a
 blanket rule, discourages long variable/function names, and needlessly
 expands code vertically ignoring modern wider-than-long monitors.

 The optparse code which was recently re-wrapped is one example of 80c
 fail.  Impossible to tell in the wrapped version which arguments are
 actually being listed (first argument to the function) because your
 eye can't parse the start of each line.

 That said.  I'd rather have you and Adam and Chris all working on the
 Python than have folks lose interest due to code wrapping.  If the
 consensus is 80c, I'll learn to deal. :)

 The choice is either:
 A. no wrapping rule to match the rest of WebKit
 B. 80c to match the official PEP8 spec (and Google code).

 I've chosen A. in the past.  Mostly to match my own personal bias I'm
 sure.


 I haven't contributed to WebKit's Python code yet, but I will say that I
 agree with Eric's sentiments here. 80-column limit is archaic and pointless.
 No one is developing WebKit on a vt220.

 Regards,
 Maciej


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Dirk Pranke]

I think having longer lines of code hurts readability. There is lots
of typographic evidence
to back this up ( e.g.
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/.
Of
course, the typographic commentary applies to text rather than code,
and most text isn't indented,
but I still think it's right). Even where the monitors are wider than
they are tall argument goes, I
prefer to use that space for multiple columns of text, because even if
you do allow 80 char lines,
most lines are shorter and hence you have a lot of wasted space.

Granted, it is a combination of factors. I come from a C-based lineage
of 2-space indentation,
short variable names, and 8-character function names. Those all
combine to make an 80-
character line length workable. People who come from a 4-space (or
greater) indentation,
and the long variable-names style of Java or C++-with-templates will
tend to see things
differently.

-- Dirk

On Fri, Apr 16, 2010 at 3:09 PM, David Levin le...@chromium.org wrote:
 (I have contributed but not often.) I also agree with  80 columns hurts
 readability.
 It doesn't take much looking to show a lot of lines that demonstrate this.
 However, I understand the desire to just take PEP8 whole. Once you decide to
 throw away one item, why not argue about any other (I tend to think 80
 columns is the only thing that should be thrown out.)
 Sincerely,
 dc86ed7c29395f2b0863967f5350dfca4151be9d
 On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote:

 On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:

 bike-shedding

 I think 80 columns is a waste of time and hurts readability.

 Instead of being smart about when we wrap code, 80 adheres to a
 blanket rule, discourages long variable/function names, and needlessly
 expands code vertically ignoring modern wider-than-long monitors.

 The optparse code which was recently re-wrapped is one example of 80c
 fail.  Impossible to tell in the wrapped version which arguments are
 actually being listed (first argument to the function) because your
 eye can't parse the start of each line.

 That said.  I'd rather have you and Adam and Chris all working on the
 Python than have folks lose interest due to code wrapping.  If the
 consensus is 80c, I'll learn to deal. :)

 The choice is either:
 A. no wrapping rule to match the rest of WebKit
 B. 80c to match the official PEP8 spec (and Google code).

 I've chosen A. in the past.  Mostly to match my own personal bias I'm
 sure.

 I haven't contributed to WebKit's Python code yet, but I will say that I
 agree with Eric's sentiments here. 80-column limit is archaic and pointless.
 No one is developing WebKit on a vt220.

 Regards,
 Maciej

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev