On 07/20/2015 01:35 PM, Florian Bruhin wrote:
> >>>m.assert_me()
>Traceback (most recent call last):
> File "", line 1, in
> File
"/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py",
>line 583, in __getattr__
> raise AttributeError(name)
>AttributeError
On 07/20/2015 03:32 AM, Florian Bruhin wrote:
* Ron Adam [2015-07-19 18:06:22 -0400]:
>
>
>On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> >* Ron Adam [2015-07-19 11:17:10 -0400]:
> >>>I had to look at the source to figure out what this thread was really all
&
On 07/19/2015 02:33 PM, Florian Bruhin wrote:
* Ron Adam [2015-07-19 11:17:10 -0400]:
>I had to look at the source to figure out what this thread was really all
>about.
And it seems I don't quite get it still, but I am trying.
>Basically it looks to me the purpose of addi
On 07/19/2015 11:52 AM, Ethan Furman wrote:
Seems to me a lot of fuss could have been avoided by just acknowledging
that a mistake may have been made, and asking for patches if anybody cared
enough about it.
I'm not sure it's a mistake, but it may not be the best way to do what the
"alias ch
On 07/16/2015 07:48 PM, Antoine Pitrou wrote:
On Fri, 17 Jul 2015 11:35:53 +1200
Alexander wrote:
>
>I do not want to read mistyped code from other developers and try to
>guess whether it will work properly or not.
You don't have to guess anything. If it's mistyped, either it raises
Attrib
On 07/14/2015 12:36 PM, Christie Wilson wrote:
If people do misspell it, I think they do learn not to after it
happens a few times.
Unless the line silently executes and they don't notice the mistake for
years :'(
Yes, and I'm concerned that allowing it in one location may bring abo
On 07/14/2015 09:41 AM, Steven D'Aprano wrote:
On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>https://bugs.python.org/issue21238 introduces detection of
>missing/misspelt mock.assert_xxx() calls on getattr level in Python
>3.5
>
>Michael and Kushal are of the opinion that "assr
On 06/26/2015 10:31 AM, Chris Angelico wrote:
Apologies if this is a really REALLY dumb question, but... How hard
would it be to then dispense with the await keyword, and simply
_always_ behave that way? Something like:
def data_from_socket():
# Other tasks may run while we wait for data
On 06/20/2015 12:12 PM, Ron Adam wrote:
On 06/20/2015 02:51 AM, Ivan Levkivskyi wrote:
Guido said 13 years ago that this behavior should not be changed:
https://mail.python.org/pipermail/python-dev/2002-April/023428.html,
however, things changed a bit in Python 3.4 with the introduction
On 06/20/2015 02:51 AM, Ivan Levkivskyi wrote:
Hello,
There appeared a question in the discussion on
http://bugs.python.org/issue24129 about documenting the behavior that
unbound local variables in a class definition do not follow the normal rules.
Guido said 13 years ago that this behavior s
he same task, even if there is another one that
>could run. It's up to the scheduler whether it
>implements any kind of "fair" scheduling policy.
That's what I understood but the example ('yielding()') provided by
Ron Adam seemed to imply otherwise, so I wanted t
On 05/02/2015 04:18 PM, Arnaud Delobelle wrote:
On 1 May 2015 at 20:59, Guido van Rossum wrote:
>On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote:
>>
>>
>>Another useful async function might be...
>>
>>async def yielding():
>>pass
>>
On 05/01/2015 07:54 AM, Steven D'Aprano wrote:
On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote:
>Ah, but here's the other clever bit: it's only interpreted this way
>*inside* a function declared with 'async def'. Outside such functions,
>'await' is not a keyword, so that gra
On 03/07/2015 04:58 AM, Steven D'Aprano wrote:
On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote:
>Have you considered doing this by having different magic numbers in the
>.pyc file for standard, -O, and -O0 compiled bytecode files? Python
>already checks that number
On 03/06/2015 11:34 AM, Brett Cannon wrote:
There are currently two open issues, although one is purely a bikeshed
topic on formatting of file names so I don't really consider it open for
change from what is proposed in the PEP without Guido saying he hates my
preference or someone having a re
On 11/23/2014 04:15 PM, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adam wrote:
>With the passage of the PEP, it will change what is different about them
>once it's in full effect. The stop hack won't work in both, and you may get
>a RuntimeError in ge
On 11/23/2014 04:08 AM, Terry Reedy wrote:
On 11/22/2014 5:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
Making comprehensions work more like generator expressions
would, IMO, imply making the same change to all for loops: having a
StopIteration raised by the
On 11/22/2014 07:06 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adam wrote:
>
>
>On 11/22/2014 06:20 PM, Chris Angelico wrote:
>>
>>Hmmm, there's no such thing as tuple comprehensions.
>
>Just didn't think it through quite well enou
On 11/22/2014 06:20 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adam wrote:
>Se we have these...
>
> Tuple Comprehension (...)
> List Comprehension [...]
> Dict Comprehension {...} Colon make's it different from sets.
>
On 11/22/2014 04:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
>>Making comprehensions work more like generator expressions
>>would, IMO, imply making the same change to all for loops: having a
>>StopIteration raised by the body of the loop
On 11/22/2014 03:01 PM, Terry Reedy wrote:
Then both a comprehension and a generator expressions can be viewed as
defining iterators,
A comprehension is not an iterator. The above would make a list or set
comprehension the same as feeding a genexp to list() or set().
Correct, but we coul
On 11/22/2014 02:16 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adam wrote:
>
>OPTION 1:
>
>Make comprehensions act more like generator expressions.
>
>It would mean a while loop in the object creation point is converted to a
>for loop. (or something
On 11/22/2014 08:31 AM, Nick Coghlan wrote:
On 22 Nov 2014 02:51, "Antoine Pitrou" mailto:solip...@pitrou.net>> wrote:
>
> On Fri, 21 Nov 2014 05:47:58 -0800
> Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote:
> >
> > Another issue is that it breaks the way I and others have t
On 12/31/2013 04:34 AM, "Martin v. Löwis" wrote:
So for the Python 4 survey, I propose to have just a single question:
* Have you heard of Python 4?
That will prove that Python 4 is even faster than Python 3:-)
Of course, that is also because it has a JIT compiler, and runs
on 16 cores with n
On 06/17/2013 05:18 PM, Greg Ewing wrote:
I'm still not convinced that this is necessary or desirable
behaviour. I can understand the parser doing this as a
workaround before we had universal newlines, but now that
we do, I'd expect any Python string to already have newlines
converted to their
On 06/17/2013 12:04 PM, Walter Dörwald wrote:
Making the string raw, of course turns it into:
U+0027: APOSTROPHE
U+0027: APOSTROPHE
U+0027: APOSTROPHE
U+005C: REVERSE SOLIDUS
U+0072: LATIN SMALL LETTER R
U+005C: REVERSE SOLIDUS
U+006E: LATIN SMALL LETTER N
U+002
On 06/15/2013 03:23 PM, Guido van Rossum wrote:
The semantics of raw strings are clear. I don't see that they should be
called out especially in any context. (Except for regexps.) Usually exec()
is not used with a literal anyway (what would be the point).
There are about a hundred instances
On 06/14/2013 04:03 PM, PJ Eby wrote:
>Should this be the same?
>
>
>python3 -c 'print(bytes("""\r\n""", "utf8"))'
>b'\r\n'
>
>
eval('print(bytes("""\r\n""", "utf8"))')
>b'\n'
No, but:
eval(r'print(bytes("""\r\n""", "utf8"))')
should be. (And is.)
What I believe you and Walter are mi
On 06/14/2013 10:36 AM, Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
Should this be the same?
python3 -c 'print(bytes("""\r\n""", "utf8"))'
b'\r\n'
>>> eval('print(bytes("""\r\n""", "utf8"))')
b'\n'
Ron
On Jun 14, 2
On 06/09/2013 10:13 PM, Alexander Belopolsky wrote:
On Sun, May 19, 2013 at 1:47 AM, Guido van Rossum mailto:gu...@python.org>> wrote:
I'm slow at warming up to the idea. My main concern is speed -- since
most code doesn't need it and function calls are already slow (and
obviously
On 05/30/2013 03:34 AM, Mark Shannon wrote:
On 29/05/13 01:14, Brett Cannon wrote:
On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote:
On Tue, 28 May 2013 23:29:46 +0200 (CEST)
brett.cannon wrote:
+.. class:: ModuleManager(name)
+
+A :term:`context manager` which provides the mod
On Mon, 2012-01-02 at 14:44 +1000, Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
> statement;
> else
> statement;
>
> vs.
>
> if (cond) {
> statement;
> } else {
> statement;
> }
>
Hi, I Just added issue 13607 with a patch that removes the generator
specific checks and code out of the ceval PyEval_EvalFrameEx() function.
Those parts where moved up into the generator gen_send_ex() function.
Doing that removed the generator flag checks from the eval loop and made
it a bit c
On Wed, 2011-10-19 at 22:17 +0300, anatoly techtonik wrote:
> Does everybody feel comfortable with 'stage' and 'resultion' fields in
> tracker?
>
> I understand that 'stage' defines workflow and 'resolution' is status
> indicator, but the question is - do we really need to separate them?
> For ex
On 03/05/2011 06:33 PM, Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam wrote:
Adding a second references to the '__main__' module begins to blur the
purpose of sys.modules from being a place to keep imported modules to a
place that also has some ordering i
On 03/05/2011 01:14 AM, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam wrote:
Fixing direct execution inside packages
+1 on both of these.
I don't see any major problems with these. Any minor issues can be worked
out.
I suggest separating these two items out into thei
On 03/04/2011 09:30 AM, Nick Coghlan wrote:
Fixing dual imports of the main module
--
Two simple changes are proposed to fix this problem:
1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
install the specified module in ``sys.
On 03/01/2011 01:22 PM, Georg Brandl wrote:
On 01.03.2011 16:05, Antoine Pitrou wrote:
On Tue, 1 Mar 2011 16:52:58 +0200
Eli Bendersky wrote:
The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
2010-03-05: final conversion (tentative)
I assume 2011-03-05 is meant here.
On 02/01/2011 09:51 AM, anatoly techtonik wrote:
So far only Georg explained what patches sent to mailing list will not
be reviewed, because there is too much volume. But bugtracker is not a
patch tracker. It doesn't allow to monitor incoming patches by module,
its search is very poor. Of cour
On 01/18/2011 01:14 AM, Georg Brandl wrote:
For these cases, you can use traceback.format_exception_only().
Thanks George, That works nicely.
Ron ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
On 01/17/2011 02:27 PM, Georg Brandl wrote:
Am 17.01.2011 21:22, schrieb Ron Adam:
Is this on purpose?
Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more informati
27;has no name')
>>> e.__name__
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Exception' object has no attribute '__name__'
Ron Adam
___
Python-Dev mailing list
Python-Dev@python.o
:-D
Great job Georg!
Ron Adam
On 01/16/2011 01:33 AM, Georg Brandl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm very happy to announce the
first release candidate of Python 3.2.
Python 3.2 is a continuation of the efforts to im
On 01/10/2011 12:01 PM, Antoine Pitrou wrote:
Hello,
I would like to advocate again for the removal of the "unit test
needed" stage on the tracker, which regularly confuses our triagers
into thinking it's an actual requirement or expectation from
contributors and bug reporters.
This keeps
On 12/24/2010 02:03 PM, Raymond Hettinger wrote:
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
On 12/24/2010 11:09 AM, Michael Foord wrote:
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match.
Close second is
On 12/18/2010 04:46 PM, Terry Reedy wrote:
On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
Author: ezio.melotti
Date: Sat Dec 18 21:00:04 2010
New Revision: 87389
Log:
#10573: use actual/expected consistently in unittest methods.
Ch
On 12/01/2010 04:39 AM, Nick Coghlan wrote:
On Wed, Dec 1, 2010 at 8:22 PM, Greg Ewing wrote:
Nick Coghlan wrote:
For the directory-as-module-not-package idea ...
you would need to be very careful with it,
since all the files would be sharing a common globals() namespace.
One of the thing
On 11/30/2010 07:19 PM, Nick Coghlan wrote:
On Wed, Dec 1, 2010 at 8:48 AM, Ron Adam wrote:
* It almost seems like the concept of a sub-module (in a package) is flawed.
I'm not sure I can explain what causes me to feel that way at the moment
though.
It isn't flawed, it is j
On 11/30/2010 01:41 PM, Brett Cannon wrote:
On Mon, Nov 29, 2010 at 12:21, Ron Adam wrote:
On 11/29/2010 01:22 PM, Brett Cannon wrote:
On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
wrote:
On 25 novembre 11:22, Ron Adam wrote:
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello
On 11/28/2010 09:03 PM, Ron Adam wrote:
It does associate additional info to names and creates a nice dictionary to
reference.
>>> def name_values( FOO: 1,
BAR: "Hello World!",
BAZ: dict(a=1, b=2, c=3) ):
... return FOO, BAR, BAZ
...
>>> foo(1,2,3)
(1, 2, 3)
&
On 11/29/2010 01:22 PM, Brett Cannon wrote:
On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
wrote:
On 25 novembre 11:22, Ron Adam wrote:
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
On 11/27/2010 04:51 AM, Nick Coghlan wrote:
x = named_value("FOO", 1)
y = named_value("BAR", "Hello World!")
z = named_value("BAZ", dict(a=1, b=2, c=3))
print(x, y, z, sep="\n")
print("\n".join(map(repr, (x, y, z
print("\n".join(map(str, map(type, (x, y, z)
set_named_values(globals(),
so you get a different error than if you used import, which uses the parser
module and that does set the filename.
From what I've seen, it would help if the imp module was rewritten to use
parser.c like the import statement does, rather than tokenizer.c directly.
The error handling in parse
Oops.. x**2 should have been 2**x below.
On 11/23/2010 03:03 PM, Ron Adam wrote:
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many
On 11/23/2010 12:07 PM, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 12:50 -0500, Isaac Morland a écrit :
Each enumeration is a type (well, OK, not in every language, presumably,
but certainly in many languages). The word "basic" is more important than
"types" in my sentence - the point
On 11/10/2010 01:33 PM, Raymond Hettinger wrote:
On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
So it is obvious that we don't have a clearly stated policy for what defines
the public API of standard library modules.
How about making this explicit (either pep 8 or our developer docs):
On 11/08/2010 10:26 PM, Nick Coghlan wrote:
On Tue, Nov 9, 2010 at 11:18 AM, Ron Adam wrote:
What do you think about adding a new _pydoc3.py module along with a
pydoc3.py loader module with a basic user api. The number 3, so that it
match's python3.x.
We can then keep the old pyd
On 11/08/2010 07:18 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 16:10, Ron Adam wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
That is ugly. I already hate doing that for unittest, I'm not about to
champion that for any
On 11/08/2010 05:44 AM, Nick Coghlan wrote:
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically public standard
library APIs (albeit undocumented ones).
On 11/08/2010 04:01 PM, Brett Cannon wrote:
My understanding is that anything with an actual docstring is part of the
public API. Any thing with a leading underscore is private.
That's a bad rule. Why shouldn't I be able to document something that
is not meant for the public so that fellow
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan wrote:
..
I'd actually started typing out the command to commit this before it finall
On 11/08/2010 09:12 AM, exar...@twistedmatrix.com wrote:
On 11:44 am, ncogh...@gmail.com wrote:
All,
I was about to commit the patch for issue 2001 (the improvements to
the pydoc web server and the removal of the Tk GUI) when I realised
that pydoc.serve() and pydoc.gui() are technically publi
Current status from the tracker...
don't care: 22134
not closed: 2491
not selected: 1
open: 2451
languishing: 25
pending: 39
closed: 19604
That gives us...
2451 open
1 not selected
39 pending
25 languishing
2516 Total open
2451 open
39 languishing
Should be 39 pending here, not la
On 11/06/2010 12:01 PM, Terry Reedy wrote:
On 11/6/2010 11:42 AM, R. David Murray wrote:
On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote:
Am 06.11.2010 05:44, schrieb Ezio Melotti:
Hi,
On 05/11/2010 19.08, Python tracker wrote:
ACTIVITY SUMMARY (2010-10-29 - 2010-11-05)
Python track
On 10/27/2010 08:51 AM, Nick Coghlan wrote:
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam wrote:
I still would like to know what your thoughts are concerning where to put,
and/or how to package, the simple threaded text server?
Given the time frame until beta 1, I'd suggest leaving it in
On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I wonder what you may think. Keep it in pydoc or move it to the
HTTP package? Document it or not?
I still would like to know what your thoughts are concerning where to put,
and/or how to
On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
On 10/26/2010 02:34 PM, Raymond Hettinger wrote:
FWIW, it wasn't that big (approx 2500 lines).
The argparse, difflib, doctest, pickletools, pydoc, tarfile modules
are about the same size and the decimal module is even larger.
Please don't split those.
Sense you mention this...
I've worked on
On 10/21/2010 07:13 PM, Greg Ewing wrote:
Eric Smith wrote:
Or for that matter a plain "pysetup". It would be the one that a plain
"python" would get you.
If 'pysetup' is simply a shell script that invokes 'python -m setup'
using the current search path, I guess that's true.
On Windows, how
On 10/12/2010 09:59 AM, Barry Warsaw wrote:
On Oct 12, 2010, at 12:24 PM, Greg Ewing wrote:
Giampaolo Rodolà wrote:
If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".
Anoth
; or "license" for more information.
>>> help('modules ""')
Here is a list of matching modules. Enter any module name to get more help.
Segmentation fault
Or more directly...
>>> import imp
>>> imp.find_module('test/badsyntax_pep
On 10/18/2010 07:07 PM, R. David Murray wrote:
Seriously, though, what it indicates is indicates is that we need a unit
test for the patch to be complete. We have a number of issues with
patches but no tests, I believe. Which order 'unit test' and 'fix'
occur in is arbitrary in practice. I
On 10/11/2010 07:27 AM, Nick Coghlan wrote:
On Mon, Oct 11, 2010 at 1:54 AM, anatoly techtonik wrote:
On Sun, Sep 26, 2010 at 2:32 PM, Nick Coghlan wrote:
This is almost certainly failing because the directory containing the
spyderlib package isn't on sys.path anywhere (instead, whichever
d
On 10/09/2010 12:39 PM, "Martin v. Löwis" wrote:
Am 09.10.2010 01:35, schrieb Greg Ewing:
Georg Brandl wrote:
The explanation is that everything that comes after "import" is
thereafter
usable as an identifier (or expression, in the case of dotted names) in
code. ".mymodule" is not a valid ex
yield f(n)
if __name__ == "__main__":
print(factoral(1)) # < extra zero too!
But if I add another zero, it begins to slow to a crawl as it uses swap
space. ;-)
How would a "yield from" version compare?
I'm basically learning this stuff by trying
On 08/02/2010 03:57 AM, Stephen J. Turnbull wrote:
Ron Adam writes:
> Something that may be more useful, is a "no activity" search field
> with choices of day, week, month, year, etc... and make the output
> sortable on time without activity.
That's exactl
On 08/01/2010 06:14 PM, Terry Reedy wrote:
On 8/1/2010 7:44 AM, Éric Araujo wrote:
+1 On a prebuilt search
This is not as easy as it seems.
A nosy count of 1 misses posts where someone added themself as nosy
without saying anything, waiting for someone else to answer (and maybe
no one ever di
FWIW, I am +1 on dropping tkinter interface. Tkinter window looks
foreign next to browser and server-side GUI that opens a new client
window with each search topic does not strike me as most usable
design. Furthermore, I just tried to use it on my OSX laptop and it
crashed after I searched fo
On 07/24/2010 10:44 PM, Nick Coghlan wrote:
To request automatic assignment of a local port number, "-p 0" could
be made to work correctly (i.e. print out the actual port the OS
assigned rather than the 0 that was passed in on the command line as
it does currently).
I was able to implement t
On 07/25/2010 12:01 PM, Alexander Belopolsky wrote:
On Sun, Jul 25, 2010 at 12:32 PM, Ron Adam wrote: ..
I'd be completely fine with dropping the "Search For" box from the
GUI interface, but the persistent window listing the served port
and providing "Open Browser" a
On 07/24/2010 10:38 PM, Nick Coghlan wrote:
On Sun, Jul 25, 2010 at 5:34 AM, Ron Adam wrote:
On 07/24/2010 05:37 AM, Nick Coghlan wrote:
On Sat, Jul 24, 2010 at 10:05 AM, Ron Adamwrote:
I am not sure I like the fact that the browser is started automatically.
Please bring this up on
On 07/24/2010 04:29 PM, Alexander Belopolsky wrote:
On Sat, Jul 24, 2010 at 3:34 PM, Ron Adam wrote:
On 07/24/2010 05:37 AM, Nick Coghlan wrote:
..
- leave the "-g" option alone (including the tk gui), but make sure
other options still work when tk is unavailable
I was hopin
On 07/24/2010 05:37 AM, Nick Coghlan wrote:
On Sat, Jul 24, 2010 at 10:05 AM, Ron Adam wrote:
I am not sure I like the fact that the browser is started automatically.
Please bring this up on python-dev. This may be an opportunity to
rethink pydoc command line switches. For example, -p and
On 07/24/2010 10:16 AM, Alexander Belopolsky wrote:
On Sat, Jul 24, 2010 at 6:37 AM, Nick Coghlan wrote:
..
For the "-b" option, if the server is already running (and hence the
port is in use), catch the exception, print a message and start the
webbrowser anyway.
I was going to make a simil
This regards the following feature request.
http://bugs.python.org/issue2001
Summery:
The pydoc "gui" enhancement patch adds a navigation bar on each page with
features that correspond to abilities that are currently available to help.
ie.. a get field, to get help on an item, a find fi
On 07/20/2010 12:00 PM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam wrote:
It doesn't fall under the single constant rule if done this way.
If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions inste
On 07/20/2010 11:47 AM, Ron Adam wrote:
On 07/20/2010 10:43 AM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano
wrote:
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing
On 07/20/2010 10:43 AM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano wrote:
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select between them.
In particular, when that a
On 07/15/2010 07:13 AM, Nick Coghlan wrote:
On Thu, Jul 15, 2010 at 7:23 PM, Oleg Broytman wrote:
Sorry for being a wet blanket but vim implements tabbed windows even in
console (text) mode. (-:
Oh, I know vim and emacs are actually incredibly powerful once you
learn how to use them. I'm
On 07/12/2010 01:21 PM, Ian Bicking wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam mailto:r...@ronadam.com>> wrote:
There might be another alternative.
Both idle and pydoc are applications (are there others?) that are in
the standard library. As such, they or parts o
On 07/10/2010 06:05 PM, Tal Einat wrote:
Hello,
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help
maintain and further develop IDLE since 2005.
In recent years IDLE has received negligible interest and atten
On 07/07/2010 12:30 PM, Georg Brandl wrote:
Am 07.07.2010 18:09, schrieb Michael Foord:
I would say that the major use of docstrings is for interactive help - so
interactive readability should be *the most important* (but perhaps not only)
factor when considering how to format standard librar
On 04/18/2010 06:35 PM, Nick Coghlan wrote:
Steven Bethard wrote:
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan wrote:
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version'
On 04/18/2010 05:57 PM, Nick Coghlan wrote:
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
"show program's version number and exit" as the default help for the
'version' action. Then you should just write:
parser.add_argument('--version', act
anatoly techtonik wrote:
So, there won't be any package management tool shipped with Python 2.7
and users will have to download and install `setuptools` manually as
before:
"search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
setup.py install"
Therefore I still propose shipping bo
Nick Coghlan wrote:
Ron Adam wrote:
I think I misunderstood this at first.
It looks like, while developing a python 3.2+ program, if you don't
create an empty __pycache__ directory, everything will still work, you
just won't get the .pyc files. That can be a good thing during
d
Terry Reedy wrote:
On 3/22/2010 2:15 PM, Antoine Pitrou wrote:
What I am proposing is that the creation of __pycache__ /directories/
be put
outside of the core. It can be part of distutils, or of a separate
module, or
delegated to third-party tools. It could even be as simple as
"python -m
Guido van Rossum wrote:
On Mon, Mar 22, 2010 at 12:20 PM, Barry Warsaw wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and
Barry Warsaw wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and deleting any byte-code files in the module/program
Antoine Pitrou wrote:
Isaac Morland uwaterloo.ca> writes:
IMO, all these issues militate for putting __pycache__ creation out of
the interpreter core, and in the hands of third-party package-time/
install-time tools (or distutils).
Speaking only for myself, but really for anybody who likes ti
1 - 100 of 280 matches
Mail list logo