On Sat, May 27, 2017 at 3:31 PM, Steve D'Aprano
wrote:
> Python has nothing like that. What we have is a collection of ad hoc and
> subjective heuristics. If you want to call that a de facto standard, I'm
> okay with that, so long as we're aware of the significant gap between a de
> facto standard
On Sat, 27 May 2017 02:20 pm, Chris Angelico wrote:
> On Sat, May 27, 2017 at 12:59 PM, Steve D'Aprano
> wrote:
>>> What is a standards-compliant Python interpreter allowed to do?
>>
>> There's no such thing, so your question is moot.
>>
>> There is no Python standard. There's only:
>>
>> - do wh
On Sat, May 27, 2017 at 12:59 PM, Steve D'Aprano
wrote:
>> What is a standards-compliant Python interpreter allowed to do?
>
> There's no such thing, so your question is moot.
>
> There is no Python standard. There's only:
>
> - do what CPython does;
>
> - do what the documentation says;
>
> - if
On 05/26/2017 04:46 AM, Steve D'Aprano wrote:
[snip..]>
That's not how the C standard defines "undefined behaviour", or the
implication of such.
A little OT here, but...
This brings to mind this entry in the Jargon File:
http://catb.org/jargon/html/N/nasal-demons.html
--
-=- Larry -=-
-
On Sat, 27 May 2017 09:36 am, Chris Angelico wrote:
> On Sat, May 27, 2017 at 8:48 AM, Steve D'Aprano
> wrote:
>> I don't actually believe that any real compiler will *literally* contain
>> code that looks like this:
>>
>>
>> if phase_of_moon(now()) != X:
>> # emit machine code you expected
>
On Sat, May 27, 2017 at 8:48 AM, Steve D'Aprano
wrote:
> I don't actually believe that any real compiler will *literally* contain
> code that looks like this:
>
>
> if phase_of_moon(now()) != X:
> # emit machine code you expected
> else:
> # erase your hard drive
>
>
> but if one did, that
On Fri, 26 May 2017 10:01 pm, Chris Angelico wrote:
>> That's not how the C standard defines "undefined behaviour", or the
>> implication of such.
>
> Can you explain to me how it's different? Either way, the
> implementation is allowed to do what it likes, because you shouldn't
> be doing that.
On Fri, 26 May 2017 10:56 pm, Rhodri James wrote:
> On 26/05/17 12:46, Steve D'Aprano wrote:
>> On Thu, 25 May 2017 11:26 am, Chris Angelico wrote:
>>
>>> On Thu, May 25, 2017 at 9:34 AM, bartc wrote:
That was quite likely with older Fortrans, where subroutines only used
pass-by-refere
On 26/05/2017 12:46, Steve D'Aprano wrote:
On Thu, 25 May 2017 11:26 am, Chris Angelico wrote:
And why should they try to stop you? The whole point of undefined
behaviour is that you shouldn't be doing this, so if you do, the
interpreter's allowed to do anything.
Does the C specification act
On Friday, May 26, 2017 at 7:11:50 PM UTC+5:30, Chris Angelico wrote:
> On Fri, May 26, 2017 at 10:52 PM, Rustom Mody wrote:
> >> Can you explain to me how it's different? Either way, the
> >> implementation is allowed to do what it likes, because you shouldn't
> >> be doing that.
> >
> > I am gue
On Fri, May 26, 2017 at 10:52 PM, Rustom Mody wrote:
>> Can you explain to me how it's different? Either way, the
>> implementation is allowed to do what it likes, because you shouldn't
>> be doing that.
>
> I am guessing that Steven is mixing up undefined and unspecified behavior
>
> Undefined :
On 26/05/17 12:46, Steve D'Aprano wrote:
On Thu, 25 May 2017 11:26 am, Chris Angelico wrote:
On Thu, May 25, 2017 at 9:34 AM, bartc wrote:
That was quite likely with older Fortrans, where subroutines only used
pass-by-reference, but which didn't stop you passing references to
constants that t
On Friday, May 26, 2017 at 5:31:54 PM UTC+5:30, Chris Angelico wrote:
> On Fri, May 26, 2017 at 9:46 PM, Steve D'Aprano wrote:
> >
> >> And yes, Steve, this is a challenge to you: if you think C's undefined
> >> behaviour is an abomination that should not be allowed to exist,
> >
> > CPython doesn'
On Fri, May 26, 2017 at 9:46 PM, Steve D'Aprano
wrote:
>
>> And yes, Steve, this is a challenge to you: if you think C's undefined
>> behaviour is an abomination that should not be allowed to exist,
>
> CPython doesn't have to define the behaviour here. In *that* sense, the
> ordinary, regular sen
On Thu, 25 May 2017 11:26 am, Chris Angelico wrote:
> On Thu, May 25, 2017 at 9:34 AM, bartc wrote:
>> That was quite likely with older Fortrans, where subroutines only used
>> pass-by-reference, but which didn't stop you passing references to
>> constants that the subroutine could then modify.
>
On 2017-05-25, Dennis Lee Bieber wrote:
> On Thu, 25 May 2017 00:34:52 +0100, bartc declaimed the
> following:
>
>
>>That was quite likely with older Fortrans, where subroutines only
>>used pass-by-reference, but which didn't stop you passing references
>>to constants that the subroutine could th
On Thu, 25 May 2017 10:59:55 +1200, Gregory Ewing wrote:
> bartc wrote:
>
>> Yet the language will stop you assigning to 672, or "abc".
>>
>> Maybe the language could have been made even smaller if that was not
>> checked; after all the developer ought to be trusted not to assign to
>> them!
>
>
On Wed, May 24, 2017 at 8:49 PM, wrote:
> On Tuesday, May 23, 2017 at 11:47:21 PM UTC-4, bream...@gmail.com wrote:
>> Well that's what is says here https://github.com/ofek/venum so it must be
>> true. Please move over Ethan, your time is up :-)
>>
>> Kindest regards.
>>
>> Mark Lawrence.
>
> He
On Tuesday, May 23, 2017 at 11:47:21 PM UTC-4, bream...@gmail.com wrote:
> Well that's what is says here https://github.com/ofek/venum so it must be
> true. Please move over Ethan, your time is up :-)
>
> Kindest regards.
>
> Mark Lawrence.
Hey I've just run some tests and have updated the doc
On Thu, May 25, 2017 at 9:34 AM, bartc wrote:
> That was quite likely with older Fortrans, where subroutines only used
> pass-by-reference, but which didn't stop you passing references to constants
> that the subroutine could then modify.
>
> I doubt that's still the case. With C, however, I tried
On 24/05/2017 23:59, Gregory Ewing wrote:
bartc wrote:
Yet the language will stop you assigning to 672, or "abc".
Maybe the language could have been made even smaller if that was not
checked; after all the developer ought to be trusted not to assign to
them!
I'm told that some Fortran implem
bartc wrote:
Yet the language will stop you assigning to 672, or "abc".
Maybe the language could have been made even smaller if that was not
checked; after all the developer ought to be trusted not to assign to them!
I'm told that some Fortran implementations experimented with
something akin
bartc wrote:
Anyway, my Python 3.4 comprises 5000 files in around 90MB. Minimalism
hasn't really worked.
Most of that is standard library code, not part of the core
language.
Well, named constants are just such literals, but with a name. The
design of Python however means that that immediatel
Chris Angelico wrote:
So Fred might still think "final is great,
my stuff runs 0.1% faster", but Joe thinks "final is a pain in the
behind".
C# addresses this issue by making final the default. That way,
your behind is so numb from constant pain that you don't really
notice it, and the relief f
Steve D'Aprano wrote:
But I'll note that Python has supported read-only
properties for, oh, a decade or more, and do I hear people complaining
about how much libraries and applications over-use and abuse properties?
That's not quite the same thing. Python doesn't go out of its
way to support re
On Wed, May 24, 2017 at 4:11 PM, bartc wrote:
> On 24/05/2017 15:31, Steve D'Aprano wrote:
>> If you don't want to assign to a name, then
>> just don't assign to it. No need to build support for constants into the
>> language when you can trust the developer to Don't Do That.
>
> Yet the language
On 24/05/2017 15:31, Steve D'Aprano wrote:
Same as if Python supported constants (names that can only be assigned to
once).
That's not quite the same as my notion of 'named constant' that I expand
below. This suggests that the actual literal bound to the name may not
be known until runtime.
On Thu, May 25, 2017 at 12:31 AM, Steve D'Aprano
wrote:
> On Wed, 24 May 2017 10:07 pm, Chris Angelico wrote:
>
>> I'm sure it could be done. But would it really benefit anyone
>> anything? Java has "final" classes, which can't be subclassed; and I
>> haven't heard many people saying "I wish you w
On Wed, May 24, 2017 at 3:10 AM, Steve D'Aprano
wrote:
> The page says:
>
> venum provides an Enum that is actually just a namedtuple,
No kidding. This is the entirety of the code for it:
from collections import namedtuple
def Enum(*args, **kwargs):
fields, values = zip(*args)
ret
On 05/24/2017 07:31 AM, Steve D'Aprano wrote:
On Wed, 24 May 2017 10:07 pm, Chris Angelico wrote:
On Wed, May 24, 2017 at 7:10 PM, Steve D'Aprano wrote:
Although I wonder:
- maybe the enumeration (the class ContentTypes) could have a nicer repr
than
- maybe you could add functionality to
On Wed, 24 May 2017 10:07 pm, Chris Angelico wrote:
> On Wed, May 24, 2017 at 7:10 PM, Steve D'Aprano
> wrote:
>> Although I wonder:
>>
>> - maybe the enumeration (the class ContentTypes) could have a nicer repr
>> than
>>
>>
>>
>> - maybe you could add functionality to freeze the enumeration so
On Wed, May 24, 2017 at 7:10 PM, Steve D'Aprano
wrote:
> Although I wonder:
>
> - maybe the enumeration (the class ContentTypes) could have a nicer repr
> than
>
>
>
> - maybe you could add functionality to freeze the enumeration so that new
> members cannot be added?
>
>
> class ContentTypes(Enu
On Wed, 24 May 2017 01:47 pm, breamore...@gmail.com wrote:
> Well that's what is says here https://github.com/ofek/venum so it must be
> true. Please move over Ethan, your time is up :-)
The page says:
venum provides an Enum that is actually just a namedtuple, but
easier to create. Thi
On Wed, May 24, 2017 at 5:22 PM, Ethan Furman wrote:
> On 05/23/2017 08:47 PM, breamore...@gmail.com wrote:
>
>> Well that's what is says here https://github.com/ofek/venum so it must be
>> true. Please move over Ethan, your time is up :-)
>
>
> No comment.
>
# No longer no comment.
ChrisA
--
On 05/23/2017 08:47 PM, breamore...@gmail.com wrote:
Well that's what is says here https://github.com/ofek/venum so it must be true.
Please move over Ethan, your time is up :-)
No comment.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Well that's what is says here https://github.com/ofek/venum so it must be true.
Please move over Ethan, your time is up :-)
Kindest regards.
Mark Lawrence.
--
https://mail.python.org/mailman/listinfo/python-list
36 matches
Mail list logo
