Currently, list.reverse() only works for an entire list. If one wants to reverse a section of it 'in-place', one needs to slicing which makes the space complexity no longer O(1). One can also manually make a loop and do the reversal but that is even slower than slicing. List.reverse() does not take any arguments. Wouldn't it be a good if it can take in parameters such as 'start' and 'stop' to enable list.reverse() work even for a section of the list? When no arguments are specified, then it works on the whole list, like usual.
Apologies if this has already been raised at some point, but I wanted to
raise the idea of a basic standard library toolkit for operations on
async iterators.
This would include versions of functions that are already in the
standard library for non-async iterators, such as *map*, *filter*,*zip
*etc. It could also include a *merge* function for async iterators, for
example (this would yield items in whatever order they are yielded from
from the constituent iterators).
There are, of course, open source libraries providing these functions.
But in general there is far too wide a range of such libraries, and it
is difficult to tell which ones are best maintained. For the most basic
and universally useful of operations on async iterators, it would be far
better if they were part of the standard library.
Hi,
Python has an __all__ variable that can be defined in a module to restrict
which members of the module should be included in a call `from foo import
*`. However specifying which members of the module should be excluded is
more difficult. There are three workarounds that I see:
1) Defining __all__ to specify most of the members of the module, except
the few that should be excluded.
2) Naming members to be excluded with a leading underscore. e.g. as done
here in ctypes:
https://github.com/python/cpython/blob/master/Lib/ctypes/__init__.py#L3
3) Manually deleting members from the module. e.g. as done here in numpy:
https://github.com/numpy/numpy/blob/master/numpy/core/__init__.py#L52
I think it might be cleaner to also allow an __exclude_all__ variable which
will exclude some members from being imported.
If both were defined I would imagine __exclude_all__ being applied second.
Best,
George Harding
Please, consider class(obj) to return obj.__class__
consistenly with dir(), vars(), repr(), str(),…
>>> class c: pass
>>> o = c()
>>> o.__class__
<class '__main__.c'>
>>> class(o)
File "<stdin>", line 1
class(o)
^
SyntaxError: invalid syntax
Thank you in advance,
H.
Err, why is it insufficient?
On Wed, 2021-03-03 at 14:03 -0800, Paul Bryan wrote:
> Since class is a keyword, this is unlikely. Why is type(o) not
> insufficient?
>
> On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > > class c: pass
> > > > > o = c()
> > > > > o.__class__
> > <class '__main__.c'>
> > > > > class(o)
> > File "<stdin>", line 1
> > class(o)
> > ^
> > SyntaxError: invalid syntax
>
Please, is there a reason why extend() method does not return self?
>>> a = [1,2].extend((3,4))
>>> a
>>> type(a)
<class 'NoneType'>
>>> b = [1,2]
>>> b.extend((3,4))
>>> b
[1, 2, 3, 4]
Dear Anthony,
Greetings from another Anthony (although my friends call me Tony).
Thank you for your suggestion about changes to the Python Syntax.
The Idea of having curly braces with blocks of code has been considered
many times, and every time it has not been accepted.
When you do enough programming even in languages such as C, C++ and Java
which do use Curly braces (or languages such as Pascal which use
Begin/End and other such keywords), you will find that you do indent
your code consistently as a matter of habit. Most serious developers in
those languages will use auto-formatters to ensure that their code is
nicely indented. Even though they use languages which have syntax
elements to denote the start and end of a block, they recognize that
indentation is a very natural way to layout code to make it readable,
and they avoid 'indentation where ever they want'.
Python - by adopting indentation as it does - has simply adopted a very
natural form for writing code, and made it mandatory.
You might be surprised to know that Python does allow semicolons at the
end of statements, but they are optional, and really only used to run
mutiple statements together on a single line; which is not considered to
be a good style of writing.
Don't be put off by this message - keep enjoying Python and learning
about the world of programming. You have taken your first steps in the
Python community, and we all look forward to hearing what ever ideas you
might have in future.
Good luck in your future journey in the computing universe.
Tony Flury.
>
> On 03/03/2021 18:24, George Harding wrote:
>>
>>
>> ---------- Forwarded message ---------
>> From: *Anthony Farino* <anthonyf(a)pacemschool.org
>> <mailto:anthonyf@pacemschool.org>>
>> Date: Wed, Mar 3, 2021 at 5:52 PM
>> Subject: [Python-Dev] Suggestion About Python Syntax
>> To: <python-dev(a)python.org <mailto:python-dev@python.org>>
>>
>>
>> I love the Python scripting language, but there’s something that
>> would make it much better. Almost every other programming language
>> uses curly braces to enclose blocks of code and semicolons after the
>> lines of code. That means that:
>>
>> 1.
>>
>> You can have as much white space as you want.
>>
>> 2.
>>
>> You don’t need to worry about indentation, and you can indent
>> whenever you want.
>>
>> I hope that you consider these issues and fix them in Python 4 (if
>> you ever make it).
>>
>> Sincerely, Anthony, age 10.
>>
>>
>>
>> --
>> mm m #
>> ## m mm mm#mm # mm mmm m mm m m
>> # # #" # # #" # #" "# #" # "m m"
>> #mm# # # # # # # # # # #m#
>> # # # # "mm # # "#m#" # # "#
>> m"
>> ""
>> _______________________________________________
>> Python-Dev mailing list -- python-dev(a)python.org
>> <mailto:python-dev@python.org>
>> To unsubscribe send an email to python-dev-leave(a)python.org
>> <mailto:python-dev-leave@python.org>
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> <https://mail.python.org/mailman3/lists/python-dev.python.org/>
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y…
>> <https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y…>
>> Code of Conduct: http://python.org/psf/codeofconduct/
>> <http://python.org/psf/codeofconduct/>
>>
>> _______________________________________________
>> Python-ideas mailing list --python-ideas(a)python.org
>> To unsubscribe send an email topython-ideas-leave(a)python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived athttps://mail.python.org/archives/list/python-ideas@python.org/message/OEI…
>> Code of Conduct:http://python.org/psf/codeofconduct/
We where no longer on the ideas list...
> On 2 Mar 2021, at 13:04, Memz <mmax42852(a)gmail.com> wrote:
>
> There is no specific scenario it solves. The lack of efficiency of the timed code should speak for itself. Non-mutable bytes is a limit of python, since it's reliant on using function calls.
>
> b"\x00\x00\x00\x00\x00"
> bytearray( b"\x00\x00\x00\x00\x00" )
> struct.pack("iiiii",0,0,0,0,0)
> b"\x00\x00\x00\x00\x00" + bytes([1,0,0,0,0])
You mean the above is what you timed?
It is not a realistic problem you are measuring.
You also did not share how you measured the the code.
If you are not experienced in benchmarking there are variables
that you must control for to have meaningful results.
>
> All function calls take time and resources, it would be impossible to streamline a function call to make it faster than building it in. This goes for most languages, including C.
All python byte code is interpreted by calling functions. They take time and resources.
Barry
>
>
> On Tue, Mar 2, 2021 at 3:29 AM Barry Scott <barry(a)barrys-emacs.org <mailto:barry@barrys-emacs.org>> wrote:
>
>
> > On 2 Mar 2021, at 02:03, Memz <mmax42852(a)gmail.com <mailto:mmax42852@gmail.com>> wrote:
> >
> > >When I needed to do the creation of bytes objects from a mix of types the
> > >struct.pack() method has been the obvious way to go.
> >
> > >What is the use case that leads to needing the above?
> >
> > >Barry
> >
> > The use of my suggestion is to reduce the reliance of function calls for bytes and bytearrays, which currently can only be done through function calls, and making it more efficient all-together. Here is a timed version of this:
> > b-strings: 5-5.4 s
> > bytearray() function call: 67.9 s
> > struct.pack() 80.9 s
> > b-string + bytes([1,...]) 54.3 s
>
> What code are you benchmarking? What problem does that code solve?
>
> My experience with creating byte objects is that struct is the fastest way to get the job done.
> But that could be becuase of the problems that I need bytes for.
> For example calling ioctl().
>
> >
> > Moving bytearray to a non-function call would overhaul and optimize code that works with bytes, increase flexibility, and reduce reliance on imports, including struct.pack(). There is a lot of code that could, and should be using bytearray but can't, because other, more slow and painful than should be methods are more efficient because of the function call nature of bytearray.
>
> You are assuming that the problem is the function calls.
> Surely its the algorithms that lead to issues in most code that is slow?
>
> Barry
---------- Forwarded message ---------
From: Anthony Farino <anthonyf(a)pacemschool.org>
Date: Wed, Mar 3, 2021 at 5:52 PM
Subject: [Python-Dev] Suggestion About Python Syntax
To: <python-dev(a)python.org>
I love the Python scripting language, but there’s something that would make
it much better. Almost every other programming language uses curly braces
to enclose blocks of code and semicolons after the lines of code. That
means that:
1.
You can have as much white space as you want.
2.
You don’t need to worry about indentation, and you can indent whenever
you want.
I hope that you consider these issues and fix them in Python 4 (if you ever
make it).
Sincerely, Anthony, age 10.
--
mm m #
## m mm mm#mm # mm mmm m mm m m
# # #" # # #" # #" "# #" # "m m"
#mm# # # # # # # # # # #m#
# # # # "mm # # "#m#" # # "#
m"
""
_______________________________________________
Python-Dev mailing list -- python-dev(a)python.org
To unsubscribe send an email to python-dev-leave(a)python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y…
Code of Conduct: http://python.org/psf/codeofconduct/
Currently, the only way to concatenate an integer to a bytes object is by converting the integer to bytes with a function call before concatenating. And there is no way to make a mutable bytes object without a function call.
I propose an array-type string like the, or for the bytearray. It would work as a mutable b-string, as
foo = a"\x00\x01\x02abcÿ" # a-string, a mutable bytes object.
foo[0] = 123 # Item assignment
foo+= 255 # Works the same as bytesvariable+=b"123"
foo+= a"\x255\x00" # Concatenation with itself
foo+= b"\x255\x00" # Cross compatibility with bytes objects.
This would be processed the same as, or would be the bytearray,
>>> type(a"\x00\x01\x02abcÿ")
<class 'bytearray'>
