On Mon, Sep 11, 2017 at 8:21 PM, Barry Warsaw wrote:
> On Sep 11, 2017, at 19:16, Guido van Rossum wrote:
> >
> > Or we could just have two arguments, eq= and order=, and
> some rule so that you only need to specify one or the other but not both.
> (E.g. order=True implies eq=True.) That seems b
On Sep 11, 2017, at 19:16, Guido van Rossum wrote:
>
> Or we could just have two arguments, eq= and order=, and some
> rule so that you only need to specify one or the other but not both. (E.g.
> order=True implies eq=True.) That seems better than needing new constants
> just for this flag.
Y
Hi there,
I have had the privilege of getting to know some core developers at PyCon in
Portland, and I've met some others through my volunteering at PyGotham and the
NYC Python meetup group (resisting urge to name-drop).
In spite of not joining the mailing list until about a week ago at Brett
C
On Mon, Sep 11, 2017 at 6:04 PM, Larry Hastings wrote:
>
>
> On 09/11/2017 08:44 AM, Guido van Rossum wrote:
>
> I worry that in the end @property isn't general enough and the major use
> cases end up still having to use __class__ assignment, and then we'd have a
> fairly useless feature that we
Or we could just have two arguments, eq= and order=, and some
rule so that you only need to specify one or the other but not both. (E.g.
order=True implies eq=True.) That seems better than needing new constants
just for this flag.
On Mon, Sep 11, 2017 at 6:49 PM, Barry Warsaw wrote:
> On Sep 11,
On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw wrote:
> On Sep 11, 2017, at 18:15, Nathaniel Smith wrote:
>
>> Compared to checking it on each call to sys.breakpointhook(), I guess
>> the two user-visible differences in behavior would be:
>>
>> - whether mutating os.environ["PYTHONBREAKPOINT"] ins
I am new to this list.
Skip suggested that I join.
I convene ISO/IEC/JTC1SC22/WG23 Programming Languages Working Group. We produce
a suite of international technical reports that document vulnerabilities in
programming that can lead to serious safety and security breaches.
We published TR 2
On 09/06/2017 08:26 AM, Guido van Rossum wrote:
So we've seen a real use case for __class__ assignment: deprecating things on
access. That use case could also be solved
if modules natively supported defining __getattr__ (with the same "only used if
attribute not found otherwise" semantics
as i
On Sep 11, 2017, at 18:36, Eric V. Smith wrote:
> So if we don't do enums, I think the choices are ints, strs, or maybe
> True/False/None. Do you have a preference here?
>
> If int or str, I assume we'd want module-level constants.
>
> I like the name compare=, and 3 values makes sense: None, E
On Sep 11, 2017, at 18:15, Nathaniel Smith wrote:
> Compared to checking it on each call to sys.breakpointhook(), I guess
> the two user-visible differences in behavior would be:
>
> - whether mutating os.environ["PYTHONBREAKPOINT"] inside the process
> affects future calls. I would find it quit
On 9/11/2017 6:28 PM, Guido van Rossum wrote:
Oddly I don't like the enum (flag names get too long that way), but I do
agree with everything else Barry said (it should be a trivalue flag and
please don't name it cmp).
So if we don't do enums, I think the choices are ints, strs, or maybe
True/
On 9/11/2017 12:34 PM, Nathaniel Smith wrote:
On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote:
On 9/10/17 11:08 PM, Nathaniel Smith wrote:
Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unha
On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw wrote:
> On Sep 10, 2017, at 13:46, Nathaniel Smith wrote:
>>
>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
>>> For PEP 553, I think it’s a good idea to support the environment variable
>>> $PYTHONBREAKPOINT[*] but I’m stuck on a design q
On 09/11/2017 08:44 AM, Guido van Rossum wrote:
I worry that in the end @property isn't general enough and the major
use cases end up still having to use __class__ assignment, and then
we'd have a fairly useless feature that we cant withdraw, ever.
What can I say--I don't have that worry ;-)
On Sep 10, 2017, at 13:46, Nathaniel Smith wrote:
>
> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
>> For PEP 553, I think it’s a good idea to support the environment variable
>> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get
>> some feedback.
>>
>> Shoul
On Sep 10, 2017, at 12:16, Guido van Rossum wrote:
>
> I think programmatic overrides should be able to decide for themselves if
> they want to honor PYTHONBREAKPOINT or not, since I can imagine use cases
> that go both ways. So it should be checked in sys.breakpointhook().
Thanks Guido, I’ll
On 2017-09-11 17:00, Barry Warsaw wrote:
I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.
Well, "the Pythons" were irreverent, were they not? ;)
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
On Sep 11, 2017, at 16:51, Mike Miller wrote:
>
> On 2017-09-11 05:26, Eric V. Smith wrote:
>> On 9/10/17 10:27 PM, Raymond Hettinger wrote:
>
> I've typically used these type of objects as records. When in an irreverent
> mood I've called them bags.
I’ve used ‘bag’ too, but I’m not sure that
On 2017-09-11 05:26, Eric V. Smith wrote:
On 9/10/17 10:27 PM, Raymond Hettinger wrote:
I've typically used these type of objects as records. When in an irreverent
mood I've called them bags. The short name is helpful as they get used all over
the place. I'll add Nick's "declarative" as i
On 2017-09-10 18:20, Eric V. Smith wrote:
I'll think about adding some more language to the PEP about it.
Agreed, was only looking for mention or example that a specific type was not
required. Perhaps even dusting off the word "annotation" to describe them.
___
On 2017-09-10 23:38, Michel Desmoulin wrote:
I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?
Not preferring, but having it as an alternative. Mainly for 2 reasons:
1 - data
On Sep 11, 2017, at 15:16, Ethan Furman wrote:
>>
>> enum Compare(enum.Enum):
>> none = 1
>> unordered = 2
>> ordered = 3
>
> I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent"
> instead of "unordered"; better to say what they are rather than what they are
Oddly I don't like the enum (flag names get too long that way), but I do
agree with everything else Barry said (it should be a trivalue flag and
please don't name it cmp).
On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman wrote:
> On 09/11/2017 03:00 PM, Barry Warsaw wrote:
>
>> On Sep 10, 2017, at
On 09/11/2017 03:00 PM, Barry Warsaw wrote:
On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:
I've sometimes wished that attrs let me control whether it generated equality
methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the
cmp= argument should take an enum with optio
On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:
>
> I've sometimes wished that attrs let me control whether it generated equality
> methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the
> cmp= argument should take an enum with options none/equality-only/full?
I have ha
On Mon, Sep 11, 2017 at 10:20 AM, Victor Stinner
wrote:
> 2017-09-11 19:00 GMT+02:00 Chris Barker :
> > There are a heck of a lot in the os module:
> > ['get_blocking',
>
> This one is not a good example: it takes a parameter. You cannot
> convert it to a property.
>
I'm sure there are many that
2017-09-11 19:00 GMT+02:00 Chris Barker :
> I wish there were a property feature available almost very time I encounter
> a "get*" method in the stdlib (or any where):
>
> There are a heck of a lot in the os module:
>
> In [4]: [s for s in dir(os) if s.startswith('get')]
> Out[4]:
>
> ['get_blockin
On Thu, Sep 7, 2017 at 3:49 PM, Larry Hastings wrote:
> But I can cite at least one place in the standard library that would have
> been better if it'd been implemented as a module property:
>
os.stat_float_times().
>
I wish there were a property feature available almost very time I encounter
a
On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote:
> On 9/10/17 11:08 PM, Nathaniel Smith wrote:
>>
>> Hi Eric,
>>
>> A few quick comments:
>>
>> Why do you even have a hash= argument on individual fields? For the
>> whole class, I can imagine you might want to explicitly mark a whole
>> class
On Mon, Sep 11, 2017 at 6:51 AM, Eric V. Smith wrote:
> On 9/11/17 9:43 AM, tds...@mailbox.org wrote:
>
>> Hi Eric,
>>
>> I have on question not addressed yet.
>> The implementation is based on "__annotations__" where the type is
>> specified.
>> But "__annotations__" is not always filled. An int
On Sun, Sep 10, 2017 at 8:52 PM, Larry Hastings wrote:
>
> On 09/06/2017 02:13 PM, Ronald Oussoren wrote:
>
> To be honest this sounds like a fairly crude hack. Updating the __class__
> of a module object feels dirty, but at least you get normal behavior w.r.t.
> properties.
>
> Okay. Obviously I
2017-09-10 11:42 GMT+02:00 Skip Montanaro :
> I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We
> publish an international technical report, ISO IEC TR 24772 Guide to
> avoiding programming language vulnerabilities through language selection
> use. Annex D in this document add
Hi Eric,
I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special
optimization
could remove all __annotations__ for performance reasons. (Discussed in other
On 9/11/17 9:43 AM, tds...@mailbox.org wrote:
Hi Eric,
I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special
optimization
could remove all __annotations_
On 9/10/17 11:08 PM, Nathaniel Smith wrote:
Hi Eric,
A few quick comments:
Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unhashable, but it seems like the only thing you can do with
the field-lev
On 9/10/17 10:27 PM, Raymond Hettinger wrote:
On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote:
And now I've pushed a version that works with Python 3.6 to PyPI at
https://pypi.python.org/pypi/dataclasses
It implements the PEP as it currently stands. I'll be making some tweaks in the
comin
On 11 September 2017 at 12:27, Raymond Hettinger
wrote:
> Once you get agreement on the functionality, name bike-shedding will likely
> be next. In a way, all classes are data classes so that name doesn't tell me
> much. Instead, it would be nice to have something suggestive of what it
> actu
37 matches
Mail list logo
