On 16 November 2016 at 08:51, Mikhail V wrote:
> What semantics it will fundamentally break or so hard to implement?
I'm afraid I don't have time at the moment to fully review your email,
but my first impression is that you are proposing that the name "self"
be treated specially. It's going to be
On 16 November 2016 at 13:55, Cory Benfield wrote:
>> If you have any idea about how we could reach more coders I’m all ears.
>
> Coders who need OIDC will go looking for it and will find their options.
> Ultimately, a huge number of projects haven’t suffered from being outside the
> standard li
On 16 November 2016 at 16:48, Mikhail V wrote:
> On 16 November 2016 at 10:27, Paul Moore wrote:
>> On 16 November 2016 at 08:51, Mikhail V wrote:
>>> What semantics it will fundamentally break or so hard to implement?
>>
>> I'm afraid I don't have time
On 16 November 2016 at 17:50, Ryan Gonzalez wrote:
> If someone decided to be weird and have __add__ and __iadd__ do two
> different things, this would completely break that. Granted, that's a stupid
> idea to begin with, but it's still poor justification for the code breakage.
If you think of a
rcastic, not all readers
> > can. Your messages can also be cited out of context.
>
> Mikhail has long since gone past the point where further posts from
> him deserve such consideration. Replying to Paul Moore when
> deprecating "sarcastic" replies is just bad manners
On 17 November 2016 at 03:07, Stephen J. Turnbull
wrote:
> Paul Moore writes:
>
> > PS Note for anyone who wants to take this off on a wild tangent - my
> > above comment is *in the context of Python as it has been defined for
> > 20+ years*.
>
> Not quite. Augme
On 17 November 2016 at 02:42, Stephen J. Turnbull
wrote:
> But I am not a draconian security policy QA/security reviewer. I'd
> take anything Paul Moore says pretty seriously, as he operates in such
> an environment.
For context, my environment is one that doesn't formally us
On 17 November 2016 at 10:58, Cory Benfield wrote:
> Paul, you mentioned that discovery on PyPI is a problem: I don’t contest that
> at all. But I don’t think the solution to that problem is to jam modules into
> the standard library, and I think even less of that idea when there is no
> formal
On 17 November 2016 at 11:12, Stephen J. Turnbull
wrote:
> > However, when it comes to draconian security policies, *transitive
> > recommendations have power*: if CPython is approved, and python-dev
> > collectively says "we recommend pip, virtualenv, and requests", then
> > folks in locked d
On 17 November 2016 at 12:27, Cory Benfield wrote:
> This isn’t me disagreeing with you, just me pointing out that the fuzziness
> around this makes me nervous. It has been my experience that a large number
> of protocol implementations in the standard library are already struggling to
> meet t
On 17 November 2016 at 14:45, Chris Angelico wrote:
> Personally, when I hit step 6, I search the web. PyPI search is
> exhaustive but not very usefully ranked (for this purpose). Searching
> for a keyword or protocol will give undue weight to a module whose
> name is simply that word, even if tha
On 23 November 2016 at 08:08, François Leblanc wrote:
> It's why I'd prefer this integrate in language, but if there no way to get
> it without performance cost
> I will have a look to a pylint solution...
The point here is that if there is a way to get it without a
performance cost (I can't imag
On 26 November 2016 at 07:16, Nick Coghlan wrote:
> On 26 November 2016 at 13:26, Guido van Rossum wrote:
>> I think one reason why such proposals are unwelcome to experienced users may
>> be that when done right this is totally legitimate, and the requirement to
>> use an @override decorator is
On 28 November 2016 at 13:28, Tomas Orsava wrote:
> The ``.missing.py`` extension will be added to the end of the list, and
> configured to be handled by ``SourceFileLoader``. Thus, if a module is not
> found in its proper location, the ``XYZ.missing.py`` file is found and
> executed, and further
On 28 November 2016 at 15:51, Tomas Orsava wrote:
> I believe I may have found the Windows curses implementation, it's called
> PDCurses [0], and this website [1] appears to be distributing it under the
> name `curses`.
My apologies, I should have included a pointer. That is indeed the
distributi
On 28 November 2016 at 21:11, Ethan Furman wrote:
> One "successful" use-case that would be impacted is the fallback import
> idiom:
>
> try:
> # this would do two full searches before getting the error
> import BlahBlah
> except ImportError:
> import blahblah
Under this proposal, the
On 28 November 2016 at 22:33, Steve Dower wrote:
> Given that, this wouldn't necessarily need to be an executable file. The
> finder could locate a "foo.missing" file and raise ModuleNotFoundError with
> the contents of the file as the message. No need to allow/require any Python
> code at all, an
On 29 November 2016 at 10:51, Wolfgang Maier
wrote:
> On 29.11.2016 10:39, Paul Moore wrote:
>>
>> On 28 November 2016 at 22:33, Steve Dower wrote:
>>>
>>> Given that, this wouldn't necessarily need to be an executable file. The
>>> fin
On 30 November 2016 at 02:14, Stephen J. Turnbull
wrote:
> How about:
>
> class Blog:
> pass
>
> blog = get_blog_for_date(someday)
>
> logn = log(blog.size)
>
> NameError: Python doesn't recognize the function "log". Did you
> mean "Blog"?
>
> Wouldn't
>
> NameErro
On 7 December 2016 at 23:52, Mikhail V wrote:
> Proposal: I would want to have a possibility to input it *by decimals*:
>
> s = "first cyrillic letters: \{1040}\{1041}\{1042}"
> or:
> s = "first cyrillic letters: \(1040)\(1041)\(1042)"
>
> =
>
> This is more compact and seems not very cont
On 13 December 2016 at 11:28, Nick Coghlan wrote:
> Armed with those, the "give me all the attributes from __dir__"
> command would be:
>
> attrs = dict.from_attrs(obj, dir(obj))
Which of course can already be spelled as
attrs = { attr: getattr(obj, attr) for attr in dir(obj) }
There's
Would this only apply to recent versions of Windows? (IIRC, the VT100
support is Win10 only). If so, I'd be concerned about scripts that
worked on *some* Windows versions but not others. And in particular,
about scripts written on Unix using raw VT codes rather than using a
portable solution like c
On 5 January 2017 at 00:31, Steven D'Aprano wrote:
> This is a good point. Until now, I've been assuming that
> hash.from_iterable should consider order. But frozenset shows us that
> sometimes the hash should *not* consider order.
>
> This hints that perhaps the hash.from_iterable() should have i
On 5 January 2017 at 13:28, Neil Girdhar wrote:
> The point is that the OP doesn't want to write his own hash function, but
> wants Python to provide a standard way of hashing an iterable. Today, the
> standard way is to convert to tuple and call hash on that. That may not be
> efficient. FWIW f
On 6 January 2017 at 09:02, Neil Girdhar wrote:
>
> Yeah, looks like you missed a revision. There were two emails. I suggested
> adding ImmutableIterable and ImmutableSet, and so there is an obvious
> implementation of __hash__ for both.
OK, sorry.
The proposal is still getting more complicate
On 6 January 2017 at 07:26, Neil Girdhar wrote:
> On Fri, Jan 6, 2017 at 2:07 AM Stephen J. Turnbull
> wrote:
>>
>> Neil Girdhar writes:
>>
>> > I don't understand this? How is providing a default method in an
>> > abstract base class a pessimization? If it happens to be slower
>> > than the
On 12 January 2017 at 04:39, Mikhail V wrote:
> And my first though is about "will not change". Like: never ever change or
> like: will not change in 10 years or 20 years.
Like: "Please don't waste people's time trying to start a discussion
about them". In 10 or 20 years, if opinions have changed
On 12 January 2017 at 09:04, George Fischhof wrote:
> Hi There,
>
> Settable defaulting to decimal instead of float
>
> It would be good to be able to use decimal automatically instead of float if
> there is a setting. For example an environment variable or a flag file.
>
> Where and when accuracy
On 12 January 2017 at 10:28, Victor Stinner wrote:
> George requested this feature on the bug tracker:
> http://bugs.python.org/issue29223
>
> George was asked to start a discusson on this list. I posted the
> following comment before closing the issue:
>
> You are not the first one to propose the
On 12 January 2017 at 12:07, Nick Coghlan wrote:
> On 12 January 2017 at 20:30, Paul Moore wrote:
>> It's unlikely that there's a practical suggestion here that hasn't
>> been discussed before and rejected
>
> There's one practical decimal-literal-relate
On 12 January 2017 at 15:34, Victor Stinner wrote:
> 2017-01-12 13:13 GMT+01:00 Stephan Houben :
>> Something like:
>> from __syntax__ import decimal_literal
>
> IMHO you can already implement that with a third party library, see for
> example:
> https://github.com/lihaoyi/macropy
>
> It also rem
On 12 January 2017 at 19:33, Sven R. Kunze wrote:
> This a very absolute-sounding title. Maybe inserting a "(most likely)"
> between "that" and "won't" will give it the right nudge.
Well, the whole point of the document is to stop people falsely hoping
that they can "persuade" people to change th
On 20 January 2017 at 16:51, Elizabeth Myers wrote:
> Should I write up a PEP about this? I am not sure if it's justified or
> not. It's 3 changes (calcsize and two format specifiers), but it might
> be useful to codify it.
It feels a bit minor to need a PEP, but having said that did you pick
up
On 20 January 2017 at 18:18, Guido van Rossum wrote:
> I'd be wary of making a grab-bag of small improvements, it encourages
> bikeshedding.
Agreed. Plus the bikeshedding and debating risks draining Elizabeth's
motivation.
Paul
___
Python-ideas mailing
On 20 January 2017 at 20:47, Elizabeth Myers wrote:
> Two things:
>
> 1) struct.unpack and struct.unpack_from should remain
> backwards-compatible. I don't want to return extra values from it like
> (length unpacked, (data...)) for that reason. If the calcsize solution
> feels a bit weird (it isn'
On 22 January 2017 at 22:45, Soni L. wrote:
> I've been thinking of an Immutable Builder pattern and an operator to go
> with it. Since the builder would be immutable, this wouldn't work:
>
> long_name = mkbuilder()
> long_name.seta(a)
> long_name.setb(b)
> y = long_name.build()
>
> Instead, you'd
On 23 January 2017 at 13:05, Soni L. wrote:
> Yeah but the dotequals operator has many other benefits:
>
> long_name .= __call__ # cast to callable
> long_name .= wrapped # unwrap
> etc
Those don't seem particularly clear to me.
> And it also looks neat.
Well, we have to agree to differ on th
On 23 January 2017 at 13:47, Hervé "Kyle" MUTOMBO
wrote:
> Paul Moore is clearly right when He says that this "a .= 1+1" doesn't make
> sense. It means nothing understandable although in "a .= s(e)" can mean
> something. As a matter of fact "a .=
On 25 January 2017 at 16:04, Thomas Kluyver wrote:
> On Wed, Jan 25, 2017, at 03:54 PM, Todd wrote:
>
> Those [.tar.foo] are just examples that I encounter a lot, there can be
> other cases where multiple extensions are used.
>
>
> The real issue is that there's no definition of what an extension
On 26 January 2017 at 16:11, Victor Stinner wrote:
> The download button of https://www.python.org/ currently gives the
> choice between Python 2.7 and 3.6. I read more and more articles
> saying that we reached a point where Python 3 became more popular than
> Python 2, Python 3 has now enough ne
On 26 January 2017 at 16:11, Victor Stinner wrote:
> Is it time to "hide" Python 2.7 from the default choice and only show
> Python 3.6 *by default*?
Actually, looking back at the "Download" dropdown for Windows, I see
Python 3.6.0Python 2.7.13
That's not really that bad (I recalled it bein
On 26 January 2017 at 22:32, M.-A. Lemburg wrote:
> On 26.01.2017 23:09, Random832 wrote:
>> On Thu, Jan 26, 2017, at 11:21, Paul Moore wrote:
>>> On a similar note, I always get caught out by the fact that the
>>> Windows default download is the 32-bit version. Ar
Resending because Google Groups handling of mailing lists is broken
:-( Sorry to anyone who gets double posts.
On 27 January 2017 at 08:39, Paul Moore wrote:
> On 27 January 2017 at 06:22, Denis Akhiyarov
> wrote:
>> The problem is not in Python packages, but when gluing Pytho
On 28 January 2017 at 02:11, C Anthony Risinger wrote:
> I can't articulate it we'll, or even fully isolate the reasons for it. All I
> really know is how I feel when peers ask me about Python or the reading I
> get when others speak about their experience using it. Python is absolutely
> one of m
On 2 February 2017 at 10:38, Cory Benfield wrote:
> This PEP would define a standard TLS interface in the form of a collection of
> abstract base classes. This interface would allow Python implementations and
> third-party libraries to provide bindings to TLS libraries other than OpenSSL
> that ca
On 2 February 2017 at 12:01, wrote:
> P.P.S.: The function is tested, it’s working 😊
>
First of all, thanks for your suggestion, and for taking the time to help
improve Python. As noted, random.uniform probably does what you want, so we
don't really need this function.
But in case it's of inter
On 7 February 2017 at 12:33, Thomas Kluyver wrote:
> On Sat, Jan 28, 2017, at 11:26 AM, Paul Moore wrote:
>> I'm working on
>> a project to bundle a working zipapp with the embedded distribution to
>> make a standalone exe - would having something like that make
On 7 February 2017 at 14:29, Steve Dower wrote:
> You can leave python.exe out of your distribution to avoid it showing up on
> PATH, or if your stub explicitly LoadLibrary's vcruntime140.dll and then
> python36.dll you should be able to put them wherever you like.
Understood, but I may need pyth
On 8 February 2017 at 00:49, eryk sun wrote:
>> LoadLibrary might work (I'm only calling Py_Main). I seem to recall
>> trying this before and having issues but that might have been an
>> earlier iteration which made more complex use of the C API. Also, I
>> want to load python3.dll (the stable ABI
On 10 February 2017 at 10:45, Markus Meskanen wrote:
> Keep in mind that the extra syntax is *very* minor, and goes hand-to-hand
> with the existing attribute access syntax. Basically it's taking the
> existing syntax to one more place, where it in my opinion should have been
> since long ago.
In
On 10 February 2017 at 11:16, Chris Angelico wrote:
> On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore wrote:
>> Furthermore, once we open up this possibility, I would expect requests
>> for things like
>>
>> func_table = {}
>> func_table["foo"] =
On 10 February 2017 at 13:55, Stephan Houben wrote:
> My point would be that the new syntax *also* requires one to figure out what
> the new syntax does.
This is an extremely good point. It is mentioned when new syntax is
proposed (the term often used is "discoverability") but the idea never
seem
On 10 February 2017 at 14:00, Markus Meskanen wrote:
>> > I've started working on a PEP for this since most people seem to be for
>> > it.
>>
>> I don't know how you get "most people" -- there's only been a handful of
>> responses in the few hours since the original post. And apart from one
>> exp
On 10 February 2017 at 16:09, Markus Meskanen wrote:
> But if people are gonna do it anyways with the tools provided (monkey
> patching), why not provide them with better tools?
Because encouraging and making it easier for people to make mistakes
is the wrong thing to do, surely?
Paul
__
On 12 February 2017 at 04:37, Steven D'Aprano wrote:
>> Making a dedicated syntax or decorator for patching is saying that we
>> (the language) think you should do it.
>
> We already have that syntax:
>
> anything.name = thing
And the point here is that we don't need to extend def, because we
alr
On 12 February 2017 at 16:51, Markus Meskanen wrote:
>> I will say, though, that you're right that we've over-reacted a bit to
>> the monkeypatching use case. Although maybe that's because no-one can
>> think of many *other* use cases that they'd need the new syntax for
>> :-)
> Hi Paul, I believ
On 15 February 2017 at 11:07, Steven D'Aprano wrote:
>> I have two ides to improve the package index:
>
> Thank you for your ideas, but I don't think this is the right place for
> suggesting improvements to PyPI. You could try looking through the list
> of other Python mailing lists:
>
> https://m
On 20 February 2017 at 20:54, Ryan Gonzalez wrote:
> Apologies if this has already been covered!
>
> Right now, if you want to get multiple elements in a list, you have to do:
>
> elements = [mylist[a], mylist[b]]
>
> My proposal is two-folded:
>
> - Right now, a[b,c] is already valid syntax, sinc
On 23 February 2017 at 13:37, Henk-Jaap Wagenaar
wrote:
> Note that this has been suggested before at least once
> (https://mail.python.org/pipermail/python-dev/2007-November/075257.html),
> and that thread itself suggests it has been suggested before and shutdown by
> Guido (though no source is g
On 23 February 2017 at 14:20, Henk-Jaap Wagenaar
wrote:
>
> In a straw poll at the company I work at everyone was in favour, though they
> obviously are not in charge of implementing or changing documentation so
> that is easy for them to say, they've got no skin in the game. I don't know
> whethe
On 23 February 2017 at 15:18, Henk-Jaap Wagenaar
wrote:
> Thanks for typing that all out and taking the time to respond to my emails.
> I think as you say, it might be good to put this somewhere obvious.
>
> I did find https://docs.python.org/devguide/langchanges.html and
> http://www.curiouseffic
On 1 March 2017 at 01:31, qhlonline wrote:
> My code example is not proper, Yes, may be this is better:
> list.sort().revers(
We can already do this - reversed(sorted(lst))
This is a long-established design decision in Python. It would need a
*very* compelling use case to even think about chan
On 1 March 2017 at 13:50, Steven D'Aprano wrote:
> It is possible that we could come up with a pretty-printing protocol,
> but that wouldn't be a trivial job.
I'd be inclined to do this via simplegeneric. Let pprint do what it
currently does, but allow users to register implementations for
specif
On 1 March 2017 at 14:48, Eric V. Smith wrote:
>
> If you mean functools.singledispatch, then I agree. It's even mentioned as a
> motivating case in PEP 443.
Sorry - that was a thinko on my part - yes, functools.singledispatch.
Paul
___
Python-ideas m
On 1 March 2017 at 19:38, Serhiy Storchaka wrote:
> On 01.03.17 11:31, Paul Moore wrote:
>>
>> On 1 March 2017 at 01:31, qhlonline wrote:
>>>
>>> My code example is not proper, Yes, may be this is better:
>>> list.sort().revers(
>>
>>
>
On 2 March 2017 at 11:31, Stephan Houben wrote:
> NoDefault would be special syntax so that this would be disallowed:
>
> f(NoDefault)
I think the key point of confusion here is whether the language needs
to enforce this or it's just convention.
MAL is saying that f(NoDefault) is disallowed - bu
On 2 March 2017 at 13:11, Serhiy Storchaka wrote:
> On 02.03.17 14:20, Paul Moore wrote:
>>
>> So I guess I'm +0.5 on the proposed "positional only parameters"
>> syntax, and -1 on any form of new language-defined sentinel value.
>
>
> My proposi
On 2 March 2017 at 14:24, Steven D'Aprano wrote:
> I like this! If the caller doesn't provide a value, the parameter
> remains unbound and any attempt to look it up will give a NameError or
> UnboundLocalError.
Hmm. But those exceptions currently indicate with almost 100%
certainty, a programming
On 3 March 2017 at 18:29, Ed Kellett wrote:
> I guess I don't have any hope of convincing people who think there's no need
> to ever do this, but I have a couple of questions for the people who think
> the existing solutions are fine:
>
> - Which of the existing things (slice + [default], conditio
On 5 March 2017 at 13:03, Ed Kellett wrote:
>
> No. I'm asking: if list.get did exist, are there any cases (compatibility
> with old versions aside) where list.get's semantics would be applicable, but
> one of the alternatives would be the better choice?
Self-evidently no. But what does that prov
On 5 March 2017 at 19:13, Ed Kellett wrote:
>> I think we're going to have to just disagree. You won't convince me
>> it's worth adding list.get unless you can demonstrate some *existing*
>> costs that would be removed by adding list.get, and showing that they
>> are greater than the costs of addi
On 24 March 2017 at 15:41, Ryan Gonzalez wrote:
> Recently, I was working on a Windows GUI application that ends up running
> ffmpeg, and I wanted to see the command that was being run. However, the
> file name had a Unicode character in it (it's a Sawano song), and when I
> tried to print it to t
On 24 March 2017 at 16:37, Victor Stinner wrote:
> *If* we change something, I would prefer to modify sys.stdout. The
> following issue proposes to add
> sys.stdout.set_encoding(errors='replace'):
> http://bugs.python.org/issue15216
I thought I recalled seeing something like that discussed somewh
On 25 March 2017 at 11:24, Pavel Velikhov wrote:
> No, the current solution is temporary because we just don’t have the
> manpower to
> implement the full thing: a real system that will rewrite parts of PythonQL
> queries and
> ship them to underlying databases. We need a real query optimizer and
On 27 March 2017 at 10:54, Brice PARENT wrote:
> I get it, but it's more a matter of perception. To me, the version I
> described is just Python, while yours is Python + specific syntax. As this
> syntax is only used in PyQL sub-language, it's not really Python any more...
... which is why I susp
On 27 March 2017 at 13:50, Ram Rachum wrote:
> This would make writing / reading JSON to a file a one liner instead of a
> two-line with clause.
That hardly seems like a significant benefit...
Paul
___
Python-ideas mailing list
Python-ideas@python.org
On 27 March 2017 at 15:33, Donald Stufft wrote:
> What do you think about adding methods pathlib.Path.write_json and
> pathlib.Path.read_json , similar to write_text, write_bytes, read_text,
> read_bytes?
>
>
>
> -1, I also think that write_* and read_* were mistakes to begin with.
Text is (much)
On 27 March 2017 at 15:40, Ram Rachum wrote:
> Another idea: Maybe make json.load and json.dump support Path objects?
If they currently supported filenames, I'd say that's a reasonable
extension. Given that they don't, it still seems like more effort than
it's worth to save a few characters
On 27 March 2017 at 15:48, Eric V. Smith wrote:
> On 3/27/17 10:40 AM, Ram Rachum wrote:
>>
>> Another idea: Maybe make json.load and json.dump support Path objects?
>
>
> json.dump requires open file objects, not strings or Paths representing
> filenames.
>
> But does this not already do what you
On 27 March 2017 at 17:43, Bruce Leban wrote:
> the ability to read one json object from the input rather than reading the
> entire input
Is this a well-defined idea? From a quick read of the JSON spec (which
is remarkably short on details of how JSON is stored in files, etc)
the only reference I
On 28 March 2017 at 08:54, Simon D. wrote:
> I believe that the u"" notation in Python 2.7 is defined by while
> importing the unicode_litterals module.
That's not true. The u"..." syntax is part of the language. from
future import unicode_literals is something completely different.
> Each regex
On 31 March 2017 at 09:20, Stephan Houben wrote:
> FWIW, I also strongly prefer the Verbal Expression style and consider
> "normal" regular expressions to become quickly unreadable and
> unmaintainable.
Do you publish your code widely? What's the view of 3rd party users of
your code? Until this t
On 12 April 2017 at 14:35, Kamal Mustafa wrote:
> Never mind. site._script() as pointed out by Wes Turner is what I need:-
>
> Python 3.4.2 (default, Oct 8 2014, 10:45:20)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
import site
site._s
On 15 April 2017 at 10:45, Nick Coghlan wrote:
> So I'd be opposed to trying to make generator objects natively thread
> aware - as Stephen notes, the GIL is an implementation detail of
> CPython, so it isn't OK to rely on it when defining changes to
> language level semantics (in this case, wheth
On 25 April 2017 at 03:53, Steven D'Aprano wrote:
> On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:
>
>> I often find myself writing __init__ methods of the form:
>>
>> def __init__(self, foo, bar, baz, spam, ham):
>> self.foo = foo
>> self.bar = bar
>> self.baz = baz
>> self.spam =
On 25 April 2017 at 22:15, Brice PARENT wrote:
>> Also, I did find the decorator proposal intriguing, though have to say I
>> probably wouldn't bother to use it unless it were a builtin or I had a dozen
>> parameters to deal with.
>>
> If you *need* a shorter solution, even though I'm not entirely
On 25 April 2017 at 22:27, Mike Miller wrote:
> On 2017-04-25 14:15, Brice PARENT wrote:
>>
>> But, any of these proposals, mine and yours, if you really need this to
>> shorten
>> the code writing time or vertical space only, is not a better idea than to
>> propose a macro to your IDE editor, or
On 25 April 2017 at 23:30, Erik wrote:
> As I said above, it's not about the effort writing it out. It's about the
> effort (and accuracy) of reading the code after it has been written.
Well, personally I find all of the syntax proposals relatively
unreadable. So that's definitely a matter of opi
On 26 April 2017 at 16:17, Erik wrote:
> On 26/04/17 08:59, Paul Moore wrote:
>>
>> It should be possible to modify the decorator to take a list
>> of the variable names you want to assign, but I suspect you won't like
>> that
>
>
> Now you're se
On 26 April 2017 at 21:51, Erik wrote:
> It doesn't make anything more efficient, however all of the suggestions of
> how to do it with current syntax (mostly decorators) _do_ make things less
> efficient.
Is instance creation the performance bottleneck in your application?
That seems unusual. I
On 26 April 2017 at 22:42, Erik wrote:
> 2) The original proposal, which does belong on -ideas and has to take into
> account the general case, not just my specific use-case.
>
> The post you are responding to is part of (2), and hence reduced performance
> is a consideration.
Ah, OK. I'm discoun
On 28 April 2017 at 00:18, Erik wrote:
>> The semantics are very different and there's little or no connection
>> between importing a module and setting an attribute on self.
>
> At the technical level of what goes on under the covers, yes. At the higher
> level of what the words mean in spoken En
On 28 April 2017 at 12:55, Tin Tvrtković wrote:
> I'm putting forward three examples. These examples are based on attrs since
> that's what I consider to be the best way of having declarative classes in
> Python today.
Your comments and examples are interesting, but don't they just come
down to "
On 28 April 2017 at 14:07, Nick Coghlan wrote:
>> Am I missing some point?
>
> Yes, the point I attempted to raise earlier: at the language design
> level, "How do we make __init__ methods easier to write?" is the
> *wrong question* to be asking. It's treating the symptom (writing an
> imperative
On 28 April 2017 at 23:04, Erik wrote:
>> See what I mean? Things get out of hand *very* fast.
>
> I don't see how that's getting "out of hand". The proposal is nothing more
> complicated than a slightly-different spelling of assignment. It could be
> done today with a text-based preprocessor whic
On 1 May 2017 at 12:13, NoxDaFox wrote:
>
> I think it could be a good fit for the `concurrent.futures` module.
> Decorated functions would return a `Future` object and run the logic in a
> separate thread or process.
>
>
> @concurrent.futures.thread
> def function(arg, kwarg=0):
> return arg
On 3 May 2017 at 02:48, Erik wrote:
> Anyway, I know you can't stop anyone from *proposing* something like this,
> but as soon as they do you may decide to quote the recipe from
> "https://docs.python.org/3/library/functions.html#zip"; and try to block
> their proposition. There are already thread
On 3 May 2017 at 06:43, Serhiy Storchaka wrote:
> On 02.05.17 22:07, Ram Rachum wrote:
>>
>> I have a suggestion: Add a function shutil.get_dir_size that gets the
>> size of a directory, including all the items inside it recursively. I
>> currently need this functionality and it looks like I'll ha
On 25 May 2017 at 20:01, Eric Snow wrote:
> More significantly, I genuinely believe that isolated
> interpreters in the same process is a tool that many people will find
> extremely useful and will help the Python community. Consequently,
> exposing subinterpreters in the stdlib would result in a
On 8 June 2017 at 08:15, Stephen J. Turnbull
wrote:
> If you like this feature, and wish it were in Python, I genuinely wish
> you good luck getting it in. My point is just that in precisely that
> use case I wouldn't be passing dictionaries that need destructuring
> around. I believe that to be
501 - 600 of 896 matches
Mail list logo
