Re: [Python-Dev] [Python-checkins] cpython (3.3): Add -b and -X options to python man page.

2013-06-25 Thread Maciej Fijalkowski 
On Mon, Jun 24, 2013 at 10:56 PM, Antoine Pitrou  wrote:
> On Mon, 24 Jun 2013 16:43:15 -0400
> "R. David Murray"  wrote:
>> On Mon, 24 Jun 2013 22:14:46 +0200, Maciej Fijalkowski  
>> wrote:
>> > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray  
>> > wrote:
>> > > On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski 
>> > >  wrote:
>> > >> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon  wrote:
>> > >> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran
>> > >> >  wrote:
>> > >> >>  .TP
>> > >> >> +.BI "\-X " option
>> > >> >> +Set implementation specific option.
>> > >> >
>> > >> >
>> > >> > Should probably be "Set the implementation-specific option."
>> > >>
>> > >> Is there anyone respecting this notation? (I know pypy does not, it
>> > >> uses --jit and stuff)
>> > >
>> > > CPython does.  We introduced it for ourselves, it is up to other
>> > > implementations whether or not to use it, or use something else.
>> > >
>> > > --David
>> >
>> > you mean "CPython does not have any implementation-specific options"?
>> > I would claim -O behavior should be implementation-specific since it's
>> > nonsense in the optimizations sense, but other than that, it does not
>> > seem that there is any -X options?
>>
>> There is one.  -X faulthandler.  I'm sure others would agree about
>> -O, but that long predates -X.
>>
>> So, the idea is that -X *can* be used by other implementations for their
>> own purposes, but there is certainly no requirement that they do so.
>> Our promise is that anything CPython uses it for is something we don't
>> expect other implementations to support.
>
> Yes, basically -X is a private namespace for every implementation to
> use as it sees fit without fearing of conflicting with a future
> cross-implementation option.
>
> Regards
>
> Antoine.

I'm for one looking forward to the day where cpython conflicts on --jit ;-)
___
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-checkins] cpython: Issue #18081: Workaround "./python -m test_idle test_logging" failure

2013-06-25 Thread Brett Cannon 
This fix is still not correct as warnings.formatwarning should not be
overridden, only showwarning can be.
On Jun 24, 2013 6:18 PM, "victor.stinner" 
wrote:

> http://hg.python.org/cpython/rev/2a9e1eb3719c
> changeset:   84330:2a9e1eb3719c
> user:Victor Stinner 
> date:Tue Jun 25 00:17:37 2013 +0200
> summary:
>   Issue #18081: Workaround "./python -m test_idle test_logging" failure
>
> "import idlelib" should not install hooks on the warning modules, hooks
> should
> only be installed when IDLE is started.
>
> files:
>   Lib/idlelib/PyShell.py |  5 +++--
>   Lib/idlelib/run.py |  4 +++-
>   2 files changed, 6 insertions(+), 3 deletions(-)
>
>
> diff --git a/Lib/idlelib/PyShell.py b/Lib/idlelib/PyShell.py
> --- a/Lib/idlelib/PyShell.py
> +++ b/Lib/idlelib/PyShell.py
> @@ -61,7 +61,6 @@
>lineno, line=line))
>  except OSError:
>  pass  ## file (probably __stderr__) is invalid, warning
> dropped.
> -warnings.showwarning = idle_showwarning
>  def idle_formatwarning(message, category, filename, lineno,
> line=None):
>  """Format warnings the IDLE way"""
>  s = "\nWarning (from warnings module):\n"
> @@ -73,7 +72,6 @@
>  s += "%s\n" % line
>  s += "%s: %s\n>>> " % (category.__name__, message)
>  return s
> -warnings.formatwarning = idle_formatwarning
>
>  def extended_linecache_checkcache(filename=None,
>orig_checkcache=linecache.checkcache):
> @@ -1425,6 +1423,9 @@
>  def main():
>  global flist, root, use_subprocess
>
> +warnings.showwarning = idle_showwarning
> +warnings.formatwarning = idle_formatwarning
> +
>  use_subprocess = True
>  enable_shell = False
>  enable_edit = False
> diff --git a/Lib/idlelib/run.py b/Lib/idlelib/run.py
> --- a/Lib/idlelib/run.py
> +++ b/Lib/idlelib/run.py
> @@ -40,7 +40,6 @@
>  s += "%s\n" % line
>  s += "%s: %s\n" % (category.__name__, message)
>  return s
> -warnings.formatwarning = idle_formatwarning_subproc
>
>
>  tcl = tkinter.Tcl()
> @@ -82,6 +81,9 @@
>  global exit_now
>  global quitting
>  global no_exitfunc
> +
> +warnings.formatwarning = idle_formatwarning_subproc
> +
>  no_exitfunc = del_exitfunc
>  #time.sleep(15) # test subprocess not responding
>  try:
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
___
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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

