[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...

[Cherniavsky Beni]

Changes by Cherniavsky Beni :


--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Easily detecting interactive mode is of general interest for customization.

1. What if C also set sys.flags.interactive in "python" mode,
   or exposed sys.flags.implicit_interactive (but with better name)?

2. It's more useful to have a hook called when entering interactive mode,
   rather than a flag that's set from the beginning:

   $ python -i -c 'import sys; print sys.flags.interactive'
   1
   >>> 

   For this, importing _setupinteractive is a step forward;
   calling e.g. sys.__interactivehook__ sounds even better.
   (site.py would set it by default to a function that enables
   rlcompleter, user can always override...)

BTW, drawback of doing any such setup in site.py: "python -S" would 
be unfriendly!

--

___
Python tracker 
<http://bugs.python.org/issue5845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou  wrote:

It covers the user's desire customization very well (esp. if it worked with
-i).
sys.__interactivehook__ has the benefit of being cleanly settable from
python code.
But it might well be a YAGNI idea.

$PYTHONSTARTUP doesn't work with -i
>

Perhaps it should?
I can't think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't
want with -i.
(and if there is one, one can add a test for sys.flags.interactive, or run
with env PYTHONSTARTUP='')

Point to watch out for: errors in $PYTHONSTARTUP.
One of the uses of "python -i script.py" is doing pdb.pm() on an exception
thrown by the script;
ideally a broken $PYTHONSTARTUP would not overr

"customization" than editing?
The fact that it'd be implemented in site.py?
Yes, obviously, if it's implemented in site.py, -S should disable it.  My
point was that it doesn't have to be implemented there.  You could drink the
cool aid instead :-)

--
Added file: http://bugs.python.org/file23108/unnamed

___
Python tracker 
<http://bugs.python.org/issue5845>
___On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou <mailto:rep...@bugs.python.org"; 
target="_blank">rep...@bugs.python.org> wrote:


Éric Araujo <mailto:mer...@netwok.org"; 
style="color:rgb(17, 85, 204)" target="_blank">mer...@netwok.org> added 
the comment:



> > It's more useful to have a hook called when entering 
interactive mode, rather than a flag
> > that's set from the beginning:
> We already have such a hook: $PYTHONSTARTUP
Good point!It covers the user's 
desire customization very well (esp. if it worked with 
-i).sys.__interactivehook__ has the benefit of being cleanly 
settable from python code.

But it might well be a YAGNI idea.

$PYTHONSTARTUP doesn't work with 
-i Perhaps it should?I can't 
think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't want 
with -i.(and if there is one, one can add a test 
for sys.flags.interactive, or run with env PYTHONSTARTUP='')


 Point to watch out for: errors in 
$PYTHONSTARTUP.One of the uses of "python -i script.py" is 
doing http://pdb.pm";>pdb.pm() on an exception thrown by the 
script;

ideally a broken $PYTHONSTARTUP would not overr> BTW, drawback of doing any such 
setup in site.py: "python -S" would be unfriendly!People using -S 
don’t want the customizations done in site, so I don’t think there’s a 
problem here.


python -S doesn't disable 
readline.  What makes completions more of a "customization" than 
editing?The fact that it'd be implemented in site.py?


Yes, obviously, if it's implemented in site.py, -S should disable it. 
 My point was that it doesn't have to be implemented there.  You could 
drink the cool aid instead :-)
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

[sorry, html mail was bad idea]

On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou  wrote:

Éric Araujo  added the comment:
> > It's more useful to have a hook called when entering interactive mode,
> > rather than a flag
> > that's set from the beginning:
> We already have such a hook: $PYTHONSTARTUP

Good point!
It covers the user's desire customization very well (esp. if it worked with -i).
sys.__interactivehook__ has the benefit of being cleanly settable from python 
code.
But it might well be a YAGNI idea.

> $PYTHONSTARTUP doesn't work with -i
 
Perhaps it should?
I can't think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't 
want with -i.
(and if there is one, one can add a test for sys.flags.interactive, or run with 
env PYTHONSTARTUP='')
 
Point to watch out for: errors in $PYTHONSTARTUP.
One of the uses of "python -i script.py" is doing pdb.pm() on an exception 
thrown by the script;
ideally a broken $PYTHONSTARTUP would not overr

