Re: Documentation of __hash__

On 02/11/2020 02:23 AM, klau...@gmail.com wrote: On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote: The purpose of this rule is to save you from having to override the default __hash__ with something that will only raise an exception when you do not intend your class to be has

Re: Documentation of __hash__

On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote: > On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote: > > On 2/6/20 2:13 PM, klau...@gmail.com wrote: > > > The default __eq__ method (object identity) is compatible with all > > > (reasonable) self-defined __hash__ method. > > > >

Re: Documentation of __hash__

On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote: > On 2/6/20 2:13 PM, klau...@gmail.com wrote: > > The default __eq__ method (object identity) is compatible with all > > (reasonable) self-defined __hash__ method. > > > > Stefan > > If __eq__ compares just the id, then the only hash you need is

Re: Documentation of __hash__

On 2/6/20 2:13 PM, klau...@gmail.com wrote: The default __eq__ method (object identity) is compatible with all (reasonable) self-defined __hash__ method. Stefan If __eq__ compares just the id, then the only hash you need is the default that is also the id. If you define a separate hash funct

Re: Documentation of __hash__

The default __eq__ method (object identity) is compatible with all (reasonable) self-defined __hash__ method. Stefan -- https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

Am 05.02.20 um 20:55 schrieb klau...@gmail.com: If not, why should a class not define __hash__, if it does not define __eq__? Hashes are not unique. When you insert or look up something in a hashtable, the hash is computed and used as the index into the table. Because the hash is not necessa

Re: Documentation of __hash__

On Wednesday, February 5, 2020 at 7:41:13 PM UTC+1, Dieter Maurer wrote: > Stefan Halfpap wrote at 2020-2-5 14:57 +0100: > >I do not understand the following statement from the python (2 and 3) > >documentation regarding __hash__ and __eq__ methods: > >"If a class does not define an __eq__() > ><

Re: Documentation of __hash__

Stefan Halfpap wrote at 2020-2-5 14:57 +0100: >I do not understand the following statement from the python (2 and 3) >documentation regarding __hash__ and __eq__ methods: >"If a class does not define an __eq__() > method it >shoul

Re: documentation on read.encode

On Thu, Jan 18, 2018 at 12:47 AM, Steven D'Aprano wrote: > On Wed, 17 Jan 2018 16:54:37 -0500, Larry Martell wrote: > >> The code that was receiving the >> PNG was not reading and writing the file as binary. Strangely that >> worked on Linux but not on Windows. > > Nothing strange about it -- on U

Re: documentation on read.encode

On Wed, 17 Jan 2018 16:54:37 -0500, Larry Martell wrote: > The code that was receiving the > PNG was not reading and writing the file as binary. Strangely that > worked on Linux but not on Windows. Nothing strange about it -- on Unix and Linux systems (with the possible exception of Mac OS?) in

Re: documentation on read.encode

On Tue, Jan 16, 2018 at 3:58 PM, MRAB wrote: > On 2018-01-16 19:52, Larry Martell wrote: >> >> On Tue, Jan 16, 2018 at 2:35 PM, Gene Heskett >> wrote: >>> >>> On Tuesday 16 January 2018 14:19:38 Larry Martell wrote: >>> On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell >>> >>> wrote: >>>

Re: documentation on read.encode

On 2018-01-16 19:52, Larry Martell wrote: On Tue, Jan 16, 2018 at 2:35 PM, Gene Heskett wrote: On Tuesday 16 January 2018 14:19:38 Larry Martell wrote: On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell wrote: > Looking for 2.7 docs on read.encode - googling did not turn up > anything. > > Sp

Re: documentation on read.encode

On 2018-01-16, Larry Martell wrote: > Yeah I saw it mentioned in a SO post that was java related. Wondering > if there is some way to do the same in python. base64.b64encode(foo) -- https://mail.python.org/mailman/listinfo/python-list

Re: documentation on read.encode

On Tue, Jan 16, 2018 at 3:17 PM, Ned Batchelder wrote: > On 1/16/18 2:19 PM, Larry Martell wrote: >> >> On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell >> wrote: >>> >>> Looking for 2.7 docs on read.encode - googling did not turn up anything. >>> >>> Specifically, looking for the supported option

Re: documentation on read.encode

On 1/16/18 2:19 PM, Larry Martell wrote: On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell wrote: Looking for 2.7 docs on read.encode - googling did not turn up anything. Specifically, looking for the supported options for base64, and how to specify them, e.g. Base64.NO_WRAP So I just realized