2013-06-25 Thread Raymond Hettinger 

On Jun 24, 2013, at 10:12 PM, Benjamin Peterson  wrote:

> Raymond, go ahead and reapply your change.

If you don't mind, I think you should be the one to undo your own reversions.

Thank you,


Raymond

___
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-checkins] cpython (3.3): Add -b and -X options to python man page.

2013-06-25 Thread Jeff Hardy 
On Sun, Jun 23, 2013 at 8:40 AM, Maciej Fijalkowski wrote:

> >> +.BI "\-X " option
> >> +Set implementation specific option.
> >
> >
> > Should probably be "Set the implementation-specific option."
>
> Is there anyone respecting this notation? (I know pypy does not, it
> uses --jit and stuff)
>
> IronPython does, for -X:Frames and a few others.

- Jeff
___
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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

2013-06-25 Thread Benjamin Peterson 
2013/6/25 Raymond Hettinger :
>
> On Jun 24, 2013, at 10:12 PM, Benjamin Peterson  wrote:
>
> Raymond, go ahead and reapply your change.
>
>
> If you don't mind, I think you should be the one to undo your own
> reversions.

Done.


--
Regards,
Benjamin
___
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] Relative path in co_filename for zipped modules

2013-06-25 Thread Vitaly Murashev 
Dear Python developers community,

Recently I found out that it not possible to debug python code if it
is a part of zip-module.
Python version being used is 3.3.0

Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to
start debugging and give the following warning:
---
pydev debugger: CRITICAL WARNING: This version of python seems to be
incorrectly compiled (internal generated filenames are not absolute)
pydev debugger: The debugger may still function, but it will work
slower and may miss breakpoints.
---
So I started my own investigation of this issue and results are the following.

At first I took traditional python debugger 'pdb' to analyze how it
behaves during debugging of zipped module.
'pdb' showed me some backtaces and filename part for stack entries
looks malformed.
I expected something like
'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py'
but realy it looks like 'full-path-to-current-dir/subdir/test_module.py'

Source code in pdb.py and bdb.py (which one are a part of python
stdlib) gave me the answer why it happens.

The root cause are inside Bdb.format_stack_entry() + Bdb.canonic()

Please take a look at the following line inside 'format_stack_entry' method:

filename = self.canonic(frame.f_code.co_filename)

For zipped module variable 'frame.f_code.co_filename' holds _relative_
file path started from the root of zip archive like
'subdir/test_module.py'
And as result Bdb.canonic() method gives what we have -
'full-path-to-current-dir/subdir/test_module.py'
---
So my final question.
Could anyone confirm that it is a bug in python core subsystem which
one is responsible for loading zipped modules,
or something is wrong with my zipped module ?

If it is a bug could you please submit it into official python bugtracker ?
I never did it before and afraid to do something wrong.

Thanks,
Vitaly Murashev
___
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] Relative path in co_filename for zipped modules

2013-06-25 Thread R. David Murray 
Please file this as a bug report on bugs.python.org so that it doesn't
get lost.

See also http://bugs.python.org/issue13328 (which looks like a different bug
but could also be causing you problems).

--David

On Wed, 26 Jun 2013 00:11:04 +0400, Vitaly Murashev  
wrote:
> Dear Python developers community,
> 
> Recently I found out that it not possible to debug python code if it
> is a part of zip-module.
> Python version being used is 3.3.0
> 
> Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to
> start debugging and give the following warning:
> ---
> pydev debugger: CRITICAL WARNING: This version of python seems to be
> incorrectly compiled (internal generated filenames are not absolute)
> pydev debugger: The debugger may still function, but it will work
> slower and may miss breakpoints.
> ---
> So I started my own investigation of this issue and results are the following.
> 
> At first I took traditional python debugger 'pdb' to analyze how it
> behaves during debugging of zipped module.
> 'pdb' showed me some backtaces and filename part for stack entries
> looks malformed.
> I expected something like
> 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py'
> but realy it looks like 'full-path-to-current-dir/subdir/test_module.py'
> 
> Source code in pdb.py and bdb.py (which one are a part of python
> stdlib) gave me the answer why it happens.
> 
> The root cause are inside Bdb.format_stack_entry() + Bdb.canonic()
> 
> Please take a look at the following line inside 'format_stack_entry' method:
> 
> filename = self.canonic(frame.f_code.co_filename)
> 
> For zipped module variable 'frame.f_code.co_filename' holds _relative_
> file path started from the root of zip archive like
> 'subdir/test_module.py'
> And as result Bdb.canonic() method gives what we have -
> 'full-path-to-current-dir/subdir/test_module.py'
> ---
> So my final question.
> Could anyone confirm that it is a bug in python core subsystem which
> one is responsible for loading zipped modules,
> or something is wrong with my zipped module ?
> 
> If it is a bug could you please submit it into official python bugtracker ?
> I never did it before and afraid to do something wrong.
> 
> Thanks,
> Vitaly Murashev
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Victor Stinner 
Hi,

