Thank you.
Uri.
אורי
u...@speedy.net
On Tue, Jul 9, 2024 at 6:40 PM Barry Scott wrote:
>
>
> On 9 Jul 2024, at 06:13, אורי via Python-list <python-list@python.org>
> wrote:
>
> I tried to subscribe to Python-ideas
>
>
> These days ideas are discussed on https://discuss.python.org/
> It is
> On 9 Jul 2024, at 06:13, אורי via Python-list <python-list@python.org>
> wrote:
>
> I tried to subscribe to Python-ideas
These days ideas are discussed on https://discuss.python.org/
It is rare to see an idea on the mailing list.
Barry
--
https://mail.python.org/mailman/listinfo/pyt
Hi,
Please look at this Stack Overflow post:
https://stackoverflow.com/questions/78722378/parser-add-mutually-exclusive-group-how-can-i-set-a-default-value
1. Is there a way to add a default to parser add_mutually_exclusive_group
groups - a value that will be set by default? In this case I
want
On Thu, 19 Oct 2023 at 19:34, Karsten Hilbert wrote:
>
> > > As per my recent foray into abusing existence-checking for Singleton
> > > assurance
> > > along such lines as
> > >
> > > >>> try: self.initialized
> > > >>> except AttributeError: print('first instantiation'); self.initialized
> > >
> > As per my recent foray into abusing existence-checking for Singleton
> > assurance
> > along such lines as
> >
> > >>> try: self.initialized
> > >>> except AttributeError: print('first instantiation'); self.initialized =
> > >>> True
> >
> > and then changing that to
> >
> > >>> try: self.ini
On Thu, 19 Oct 2023 at 18:25, Karsten Hilbert wrote:
>
> > > > Fundamentally no, at least not without some shenanigans. Type hints do
> > > > not affect the regular running of the code,
> > >
> > > Except when they do ;-)
> > >
> > > ... depending on what counts as (valid) code ...
> > >
> > > In
> > > Fundamentally no, at least not without some shenanigans. Type hints do
> > > not affect the regular running of the code,
> >
> > Except when they do ;-)
> >
> > ... depending on what counts as (valid) code ...
> >
> > In Python a distinction can be made between "runnable" and "valid" :-D
> >
On Thu, 19 Oct 2023 at 18:04, Karsten Hilbert wrote:
>
> > > or something like that. Basically, any way to avoid writing `= None` over
> > > and over again.
> >
> > Fundamentally no, at least not without some shenanigans. Type hints do
> > not affect the regular running of the code,
>
> Except wh
> > or something like that. Basically, any way to avoid writing `= None` over
> > and over again.
>
> Fundamentally no, at least not without some shenanigans. Type hints do
> not affect the regular running of the code,
Except when they do ;-)
... depending on what counts as (valid) code ...
In
On Thu, 19 Oct 2023 at 10:11, Matthew Carruth via Python-list
wrote:
>
> We have the `Optional[T]` type as a short-hand for Union[T | None] and
> telling us that said argument may not be present.
>
> However, I find that a majority of the time, we also want to set a default
>
We have the `Optional[T]` type as a short-hand for Union[T | None] and telling
us that said argument may not be present.
However, I find that a majority of the time, we also want to set a default
value of None on the argument so that it can be evaluated without doing a
getattr() check first
>> > else:
>> > raise ValueError
[...]
>> Your class definition is basically
>>
>> class Container:
>> x = default_value
>> x = property_x
>>
>> i. e. you use the same name twice. A possible workaround mi
return 30
> >
> > @dataclass
> > class Container:
> > x: int = field(default_factory=set_property)
> >
> > def get_x(self) -> int:
> > return self._x
> >
> > def set_x(self, z: int):
> > if z > 1:
> >
._x = z
> else:
> raise ValueError
>
> c= Container(x=10)
> print(c)
> c= Container()
> print(c)
>
> output is:
> Container(x=10)
> Container(x=30)
>
> So, what I'm missing here? Is there some way to use field() or
> decorato
Hello All,
I have some trouble using @dataclass together with @property decorator
or property() function.
>From the documentation and PEP is seems that the intended behaviour of
@dataclass is to be the same as normal __init__() that sets instance
variables.
But it seems that when using @property
>
> The Apathetic Approach:
>
> I could just assume that a programmer is responsible for the
> code he writes. If he passes mutables into a function as
> default arguments, and
I don't think so!
>
> Any "intelligent" programmer would NEVER use mutable keys
> for a hash table -- unless he had a very good reason and was
> willing to take the risks -- EVEN IF the language allowed
> such foolishness!
The reason this isn't allowed is becaus
On Sat, Jun 22, 2013 at 8:40 AM, Antoon Pardon
wrote:
> Are you two guys now egging on Rick Johnson?
No. Rick is incorrigible, and I would have been surprised if he
responded to that anyway.
--
http://mail.python.org/mailman/listinfo/python-list
On 24/06/2013 15:22, Grant Edwards wrote:
On 2013-06-22, Ian Kelly wrote:
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
On 21/06/2013 21:44, Rick Johnson wrote:
[...]
Which in Python would be the "MutableArgumentWarning".
*school-
On 2013-06-22, Ian Kelly wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> wrote:
>> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>>
>>> On 21/06/2013 21:44, Rick Johnson wrote:
>> [...]
Which in Python would be the "MutableArgumentWarning".
*school-bell*
>>> I not
On 22/06/2013 19:49, Rick Johnson wrote:
On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote:
On 22/06/2013 02:15, Rick Johnson wrote:
IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?
No, I don't. These two special cases are not sufficient
for me to determine what semantics you are prop
On 22/06/2013 03:32, Rick Johnson wrote:
On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
On 22/06/2013 00:51, Rick Johnson wrote:
> On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> My argument has always been that mutables should not be
> passed into subroutines as default argumen
On Sat, Jun 22, 2013 at 10:49 AM, Dennis Lee Bieber
wrote:
> On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly
> declaimed the following:
>
>>While we're at it, I would like to petition for a function
>>terminates(f, args) that I can use to determine whether a function
>>will terminate before I actua
On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote:
> > On 22/06/2013 02:15, Rick Johnson wrote:
> > IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?
>
> No, I don't. These two special cases are not sufficient
> for me to determine what semantics you are proposing for
> the general case.
On 22/06/2013 03:01, I wrote:
On 22/06/2013 02:15, Rick Johnson wrote:
[...]
This is what should happen:
py> def foo(arg=[]):
... arg.append(1)
... print(arg)
...
py> foo()
[1]
py> foo()
[1]
py> foo()
[1]
Yes, Yes, YES! That is intuiti
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote:
> I sorry, but FP is not going to wash our sins clean. In
> fact, if taken too seriously, FP leads to preaching
> professors, intellectually unstimulated students, and
> semesters of wasted time that could have been better spent
>
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote:
> > So for example, if the use-case contained a statement
> > like: In order to safeguard customer-satisfaction, the
> > ATM's performance shall not degrade beyond 3 seconds
> > response time.
> > So now - according to our methodol
> See my blog [...]
> for a history of wishes akin to yours and lessons not
> learnt. In short the problems accruing from unconstrained
> imperative programming are severe and the solutions are
> hard. In the meanwhile, goals such as your 'keep-
> procedures-stateless' can and should certainly be
>
Op 22-06-13 03:27, Ian Kelly schreef:
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
On 21/06/2013 21:44, Rick Johnson wrote:
[...]
Which in Python would be the "MutableArgumentWarning".
*school-bell*
I notice that you've omitted
On 22/06/2013 02:31, Steven D'Aprano wrote:
On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
Oh! I know. Function argument defaults will now be restricted to
int/float/tuple. That would do it, right? Nobody would be bothered by
little restrictions like that, would they.
Alas, tuples
On Saturday, June 22, 2013 8:25:15 AM UTC+5:30, Rick Johnson wrote:
> On Friday, June 21, 2013 9:32:43 PM UTC-5, rusi wrote:
> > So Rick... I agree with you... all these theoreticians
> > should be burnt at the stake!
> > On a more serious note: many
> > people make similar mistakes eg Haskellers
On Friday, June 21, 2013 9:32:43 PM UTC-5, rusi wrote:
> So Rick... I agree with you... all these theoreticians
> should be burnt at the stake! On a more serious note: many
> people make similar mistakes eg Haskellers who think
> Haskell is safe. Safer (than something or other) -- Ok
> Safe -- NO
On 06/21/2013 07:41 PM, Chris Angelico wrote:
>> While we're at it, I would like to petition for a function
>> terminates(f, args) that I can use to determine whether a function
>> will terminate before I actually call it.
>
> Nice idea from a theoretical point of view, but practicality beats
> pu
On Saturday, June 22, 2013 7:34:18 AM UTC+5:30, MRAB wrote:
> Pure functional languages don't have mutables, or even variables, but
> then we're not talking about a pure functional language, we're talking
> about Python.
In which case neither do mathematicians. Do we rewrite the last 1000 years o
On Friday, June 21, 2013 8:38:21 PM UTC-5, Ian wrote:
> The answer to this conundrum is staring you in the face.
Thanks for posting a solution for this. Not sure if i'll
ever need it, but nice to know.
> Note that the TypeError complains that you passed it an
> "unhashable" type, and not that you
On Saturday, June 22, 2013 6:57:42 AM UTC+5:30, Ian wrote:
> While we're at it, I would like to petition for a function
> terminates(f, args) that I can use to determine whether a function
> will terminate before I actually call it.
I was going to say something about this -- viz that in prog. lang
On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
> On 22/06/2013 00:51, Rick Johnson wrote:
> > On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> > My argument has always been that mutables should not be
> > passed into subroutines as default arguments because bad
> > things can happen
On 22/06/2013 03:18, Chris Angelico wrote:
On Sat, Jun 22, 2013 at 12:01 PM, Rotwang wrote:
class hashablelist(list):
... def __hash__(self):
... return hash(tuple(self))
There's a vulnerability in that definition:
a=hashablelist((1,[],3))
a
[1, [], 3]
{a:1}
Traceback (most
On Sat, Jun 22, 2013 at 12:01 PM, Rotwang wrote:
class hashablelist(list):
> ... def __hash__(self):
> ... return hash(tuple(self))
There's a vulnerability in that definition:
>>> a=hashablelist((1,[],3))
>>> a
[1, [], 3]
>>> {a:1}
Traceback (most recent call last):
File "", l
ntation is partly apathetic,
is is also benevolent, and malevolent simultaneously. My
approach is purely apathetic. I'll explain later. Stay
tuned.
OK...
[...]
So how does the interpreter know whether an arbitrary
object passed as a default value is mutable or not? Not
that it really matt
On 22/06/2013 02:40, Chris Angelico wrote:
On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
wrote:
Thinking about this, I think that the only safe thing to do in Rickython
4000 is to prohibit putting mutable objects inside tuples. Putting a list
or a dict inside a tuple is just a bug waiting t
On 22/06/2013 00:51, Rick Johnson wrote:
On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
I notice that you've omitted any mention of how you'd know that the
argument was mutable.
My argument has always been that mutables should not be
passed into subroutines as default arguments because
On Fri, Jun 21, 2013 at 7:37 PM, Chris Angelico wrote:
class HashableList(list):
> def __hash__(self):
> return 42
Hey, we both picked exactly the same example!
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Jun 21, 2013 at 7:15 PM, Rick Johnson
wrote:
>> > Let's imagine for a second if Python allowed mutable keys in
>> > a dictionary,
>> which it does
>
> Am i just to take your word for this? You cannot provide an
> example? Here, allow me to "break the ice":
>
> # Literal
> py> d = {
On Friday, June 21, 2013 8:31:35 PM UTC-5, Steven D'Aprano wrote:
> Tuples have to go into the "Bad List" because, although
> they themselves are immutable, their contents may not be.
> Imagine the confusion and horror that poor developers will
> experience when they do something like this:
>
> de
On Sat, Jun 22, 2013 at 11:27 AM, Ian Kelly wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> wrote:
>> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>>
>>> On 21/06/2013 21:44, Rick Johnson wrote:
>> [...]
Which in Python would be the "MutableArgumentWarning".
*school-
On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
wrote:
> Thinking about this, I think that the only safe thing to do in Rickython
> 4000 is to prohibit putting mutable objects inside tuples. Putting a list
> or a dict inside a tuple is just a bug waiting to happen!
I think you're onto something
On Sat, Jun 22, 2013 at 11:15 AM, Rick Johnson
wrote:
> # Literal
> py> d = {[1]:2}
> Traceback (most recent call last):
> File "", line 1, in
> d = {[1]:2}
> TypeError: unhashable type: 'list'
> # Symbol
> py> lst = [1]
> py> d = {lst:2}
> Traceback
On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
> Oh! I know. Function argument defaults will now be restricted to
> int/float/tuple. That would do it, right? Nobody would be bothered by
> little restrictions like that, would they.
Alas, tuples won't do it. Fortunately, you can include
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>
>> On 21/06/2013 21:44, Rick Johnson wrote:
> [...]
>>> Which in Python would be the "MutableArgumentWarning".
>>>
>>> *school-bell*
>>>
>> I notice that you've omitted any mention of how yo
on is partly apathetic,
is is also benevolent, and malevolent simultaneously. My
approach is purely apathetic. I'll explain later. Stay
tuned.
> [...]
> So how does the interpreter know whether an arbitrary
> object passed as a default value is mutable or not? Not
> that it reall
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
> On 21/06/2013 21:44, Rick Johnson wrote:
[...]
>> Which in Python would be the "MutableArgumentWarning".
>>
>> *school-bell*
>>
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.
That's easy. Just call is
On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.
My argument has always been that mutables should not be
passed into subroutines as default arguments because bad
things can happen. And Python's excu
uld happen when I passed a mutable argument as a
default value in a def statement? E.g. this:
>>> a = [1, 2, 3]
>>> a.append(a)
>>> b = object()
>>> def f(x = [None, b, [a, [4]]]):
... pass # do something
What would you like to see the interpreter do
On 21/06/2013 21:44, Rick Johnson wrote:
On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
On 21/06/2013 19:26, Rick Johnson wrote:
>
> The Apathetic Approach:
>
> I c
On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> >
> > The Apathetic Approach:
> >
> > I could just assume that a programmer
On Friday, June 21, 2013 2:20:22 PM UTC-5, Neil Cerutti wrote:
> Rick, it's not a wart, It's a gotcha. The reason it's a
> gotcha is this: In order to predict what will happen
> correctly, you have to have mastered three separate Python
> concepts.
>
> 1. How name-binding works.
> 2. How argument p
On Friday, June 21, 2013 2:18:27 PM UTC-5, Rick Johnson wrote:
> On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
>
> > Okay, you're trolling.
Steven, you wouldn't know "trolling" even if you were an honorary salad tosser
at a troll face-sitting contest.
--
http://mail.python.
uld happen when I passed a mutable argument as a
default value in a def statement? E.g. this:
>>> a = [1, 2, 3]
>>> a.append(a)
>>> b = object()
>>> def f(x = [None, b, [a, [4]]]):
... pass # do something
What would you like to see the interpreter do
On 2013-06-21, Chris Angelico wrote:
> On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
> wrote:
>> I could cast a "virtual net" over my poor lemmings before
>> they jump off the cliff by throwing an exception:
>>
>> Traceback (most recent screw-up last):
>>Line BLAH in SCRIPT
>> def f(x =
On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
> Okay, you're trolling. Time for another month in the kill-file.
> *plonk*
That's so typical of you. You start losing an argument, and
when you have no remaining counter arguments, you resort to
name calling. Why am i not surprise
On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
wrote:
> I could cast a "virtual net" over my poor lemmings before
> they jump off the cliff by throwing an exception:
>
> Traceback (most recent screw-up last):
>Line BLAH in SCRIPT
> def f(x = [None, b, [a, [4]]]):
> ArgumentError: No mut
On Fri, 21 Jun 2013 11:26:39 -0700, Rick Johnson wrote:
> You know, out of all these post, not one of you guys has presented a
> valid use-case that will give validity to the existence of this PyWart
LOL.
Okay, you're trolling. Time for another month in the kill-file.
*plonk*
--
Steven
--
h
sed a mutable argument as a
> default value in a def statement? E.g. this:
>
> >>> a = [1, 2, 3]
> >>> a.append(a)
> >>> b = object()
> >>> def f(x = [None, b, [a, [4]]]):
> ... pass # do something
>
> What would you like to see t
On 21/06/2013 18:01, Rick Johnson wrote:
[stuff]
It isn't clear to me from your posts what exactly you're proposing as an
alternative to the way Python's default argument binding works. In your
version of Python, what exactly would happen when I passed a mutable
argument as
routine method if encapsulation is not #
# warrented. #
But in any case, following this advice will ensure less bugs
and more maintainable code than Python's current
implementati
, like 'y' above, is an expression. In any case, while the
name must exist at the time the function is defined, it does not need to
exist when the function is called:
py> y = 23
py> def func(x=y):
... return x
...
py> del y
py> func()
23
>> The only difference
ve. What you haven't done is
define a function which takes a default value that can be overridden when
called. Your argument is invalid.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Thursday, June 20, 2013 5:28:06 PM UTC-5, Lefavor, Matthew
(GSFC-582.0)[MICROTEL LLC] wrote:
>
> [snip example showing dummy coder doing something dumb]
>
> +1. This is what convinces me that keeping references to
> keyword arguments is actually the right thing to do.
>
> Perhaps I'm biased b
On Friday, June 21, 2013 2:10:49 AM UTC-5, Chris Angelico wrote:
> Why should that be? Why is a subroutine not allowed to
> retain any state?
I refuse to repeat myself for lazy readers!
> You're free to write code in a purely functional style if
> you like
I don't want to write code in a purely
Or, in many MANY cases, the choice was the right one, but isn't
obvious to everyone.
I think it's worth pointing out that changing function defaults to
late-binding would merely change the nature of the gotcha, not eliminate it.
words = ("one", "two", "red", "blue", "fish")
def join_strings(stri
On Fri, Jun 21, 2013 at 1:16 PM, Rick Johnson
wrote:
> On Thursday, June 20, 2013 7:57:28 PM UTC-5, Steven D'Aprano wrote:
>> Python functions are
>> created *once*, when defined. The cost of building the
>> function -- compiling the source code to byte code,
>> assembling the pieces into a functi
routine will need to "store"
the resulting object. Yes.
> The only difference is that with early binding, the
> default value is calculated once, and the object stored,
> while with late binding the default value is re-calculated
> over and over again, every time it is needed
On Thu, 20 Jun 2013 10:12:01 -0700, rusi wrote:
> Python (and all the other 'cool' languages) dont have gotchas because
> someone malevolently put them there.
> In most cases, the problem is seen too late and the cost of changing
> entrenched code too great.
> Or the problem is clear, the solution
rusi於 2013年6月21日星期五UTC+8上午1時12分01秒寫道：
> You know Rick, you are good at python, you are better at polemics.
>
> If only you would cut the crap I would (be able to) agree with you.
>
> See below
>
>
>
> On Jun 20, 7:49 pm, Rick Johnson wrote:
>
> > On Thursday, June 20, 2013 7:57:06 AM UTC-5,
On 2013-06-20 21:40, Roy Smith wrote:
> In article ,
> Tim Chase wrote:
>
> > On 2013-06-21 01:08, Steven D'Aprano wrote:
> > > Here's my syntax plucked out of thin air:
> > >
> > > def func(arg, x=expression, !y=expression):
> > > ...
> > >
> > > where y=expression is late-bound, and the
In article ,
Tim Chase wrote:
> On 2013-06-21 01:08, Steven D'Aprano wrote:
> > Here's my syntax plucked out of thin air:
> >
> > def func(arg, x=expression, !y=expression):
> > ...
> >
> > where y=expression is late-bound, and the above is compiled to:
> >
> > def func(arg, x=expression,
a subroutine should never have side effects UNLESS the
> programmer explicitly ask for a side effect.
Correct. And by using a default value, you are explicitly asking for a
side-effect, namely, "use this object as the default" (not, "use this
expression, and re-evaluate it at call-tim
On 2013-06-21 01:08, Steven D'Aprano wrote:
> Here's my syntax plucked out of thin air:
>
> def func(arg, x=expression, !y=expression):
> ...
>
> where y=expression is late-bound, and the above is compiled to:
>
> def func(arg, x=expression, y=None):
> if y is None:
> y = express
On Thu, 20 Jun 2013 11:57:34 -0600, Ian Kelly wrote:
> Additionally, with late-binding semantics the default values would no
> longer be default *values*. They would be initialization code instead,
> which sort of flies in the face of the idea that late-binding would
> somehow be better for funct
y blob.
Even if Python chose late binding instead of early binding for function
defaults, the default would *still* need to be stored somewhere. The only
difference is that with early binding, the default value is calculated
once, and the object stored, while with late binding the default value is
On 21/06/2013 4:07 AM, Rick Johnson wrote:
Okay. So now you are admitting the problem. That is a good
start. Thanks for being honest.
If you think mutable default arguments is a "problem", then you don't
really understand Python. The only "gotcha" here is in people's heads.
--
http://mail.py
In article <51c39b88$0$2$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote:
>
> > In article
> > <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
> > rusi wrote:
> >
> >> > > def f(a, L=[]):
> >> > > Â Â
On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote:
> In article
> <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
> rusi wrote:
>
>> > > def f(a, L=[]):
>> > > L.append(a)
>> > > return L
>
>> Every language has gotchas. This is one of python's.
>
> One of our pr
On Jun 20, 10:57 pm, Ian Kelly wrote:
> If
> the goal is indeed to make the the functions more functional, then the
> proper solution would be to keep the binding early but just disallow
> mutable defaults altogether -- which is tricky to achieve in Python,
> so we simply emulate it with the advic
On Thursday, June 20, 2013 12:12:01 PM UTC-5, rusi wrote:
> Python (and all the other 'cool' languages) dont have
> gotchas because someone malevolently put them there. In
> most cases, the problem is seen too late and the cost of
> changing entrenched code too great.
Okay. So now you are admitt
On Thursday, June 20, 2013 10:38:34 AM UTC-5, Chris Angelico wrote:
> Function defaults in Python, being implemented as
> attributes on the function object, are very similar in
> nature to static variables in C.
Oh wait a minute. i think it's becoming clear to me now!
Python functions are objects
On Thu, Jun 20, 2013 at 11:19 AM, Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote:
>> Python (and all the other 'cool' languages) dont have gotchas because
>> someone malevolently put them there.
>> In most cases, the problem is seen too late and the cost of changing
>> entren
On Jun 20, 10:19 pm, Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote:
> > Python (and all the other 'cool' languages) dont have gotchas because
> > someone malevolently put them there.
> > In most cases, the problem is seen too late and the cost of changing
> > entrenched code
On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote:
> Python (and all the other 'cool' languages) dont have gotchas because
> someone malevolently put them there.
> In most cases, the problem is seen too late and the cost of changing
> entrenched code too great.
> Or the problem is clear, the solution is
You know Rick, you are good at python, you are better at polemics.
If only you would cut the crap I would (be able to) agree with you.
See below
On Jun 20, 7:49 pm, Rick Johnson wrote:
> On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote:
> > Every language has gotchas. This is one of python
On Fri, Jun 21, 2013 at 12:49 AM, Rick Johnson
wrote:
> When the subroutine is completed, all inputs and local
> variables are expected to be destroyed. If the programmer
> wants a return value, he need simply ask. Data persistence
> is not a function of subroutines!
Funny, C violates your descri
On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote:
> Every language has gotchas. This is one of python's.
So are we purposely injecting illogic into our language just
to be part of some "cool crowd" of programming languages with
gotchas.
"You thought intuitiveness was a virtue? Haha, we go
On Jun 20, 6:19 pm, Roy Smith wrote:
> In article
> <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
>
> rusi wrote:
> > > > def f(a, L=[]):
> > > > L.append(a)
> > > > return L
> > Every language has gotchas. This is one of python's.
>
> One of our pre-interview scree
In article
<447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
rusi wrote:
> > > def f(a, L=[]):
> > > L.append(a)
> > > return L
> Every language has gotchas. This is one of python's.
One of our pre-interview screening questions for Python programmers at
Songza is ab
On Jun 20, 12:38 am, Rick Johnson
wrote:
> On Wednesday, June 19, 2013 2:17:35 PM UTC-5, Ahmed Abdulshafy wrote:
> > I'm reading the Python.org tutorial right now, and I found
> > this part rather strange and incomprehensible to me>
>
> > Important warning: The
On Wed, 19 Jun 2013 12:17:35 -0700, Ahmed Abdulshafy wrote:
> I'm reading the Python.org tutorial right now, and I found this part
> rather strange and incomprehensible to me>
>
> Important warning: The default value is evaluated only once. This makes
> a difference when t
On 06/19/2013 12:17 PM, Ahmed Abdulshafy wrote:
I'm reading the Python.org tutorial right now, and I found this part rather
strange and incomprehensible to me>
Important warning: The default value is evaluated only once. This makes a
difference when the default is a mutable object s
On Wednesday, June 19, 2013 2:17:35 PM UTC-5, Ahmed Abdulshafy wrote:
> I'm reading the Python.org tutorial right now, and I found
> this part rather strange and incomprehensible to me>
>
> Important warning: The default value is evaluated only
> once. This makes a differe
Ahmed Abdulshafy writes:
> I'm reading the Python.org tutorial right now, and I found this part
> rather strange and incomprehensible to me
>
> Important warning: The default value is evaluated only once. This
> makes a difference when the default is a mutable obj
1 - 100 of 265 matches
Mail list logo
