Re: Python Package documentation error
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 this file, it is not mandatory to have in Python 3x. to treat directories as packages. So I think we should correct it. [1] https://docs.python.org/3/tutorial/modules.html?highlight=packages#packages Thanks, Krishna On Fri, Sep 3, 2021 at 10:13 AM Krishna wrote: > 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 this file, it is not mandatory to > have in Python 3x. to treat directories as packages. So I think we should > correct it. > > [1] > https://docs.python.org/3/tutorial/modules.html?highlight=packages#packages > > Thanks, > Krishna > -- https://mail.python.org/mailman/listinfo/python-list
Re: Event loop documentation error
On 7/21/2014 2:38 PM, Yaşar Arabacı wrote: I was reading https://docs.python.org/3/library/asyncio-eventloop.html#example-set-signal-handlers-for-sigint-and-sigterm and wanted to test the example, With 3.4.0, 3.4.1, or 3.5.0a0 in the repository (available to view at hg.python.org, I believe)? Asyncio is patched at least once a week You can access the latest version of the 3.5 docs online (see the box in upper left corner) also to check how the example is written today. however, I am getting this error when I run the code; Traceback (most recent call last): File "C:/Users/gorki/Documents/Python Scripts/as-io.py", line 14, in loop.add_signal_handler(SIGINT, partial(ask_exit, "SIGINT")) File "C:\Python34\lib\asyncio\events.py", line 329, in add_signal_handler raise NotImplementedError NotImplementedError I was wondering if there is something I am doing wrong, or is this behaviour platform specific (I am on windows 7). I wanted to ask in the list before I file a bug report. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Event loop documentation error
On Tue, Jul 22, 2014 at 5:15 AM, Mark Lawrence wrote: > On 21/07/2014 20:00, Chris Angelico wrote: >> >> On Tue, Jul 22, 2014 at 4:55 AM, Yaşar Arabacı >> wrote: >>> >>> After reading the next page of the documentation, I realized that >>> "add_signal_handler() and remove_signal_handler() are not supported" >>> on Windows. Moreover, dev3.5 version of the docs are also saying that >>> they are not supported, so I think they are not planning to supports >>> those features on Windows anytime soon. >> >> >> If I had to guess, I would say that the reason there's no Windows >> Ctrl-C handler would simply be that nobody's yet volunteered to write >> one. So you might be in a position to add what you want to 3.5 :) >> >> ChrisA >> > > I'd check the bug tracker before doing anything. It's perfectly possible > that somebody has already done this but the patch hasn't been reviewed yet. Or that, yes. My point is, I doubt there's a strong philosophical reason for there to be a lack of support, but merely that it hasn't been done yet. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Event loop documentation error
On 21/07/2014 20:00, Chris Angelico wrote: On Tue, Jul 22, 2014 at 4:55 AM, Yaşar Arabacı wrote: After reading the next page of the documentation, I realized that "add_signal_handler() and remove_signal_handler() are not supported" on Windows. Moreover, dev3.5 version of the docs are also saying that they are not supported, so I think they are not planning to supports those features on Windows anytime soon. If I had to guess, I would say that the reason there's no Windows Ctrl-C handler would simply be that nobody's yet volunteered to write one. So you might be in a position to add what you want to 3.5 :) ChrisA I'd check the bug tracker before doing anything. It's perfectly possible that somebody has already done this but the patch hasn't been reviewed yet. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Event loop documentation error
On Tue, Jul 22, 2014 at 4:55 AM, Yaşar Arabacı wrote: > After reading the next page of the documentation, I realized that > "add_signal_handler() and remove_signal_handler() are not supported" > on Windows. Moreover, dev3.5 version of the docs are also saying that > they are not supported, so I think they are not planning to supports > those features on Windows anytime soon. If I had to guess, I would say that the reason there's no Windows Ctrl-C handler would simply be that nobody's yet volunteered to write one. So you might be in a position to add what you want to 3.5 :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Event loop documentation error
-- Forwarded message -- From: Yaşar Arabacı Date: 2014-07-21 21:54 GMT+03:00 Subject: Re: Event loop documentation error To: Chris Angelico 2014-07-21 21:45 GMT+03:00 Chris Angelico : > SIGINT is a Unix signal. There is an equivalent for Windows, but it > wouldn't at all surprise me if trying to hook signals raises > NotImplementedError. See if there's a different way to hook Ctrl-C on > Windows; if not, you may want to word your report as a feature > request. > > ChrisA After reading the next page of the documentation, I realized that "add_signal_handler() and remove_signal_handler() are not supported" on Windows. Moreover, dev3.5 version of the docs are also saying that they are not supported, so I think they are not planning to supports those features on Windows anytime soon. In that case, should I make a bug report on docs that it should be mentioned on example that this feature is not supported on Windows. As for the feature request, I think there is a good reason that they didn't include it already. I will try to look into it, before making a feature request. -- http://ysar.net/ -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Event loop documentation error
On Tue, Jul 22, 2014 at 4:38 AM, Yaşar Arabacı wrote: > Traceback (most recent call last): > File "C:/Users/gorki/Documents/Python Scripts/as-io.py", line 14, in > > loop.add_signal_handler(SIGINT, partial(ask_exit, "SIGINT")) > File "C:\Python34\lib\asyncio\events.py", line 329, in add_signal_handler > raise NotImplementedError > NotImplementedError > > I was wondering if there is something I am doing wrong, or is this > behaviour platform specific (I am on windows 7). I wanted to ask in > the list before I file a bug report. SIGINT is a Unix signal. There is an equivalent for Windows, but it wouldn't at all surprise me if trying to hook signals raises NotImplementedError. See if there's a different way to hook Ctrl-C on Windows; if not, you may want to word your report as a feature request. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Event loop documentation error
I was reading https://docs.python.org/3/library/asyncio-eventloop.html#example-set-signal-handlers-for-sigint-and-sigterm and wanted to test the example, however, I am getting this error when I run the code; Traceback (most recent call last): File "C:/Users/gorki/Documents/Python Scripts/as-io.py", line 14, in loop.add_signal_handler(SIGINT, partial(ask_exit, "SIGINT")) File "C:\Python34\lib\asyncio\events.py", line 329, in add_signal_handler raise NotImplementedError NotImplementedError I was wondering if there is something I am doing wrong, or is this behaviour platform specific (I am on windows 7). I wanted to ask in the list before I file a bug report. -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: using strings from extension module question + possible documentation error
On Dec 24, 4:42 pm, Stefan Sonnenberg-Carstens wrote: > You could as an alternative just use byte arrays. These are changeable. thanks, that's exactly what I need. I have completely missed those things since they're pretty new. -- http://mail.python.org/mailman/listinfo/python-list
Re: using strings from extension module question + possible documentation error
Am 24.12.2010 13:31, schrieb Oleg Leschov: Hi, I am writing an extension module in which I want to do some heavy number crunching on large amount of data. The input data is prepared using Python code and passed to this extension module via strings containing binary data, and the result is also passed back as a list of pretty large strings containing binary data. So first I thought I'll just pass the empty strings made in Python along with input data strings, so my extension code would just fill those empty strings with the results. But then I read the PyString docs, it says I must not modify any strings even though it seems to be possible... strings are immutable. If you pass a string and the underlying C module changes it's contents, this idiom is broken. The source for endless pain ... Ok then I decided I'll create a list and fill it with strings from my C extension code.. However to avoid data copying I wish to fill the newly created (using PyString_FromString(NULL,x) ) strings' buffers (obtained with PyString_AsString) with data after creating them in my extension module. You could as an alternative just use byte arrays. These are changeable. The question is - is this allowed? Because the doc says this The data must not be modified in any way, unless the string was just created using PyString_FromStringAndSize(NULL, size). Once the string has been used by python code, you should not change it. strings are immutable in python, so that every operation on a string returns a new one. See above. but what exactly does "just created" mean? will it not be considered Just created means just that. It is created and not been passed back to the interpreter. So long you may change it. "just created" if I call any more Python stuff after PyString_FromString, like another PyString_FromString along with PyString_AsString? Which I certainly intend to do since I first create all strings I want, and then do my calculations which fill those with actual data. Another question is this - why does PyString_AsString doc states that Return a NUL-terminated representation of the contents of string. when strings may contain binary data and thus NOT NUL-terminated in general? is this a documentation error or I can't access binary strings using PyString_AsString ? Read carefully: NUL-terminated representation of the contents of the string. It may contain other data, but the C-API will take care that this "contract" will be valid. P.S. the doc quotes are from http://docs.python.org/release/2.6.6/c-api/string.html There do they live, indeed. -- http://mail.python.org/mailman/listinfo/python-list
using strings from extension module question + possible documentation error
Hi, I am writing an extension module in which I want to do some heavy number crunching on large amount of data. The input data is prepared using Python code and passed to this extension module via strings containing binary data, and the result is also passed back as a list of pretty large strings containing binary data. So first I thought I'll just pass the empty strings made in Python along with input data strings, so my extension code would just fill those empty strings with the results. But then I read the PyString docs, it says I must not modify any strings even though it seems to be possible... Ok then I decided I'll create a list and fill it with strings from my C extension code.. However to avoid data copying I wish to fill the newly created (using PyString_FromString(NULL,x) ) strings' buffers (obtained with PyString_AsString) with data after creating them in my extension module. The question is - is this allowed? Because the doc says this > The data must not be modified in any way, unless the string was just created > using PyString_FromStringAndSize(NULL, size). but what exactly does "just created" mean? will it not be considered "just created" if I call any more Python stuff after PyString_FromString, like another PyString_FromString along with PyString_AsString? Which I certainly intend to do since I first create all strings I want, and then do my calculations which fill those with actual data. Another question is this - why does PyString_AsString doc states that > Return a NUL-terminated representation of the contents of string. when strings may contain binary data and thus NOT NUL-terminated in general? is this a documentation error or I can't access binary strings using PyString_AsString ? P.S. the doc quotes are from http://docs.python.org/release/2.6.6/c-api/string.html -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.islink documentation error?
En Tue, 27 Nov 2007 14:46:24 -0300, Diez B. Roggisch <[EMAIL PROTECTED]> escribió: > Giampaolo Rodola' schrieb: >> os.path.islink documentation says: >> >> "Return True if path refers to a directory entry that is a symbolic >> link. Always False if symbolic links are not supported." >> >> It's not clear to me why it is mentioned the DIRECTORY term. >> Shouldn't os.path.islink be used to just check if the *path* passed as >> argument is a symlink? >> In such case I would change it in: >> >> "Return True if path refers to a symbolic link" > > > But it does say so. It talks about entries in a directory being symbolic > links. Not the entries being symbolic links to directories. But it's a bit confusing. Most of the directory functions in module os operate on "directory entries" anyway, but it's not explicitely written as in this case. To be consistent, os.remove should be "remove the directory entry `path`", os.rename should be "rename the directory entry for `src` to `dst`", etc. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.islink documentation error?
:) You're right... My skimpy English cheated me. -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.islink documentation error?
Giampaolo Rodola' schrieb: > os.path.islink documentation says: > > "Return True if path refers to a directory entry that is a symbolic > link. Always False if symbolic links are not supported." > > It's not clear to me why it is mentioned the DIRECTORY term. > Shouldn't os.path.islink be used to just check if the *path* passed as > argument is a symlink? > In such case I would change it in: > > "Return True if path refers to a symbolic link" But it does say so. It talks about entries in a directory being symbolic links. Not the entries being symbolic links to directories. Diez -- http://mail.python.org/mailman/listinfo/python-list
os.path.islink documentation error?
os.path.islink documentation says: "Return True if path refers to a directory entry that is a symbolic link. Always False if symbolic links are not supported." It's not clear to me why it is mentioned the DIRECTORY term. Shouldn't os.path.islink be used to just check if the *path* passed as argument is a symlink? In such case I would change it in: "Return True if path refers to a symbolic link" -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
On Sunday 04 September 2005 01:30 pm, Reinhold Birkenfeld wrote: > tiissa wrote: > > bill wrote: > >>>From 3.2 in the Reference Manual "The Standard Type Hierarchy": > >> > >> "Integers > >> These represent elements from the mathematical set of whole > >> numbers." > >> > >> The generally recognized definition of a 'whole number' is zero and the > >> positive integers. > > > > This term is ambiguous as it seems to be used for both natural numbers > > and signed numbers [1]. You realize, of course, that "natural numbers" don't include zero. ;-) This is a pretty serious nitpick, isn't it? "Integers" is a well defined mathematical concept, as well as a pretty well defined (but not coincident) computer science concept. It's probably worth mentioning that Python uses the *mathematical* definition of "integer" here -- or more precisely that Python "long integers" do, while regular "integers" are what are known as "long integers" in C. Okay. I guess that *is* pretty confusing. I think the manual is not so far off since "whole number" makes English sense, if not mathematical. Certainly, if I were explaining this to my kids I would say "whole" and not "integer" (I at least know they know what "whole" means). -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
Bengt Richter wrote: > Bryan Olson wrote: >>Consider deleting the sentence in which the Python doc tries to >>define mathematical integers. > This is a nice site: > > http://mathworld.wolfram.com/WholeNumber.html > http://mathworld.wolfram.com/topics/Integers.html So maybe: Integers Pyton offers three types of http://mathworld.wolfram.com/topics/Integers.html";>integers: Or use the Wikipedia ref. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
On Sun, 04 Sep 2005 20:02:10 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote: >Reinhold Birkenfeld wrote: > > tiissa wrote: > > > >>bill wrote: > >> > From 3.2 in the Reference Manual "The Standard Type Hierarchy": > >>> > >>>"Integers > >>>These represent elements from the mathematical set of whole > >>>numbers." > >>> > >>>The generally recognized definition of a 'whole number' is zero and the > >>>positive integers. > >> > >>This term is ambiguous as it seems to be used for both natural numbers > >>and signed numbers [1]. > > > > > > I cleared this up; now it reads "... set of whole numbers (positive >and negative > > ones)." > >Consider deleting the sentence in which the Python doc tries to >define mathematical integers. > > Integers > > [In Python] There are three types of integers: > This is a nice site: http://mathworld.wolfram.com/WholeNumber.html http://mathworld.wolfram.com/topics/Integers.html Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
Reinhold Birkenfeld wrote: > tiissa wrote: > >>bill wrote: >> From 3.2 in the Reference Manual "The Standard Type Hierarchy": >>> >>>"Integers >>>These represent elements from the mathematical set of whole >>>numbers." >>> >>>The generally recognized definition of a 'whole number' is zero and the >>>positive integers. >> >>This term is ambiguous as it seems to be used for both natural numbers >>and signed numbers [1]. > > > I cleared this up; now it reads "... set of whole numbers (positive and negative > ones)." Consider deleting the sentence in which the Python doc tries to define mathematical integers. Integers [In Python] There are three types of integers: -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
tiissa wrote: > bill wrote: >>>From 3.2 in the Reference Manual "The Standard Type Hierarchy": >> >> "Integers >> These represent elements from the mathematical set of whole >> numbers." >> >> The generally recognized definition of a 'whole number' is zero and the >> positive integers. > > This term is ambiguous as it seems to be used for both natural numbers > and signed numbers [1]. I cleared this up; now it reads "... set of whole numbers (positive and negative ones)." Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
bill wrote: >>From 3.2 in the Reference Manual "The Standard Type Hierarchy": > > "Integers > These represent elements from the mathematical set of whole > numbers." > > The generally recognized definition of a 'whole number' is zero and the > positive integers. This term is ambiguous as it seems to be used for both natural numbers and signed numbers [1]. > That is to say, -1 is not a whole number. The > documentation ought to replace "whole numbers" with "integers". Then you get a circular definition, arguably not very useful. Why not simply precise 'signed whole numbers'? However, it can be noted that the first instance of such types provides the range -2147483648, 2147483647 which cannot be mistaken for natural numbers. [1] http://en.wikipedia.org/wiki/Whole_numbers -- http://mail.python.org/mailman/listinfo/python-list
documentation error
>From 3.2 in the Reference Manual "The Standard Type Hierarchy": "Integers These represent elements from the mathematical set of whole numbers." The generally recognized definition of a 'whole number' is zero and the positive integers. That is to say, -1 is not a whole number. The documentation ought to replace "whole numbers" with "integers". -- http://mail.python.org/mailman/listinfo/python-list