Re: documentation on read.encode

On Tue, Jan 16, 2018 at 2:35 PM, Gene Heskett wrote: > On Tuesday 16 January 2018 14:19:38 Larry Martell wrote: > >> On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell > wrote: >> > Looking for 2.7 docs on read.encode - googling did not turn up >> > anything. >> > >> > Specifically, looking for the

Re: documentation on read.encode

On Tuesday 16 January 2018 14:19:38 Larry Martell wrote: > On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell wrote: > > Looking for 2.7 docs on read.encode - googling did not turn up > > anything. > > > > Specifically, looking for the supported options for base64, and how > > to specify them, e.g.

Re: documentation on read.encode

On Tue, Jan 16, 2018 at 12:00 PM, Larry Martell wrote: > Looking for 2.7 docs on read.encode - googling did not turn up anything. > > Specifically, looking for the supported options for base64, and how to > specify them, e.g. Base64.NO_WRAP So I just realized that encode() is not a method of read

Re: Documentation of dict views change request

On 1/19/2014 4:41 PM, Mark Lawrence wrote: On 19/01/2014 21:26, Charles Hixson wrote: Could it please be clearly documented that keys(), values(), and items() are not writeable. I agree that this is how they should be, but it would be still better if they were clearly documented as such. The l

Re: Documentation of dict views change request

On Mon, Jan 20, 2014 at 8:40 AM, Roy Smith wrote: > In article , > Charles Hixson wrote: > >> Could it please be clearly documented that keys(), values(), and items() >> are not writeable. > > We'll, technically, they are. > > Of course, this only changes the list that keys() returns, it doesn't

Re: Documentation of dict views change request

In article , Charles Hixson wrote: > Could it please be clearly documented that keys(), values(), and items() > are not writeable. We'll, technically, they are. >>> d = {'foo': 1, 'bar':2} >>> k = d.keys() >>> k ['foo', 'bar'] >>> k[0] = "some other key" >>> k ['some other key', 'bar'] Of co

Re: Documentation of dict views change request

On 19/01/2014 21:26, Charles Hixson wrote: Could it please be clearly documented that keys(), values(), and items() are not writeable. I agree that this is how they should be, but it would be still better if they were clearly documented as such. The labeling of them as dynamic, while true, was

Re: Documentation, assignment in expression.

On 03/26/12 08:59, Thomas Rachel wrote: Am 25.03.2012 15:03 schrieb Tim Chase: while True: data = conn.fetchmany() if not data: break for row in data: process(row) Or simpler for data in iter(conn.fetchmany, []): for row in data: process(row) Nice! T

Re: Documentation, assignment in expression.

On 3/26/2012 1:36 AM, Steven D'Aprano wrote: (I seem to recall a language that used a single = for both assignment and equality testing, guessing which one you meant from context. BASIC perhaps? Right. In some Basics, such as MS GW-Basic (I still have their book), a = b = c meant a = (b = c),

Re: Documentation, assignment in expression.

Am 26.03.2012 00:59 schrieb Dennis Lee Bieber: If you use the longer form con = db.connect() cur = con.cursor() the cursor object, in all that I've worked with, does function for iteration I use this form regularly with MySQLdb and am now surprised to see that this is optional according to

Re: Documentation, assignment in expression.

Am 25.03.2012 15:03 schrieb Tim Chase: Perhaps a DB example works better. With assignment allowed in an evaluation, you'd be able to write while data = conn.fetchmany(): for row in data: process(row) whereas you have to write while True: data = conn.fetchmany() if not data:

Re: Documentation, assignment in expression.

On 3/26/2012 13:13, Jussi Piitulainen wrote: Kiuhnm writes: On 3/26/2012 10:52, Devin Jeanpierre wrote: On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm wrote: On 3/25/2012 15:48, Tim Chase wrote: The old curmudgeon in me likes the Pascal method of using "=" for equality-testing, and ":=" for ass

Re: Documentation, assignment in expression.