> > BTW, drawback of doing any such setup in site.py: "python -S" 
> > would be unfriendly!
> People using -S don’t want the customizations done in site, so I 
> don’t think there’s a problem here.

python -S doesn't disable readline.  What makes completions more of a 
"customization" than editing?
The fact that it'd be implemented in site.py?
Yes, obviously, if it's implemented in site.py, -S should disable it.  My point 
was that it doesn't have to be implemented there.  You could drink the cool aid 
instead :-)

--

___
Python tracker 
<http://bugs.python.org/issue5845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6321] Reload Python modules when running programs

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

When you run a program using F5 in IDLE,
it completely restarts the underlying interpreter!
If you meant a different way of running, please elaborate.

(Exception: it uses the same interpreter if you're running "idle -n"; this 
commonly happens on Windows if you rightclick->Edit with IDLE... a .py file - 
just don't use that.)

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue6321>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7676] IDLE shell shouldn't use TABs

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

This is almost a duplicate of http://bugs.python.org/issue1196946
(though the solution there took a different direction).

--

___
Python tracker 
<http://bugs.python.org/issue7676>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9618] IDLE shell ignores all but first statement

[Cherniavsky Beni]

New submission from Cherniavsky Beni :

[Spinoff of http://bugs.python.org/issue3559]

If you manage to type several simple statements into the prompt (by 
copy-pasting them, using Ctrl+J, or creative deletion), IDLE runs the first one 
and silently ignores the rest:

>>> x = 1
x = 2
>>> x
1

Moreover, it doesn't even parse the additional lines:

>>> x = 3
$...@syntax error?!
>>> x
3

If the first statement is a compound statement, IDLE refuses with a SyntaxError 
at the begging of the second statement:


>>> def f():
return 42
f()
SyntaxError: invalid syntax


I believe in both cases the right least-surprise behavior is to run all 
statements.

If not, a clear error explaining that IDLE doesn't support multiple statements 
must be printed.  But I can't see a reason to choose this over making it Just 
Work.


[Implementation: might or might not be related to 
http://bugs.python.org/issue7741]

--
components: IDLE
messages: 114019
nosy: cben
priority: normal
severity: normal
status: open
title: IDLE shell ignores all but first statement
versions: Python 2.7, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue9618>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3559] Pasted \n not same as typed \n

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

There are 2 issues here:

(1) There should be a quick & obvious way to paste and run several statements.

(2) If a user types several statements and presses Enter, all should run.  The 
current behavior is badly broken, and pasting is just one of the ways to 
trigger this.  Splitting this into a new bug: http://bugs.python.org/issue9618

The original formulation of this bug seems to favor an xterm-like solution to 
(1): when you paste \n-terminated, run them immediately, as if each \n was an 
Enter press.

I think a more IDLEic [think "idillic" ;-)] approach to solving (1) is to solve 
(2): keep the behavior that pasting creates a multi-line block without 
executing anything, make Enter execute it all.  Benefits:

- More intuitive to users that have never pasted multiple lines into a shell 
terminal.
- More sensible: why should Pasting execute anything?!
- Allows editing any of the statements before running.
- Keeps all statements together for Alt+P recalling.

If there is agreement on this, then this issue requires no action beyond 
solving issue 9618.

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue3559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6321] Reload Python modules when running programs

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

> As it happens, I do use Windows and almost exclusively start IDLE via 
> right-clicks on .py files. I've never seen the behavior you describe 
> documented anywhere.

