Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

[Georg Brandl]

Am 19.07.2010 04:28, schrieb Eli Bendersky:
> On Mon, Jul 19, 2010 at 05:57, Eli Bendersky  > wrote:
> 
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo  > wrote:
> 
> > The "--help" option appears as a hyperlink leading to
> > http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help,
> which is
> > hardly relevant or useful. [...]
> >
> > -h/:option:`--help`
> >print a short usage message and exit
> 
> I think this is a doc bug in Doc/documenting/markup.rst
> :cmdoption: and :option: are not clearly distinguished; the latter
> creates references to using/cmdline, the former is what you’re looking
> for for documenting trace.py.
> 
> 
> How would you guys recommend to proceed from here?
> 
> The simplest approach for me is just use :cmdoption: instead of :option: 
> in
> my work on trace.py . However, a few more things can be done if this is
> indeed "official policy":
> 
> 1. Fix other modules that use :option: to use :cmdoption: instead (timeit,
> unittest and others)
> 2. Fix Doc/documenting/markup.rst to clarify which option kind goes where
> 
> If these steps get approved I'll be happy to create an issue and submit
> patches to the relevant files.
> 
> Eli
> 
> 
> More input on this issue:
> 
> 'cmdoption' is a directive, while 'option' is inline markup. Therefore I
> wouldn't say they're completely similar, just meant for different purposes. 
> Both
> a directive and inline markup is useful for describing "official python
> executable options/flags". Regarding per-module options, I'm not sure special
> markup is needed at all. So a policy has to be define regarding the correct
> usage of these directives/markups, and probably documented in
> Doc/documenting/markup.rst

I've done that now in r82961.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] tracker contribution

[Nick Coghlan]

On Mon, Jul 19, 2010 at 9:06 AM, Mark Lawrence  wrote:
> Hell, I just wish I was fully healthy and had my MBCS/CEng status back, then
> I'd really feel capable of letting fly.  Having worked on massive UK MOD
> projects (can't say much, Official Secrets Acts and all that stuff) and
> knowing a hell of a lot about change control, configuration management, call
> it what you like, quite frankly Python is years behind.  But there I go
> again, can't rock the boat because someone might get upset, to hell with the
> poor sods putting in their patches years ago and being completely ignored.

I have worked (and do work) on similar projects and in many ways
Python is well ahead of what some large corporations do. In terms of
test automation, baseline control, public auditing of the source
repository, public communications, the very nature of open source
development avoids a lot of the pitfalls private enterprise can fall
into. We *have* to document and automate stuff, because you can't just
yell over at Bob in the next cubicle to ask "hey, what do I need to
install to get [fnord] to build?". We *know* that everything we commit
is going to land in the email inbox of a large number of people, so we
better give it a reasonable checkin message and include a meaningful
comment explaining any apparently-stupid-but-actually-correct code.

The fundamental constraint, though, is that the core developers aren't
paid specifically to hack on Python. We may use it in our day jobs,
and I think some of the folks may get a bit of time to spend on it
during their work week, but making the new versions better isn't the
primary task for any of us. Large corporations, on the other hand,
have a lot more money to throw at things and can pay people to work on
the boring stuff rather than relying purely on volunteers.

If you get to a feature request, find that it doesn't apply cleanly
anymore (or even come close), post a comment to say that. If nobody
steps up to modernise the patch, but it isn't a fundamentally bad
idea, then it's OK for the tracker issue to remain open indefinitely
(e.g. one of mine you commented on recently I had deliberately left
open for a long time because I hadn't made up my mind whether I agreed
with it or not. There were some comments from earlier this year that I
missed at the time, but reading them all now means that I'm inclined
to accept the change for 3.2).

For bug reports, the basic thing is to see if the issue can be
reproduced on currently maintained versions. If it can, update the
version applicability accordingly, if it can't, suggest closure as out
of date.

This isn't a company where the metrics mavens will see a growing count
of low priority feature requests and issue reports and demand that
they either be accepted or rejected and people will be taken from
other tasks and given the responsibility to work through the list. Is
it *good* that things are this way? No, not at all. But it isn't
likely to change anytime soon, either.

Cheers,
Nick.

P.S. Regarding the version bumps with no other comment: I believe
there are some scripts kicking around to bump feature requests up to
the new development version after a new release goes into
maintenance-only mode. It may be good if any such scripts are updated
to also add a comment to that effect, but I don't believe those
scripts are centrally controlled anywhere.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Does trace modules have a unit test?

[Nick Coghlan]

On Mon, Jul 19, 2010 at 2:23 PM, Alexander Belopolsky
 wrote:
> On Mon, Jul 19, 2010 at 12:21 AM, Alexander Belopolsky
>  wrote:
>> On Mon, Jul 19, 2010 at 12:12 AM, Eli Bendersky  wrote:
>> ..
>>> stdout output can be captured, but what about the .cover files? Can a Python
>>> unit test create temporary files in tmp/ (or somewhere else) as part of its
>>> testing, or is this forbidden?
>>>
>>
>> That's perfectly fine.  Grep in the Lib/test directory for
>> 'tempfile.mkdtemp()' to see examples.
>>
>
> Actually the first hit is Lib/test/script_helper.py which contains
> several utilities that you may find useful.

Yeah, the script_helper.temp_dir CM is especially handy for mucking
about on the filesystem.

test_cmd_line_script.py and test_runpy.py are other places to look for
inspiration on ways to make heavy use of the filesystem for testing
without leaving junk behind when the test is over (script_helper was
actually born by refactoring the helpers from those two test suites
out to a common module).

I really should get back to the issue about a temp_dir equivalent
worthy of inclusion in the tempfile module at some point, though
(there's an unfortunate corner case relating to interpreter shutdown
and generators or explicit invocation of __enter__ that causes
problems for the script_helper.temp_dir incarnation. The test suite
avoids that corner case naturally, but a tempfile.tempdir CM needs to
cope with it)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

[Éric Araujo]

Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo  wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the former is what you’re looking
>> for for documenting trace.py.

I had actually misunderstood the documentation here. Georg corrected me
in http://bugs.python.org/issue9288 and made the right fix (thanks!)

Kind regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

[Éric Araujo]

Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo  wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the former is what you’re looking
>> for for documenting trace.py.

I had actually misunderstood the documentation here. Georg corrected me
in http://bugs.python.org/issue9288 and made the right fix (thanks!)

Kind regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ray Allen]

