Chris Green wrote at 2023-10-28 17:08 +0100:
>I am using the python3 smbus module, but it's hard work because of the
>lack of documentation. Web searches confirm that the documentation is
>somewhat thin!
>
>If you do the obvious this is what you get:-
>
>>>&g
Dan Purgert wrote:
> On 2023-10-28, Chris Green wrote:
> > I am using the python3 smbus module, but it's hard work because of the
> > lack of documentation. Web searches confirm that the documentation is
> > somewhat thin!
> >
>
> The SMBus spec is availa
Il Sat, 28 Oct 2023 17:08:00 +0100, Chris Green ha scritto:
> I am using the python3 smbus module, but it's hard work because of the
> lack of documentation. Web searches confirm that the documentation is
> somewhat thin!
>
> If you do the obvious this is what you get:-
km wrote:
> Il Sat, 28 Oct 2023 17:08:00 +0100, Chris Green ha scritto:
>
> > I am using the python3 smbus module, but it's hard work because of the
> > lack of documentation. Web searches confirm that the documentation is
> > somewhat thin!
> >
> > I
I am using the python3 smbus module, but it's hard work because of the
lack of documentation. Web searches confirm that the documentation is
somewhat thin!
If you do the obvious this is what you get:-
>>> import smbus
>>> dir (smbus)
['SMBus', &
E
> On 3 Sep 2023, at 22:49, Chris Green via Python-list
> wrote:
>
> Mostly I am managing to get things to work as I want but better
> documentation of gpiod would be a great help.
Ask the author? https://github.com/aswild/python-gpiod
Maybe read the source code for hints?
I am using the gpiod package for manipulating GPIO inputs/outputs on a
Beaglebone Black SBC (like a Raspberry Pi but with more flexible I/O).
Mostly I am managing to get things to work as I want but better
documentation of gpiod would be a great help.
For example, when one has found an I/O pin
def construct_response(exit_code: int, message: str) -> Response:
>> """
>> Construct a Flask-suitable response
>>
>> :param exit_code: 0 or something else
>> :param message: something useful
>> :return: a Flask-suitable response
>> """
>>
>>
>> @app.route(f"/{version}/", me
And I can answer my own Question 2:
:func:`my_project.main_application.construct_response`
On Mon, Aug 28, 2023 at 1:39 PM Jason Friedman wrote:
> def construct_response(exit_code: int, message: str) -> Response:
>> """
>> Construct a Flask-suitable response
>>
>> :param exit_code: 0
>
> def construct_response(exit_code: int, message: str) -> Response:
> """
> Construct a Flask-suitable response
>
> :param exit_code: 0 or something else
> :param message: something useful
> :return: a Flask-suitable response
> """
>
>
> @app.route(f"/{version}/", methods=
I have two questions, please (this is after reading
https://docs.readthedocs.io/en/stable/guides/cross-referencing-with-sphinx.html#automatically-label-sections
).
This is my project structure:
my_project
api
stuff1.py
stuff2.py
lib
stuff3.py
stuff4.py
main_application.py
On Thu, 12 Jan 2023 at 21:25, Stephen Tucker wrote:
>
> Chris,
>
> Thanks for this clarification.
>
> I have not found documentation that disagrees with you. I simply observe that
> the documentation that I have alluded to earlier in this chain (section 5.9
> File Objec
Chris,
Thanks for this clarification.
I have not found documentation that disagrees with you. I simply observe
that the documentation that I have alluded to earlier in this chain
(section 5.9 File Objects) could have been made clearer by the addition of
a note along the lines that the behaviour
Chris Angelico schreef op 11/01/2023 om 18:36:
On Thu, 12 Jan 2023 at 04:31, Stephen Tucker wrote:
> 1. Create BOM.txt
> 2. Input three bytes at once from BOM.txt and print them
> 3. Input three bytes one at a time from BOM.txt and print them
All of these correctly show that a file, in binary m
>
> >>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
> >>> myBOM_4 = myfil.read (1)
> >>> myBOM_4
> u'\ufeff'
> A. The attempt at Part 5 actually inputs all three bytes when we ask it to
> inpu
at, actually, the request to input text
in Part 4 brought about a response from the program something like this:
Input the UTF-8-encoded character as the first "byte";
As expected, after reaching the end of the file, continue supplying an
empty string for each of the requested extra bytes
On Wed, 11 Jan 2023 at 21:31, Stephen Tucker wrote:
>
> Chris -
>
> In the Python 2.7.10 documentation, I am referring to section 5. Built-in
> Types, subsection 5.9 File Objects.
>
> In that subsection, I have the following paragraph:
>
> file.read([size])
>
>
Chris -
In the Python 2.7.10 documentation, I am referring to section 5. Built-in
Types, subsection 5.9 File Objects.
In that subsection, I have the following paragraph:
file.read([*size*])
Read at most *size* bytes from the file (less if the read hits EOF before
obtaining *size* bytes). If
On Tue, 10 Jan 2023 at 01:36, Stephen Tucker wrote:
>
> Dear Python-list,
>
> Yes, I know that Python 2.x is no longer supported.
>
> I have found that the documentation for this method is misleading when the
> file being read is UTF-8-encoded:
>
>Instead of readi
On 09/01/2023 14:34, Stephen Tucker wrote:
Dear Python-list,
Yes, I know that Python 2.x is no longer supported.
I have found that the documentation for this method is misleading when the
file being read is UTF-8-encoded:
Instead of reading *size* bytes, the method reads *size *UTF-8
Dear Python-list,
Yes, I know that Python 2.x is no longer supported.
I have found that the documentation for this method is misleading when the
file being read is UTF-8-encoded:
Instead of reading *size* bytes, the method reads *size *UTF-8 byte
*sequences*.
Has this error been corrected
Hi Python Team,
I think the statement "The __init__.py files are required to make Python
treat directories containing the file as packages" is wrong in the
documentation[1] because it is valid only for Python 2.x version not Python
3.x version.
Even though it is good practice to have
On 2021-04-28 08:16:19 -0700, elas tica wrote:
> Peter J. Holzer a écrit :
> > > Is the "is not" operator a token?
> > Yes. See chapter 2.3.1.
Sorry. I obviously read what I expected to read here, not what you
actually wrote. "is not" ist of course not a token. It is two tokens:
"is" and "not". H
> > the docs are wrong when they say:
> >
> > ..
> > using a backslash). A backslash is illegal elsewhere on a line outside a
> > string literal.
> > ..
> >
> You're not passing a backslash. Try print(s).
> It would be
Am 29.04.21 um 08:54 schrieb elas tica:
Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
In what sense of the word "token" are you asking? The parser? You can
play around with the low-level tokenizer with the aptly-named
tokenizer module.
It was a good suggestion, and the
On Wed, 28 Apr 2021 at 22:18, Dennis Lee Bieber wrote:
> The old range() returned a list, and said list could (in your example)
> contain 42. The current range() (equivalent to former xrange() ) is not a
> container as retrieving values consumes them from the range.
A nitpick -- retrievi
On Thu, Apr 29, 2021 at 4:56 PM elas tica wrote:
>
> Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
>
> > In what sense of the word "token" are you asking? The parser? You can
> > play around with the low-level tokenizer with the aptly-named
> > tokenizer module.
>
> It was a
Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
> In what sense of the word "token" are you asking? The parser? You can
> play around with the low-level tokenizer with the aptly-named
> tokenizer module.
It was a good suggestion, and the PLR doesn't mention the tokeniser m
On Thu, Apr 29, 2021 at 5:16 AM elas tica wrote:
>
>
> Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
>
> > > if a string or a range object is a container or not. For instance,
> > > can we say that range(100) contains 42 ?
> > Not by that definition of container.
>
> Which d
Le mercredi 28 avril 2021 à 17:36:32 UTC+2, Chris Angelico a écrit :
> > if a string or a range object is a container or not. For instance,
> > can we say that range(100) contains 42 ?
> Not by that definition of container.
Which definition? ;)
> some objects have references to other object
On Thu, Apr 29, 2021 at 1:21 AM elas tica wrote:
>
> Peter J. Holzer a écrit :
>
> > That's why it's called a container. But it also says *what* an object
> > must contain to be called a container. You could say that an int object
> > contains an integer value and a str object contains a reference
Peter J. Holzer a écrit :
> That's why it's called a container. But it also says *what* an object
> must contain to be called a container. You could say that an int object
> contains an integer value and a str object contains a reference to a
> buffer containing the string - but those aren't re
On 2021-04-27 06:42:38 -0700, elas tica wrote:
> > The *Language Reference* is designed to be much more formally defined, and
> > favors correctness and completeness over being easy to access by less
> > technical readers.
> >
>
>
> Not really my opinion. Language Reference (LR) style is stil
Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit :
> From
> https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
>
> :
>
> > The string representations of the numeric classes, computed
> > by__repr__() and __str__(), have the following properties:
> > * T
he problem is that the documentation doesn't define what the value of an
object is, what means changing the value. The documentation doesn't explain
**how** mutability is determined by the type of the object.
By the way, how the docs define a container? Answer: "Some objects
ontains info that cover
90% of use-cases and questions. (note built-in types are a section in the
library reference, despite being built-in to the interpreter and not really
part of the standard library, but this makes sense if you consider the
library reference to be more 'friendly' docu
On Tue, Apr 27, 2021 at 9:51 PM elas tica wrote:
>
>
> > However, in this case, the general information in the docs is
> > absolutely sufficient, and the basic principle that the repr should
> > (where possible) be a valid literal should explain what's needed.
>
>
> This is a subjective statement.
> However, in this case, the general information in the docs is
> absolutely sufficient, and the basic principle that the repr should
> (where possible) be a valid literal should explain what's needed.
This is a subjective statement. Recall: explicit is better implicit. Alas, many
parts of
On Tue, Apr 27, 2021 at 6:11 PM elas tica wrote:
>
>
> > Python has this thing called interactive mode that makes it possible to
> > discover answers even faster than looking in the docs
>
> To go further :
> Python has this thing called source code that makes it possible to discover
> answers ev
> Python has this thing called interactive mode that makes it possible to
> discover answers even faster than looking in the docs
To go further :
Python has this thing called source code that makes it possible to discover
answers even faster than looking in the docs
--
https://mail.python.
from the PSL documentation. The representation returned
by str over a complex number is not stated. The same for fraction objects. All
the docstrinds are meaningless, showing :
Try ...
>>> help(int)
and any other built-in type
__str__(self)
str(self)
(END)
not very in
On 4/26/2021 7:24 PM, elas tica wrote:
Python documentation doesn't seem to mention anywhere what is the str value of an int: is it right? the same
for float, Fraction, complex, etc? Not worth to be documented? Perphaps str(42) returns "forty two"
or "XLII" or "
> From
> > https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
> >
> > :
> >
>
>
> Thanks for the reference. I was expecting to find this information in
> the Built-in Types section from the PSL documentation. The
> representat
On 2021-04-26 at 18:24:18 -0700,
elas tica wrote:
> [...] I was expecting to find [a description of what str returns for
> various types] in the Built-in Types section from the PSL
> documentation. The representation returned by str over a complex
> number is not stated. The same
Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit :
> From
> https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
>
> :
>
Thanks for the reference. I was expecting to find this information in the
Built-in Types section from the PSL doc
after a
>decimal point, are not shown.
> * A sign is shown only when the number is negative.
Paul
On Mon, 2021-04-26 at 16:24 -0700, elas tica wrote:
>
> Python documentation doesn't seem to mention anywhere what is the str
> value of an int: is it right? the same for f
Python documentation doesn't seem to mention anywhere what is the str value of
an int: is it right? the same for float, Fraction, complex, etc? Not worth to
be documented? Perphaps str(42) returns "forty two" or "XLII" or "101010" ...
--
https://mail.python.org/mailman/listinfo/python-list
reconsider?
Oops. You weren't ever asking for help. My bad.
However there was understandable push back to documenting and promoting
an obsolete distribution of Python 2 (and Qt4 no less!) to new users.
Definitely not something the documentation should be doing.
--
https://mail.python.org/m
On 3/27/21 1:02 PM, pyt...@blackward.eu wrote:
> You say: "The point is that there are those who use Python 2 and
> don't want to move to Python 3, claiming that it's easier to switch
> from Python 2 to some other language than from Python 2 to Python 3.
> That's what seems questionable." And I say
On 27/03/2021 06:20, pyt...@blackward.eu wrote:
Chris,
you seem to imply, that I have compiled said versions without reason
and that the same would be possible on basis of Python 3 - which is
simply not true. Maybe you are not enough acquainted with Qt and
belonging libraries alike PyQtGraph.
On 3/27/2021 1:20 AM, pyt...@blackward.eu wrote:
By the way, some months ago I started trying to migrate to Python 3 and
gave up in favor of creating said compilation.
Why? What was biggest roadblock?
Compatibility of Python and its Packages decreased with V3 significantly.
I don't believ
On 2021-03-27, MRAB wrote:
> On 2021-03-27 17:03, pyt...@blackward.eu wrote:
>> You write, that "Everyone claims that it's easier to move to some other
>> language rather than to migrate to Python 3".
>>
>> Thank you for sharing this remarkable information!
>
> You've quoted him partially and inc
I would like to suggest adding "Blythooon" to the list under "Other
parties have re-packaged CPython" listed here:
https://www.python.org/download/alternatives/
Your title is misleading because you are proposing a change to a
python.org website page, not the 'Pyt
I answered your actual question, in your original post, separately. But
by posting here, and continuing to respond, you implicitly invited
extended discussion with questions and opinions.
On 3/26/2021 11:15 PM, pyt...@blackward.eu wrote:
in response to Chris Angelico, a long-time python-list
On Sun, Mar 28, 2021 at 7:46 AM Avi Gross via Python-list
wrote:
>
> What are the odds, Chris, that rewriting an existing project written in an
> older version of a language like python FROM SCRATCH into any other existing
> language, would be easier than updating it to the same language which mad
wishes but not free to force others to
help him when it is not in their interest.
-Original Message-
From: Python-list On
Behalf Of Chris Angelico
Sent: Saturday, March 27, 2021 1:37 AM
To: Python
Subject: Re: python documentation
On Sat, Mar 27, 2021 at 4:20 PM wrote:
>
> Chris,
&
On 2021-03-27 19:02, pyt...@blackward.eu wrote:
You say: "The point is that there are those who use Python 2 and don't
want to move to Python 3, claiming that it's easier to switch from
Python 2 to some other language than from Python 2 to Python 3. That's
what seems questionable."
And I say, fo
You say: "The point is that there are those who use Python 2 and don't
want to move to Python 3, claiming that it's easier to switch from
Python 2 to some other language than from Python 2 to Python 3. That's
what seems questionable."
And I say, forcing people to do things they do not want to
On 2021-03-27 17:03, pyt...@blackward.eu wrote:
You write, that "Everyone claims that it's easier to move to some other
language rather than to migrate to Python 3".
Thank you for sharing this remarkable information!
You've quoted him partially and incorrectly. He said "Everyone claims
that it
On Sun, Mar 28, 2021 at 4:03 AM wrote:
>
> You write, that "Everyone claims that it's easier to move to some other
> language rather than to migrate to Python 3".
>
> Thank you for sharing this remarkable information!
>
Yep. Plenty of people have claimed that. And guess what? They mostly
end up d
On Sat, Mar 27, 2021 at 9:56 AM wrote:
> May I ask, do you have any knowledge or even experience about if resp.
> how good Tauthon and Pypy2 works together with Qt 4.8?
>
I've never used Qt. I do my GUI's with PyGOBject.
I've moved all of my personal code that I care about from Python 2.x to
3
You write, that "Everyone claims that it's easier to move to some other
language rather than to migrate to Python 3".
Thank you for sharing this remarkable information!
On 2021-03-27 06:36, Chris Angelico wrote:
On Sat, Mar 27, 2021 at 4:20 PM wrote:
Chris,
you seem to imply, that I ha
Hi Dan,
thank you very much for your kind hints - quite interesting idea to have
a more detailed look into this direction!
By the way, your response was the very first here, which I consider to
have a constructive notion; at least I did not felt very welcome here by
Chris until yet...
In
On Sat, Mar 27, 2021 at 5:01 PM Dan Stromberg wrote:
>
> On Fri, Mar 26, 2021 at 10:37 PM Chris Angelico wrote:
>>
>> On Sat, Mar 27, 2021 at 4:20 PM wrote:
>> > By the way, some months ago I started trying to migrate to Python 3 and
>> > gave up in favor of creating said compilation. Compatibil
On Fri, Mar 26, 2021 at 10:37 PM Chris Angelico wrote:
> On Sat, Mar 27, 2021 at 4:20 PM wrote:
> > By the way, some months ago I started trying to migrate to Python 3 and
> > gave up in favor of creating said compilation. Compatibility of Python
> > and its Packages decreased with V3 significan
On Sat, Mar 27, 2021 at 4:20 PM wrote:
>
> Chris,
>
> you seem to imply, that I have compiled said versions without reason and
> that the same would be possible on basis of Python 3 - which is simply
> not true. Maybe you are not enough acquainted with Qt and belonging
> libraries alike PyQtGraph.
Chris,
you seem to imply, that I have compiled said versions without reason and
that the same would be possible on basis of Python 3 - which is simply
not true. Maybe you are not enough acquainted with Qt and belonging
libraries alike PyQtGraph. Maybe you are just not willing to see /
accept
On 2021-03-27 03:44, Chris Angelico wrote:
On Sat, Mar 27, 2021 at 2:15 PM wrote:
[snip]
By the way, there is more, Blythooon offers beyond what I already have
written in the last email. Otherwise please name me another comparable
MINIMAL 'distribution', which is compiled specifically for sc
On Sat, Mar 27, 2021 at 2:15 PM wrote:
>
> No, I am not encouraging, I am just offering the possibility.
>
> Python and its community once was not dogmatic. At least this was my
> impression when I started - after all Python originally had been
> designed to be multi paradigmatic. This spirit of f
No, I am not encouraging, I am just offering the possibility.
Python and its community once was not dogmatic. At least this was my
impression when I started - after all Python originally had been
designed to be multi paradigmatic. This spirit of freedom was one mayor
reason for Python to grow
On Sat, Mar 27, 2021 at 7:49 AM wrote:
>
> Hi Chris,
>
>
> thank you for your interest and thanks for asking.
>
>
> Blythooon is notable due to several reasons; let's compare it with some
> of the already listed (and thus obviously notable) 'distributions':
>
> 2) winpython seems not to support Py
Sorry, copy & paste obviously failed, here is the link I wanted to
include:
https://www.anaconda.com/terms-of-service
On 2021-03-26 17:33, Chris Angelico wrote:
On Sat, Mar 27, 2021 at 3:31 AM wrote:
Howdy Folks,
I would like to suggest adding "Blythooon" to the list under "Other
partie
Hi Chris,
thank you for your interest and thanks for asking.
Blythooon is notable due to several reasons; let's compare it with some
of the already listed (and thus obviously notable) 'distributions':
1) pythonxy seems not to be maintained anymore - the last version I
found is from 2015.
On Sat, Mar 27, 2021 at 3:31 AM wrote:
>
> Howdy Folks,
>
>
> I would like to suggest adding "Blythooon" to the list under "Other
> parties have re-packaged CPython" listed here:
>
What makes it notable?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Howdy Folks,
I would like to suggest adding "Blythooon" to the list under "Other
parties have re-packaged CPython" listed here:
https://www.python.org/download/alternatives/
Blythooon can be found here:
https://pypi.org/project/blythooon/
and the belonging installation step-by-step-guid
On 05/18/2020 09:46 AM, Kale Kundert wrote:
I'm writing to share a Sphinx plugin I wrote, which I think makes the
documentation for large classes much easier to navigate and understand. The
plugin is called `autoclasstoc` and you can find the documentation here:
I'm writing to share a Sphinx plugin I wrote, which I think makes the
documentation for large classes much easier to navigate and understand. The
plugin is called `autoclasstoc` and you can find the documentation here:
https://autoclasstoc.readthedocs.io/en/latest/
I wrote this plugin be
Might be your wish!!! If that is not the fault of the devs then I think
issuing in GitHub wont help.
Souvik flutter dev
On Fri, Apr 10, 2020, 5:10 PM Sanjay Gupta wrote:
> Hi Everyone,
> I recently started working on Data Visualization. In one of my
> assignments, I want to use PyValentina 0.2.
Hi Everyone,
I recently started working on Data Visualization. In one of my assignments, I
want to use PyValentina 0.2.0 library. When I visited the
https://pypi.org/project/PyValentina/
page and click on PyValentina Home Page link it give me a 404 error. After
spending a little more time I come
hashable.
If I do not intend my class to be hashable, I will set __hash__ to None
(according to the documentation).
If you define your own __eq__ method, __hash__ is automatically set to None.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
ing to override the default
> __hash__ with something that will only raise an exception when you do not
> intend your class to be hashable.
If I do not intend my class to be hashable, I will set __hash__ to None
(according to the documentation).
--
https://mail.python.org/mailman/listinfo/python-list
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
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
The default __eq__ method (object identity) is compatible with all (reasonable)
self-defined __hash__ method.
Stefan
--
https://mail.python.org/mailman/listinfo/python-list
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
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
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__()
><https://docs.python.org/3/reference/datamodel.html#obje
Hi,
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__()
<https://docs.python.org/3/reference/datamodel.html#object.__eq__> method it
should not define a __hash_
On Wed, Feb 13, 2019 at 6:18 AM Peter J. Holzer wrote:
>
> On 2019-02-12 07:31:54 +1100, Chris Angelico wrote:
> > Positional arguments with defaults is a concept known in MANY
> > languages,
>
> True.
>
> > including C.
>
> Nope. At least not until C99, and I can't find anything in C11 either.
>
On 2019-02-12 07:31:54 +1100, Chris Angelico wrote:
> Positional arguments with defaults is a concept known in MANY
> languages,
True.
> including C.
Nope. At least not until C99, and I can't find anything in C11 either.
Maybe they'll add it in C2x.
hp
--
_ | Peter J. Holzer|
On Tue, Feb 12, 2019 at 8:13 AM Avi Gross wrote:
>
>
> Just Chris,
Can we keep things on the list please?
> I am thinking I missed the point of this discussion thus what I say makes no
> sense.
Not sure. You were fairly specific with your statements about how
things supposedly were in the past.
On Mon, Feb 11, 2019 at 1:56 PM boB Stepp wrote:
>
> On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico wrote:
>
> > Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> > here, but I strongly suspect that positional arguments with defaults
> > go back all the way to 1.x.
>
> Has
On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico wrote:
> Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> here, but I strongly suspect that positional arguments with defaults
> go back all the way to 1.x.
Has Steve's banishment ended yet? The only postings I have recently
ect that positional arguments with defaults
> go back all the way to 1.x.
The archived documentation shows that both parameter defaults and
keyword arguments have been around since at least 1.4. I can't
directly confirm that required parameters could be passed by keyword,
but I see nothing in t
On Tue, Feb 12, 2019 at 7:26 AM Avi Gross wrote:
> If you want to talk about recent or planned changes, fine. But make that
> clear. I was talking about how in the past positional arguments did not have
> defaults available at the def statement level. I was talking about how use
> of the symbol "=
Ian,
Again, not having read whatever documentation we may be discussing, I may be
very wrong.
The topic is the C API. I started using C at Bell Laboratories in 1982
replacing other languages I had used before. I haven't felt a reason to use
it in the last few decades as I moved on to yet
absence
of the changes needed to make new functionality possible.
So let me make sure I understood you. We are talking about the function
prototype as in def fun(...) and perhaps the lambda equivalent. The user of
the function would only see changes in the help files or other documentation
but no
ering or maybe
even implementing and in what ways it may not be compatible with present
functionality.
-Original Message-
From: Python-list On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python
Subject: Re: The slash "/" as used in the documentation
On Sun
On 2/11/2019 2:47 AM, Ian Kelly wrote:
For math.sin, sure, but what about, say, list.index?
Special-case conversion is a different issue from blanket conversion.
Some C functions have been converted to accept some or all args by
keyword. I don't know the status of list method conversion: dis
On Mon, Feb 11, 2019 at 6:51 PM Terry Reedy wrote:
> > and not normally accessible to pure Python functions without
> > some arm twisting.
>
> In my first response on this thread I explained and demonstrated how to
> access signature strings from Python, as done by both help() and IDLE.
> Please r
1 - 100 of 1764 matches
Mail list logo