You're right, it wasn't.
[IDLE does show a " No Subprocess " line in the IDLE shell when you 
launch it this way.  Unfortunately, the significance of this (and of the 
absence of "== Restart ==" lines on F5) wouldn't be obvious unless you 
followed IDLE development around 2.3... :-(]

If you're using Python up to 2.6/3.0, please fall back to starting IDLE from 
the Start menu → Programs → Python X.Y → IDLE, then use File→Open to open files.

Or upgrade to Python 2.7/3.1, where right click → Edit with IDLE was fixed 
[issue5847] to open IDLE in the fully-functional mode.  Note however, that once 
you have an open IDLE, still want to use File→Open or you'll get *2* IDLEs 
running at once, each with its own shell.

In both cases you'll notice IDLE will *completely* restart the underlying 
Python each time you press F5.  This eliminates any stale-module problems, but 
kills all variables and state you had; this might require a change of habits 
but in my experience it's well worth it.

[P.S. If you absolutely must have module reloading without killing the whole 
state, and you're willing to debug occasional issues, take a look at 
http://www.cherrypy.org/attachment/wiki/AutoReload/autoreload.py
and possibly http://www.codexon.com/posts/a-better-python-reload]

--

___
Python tracker 
<http://bugs.python.org/issue6321>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9724] help('nonlocal') missing

[Cherniavsky Beni]

New submission from Cherniavsky Beni :

>>> help('nonlocal')
no Python documentation found for 'nonlocal'

As a language keyword, it clearly should have documentation.

--
assignee: d...@python
components: Documentation
messages: 115266
nosy: cben, d...@python
priority: normal
severity: normal
status: open
title: help('nonlocal') missing
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue9724>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10457] "Related help topics" shown outside pager

[Cherniavsky Beni]

New submission from Cherniavsky Beni :

help('NAMESPACES') or any other long help is shows in a pager.  That's great.  
It's a bit surprising however that the text shown in the pager doesn't include 
the "Related help topics: ..." line, which is shown when you leave the pager.

There is practical benefit to see the related topics after you exited the pager 
- that's when you have the chance to follow these other topics.  But I think it 
should be duplicated inside the pager as well.

--
assignee: d...@python
components: Documentation, Library (Lib)
messages: 121514
nosy: cben, d...@python
priority: normal
severity: normal
status: open
title: "Related help topics" shown outside pager
type: behavior
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue10457>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9724] help('nonlocal') missing

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Reopening because help('nonlocal') still doesn't work; attached patch fixes 
that.  It also cross-links all of global/nonlocal/NAMESPACES.

--
keywords: +patch
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file19700/nonlocal.diff

___
Python tracker 
<http://bugs.python.org/issue9724>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4246] execution model - clear and complete example in documentation

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

The FAQ for this was much improved in 2009 (issue 7290): 
http://docs.python.org/py3k/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

To support the claim that this keeps biting people, at least the following bug 
reports all came from people misundestanding this:
issue 10043
issue 9049
issue 7747
issue 7276
issue 6833
issue 5763
issue 4109 (understood effect of =, surprised by +=)
issue 972467
issue 850110
issue 463640
These are just the people who were persistent enough to open a bug (and in most 
cases managed to produce a minimal example); many more ask on c.l.p, 
StackOverflow (>50 hits for UnboundLocalError, many of which are this exact 
issue) etc., or just give up.