Agree. Through searching for existing issues, I found there isn't any such
request. And I will submit one.

The '-p' option of shell's mkdir has tow functions:
1, create parents directories if not exists,
2, suppress "File exists" error if the target has already exists.
What we need is the second function. So I think both os.mkdir() and
os.makedirs() should add a keyword argument to suppress the "OSError: [Errno
17] File exists". So we can remove many "try...except..." codes surround
os.mkdir() and os.makedirs() as Greg said, "The operation of 'make sure this
directory and all its parents exist' is very commonly required"

-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ray Allen]

See http://bugs.python.org/issue9299

On Mon, Jul 19, 2010 at 1:16 PM, Ray Allen  wrote:

>
> Agree. Through searching for existing issues, I found there isn't any such
> request. And I will submit one.
>
> The '-p' option of shell's mkdir has tow functions:
> 1, create parents directories if not exists,
> 2, suppress "File exists" error if the target has already exists.
> What we need is the second function. So I think both os.mkdir() and
> os.makedirs() should add a keyword argument to suppress the "OSError: [Errno
> 17] File exists". So we can remove many "try...except..." codes surround
> os.mkdir() and os.makedirs() as Greg said, "The operation of 'make sure
> this directory and all its parents exist' is very commonly required"
>
> --
> Ray Allen
> Best wishes!
>



-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python signal processing question

[Scott McCarty]

All, I have searched everywhere (mostly the code and a little google) and I
cannot understand where the SIGKILL signal gets checked when it is set as a
handler. I have scoured the Modules/signalmodule.c only to find two
instances of the RuntimeError exception, but I cannot understand how python
knows when a handler is set for SIGKILL. I understand that this changed in
2.4 and I am not trying to change it, I just really want to understand where
this happens. I used grep to find SIGKILL and SIGTERM to see if I could
determine where the critical difference is, but I cannot figure it out.

I have about 2 hours of searching around and I can't figure it out, I assume
it has to rely on some default behaviour in Unix, but I have no idea. I
don't see a difference between SIGKILL and SIGTERM in the python code, but
obviously there is some difference. I understand what the difference is in
Unix/Linux, I just want to see it in the python code. Since python is
checking at run time to see what signals handlers are added, I know there
must be a difference.

