I was extending a `list` and am wondering why slicing lists will never raise an
IndexError, even if the `slice.stop` value if greater than the list length.
Quick example:
my_list = [1, 2, 3]
my_list[:100] # does not raise an IndexError, but instead returns the full
list
Is there any background
I'll try to summarize what I've learned with a few responses in hodge-podge
order and to no one in particular:
>That's a feature dude, not a bug.
Absolutely. I _do not_ think that how slicing works in python should be
changed, but I _do_ want to understand its design decisions because it will
mak
>
> >> This is explained in the Python tutorial for strings
> >> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
> >> is a sequence just like a string it will act in exactly the same way.
> >>
> >
> > The only relevant bit I found in that link is: "However, out of range
> >
>
> This is explained in the Python tutorial for strings
> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
> is a sequence just like a string it will act in exactly the same way.
>
The only relevant bit I found in that link is: "However, out of range
slice indexes are hand
>Why would this simplify your code? What are you doing that would benefit
>from an IndexError here?
Without simplifying too much, I'm writing a wrapper around a REST API. I
want lazy-loading functionality for lists-of-things, so I am creating a
LazyList class.
This LazyList class will load items
>
> Have you ever used a language that does that?
I have.
> The String class in the C# language does that, and it's /really/ annoying.
> I have to add extra code to prevent such exceptions.
> In practice, I find that the way that Python does it is much nicer. (And
> Python isn't unique in this res
I was extending a `list` and am wondering why slicing lists will never
raise an IndexError, even if the `slice.stop` value if greater than the
list length.
Quick example:
my_list = [1, 2, 3]
my_list[:100] # does not raise an IndexError, but instead returns the full
list
Is there any background
choice -- for the reasons I listed above -- but I
would like a more expert opinion (and I'd like to learn why :)).
Thanks!
Jason
On Thu, Nov 2, 2017 at 12:28 AM, Steve D'Aprano
wrote:
> On Thu, 2 Nov 2017 10:13 am, Jason Maldonis wrote:
>
> > Hi everyone,
> >
&
Ok no worries then! Thanks for the tips. I might wait until tomorrow then
until someone comes along who deals with metaclasses and alternate class
constructors.
In case you're curious, I'm doing two things that are relevant here, and
I'll link the python3 cookbook examples that are super useful (I
(I'm using python3)
@classmethod
def normal_constructor(cls, *args, **kwargs):
self = cls.__new__(cls)
self.__init__(*args, **kwargs)
return self
On Wed, Nov 1, 2017 at 6:51 PM, Stefan Ram wrote:
> Jason Maldonis writes:
> >I was looking for documentation for what exac
Hi everyone,
I want to use a metaclass to override how class instantiation works. I've
done something analogous to using the Singleton metaclass from the Python3
Cookbook example.
However, I want to provide a classmethod that allows for "normal" class
instantiation that prevents this metaclass fr
Thank you Ethan and Chris for the tips. I may be able to adapt that
decorator for my use cases -- I hadn't thought of using something like
that. Ethan, I'll drop a note over at Python Ideas too with some details
about this.
Thanks for your help,
Jason
On Tue, May 2, 2017 at 9:47 PM, Chris Angel
-- I.e.
if you just remove @property from the first example, it returns the full
error stack exactly like we'd expect. That means the @property is changing
the call order (?) in some way that I don't understand.
Thanks!
Jason
On Tue, May 2, 2017 at 7:11 PM, Ethan Furman wrote:
> On 0
Moving this conversation from python-dev to here because I shouldn't have
sent it to python-dev.
My original message:
I'm working on a large class architecture and I find myself often
overloading __getattr__. I am continuously running into the issue where I
want __getattr__ to have access to the
14 matches
Mail list logo