[Interesting point: people mostly complain when the unbound reference occurs 
textually *before* the assignment (though there's selection bias here), and 
many of them complain that things happen "out of order".  It seems half the 
misunderstanding is that people expect variables to *become* localized when 
first assigned - they don't understand it's a static decision affecting all 
occurences in a function.]

The central problem I believe is that when people try to modify a non-local var 
and get
  UnboundLocalError: local variable foo referenced before assignment
their mental model of Python scopes is *wrong*, so the error message is 
*useless* for them (what 'local variable foo' is it talking about?), and have 
no idea where to look next.

Also, I'm afraid people just won't internalize this issue until it bites them 
at least once (I've seen a Python course where I had explained this, with a 
print-before-assignment example, and 2 days later a student was bitten by the 
exception and was at a loss.  Therefore, I think providing a clear learning 
path from UnboundLocalError is crucial.

==>

I propose (i.e. am working on patch(s)) attacking it at many points:

(1) Expand UnboundLocalError message to point to help('NAMESPACES') 
[Execution Model → Naming and Binding] and/or the FAQ.
(requirement IMHO: use a help() ref that can be followed the 
from a Python prompt on an offline machine; not sure if FAQ can
work this way.)

(1B) Ideally, detect if the var is bound in outer/global scope 
 and suggest help('nonlocal') / help('global') approriately.

(1C) Ideally, improve UnboundLocalError to explain "foo is local 
 throughout the function because it's bound at line 42".

(2) Add an example to Naming and Binding section.
Currently, it's a bunch of legalese, defining 7 terms(!) before 
you get to the meat.  Mortal users won't survive that.
Being the language spec, the precise legalese must stay there;
but it'd be good to prepend it with a human-readable blurb and 
example regarding this issue.

(3) Improve the tutorial.  Sections 4.6 [Defining functions] and 9.2 
[Scopes and Namespaces] are relevant.  4.6 mentions the issue of 
assignment to global but neither section has a clear example.
And 9.2 is scary IMHO; I'll see if I can make it any better...

(4) Add examples to documentation of global & nonlocal?
Not clear if helpful, probably too much.

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue4246>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10043] UnboundLocalError with local variable set by setattr, caused by code run later

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Hi Steven.
Please confirm if we can mark the bug closed; if you need farther advice, 
posting your full code (not just the error case) on comp.lang.python or 
StackOverflow would be more effective.

The documentation is indeed correct but hard to find (you're not the first to 
be surprised by UnboundLocalError); I'm working on making things more 
discoverable in issue 4246.
See also 
http://docs.python.org/py3k/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

First of all, it's important to understand that a Python function has a *fixed* 
set of local variables, frozen when the function is parsed.  If you assign to 
it (e.g. ``name = None``), *all* appearances of the name in the function refer 
to a local variable; if not, they refer to the outer scope.
Therefore, you can't achieve what you want with local variables.

Generally, dynamically creating variables is a bad programming practice.  A 
dictionary is the cleanest way to hold a set of names/values that is not fixed. 
 Yes, you'll have to write ``cols['foo']`` instead of ``foo``; OTOH, setting 
them will not require any ugly magic...
Note also that string formatting can use values from a dictionary with very 
conveniently: ``"... {foo} ...".format(**cols)``.

The next best thing if ``cols['foo']`` is too verbose for you is ``cols.foo``: 
create an object which will contain the values as instance variables (that's a 
good use for setattr()).
This is the most Pythonic solution if a dictionary doesn't suffice - it's what 
most object-relational mappers do.

The third idea is to (ab)use a class statement.  A class statement in Python 
creates a temporary namespace *during the class definition* (we'll not be 
defining any methods or using it object-oriented stuff).
And the nice part is that you can put a class statement anywhere, even inside a 
function:
def f():
cols = {'foo': 42}  # however you fetch them...
class temp_namespace:
locals().update(cols)
print(foo / 6) # prints 7.0
assert 'foo' not in locals()  # no effect outside the class!
This works both in CPython 2 and 3.  I'm not 100% sure that being able to 
change locals() in a class is guaranteed in all other implementations.  (Note 
again that locals() of a *function* are not a real dictionary and you *can't* 
change them - as I said these are fixed when the function is defined.)

The fourth idea if you must have code that says just ``foo`` to access columns 
is to use the exec statement - you can pass it a dictionary that will serve as 
globals and/or locals.  An upside is that the code will be a string and can be 
dynamic as well.

(BTW, if the code is not dynamic, how come you don't know the names you're 
accessing?  If you do, you could just set ``foo = cols['foo']`` etc. for every 
variable you need - tedious but no magic needed.)

Lastly, as you discovered you can dynamically create global variables.  
(As Terry said, just use the dictionary returned by ``globals()``; no need for 
setattr).
But this is a very last resort (changing globals for a single function is 
ugly), and somewhat dangerous - e.g. consider what happens if a column names 
changes and overwrites a function name you had...

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue10043>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface

[Cherniavsky Beni]

Cherniavsky Beni <[EMAIL PROTECTED]> added the comment:

The patch logic is very simple: inside the command area Up/Down move
through history.
But what about multi-line editing?  Wouldn't this interfere when you
just want to move between lines in a multi-line command (e.g. a long
``def``)?
I'm afraid the conditional logic needs more refining to be useful.

--
nosy: +cben

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5594] IDLE startup configuration

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Editing a block of code from inside the config dialog (and storing it in the 
config file?) seems a bad idea because you lose all the power of the normal 
IDLE editor.