Please  can someone just point me in the right direction.

Thank You
Scott M
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Oleg Broytman]

Hello.

   We'are sorry but we cannot help you. This mailing list is to work on
developing Python (fixing bugs and adding new features to Python itself); if
you're having problems using Python, please find another forum. Probably
python-list (comp.lang.python) news group/mailing list is the best place.
See http://www.python.org/community/ for other lists/news groups/fora.
Thank you for understanding.

   Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix
programmer guide.

On Mon, Jul 19, 2010 at 12:11:10PM -0400, Scott McCarty wrote:
> All, I have searched everywhere (mostly the code and a little google) and I
> cannot understand where the SIGKILL signal gets checked when it is set as a
> handler. I have scoured the Modules/signalmodule.c only to find two
> instances of the RuntimeError exception, but I cannot understand how python
> knows when a handler is set for SIGKILL. I understand that this changed in
> 2.4 and I am not trying to change it, I just really want to understand where
> this happens. I used grep to find SIGKILL and SIGTERM to see if I could
> determine where the critical difference is, but I cannot figure it out.
> 
> I have about 2 hours of searching around and I can't figure it out, I assume
> it has to rely on some default behaviour in Unix, but I have no idea. I
> don't see a difference between SIGKILL and SIGTERM in the python code, but
> obviously there is some difference. I understand what the difference is in
> Unix/Linux, I just want to see it in the python code. Since python is
> checking at run time to see what signals handlers are added, I know there
> must be a difference.
> 
> Please  can someone just point me in the right direction.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Scott McCarty]

I apologize if this is the wrong place to ask questions about Python C code,
but I didn't know where else to turn. I don't think the regular user group
will be technical enough to find this, am I wrong?

There is no forum for something this in depth. This is not a usage problem,
I want to know where in the code this is happening, I understand how to use
these signals perfectly and why they are different. Clearly SIGKILL cannot
be caught and would never get used even if you did register that handler in
Python, while SIGTERM is able to be caught, this is standard Unix signals.
The part I am asking about is how python checks ahead of time. If it didn't
check (case before python 2.4), then it would get silently ignored because
the OS would kill the process without ever letting python even try and
handle that signal.

 I just want to understand the C/Python piece better because I am writing a
tutorial on signals and I am using python to demonstrate. I thought it would
be fun to show that the SIGKILL is never processed, but instead python
errors out. There is something in Python checking the SIGKILL signal
handler, while not checking SIGTERM and I can't find the Python C code that
handles it. When I am writing something like this, I like to point out the C
code, not just cite the documentation (I did find this change in behaviour
noted in the Python change log).

I will try and find a different list
Scott M

On Mon, Jul 19, 2010 at 12:27 PM, Oleg Broytman  wrote:

> Hello.
>
>   We'are sorry but we cannot help you. This mailing list is to work on
> developing Python (fixing bugs and adding new features to Python itself);
> if
> you're having problems using Python, please find another forum. Probably
> python-list (comp.lang.python) news group/mailing list is the best place.
> See http://www.python.org/community/ for other lists/news groups/fora.
> Thank you for understanding.
>
>   Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix
> programmer guide.
>
> On Mon, Jul 19, 2010 at 12:11:10PM -0400, Scott McCarty wrote:
> > All, I have searched everywhere (mostly the code and a little google) and
> I
> > cannot understand where the SIGKILL signal gets checked when it is set as
> a
> > handler. I have scoured the Modules/signalmodule.c only to find two
> > instances of the RuntimeError exception, but I cannot understand how
> python
> > knows when a handler is set for SIGKILL. I understand that this changed
> in
> > 2.4 and I am not trying to change it, I just really want to understand
> where
> > this happens. I used grep to find SIGKILL and SIGTERM to see if I could
> > determine where the critical difference is, but I cannot figure it out.
> >
> > I have about 2 hours of searching around and I can't figure it out, I
> assume
> > it has to rely on some default behaviour in Unix, but I have no idea. I
> > don't see a difference between SIGKILL and SIGTERM in the python code,
> but
> > obviously there is some difference. I understand what the difference is
> in
> > Unix/Linux, I just want to see it in the python code. Since python is
> > checking at run time to see what signals handlers are added, I know there
> > must be a difference.
> >
> > Please  can someone just point me in the right direction.
>
> Oleg.
> --
> Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
>   Programmers don't die, they just GOSUB without RETURN.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Oleg Broytman]