One month ago, unit tests were added to IDLE (cool!) with a file
called @README.txt. The @ was used to see the name on top in a listing
of the directory.

Some developers began to get strange Mercurial errors like:
"abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match"
" 83941: empty or missing Lib/idlelib/idle_test/@README.txt "
etc.

Senthil reported the issue on python-committers mailing list:
http://mail.python.org/pipermail/python-committers/2013-May/002565.html

The @ character was discussed. Replacing it with "_" was proposed.
Guido asked to simply rename the name "README.txt", he wrote:

"I think we have a zen rule about this: Special cases aren't special
enough to break the rules."

Senthil was asked to upgrade its Mercurial version. Someone supposed
that it is a disk issue. Anyway, the issue disappeared with a fresh
clone.

I also had the issue on 3 different computers, and so I reported the
issue upstream:
http://bz.selenic.com/show_bug.cgi?id=3954

I discussed with a Mercurial developer, Matt, on IRC. He asked how the
server is managed, if we are using only one physical server, if
repositories are copied with rsync, etc. I was unable to answer, I
don't have access to hg.python.org server.

The issue was closed, but 20 days later (today) I reproduced the issue again.

I cloned the repository at a specific revision, tried to update to
another specific revision: no bug.

I also played with with hg bisect, because I suspected a bug in bisect: no bug.

I tried to update at each revision between 83900 and 84348 to check if
@README.txt disappears from .hg/store: still no bug.

I also ran fsck: no error (but the disk is mounted, so I don't know if
the report is reliable).

And then I ran "make distclean"...

Victor
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Benjamin Peterson 
2013/6/25 Victor Stinner :
> And then I ran "make distclean"...

You've left us hanging...


--
Regards,
Benjamin
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Senthil Kumaran 
On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson wrote:

> 2013/6/25 Victor Stinner :
> > And then I ran "make distclean"...
>
> You've left us hanging...
>
>
Yeah, the final part is here: http://bz.selenic.com/show_bug.cgi?id=3954#c4
But still I have question as why hg complained about @README in the first
place.
Also, I hope make distclean is not working "inside" .hg folder.

-- 
Senthil
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Steven D'Aprano 

On 26/06/13 08:44, Victor Stinner wrote:


And then I ran "make distclean"...



Victor, you're a cruel, cruel man. You've told us everything except the 
solution to the mystery.


--
Steven
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Mark Janssen 
> It's like this.  Whenever you use special characters in a file name,
> you're asking for trouble.  The shell and the OS have negotiate how to
> interpret it.  It bigger than git, and not a bug.

Sorry, I meant mercurial, not git.
-- 
MarkJ
Tacoma, Washington
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Mark Janssen 
> One month ago, unit tests were added to IDLE (cool!) with a file
> called @README.txt. The @ was used to see the name on top in a listing
> of the directory.

It's like this.  Whenever you use special characters in a file name,
you're asking for trouble.  The shell and the OS have negotiate how to
interpret it.  It bigger than git, and not a bug.  The issue is
between the file system, the kernel, and the shell.

> I also had the issue on 3 different computers, and so I reported the
> issue upstream:
> http://bz.selenic.com/show_bug.cgi?id=3954

Try it on different OS's on different machines (MacOS, Linux, Windows)
.  If my theory is right, it should be inconsistent across machines,
but consistent within the same machine.

-- 
MarkJ
Tacoma, Washington
___
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] End of the mystery "@README.txt Mercurial bug"

2013-06-25 Thread Eric V. Smith 
On 6/25/2013 9:33 PM, Senthil Kumaran wrote:
> 
> 
> 
> On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson  > wrote:
> 
> 2013/6/25 Victor Stinner  >:
> > And then I ran "make distclean"...
> 
> You've left us hanging...
> 
> 
> Yeah, the final part is here: http://bz.selenic.com/show_bug.cgi?id=3954#c4
> But still I have question as why hg complained about @README in the
> first place.
> Also, I hope make distclean is not working "inside" .hg folder.

I think that's exactly what's happening.

>From the bug report:

find $(srcdir) '(' -name '*.fdc' -o -name '*~' \
   -o -name '[@,#]*' -o -name '*.old' \
   -o -name '*.orig' -o -name '*.rej' \
   -o -name '*.bak' ')' \
   -exec rm -f {} ';'

Will find files beginning with '@' inside subdirectories of $(srcdir)/.hg.

Just this week I saw someone use the logical equivalent of:

find $(srcdir)/* ...

to avoid this problem. It won't expand the .hg top-level directory.

-- 
Eric.
___
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