Instead, you should edit the startup code in the editor, save it to a file and 
point the IDLESTARTUP or PYTHONSTARTUP environment variable to it 
(http://docs.python.org/library/idle.html#startup).

[Unfortunately, these envvars currently don't work after restart; 
http://bugs.python.org/issue5233 has patches to fix that.]

What does make sense is having a way to set the startup file from the  config 
dialog, instead of environment variables.  I suspect nobody cares enough to 
implement this if you don't.

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue5594>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5594] IDLE startup configuration

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

(Another point I forgot to mention is that you must also run idle with the -s 
command-line option to look at these envvars.  This was silly and is also fixed 
by the #5233 patch.)

--

___
Python tracker 
<http://bugs.python.org/issue5594>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

History access by Up/Down is important because it makes IDLE history much more 
discoverable.  Most users instinctively expect Up/Down to work; moving back 
through the text of the session is nice but they probably won't guess that you 
can press Enter to reuse old commands; and it's not an efficient way to access 
history anyway.

The problem is increased by the fact that Alt+P/N *don't appear anywhere in the 
menus*, so a user will never discover them!

--

___
Python tracker 
<http://bugs.python.org/issue2704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5233] Enhance 2.7 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Oops!  Mitchell's patch didn't actually run the startup code after restart.  
Fixed patch attached (updated against 2.7 trunk).  Also added some doc updates. 
 Too lazy to produce a 3.2 version now.

[Apology to Mitchell: I removed most of your comments explaining the change and 
attributing it to you.  Nothing personal, just that's we have version control 
to store that info.]

Open questions / doubts:

* I described it in Lib/idlelib/NEWS.txt - correct?

* There is much duplication between the Doc/library/idle.rst, the command-line 
help string in PyShell.py and the option parsing code.  Maybe it should be 
rewritten with optparse?  [Doesn't block this patch.]

* There is much duplication between begin()/start_subprocess() and 
restart_subprocess().  These pieces of the code have a history of being 
fragile, and having subtle differences between them is a bad idea :-(  I didn't 
dare refactor them as I can't test such changes widely enough, so the startup 
call is duplicated.

* When a script is being run, should the startup file run before or after it 
(or at all)?  Currently it runs before the script, which is good because it can 
e.g. set the excepthook, and bad because it's different from running in a clean 
Python.   (Python doesn't run PYTHONSTARTUP at all when running a script, even 
in -i mode.)
Opinions?  Anyway, it's hard to implement otherwise with currect runcode().

[Unrelated to the patch but bothering me: it seems that runcode() sometimes 
restart the shell and sometimes not, and is used in both capacities?!  This is 
very confusing.  Or am I just reading it wrong?]

--
nosy: +cben
Added file: http://bugs.python.org/file16564/startup-2.7.diff

___
Python tracker 
<http://bugs.python.org/issue5233>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8285] IDLE not smart indenting correctly in nested statements

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Mark: customizing tabs to be anything but 8 spaces is inadvisable with Python, 
because Python always parses them as 8.
Sooner or later one would mix tabs and spaces and the result would be really 
painful to debug.

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue8285>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10224] Build 3.x documentation using python3.x

[Cherniavsky Beni]

Cherniavsky Beni added the comment:

I was only thinking of 3.4, which will have venv and a pip bootstrapper.
Is changing the doc build / doctest in scope for minor releases of 3.3 (or even 
earlier)?

The commands I listed (using setup_distribute.py) also work with 3.3.
(But they're unsecure -- https://bitbucket.org/tarek/distribute/issue/374/)
3.2 is harder as it doesn't even have builtin venv.

--

___
Python tracker 
<http://bugs.python.org/issue10224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15572] Python2 documentation of the file() built-in function

[Cherniavsky Beni]

New submission from Cherniavsky Beni:

[followup for issue 12642 which only fixed it for open()]

http://docs.python.org/library/functions.html#file
says the arg names are:
  file(filename[, mode[, bufsize]])
but in practice they are:
  file(name[, mode[, buffering]])

--
assignee: docs@python
components: Documentation
messages: 167617
nosy: cben, docs@python
priority: normal
severity: normal
status: open
title: Python2 documentation of the file() built-in function
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue15572>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Nice.  2 questions:

1. Why not change getch() to always use get_wch()?
2. I think you also want fix getkey() / introduce get_wkey().

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue6755>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7676] IDLE shell shouldn't use TABs

[Cherniavsky Beni]

New submission from Cherniavsky Beni :

IDLE defaults to indenting with 4 spaces in editor windows, but hard TABs in 
the Python Shell window.  This is inconsistent with PEP 8; what's worse, it's 
makes copy-paste code between the shell and editor windows confusing and 
dangerous!

Recently I gave a 3-day Python course to 6 people.  I spent some time 
explaining the dangers of TABs with Python's indentation-sensitive syntax and 
telling them "just use 4 spaces and all will be OK".  A few hours later one of 
them asked me why IDLE is refusing to run his code.  Turns out he copy-pasted 
code he tried out in the shell, edited it and tried running it, which resulted 
in a mix of tabs and spaces (which triggered IDLE's tabnanny check) and a 
mixture of 4 and 8 indents (which is ugly).

I had to explain IDLE's confusing behavior, introduce them to Untabify, and 
apologize for the inconvenience.  All this TABs stuff (and Untabify) are things 
people should eventually learn - but they shouldn't bite them on their first 
day!  (This is what Ubuntu calls a "papercut".)

The rationale for the current behavior seems to be making indentation clear 
despite the prompt offsetting the first line by 4:

>>> for i in range(3):
print i

There are 3 alternative behaviors that would be better:

 (1) Use 8 spaces instead of a TAB.
 (2) Use 4 spaces.
 (3) Use 4 spaces, but add a GUI left margin of 4 to continuation lines.

(3) would be ideal, making copy-paste work cleanly while looking good.  I'm not 
sure if it can be implemented easily, but I'll look into it.

If it's hard, (2) would still be a big improvement IMHO.  I think correct 
behaviour is more important than looking good after ">>> " - but others may 
disagree on this.

If there is doubt, (1) is still strictly an improvement.  It can lead to mixed 
8/4 spaces - but at least there won't be invisible problems that the user 
doesn't understand.

[Configurability concerns: all I said above refers to the *default* behavior of 
IDLE, which should follow 4-spaces.  The user should be able to configure it to 
use another width, or TABs.  This option already exists - but it's ignored 
outright by the shell window.  Solutions (2) and (3) would make the shell 
window respect it.]

--
components: IDLE
messages: 97586
nosy: cben
severity: normal
status: open
title: IDLE shell shouldn't use TABs
type: behavior

___
Python tracker 
<http://bugs.python.org/issue7676>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5067] Error msg from using wrong quotes in JSON is unhelpful

[Cherniavsky Beni]

Cherniavsky Beni  added the comment:

Perhaps it should not be an error at all?  The default should probably
stay strict to the spec, but IMHO the module should provide an optional
lenient parsing mode that also accepts single quotes.

Why support single quotes and not any other imaginable deviation from
the spec?  Because single quotes are the only way (AFAIK) in which
Python's repr() produces invalid JSON (from JSONable combinations of types).

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue5067>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Cherniavsky Beni]

New submission from Cherniavsky Beni :

An interactive prompt should offer working completion out-of-the-box,
without requiring every Python user on earth to create a $PYTHONSTARTUP
with '''import readline; readline.parse_and_bind("tab: complete")'''.

Note that it should work not only when Python is run without arguments,
but also when running with the -i option.
And ideally, it should only install the completion function when
dropping to the interpreter, not from the start, so that code that runs
before dropping to the interpreter is not affected.  But this is really
not important.

Safety: if 'rlcompleter' or 'readline' are not availiable (e.g. broken
python install), the user must still get a working interpreter, just
without completion.

Portability: there won't be completion on windows (as long as pyreadline
or similar is not part of Python).  But that shouldn't delay unix support!

--
messages: 86570
nosy: cben
severity: normal
status: open
title: rlcompleter should be enabled automatically

___
Python tracker 
<http://bugs.python.org/issue5845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Cherniavsky Beni]

Changes by Cherniavsky Beni :


--
components: +Interpreter Core
type:  -> feature request
versions: +Python 2.7, Python 3.1

___
Python tracker 
<http://bugs.python.org/issue5845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17475] Better doc on using python-gdb.py

[Cherniavsky Beni]

New submission from Cherniavsky Beni:

recent gdb versions by default won't auto-load python-gdb.py.
issue15043 fixed this in test_gdb, but manual action is still needed to when a 
developer actually wants to run gdb.

Attached devguide patch.
After writing this I noticed it's already explained in faq.txt, but I think 
it's important to also explain it in the devguide's GDB section.

Should this also be mentioned inside python-gdb.py?
And why does that file have a Tools/gdb/libpython.py doppleganger?

--
components: Devguide
files: python-gdb-how-to-load.diff
keywords: patch
messages: 184574
nosy: cben, ezio.melotti, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: Better doc on using python-gdb.py
versions: Python 3.4
Added file: http://bugs.python.org/file29469/python-gdb-how-to-load.diff

___
Python tracker 
<http://bugs.python.org/issue17475>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17475] Better doc on using python-gdb.py

[Cherniavsky Beni]

Cherniavsky Beni added the comment:

The links to gdb docs presently are broken because sourceware.org is down for 
maintenance, but it should be back up in a couple days.

--

___
Python tracker 
<http://bugs.python.org/issue17475>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10224] Build 3.x documentation using python3.x

[Cherniavsky Beni]

Cherniavsky Beni added the comment:

After a lot of experimentation, this worked for me to build AND doctest using 
the local python:

cd Doc/
../python -m venv toolsenv
curl http://python-distribute.org/distribute_setup.py | toolsenv/bin/python
toolsenv/bin/easy_install pip
toolsenv/bin/pip install Sphinx
# EDIT conf.py: add 'toolsenv' to exclude_trees.
toolsenv/bin/sphinx-build -b html -d build/doctrees -D latex_paper_size=  . 
build/html
toolsenv/bin/sphinx-build -b doctest -d build/doctrees . build/doctest

The tool versions I got:

$ toolsenv/bin/pip list
distribute (0.6.35)
docutils (0.10)
Jinja2 (2.6)
Pygments (1.6)
Sphinx (1.1.3)

HTML: http://dl.dropbox.com/u/132894668/python3-Doc-build/html/index.html
The HTML has no significant differences vs the output of "make html".
It's mostly sphinx html tweaks.  The only user-visible diff I noticed is 
s/v3.4.0a0/3.4.0a0/.

The doctests are pretty horrible - 559 failed out of 1954!  (attached)
But it's better than 900+ failed with python 2 ("make doctest") and 700+ with 
python 3.2 that I originally tried via "apt-get install python3-sphinx"...

So let's update the tools ASAP, and start using PYTHON=../python.
The doctests won't get any love unless "make doctest" does the right thing out 
of the box.

Should I write a Makefile patch using the venv/install from pypi approach?
Or could somebody upload new versions to 
http://svn.python.org/projects/external/?
(Lack of access there was the reason I went the venv way.
IMHO the ease of future upgrades outweighs the concern of not depending on 
external sites, but I don't feel strongly about it.)

--
nosy: +cben
Added file: http://bugs.python.org/file29525/output.txt

___
Python tracker 
<http://bugs.python.org/issue10224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Cherniavsky Beni]

Cherniavsky Beni added the comment:

+1, is there anything missing to apply Paul's patch?

Can I additional suggest a change to the error message, e.g.:

  $ prog --foo -bar
  prog: error: argument --foo: expected one argument
  (tip: use --foo=-bar to force interpretation as argument of --foo)

This can be safely added in the current mode with no opt-in required, and will 
relieve the immediate "but what can I do?" confusions of users.  The workaround 
is hard to discover otherwise, as `--foo=x` is typically equivalent to `--foo 
x`.

--- more discussion, though I suspect it's not productive ---

I've tried to find what the GNU Standards or POSIX say about this and was 
surprised to see neither explains how exactly `--opt_with_mandatory_argument 
-quux` behaves.

man getopt says:

 If such a character is followed by a colon, the option requires an 
argument, so getopt() places a pointer to the following text in the same 
argv-element, or the text of the following argv-element, in optarg. Two colons 
mean an option takes an optional arg; if there is text in the current 
argv-element (i.e., in the same word as the option name itself, for example, 
"-oarg"), then it is returned in optarg, otherwise optarg is set to zero. This 
is a GNU extension.

POSIX similarly does explain that an optional arg after an option must follow 
within the same argument:

(2)(b) If the SYNOPSIS shows an optional option-argument (as with [ -f[ 
option_argument]] in the example), a conforming application shall place any 
option-argument for that option directly adjacent to the option in the same 
argument string, without intervening  characters. If the utility 
receives an argument containing only the option, it shall behave as specified 
in its description for an omitted option-argument; it shall not treat the next 
argument (if any) as the option-argument for that option.

-- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

Anyway, every argument parsing library I've ever seen parses options in a 
left-to-right pass, consuming non-optional arguments after an option whatever 
they look like.  I've never seen a difference between `--foo bar` and 
`--foo=bar` when bar is *non-optional*.

Both behaviors (--opt_with_mandatory_argument bar, 
--opt_with_optional_argument[=bar]) were clearly designed to avoid ambiguity.
Whereas argparse innovated some constructs eg. '--opt', nargs='*' that are 
inherently ambiguous.  But for the simple constructs, most notably nargs=1, 
there should be a way to get the traditional unix meaning.

--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Cherniavsky Beni]

Changes by Cherniavsky Beni :


--
nosy: +cben

___
Python tracker 
<http://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com