On Mon, Jul 19, 2010 at 01:09:36PM -0400, Scott McCarty wrote:
> I apologize if this is the wrong place to ask questions about Python C code,
> but I didn't know where else to turn. I don't think the regular user group
> will be technical enough to find this, am I wrong?

   I am sure there are quite a lot of skilled professionals in the
python-list (comp.lang.python).

> On Mon, Jul 19, 2010 at 12:27 PM, Oleg Broytman  wrote:
> > python-list (comp.lang.python) news group/mailing list is the best place.
> > See http://www.python.org/community/ for other lists/news groups/fora.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Use of coding cookie in 3.x stdlib

[Alexander Belopolsky]

On Mon, Jul 19, 2010 at 2:45 AM, Guido van Rossum  wrote:
> Sounds like a good idea to try to remove redundant cookies *and* to
> remove most occasional use of non-ASCII characters outside comments. ...

Please see http://bugs.python.org/issue9308 .

I am going to post a patch shortly.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[average]

>   We'are sorry but we cannot help you. This mailing list is to work on
> developing Python (fixing bugs and adding new features to Python itself); if
> you're having problems using Python, please find another forum. Probably
> python-list (comp.lang.python) news group/mailing list is the best place.
> See http://www.python.org/community/ for other lists/news groups/fora.
> Thank you for understanding.
>
>   Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix
> programmer guide.

Wha?  How could this not be the right place?  He's not asking about
USING python, but asking: WHERE in the PYTHON CODE BASE does the
signal get checked?

A-bit-miffed-at-the-cold-shoulderly yours,

Marcos  (wink wink)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Steve Holden]

On 7/19/2010 11:08 PM, average wrote:
>>   We'are sorry but we cannot help you. This mailing list is to work on
>> developing Python (fixing bugs and adding new features to Python itself); if
>> you're having problems using Python, please find another forum. Probably
>> python-list (comp.lang.python) news group/mailing list is the best place.
>> See http://www.python.org/community/ for other lists/news groups/fora.
>> Thank you for understanding.
>>
>>   Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix
>> programmer guide.
> 
> Wha?  How could this not be the right place?  He's not asking about
> USING python, but asking: WHERE in the PYTHON CODE BASE does the
> signal get checked?
> 
> A-bit-miffed-at-the-cold-shoulderly yours,
> 
> Marcos  (wink wink)

+1

Another potential developer walks away feeling unwanted?

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Simon Cross]

On Tue, Jul 20, 2010 at 12:29 AM, Steve Holden  wrote:
> Another potential developer walks away feeling unwanted?

Let just kill this thread here. SIGKILL can't be caught. :)

(I had sort of assumed that Marcos was being ironic).

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Greg Ewing]

Ray Allen wrote:

I think both os.mkdir() and 
os.makedirs() should add a keyword argument to suppress the "OSError: 
[Errno 17] File exists".


This could be seen as violating the "no constant arguments"
guideline. Maybe separate function would be better?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Greg Ewing]

Scott McCarty wrote:
All, I have searched everywhere (mostly the code and a little google) 
and I cannot understand where the SIGKILL signal gets checked when it is 
set as a handler.


Possibly it's not being checked at all by Python, but
is being rejected by the system call. The Darwin man
page says this about signal(3) in the ERRORS section:

 [EINVAL]   An attempt is made to ignore or supply a handler for
SIGKILL or SIGSTOP.

Not sure why it gets reported as a RuntimeError rather
than an OSError, though.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Michael Crute]

On Mon, Jul 19, 2010 at 12:11 PM, Scott McCarty  wrote:
> All, I have searched everywhere (mostly the code and a little google) and I
> cannot understand where the SIGKILL signal gets checked when it is set as a
> handler. I have scoured the Modules/signalmodule.c only to find two
> instances of the RuntimeError exception, but I cannot understand how python
> knows when a handler is set for SIGKILL. I understand that this changed in
> 2.4 and I am not trying to change it, I just really want to understand where
> this happens. I used grep to find SIGKILL and SIGTERM to see if I could
> determine where the critical difference is, but I cannot figure it out.
>
> I have about 2 hours of searching around and I can't figure it out, I assume
> it has to rely on some default behaviour in Unix, but I have no idea. I
> don't see a difference between SIGKILL and SIGTERM in the python code, but
> obviously there is some difference. I understand what the difference is in
> Unix/Linux, I just want to see it in the python code. Since python is
> checking at run time to see what signals handlers are added, I know there
> must be a difference.

