enums:
"There are 83 open Enum mypy issues at the the time of this writing.
Getting the Enum datatype to work with mypy is becoming impossible as
I find myself having to use cast() in at least every other line."
(see https://gi
thub.com/python/mypy/issues/12841)
There have also
On 16/06/2023 23.47, Thomas Passin via Python-list wrote:
On 6/16/2023 1:40 AM, dn via Python-list wrote:
Have you figured-out a use for the @enum.member and @enum.nonmember
decorators (new in Python 3.11)?
mypy is having trouble with 3.11 enums:
"There are 83 open Enum mypy issues a
On 6/16/2023 1:40 AM, dn via Python-list wrote:
Have you figured-out a use for the @enum.member and @enum.nonmember
decorators (new in Python 3.11)?
"What's New" says:
Added the member() and nonmember() decorators, to ensure the decorated
object is/is not converted to an enu
Have you figured-out a use for the @enum.member and @enum.nonmember
decorators (new in Python 3.11)?
"What's New" says:
Added the member() and nonmember() decorators, to ensure the decorated
object is/is not converted to an enum member.
The PSL docs say:
@enum.member
A de
ome attributes are required (e.g. __name__) it is easy to set them in
> the Python code (__name__ = 'pycenum').
>
> 2. No need to import the enum module in the C code. It is easier to do
> it in the Python code.
>
Don't you need the '__import__' attribute for th
e__ = 'pycenum').
2. No need to import the enum module in the C code. It is easier to do
it in the Python code.
3. Can you define your DummyType in the Python code instead of the C
code? Even if you need to create in the C code, it may be better to
define your enum class inside a dummy Dummy
> > > > I'm working on a Python C extension and I would like to expose a
> > > > custom enum (as in: a class inheriting from enum.Enum) that would be
> > > > entirely defined in C.
> > >
> > > I think that it would be much easier to define
On Sat, Jul 31, 2021 at 3:01 PM Bartosz Golaszewski wrote:
>
> On Fri, Jul 30, 2021 at 2:41 PM Serhiy Storchaka wrote:
> >
> > 23.07.21 11:20, Bartosz Golaszewski пише:
> > > I'm working on a Python C extension and I would like to expose a
> > > cu
On Fri, Jul 30, 2021 at 2:41 PM Serhiy Storchaka wrote:
>
> 23.07.21 11:20, Bartosz Golaszewski пише:
> > I'm working on a Python C extension and I would like to expose a
> > custom enum (as in: a class inheriting from enum.Enum) that would be
> > entirely defined in
Instead of struggling to define an enum in C that can be read in Python - I'm
assuming you can pass strings back and forth - why not just print whatever you
need to give to Python into a string (or maybe 2 strings) and send it to Python
as string? Python is a dynamic language, it can qu
23.07.21 11:20, Bartosz Golaszewski пише:
> I'm working on a Python C extension and I would like to expose a
> custom enum (as in: a class inheriting from enum.Enum) that would be
> entirely defined in C.
I think that it would be much easier to define it in Python, and then
either i
On Sat, Jul 24, 2021 at 6:55 AM Dan Stromberg wrote:
>
>
> On Fri, Jul 23, 2021 at 1:20 AM Bartosz Golaszewski wrote:
>>
>> Hi!
>>
>> I'm working on a Python C extension and I would like to expose a
>> custom enum (as in: a class inheriting from enum.
On Fri, Jul 23, 2021 at 1:20 AM Bartosz Golaszewski wrote:
> Hi!
>
> I'm working on a Python C extension and I would like to expose a
> custom enum (as in: a class inheriting from enum.Enum) that would be
> entirely defined in C.
>
I'm probably missing something obvi
On Fri, Jul 23, 2021 at 5:08 PM MRAB wrote:
>
> On 2021-07-23 09:20, Bartosz Golaszewski wrote:
> > Hi!
> >
> > I'm working on a Python C extension and I would like to expose a
> > custom enum (as in: a class inheriting from enum.Enum) that would be
> >
On 2021-07-23 09:20, Bartosz Golaszewski wrote:
Hi!
I'm working on a Python C extension and I would like to expose a
custom enum (as in: a class inheriting from enum.Enum) that would be
entirely defined in C.
It turned out to not be a trivial task and the regular mechanism for
inheri
Hi!
I'm working on a Python C extension and I would like to expose a
custom enum (as in: a class inheriting from enum.Enum) that would be
entirely defined in C.
It turned out to not be a trivial task and the regular mechanism for
inheritance using .tp_base doesn't work - most likely
PEP: 663
Title: Improving and Standardizing Enum str(), repr(), and format() behaviors
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-...@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post
> On 31 May 2021, at 18:24, Peter Otten <__pete...@web.de> wrote:
>
> On 31/05/2021 17:57, Colin McPhail via Python-list wrote:
>> Hi,
>> According to the enum module's documentation an Enum-based enumeration's
>> members can have values of any t
On 31/05/2021 17:57, Colin McPhail via Python-list wrote:
Hi,
According to the enum module's documentation an Enum-based enumeration's
members can have values of any type:
"Member values can be anything: int, str, etc.."
You didn't read the fineprint ;)
Hi,
According to the enum module's documentation an Enum-based enumeration's
members can have values of any type:
"Member values can be anything: int, str, etc.."
I defined one with functions as member values. This seemed to work as long as
the functions were
On 5/28/21 5:23 AM, Ethan Furman wrote:
Greetings!
The Flag type in the enum module has had some improvements, but I find
it necessary to move one of those improvements into a decorator instead,
and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a
On 2021-05-28 04:23, Ethan Furman wrote:
Greetings!
The Flag type in the enum module has had some improvements, but I find it
necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
[snip]
So, like the enum.unique decorator
On 2021-05-27 at 20:23:29 -0700,
Regarding "name for new Enum decorator,"
Ethan Furman wrote:
> Greetings!
>
> The Flag type in the enum module has had some improvements, but I find it
> necessary to move one of those improvements into a decorator instead, and
> I'
Greetings!
The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a flag type can be either canonical (it repre
Here's a question on SO about typing, enum, and ABC:
https://stackoverflow.com/q/67610562/208880
No answers so far.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
MRAB wrote:
> On 2020-07-30 11:09, Chris Green wrote:
> > I am going round and round in steadily increasing frustration trying
> > to find the constants for button events in Pygobject/Gtk 3.
> >
> > I have the following imports:-
> >
> > import gi
> > gi.require_version('Gtk', '3.0')
>
On 2020-07-30 11:09, Chris Green wrote:
I am going round and round in steadily increasing frustration trying
to find the constants for button events in Pygobject/Gtk 3.
I have the following imports:-
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
fr
I am going round and round in steadily increasing frustration trying
to find the constants for button events in Pygobject/Gtk 3.
I have the following imports:-
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
from gi.repository import Gdk
The old GTK 2 co
le of related constants you would want to keep together,
but Python enums can be more complex than that both as structured data
and associated functions.
Is the above 'interfacing' an appropriate use of enum-s; or is it really
'overkill' or posturing?
I think it's an ent
rolling what control-data (cf statistics/source-data)
may be input.
Accordingly, as 'they' say, there is a "first time for everything", and
I starting playing with enums...
The PSL manual is somewhat sparse. The examples are weak and almost
solely introspective: if I have
or in your case
class Colors(TokenContainer):
red = Token()
green = Token()
blue = Token()
(this is using tri.token).
This seems like a good approach and is similar to the strategy Enum uses.
Site note: When we saw enums landing we hoped we could ditch tri.token but
unfortunately
On 07/28/2019 01:46 PM, Erik Aronesty wrote:
One possibility
---
class Status:
valid = 1
invalid = 2
unknown = 3
if status is Status.valid:
# good status, do something
elif status is Status.unknown:
figure_out_status()
elif status is Status.invalid:
class Status:
valid = 1
invalid = 2
unknown = 3
On Fri, Jul 26, 2019, 3:37 PM Chris Angelico wrote:
> On Sat, Jul 27, 2019 at 5:16 AM Erik Aronesty wrote:
> >
> > I just spend a while tracking down and killing all "if Enum" and "if not
> > En
On Sat, Jul 27, 2019 at 5:16 AM Erik Aronesty wrote:
>
> I just spend a while tracking down and killing all "if Enum" and "if not
> Enum" bugs in my code. I was frankly shocked that this didn't raise a
> ValueError to begin with.
>
> Apparently all en
On 07/26/2019 11:56 AM, Erik Aronesty wrote:
I just spend a while tracking down and killing all "if Enum" and "if not
Enum" bugs in my code. I was frankly shocked that this didn't raise a
ValueError to begin with.
Very few items, if any, raise a ValueError when
I just spend a while tracking down and killing all "if Enum" and "if not
Enum" bugs in my code. I was frankly shocked that this didn't raise a
ValueError to begin with.
Apparently all enums are true/false depending on whether the underlying
value is truthy or
oadGrammer(GrammarFile)
EnumList = ['class NonTerminal(Enum):\n']
for Index, NonTerminal in enumerate(grammar.NonTerminals):
EnumList.append('%s = %d\n' % (NonTerminal, Index))
exec(''.join(EnumList), ..., ...)
The problem with this approach is that I can'
On 18/07/19 18:14, Ethan Furman wrote:
> On 07/18/2019 06:04 AM, Antoon Pardon wrote:
>
>> I am experimenting with writing an Earley Parser. Now I would like to
>> have the non-terminals from the grammer I am reading in, be represented
>> bye an enum like type. So that if
On 07/18/2019 06:04 AM, Antoon Pardon wrote:
I am experimenting with writing an Earley Parser. Now I would like to
have the non-terminals from the grammer I am reading in, be represented
bye an enum like type. So that if the grammer contains the following
production: Term -> Term '+&#
Something seems to have gone wrong with the formatting of my latest
contribution,
so let me try again.
I am experimenting with writing an Earley Parser. Now I would like to
have the non-terminals from the grammer I am reading in, be represented
bye an enum like type. So that if the grammer
Hi, I am experimenting with writing an Earley Parser. Now I would like
to have the non-terminals from the grammer I am reading in, be
represented bye an enum like type. So that if the grammer contains the
following production: Term -> Term '+' Factor I can reprensent the right
han
Ian Kelly :
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>>> class State(Enum):
>>> Maybe = 2
>>
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __
Ethan Furman writes:
> I'm asking because in doing some work on Enum it became apparent to me
> that having nested classes was not a smooth, satisfying experience,
> and I'm considering treating them the same way as methods (they will
> no longer be converted into members
Greetings!
So the stdlib Enum has been around for a few years now. Has anyone
written an enum that either had types as members:
class Types(Enum):
Int = int
Str = str
or that had nested classes:
class Types(Enum):
class Contained(Enum):
circle = 1
On 06/29/2018 05:51 PM, Steven D'Aprano wrote:
So not especially complimentary (sorry Ethan, but that was my first
impression) but not *necessarily* a bad thing either.
No worries! :)
The Jargon File adjective that comes closest is probably gnarly:
Wow, I haven't heard that word in a long
e of it this year?
- will it ever fall on my birthday?
etc. I think that once we start adding methods to enums, we're starting
to move into a gray area where they aren't *really* arbitrary enumerated
values any longer. (Maybe.) If your methods use "self", then they
implicitly car
On Sat, Jun 30, 2018 at 10:51 AM, Steven D'Aprano
wrote:
> ["Baroque"] should not mean "weird or bizarre", although I've seen a couple of
> lesser-quality dictionaries give that as a meaning. Which is itself weird
> and bizarre :-)
>
I guess those dictionaries are baroque. Or maybe just broke.
C
On Sat, 30 Jun 2018 09:02:37 +1000, Cameron Simpson wrote:
> On 29Jun2018 10:36, Ethan Furman wrote:
>>On 06/28/2018 10:52 PM, Steven D'Aprano wrote:
>>>It isn't clear to me why FederalHoliday is an Enum, especially as the
>>>API seems extremely baraque.
Cameron Simpson wrote:
It tends to mean "weird", but perhaps a more nuanced phrasing might be
unusual and strange, and usually connotes some degree of over complication.
When used in a derogatory way it means "excessively elaborate".
The Baroque period was characterised by extremely ornate
arch
Ethan Furman wrote:
They are the list of dates in which US banks are closed for electronic
business (funds transfers and things).
That sems like something that would be better specified in
a configuration file than hard-wired into the code, in case
the rules change.
--
Greg
--
https://mail.pyt
On 06/29/18 16:02, Cameron Simpson wrote:
On 29Jun2018 10:36, Ethan Furman wrote:
On 06/28/2018 10:52 PM, Steven D'Aprano wrote:
On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote:
Perhaps I am using Enum incorrectly, but here is my FederalHoliday
Enum.
Note that
On 29Jun2018 10:36, Ethan Furman wrote:
On 06/28/2018 10:52 PM, Steven D'Aprano wrote:
On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote:
Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum.
Note that date(), next_business_day, and year() are all callables.
On 06/28/2018 10:52 PM, Steven D'Aprano wrote:
On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote:
Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum.
Note that date(), next_business_day, and year() are all callables. The
AutoEnum parent assigns values from 1
On 29/06/2018 09:01, Ian Kelly wrote:
On Thu, Jun 28, 2018 at 10:06 PM Ben Finney wrote:
@total_ordering
class ChessPiece(Enum):
PAWN = 1, 'P'
KNIGHT = 2, 'N'
BISHOP = 3, 'B'
ROOK = 4, 'R'
# ...
@property
def l
ibutes in its API.
> >
> > Perhaps I am using Enum incorrectly, but here is my FederalHoliday
> > Enum. […]
>
> Thanks for the example. Yes, my personal impression is that class
> is not a good use of enum.Enum (nor enum.AutoEnum).
>
> To inherit from enum.Enu
want to have a
> > > class that is simultaneously behaving as an enumerated type, *and*
> > > has an API of custom callable attributes.
> >
> > You don't see value in enum members having properties?
>
> Is a Python property a callable attribute?
I was
On Thu, 28 Jun 2018 18:33:31 -0700, Ethan Furman wrote:
> On 06/28/2018 05:58 PM, Ben Finney wrote:
>
>> So I remain dumbfounded as to why anyone would want a class to *both*
>> be an enumerated type, *and* have callable attributes in its API.
>
> Perhaps I am using En
Ethan Furman writes:
> On 06/28/2018 05:58 PM, Ben Finney wrote:
>
> > So I remain dumbfounded as to why anyone would want a class to *both* be
> > an enumerated type, *and* have callable attributes in its API.
>
> Perhaps I am using Enum incorrectly, but here is
On 06/28/2018 05:58 PM, Ben Finney wrote:
So I remain dumbfounded as to why anyone would want a class to *both* be
an enumerated type, *and* have callable attributes in its API.
Perhaps I am using Enum incorrectly, but here is my FederalHoliday Enum. Note that date(), next_business_day, and
On Thu, 28 Jun 2018 20:34:58 +1000, Ben Finney wrote:
> Ethan Furman writes:
>
>> Consider the following Enum definition:
>>
>> class Color(Enum):
>> RED = 1
>> GREEN = 2
>> BLUE = 3
>> @property
>>
design?
>
> By design. It is entirely possible to want an enum of types (int,
> float, str, etc.).
Seems strange to me. Why enum of types but not an enum of functions or
methods?
Perhaps you could have had an explicit decorator?
class Colours(Enum):
RED = 1
class
gt; has an API of custom callable attributes.
>
> You don't see value in enum members having properties?
Is a Python property a callable attribute?
>>> class Lorem:
... @property
... def spam(self):
... print(self)
...
>>> foo
On Thu, Jun 28, 2018 at 4:38 AM Ben Finney wrote:
>
> Ethan Furman writes:
>
> > Consider the following Enum definition:
> >
> > class Color(Enum):
> > RED = 1
> > GREEN = 2
> > BLUE = 3
> > @property
> >
On 06/28/2018 01:11 AM, Steven D'Aprano wrote:
On Wed, 27 Jun 2018 07:48:53 -0700, Ethan Furman wrote:
[Note: there is a similar thread on Python-Ideas, if you would like to
respond there.]
Consider the following Enum definition:
class Color(Enum):
RED = 1
GREE
Ethan Furman writes:
> Consider the following Enum definition:
>
> class Color(Enum):
> RED = 1
> GREEN = 2
> BLUE = 3
> @property
> def lower(self):
> return self.name.lower()
> def spam(self):
>
On Wed, 27 Jun 2018 07:48:53 -0700, Ethan Furman wrote:
> [Note: there is a similar thread on Python-Ideas, if you would like to
> respond there.]
>
> Consider the following Enum definition:
>
> class Color(Enum):
>RED = 1
>GREEN = 2
>
[Note: there is a similar thread on Python-Ideas, if you would like to respond
there.]
Consider the following Enum definition:
class Color(Enum):
RED = 1
GREEN = 2
BLUE = 3
@property
def lower(self):
return self.name.lower()
def spam(self
On 05/26/2018 01:00 AM, Steven D'Aprano wrote:
I wish there was a simpler way to define symbols with identity but no
state or behaviour...
Check out the Constant class in aenum. You still might want to customize the
repr, though.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/pytho
On Sat, 26 May 2018 23:54:51 +1000, Chris Angelico wrote:
> Seems pretty non-controversial, which means it's almost guaranteed to
> reach 100+ posts debating what the name should be.
Including:
* 27 posts declaring that using such singleton symbols is completely
un-Pythonic and is sure to doom
On Sat, May 26, 2018 at 6:50 PM, Steven D'Aprano
wrote:
> On Sat, 26 May 2018 18:14:08 +1000, Chris Angelico wrote:
>
>> On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
>> wrote:
>>> Actually I don't really need all the features of Enums, I might just
>>> define my own class:
>>>
>>>
>>> class M
Steven D'Aprano wrote:
> Am I silly for wanting to make a single enum?
>
> I have a three-state flag, True, False or Maybe. Is is confusing or bad
> practice to make a single enum for the Maybe case?
>
>
> from enum import Enum
> class State(Enum):
> Ma
Ian Kelly :
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico wrote:
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __str__ though.
I use strings for enums:
class X:
HERE = "HERE"
THERE = "THERE"
EVERYWHERE
26.05.18 08:07, Ian Kelly пише:
On Fri, May 25, 2018 at 11:00 PM, Chris Angelico wrote:
On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
wrote:
Am I silly for wanting to make a single enum?
I have a three-state flag, True, False or Maybe. Is is confusing or bad
practice to make a s
On Sat, 26 May 2018 18:14:08 +1000, Chris Angelico wrote:
> On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
> wrote:
>> Actually I don't really need all the features of Enums, I might just
>> define my own class:
>>
>>
>> class Maybe:
>> def __repr__(self):
>> return "Maybe"
>>
>>
On Sat, May 26, 2018 at 6:00 PM, Steven D'Aprano
wrote:
> Actually I don't really need all the features of Enums, I might just
> define my own class:
>
>
> class Maybe:
> def __repr__(self):
> return "Maybe"
>
> Maybe = Maybe()
>
>
>
> I wish there was a simpler way to define symbols
>>>
>> Does it need to have a value of 2? If not:
>>
>> # Tri-state logic
>> Maybe = object()
>
> The enum has a nice __str__ though.
Yes, that's why I wanted to use enum.
Also because apparently Enums are the future and nobody uses object() any
more
On Sat, May 26, 2018 at 3:07 PM, Ian Kelly wrote:
> On Fri, May 25, 2018 at 11:00 PM, Chris Angelico wrote:
>> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
>> wrote:
>>> Am I silly for wanting to make a single enum?
>>>
>>> I have a three-state
On Fri, May 25, 2018 at 11:00 PM, Chris Angelico wrote:
> On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
> wrote:
>> Am I silly for wanting to make a single enum?
>>
>> I have a three-state flag, True, False or Maybe. Is is confusing or bad
>> practice to ma
On Sat, May 26, 2018 at 2:46 PM, Steven D'Aprano
wrote:
> Am I silly for wanting to make a single enum?
>
> I have a three-state flag, True, False or Maybe. Is is confusing or bad
> practice to make a single enum for the Maybe case?
>
>
> from enum import Enum
> class
Am I silly for wanting to make a single enum?
I have a three-state flag, True, False or Maybe. Is is confusing or bad
practice to make a single enum for the Maybe case?
from enum import Enum
class State(Enum):
Maybe = 2
Maybe = State.Maybe
del State
Is there a better way of handling a
ast wrote:
> https://docs.python.org/3.5/library/enum.html#planet
>
> Documentation says that the value of the enum
> members will be passed to this method.
>
> But in that case __init__ waits for two arguments, mass
> and radius, while enum member's value is a tuple
Hi
Below an example of enum which defines an __init__
method.
https://docs.python.org/3.5/library/enum.html#planet
Documentation says that the value of the enum
members will be passed to this method.
But in that case __init__ waits for two arguments, mass
and radius, while enum member&#
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!
>
>
est regards.
>>
>> Mark Lawrence.
>
> Hey I've just run some tests and have updated the docs showing memory usage
> https://github.com/ofek/venum
>From the updated documentation:
"""
This example was run on a 64-bit machine.
Note that stdlib's Enum by it
1 - 100 of 253 matches
Mail list logo
