On 15 November 2017 at 08:22, Nick Coghlan wrote:
> On 15 November 2017 at 16:13, Steve Barnes wrote:
>>
>> - "pip -X[.Y][-32|-64] operation ..." tries to find a python matching
>> -X[.Y][-32|-64] and if it succeeds executes "python -m pip operation
>> ..." with that python, (if it doesn't find
On 14 November 2017 at 10:02, Nathaniel Smith wrote:
> On Tue, Nov 14, 2017 at 12:56 AM, Paul Moore wrote:
>> On 14 November 2017 at 03:08, Nathaniel Smith wrote:
>>> On Nov 13, 2017 6:47 PM, "Nick Coghlan" wrote:
>>
>>>> and a pip.bat with t
On 14 November 2017 at 03:08, Nathaniel Smith wrote:
> On Nov 13, 2017 6:47 PM, "Nick Coghlan" wrote:
>> and a pip.bat with the equivalent contents on Windows?
>> (Bonus: maybe this would fix the problem with upgrading pip on
>> Windows?)
>
> Depending on how the batch file was written, I think
On 13 November 2017 at 20:43, MRAB wrote:
> On 2017-11-13 19:10, Barry Warsaw wrote:
>> The specifics aren't as important as the general use case: multiple
>> tools competing for the same valuable real-estate.
>>
>> I have no ideas how to improve the situation, and of course any solution
>> would
On 13 November 2017 at 18:57, Chris Barker wrote:
> This has gotten to be a big thread, and it's a pretty intractable problem,
> but I think there are a few fairly small things that could be done to at
> least make it a bit easier:
In principle, I agree with the ideas here, but there are some
pra
On 12 November 2017 at 18:38, Antoine Pitrou wrote:
> On Sun, 12 Nov 2017 12:20:45 +
> Paul Moore wrote:
>>
>> > Well, not exactly. Do you do python -m venv, or py -x.x -m venv or
>> > pythonx -m venv ? Wait, it's not installed by default on debian.
>>
On 12 November 2017 at 13:18, Nick Coghlan wrote:
>> Seriously? Debian don't provide venv in the standard Python install?
>> That's just broken.
>
> Yup. And RHEL/CentOS don't provide Python 3.x by default at all - you
> need to grab it via other means.
Wow. I have no problem with not providing P
On 12 November 2017 at 06:19, Michel Desmoulin
wrote:
>> 1. Go back to adding Python to PATH. Because our installers don't say
>> "do you want to uninstall the old version", we should probably do a
>> check for a "python" command on PATH in the installer, and if there is
>> one, warn the user "You
On 10 November 2017 at 11:37, Oleg Broytman wrote:
> On Fri, Nov 10, 2017 at 07:48:35AM +0100, Michel Desmoulin
> wrote:
>> On linux you
>> can't pip install, you need --users, admin rights or a virtualenv.
>
>Isn't it the same on Windows? For an admin-installed Python you need
> --users, ad
On 10 November 2017 at 10:01, Nick Coghlan wrote:
> On 10 November 2017 at 19:50, Paul Moore wrote:
>> On 10 November 2017 at 08:01, Nick Coghlan wrote:
>>> That tooling is venv:
>>>
>>> * it ensures you have "pip" on your PATH
>>> * it
On 10 November 2017 at 08:01, Nick Coghlan wrote:
> You can't have it both ways - the only way we can systematically mask
> the environmental differences between Windows, Linux and Mac OS X is
> by providing tooling that actually masks those differences, which
> means introducing that tooling beco
On 7 November 2017 at 20:38, Chris Barker wrote:
> On Tue, Nov 7, 2017 at 5:04 AM, Thomas Jollans wrote:
>>
>> As Ivan said earlier, perhaps the Windows installers should provide a
>> "python3" executable, so "python3 -m pip" works everywhere.
>
> absolutely! I really, really thought it did (
On 7 November 2017 at 13:06, אלעזר wrote:
> On Tue, Nov 7, 2017 at 2:45 PM Nick Coghlan wrote:
>>
>> On 7 November 2017 at 03:52, Michel Desmoulin
>> wrote:
>>
>> > And assume that stuff in any tutorial you make they know this stuff.
>> >
>> > This is a strong barrier or entry IMO.
>>
>> Sure, b
On 7 November 2017 at 12:44, Nick Coghlan wrote:
>> - make sure the system path is correctly set
>
> Recent python.org Windows installers do this automatically, but there
> are unfortunately still lots of ways for things to go wrong.
I believe the latest installers switch it off again, because on
On 6 November 2017 at 06:42, Lukasz Langa wrote:
>> Now it's annoying already. Because you have to write every tutorial to
>> include a special case for them. But at least it's not a required step
>> to run your program.
>>
>> However, if you do code using type hints and typing is not installed,
>
On 5 November 2017 at 18:40, Antoine Pitrou wrote:
> I think typing shouldn't require any extra typing (ha) on Unix either.
> I don't remember what the rationale was for having to type
> "python -m ensurepip" to get pip installed, but typing is just a
> library, not an executable tool that may be
On 5 November 2017 at 14:47, Antoine Pitrou wrote:
>
> Le 05/11/2017 à 14:30, Paul Moore a écrit :
>> On 5 November 2017 at 10:48, Antoine Pitrou wrote:
>>> On Sun, 5 Nov 2017 13:46:59 +1000
>>> Nick Coghlan wrote:
>>>> * ensurepip gains the a
On 5 November 2017 at 10:48, Antoine Pitrou wrote:
> On Sun, 5 Nov 2017 13:46:59 +1000
> Nick Coghlan wrote:
>> * ensurepip gains the ability to also install bundled wheel files
>
> Why? Why wouldn't you put the wheel directly in site-packages on
> install?
I'm not quite sure what you mean? It n
On 30 October 2017 at 16:22, Nick Coghlan wrote:
>> Also, on Windows, I believe that any emulation of execve either leaves
>> the original process in memory, or has problems getting console
>> inheritance right. It's been a long time since I worked at that level,
>> and things may be better now, b
On 30 October 2017 at 15:53, Antoine Pitrou wrote:
> On Tue, 31 Oct 2017 01:44:10 +1000
> Nick Coghlan wrote:
>>
>> A few specific notes here:
>>
>> 1. As you say, this sort of already works in notebooks, since instructors
>> can say to run "!pip install requests" and then restart the language ke
On 29 October 2017 at 20:44, Alex Walters wrote:
> Writing scripts for non-developers, in an unmanaged environment (IT cant
> push a python install to the system) on windows means running pyinstaller
> et. al., on your script, if it has dependencies or not. Its not worth it to
> walk someone thro
On 29 October 2017 at 19:40, Stephan Houben wrote:
> Hi Antoine,
>
> 2017-10-29 20:31 GMT+01:00 Antoine Rozo :
>>
>> Hi,
>>
>> What would be the difference with current pip module?
>> pip.main(['install', 'some_package'])
>
>
>
> My understanding is that direct use of the `pip` module is explicitl
On 29 October 2017 at 18:56, Guido van Rossum wrote:
> The two use cases you describe (scripters and teachers) leave me luke-warm
> -- scripters live in the wild west and can just pip install whatever (that's
> what it means to be scripting)
In my experience, "scripting" *does* include people for
On 29 October 2017 at 10:40, Stephan Houben wrote:
> Perhaps slightly off-topic, but I have sometimes wondered if
> pip could not be made somewhat friendlier for the absolute newbie
> and the classroom context.
>
> Some concrete proposals.
>
> 1. Add a function `pip` to the interactive interpreter
On 29 October 2017 at 09:51, Antoine Pitrou wrote:
> On Sun, 29 Oct 2017 17:54:22 +1000
> Nick Coghlan wrote:
>> This means that
>> if educators aren't teaching them, or redistributors aren't providing them,
>> then they're actively doing their users a disservice
>
> Which redistributors do not p
On 29 October 2017 at 07:54, Nick Coghlan wrote:
> On 29 October 2017 at 15:16, Guido van Rossum wrote:
>>
>> Why? What's wrong with pip install?
>
> At a technical level, this would just be a really thin wrapper around 'pip
> install' (even thinner than ensurepip in general, since these librarie
On 26 October 2017 at 13:53, Daniel Moisset wrote:
> This is to clarify that this si NOT about function composition, just an
> alternate
> application syntax
The idea is already dead, based on the quote from Guido, but this
makes it even more clear that it's inappropriate for Python. As you
said
OK, looks like I've lost track of what this thread is about then.
Sorry for the noise.
Paul
On 18 October 2017 at 16:40, Koos Zevenhoven wrote:
> On Wed, Oct 18, 2017 at 6:36 PM, Paul Moore wrote:
>>
>> On 18 October 2017 at 16:27, Koos Zevenhoven wrote:
>> > So y
On 18 October 2017 at 16:27, Koos Zevenhoven wrote:
> So you're talking about code that would make a C-implemented Python iterable
> of strictly C-implemented Python objects and then pass this to something
> C-implemented like list(..) or sum(..), while expecting no Python code to be
> run or sign
On 18 October 2017 at 10:56, Koos Zevenhoven wrote:
> I'm unable to reproduce the "uninterruptible with Ctrl-C" problem with
> infinite iterators. At least itertools doesn't seem to have it:
>
import itertools
for i in itertools.count():
> ... pass
> ...
> ^CTraceback (most recent ca
On 15 October 2017 at 13:51, Amit Green wrote:
> Once again, I think Paul Moore gets to the heart of the issue.
>
> Generators are simply confusing & async even more so.
>
> Per my earlier email, the fact that generators look like functions, but are
> not functions,
On 13 October 2017 at 23:30, Yury Selivanov wrote:
> At this point of time, there's just one place which describes one well
> defined semantics: PEP 550 latest version. Paul, if you have
> time/interest, please take a look at it, and say what's confusing
> there.
Hi Yury,
The following is my imp
On 15 October 2017 at 06:43, Nick Coghlan wrote:
> On 15 October 2017 at 15:05, Guido van Rossum wrote:
>>
>> I would like to reboot this discussion (again). It feels to me we're
>> getting farther and farther from solving any of the problems we might solve.
>>
>> I think we need to give up on do
On 15 October 2017 at 05:39, Nick Coghlan wrote:
> On 15 October 2017 at 05:47, Paul Moore wrote:
>>
>> On 14 October 2017 at 17:50, Nick Coghlan wrote:
>> > If you capture the context eagerly, then there are fewer opportunities
>> > to
>> > get mat
On 14 October 2017 at 17:50, Nick Coghlan wrote:
> On 14 October 2017 at 21:56, Paul Moore wrote:
>
> TL;DR of below: PEP 550 currently gives you what you're after, so your
> perspective counts as a preference for "please don't eagerly capture the
> creation
On 14 October 2017 at 08:09, Nick Coghlan wrote:
> To try and bring this back to synchronous examples that folks may find more
> intuitive, I figure it's worth framing the question this way: do we want
> people to reason about context variables like the active context is
> implicitly linked to the
On 13 October 2017 at 19:32, Yury Selivanov wrote:
>>> It seems simpler to have one specially named and specially called function
>>> be special, rather than make the semantics
>>> more complicated for all functions.
>>
>
> It's not possible to special case __aenter__ and __aexit__ reliably
> (sup
>>> a = [1,2,3]
>>> [x if x & 1 else 'even' for x in a]
[1, 'even', 3]
You're mixing the if clause of the list comprehension up with a
ternary expresssion. There's no "else" in the list comprehension if
clause.
Paul
On 5 October 2017 at 16:40, Jason H wrote:
a = [1,2,3]
[ x for x in
On 29 September 2017 at 11:25, Steven D'Aprano wrote:
> I like it very much.
>
> But as an alternative, perhaps all we really need is a context manager
> to set the std* files:
>
> with open('/dev/tty', 'r+') as f:
> with stdio(stdin=f, stdout=f):
> name = input('Name? ')
>
> print(nam
On 21 September 2017 at 02:53, Steven D'Aprano wrote:
> On Thu, Sep 21, 2017 at 11:13:44AM +1000, Nick Coghlan wrote:
>
>> I think so, as consider this question: how do you write a script that
>> accepts a user-supplied string (e.g. from a CSV file) and treats it as
>> hex floating point if it has
On 7 September 2017 at 20:14, Eric Snow wrote:
> On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore wrote:
>> Is there any reason why passing a callable and args is unsafe, and/or
>> difficult? Naively, I'd assume that
>>
>> interp.call('f(a)&
On 7 September 2017 at 19:26, Eric Snow wrote:
> As part of the multi-core work I'm proposing the addition of the
> "interpreters" module to the stdlib. This will expose the existing
> subinterpreters C-API to Python code. I've purposefully kept the API
> simple. Please let me know what you thi
On 7 September 2017 at 11:43, Denis Krienbühl wrote:
> What I would love to see is the following syntax instead, which to me is much
> cleaner:
>
>if computation() as result:
>do_something_with_result(result)
Hi - thanks for your suggestion! This has actually come up quite a lot
in t
On 1 September 2017 at 12:50, Tarek Ziadé wrote:
> Hey,
>
> For large archives, I want to display a progress bar while the archive
> is being extracted with:
>
> https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall
>
> I could write my own version of extractall() to do this, o
On 23 August 2017 at 18:49, Chris Angelico wrote:
> Still -1 on this becoming a stdlib package, as there's nothing I've
> yet seen that can't be done as a third-party package. But it's less
> scary than I thought it was :)
IMO, this would make a great 3rd party package (I note that it's not
yet p
On 11 August 2017 at 05:49, Steven D'Aprano wrote:
> On Thu, Aug 10, 2017 at 01:25:24PM -0700, Chris Barker wrote:
>> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
>>
>>
>> > Also, there's a potential issue
>> > here - consider
>> &
On 10 August 2017 at 21:25, Chris Barker wrote:
> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore wrote:
>
>>
>> Also, there's a potential issue
>> here - consider
>>
>> [expr for var in even_numbers() if is_odd(var) while var < 100]
>>
>&g
On 10 August 2017 at 14:42, Steven D'Aprano wrote:
> I don't think it is confusing. Regardless of the implementation, the
> meaning of:
>
> [expression for x in sequence while condition]
>
> should (I believe) be obvious to anyone who already groks comprehension
> syntax. The mapping to a for-loop
On 4 August 2017 at 14:20, Joao S. O. Bueno wrote:
> Had not this been discussed here earlier this year?
>
> (And despite there being perceived dangers to readability in the long term,
> was accepted?)
>
> Here it is on an archive:
> https://mail.python.org/pipermail/python-ideas/2017-February/044
On 4 August 2017 at 08:39, Paul Laos wrote:
> Hi folks
> I was thinking about how sometimes, a function sometimes acts on classes,
> and behaves very much like a method. Adding new methods to classes existing
> classes is currently somewhat difficult, and having pseudo methods would make
> that
>
On 1 August 2017 at 14:01, Louie Lu wrote:
> I'm not sure if this is discuss before, but can "any" and "all"
> support like min_max "arg1, arg2, *args" style?
I don't see any particular reason why not, but is there a specific use
case for this or is it just a matter of consistency? Unlike max and
On 30 July 2017 at 16:24, Nick Coghlan wrote:
> Rather than being about any changes on that front, these threads are
> mostly about making it possible to write that first line as:
>
> MyNT = type(implicitly_typed_named_tuple_factory(foo=None, bar=None))
Is that really true, though? There's a
On 24 July 2017 at 17:37, Michel Desmoulin wrote:
> You are in the wrong thread. This thread is specifically about
> namedtupels literal.
In which case, did you not see Guido's post "Honestly I would like to
declare the bare (x=1, y=0) proposal dead."? The namedtuple literal
proposal that started
On 20 July 2017 at 10:15, Clément Pit-Claudel wrote:
> On 2017-07-20 11:02, Paul Moore wrote:
>>> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e.,
>>> why does this need to be syntax instead of a library?
>>
>> Agreed. Now that keyword ar
On 20 July 2017 at 07:58, Nathaniel Smith wrote:
> From the above it sounds like this ntuple literal idea would be giving
> us a third independent way to solve this niche use case (ntuple,
> namedtuple, structseq). This seems like two too many? Especially given
> that namedtuple is already arguabl
On 11 July 2017 at 11:19, Victor Stinner wrote:
> XXX should we abandon the stable ABI? Never really used by anyone.
Please don't. On Windows, embedding Python is a pain because a new
version of Python requires a recompile (which isn't ideal for apps
that just want to optionally allow Python scri
On 7 July 2017 at 04:54, Jeff Walker wrote:
> Here is an example:
>
> class NameError(BaseException):
> pass
>
> try:
> raise NameError('welker', db='users', template='{0}: unknown {db}.')
> except NameError as e:
> unknown_name = e.args[0]
> missing_fr
On 6 July 2017 at 18:59, Mark E. Haase wrote:
> On Thu, Jul 6, 2017 at 5:58 AM, Paul Moore wrote:
>>
>> To use the (already
>>
>> over-used) NameError example, Ken's proposal doesn't include any
>> change to how NameError exceptions are raised to st
On 6 July 2017 at 02:53, Jeff Walker wrote:
> Could you please expand on these statements:
>
>> the idea doesn't actually solve the problem it is intended to
>
> Specifically Ken started by saying that it should not be necessary to parse
> the
> messages to get the components of the message. He
On 4 July 2017 at 06:08, Nick Coghlan wrote:
> On 4 July 2017 at 09:46, Greg Ewing wrote:
>> Paul Moore wrote:
>>>
>>> As noted, I disagree that people are not passing components because
>>> str(e) displays them the way it does. But we're both just
On 3 July 2017 at 21:56, Jeff Walker wrote:
> Paul,
> Indeed, nothing gets better until people change the way they do their
> exceptions. Ken's suggested enhancement to BaseException does not
> directly solve the problem, but it removes the roadblocks that discourage
> people from passing the
On 3 July 2017 at 20:46, Jeff Walker wrote:
> I think you are fixating too much on Ken's example. I think I understand
> what he
> is saying and I agree with him. It is a problem I struggle with routinely. It
> occurs in
> the following situations:
Possibly. I hadn't reread the original e
On 3 July 2017 at 09:59, Ken Kundert wrote:
> I think in trying to illustrate the existing behavior I made things more
> confusing than they needed to be. Let me try again.
>
> Consider this code.
>
> >>> import Food
> >>> try:
> ... import meals
> ... except NameError as e:
>
On 1 July 2017 at 18:35, Nick Timkovich wrote:
> Devil's advocate: why prepare a patch and submit it if it is going to be
> dismissed out of hand. Trying to gauge support for the idea is a reasonable
> first-step.
That's perfectly OK, but it's important to phrase the email in a way
that makes tha
On 1 July 2017 at 07:13, Steven D'Aprano wrote:
> But the more I think about it the more I agree with Nick. Let's start
> by moving itertools.chain into built-ins, with zip and map, and only
> consider giving it an operator after we've had a few years of experience
> with chain as a built-in. We m
On 28 June 2017 at 05:30, Terry Reedy wrote:
> On 6/27/2017 10:47 PM, Nick Coghlan wrote:
>
>> While I haven't been following this thread closely, I'd like to note
>> that arguing for a "chain()" builtin has the virtue that would just be
>> arguing for the promotion of the existing itertools.chain
On 23 June 2017 at 19:28, Brendan Barnwell wrote:
> So to put it succinctly, as someone who's found discussion on this list
> interesting and valuable, I think there is value in having discussion about
> "what would Python be like if this idea were implemented" even if we never
> get very far with
On 23 June 2017 at 15:20, Sven R. Kunze wrote:
> On 23.06.2017 03:02, Cameron Simpson wrote:
>
>
> How about something like this?
>
>try:
>val = bah[5]
>except IndexError:
># handle your expected exception here
>else:
>foo(val)
>
>
> That is the kind of refactor
On 13 June 2017 at 23:36, Chris Angelico wrote:
> On Wed, Jun 14, 2017 at 8:10 AM, Mahmoud Hashemi wrote:
>> I didn't interpret the initial email as wanting an error on *all* circular
>> imports. Merely those which are unresolvable. I've definitely helped people
>> diagnose circular imports and w
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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
601 - 700 of 896 matches
Mail list logo