The signals get initialized at interpreter startup within the initsigs
function (Python/pythonrun.c). By default the interpreter ignores
SIGPIPE, SIGXFZ and SIGXFSZ. Eventually initsignal
(Modules/signalmodule.c) which will loop over an array of all handlers
and set their handlers to the default handler, ignore handler or None,
depending on the default state of the handler as reported by the OS.
After all of that python will register its own signal handler for
SIGINT which raises a KeyboardInterrupt error (you can change this).

By default on Linux SIGKILL gets a None handler since it can not be
handled or ignored (as dictated by the OS) and SIGTERM gets the
default handler which at least under Linux is to terminate the program
without doing any kind of cleanup.

It is worth noting that you can handle SIGTERM but python chooses not
to do this by default.

Doug Hellmann wrote a post about the signal module that is a good
complement to the C code for understanding how signals are handled in
python. http://www.doughellmann.com/PyMOTW/signal/

HTH.

-mike

-- 
Michael E. Crute
http://mike.crute.org

It is a mistake to think you can solve any major problem just with
potatoes. --Douglas Adams
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

[Eli Bendersky]

> >
> > More input on this issue:
> >
> > 'cmdoption' is a directive, while 'option' is inline markup. Therefore I
> > wouldn't say they're completely similar, just meant for different
> purposes. Both
> > a directive and inline markup is useful for describing "official python
> > executable options/flags". Regarding per-module options, I'm not sure
> special
> > markup is needed at all. So a policy has to be define regarding the
> correct
> > usage of these directives/markups, and probably documented in
> > Doc/documenting/markup.rst
>
> I've done that now in r82961.
>
> Georg


Georg,

Your fix indeed clarifies :option:. However, I think that cmdoption could
also be made clearer by re-iterating that it is to refer to Python's own
options only, and not to be used for command line options of modules.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Mark Lawrence]

On 18/07/2010 23:38, Alexander Belopolsky wrote:

On Sun, Jul 18, 2010 at 6:10 PM, "Martin v. Löwis"  wrote:

Maybe going off on a tangent, but I find it frustrating because you
(plural) can't find a given module on the issue tracker. Say I'm looking
for issues relating to smtplib, all I can do is look in the title of the
issue. Have I missed something, or is there a need to have subsections
so that if Lib is selected, you can then find the appropriate module?


If you think any specific feature is missing in the tracker, please post
a report to the meta-tracker.


This is an excellent point and for those who don't know what
"meta-tracker" is, see the link to "Report Tracker Problem" at the
bottom of left column on the main tracker page.  The direct link is
http://psf.upfronthosting.co.za/roundup/meta/ .  (I did not know about
the "meta-tracker" myself until a couple of months ago.)


Is this the same login as for the issue tracker or is a new one needed?

I also suspect that subsections for Extension Modules would be extremely 
useful for our C developers, thoughts anybody?


Cheers.

Mark Lawrence.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Alexander Belopolsky]

On Mon, Jul 19, 2010 at 11:55 PM, Mark Lawrence  wrote:
..
> Is this the same login as for the issue tracker or is a new one needed?
>

AFAIK, it is separate.

> I also suspect that subsections for Extension Modules would be extremely
> useful for our C developers, thoughts anybody?