Dennis Lee Bieber wrote: > On Sun, 25 Mar 2012 19:09:12 -0400, mwil...@the-wire.com declaimed the > following in gmane.comp.python.general: > > >> Most of my database programs wind up having the boilerplate (not tested): >> >> def rowsof (cursor): >> names = [x[0] for x in cursor.descriptio

Re: Documentation, assignment in expression.

Kiuhnm writes: > On 3/26/2012 10:52, Devin Jeanpierre wrote: > > On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm > > wrote: > >> On 3/25/2012 15:48, Tim Chase wrote: > >>> > >>> The old curmudgeon in me likes the Pascal method of using "=" for > >>> equality-testing, and ":=" for assignment which feels

Re: Documentation, assignment in expression.

On 3/26/2012 10:52, Devin Jeanpierre wrote: On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm wrote: On 3/25/2012 15:48, Tim Chase wrote: The old curmudgeon in me likes the Pascal method of using "=" for equality-testing, and ":=" for assignment which feels a little closer to mathematical use of "=".

Re: Documentation, assignment in expression.

On 03/25/12 17:59, Dennis Lee Bieber wrote: On Sun, 25 Mar 2012 08:48:31 -0500, Tim Chase Yeah, it has the same structure internally, but I'm somewhat surprised that the DB connection object doesn't have an __iter__() that does something like this automatically under the covers. I beli

Re: Documentation, assignment in expression.

On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm wrote: > On 3/25/2012 15:48, Tim Chase wrote: >> >> The old curmudgeon in me likes the Pascal method of using "=" for >> equality-testing, and ":=" for assignment which feels a little closer to >> mathematical use of "=". > > > Unfortunately, ":=" means "is

Re: Documentation, assignment in expression.

On Sun, 25 Mar 2012 17:16:16 +0200, Kiuhnm wrote: > On 3/25/2012 15:48, Tim Chase wrote: >> The old curmudgeon in me likes the Pascal method of using "=" for >> equality-testing, and ":=" for assignment which feels a little closer >> to mathematical use of "=". > > Unfortunately, ":=" means "is d

Re: Documentation, assignment in expression.

On Sun, 25 Mar 2012 08:03:14 -0500, Tim Chase wrote: > I think the complaint was backed by a bad example. Perhaps a DB example > works better. With assignment allowed in an evaluation, you'd be able > to write > >while data = conn.fetchmany(): > for row in data: >process(row)

Re: Documentation, assignment in expression.

Tim Chase wrote: > On 03/25/12 08:11, Chris Angelico wrote: >> On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase >> wrote: >>> Granted, this can be turned into an iterator with a yield, making the >>> issue somewhat moot: >> >> No, just moving the issue to the iterator. Your iterator has exactly >> th

Re: Documentation, assignment in expression.

On 03/25/12 10:16, Kiuhnm wrote: On 3/25/2012 15:48, Tim Chase wrote: The old curmudgeon in me likes the Pascal method of using "=" for equality-testing, and ":=" for assignment which feels a little closer to mathematical use of "=". Unfortunately, ":=" means "is defined as" in mathematics. Th

Re: Documentation, assignment in expression.

On Mar 25, 6:48 pm, Tim Chase wrote: > > The old curmudgeon in me likes the Pascal method of using "=" for > equality-testing, and ":=" for assignment which feels a little > closer to mathematical use of "=". > > -tkc Carroll Morgan author of programming from specifications http://www.cs.ox.ac.uk

Re: Documentation, assignment in expression.

On 3/25/2012 15:48, Tim Chase wrote: The old curmudgeon in me likes the Pascal method of using "=" for equality-testing, and ":=" for assignment which feels a little closer to mathematical use of "=". Unfortunately, ":=" means "is defined as" in mathematics. The "right" operator would have bee

Re: Documentation, assignment in expression.

On 3/25/2012 16:11, Chris Angelico wrote: On Mon, Mar 26, 2012 at 12:48 AM, Tim Chase wrote: Yeah, it has the same structure internally, but I'm somewhat surprised that the DB connection object doesn't have an __iter__() that does something like this automatically under the covers. Sure. Tha

Re: Documentation, assignment in expression.

On Mon, Mar 26, 2012 at 12:48 AM, Tim Chase wrote: > Yeah, it has the same structure internally, but I'm somewhat surprised that > the DB connection object doesn't have an __iter__() that does something like > this automatically under the covers. Sure. That's definitely the truly Pythonic techniq

Re: Documentation, assignment in expression.

On 03/25/12 08:11, Chris Angelico wrote: On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase wrote: Granted, this can be turned into an iterator with a yield, making the issue somewhat moot: No, just moving the issue to the iterator. Your iterator has exactly the same structure in it. Yeah, it has

Re: Documentation, assignment in expression.

On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase wrote: > Granted, this can be turned into an iterator with a yield, making the issue > somewhat moot: No, just moving the issue to the iterator. Your iterator has exactly the same structure in it. Personally, I quite like assignment-in-conditional nota

Re: Documentation, assignment in expression.

On 03/25/12 07:18, Alexander Blinne wrote: I am not sure I understand your argument. The doc section states that " [...] in Python you’re forced to write this: while True: line = f.readline() if not line: break ... # do something with line". That simply isn't true as on

Re: Documentation, assignment in expression.

I am not sure I understand your argument. The doc section states that " [...] in Python you’re forced to write this: while True: line = f.readline() if not line: break ... # do something with line". That simply isn't true as one can simply write: for line in f: #do s

Re: Documentation, assignment in expression.

In article <4f6d0060$0$6634$9b4e6...@newsspool2.arcor-online.net>, Alexander Blinne wrote: > The last sentence "For example, in the current version of Python file > objects support the iterator protocol, so you can now write simply > (for line in file:)" ... In general, words like "current",

Re: Documentation for python-evolution - where?

On Tue, Dec 13, 2011 at 3:40 AM, wrote: > Actually I'm not sure if it's down to the docstrings because the help > available from Python itself stops (not unreasonably) at the interface > to the C library code.  What I was after (and you have told me where > it is) was the functions/methods availa

Re: Documentation for python-evolution - where?

Chris Angelico wrote: > On Mon, Dec 12, 2011 at 9:28 AM, wrote: > > I'm trying to use the python evolution (as in Gnome Evolution) module > > but I can't find any documetation beyond the odd trivial example and > > the API documentation at http://doc.conduit-project.org/evolution-python/ > > (or

Re: Documentation for python-evolution - where?

On Mon, Dec 12, 2011 at 9:28 AM, wrote: > I'm trying to use the python evolution (as in Gnome Evolution) module > but I can't find any documetation beyond the odd trivial example and > the API documentation at http://doc.conduit-project.org/evolution-python/ > (or similar places presumably). One

Re: Documentation using Sphinx

On 12/08/2011 02:09 PM, sajuptpm wrote: Hi, I am trying source code documentation using Sphinx. Here i have to copy paste all modules in to *.rst file, that is painful. Have any way to create documentation (doc for all modules, classes and methods in the project directory) from project folder qui

Re: re documentation bug?

On 08/03/2011 03:01, Tycho Andersen wrote: Consider the following session: Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. import re p = re.compile("foo") re.sub(p, "bar", "foobaz", flags=re.IGNORECASE

re documentation bug?

Consider the following session: Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> p = re.compile("foo") >>> re.sub(p, "bar", "foobaz", flags=re.IGNORECASE) Traceback (most recent call las

Re: documentation / reference help

On Jan 25, 2011 1:19 PM, "Craig Leffel" wrote: > > Where does it return the value to? > > What do I need to put in the calling function so that I can use that value? > I need a variable name to refer to. Shouldn't I have to define that variable > someplace? > Python functions are like mathematica

Re: documentation / reference help

Where does it return the value to? What do I need to put in the calling function so that I can use that value? I need a variable name to refer to. Shouldn't I have to define that variable someplace? "Littlefield, Tyler" wrote in message news:mailman.1103.1295811520.6505.python-l...@python.org...

Re: documentation / reference help

Scott Meup wrote: > I'm trying tolearn Python. The documentation tells syntax, and other > things > about a command. But for too many commands, it doesn't tell what it does. > for instance, in VB the 'return' command tells the program what line to > execute after some event (usually an error).

Re: documentation / reference help

On 1/23/2011 1:41 PM, Scott Meup wrote: I'm trying tolearn Python. The documentation tells syntax, and other things about a command. But for too many commands, it doesn't tell what it does. for instance, in VB the 'return' command tells the program what line to execute after some event (usually

Re: documentation / reference help

On Sun, Jan 23, 2011 at 11:52 AM, CM wrote: > On Jan 23, 2:38 pm, "Littlefield, Tyler" wrote: >> The return value simply returns a value to the calling function, which >> the function can handle, however it wants. so: for example >> def add(a, b): >>    return (a+b) >> >> That simply returns the

Re: documentation / reference help

On Jan 23, 2:38 pm, "Littlefield, Tyler" wrote: > The return value simply returns a value to the calling function, which > the function can handle, however it wants. so: for example > def add(a, b): >    return (a+b) > > That simply returns the value a+b, which you can use however you like, > like

Re: documentation / reference help

On 1/23/2011 10:41 AM Scott Meup said... I'm trying tolearn Python. The documentation tells syntax, and other things about a command. But for too many commands, it doesn't tell what it does. for instance, in VB the 'return' command tells the program what line to execute after some event (usuall

Re: documentation / reference help

The return value simply returns a value to the calling function, which the function can handle, however it wants. so: for example def add(a, b): return (a+b) That simply returns the value a+b, which you can use however you like, like so: i=add(2,3) will assign the return value to add. I rec

Re: documentation bug? (format spec mini language)

On 5/11/2010 5:05 PM, Terry Reedy wrote: http://bugs.python.org/issue8691 Thanks! Alan -- http://mail.python.org/mailman/listinfo/python-list

Re: documentation bug? (format spec mini language)

On 5/11/2010 3:19 PM, MRAB wrote: Alan G Isaac wrote: The documentation at http://docs.python.org/py3k/library/string.html#format-specification-mini-language '<' Forces the field to be left-aligned within the available space (This is the default.) The conflicting example:: >>> format(3.2,'10

Re: documentation bug? (format spec mini language)

On 5/11/2010 3:19 PM, MRAB wrote: You usually want numbers to be right-aligned so that the decimal points line up when writing a columns of them. Yes. I'm not questioning the wisdom of the implementation, just the documentation of it. Thanks, Alan -- http://mail.python.org/mailman/listinfo/

Re: documentation bug? (format spec mini language)

Alan G Isaac wrote: The documentation at http://docs.python.org/py3k/library/string.html#format-specification-mini-language '<' Forces the field to be left-aligned within the available space (This is the default.) The conflicting example:: >>> format(3.2,'10.5f') '

Re: Documentation bugs in 3.1 - C-API - TypeObjects

DreiJane wrote: > Thanks a second time - the picture has > gotten clearer indeed. But for third-party > readers the complexities of this matter > require the correction, that > > "Py_Type(&Foo_Type) = &PyType_Type" > > must be: > "Py_TYPE(&Foo_Type) = &PyType_Type " > > - or am i completely wron

Re: Documentation bugs in 3.1 - C-API - TypeObjects

> Still there remains the difference to what is told with the > Noddy_Type in the tutorial. Please report that to bugs.python.org. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list

Re: Documentation bugs in 3.1 - C-API - TypeObjects

Thanks a second time - the picture has gotten clearer indeed. But for third-party readers the complexities of this matter require the correction, that "Py_Type(&Foo_Type) = &PyType_Type" must be: "Py_TYPE(&Foo_Type) = &PyType_Type " - or am i completely wrong ? Joost -- http://mail.python.org/m

Re: Documentation bugs in 3.1 - C-API - TypeObjects

Thanks ! Okay, i've already used the call of tp_free as the last statement in tp_dealloc and do understand now, that a call of tp_dealloc should be the last statement in the code for tp_free in specific cases. And yes, "Py_Type(&Foo_Type) = &PyType_Type" will be more stable against changes of the

Re: Documentation bugs in 3.1 - C-API - TypeObjects

> This cannot work, because Foo_Type is no PyObject but a PyVarObject > (independent > of the use of PyVarObject_HEAD_INIT or PyObject_HEAD_INIT). The code > line would > work so: > > ((PyObject *)&Foo_Type)->ob_type = &PyType_Type However, this is not what you should use. Instead, use Py_Type(&

Re: Documentation of 2.x indicating what will be gone in 3.x?

On Oct 12, 8:21 pm, Peng Yu wrote: > Hi, > > I'm wondering if there is a document for 2.x indicating what will be > gone in 3.x. For example, I heard that __cmp__ be not available in > Python 3. But I don't see it > inhttp://docs.python.org/reference/datamodel.html. > > Regards, > Peng 'Dive int

Re: Documentation of 2.x indicating what will be gone in 3.x?

On Tue, 13 Oct 2009 01:21:17 +0100, Peng Yu wrote: Hi, I'm wondering if there is a document for 2.x indicating what will be gone in 3.x. For example, I heard that __cmp__ be not available in Python 3. But I don't see it in http://docs.python.org/reference/datamodel.html. Look in the "What's

Re: Documentation Problems

Inky 788 writes: > Could you please provide brief instructions on exactly how to go about > creating a suitable patch file? I mean, starting from the beginning > (as in, "check out code from {here} using {this command}", "cd to > {this} directory", "edit the file in place", "run {this} command to

Re: Documentation Problems

Inky 788 wrote: > On Jul 22, 7:15 am, Tim Golden wrote: >> Mark du Preez wrote: >>> Hi >>> Can anyone tell me where to go to suggest changes to the Python >>> documentation? >> Drop an entry in the tracker: >> >> http://bugs.python.org >> >> Patches are always welcome, > > Could you please provi

Re: Documentation Problems

Diez B. Roggisch wrote: Mark du Preez wrote: Hi Can anyone tell me where to go to suggest changes to the Python documentation? Thanks. http://docs.python.org/ has a "bugs"-section that leads to http://docs.python.org/bugs.html You can file doc-bugs in the tracker, and check if they are al

Re: Documentation Problems

On Jul 22, 7:15 am, Tim Golden wrote: > Mark du Preez wrote: > > Hi > > > Can anyone tell me where to go to suggest changes to the Python > > documentation? > > Drop an entry in the tracker: > >  http://bugs.python.org > > Patches are always welcome, Could you please provide brief instructions on

Re: Documentation Problems

Mark du Preez wrote: > Hi > > Can anyone tell me where to go to suggest changes to the Python > documentation? > > Thanks. http://docs.python.org/ has a "bugs"-section that leads to http://docs.python.org/bugs.html You can file doc-bugs in the tracker, and check if they are already fixed in t

Re: Documentation Problems

Mark du Preez wrote: Hi Can anyone tell me where to go to suggest changes to the Python documentation? Drop an entry in the tracker: http://bugs.python.org Patches are always welcome, or at least suggested wording rather than vague "I don't think it should say that" -- although that's bett

Re: documentation link for python 3.0.1 on python.org is broken

Brendan Miller wrote: Like the title says. but on which page? in any case, inform webmas...@python.org of specific site problems -- http://mail.python.org/mailman/listinfo/python-list

Re: documentation: what is "::="?

In message <[EMAIL PROTECTED]>, Anita Kean wrote: > I'm still curious about why isn't ["::="] documented ... It is . -- http://mail.python.org/mailman/listinfo/python-list

Re: documentation: what is "::="?

On 2008-10-14, Peter Otten <[EMAIL PROTECTED]> wrote: > Anita Kean wrote: >>... >> But for example, if I import the sys module and perform the following >> three commands, >> print sys.path >> sys.path.__str__() >> str(sys.path) >> >> the first two give me the python path, and the last reports an

Re: documentation: what is "::="?

In message <[EMAIL PROTECTED]>, Peter Otten wrote: > ... you have probably executed > > from locale import * > > This has imported the locale.str() function that now shadows the builtin > str(). One of many reasons not to use wildcard imports. :) -- http://mail.python.org/mailman/listinfo/pytho

Re: documentation: what is "::="?

Anita Kean wrote: > I'm guessing something like "if and only if" is implicated here? > But for example, if I import the sys module and perform the following > three commands, > print sys.path > sys.path.__str__() > str(sys.path) > > the first two give me the python path, and the last reports an e

Re: documentation: what is "::="?

Anita Kean wrote: 1) Everywhere in the old and new documentation, the string of characters "::=" is used in "explaining" things - but I can nowhere find any stated meaning of this string. Read Reference manual introductin notation: The descriptions of lexical analysis and syntax use a modifi

Re: documentation: what is "::="?

On Oct 13, 5:33 pm, Anita Kean <[EMAIL PROTECTED]> wrote: > Hello > > I just downloaded the new python2.6 documentation, > full of hopes it would solve some basic mysteries for me. > I'm new to python, so please forgive my ignorance. > I've two questions. > > 1) Everywhere in the old and new docum

Re: documentation: what is "::="?

Anita Kean schrieb: Hello I just downloaded the new python2.6 documentation, full of hopes it would solve some basic mysteries for me. I'm new to python, so please forgive my ignorance. I've two questions. 1) Everywhere in the old and new documentation, the string of characters "::=" is used i

Re: Q re documentation Python style

kj wrote: I'm a Perlhead trying to learn the Way of Python. I like Python overall, but every once in a while I find myself trying to figure out why Python does some things the way it does. At the moment I'm scratching my head over Python's docstrings. As far as I understand this is the standa

Re: Q re documentation Python style

Wow. That was a great bunch of advice. Thank you all very much! Kynn -- NOTE: In my address everything before the first period is backwards; and the last period, and everything after it, should be discarded. -- http://mail.python.org/mailman/listinfo/python-list

Re: Q re documentation Python style

kj: > I have some functions > that require a very long docstring to document, and somehow I find > it a bit disconcerting to stick a few screenfuls of text between > the top line of a function definition and its body. You may put the main function(s) documentation in the docstring of the module, a

Re: Q re documentation Python style

kj a écrit : (snip) I think that sometimes even simple functions require a lot of documentation. For example, I want to document a function that takes a dictionary as argument, and this dictionary is expected to have 5 keys. (When the number of mandatory arguments gets above 4, I find that it'

Re: Q re documentation Python style

On Jun 8, 2:17 pm, kj <[EMAIL PROTECTED]> wrote: > I'm a Perlhead trying to learn the Way of Python.  I like Python > overall, but every once in a while I find myself trying to figure > out why Python does some things the way it does.  At the moment > I'm scratching my head over Python's docstrings

Re: Q re documentation Python style

On Jun 8, 10:17 pm, kj <[EMAIL PROTECTED]> wrote: > I'm a Perlhead trying to learn the Way of Python. I like Python > overall, but every once in a while I find myself trying to figure > out why Python does some things the way it does. At the moment > I'm scratching my head over Python's docstring

Re: Q re documentation Python style

kj wrote: ... I want to document a function that takes a dictionary as argument, and this dictionary is expected to have 5 keys. When the number of mandatory > arguments gets above 4, I find that it's too difficult to remember > their order, so I resort to using a dictionary as the single argu

Re: Q re documentation Python style

On Jun 9, 7:17 am, kj <[EMAIL PROTECTED]> wrote: [snip] > For example, I want to document a function that > takes a dictionary as argument, and this dictionary is expected to > have 5 keys. (When the number of mandatory arguments gets above > 4, I find that it's too difficult to remember their or

Re: Q re documentation Python style

On Jun 8, 5:17 pm, kj <[EMAIL PROTECTED]> wrote: > I'm a Perlhead trying to learn the Way of Python. Welcome to the light, my son. > I guess this is a rambling way to ask: are docstrings *it* as far > Python documentation goes? Or is there a second, more flexible > system? You can define a de

Re: Q re documentation Python style

On Sun, Jun 8, 2008 at 2:17 PM, kj <[EMAIL PROTECTED]> wrote: > > > I'm a Perlhead trying to learn the Way of Python. I like Python > overall, but every once in a while I find myself trying to figure > out why Python does some things the way it does. At the moment > I'm scratching my head over P

Re: Q re documentation Python style

I guess this is a rambling way to ask: are docstrings *it* as far Python documentation goes? Or is there a second, more flexible system? Docstrings are it. Yet there are several ways how their content is interpreted. Google for example epydoc. You can embed links that way. I don't know perl,

Q re documentation Python style

I'm a Perlhead trying to learn the Way of Python. I like Python overall, but every once in a while I find myself trying to figure out why Python does some things the way it does. At the moment I'm scratching my head over Python's docstrings. As far as I understand this is the standard way to d

Re: Documentation - which format

[EMAIL PROTECTED] wrote: > Definitely ReST. See http://rst2a.com/ > Hey, this is sweet! Thanks for that. /W -- http://mail.python.org/mailman/listinfo/python-list

Re: Documentation - which format

Ben Finney wrote: > Yes, TTBOMK. The site hasn't been updated for a while, but I follow > the mailing list and activity continues on the code itself. Python 2.6 and newer are using reST for documentation, see http://docs.python.org/dev/ Christian -- http://mail.python.org/mailman/listinfo/pyth

Re: Documentation - which format

On Feb 26, 11:47 pm, Jumping Arne <[EMAIL PROTECTED]> wrote: > I'm considering using plain text file for documenting certain things (nothing > to do with Python) and I'm looking at different "formatting systems" ... > preferable with a python implementation to render the text at least as HTML - > p

Re: Documentation - which format

Jumping Arne <[EMAIL PROTECTED]> writes: > On Wed, 27 Feb 2008 05:51:11 +0100, Ben Finney wrote > (in article <[EMAIL PROTECTED]>): > > > Your needs are met amply with reStructuredText. It's still under > > active development > > is http://docutils.sourceforge.net/ still the official site (I > d

  1   2   3   >