Well, with the current trend of making extensions an optional fast
reimplementation of library modules, the distinction between Lib and
Extension Modules gets blurred.   For example,
http://bugs.python.org/issue1062277, "Pickle breakage with reduction
of recursive structures" is a bug that affects both python and C
implementation of pickle module.  Should this be Lib or Extension
issue or both? (The issue is actually misclassified as "Interpreter
Core".)  I think it is both.  Here is a less clear example.  Suppose
someone reports a bug is time.strptime.  The time module is a C
extension, but strptime is implemented in a "hidden" python module,
_strptime.  How would you classify this issue?  If your head does not
spin yet, consider http://bugs.python.org/issue1677872, "Efficient
reverse line iterator".  When the patch was submitted, io module was
implemented in python, but since then it was reimplemented in C.

If we allow tagging issues with the module name, I would rather not
make distinction between C and python modules.   just make it one flat
list similar to the one in maintainers.txt.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Markup of command-line options in Python's .rst documentation

[Eli Bendersky]

> > 'cmdoption' is a directive, while 'option' is inline markup. Therefore I
> > wouldn't say they're completely similar, just meant for different
> purposes. Both
> > a directive and inline markup is useful for describing "official python
> > executable options/flags". Regarding per-module options, I'm not sure
> special
> > markup is needed at all. So a policy has to be define regarding the
> correct
> > usage of these directives/markups, and probably documented in
> > Doc/documenting/markup.rst
>
> I've done that now in r82961.
>

As per your recommendation in the updated documentation guide, I have fixed
the ReST docs of stdlib modules that used :option:, to use code markup (``)
instead. I've opened issue 9312 for this and submitted a patch.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python signal processing question

[Terry Reedy]

On 7/19/2010 6:08 PM, average wrote:

   We'are sorry but we cannot help you. This mailing list is to work on
developing Python (fixing bugs and adding new features to Python itself); if
you're having problems using Python, please find another forum. Probably
python-list (comp.lang.python) news group/mailing list is the best place.
See http://www.python.org/community/ for other lists/news groups/fora.
Thank you for understanding.


This is a polite boilerplate response for off-topic posts. I suppose 
'using' should be expanded to 'using or understanding'.



   Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix
programmer guide.


Wha?  How could this not be the right place?  He's not asking about
USING python, but asking: WHERE in the PYTHON CODE BASE does the
signal get checked?


Right, he asked about how Python operates, which is a constant type of 
question on python-list and which has nothing to do with developing the 
next version(s) of Python.



A-bit-miffed-at-the-cold-shoulderly yours,


Py-dev was started when python-list because unusable for development. If 
this list were to become, in turn, overwhelmed with general questions, 
as it would be it non-development questions were not directed elsewhere, 
then the devs would have to start a new python-really-development-only 
list, and perhaps not make it so public.


If someone tries an advanced question on python-list first and gets no 
answer, then there might be an excuse to turn to py-dev to grab the 
attention of those developers who do not ever read python-list. But in 
this case, the question was readily answered there, in part by devs who 
do frequent both. The OP acknowledged there that he acted on prejudice 
and should have posted there in the first place.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Maciej Fijalkowski]

On Sun, Jul 18, 2010 at 10:32 PM, Paul Moore  wrote:
> On 18 July 2010 20:57, Glyph Lefkowitz  wrote:
>>
>> On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote:
>>
>> We already have "posponed" and "remind" resolutions, but these are
>> exclusive of "accepted".   I think there should be a clear way to mark
>> the issue "accepted and would be applied if X.Y was out already."
>> Chances are one of the resolution labels already has such meaning, but
>> in this case it should be more prominently documented as such.
>>
>> This is what branches are for.
>> When the X.Y release cycle starts, there should be a branch for X.Y.  Any
>> "would be applied" patches can simply be applied to trunk without
>> interrupting anything; the X.Y release branch can be merged back into trunk
>> as necessary.
>
> Agreed. If that isn't already the recommended workflow under
> Mercurial, I'd suggest making it so. (I can imagine that under
> Subversion, where branching and merging is more awkward, it might have
> been deemed not worth doing).
>
> Paul.

Contrary to a widespread popular belief subversion supports branching
and I don't think anyone suggested merging release branches back (even
though you can do it in subversion as well).

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Stephen J. Turnbull]

Mark Lawrence writes:

 > Is this the same login as for the issue tracker or is a new one needed?

It's different.  Both trackers are supposed to support OpenID logins,
I believe.  (However, there are somewhat frequent reports of
difficulties with it; I don't know if the system is fully debugged.  I
think most people are OK, but making a new login is the sure path.)

 > I also suspect that subsections for Extension Modules would be extremely 
 > useful for our C developers, thoughts anybody?

Do you mean an entry per module?

The XEmacs Tracker (http://tracker.xemacs.org/), which also is based
on Roundup, has an extensive list of add-on packages (somewhat like
the stdlib).  We're currently stuck in the doldrums, and it is sadly
mostly unused, so I can't really comment on the utility.

I find that there are some UI issues with such long lists in Roundup.
I don't want to discourage adding such information to the tracker; I
think it's a good idea.  But it will need attention to UI to be most
useful.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com